Ouroboros Peras: settlement in minutes, and what happens when things go wrong

Peras would let Cardano treat a transaction as settled within about two minutes instead of waiting hours. Here is how it works, where it sits on the roadmap, how it compares with other chains, and what it would have meant during the November 2025 chain split.

The short answer

• Peras is about settlement, not speed of blocks. Blocks still arrive every 20 seconds or so under Praos. Peras adds stake pool voting on top, so a block can be treated as settled in about two minutes.
• It is the second phase of the Dijkstra upgrade. Phase 1 (Linear Leios and nested transactions) targets code completion in Q4 2026. Peras follows as a separate hard fork, with code completion estimated for Q2 2027, before governance and testing.
• It degrades gracefully. If the voting fails, Cardano falls back to plain Praos instead of halting, which is the main difference from BFT-style chains.
• It would not have stopped the November 2025 split, and in one scenario it could have made recovery harder. Faster finality cuts both ways.

At a glance:

• About 2 minutes: target settlement time under realistic parameters (CIP-140).
• 75%: share of the voting committee needed to certify a block.
• About 14 kB/s: extra bandwidth per node, roughly $3.80 a month on AWS.
• Q2 2027: estimated code completion, before governance and testing.

Why settlement matters

Cardano's current consensus protocol, Ouroboros Praos, gives probabilistic settlement. Each new block on top of yours makes a reversal less likely, but never impossible, and the confidence grows slowly. That is why exchanges wait for around 15 confirmations (roughly 10 minutes) before crediting a deposit, and why bridges and some applications wait much longer.

There is a hard ceiling. A Cardano node never rolls back more than 2,160 blocks (the consensus security parameter, k), so a transaction buried that deep is final. With a block every 20 seconds on average, that usually takes about 12 hours, and the protocol is built so those 2,160 blocks arrive within 129,600 slots: 36 hours. That is Praos's worst case for settlement, and the November 2025 chain split, at about 14.5 hours, stayed well inside it.

A note on names: this k is not the "k" in our posts on stake pool saturation. That one is stakePoolTargetNum, the protocol parameter that sets the target number of stake pools, and governance can change it. The security parameter is fixed in the chain's genesis. They share a letter and nothing else.

Peras is designed to shorten that wait sharply. In the words of the project site, it aims to "reduce transaction confirmation time from hours to minutes" while keeping "the security guarantees of Ouroboros Praos".

How Peras works

Peras is specified in CIP-140, written by researchers at Input Output and currently at the "Proposed" stage. The mechanism is simple to describe:

1. Rounds. Time is split into voting rounds. The CIP's example uses 90 slots, about a minute and a half.
2. A committee votes. Each round, a committee of stake pools is chosen in proportion to stake. Each member votes for a block a little way back from the tip of the chain it currently follows.
3. A quorum makes a certificate. If at least three quarters of the committee vote for the same block, the votes combine into a certificate (about 50 kB).
4. Certified blocks are heavier. A certificate adds a boost to that chain's weight, 15 blocks' worth in the CIP's example. Nodes then follow the heaviest chain rather than the longest.

Picture two competing chains after a fork. One is five blocks long and contains a certified block; the other is six blocks long with no certificate. Under Praos the longer chain wins. Under Peras the certified chain wins, because its weight is 5 plus a boost of 15, and a competing chain cannot easily make that up.

When voting fails: the cooldown

If a round misses quorum, because pools are offline, votes do not spread in time, or pools disagree about which block they are on, Peras enters a cooldown. Voting pauses and Cardano behaves exactly like Praos until the chain has settled down again. The reason is defensive: an attacker who just misses quorum must not be able to finish the job in a later round and force a deep reorganisation.

Who sits on the committee

It is not a fixed club of the largest pools, and it has nothing to do with the "k" target of 500 pools. Every registered pool with stake is eligible. CIP-140 describes a stake-weighted lottery modelled on Praos block production, with about 900 seats in its example sizing. The implementation team has since settled on a scheme called weighted Fait Accompli with local sortition, which splits the seats two ways:

• Persistent seats. The largest pools get a seat for the whole epoch, and each votes with weight equal to its stake.
• Lottery seats. Every other pool runs a private VRF draw each round, as it does for block leadership. The bigger the pool, the better the odds.

