Tweag’s proposals for 2026–2028 build on the work delivered in 2025, focusing on bringing Peras to mainnet, scaling the network’s observability and reliability infrastructure, and strengthening the testing foundations that underpin the Cardano ecosystem.

In 2025, we established the foundations: advancing Peras towards private testnet deployment, developing the hoarding node, introducing conformance testing, and developing and implementing a canonical ledger state format and delivering the Genesis Sync Accelerator.

The next phase is about taking that work into production, ensuring it scales with the network, and making it usable and integrated across the ecosystem.

Tweag’s proposals

The main purpose of our proposal is bringing fast finality (Peras) safely to mainnet. All other work exists to ensure that this upgrade is safe, observable, and adoptable. Our proposal consists of the 9 projects, and split into more fine-grained measurable work packages. Tweag’s proposal spans multiple work packages across core Cardano priorities:

• Peras: from testnet to mainnet
• Network reliability and observability
• Correctness and testing infrastructure
• Ecosystem integration
• Maintenance

Ouroboros Peras

Ouroboros Peras remains a central focus for this cycle. It is designed to vastly reduce transaction settlement time from around 12 minutes to 2–5 minutes under normal conditions, improving usability for DApps, L2 solutions, and partner chains that depend on timely L1 confirmation.

Following the 2025 work, where Peras was implemented on a testnet, the next step is completing the transition to mainnet. This includes introducing production-grade cryptographic primitives, enabling secure node bootstrapping through historical certificates, and adding operational safeguards such as a KillSwitch mechanism. In addition, Peras parameters will be exposed on-chain to allow governance control.

The outcome of this work will be a hard fork candidate implementation, supported by pre-production deployment, SPO documentation, and governance action packages to support community adoption.

Beyond the initial release, we will continue improving Peras through a second phase focused on resilience and performance. This includes reducing the likelihood of failed voting rounds, improving recovery when they occur, and applying data-driven optimisations informed by mainnet data as it becomes available, while foundational v2 work begins immediately in parallel with v1 finalisation.

Network reliability and observability

As transaction throughput increases and new protocol features Peras and Leios are introduced, the operational demands on the network grow significantly. This leads to higher infrastructure costs, and increased operational risk. To address those challenges. History Expiry introduces support for partial-history nodes, reducing storage requirements as transaction throughput increases. The project sits on top of the Genesys Sync Accelerator project delivered in 2025. In parallel, a mempool bridging tool will ensure that transactions are preserved during fork incidents, preventing loss when chains temporarily diverge.

But those solutions do not cover all the observability demands. Building on the hoarding node developed in 2025, this cycle extends it into a continuously running, production-grade observability system.

The Hoarding Node will be deployed against pre-production and mainnet networks, collecting blocks, headers, and peer data over extended periods. From there, the system evolves into a distributed model, introducing collectors across multiple regions to provide visibility into how data propagates globally.

Further enhancements include embedding consensus validation directly into the node, enabling it to detect invalid blocks and attribute them to specific peers, as well as introducing transaction collection capabilities to observe mempool activity before inclusion in blocks.

Correctness and testing infrastructure

A significant portion of this work is focused on improving confidence in the correctness of the system.

Conformance testing of Consensus will be extended to cover both Peras and Leios, allowing implementations to be validated against shared protocol guarantees under realistic and adversarial conditions. We will also expand our ability to simulate complex attack scenarios by generating adversarial forks that branch from other adversarial forks.

We will also revisit block cost modelling using real mainnet data, building regression tests to detect performance regressions and potential denial-of-service vectors, and integrating anomaly detection into the observability layer.

Ecosystem integration

This cycle also focuses on ensuring that the work delivered is usable across the ecosystem.

The canonical ledger state format defined in the previous cycle will be integrated with Mithril, enabling stable, versioned snapshots that can be shared across different node implementations. This supports alternative nodes in bootstrapping from a consistent and reliable state.

In parallel, the Plutus Script Re-Executor will be extended into a more complete developer tool. By enabling off-chain re-execution of scripts with the same context as on-chain execution, it supports debugging, analysis, and development workflows.

