Ouroboros Peras

Implementation Progress Update and Discussion

February 23, 2026

Agenda

2

1. Dashboard updates
2. Implementation updates
3. Updated roadmap and PR choreography
4. Discussion

​

Disclaimer

3

• Ouroboros Peras is a protocol that enables significantly faster settlement times under optimistic conditions

​

• At a fixed schedule, all pools vote for a recent block.
• If sufficiently many pools vote for the same block, this block receives a boost, making it unlikely to be rolled back
• Otherwise, the system enters a cooldown period, during which no voting takes place.

​

• More resources: https://github.com/tweag/cardano-peras#resources-on-peras�
• In these slides, “Peras” refers to the pre-alpha and caught-up version of the protocol.

See here for more information:

https://github.com/tweag/cardano-peras/blob/main/docs/pre-alpha.md

​

• Past demos (recordings, slides, etc.): https://github.com/tweag/cardano-peras/blob/main/demo/README.md�Moved to: https://tweag.github.io/cardano-website/

​

​

​

​

​

​

​

Dashboard updates ( public URL )

4

​

• New metrics on the Peras parameterization dashboard:
• Upper bound for extra bandwidth
• Upper bound for extra CPU time
• These metrics are parameterized by the size, generation time, and verification time of votes and certificates (those are unknown until the crypto schemes are known)
• Notable takeaway: naive Peras implementation could add up to 70% extra CPU time
• Some pessimistic assumptions are made:
• All available votes are downloaded from every peer on each round
• Vote verification happens before deduplication
• Future work on the implementation will improve Peras worst-case performances
• Peras Settlement metric didn’t make it to the dashboard

​

​

​

Implementation updates

5

• PerasVoteDB ✅
• Settled on an in-memory implementation
• Reworked API to work within STM as much as possible
• Keeping track of latest certificate stored on (our preferred) chain 🕵️
• Needed to evaluate the Peras voting rules (to coordinate the end of a cooldown period)
• The certificate can appear anywhere on the chain (both volatile and immutable parts)
• An initial implementation extends the Shelley Ledger state with a cached value
• The value is potentially updated when applying new blocks to the Ledger
• Model implementation for the committee selection scheme (wFA^LS) 🕵️
• QuickCheck properties to validate the deterministic part of the algorithm
• Will serve as the basis for the real implementation (conformance test oracle)
• Continued with the HFC plumbing efforts 🚧
• Most of the complexity comes from the need for handling votes and certificates created across (potentially) different eras

​

​

Updated roadmap (link)

6

PR choreography

• Global effort restructuring PRs to avoid the #5202 blocker�
• Most work can now target main�
• Next steps:
• Finish the HFC plumbing
• Voting orchestration thread
• Initialize vote and certificate pools
• Decide when to vote (w.r.t committee selection scheme and voting rules)
• Decide when to include certificates in blocks

​

​

​

​

7

THANK YOU!