So a small pool will vote, just not every round, much as it mints blocks now and then rather than every few minutes. The design is still in development and the exact split may change before launch.

What it asks of stake pool operators

• About 14 kB/s of extra bandwidth for votes. The CIP estimates this at about $3.80 a month on AWS.
• About 20% more network traffic and storage overall, mostly certificates kept on disk.
• Negligible extra CPU.
• A registered BLS key for voting, the same kind of key Leios will use.

Peras does not change transaction fees, staking rewards, or how many transactions fit in a block. Throughput is the job of Leios.

Peras and Leios. Leios raises throughput: how many transactions the chain can carry. Peras shortens settlement: how soon you can treat one as final. They use similar stake-based voting, which is why both depend on SPOs registering BLS keys, and Leios is designed to be able to build on Peras.

Where it stands

• 2024: research phase complete: a prototype, formal proofs of the protocol's soundness, and conformance tests. CIP-140 published in August 2024.
• May to August 2026: Peras code integrated into the main consensus code and the Cardano node, with a dedicated Peras test network running.
• Late October 2026: the Peras protocol parameters were split out of CAP-12, the constitution amendment that defines the Dijkstra-era parameters, into an amendment of their own.
• Q4 2026: Dijkstra Phase 1 (protocol version 12) code complete: Linear Leios, nested transactions, and the groundwork Peras needs. Peras stays switched off.
• Q2 2027 (estimate): Peras code complete, activated later by an intra-era hard fork after testing on Preview and Pre-production.
• Then: DReps, SPOs and the Constitutional Committee must ratify the hard fork on-chain before it reaches mainnet.

Dates are Intersect's planning estimates and exclude governance and community testing time. Treat them as targets, not promises.

How it compares with other chains

CIP-140 compares the time exchanges wait before crediting a deposit:

Chain	Typical exchange wait	Settlement model
Bitcoin	~30 min	Probabilistic, deepens with each block
Ethereum	~14 min	Checkpoint finality by validator votes
Cardano today	~10 min	Probabilistic (Praos)
Tezos	~3 min	BFT-style finality
Algorand	~1 min	BFT-style finality
Cardano with Peras	~2 min	Praos plus committee certificates

Exchange figures as quoted in CIP-140. The Peras figure is the CIP's settlement target, not a measured result.

The more interesting comparison is what happens under stress. Chains built on classic Byzantine fault tolerance, such as Tendermint-based networks, finalise in seconds but stop producing blocks if more than a third of stake goes offline or disagrees. Peras makes the opposite trade: if voting fails, Cardano keeps producing blocks as Praos and simply loses the fast settlement until things recover. The Peras FAQ makes this point directly, arguing that Peras keeps Praos's structure and its ability to heal itself.

The trade has a cost. An attacker controlling around a quarter of the stake could keep triggering cooldowns and deny the speed benefit, though not the underlying safety.

The November 2025 chain split, and what Peras would change

What happened

On 21 November 2025 a malformed delegation transaction reached Cardano mainnet. It carried an oversized hash that slipped past a deserialisation bug dating back to 2022. Newer node versions, which most stake pools ran, accepted it. Older nodes and much of the surrounding infrastructure (Daedalus, DB-Sync, light wallets and explorers) rejected it.

The network split in two: a chain containing the bad transaction, nicknamed the "pig" chain, and the healthy chain, the "chicken" chain. Fixed node versions 10.5.2 and 10.5.3 shipped the same day. As stake pools upgraded, the healthy chain grew denser, and after about 14 hours it overtook the other. There was no manual rollback, Intersect reported no loss of user funds, and exchanges paused deposits and withdrawals as a precaution. A pool operator later took responsibility for the transaction.

The recovery worked because of the rule Praos already has: nodes follow the densest chain, so once enough stake moved to the healthy chain, the bad chain lost.

Would Peras have prevented it?

No. The split was a disagreement about which transactions are valid, caused by different node software. Peras changes how nodes choose between valid-looking chains. It does nothing about two groups of nodes applying different validity rules.

Would Peras have changed the recovery?

Fluid7 analysis. Neither the Intersect incident report nor the Peras documents analyse this scenario. What follows is our reading of the CIP-140 rules, not an official position.