Planned improvements include a web interface, enhanced tracing capabilities, and more flexible execution options. The hoarding node is also being made available for external operators, providing shared visibility into live network behaviour across the ecosystem.

Maintenance

Ongoing maintenance remains a core part of the proposal.

This includes continued support for the Genesis sync accelerator and associated infrastructure, ensuring compatibility with evolving Cardano node versions and maintaining reliability over time.

We will also continue maintaining the Cardano node emulator, aligning it with current protocol developments and improving its usefulness for smart contract developers. This includes updating dependencies, addressing technical debt, and engaging with the developer community to ensure it remains a practical and relevant tool. Closing

Together, these proposals are focused on ensuring that the work delivered in 2025 reaches (and positively impacts) the network, scales with it, and is usable in practice.

They represent a shift from foundational work to delivery and integration: bringing Peras to mainnet, strengthening the infrastructure around it, and ensuring the system remains reliable, testable, and ready for continued growth.

FAQ

Why is this a single bundle rather than individual proposals?

We want to be transparent about where we stand and why we are bringing this forward now.

The shortfall of approximately $3.5M is not the result of mismanagement or undelivered work, it is a direct consequence of ADA’s market movement between our treasury award and the point Intersect needed to convert to fiat. That gap is already being absorbed by us. We have self-financed critical work since November 2025 to keep the most important roadmap deliveries on schedule.

The proposal we are putting forward covers the full scope needed to complete what we committed to work that is directly aligned to the Cardano roadmap milestones already publicly tracked. We are not proposing to split it into phases, because doing so would introduce delivery risk over the 18 months ahead and undermine the continuity this work requires.

We have been building in this ecosystem since 2018. The delivery record is public. We are asking the community to look at what has been built and decide whether it is worth completing.

Why two years? Why not deliver faster?

Peras requires a Hard Fork (HF) event to reach mainnet, and HF events happen on a fixed cadence. If the work is completed too early it sits idle waiting for the next window. The two-year plan phases delivery so Peras v1 lands at the right HF moment, and Peras v2 work begins immediately in parallel. The duration reflects the HF cycle, not padding.

What exactly is Tweag’s track record? Have they delivered before?

Tweag has been engaged with IOG on Cardano core infrastructure since January 2018. They led the consensus and ledger teams, implemented the Ouroboros Genesis protocol, and contributed to the design of Ouroboros Peras.

What is the ₳39.8M actually paying for?

The total breaks down to approximately $**9.96M** USD over two years, based on a conservative$0.25/ADA weighted average rate calculated over five years. Each work package has an FTE estimate and cost breakdown in the full proposal document. The largest single items are Peras v1 (₳4.95M including CBU research support), Peras v2 (₳8.24M including CBU research support), and the Plutus Script Re-Executor (₳4.36M).

What happens if ADA price rises significantly?

What happens if ADA price falls?

As in 2025, Tweag will make every effort to finish and bring the projects to mainnet and support the work it provides.

What does success actually look like for Peras? How will we know it worked?

For Peras as well as for other projects we have clearly written measurable success criteria that will be checked.

To be precise with Peras we expect to measure if settlement will be improved to the level comparable with the theoretical improvements expected by the Research Papers.

What is the Hoarding Node and why does it need four separate work packages?

Hoarding node is an observability tool that allows to monitor the network and find anomalies or adversarial behavior, as on the main chain as well as on the branches. The project is split into 4 distinct work packages, because each package has it’s own value for the Cardano network as well as success criteria. Instead of making it a single package, with milestone per paсkage and all metrics mixed, we have decided to note that explicitly for the greater visibility.

Why is Tweag maintaining the Cardano node emulator? Shouldn’t IOG handle that?

The Cardano node emulator (CNE) was left without active maintenance. It’s a critical tool for smart contract developers, it allows testing Plutus contracts without running a full node. Tweag picked up maintenance in 2025 and is proposing to continue because no other party has stepped up. The proposal is transparent that this is maintenance work, not new feature development.

