May 26, 2025

Intersect Proposals 2025

Tweag proposals for Intersect funding submitted on chain

Summary

Tweag’s proposals for multiple core budget projects for Cardano 2025 has been included in the onchain governance action aiming to unlock 275M ADA for blockchain maintenance and development through to June 2026.

In the first part of this article we’ll go through the work that Tweag has proposed. Part 2 to follow will talk about the next steps planned, and how we intend to continue to engage with the community as this work develops.

Tweag’s proposals

Tweag’s singular proposal encompasses multiple projects across core Cardano and community prioritised themes:

Peras
Supporting Multiple Node Implementations
Improving the development experience
Scaling the L1 engine
Maintaining Network Integrity

Ouroboros Peras

Ouroboros Peras is an extension to the Ouroboros family of protocols that provides faster post-facto settlement under optimistic conditions. As per Intersect’s identified community priorities, Peras is one of the key themes for this upcoming year.

In early 2025, Tweag put together a detailed plan for the implementation of Peras in the current Cardano node. We also identified some key questions for the community to answer and presented them in our Peras AMA

For the 2025 budget, we are proposing to go ahead with implementing Peras to the extent that it can be spun up into a testnet. This will allow people to explore the benefits that Peras provides, allow us to empirically measure its overhead, and perhaps most importantly allow the community to explore the Peras parameter space and understand what it means for their applications.

Supporting alternative node implementations

In April Tweag hosted a workshop in Paris on the development of alternative node implementations. This drew together some of the developers of the Haskell node, Amaru, gouroboros/dingo and the typescript node.

A key outcome of this workshop was the need for a number of items which are currently internal details to the Haskell node to become external and mutually controlled artefacts. Further, that we should exploit the work that has gone in to making the current Haskell node rock-solid to support testing and validation of alternative node implementations.

To that end, Tweag has proposed a number of items aligned with making it easier to develop and verify alternative nodes through making use of work already done in the Haskell node.

Canonical Ledger State

The current Cardano ledger state is defined internally to the cardano-ledger Haskell project. While the ledger specification sets out precisely how the state is updated in response to block and transaction payloads, the serialised format is only specified by its implementation and acts only as a dump of the in-memory representation. The ledger team is free to update this format to meet the needs of the ledger - for example, altering the representation of certain types in order to make lookups faster.

Alternate node implementations are currently intending to bootstrap through Mithril snapshots, rather than syncing from Genesis. To do this, we need to have a snapshot format that is guaranteed to stay stable even as the internal ledger formats evolve, and which can be shared between different implementations.

Since we proposed this work, some others have already started thinking about these ideas - for example, at this CIP and this hackMD document. We intend to build on this work and take on the pieces that others haven’t looked at, as well as building the support for this format into the existing Cardano node.

Black box ledger testing

Building on the canonical ledger state, we want to use the existing ledger implementation and tests to provide a test harness for alternative implementations. This would take the form of a repository containing test cases, where each test case consists of:

An initial state snapshot
A sequence of transactions or blocks
A final state snapshot

In addition, we would provide a tool to perform intelligent diffing of the state snapshot and provide guidance as to which parts have changed and how.

Going further on this, we intend to add tools to the existing ledger codebase to support generation of new test cases from the existing ledger testing.

Black box consensus testing

In a similar vein to testing the ledger, we also want to test that alternate nodes correctly implement the consensus algorithms that allow the network to collectively select the best chain.

While these are in some ways simpler than the ledger, in the sense that the consensus decision rule is much simpler than the ledger update rule. However, the inputs are much more complex: with multiple processes talking to each other over multiple channels, concerns about mutable state and concurrency abound.

During the course of implementing Ouroboros Genesis, we designed an approach to node testing which we now call “Node vs Environment”. It gives us a relatively declarative way to test the correctness of a consensus implementation. While this is currently specialised to syncing nodes and implemented inside the Haskell node, its declarative nature renders it suitable to be extracted and therefore used by alternate nodes.