• If neither side reached 75%: no certificates form, Peras enters cooldown, and the network behaves exactly as Praos did. The healthy chain wins as stake upgrades, as it did in 2025.
• If the bad chain held 75%: most pools ran the affected versions, so the committee could have kept certifying blocks on the bad chain, adding a large weight boost every round. The healthy chain could then not overtake it on density alone.

In the second case, recovery would likely have needed the disaster-recovery procedure from CIP-135, in which nodes deliberately cut their local chain back to before the fork, plus coordination across the community. That is slower and more manual than what happened in 2025.

The Peras FAQ already notes that the disaster-recovery and parameter CIPs will need revising before Peras goes live. The November split shows why that work matters. Faster finality makes good blocks final faster, and bad blocks too. The engineering, testing and node diversity that keep bad blocks out become more important, not less.

A new era: more than one node

In November 2025 every block producer ran the same Haskell node. The split came from versions of that one node disagreeing. That has already changed. Dingo, a node written in Go by Blink Labs, is minting mainnet blocks: Star Forge OTG minted the first Dingo block, acknowledged by Blink Labs, and was producing with it by mid-October 2026. Gimbal Pool became the second pool to do so on 27 October. Amaru, written in Rust, was cleared for mainnet block production on 5 November. The network now runs several versions of several nodes from different teams.

Fluid7 analysis. Our reading, not an official position.

• Splits get more likely. Every independent implementation of the ledger rules is another place where two nodes can disagree about whether a transaction is valid. More versions times more vendors means more combinations to keep in step.
• Bad chains get less likely to win. A chain with a bad block only wins if the nodes that accept it hold most of the stake under Praos, or three quarters of it to keep certifying under Peras. When no single implementation holds that much, a bug in one leaves its pools on a minority branch that falls behind. Those operators fix their node and resync. The rest of the network carries on, with no network-wide rollback.
• The catch is shared code. The 2025 bug sat in an underlying software library. If several nodes share a library, they share its bugs, and diversity only helps where the code really is independent.

On balance: more frequent, smaller incidents, and fewer of the large kind that need manual recovery, as long as no one node holds a majority of stake. For Peras that matters twice over. Keeping every implementation below three quarters of stake means a bug in one can never certify its own chain.

What this means for you

• Delegators: Peras does not change rewards or how you delegate, and you may see exchanges and bridges credit deposits faster once it is live. But your stake now does one more job. Under Peras it weighs in on which blocks get certified, so it matters which node software your pool runs. If too much stake sits behind one implementation, a single bug can certify a bad chain. If no node holds three quarters, it cannot. It is worth asking your pool which node it runs, and counting that as part of your choice. Your stake is a vote, not a yield makes the wider case.
• Builders: near-final settlement in about two minutes opens up payment and cross-chain use cases that are awkward today. Services such as Blockfrost are expected to report whether a transaction sits behind a certified block.
• Stake pool operators: plan for BLS key registration (needed for Leios too), a small rise in bandwidth and storage, and votes on two hard forks. Keeping nodes up to date matters more when a majority on the wrong software can certify a bad chain.
• DReps: Peras will come to you as a hard fork action and a separate parameters amendment. Both are worth reading when they land.

Sources

1. CIP-140: Ouroboros Peras, Cardano Foundation CIPs repository
2. Ouroboros Peras project site and FAQ, Input Output
3. Dijkstra hard fork planning, Intersect
4. Intersect weekly update #134, 24 October 2026
5. Dijkstra roadmap details hard fork windows, cardano.org, September 2026
6. Ouroboros Peras weekly update, Essential Cardano, 21 August 2026
7. Incident report: network partition analysis and resolution strategy, Intersect
8. November 2025 Incident: Cardano Shows Its Resilience, cardano.org
9. Cardano temporarily splits into two chains, CoinDesk, 23 November 2025
10. Cardano mainnet incident: facts at a glance, Intersect
11. Chain selection, Cardano Blueprint (the 3k/f window)
12. Weighted Fait Accompli committee selection, Ouroboros consensus code, and the Fait Accompli paper
13. Cardano Amaru node cleared for mainnet block production, CryptoTicker, November 2026
14. Star Forge OTG mints the first block with Dingo, Blink Labs on X, October 2026
15. Gimbal Pool mints with Dingo, Gimbalabs on X, 27 October 2026

This article explains protocol proposals that are still subject to testing and on-chain governance. It is not financial advice.