In October 2025, a single Hydra head settled the last stretch of the Glacier Drop claim window. Five organizations ran it on 10 nodes. In nine days it processed 3.5 billion NIGHT and returned everything to the Cardano main chain.
It worked. It was also hard going, and we found two serious bugs in Hydra along the way. Since then, Hydra has moved to a new protocol version and a year of fixes. So we took the claim transactions our own pipeline builds and replayed them, on the same machine, against two versions: the 0.22.4 release we shipped on, and Hydra as it stands today. The rerun was done by the same team that operated the head during the drop, not by the Hydra core team.
- 1.9× claims settled per second
- 2.3× faster to settle one claim
- 43% less time end to end
This post covers what went wrong in 2025, what the v2 protocol changed, and how the rerun was measured, including what it does not tell you.
Some context first
Hydra is Cardano’s Layer 2 protocol. A head is one running instance of it: a small group of parties that agree transactions among themselves off-chain, then settle the result back on Cardano. Every party signs every snapshot, so no single operator has to be trusted, and only one operator has to be honest to ensure safety.
The Glacier Drop was Midnight’s token distribution. People with qualifying history on other chains could claim NIGHT between August 5 and October 20, 2025. Our head took the tail end of that window. It opened on October 14 and was fully settled back on the main chain by October 23.
A claim is one transaction: someone proves they are owed tokens and receives them. Each claim runs three Plutus scripts. Every figure in this post counts claims.
Hydra’s role in the drop was specific. Of the 24 billion NIGHT the token policy has minted, the claim path was designed to distribute a fifth, and 3.5 billion of that came through our head.
We broke it first
Ten nodes in production put Hydra under conditions its test setups did not. Every other bug report filed upstream that summer came from three or four nodes running default settings.
Two failures mattered. A restarted node would hang partway through replaying its own state file, so a routine restart could leave a party unable to rejoin the head. And a single rejected transaction, submitted a second time, would wedge the head for good.
The Hydra team fixed both while we were live. The first was hotfixed while we were still bringing the head up. The second shipped with a regression test so it cannot quietly return. Both fixes are part of Hydra today, which means every head opened since benefits from what a production drop exposed.
What it cost to run
The nine days of operation were the easy part. Getting the head open took weeks, and three problems accounted for most of that time.
Every flag, by hand
Each node took two separate lists, one of keys and one of hosts, and neither referenced the other. A miscounted key and a second host for the same party looked identical. Changing one host made the node lose its own history, so the only remedy was to wipe it and start again. At one point six people spent a week comparing flags across nodes by hand.
One shot at opening
Under the protocol we ran, the head opened only after every party had committed funds. Until the last commit landed nothing moved, and chasing whoever had not committed became the job. The only way out of a stalled opening was to abort and start over.
What changed in Hydra v2
Most of those problems trace back to how a head was opened and run. The v2 protocol changes both.
A shorter lifecycle
In v1, a head passed through Init, Commit, and Collect before it could take a single transaction, and every party had to act at each step. In v2, Init goes straight to Open and the head starts with no funds in it. There is no commit phase, so there is nothing to wait on and no reason to abort and restart because one party is late.
An open head that changes size
Funds now move in and out of a head without closing it.
Deposit Anyone can lock funds on Cardano for the head to pick up. After a settlement period, long enough that a chain rollback cannot undo the deposit, the next snapshot brings the funds into the head. Decommit Parties withdraw funds back to the main chain while the head keeps running. Recover If a deposit is not picked up before its deadline, the owner reclaims it on the main chain. Deposits cannot get stranded. Partial fanout A large head can settle back to the main chain across several transactions, so the size of a head no longer limits whether it can close cleanly.
The practical effect is a change in how heads get used. A v1 head was something you opened for a session and tore down afterwards. A v2 head can stay open for as long as it is useful, with value flowing through it.
Configuration you can check
Node configuration is now a file rather than a pile of command-line flags, and it can express a mirror host, a second machine for the same party, directly. The week we spent diffing flags by hand is work the configuration does for you today.
A smaller surface to depend on
The part of the protocol our integration reached into was redesigned, and the new design no longer exposes it. Integrators have fewer internals to lean on, which is the point.
The rerun
To compare the two versions on real work, the team that ran the 2025 head replayed 24,576 claim transactions built by our own claim pipeline, with real scripts and real signatures over generated allotments. We ran three runs on 0.22.4 and three on today’s Hydra, alternating between versions, on the same host. No run landed more than 3% away from its version’s median result.
Throughput went from 42 claims a second to 79. The time for a single claim to settle fell from 9.9 seconds to 4.4.
A median can hide a lot, so we also plotted every claim from every run as a distribution. The two versions form two separate humps, one centered near 9.9 seconds and one near 4.4. The whole shape moved, so the typical claim really is that much faster, not just the average.
End to end, the full set of 24,576 claims took 590.4 seconds on 0.22.4 and 339.1 seconds today.
Why our number is the smaller one
We ran the whole comparison a second time with trivial transactions: each one carried a single script that does nothing, against the three real scripts in a claim.
On trivial transactions the gap widens to 3.3 times. The version improvement is there whatever the scripts cost, but script execution is a fixed toll that neither version can avoid, and it holds our own figure down to 1.9 times. For a workload like ours, with real validation in every transaction, 1.9 times is the honest number.
You will see much larger throughput figures quoted for Hydra. Those are typically measured on transactions with no scripts at all, the cheap end of this chart.
Where this leaves us
The speed-up is the easiest part to put on a chart. The bigger change, for the people running a head, is in the operation. The two failures that hurt us in production are fixed and covered by tests. The configuration that took six people a week to reconcile is a file the node can check.
In short, Hydra v2 settles the same claims at 1.9 times the rate, settles each one 2.3 times faster, and finishes the full set in 339.1 seconds instead of 590.4. A head opens without a commit phase, takes deposits and decommits while it runs, reads its configuration from a file the node can check, and carries the fixes that production load exposed.
