Vasil Hard Fork Explained: What Cardano's 2022 Upgrade Changed

The Vasil hard fork was a Cardano protocol upgrade. IOG and the Cardano Foundation deployed it on mainnet with the hard fork combinator on 22 September 2022 at 21:44 UTC, which moved the network from the Alonzo era into the Babbage era. It brought four ledger changes: reference inputs (CIP-31), inline datums (CIP-32), reference scripts (CIP-33) and collateral outputs (CIP-40). It also brought Plutus V2 and diffusion pipelining, a faster way for nodes to relay blocks. Developers could use the new features from 27 September 2022, one epoch after the fork. IOG said ordinary ada holders did not need to do anything.

Vasil is now history. Cardano's most recent hard fork is van Rossem, which went live on 18 July 2026. It moved mainnet from protocol version 10 to 11 and added new Plutus built-ins. The next planned fork is Dijkstra, which opens a new ledger era. Much of what developers rely on today still dates from Vasil, so the 2022 changes are still worth knowing.

Where Vasil sits in Cardano's upgrade history

IOG's sources give February 2023 for Valentine, and the name points to a release around 14 February. We did not find an exact mainnet day.

What a hard fork means on Cardano

A hard fork changes the protocol rules in a way older software cannot follow. Nodes that do not upgrade can no longer validate the new chain. Cardano handles these changes with the hard fork combinator, which switches the chain to the new rules at an epoch boundary without restarting it. Vasil was planned and coordinated, not contested. Before the event, IOG reported that 98% of blocks were being minted by the new 1.35.3 node.

The four CIPs, one by one

CIP-31: Reference inputs

Problem. Before Vasil, a transaction could read the data in an output only by spending it and then recreating it. CIP-31 lists three costs of this:

• Other users had to wait for the recreated output, which limited some applications to one operation per block.
• Reading meant meeting the output's spending conditions.
• Simple lookups became expensive.

The CIP's examples include checking the state of a stablecoin state machine and reading data published by oracle-style data providers.

Change. A reference input lets a transaction read an output without spending it. The output stays in the UTXO set, and its spending conditions are not checked. A transaction must still spend at least one other output. Scripts see reference inputs through a new script-context field, which is why this needs Plutus V2. A transaction that mixes reference inputs with Plutus V1 scripts fails phase-1 validation.

CIP-32: Inline datums

Problem. Outputs used to hold only a datum hash. Whoever spent the output had to supply the datum itself, which was often passed around off-chain or dug out of the chain.

Change. An output can now carry the datum directly. There are trade-offs: an inline datum raises the output's minimum ada, because that minimum depends on data size, and the datum is public straight away. The datum-hash option is still available.

CIP-33: Reference scripts

Problem. Every transaction that used a script had to include the whole script. That bloated the chain, raised size-based fees and made transaction size limits easier to hit.

Change. A script can be stored in an output once. Later transactions point to it through a reference input instead of carrying it again. The output holding the script needs more minimum ada, scaled to the script's size. The CIP gives no figure for the fee saving.

CIP-40: Collateral outputs

Problem. Under Alonzo rules, collateral had to be pure ada, and all of it was taken if a script failed phase-2 validation. Users had to keep separate token-free UTXOs for collateral, and hardware wallets were reluctant to sign transactions putting large collateral at risk.

Change. A transaction can include a collateral output that returns the excess. The rule becomes: collateral inputs = collateral output + collateral consumed. Only the consumed amount, calculated from the fee and the collateralPercent parameter, is lost on failure. If there is no collateral output, the old rule applies.

Diffusion pipelining

Cardano's design budget is about 5 seconds for a new block to reach roughly 95% of the network, with blocks expected about every 20 seconds. Before pipelining, each node fully validated a block's body before passing the block on. Validation time therefore added up at every hop.

With pipelining, a node forwards the block once two quick checks pass:

1. The header is correct: it links to the previous block, and the VRF and signature checks for block leadership succeed.
2. The body is complete: it matches the body hash in the header.

Full body validation runs while the block is already moving. Body validation then counts against the 5-second budget only once, not once per hop. That leaves room for larger blocks and more throughput. IOG's 2022 post put the block-size limit at the time at 80 kB, up from 64 kB. It did not promise a specific throughput gain from pipelining alone.

Other Plutus changes in the same release

Cardano's documentation lists more changes that shipped with Vasil:

• Lower cost-model parameters for Plutus V1 and V2, which the documentation says gave 20–30% better script resource usage.
• A new serialiseData built-in.
• verifySignature renamed to verifyEd25519Signature.
• Scripts can see the redeemers for all inputs, not only the input being validated.
• Nodes now run one VRF check per hop instead of two, which speeds up block validation and syncing.
• A Plutus V2 script never has the same hash as a Plutus V1 script compiled from identical source. The documentation advises saving compiled scripts if you need stable hashes.

SECP256k1 signature support was not part of Vasil. It came with Valentine.

What it meant for users and developers

• Ada holders: IOG said no action was needed. People holding ada on a third-party platform were told to check whether that platform had upgraded, because service could be disrupted if it had not.
• Developers: Most of the new value was here. Contracts could read shared state without competing to spend the same output. They could publish data and scripts once and reuse them. They could also limit what a failed transaction costs.
• Network operators: IOG warned of a spike in activity after the upgrade and said it would monitor the network for at least four epochs before deciding on further parameter changes.

Who the upgrade is named after

Vasil St. Dabov was a Bulgarian mathematician and long-time Cardano ambassador who died before the upgrade launched. Cardano's own documentation describes the name as a tribute to him.

Frequently asked questions

When did the Vasil hard fork go live?

On 22 September 2022 at 21:44 UTC, on Cardano mainnet. The Plutus V2 features became usable on 27 September 2022, one epoch later.

Did ada holders have to do anything?

No. IOG said ordinary holders using Cardano for transactions and dApps did not need to take any action.

Is Vasil the latest Cardano upgrade?

No. Since Vasil there have been Valentine (2023), Chang (1 September 2024), Plomin (29 January 2025) and van Rossem (18 July 2026). Dijkstra is next.

Which CIPs did Vasil add?

CIP-31 (reference inputs), CIP-32 (inline datums), CIP-33 (reference scripts) and CIP-40 (collateral outputs).

Limitations: technical details come from IOG, Cardano documentation and the CIP texts. The CIPs give no measured fee or throughput figures, and none are claimed here.