# Triage

Items on the triage have been reviewed by the CIR-WG and accepted to develop further through the [process flow](https://productcommittee.docs.intersectmbo.org/working-group/core-infrastructure-roadmap-working-group/process-flow). Items in this list may require further input and/or wider discussion at TWG or SIGs as appropriate. From time to time the items on this list will be re-assessed to align with the evolving product direction.

## OBL-1. Ouroboros Leios

Ouroboros Leios is a novel protocol extending Ouroboros Praos that aims at dramatically increasing the throughput of Cardano network. Leios is based on the key idea of input endorsers. Whereas in a classical blockchain, the blocks' body directly contains transactions, in Leios the blocks' body can also contain references to Endorser blocks which themselves contain references to so-called Input blocks containing the actual transactions. Those references are certified through a voting mechanism that guarantees a majority of validators agree on the content of Endorser blocks. By decoupling the logic of validating blocks' payload and extending the blockchain, and limiting the work needed to verify the chain, much higher throughput can be achieved and new use cases can be unlocked.

Simulating Leios is a critical precursor to subsequently implementing it because Leios aims to make full use of network bandwidth in a heterogeneous environment where input blocks, endorser blocks, votes, certificates are diffused in addition to the ordinary Ouroboros Praos traffic. Simulation will provide detailed statistics on Leios performance under normal conditions, during congestion, and in the face of adversarial activity. Formal methods are required to verify that the network simulations are faithful to the Leios protocol.

<table data-header-hidden><thead><tr><th width="257"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. </td></tr><tr><td>Drivers</td><td>Scalability</td></tr><tr><td>Documentation</td><td>Research paper<a href="https://iohk.io/en/research/library/papers/high-throughput-blockchain-consensus-under-realistic-network-assumptions/"> High-Throughput Blockchain Consensus under Realistic Network Assumptions</a> and repository<a href="https://github.com/input-output-hk/ouroboros-leios"> github:/input-output-hk/ouroboros-leios</a> and web site<a href="https://leios.cardano-scaling.org/"> https://leios.cardano-scaling.org/</a> Youtube explainer:<a href="https://www.youtube.com/watch?v=Czmg9WmSCcI"> Scaling Blockchain Protocols</a></td></tr><tr><td>Target State</td><td>Prototyping Simulations, Formal specs</td></tr><tr><td>Definition of Done</td><td>Publish simulations, their source code, visualizations, and specifications for community and stakeholder use</td></tr><tr><td>Product Stage</td><td>Currently at SRL2 (Target to get to SRL5)</td></tr><tr><td>Functional Requirements</td><td>Implement multi-node simulations that are formally verified to be faithful to the Leios protocol; develop analysis and visualization tools to quantify Leios behavior and performance.</td></tr><tr><td>Non-functional Requirements</td><td>Simulations can be used interactively by the stakeholder community to study Leios.</td></tr><tr><td>External Dependencies</td><td>TBC</td></tr><tr><td>Communication Channel</td><td>Website, Github repository, Discord channel, video</td></tr><tr><td>Indicative Sizing</td><td>2L</td></tr><tr><td>Context of Indicative Sizing</td><td>Six months of 5 FTEs (1x Architect, 1x Formal Methods Engineer, 2x prototyping engineers, 0.5x Researcher, 0.5x Product Owner)</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>TBC</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>Not for this proof of concept</td></tr><tr><td>Security Review</td><td>N/A</td></tr><tr><td>Code Audit</td><td>N/A</td></tr><tr><td>Community Endorsement</td><td>Yes</td></tr><tr><td>Feasibility Study Required?</td><td>Yes</td></tr><tr><td>Reviewing Working Group</td><td>Consensus, Networking</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>Yes</td></tr><tr><td>Item Champion</td><td>IOR</td></tr><tr><td>Talking Points (Optional)</td><td><p>- Prerequisite to implementing Leios</p><p>- Builds engineering and business cases for Leios</p><p>- Lays groundwork for detailed formal specification of Leios in a (revised) CIP</p></td></tr></tbody></table>

## OBP-1. Ouroboros Peras

Ouroboros Peras modifies the chain-selection rule to include the "boosting" of the dominant chain's blocks by a quorum of votes from periodic randomly-selected voting committees. It reduces the settlement time by orders of magnitude without weakening the existing security guarantees. It is compatible with and orthogonal to Leios and Genesis, and it only has a very minor impact on the resource consumption of block-producing nodes. It requires modification of the chain-selection rule, a small change the the CDDL of the block body, and the creation, transport, and verification of votes and the certificates that witness a quorum of votes. It adds several new protocol parameters.

Peras has synergies with Leios and other proposals that involve voting, certificates, or transport/storage of additional data beyond what Praos and Genesis already handle. The Peras task involves (a) implementing this protocol in the Haskell-based Cardano node, (b) providing node-oriented conformance tests (which are distinct from the already existing protocol-level conformance tests) so that non-Haskell nodes (in Rust, Go, etc.) can be verified, and (c) updating the relevant node documentation and specifications.

One of the key benefits is Peras will dramatically shorten the "settlement" or "finality" time for transactions, providing near-certainty within a couple of minutes regarding whether a block will forever remain on the main chain.

<table data-header-hidden><thead><tr><th width="248"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. </td></tr><tr><td>Drivers</td><td>Adoption</td></tr><tr><td>Documentation</td><td><a href="https://peras-staging.cardano-scaling.org/">https://peras-staging.cardano-scaling.org</a> (soon to become<a href="https://peras.cardano-scaling.org/"> https://peras.cardano-scaling.org/</a>),<a href="https://github.com/input-output-hk/peras-design"> https://github.com/input-output-hk/peras-design</a>, and draft CIP to be submitted early August</td></tr><tr><td>Target State</td><td>Production</td></tr><tr><td>Definition of Done</td><td>Implementation + audit + testnet + hard fork</td></tr><tr><td>Product Stage</td><td>Currently at SRL 4 (prototyping, specification, formalization, and conformance testing already completed)</td></tr><tr><td>Service Level</td><td>BRL 2</td></tr><tr><td>Functional Requirements</td><td>Implement Peras protocol (described in CIP and research paper) in the Haskell-based Cardano node.</td></tr><tr><td>Non-functional Requirements</td><td>Implement a comprehensive, node-level conformance test suite usable by nodes written in any programming language; update node specifications and CDDL; benchmark node network usage to ensure that it increased by less than 20% due to Peras vote and certificate transport.</td></tr><tr><td>External Dependencies</td><td>Coordination and architectural coherence with work on other node developments such as Genesis, Leios, and Mithril.</td></tr><tr><td>Communication Channel</td><td>Web site, Discord channel, YouTube video, GitHub repository, blog posts</td></tr><tr><td>Indicative Sizing</td><td>2L</td></tr><tr><td>Context of Indicative Sizing</td><td>The development, testing, and documentation effort is approximately two person-years. (This estimate does not include ancillary activities like testnet operation.) However, there may be synergies with other items such as Leios, and leveraging those could reduce the combined level of effort.</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>TBC</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>Yes</td></tr><tr><td>Security Review</td><td>Yes</td></tr><tr><td>Code Audit</td><td>Yes</td></tr><tr><td>Community Endorsement</td><td>Yes</td></tr><tr><td>Feasibility Study Required?</td><td>No</td></tr><tr><td>Reviewing Working Group</td><td>Consensus</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>Yes</td></tr><tr><td>Item Champion</td><td>IOR</td></tr><tr><td>Talking Points (Optional)</td><td><p>- High benefit (fast settlement) at low develoment cost and without compromises to security</p><p>- Synergies with Leios, Mithril, and Genesis</p><p>- Enables fast interoperability with partner chains and bridges</p></td></tr></tbody></table>

## BAB-1. Marketplace application for Babel fees

For the purpose of allowing atomic swaps, DApp fee sponsorship, fee coverage, etc., a proposal is raised for ledger changes that (1) add new fields to Tx which allow a top-level tx to contain sub-txs (2) allow individual sub-txs to be unbalanced, and not provide their own collateral inputs or witnesses, but the full batch (top level+sub-txs) must be fully valid, i.e. is balanced, has collateral, etc. (3) showcase how this approach can be extended to other types of intent processing

There are multiple key benefits to this implementation, including (1) transactions can be unbalanced, which allows for performing implicit trades within batches (including covering each others' collateral, fees, minUTxO) (2) scripts can inspect other transactions in the same batch (3) allows deduplication of script and datum data across multiple transactions in one batch and (4) possibility of extension to other intents

<table data-header-hidden><thead><tr><th width="253"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. </td></tr><tr><td>Drivers</td><td>Adoption/Traffic Management</td></tr><tr><td>Documentation</td><td><a href="https://iohk.io/en/blog/posts/2021/02/25/babel-fees/">https://iohk.io/en/blog/posts/2021/02/25/babel-fees/</a> ;<a href="https://github.com/cardano-foundation/CIPs/pull/862"> https://github.com/cardano-foundation/CIPs/pull/862</a> CIP has been created, with lots of community input in progress.</td></tr><tr><td>Target State</td><td>Production</td></tr><tr><td>Definition of Done</td><td>Done within Innovation = prototype built on ledger codebase + CIP, prototype build on Agda codebase (specification); done in production = implemented within a new era in the node + documentation</td></tr><tr><td>Product Stage</td><td>Prototype - with Test cases (though changes have been made since), specification</td></tr><tr><td>Service Level</td><td>SRL4; BRL1</td></tr><tr><td>Functional Requirements</td><td>new era defined for the node (including ledger, CLI, consensus, etc.), new Plutus version</td></tr><tr><td>Non-functional Requirements</td><td>documentation, conformance testing, unit testing, benchmarking</td></tr><tr><td>External Dependencies</td><td>Plutus, Dependency for adoption = community development of off-chain infrastructure for Babel fees service</td></tr><tr><td>Communication Channel</td><td>CIP-0118</td></tr><tr><td>Indicative Sizing</td><td>M</td></tr><tr><td>Context of Indicative Sizing</td><td>TBC</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>TBC</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>Yes</td></tr><tr><td>Security Review</td><td>Yes</td></tr><tr><td>Code Audit</td><td>Yes</td></tr><tr><td>Community Endorsement</td><td>Yes</td></tr><tr><td>Feasibility Study Required?</td><td>No</td></tr><tr><td>Reviewing Working Group</td><td>Ledger</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>Yes</td></tr><tr><td>Item Champion</td><td>IO Innovation</td></tr></tbody></table>

## HYD-1. Hydra Development

{% hint style="info" %}
There are various scopes that can be potentially developed for this item. Please follow this page and the Hydra working group for future updates to this item.
{% endhint %}

Interconnecting Hydra heads approaching the full heterogenous vision on scaling solutions for Cardano. By building a lightning-like system for processing payments off-chain at near zero cost and instant finality, we will enable several payment use cases and pave the way for generalized interconnection of Hydra heads isomorphic script execution across off-chain ledgers using Interhead Hydra.

The key benefits are (1) Payments of any fungible Cardano native asset unimpacted by L1 congestion (2) Re-usable payment channels for B2B, B2C and C2C micro-payments (3) Interoperability with Bitcoin Lightning (4) Near-zero cost, instant finality, and full security Cardano transactions processing for small groups of validators (Head protocol)

<table data-header-hidden><thead><tr><th width="248"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>This item is pending community input to progress. Cardano members are encouraged to join the product SIGs to discuss development direction and user needs. </td></tr><tr><td>Drivers</td><td>There is no decentralized future if it is not scalable enough.</td></tr><tr><td>Documentation</td><td><a href="https://hydra.family/">https://hydra.family</a>, constellation diagram</td></tr><tr><td>Target State</td><td>TBC</td></tr><tr><td>Definition of Done</td><td>TBC</td></tr><tr><td>Product Stage</td><td>Production</td></tr><tr><td>Service Level</td><td>SRL8</td></tr><tr><td>Functional Requirements</td><td><p>- P2P Hydra node networking (also browser)</p><p>- HTLC and Adaptor signature swaps</p><p>- Keep ADA staked in Heads, Pledge usable as collateral</p><p>- Payment invoices and routing</p><p>- ...</p></td></tr><tr><td>Non-functional Requirements</td><td>TBC</td></tr><tr><td>External Dependencies</td><td>TBC</td></tr><tr><td>Communication Channel</td><td><a href="https://hydra.family/">Website</a>,<a href="https://github.com/cardano-scaling/wg-hydra"> Working group</a>, Discord channels, YouTube video, GitHub<a href="https://github.com/cardano-scaling/hydra"> repository</a></td></tr><tr><td>Indicative Sizing</td><td>L + 30%</td></tr><tr><td>Context of Indicative Sizing</td><td>Current team size for 12 months + 30% for support, special projects</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>TBC</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>No</td></tr><tr><td>Security Review</td><td>TBC</td></tr><tr><td>Code Audit</td><td>Yes</td></tr><tr><td>Community Endorsement</td><td><p>- Proposals and projects depending on Hydra:<a href="https://projectcatalyst.io/funds/12/cardano-use-cases-mvp/wine-supply-chain-tracking-and-reporting-system"> Wine Supply Chain Tracking</a>,<a href="https://projectcatalyst.io/funds/12/f12-cardano-use-cases-mvp/hydra-enabled-accounting-and-micropayments-system"> Hydra-Enabled Accounting and Micropayments System</a>, API pay-per-use (Blockfrost, Demeter, ...), Ikigai Auctions, ...</p><p>- New revenue stream for SPOs (running Hydra payment channel network nodes) and infrastructure projects like iagon</p></td></tr><tr><td>Feasibility Study Required?</td><td>No. Research papers and bitcoin lightning sets a precedent, while<a href="https://projectcatalyst.io/funds/12/f12-cardano-use-cases-concept/cardano-lightning-network-phase-1-payment-gateways"> small related R&#x26;D project</a> already underway.</td></tr><tr><td>Reviewing Working Group</td><td><a href="https://github.com/cardano-scaling/wg-hydra">Hydra working group</a> </td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>TBC</td></tr><tr><td>Item Champion</td><td>Trym Bruset (primary), Sebastian Nagel (secondary)</td></tr><tr><td>Talking Points (Optional)</td><td>TBC</td></tr></tbody></table>

## TLM-1. Timeliness Market

Provides the ability to ensure the insertion of a transaction over a given (short) time frame into the chain with a high level of assurance irrespective of the load on the chain at that time

Key benefits are the assurance that key transactions occur in a given time frame - eg oracles for dApps, payments with real-world deadlines, etc

<table data-header-hidden><thead><tr><th width="248"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. </td></tr><tr><td>Drivers</td><td>Need for assured insertion of transactions into the chain in a given timeframe - assurance known hours, days, weeks in advance; Existence of such assurance (and where a contractual commitment can be made - feasible in this approach) helps ameliorate risks inherent in various use cases of Cardano in dApps and other commercial processes.</td></tr><tr><td>Documentation</td><td>As published Google Docs and <a href="https://drive.google.com/file/d/11i3juW2B57rQKdOvYo3HNZ1nipjRvfUO/view?usp=sharing">Report on Cardano timeliness constraints.pdf</a></td></tr><tr><td>Target State</td><td>Two possible targets: 1) changes to cardano-node (additional call in client-to-node API; minor change to mempool structure) or 2) which is (1) + initial activity to develop the "Cardano Timeliness Future Market"</td></tr><tr><td>Definition of Done</td><td>for (1) - code base updated, property tests written and integrated, regression testing completed</td></tr><tr><td>Product Stage</td><td>TBC</td></tr><tr><td>Service Level</td><td>TBC</td></tr><tr><td>Functional Requirements</td><td>TBC</td></tr><tr><td>Non-functional Requirements</td><td>TBC</td></tr><tr><td>External Dependencies</td><td>for (1) - none; for (2) - needs an appropriate ecosystem to evolve to create futures market</td></tr><tr><td>Communication Channel</td><td><br>TBC</td></tr><tr><td>Indicative Sizing</td><td>for (1): Development Effort: 4-6 person months (development and property tests); regression testing in addition to this</td></tr><tr><td>Context of Indicative Sizing</td><td>just (1); (2) would need different skills including indivdual to spearhead the market creation`</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>TBC</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>No</td></tr><tr><td>Security Review</td><td>No change to security model - not needed</td></tr><tr><td>Code Audit</td><td>External audit not needed, internal auditing (as part of standard development process) along with suitable property coverage should be sufficient</td></tr><tr><td>Community Endorsement</td><td>TBC</td></tr><tr><td>Feasibility Study Required?</td><td>No, the effort requirements are low, feasilblity study would probably represent as great an effort as low-level design and implementation</td></tr><tr><td>Reviewing Working Group</td><td>TBC, Network</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>Yes</td></tr><tr><td>Item Champion</td><td>Neil Davies</td></tr><tr><td>Talking Points (Optional</td><td>TBC</td></tr></tbody></table>

## PUW-1. Proof of Useful Work for Deep Learning

Use the training process of deep learning as “useful work” for validators to elect a block producer ensuring traceability of dataset and models trained, and obtained accuracy.

While PoW is secure, PoUW is a greener solution in which validators compute useful tasks instead of solving mathematical puzzles that have no other purpose than selecting a block producer

<table data-header-hidden><thead><tr><th width="251"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>Drafting </td></tr><tr><td>Drivers</td><td>Innovation, Sustainability (ESG), Security (with Minotaur, a PartnerChain could leverage PoS &#x26; PoUW), Blockchain-based AI</td></tr><tr><td>Documentation</td><td><a href="https://iohk.io/en/research/library/papers/provably-secure-blockchain-protocols-from-distributed-proof-of-deep-learning/">https://iohk.io/en/research/library/papers/provably-secure-blockchain-protocols-from-distributed-proof-of-deep-learning/</a></td></tr><tr><td>Target State</td><td>From SRL2 (research paper) to SRL5. From BRL0 (concept in validation) to BRL4.</td></tr><tr><td>Definition of Done</td><td>Prototype(s), Simulations, Full specifications, Target Neural Networks models identified</td></tr><tr><td>Product Stage</td><td>R&#x26;D</td></tr><tr><td>Service Level</td><td>SRL2</td></tr><tr><td>Functional Requirements</td><td>Demonstrate feasibility and total addressable market depending on which Neural Networks (RNN, CAN, LLM, SLM, etc.) can run in the constraints of the protocol</td></tr><tr><td>Non-functional Requirements</td><td>Identify the time/memory/computing/networking constraints of the protocol for Deep Learning models for the validators. Validate that models can be trained improving accuracy.</td></tr><tr><td>External Dependencies</td><td>TBC</td></tr><tr><td>Communication Channel</td><td>Website, Github repository, Discord channel, videos</td></tr><tr><td>Indicative Sizing</td><td>4-5L</td></tr><tr><td>Context of Indicative Sizing</td><td>1 year of formal methods, ML, prototyping, architecture, applied crypto engineers with support of researchers</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>Might require cooperating with AI specialized companies as well as AI data providers/consumers</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>No, this is not intended for Cardano Mainnet, most likely PartnerChains</td></tr><tr><td>Security Review</td><td>No</td></tr><tr><td>Code Audit</td><td>No</td></tr><tr><td>Community Endorsement</td><td>TBC</td></tr><tr><td>Feasibility Study Required?</td><td>TBC</td></tr><tr><td>Reviewing Working Group</td><td>Consensus</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>TBC</td></tr><tr><td>Item Champion</td><td>Romain Pellerin (IOR)</td></tr><tr><td>Talking Points (Optional)</td><td>PoW is secure, PoUW is a greener solution for PoW in which you use computational power to serve useful tasks instead of solvin mathematical puzzles that have no other purpose then selecting a block producer</td></tr></tbody></table>

## MTH-1. Mithril&#x20;

Mithril is a stake-based multi-signature scheme that leverages the Cardano network to provide certified snapshots of all or part of the blockchain state. These snapshots are valuable for various use cases, including secure voting, data exchange, and synchronization between applications, sidechains, and light wallets.

The beta version of Mithril was successfully launched on the mainnet in July 2023, enabling faster bootstrapping of Cardano nodes. Since then, numerous improvements and optimizations have been made, enhancing the protocol’s functionality and robustness. While Mithril has reached a mature state, two critical areas require further development to ensure readiness for real-world use cases: decentralization and sustainability.

Use cases include: snapshotting / fast bootstrap, more secure light wallets, trustless bridges (related [catalyst ](https://projectcatalyst.io/funds/12/f12-cardano-use-cases-product/zkfold-x-anastasia-labs-zk-bridge-using-mithril)proposal)

<table data-header-hidden><thead><tr><th width="251"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>Triaged</td></tr><tr><td>Drivers</td><td><ol><li>Scalability, Interoperability, Adoption</li><li>Secure access to the Cardano blockchain traditionally requires running a full node, which demands significant resources. Mithril addresses this challenge by enhancing security for light clients. It provides efficient cryptographic proofs that allow lightweight clients to directly verify the validity of blockchain data without relying on third parties. This approach not only reduces the resource burden on users but also maintains high security standards, enabling broader participation and adoption across the Cardano ecosystem</li></ol></td></tr><tr><td>Documentation</td><td><p><a href="https://iohk.io/en/blog/posts/2021/10/29/mithril-a-stronger-and-lighter-blockchain-for-better-efficiency/">Mithril: Stronger Lighter Blockchain for better efficiency</a></p><p><a href="https://iohk.io/en/research/library/papers/mithril-stake-based-threshold-multisignatures/">Mithril Research Paper</a></p><p>Cardano Decentralised Message Queue</p></td></tr><tr><td>Target State</td><td>Production</td></tr><tr><td>Definition of Done</td><td>TBC</td></tr><tr><td>Product Stage</td><td>BRL 6</td></tr><tr><td>Functional Requirements</td><td>Anybody can run an aggregator.</td></tr><tr><td>Non-functional Requirements</td><td>Fully decentralized and sustainable protocol, including an incentive model which ensure SPO participation.</td></tr><tr><td>External Dependencies</td><td>TxPipe to implement node-to-client mini-protocol in Pallas library</td></tr><tr><td>Communication Channel</td><td>TBC</td></tr><tr><td>Indicative Sizing</td><td>Large (For Network only) Full Solution = 5L + 1L Networking Team Support = 6L</td></tr><tr><td>Context of Indicative Sizing</td><td>Protocol maintenance and enhancements, decentralization of signer key registration and P2P signature broadcast, enabling multiple aggregators, design and implement an incentive model</td></tr><tr><td>Dependencies &#x26; Dependant</td><td>TBC</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>TBC</td></tr><tr><td>Security Review</td><td>Yes</td></tr><tr><td>Code Audit</td><td>Partial</td></tr><tr><td>Community Endorsement</td><td>Yes</td></tr><tr><td>Feasibility Study Required?</td><td>Yes, we have started with some of the feasibility studies but more will be required</td></tr><tr><td>Reviewing Working Group</td><td>Consensus/Network</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>Yes</td></tr><tr><td>Item Champion</td><td>Reza Baram / Marcin Szamotulski</td></tr></tbody></table>

## PAC-1. Partnerchains&#x20;

Partner Chains toolkit empowers Cardano Stake Pool Operators (SPOs) to validate and produce blocks for specialized blockchains directly connected to Cardano. This enables SPOs to increase their earning potential while actively contributing to the expansion and diversification of the Cardano ecosystem. By introducing native cross-chain transaction capabilities, Partner Chains enhance scalability and foster seamless interoperability with EVM-based applications, significantly boosting the connectivity and utility of the Cardano network.

If implemented, this item can potentially unlock new revenue streams for Cardano SPOs and supercharge the ecosystem's growth by enabling scalable, cross-chain Partner Chains that enhance connectivity and interoperability across blockchain networks.

<table data-header-hidden><thead><tr><th width="253"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>Triaged</td></tr><tr><td>Drivers</td><td><ol><li>Cardano Economic Growth | Cardano Network Effects</li><li>Improving the scalability and interoperability of the network</li></ol></td></tr><tr><td>Documentation</td><td><a href="https://github.com/input-output-hk/partner-chains">https://github.com/input-output-hk/partner-chains</a>; <a href="https://eprint.iacr.org/2018/1239.pdf">https://eprint.iacr.org/2018/1239.pdf</a> ; <a href="https://dl.acm.org/doi/pdf/10.1145/3548606.3559356">https://dl.acm.org/doi/pdf/10.1145/3548606.3559356</a></td></tr><tr><td>Target State</td><td>To be added</td></tr><tr><td>Definition of Done</td><td>To be added</td></tr><tr><td>Product Stage</td><td>Alpha production</td></tr><tr><td>Functional Requirements</td><td>Mixed-resource security and block production<br>Facilitate native cross-chain transactions at the consensus layer<br>Reference chain with EVM execution environment</td></tr><tr><td>Non-functional Requirements</td><td>High scalability and performance.<br>Robust security and fault tolerance.<br>Seamless interoperability with existing Cardano infrastructure.</td></tr><tr><td>External Dependencies</td><td>Integration with Cardano network protocols - LibP2P.<br>Compatibility with EVM-based applications and tools.</td></tr><tr><td>Communication Channel</td><td>Website, Github repository, Intersect TWG Discord channel, Videos</td></tr><tr><td>Indicative Sizing</td><td>3L</td></tr><tr><td>Context of Indicative Sizing</td><td>Two workstreams: security and cross-chain transactions. Each workstream is a large chunk of work with multiple sub-streams</td></tr><tr><td>Dependencies &#x26; Dependants</td><td>TBC</td></tr><tr><td>Hardfork</td><td>No</td></tr><tr><td>Security Review</td><td>TBC</td></tr><tr><td>Code Audit</td><td>Mandatory prior to production deployment of PCs</td></tr><tr><td>Community Endorsement</td><td>Yes</td></tr><tr><td>Feasibility Study Required?</td><td>No</td></tr><tr><td>Reviewing Working Group</td><td>Yes, already formed TWG Partner Chains</td></tr><tr><td>Core Infrastructure</td><td>Yes</td></tr><tr><td>Item Champion</td><td>Karen Chang (Omer Husain, Nick Stanford)</td></tr></tbody></table>

## ARN-1. Rust Node (Amaru)

Amaru is an open-source project that aims to build a new fully interoperable block-producing node for improving the overall performance the Cardano blockchain. The Amaru node provides a simplified entry point for building things on Cardano by using a modular design and Rust as its main coding language.

If implemented, this item aims to improving all the performance aspects of a Cardano node, enable less resources used for better performance and creating a modular design, giving the opportunity to tailor to the operator use case

<table data-header-hidden><thead><tr><th width="241"></th><th></th></tr></thead><tbody><tr><td>Status</td><td>Triaged</td></tr><tr><td>Drivers</td><td>Bringing diversity and operational resilience to Cardano<br>Performance with no compromise regarding security<br>Focusing on operator experience<br>Resilience in all aspect of the design (Framework, Product, Teams contributing)<br>Interoperability<br>Adoption</td></tr><tr><td>Documentation</td><td>Repository : <a href="https://github.com/pragma-org/amaru">https://github.com/pragma-org/amaru<br></a><br>Roadmap : <a href="https://github.com/orgs/pragma-org/projects/1/views/1">https://github.com/orgs/pragma-org/projects/1/views/1</a></td></tr><tr><td>Target State</td><td>Bloc producing node capability</td></tr><tr><td>Definition of Done</td><td>Various use case implemented<br>Audited code base</td></tr><tr><td>Product Stage</td><td>BRL6 on the client aspects of the node: peer to peer and networking<br>BRL5 on the relay mecanisms: consensus implementation and ledger rules<br>BRL5 on the bloc production aspects of the node</td></tr><tr><td>Functional Requirements</td><td>Feature parity with the current Cardano node (Haskell)<br>Compatibility with middlewares<br>Testing environment capabilities</td></tr><tr><td>Non-functional Requirements</td><td>Modular architecture (able to customise the build you're running)<br>Pre-built implementation</td></tr><tr><td>External Dependencies</td><td><a href="https://github.com/txpipe/dolos">Dolos </a>A first incarnation of a node client, albeit geared towards client applications such as DApps. Dolos is de-facto a foundation which will inspire the design and work on Amaru.<br><a href="https://github.com/txpipe/pallas">Pallas </a>Hosts many Rust primitives and building blocks for the node already powering tools like Dolos. In particular, the networking and serialization logic.<br><a href="https://github.com/cardano-foundation/cf-java-rewards-calculation">java-rewards-calculation</a> A Java re-implementation of the Cardano rewards calculation which can now serve as a reference implementation for a Rust version.<br><a href="https://github.com/aiken-lang/aiken/tree/main/crates/uplc">uplc </a>An Untyped Plutus Core (UPLC) parser and CEK machine for evaluating Plutus V2 and Plutus V3 on-chain scripts.<br><a href="https://github.com/input-output-hk/mithril">mithril </a>A stake-based threshold multi-signatures protocol.<br><a href="https://github.com/dcSpark/cardano-multiplatform-lib">cardano-multiplatform-library </a>A Rust implementation of various Cardano data and crypto primitives.<br><a href="https://github.com/cardano-community/cncli">cncli </a>A Rust implementation of Cardano CLI tools including VRF functionality, and some consensus tooling like leaderlogs.</td></tr><tr><td>Communication Channel</td><td><a href="https://discord.gg/3nZYCHW9Ns">https://discord.gg/3nZYCHW9Ns</a></td></tr><tr><td>Indicative Sizing</td><td>2L</td></tr><tr><td>Context of Indicative Sizing</td><td>Ongoing analysis - Rough estimate for a year : 9 FTE (7 Senior Dev; 1 Engineering Manager; 1 Product/Project manager)<br>Testing infrastructure to be estimated</td></tr><tr><td>Hardfork (Yes,No, TBC)</td><td>TBC</td></tr><tr><td>Security Review</td><td>TBC</td></tr><tr><td>Code Audit</td><td>Yes</td></tr><tr><td>Community Endorsement</td><td>To be confirmed, currently participating: Blink labs, Cardano Foundation, dcSparks, Sundae Labs, Txpipe</td></tr><tr><td>Feasibility Study Required?</td><td>No</td></tr><tr><td>Reviewing Working Group</td><td>TBC</td></tr><tr><td>Core Infrastructure (Yes, No, TBC)</td><td>TBC</td></tr><tr><td>Item Champion</td><td>Giorgio Zinetti</td></tr></tbody></table>