Improving the Development Experience

Plutus Script Re-Executor

This project aims to provide DApp developers with a powerful tool for monitoring and analyzing the execution of their Plutus scripts on-chain. By enabling off-chain re-execution of scripts with the same context and arguments as used on-chain, developers can gain deeper insights into script behavior, debug issues, and maintain off-chain state more efficiently.

The tool will allow for enriched tracing and analysis without incurring additional on-chain costs, supporting both current and future needs of the developer community. Key deliverables include the re-executor tool itself, integration with the Cardano node, and a robust event system for tracking script executions and rollbacks, all designed to minimize redundant resource usage and streamline the developer experience.

Maintaining Cardano-node-emulator

The Cardano-node-emulator (CNE) is essential for simulating Cardano node behavior without the need to run a full node, primarily benefiting the testing and validation of Plutus-based smart contracts. Unfortunately, the CNE was marooned during the transition to Intersect, and has no active maintenance plan.

This maintenance proposal focuses on updating CNE to stay in sync with the latest Cardano node releases, addressing technical debt, and responding to user feature requests. The work includes updating dependencies, improving typed validator support, and ensuring compatibility with evolving Cardano standards such as CIP69. Ongoing efforts will also enhance project governance, stakeholder engagement, and documentation, ensuring CNE remains a reliable tool for the Cardano developer ecosystem.

Scaling the L1 Engine

Block Cost Investigation

This initiative addresses the need to reassess the worst-case block validation costs on Cardano, especially in light of increased transaction complexity and recent network events. The project will develop both empirical and theoretical cost models, analyze mainnet data, and design regression test methodologies to detect performance regressions and potential denial-of-service vectors before they impact the network. Deliverables include detailed reports on cost modeling, anomaly detectors for mainnet, and regression suites for continuous integration, providing a foundation for future protocol tuning and network resilience.

History Expiry

As Cardano’s chain history grows, syncing new nodes and maintaining full historical data becomes increasingly burdensome. The History Expiry project proposes protocol and node changes to enable nodes to operate without retaining or serving the entire historical chain, significantly reducing sync times, storage, and network costs. The work will introduce explicit support for “pre-historic” chains in network protocols, allow nodes to start from recent snapshots, and design incentives for dedicated archival nodes. This approach will lower the barrier for new node implementations and support the network’s scalability as transaction volumes increase.

Genesis Sync Accelerator

To further accelerate node synchronization, this project introduces a Genesis Sync Accelerator that allows nodes to fetch the historical chain from content delivery networks (CDNs) in a secure, trust-minimized way. By offloading historical data retrieval from stake pool relays to CDNs and validating data integrity through the Ouroboros Genesis protocol, the solution reduces relay load and improves sync speeds, especially for geographically distant nodes.

Maintaining Network Integrity

Hoarding Node

The Hoarding Node project addresses the need for comprehensive monitoring and forensic capabilities within the Cardano network. Unlike standard nodes, the hoarding node will store all observed blocks and transactions—including those not included in the final chain—enabling detailed investigation of adversarial behavior, network anomalies, and discrepancies between node implementations. The system will provide APIs for data access and analysis, support detection of unusual or malicious activity, and facilitate research into network dynamics. This capability is crucial for rapid response to incidents and for maintaining the security and integrity of the Cardano ecosystem[^3].

Canonical Block and Transaction Diffusion Codecs

This project aims to simplify and future-proof the Cardano node’s data formats by removing legacy implementation details such as Epoch Boundary Blocks (EBBs) and replacing ledger era tags with explicit protocol versions in block and transaction codecs. These changes will reduce confusion for developers, streamline interoperability for alternative node implementations, and set a precedent for future schema migrations.

These projects, collectively, represent Tweag’s commitment to advancing Cardano’s core infrastructure, improving developer and user experiences, and ensuring the network’s scalability, security, and resilience through 2025 and beyond. In part 2 of this article, we’ll talk about how we plan to deliver on them!