What is the relationship between this proposal and IOG’s ongoing work?

The proposal commits to continuous vetting against IOG’s ongoing work and other ecosystem contributors. Tweag maintains dedicated internal communication channels and a program-level Slack for cross-team coordination. Several work packages, including conformance testing, canonical ledger state, and history expiry, require direct collaboration with IOG teams and Mithril. Tweag’s role is to deliver work that integrates with and complements rather than duplicates IOG’s efforts.

How will the community stay informed throughout delivery?

Weekly project updates and public demos at minimum every two months are published at tweag.github.io/cardano-website. A dedicated Discord channel is maintained for all projects.

For work requiring interaction with core teams, advance design discussions and integration alignment are built into the delivery process. Intersect serves as auditor of record, verifying that deliverables align with commitments.

What happens if a work package doesn’t deliver?

Tweag is requesting milestone based fixed price contracts with Intersect as administrator. Funds are released against milestones, not upfront. Each milestone has defined deliverables and explicit acceptance criteria. If a milestone is not met, the next payment is not triggered.

How does this align with the Cardano 2030 Vision?

All of the projects correlate with core KPI and vision of the projects. Each package have Expected Value section that explains the relationship in details. You can find a short version here here.

What’s the contingency if Peras v1 is delayed past its Hard Fork window?

While we are trying to address make this situtation not happen by working on this proactively. But in a case of this happending the actions do not depend on Tweag solely.

This question will require wider community agreement on the strategy wether to wait for the next window or to delay the HF. From our side we work on making most to ensure safe and prompt code delivery.

Has the community been tracking your 2025 delivery, and where can they see proof?

Yes, across several channels:

• Intersect milestone reporting: We submit Milestone Acceptance Forms (MAFs) for every completed milestone as part of our Intersect contract. These are reviewed and signed off before the next payment is triggered. Delivery is verified, not self-reported.
• Project website: Status updates for every active work package are published at tweag.github.io/cardano-website throughout the cycle.
• GitHub: All code is open source. Commit history and merged pull requests provide a timestamped record of what was built and when.
• Demos: Public demos at least every two months, recorded and archived on the project website.
• X: Progress updates and milestone completions shared publicly.

Do you have a full team or do you need to hire additional developers?

Tweag have a team that is ready to deliver all the projects, so no additional hires required.

Though may want to make additional hires for speeding projects up in case if it makes sense from the delivery perspectives.

What happens if the vote does not pass?

The situation with ADA price drop in 2025 has hit the company, at this point we continued development of the projects from our own budget. But it can’t continue indefinitely, in case if vote didn’t not pass Tweag will not be able to support delivery of the projects outside of the 2025 proposals scope.

See more elaborated statement

I am not a technical person, this is too complicated for me to understand, Can you boil it down for me? Why is Cardano worse if we do not fund you?

Right now Cardano takes about 12 minutes to confirm a transaction is final. Peras brings that down to 2-5 minutes. That matters for anyone building apps, running DeFi protocols, or using Cardano in the real world. Without this funding, Peras does not reach mainnet.

Beyond Peras, as Cardano processes more transactions, running a node gets more expensive. History Expiry keeps that cost manageable for stake pool operators. Without it, fewer people can afford to run nodes, which weakens decentralisation.

The hoarding node is the network’s early warning system. It watches for attacks and unusual behaviour that normal nodes miss. Without it, the community has less visibility into what is happening on the network.

The testing and tooling work is less visible but just as important. It is what catches bugs before they become incidents. The June 2024 network disruption is an example of what can happen when worst-case scenarios are not tested properly.

Tweag has been doing this work since 2018. This proposal is the continuation of that, focused on getting everything across the line to mainnet rather than back to the drawing board with a new team.

How does this go with the IOG proposals? Is it competing with them? Or something completely different?

Tweag and IOG work on separate, but complementary scopes. Leios and Peras go hand in hand. Several of our packages require direct collaboration with IOG teams and we coordinate closely to avoid duplication. One team can’t deliver everything, and this is consciously parallel effort to build faster.

Not competing. Building together.