Amaru is an open-source project building a new, fully interoperable block-producing node that improves the overall accessibility and robustness of the Cardano network without compromising its safety and security. Amaru provides another perspective and solution for stake pool operators and developers alike, prioritizing low hardware requirements and a seamless user experience. The project is implemented primarily in Rust and aims to attract new contributors to the ecosystem's core maintenance.
This is our second treasury withdrawal proposal, following a successful budget and treasury withdrawal in mid-2025. We will recap what we have accomplished so far, thanks to this first allocation, and break down the objectives, scope, and timelines for 2026.

Before we dive further into the details and cost breakdown, here is a high-level view of the ask, some assumptions we are making, and the general direction of this withdrawal request.

2025 Retrospective

We provide a full retrospective of our 2025 roadmap in annex of this document. This includes a head-to-head comparison with the roadmap items presented last year with their corresponding deliveries.

Duration & Milestones

This proposal spans over 12 months, from January to December 2026, throughout which there will be several deliveries, demos, and workshops. Amongst the key deliveries, we note:

• a relay-capable node in Q1 2026;
• an upcoming intra-era hard fork integration (likely in Q1 2026, although the exact hard fork date is still uncertain at the moment of writing this proposal);
• a block-producing node by the end of Q2 2026;
• experiments and prototypes throughout the year covering planned improvements to the protocol (i.e., Leios, Peras, Phalanx, Decentralized Messaging Queue…);
• key integrations such as StarStream or Midgard in the second half of the year.

Due to governance restrictions on Cardano (e.g. insufficient net change-limit), we've had to postpone this proposal to later in the year. Yet, activities did not stop in 2026. We'll thereby retroactively use some of that budget for the earliest part of 2026. This explains why this budget still covers 12 months: it includes January and February 2026.

Total Budget Ask

The total ask is ₳10,142,000 (covering a USD budget of $3,042,500) for 2026. The full budget breakdown is given below.

All scopes are estimated in FTE (Full-Time Equivalent) based on an average hourly market rate. Having now a year of dealing with contractors and service providers in our ecosystem we came to the average hourly rate of around $108 which gives us a figure of$225k annual billable rate.

We (still) use a conservative conversion rate of 0.5 ADA [₳] per USD [$]. This rate is based on a weighted-average price calculation over the past 2 years, resulting in a price range of $0.5 to $0.6. We “bearishly” consider the lower end of that range.

NOTE: Is $225k a realistic number?

The $225k yearly price tag may seem like a lot if taken out of context. We think it requires further clarification:

• Amaru is a critical, hyper-specialised software component in a rather niche industry. Finding experts who can navigate those waters is hard and expensive.
• There are precedents that serve as reference points and helped us size our target annual billable rate:
  • 'Input Output Engineering Core Development Proposal for 2025': $302k-$346k yearly per FTE ($48.4M for 140-160 FTE).
  • 'TWEAG’s Proposals for multiple core budget projects for Cardano 2025': $332k yearly per FTE ($160 hourly rate).
  • 'MLabs' proposal for Core Tool Maintenance & Enhancement: Plutarch: $285k yearly per FTE ($192k for 1400 hours, so $137 hourly rate).
  • 'Midgard's proposal for Optimistic Rollups': $215k yearly per FTE.
  • 'Scalus's proposal for DApps Development Platform' : $190k yearly per FTE.
• Contributors paid by the treasury aren’t employees, and the amounts paid aren’t salaries. This is more akin to consulting/contractor work and must factor in social security, vacation time, management overhead, schedule gaps, and so forth.
• Contributors are also not on a payroll, and they have little guarantee of uninterrupted payments:
  • There’s no guarantee the next Amaru withdrawal will be accepted, so their jobs are constantly at risk.
  • They are only paid if they deliver on their milestones (which means, no payouts should they get sick or unable to work, for example)
  • They are subject to the tides of Cardano governance and the intricacies of receiving money from a Blockchain. For example, some Amaru contributors haven’t been paid for multiple months while we were sorting out the legal framework around this treasury management.

Transition Into 2026 and 2025's Leftovers

Thanks to good management of our 2025 treasury (and a bit of luck with the market), we were able to fully fund our planned activities through the end of 2025 with only a fraction of the allocated funds, without resorting to our contingency.

As planned, the leftovers from the Amaru treasury have been sent back to the Cardano treasury:

• Consensus = ₳11.90k
• Ledger = ₳168.75k
• Marketing = ₳39.75k
• Mercenaries = ₳400.00k
• Contingency = ₳300.00k

Note that at the moment of writing this proposal, we still have a few remaining late 2025's invoices; which explains why some treasury addresses aren't fully empty yet. They are provisions for the already signed quotes that will be paid out soon.

With 2025 now over and as provisioned in our budget, we have also mandated an external firm to audit Amaru's finances. Once ready, the full audit report will be made publicly available and shared on social channels.

Treasury Management Transparency

As in our first treasury withdrawal, we use a smart contract to manage the treasury and control its expenditures. We will also likely secure the treasury with (Cardano native) stablecoins whenever possible and relevant to keep its value safe from market volatility until the final payment to contributors is made.

Furthermore, every expense will continue to be logged in a public journal, ultimately traceable on-chain.

Team & Budget Administration

Who we are

Amaru is a multi-entity effort that currently sits under PRAGMA: a member-based, not-for-profit open-source association for blockchain software projects. Five members with equal power currently drive PRAGMA’s strategy and operations. In particular, they oversee Amaru’s maintainer committee and progress. The appointed maintainer committee for 2026 is responsible for the following scopes:

• Operations & use cases, managed by Damien Czapla
• Core development, managed by Matthias Benkort
• Network compliance & Cardano-level Testing, managed by Paolo Veronelli
• Middleware integrations, managed by Pi Lanningham

In addition to the scope owners who constitute the maintainer committee, many great developers have been relentlessly contributing to Amaru, among them Julien, Arnaud, Joshua, Geoff, Eric, Stevan, Lucas, Roland, Jonathan, and Ethan, to name a few.

Budget Administration

The Amaru maintainer committee will ensure direct budget administration, assisted by an on-chain smart contract.

The fund management, responsibilities, and remuneration of contributors will follow PRAGMA’s legal framework, as provided in the annex under PRAGMA Maintainer Committee Framework.

In addition, the smart contract’s role is to ensure that funds are expended in accordance with the scope defined in this budget and authorized by the relevant scope owners.

On-chain Process

We recognize the following capabilities of the smart contract:

1. Standard withdrawal: A scope owner requests funds from other scope owners to be withdrawn from their scope.
2. Contingency withdrawal: A scope owner requests that other scope owners withdraw funds from the contingency fund.
3. Scope reconciliation: A scope owner requests a change of ownership (or a reallocation of budget) from other scope owners.
4. Contingency refund/closing: The scope owners request that the leftovers from the contingency budget be returned to the Cardano treasury.
5. Credential rotation: In case of lost credentials or the departure of a scope owner, a mechanism allows the rotation of credentials to a new scope owner upon approval by all (5 out of 5) PRAGMA members (effectively capturing PRAGMA’s board decision to appoint new maintainers).
6. Failsafe: In the extreme scenario where credentials are irremediably lost, preventing any further decision, a failsafe mechanism returns all unconsumed funds to the Cardano treasury.

Off-chain Process

Any disbursement of funds to a contributor must be in accordance with the maintainer committee framework and correspond to a contributor contract. We establish a contributor contract via the following steps:

• A scope owner formulates an objective and a list of deliverables.
• A timeline is then discussed and agreed upon with the contributor.
• The scope of work is formalized in a contract including the milestones and expected payouts.

The bottom line is simple: an off-chain contract materialises the agreement between a scope owner and a contributor, with milestones ensuring regular deliveries and payouts. This prevents unsupervised work from going on for too long, encourages regular touchpoints, and allows contributors to continue being paid at a steady pace.

In order to trigger a payout from the (Amaru) treasury, the following steps have to happen:

• The scope owner visibly reviews and accepts the work done (typically by reviewing and approving pull requests).
• The contributor sends an invoice to the scope owner related to the accepted deliverables.
• A transaction is built, then signed by the maintainers' committee. The transaction must include the invoice and the milestone details.
• The transaction is then recorded in a public journal (in addition to being visible on-chain).

Project management and contributions

As an open-source project, we are committed to transparency and to being as welcoming as possible to potential contributors. In particular:

• We still aim for a regular demo cadence (once every 2 months on average)
• We set common goals for the project
• Work items are planned in the form of deliverable milestones and typically assigned to one contributor.

Besides, the project has been maturing, and we are also becoming more structured in how we work, plan, and execute. While the barrier to entry remains high, we are committed to making the project progress even easier to follow for external contributors and interested stakeholders alike.  

We will likely adapt our current bi-weekly (public) maintainer meeting into more frequent milestone-oriented sprints, and we will capture work ahead and discussions in a more systematic manner on GitHub, while still using the website at https://amaru.global to centralize and organize the information.

Quarterly reports

In addition, following PRAGMA's Decision Record 006, progress on Amaru shall be reported quarterly. The content of these reports is straightforward and includes the following:

• problems that require board attention (infrastructure, trademarks, etc.)
• project status (active, inactive, initiating, etc.)
• a changelog (last committer addition)
• next planned steps (new releases, significant changes, etc.)
• reflection & performances

This recurring interaction provides a high-level project overview and long-term traceability.

Budget Breakdown

Complete View

The anticipated fixed cost includes:

• (Core Development) $500k Security audit (8 weeks, 2 engineers);
• (Operations & Use Cases) $70k Node diversity workshops (2 anticipated, $35k each);
• (Operations & Use Cases) $10k for Marketing including Cardano Summit participation;
• (Operations & Use Cases) $20k SPO contracting and Japanese translation costs;
• (Operations & Use Cases) $30k for Bug Bounty program;
• (Network Compliance & Cardano-level Testing): $500k yearly estimate for the Antithesis platform costs and infrastructure related to the end-to-end testing activities.

A complete breakdown of this budget is available in annex.

Total Ask

USD sub-total

The total ask for the project is 8.5 FTEs + $1.13M in fixed costs. FTEs are being valued at an annual billable rate of $225k.

This leaves us with the following USD sub-total: 8.5 x $225k + $1,130k = $3,042,500

Treasury valuation rate

We (still) use a conservative conversion rate of 0.5 ADA [₳] per USD [$]. This rate is based on a weighted-average price calculation over the past 2 years, resulting in a price range of $0.5 to $0.6. We “bearishly” consider the lower end of that range.

This gives us a base allocation of $3,042,500 / 0.5 = ₳6,085,000.

Contingency: market risk buffer

Given that ADA has been consistently trading below $0.5 in the past 60 days, we also consider an additional contingency budget which shall serve to compensate market conditions when they do not allow us to trade ADA at a price of at least 0.5 ADA per USD.

We observe that in the past 60 days, ADA traded at an average low of about $0.34, with a downward trend. So we conservatively consider $0.3 as a low-end trading price for our contingency. When ADA trades above $0.5, we shall not use the contingency. When it trades below $0.5, we shall use the contingency to compensate for the gap.

Said differently, to protect deliverability under adverse market conditions, we define a volatility buffer covering price drops down to $0.3/₳.

Therefore the contingency reserve equals: $3,042,500 / 0.3 - $3,042,500 / 0.5 ~ ₳4,057,000 budget.

Final total

The final ask is ₳6,085,000 + ₳4,057,000 = ₳10,142,000.

NOTE: ...but isn't that the same as considering a rate $0.3/₳?

Not really. Our contingency is governed differently than the other allocations. It requires an action from all scope owners. Here, it is only present as a treasury risk policy and shall only be used to compensate market volatility. In particular, it will NOT be used to fund unbudgeted activities.

Of course, any leftovers from the contingency and other scopes alike will eventually be returned to the Cardano treasury at the end of this budget period. So, worse case scenario: the market stays at average low of $0.3 and below all year and we have to consume our contingency entirely. In a brighter scenario, we take advantage of better market conditions and return as much of the contingency as we reasonably can.

Constitutionality checklist

In an effort to convince ourselves of the proposal's constitutionality, we thought relevant to include a checklist of the points we cover and for each, our interpretation of the Cardano Constitution.

Article I - Section 1: tenets

• [x] This proposal is for work intended to enhance the security, decentralization and long-term sustainability of Cardano.

Article II - Section 3.1: use of smart contracts

• [x] We leverage multiple (open source and audited) smart contracts as detailed in amaru-treasury to administer the requested budget.

Article II - Section 6.1: format

• [x] We have submitted this proposal in a standardized, legible format, which includes a URL and hash of all documented off-chain content. Moreover, the proposal metadata and appendix documents are hosted on an immutable storage and content-addressed.

Article II - Section 6.2: relevance

• [x] We believe our rationale to be detailed and sufficient. The proposal contains a title, abstract, reason for the proposal and relevant supporting materials.

Article II - Section 7.1: terms of withdrawal

This proposal includes:

• [x] a clear withdrawal purpose: (partially) funding the development of Amaru in 2026;
• [x] a period for delivery of proposed activities which the withdrawal shall be used for: all along 2026, with a milestone breakdown and rough timeline given in appendix;
• [x] relevant costs and expenses of the proposed activities: clear separation between fixed costs and variable costs, modeled as FTE (Full-Time Equivalent) in addition to a contingency to cope with market volatility. The full breakdown is given in appendix.
• [x] circumstances under which the withdrawal might be refunded to the Cardano Treasury: the smart contract enforces leftovers to be sent back to the treasury after the budget ends (31st December 2026). Any unused budget after payment of the remaining contributors will therefore be reimbursed to the treasury as early as possible in 2027.

Article II - Section 7.2: past withdrawal(s) disclosure

• [x] As mentioned in introduction, we have disclosed that this is our second withdrawal in the last 24 months. The previous was submitted in June 2025, and enacted in July 2025.

Article II - Section 7.3: net-change limit

• [x] This proposal follows a recently established net-change limit of 350M covering Epoch 613 to Epoch 713. At the moment of submission, this proposal is well within the boundaries.

Article II - Section 7.4: periodic audits

This proposal makes provisions for:

• [x] periodic independent audits (c.f., budget breakdown; under Operations & Use Cases); and
• [x] several 'node diversity' workshops constituting means to assess and compare our progress and use of the budget with other projects of the same nature.

Article II - Section 7.5: administration

• [x] This proposal specifies an administrator in accordance with this provision. It also specifies an internal administration process using smart contracts and an off-chain overseeing committee.

Article II - Section 7.6: treasury oversight

• [x] This proposal withdraw funds in 5 separate script accounts which each provides a public oversight of all operations, and ensures that funds cannot be delegated to an SPO and can only be delegated to the always-abstain drep/
• [x] In addition to the on-chain guarantees provided by the smart contracts, we also commit to an off-chain journaling in the same fashion as done for the first withdrawal.

Guardrails

• [x] In accordance to the guardrail TREASURY-02a, this withdrawal does not exceed the NCL at the moment of submission.
  
• [x] In accordance to the guardrail TREASURY-03a, this proposal is ultimately denominated in ada.

Conclusion

The Amaru project represents a major step towards node diversity by developing a modular, high-performance, and interoperable block-producing node for Cardano. Our approach, rooted in openness, innovation, and operational resilience, aims to deliver significant advancements in blockchain technology without compromising on security.

We are immensely proud of what our team has accomplished and delivered in a short timeframe, and we remain conscious that we had to make adjustments to the initially projected roadmap. We spent more time than anticipated on coordination and establishing a work environment for the project contributors.

Our 2025 retrospective enclosed in annex underscores last year’s achievements, as well as the roadblocks we bumped into and had to overcome. Managing an open-source project using the Cardano treasury in a decentralized manner is a learning challenge. These learnings have been directly captured in the budget breakdown for 2026 and in the evolution of our processes.

With this, we’re confident we can deliver on the next steps. And we firmly believe that Amaru demonstrates not only that an alternative Cardano node implementation is possible, but also that it can deliver significant performance, testability, and maintainability improvements.

There’s no more doubt that Amaru contributes to the decentralization and resilience of the Cardano ecosystem. This is a significant path for the future of Cardano, and a path we are strongly committed to take together with the Cardano community.

Detailed scopes (IPFS)

Budget Detailed View

In the following section, we cover the scopes of work for 2026, their main objectives, owners, estimated resources required, and an overview of their planned milestones.

Core Development

📦 Q1 - Relay Wrap-up

Goal

Deliver a production-ready relay-capable Amaru node. Said differently, a node capable of selecting and following the chain according to Ouroboros' consensus, as well as diffusing transactions and blocks to the network, while fully validating their well-formedness and ledger compliance.

Key Results

• Remaining ledger rules & stabilizations of the phase-2 validations;
• Single mempool strategy & transaction diffusion via the mini-protocols;
• Initial P2P networking stack, with basic peer discovery and management;
• Internal optimizations and polish (in particular around observability);

Key Performance Indicators (KPIs)

Estimated Effort

3.5 FTEs

📦 Q1 - Upcoming Intra-era Hard Fork

Goal

Follow through necessary protocol upgrades, plutus virtual machine changes (Plutus V4) and agreed-upon CIPs that will be part of the next intra-era hard fork to be planned (likely, circa February 2026).

Key Results

• Align with Intersect and IOE on the exact timelines and deliveries;
• Support for Plutus V4 semantic;
• Support for new virtual machine builtins (BLS, new built-in value methods, array, ...);
• Uninterrupted synchronization through the hard fork transition.

Key Performance Indicators (KPIs)

Estimated Effort

1.5 FTEs

📦 Q2 - Path to Block Production

Goal

Implement remaining node functionality to close the gap between a relay and a block producer. This includes key (KES, VRF & Ed25519) management, block forging, additional metrics, SPO-specific governance tooling and necessary performance optimisations and conformance tests. This also marks the beginning of an independent security audit to look for defects or critical vulnerabilities.

Key Results

• Begin external security audit through one or more independent firms;
• Reinforce testing and conformance, in particular on Antithesis and through penetration testing;
• Finalize work on mempools and peer management;
• Implement block forging.

Key Performance Indicators (KPIs)

Estimated Effort

5 FTEs

📦 Q3 - Mainnet Readiness

Goal

Get Amaru to a level of confidence that is sufficient for 'production'. Limit damages and disruptions that can be done to Cardano mainnet.

Key Results

• Finalize security audit & publish report (8 weeks, 2 engineers, about $500K);
• Fixes and quality of life improvements as requested by SPOs;
• Performance tweaks and monitoring improvements.

Key Performance Indicators (KPIs)

Estimated Effort

5 FTEs

📦 Q3, Q4 - Explore New Horizons

Goal

Follow-up with Cardano evolutions and help in the evaluation and design of the potential next steps. Work with the Haskell team and other node implementors to draft the future of Cardano.

Key Results

• Experiment/prototype new protocol-level updates. For example, Ouroboros Peras, Ouroboros Phalanx, and/or Ouroboros (Linear) Leios;
• Prototype with StarStream as a new virtual machine.

Key Performance Indicators (KPIs)

To be defined.

Estimated Effort

5 FTEs

🧾 Core Development ━ Summary

• Resources estimated: 5 FTEs
• Resources already funded: 1.5 FTE
• Resources required: 3.5 FTE
• Fixed Costs: $500k

Operations & Use Cases

📦 Q1 - Constrained Hardware Deployments

Goal

Continue the development and maintenance of Amaru running on a Raspberri Pi as showcased at the Cardano Summit

Key Results

• Polish and refine the Raspberry Pi setup presented at the Cardano summit.
• Explore deployments on new, more sustainable, constrained hardware setups (e.g., Radxa);

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE

Q2 - First Node Diversity Workshop

Goal

Regularly bring together node developers and close stakeholders in a constructive environment to foster coordination between nodes.

Key results

• Organise the next node diversity workshop (in Porto?) focused on (linear) Leios and network resilience in a multi-node environment.
• Workshop organised and documented on the Cardano forum

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE + $35K fixed cost

📦 Q3 - Amaru in the browser

Goal

Run (a subset of) Amaru in the browser, to showcase Amaru versatility and ensures a clean decoupling of Amaru's internal. This effort opens the door to light clients and a potentially new form of DApps on Cardano.

Key Results

• Maintain and complete WASM support of the Amaru node components;
• Provides a browser-compatible ledger and consensus stores (e.g. IndexedDB);
• Develop a backend proxy prototype to relay TCP connections;
• Explore Zero-Knowledge validations using a WASM-based prover stack.

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE

📦 Q3, Q4 - SPO Playground

Goal

Create a low entry-barrier sandbox for SPOs to swiftly experiment with Amaru.

Key results

• Develop a playground environment for exploration and learning;
• Provide examples/templates of monitoring dashboards;
• Interface internationalization, at least Japanese.

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE + $20k fixed (translation) cost

📦 Q3, Q4 - Bug Bounty Program

Goal

Incentivise the open source contributions on Amaru and improve the resilience of the Cardano network

Key Results

• Clarify the incentives, workflow, and processes for establishing and claiming bounties; ideally, using Cardano-native solutions.
• Set up a bug-bounty program that leverages existing testnets and Antithesis;

Key Performance Indicators (KPIs)

Estimated Effort

0.5 FTE + $30k fixed cost

📦 Q4 - Second Node Diversity Workshop

Goal

Bring together node developers and close stakeholders in a constructive environment to work on improving the overall resilience of the Cardano network thanks to node diversity.

Key Results

• Organise another node diversity workshop focused on mainnet readiness and hard fork decision-making criteria moving forward.
• Workshop organised and documented on Cardano forum

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE + $35K fixed cost

📦 Q4 - Financial Audit

Goal

Have an external auditor scrutinize Amaru's finances and treasury management.

Key Results

• Publish a report at the beginning of Q1 2027 about the audited finances

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE

📦 Q1 → Q4 - Performance & profiling

Goal

Improve the resources consumption of the node and the runtime of basic features.

Key Results

• Establish realistic benchmarks and metrics to analyse Amaru’s performance in a more formal, systematic manner.
• Identify codebase improvements to reduce resource usage and improve overall performance.
• Analyze dependencies to find a better fit, reduce them, or internalize interesting ones.

Key Performance Indicators (KPIs)

Estimated Effort

0.5 FTE

📦 Q1 → Q4 - Project management

Goal

Facilitate project and product management aspects of Amaru-related activities

Key Results

• Improve work processes and coordination across the team(s);
• Maintain an alignment routine with each cluster of stakeholders;
• Publish monthly & quarterly reports detailing project's activity and progress.

Key Performance Indicators (KPIs)

Estimated effort

1 FTE

📦 Q1 → Q4 - Marketing and communication

Goal

Maintain communication channels with each stakeholder: SPOs, DEX/CEX/Businesses running Amaru, Node implementors & dApp developers.

Key Results

• Maintain presence on social media;
• Attend the next Cardano Summit;
• Keep the website and other public resources up to date;
• Publish quarterly reports.

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE + $10k fixed cost

🧾 Operations & Use Cases ━ Summary

• Resources estimated: 2.5 FTEs
• Resources already funded: 0.5 FTE
• Resources required: 2 FTEs
• Fixed Costs: $130k

Network compliance & Cardano level Testing

NOTE:

For obvious reasons, activities from this scope may be documented only after remediation has been found and implemented across the entire network. The goal here isn’t to attack and break the network, but to identify and fix critical vulnerabilities before a malicious actor does.

📦 Q1, Q2 - Analyse Network Behaviour

Goal

Document the behaviour of the Cardano network and the specific caracteristics of the Haskell node.

Key Results

• Analyse and (re-)evaluate peer selection rules of the Haskell implementation, looking at different angles: resilience, decentralisation, and operational concerns;
• Contribute to the Cardano blueprint with a report detailing the expectations regarding the network’s behaviour, peer management strategies, and possible areas of improvement.

Key Performance Indicators (KPIs)

N/A

Estimated Effort

1 FTE

📦 Q1 → Q4 - Support Antithesis development

Goal

Maintain a testing environment tailored with tests toolings and tests that benefits Cardano node stakeholders.

Key Results

• Support the development of Antithesis-related tooling, to maximise its ease of use and accessibility;
• Improve tooling around local development and experiments with node clusters.

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE

📦 Q1 → Q4 - White-Hacking and Cardano-level Testing

Goal

Investigate known attack vectors, “known unknowns,” and build robust test cases and simulation scenarios to validate (or not) network assumptions

Key Results

• Identify (if any) unknown vulnerabilities;
• Challenge researchers’ security models;
• Search for potential attack vectors / demonstrate existing ones;
• Create a reference automated test suite to exercise findings and known vulnerabilities.

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE + $500k fixed costs for the Antithesis platform and related infrastructure.

🧾 Network Compliance & Cardano-level Testing ━ Summary

• Resources estimated: 1.5 FTE
• Resources already funded: 0.5 FTE
• Resources required: 1 FTE
• Fixed costs: $500k

Middleware integrations

NOTE:

Because some of the planned milestones here depend on ongoing (and sometimes unfinished) projects, most far-away integrations are subject to changes and adjustments based on the latest priorities and ecosystem state. This doesn’t concern integrations planned in the first quarter.

📦 Q1, Q2 - Kupo & Dolos

Goal

Integrate Amaru as a data source in both Kupo and Dolos via the node-to-node protocols.

Key Results

• Amaru can stream blocks to Kupo and Dolos
• Amaru can provide for remaining queries necessary to Kupo (accessing chain's tip, forcing rollbacks, etc..)
• Dolos' gRPC is available through Amaru

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE

📦 Q1, Q2 - Mithril

Goal

Make Mithril (signer & client) a first-class citizen within the Amaru ecosystem. Leverage the fact that both are implemented using the same stack (i.e. Rust) and that Amaru relies on snapshots to maximise synergies with Mithril and increase its adoption amongst SPOs.

Key Results

• Embed a Mithril client in Amaru to ease bootstrapping and offer a seamless entry point to the Cardano network.
• Integrate an optional Mithril signer in Amaru to provide out-of-the-box participation to Mithril’s security.

Key Performance Indicators (KPIs)

Estimated Effort

1 FTE

📦 [uncertain] Q3, Q4 - StarStream

Goal

Explore StarStream's unique model and provide a sandbox for experimentations within Amaru. We aim to validate StarStream readiness and feasibility for an eventual mainnet rollout.

Key Results

• Implement StarStream virtual machine and new execution model directly in Amaru’s ledger;
• Analyze impact, iterate, refine, and collaborate with the Haskell team to support the implementation across all nodes.

Key Performance Indicators (KPIs)

To be defined.

Estimated Effort

1 FTE

📦 [uncertain] Q3, Q4 - L2s integrations

Goal

Explore possible integrations with various L2s (Hydra, Hydrozoa, Midgard, Sundial, Konduit, …)

Key Results

To be defined.

Key Performance Indicators (KPIs)

To be defined.

Estimated Effort

1 FTE

🧾 Middleware Integrations ━ Summary

• Resources estimated: 2 FTEs
• Resources secured: 0 FTEs
• Resource required: 2 FTEs
• Fixed costs: $0

2025 Retrospective (IPFS)

In 2025, we accomplished significant advances in consensus, ledger state management, simulation testing, governance, and network architecture. At the same time, we deviated from our original plan in a few areas (UTxO-RPC, P2P networking, …).

In this section, we reflect upon what was planned and what has been done, following the previously presented roadmap. We’ll highlight items that have been delivered ( 🟢 ), those underway or partially done ( 🟠 ), those abandoned/cancelled ( ⬜️ ), and items that are behind schedule and require attention ( 🔴 ). We will also highlight a few extra items ( ⭐️ ) that were unplanned but happened regardless.

Relay Node (initial target: Q2 2025)

🟢 Ledger: On-disk State Tracking

• Full on-disk ledger state: On-disk snapshots with minimal in-memory footprint, including notably:
  • (e)UTxOs
  • Stake pools and stake credential registrations/deregistrations
  • Accounts, consensus rewards calculations, and distribution
  • DReps and constitutional committee members
  • Protocol parameters
  • Governance proposals and votes

🟢 Ledger: (almost) Full Validation

• Partial Phase-1 validations: all transaction validation rules are mostly implemented, but a few straightforward checks must still be implemented. More hardening is also required to ensure 100% behavioral compatibility with the Haskell node.
• Partial Phase-2 validations: new Plutus Virtual Machine integrated with the ledger, with phase-2 evaluation implemented, yet still under testing and refinement.

🟢 Ledger: Governance Rules Implementation

• Governance ledger state: Governance, including voting stake distribution(s) and ratification/enactment of all governance actions
• Proposals forest: Tracking of governance proposals as an optimized forest of interdependent proposals
• Hard forks: Protocol upgrades (hard forks) and support for multi-version ledger and dynamic protocol parameters.

⭐️ Ledger: Conformance Testing & Blueprint

• Conformance testing: creation of various conformance test scenarios from the reference Haskell implementation and/or specification, including snapshot tests from mainnet/preprod/preview data.
• Cardano Blueprint: contributions to the Cardano blueprint to extend foundational knowledge about Cardano.

🟢 Consensus: Conformance & Simulation Testing

• Pure-stage actor and effects library: Complete transition from an initial proof-of-concept to a robust event processing pipeline architecture:
  • abstracts external effects for isolation and testing, including disk I/O, network, and time
  • supports both a deterministic scheduler for precise control of thread interleaving and standard non-deterministic parallel scheduling for production
• Simulation Framework: Development of a deterministic simulation testing system inspired by Jepsen and IOG’s io-sim. At the moment, simulations cover mainly chain selection from a node under test connected to multiple upstream peers.
• Data Generation: Creation of synthetic block trees to test arbitrary consensus scenarios, including randomization of message delivery.
• Visualization: - HTML tools to visualize execution traces and troubleshoot intricate distributed scenarios.
• Reproducibility: Support for seeds and full trace replay for test reproducibility.
• Antithesis Testing: Integration with the Antithesis testing platform. We’ve been mostly experimenting with the Haskell cardano-node, identifying and reporting subtle issues as we pave the way for Amaru to be used alongside Haskell nodes in Antithesis clusters.

⬜️ UTxO RPC Implementation

This work item was dropped from the roadmap early on, as we’ve decided to limit the number of integrated APIs in Amaru to avoid duplication of effort across the ecosystem. Our strategy is to rely on middleware (software sitting between Amaru and client applications) to provide those functionalities. In the case of UTxO-RPC, that means, for example, software like TxPipe’s Dolos or Blink Labs’ Dingo, which can provide client-level interfaces while relying on Amaru as a trusted data source.

Moreover, we’ve been deprioritizing these integrations to better focus on core development, stability, and the conformance of Amaru’s internals with the Haskell implementation.

🟠 SPO Involvement

We’ve made significant progress toward getting Amaru ready for external consumption by SPOs by providing multi-architecture Docker images & static executables through our continuous integration pipeline.

However, we’ve only recently started reaching out to and engaging with SPOs. A few brave souls responded positively and are already deploying and monitoring Amaru in their environments. This is a workstream that needs to be continued, especially as we finalize the networking stack and the work around the mempool.

🟠 Networking: Inbound & outbound discovery

• Full Node-to-Node Protocols: Implementation of Cardano's handshake and node-to-node protocols:

  • 🟢 chain-sync (initiator & responder)
  • 🟢 block-fetch (initiator & responder)
  • 🟢 keep-alive (initiator & responder)
  • 🟠 tx-submission (initiator); the responder side is u nder development.
  • 🔴 peer-sharing not implemented yet

• Static Network Topology: Amaru currently supports only a static network topology (albeit from multiple peers) and no peer selection. This is sufficient for a variety of local use cases (e.g., powering a DApp), but not for qualifying as a proper relay.

Overall, the networking stack has experienced unforeseen delays due to a lack of resources, mainly because everyone was busy with other tasks. We have been focusing on aspects that could make Amaru usable, while leaving dynamic peer-to-peer management and peer sharing for later.

We are also currently hardening network protocols by implementing buffer limits and strict CBOR parsing rules, as per the networking specifications produced by the Haskell team.

Block Producing Node (initial target: Q3 2025)

🟢 Consensus: Chain validation

• Chain Selection: Implementation of the Ouroboros chain selection algorithm using an optimized data structure for header storage and on-disk navigation.
• Full Header Validation: Complete support of VRF/KES cryptographic verifications and checks, including the stake-based leader schedule of Cardano.

🟠 Ledger: Full Validations

• Remaining Ledger Rules: As mentioned above, some (straightforward) ledger rules remain. We have de-risked the most critical rules to ensure no “unknown unknowns” remain, but we still need to address the simple checks we left behind for time's sake.

• Ledger Store Refinement: We have been implementing Amaru’s ledger store based on an initial design that has shown some shortcomings over time. We’ve been waiting to get the full picture before attempting to re-design some of it to address those shortcomings. We now have a clear path for the changes we require, but they haven’t happened yet.

⬜️ UTxO RPC: Use case implementation

As previously indicated, the UTxO RPC work item has been deprioritized and eventually dropped. We want to achieve similar outcomes by integrating with middlewares that provide a variety of functionalities, including UTxO-RPC support.

🟢 Public Testnet Validation

• Continuous e2e tests: We have been continuously synchronizing the Amaru chain across Haskell peer instances on both testnets (Preview and Preprod), as well as private node clusters. Every header is validated, and the state at the end of every epoch is compared with that of a Haskell node.

• Real-World Deployments: Many team members are running (so far, read-only) Amaru nodes connected to Mainnet, Preview, and Preprod. Some SPOs are also integrating Amaru into their stacks, connected to production-grade monitoring systems. The Pi examples at the summit were another occurrence of such real-world deployments.

🔴 Mempool: Complex mempool implementation

We’re running late on our mempool implementation. One of the key reasons is the various discussions happening around Ouroboros Leios. A large chunk of the work about Leios revolves around the mempool and the rapid re-validation of transactions.

Since the design of (Linear) Leios is still an ongoing discussion, we’ve been de-prioritizing this chunk of work as well, so that we can focus on delivering a Leios-ready mempool from the start.

🔴 Block production

Without an adequate mempool and without peer management at the networking level, the block production makes little sense. Given the delays we’ve had on the networking side, we’ve been postponing the implementation of the block-production capabilities while focusing on other elements further down the path (performances, observability, etc.).

Also, given recent events on Mainnet, we think it is important that we only allow block production once we are extremely confident that the risk of Mainnet’s operation is as low as possible. We have identified areas that require more testing and hardening. It’s also important to keep in mind that often, hardening benefits both Amaru and the Haskell cardano-node (we have discovered and reported bugs in the past that could have impacted Mainnet).

Soft-forks & performance improvements (initial target: Q4 2025)

🟠 Soft forks

There have been several discussions around that topic during the node diversity workshops, and a genuine motivation from all node implementors to coordinate and collaborate on future updates.

Yet there is still no clear plan for the form this will take. So for now, this remains a work in progress at the exploratory phase.

🟢 Performances

• Continuous Performance Analysis: We continuously monitor Amaru’s internal performance (heap analysis, resident memory usage, CPU usage, I/O reads & writes, …) and seek ways to reduce bottlenecks and further optimize operations.

• ⭐️ Amaru on Pi: We attended the 2025 Cardano Summit and set a challenge to ourselves: make people feel what low hardware requirements mean by deploying Amaru on constrained hardware:

  • Low memory usage: we deployed Amaru on a variety of Raspberry Pis, down to the Pi Zero (with only ~400 MB of available RAM).
  • Low energy: we showcased Amaru's energy efficiency by powering it for hours using small batteries (~5000 mAh).
  • First-class ARM: We demonstrated how Amaru can run on native ARM – an architecture often desired by SPOs.

• 🟢 UPLC Benchmarks: Validating Amaru’s Virtual Machine performances

  • Plutus benchmarks: Implemented the benchmarks suite from the Haskell Plutus team, comparing results with the Haskell implementation, ensuring better or similar performances.
  • “Turbo” benchmarks: Implemented the benchmarks suite created as part of the TurboCardano project, obtained by sampling real-world smart contracts on mainnet across all Plutus versions.

Truth is, we are already satisfied with Amaru’s current performances. While we haven’t yet deeply explored more performance-intensive paths, the (conscious) design choices we’ve made along the way have led to good-enough performance out of the box.

In 2026, we want to dedicate time to look even further into it, while preserving data integrity and without ever cutting on security considerations.

🟢 Better Operator Interface

We have already implemented an interesting set of capable monitoring tools that integrate nicely with industry-grade observability stacks:

• 🟢 Structured Tracing: Integration of structured tracing, logging, and metrics exported using OpenTelemetry.
• 🟢 Metrics: Collection of detailed metrics for all stages compatible with existing tooling (e.g. gLiveView).
• 🟢 JSON logs: Support for structured logs for analysis and debugging.
• 🟢 Distributed Spans: Tracing of operations across different stages.
• ⭐ Amaru doctor: A TUI for inspecting Amaru's internals and visualizing execution.

🟠 However, the work around metrics and tracing will only truly be completed after several rounds of feedback with SPOs running and monitoring the live system. Based on conversations we had with SPOs, we also intend to deliver more SPO-specific command-line tools (such as ways to craft on-chain updates to pool parameters or on-chain votes on governance proposals).

Workflow

🟢 Transparent Development & Treasury Management

• Entirely open source: Amaru is an open-source project whose source code currently lives on GitHub, with an active community conversing on PRAGMA’s Discord. We also have a development log that records daily activities and explorations continuously.

• Public meetings: bi-weekly (public) maintainer committee meetings for alignment, progress report and Q&A.

• Public demos: bi-monthly (public) touchpoints with presentations and live demos from developers to showcase visible deliveries:

  • 2025/11 | Simulating executions and pre-summit preparation
  • 2025/09 | More ledger rules, distributed traces and conformance testing
  • 2025/06 | Ledger rules, time travelling & node-to-node conversations
  • 2025/03 | Deterministic simulations, ledger rules & P2P Networking
  • 2025/02 | Stake distribution, multi-chain consensus & simulation testing
  • 2024/12 | On-disk ledger state & observability
  • 2024/10 | First steps: Simple peer-to-peer network with a single block producer

• Treasury smart contract: A fully audited, deeply tested and open-source treasury smart contract.

• Public financial journal: A public journal updated regularly with payouts and delivered milestones from contributors.

• Website: Information, documentation and progress on Amaru are now available at amaru.global.

🟢 Legal Framework

• Framework: a legal framework and contract setup that allows the Amaru Maintainer Committee to use ADA withdrawn from the treasury to pay contributors in fiat currencies.
• Milestone-based: every contract has a milestone-based and deliverable-oriented schedule, to map invoices explicitly to the agreed budget and timelines;
• Self-administered: payouts are initiated by each scope owner, then reviewed and accepted by the maintainer committee; Everything is assisted by the on-chain treasury smart contract.
• Transparency: full transparency of every payout, visible on-chain and recorded in the (public) financial journal.

⭐️ Node Diversity Workshop(s)

We organised and fully funded the second Node diversity workshop in Toulouse. With it, we continued building a constructive dynamic to make Cardano more resilient and to create a common, collaborative environment for node implementors.

Conclusion

We are immensely proud of what our team has accomplished and delivered in a short timeframe, and we remain conscious that we had to make adjustments to the initially projected roadmap. We spent more time than anticipated on coordination and establishing a work environment for our project contributors.

With these necessary prerequisites now out of the way and thanks to the massive progress we’ve made, mainly in the ledger and consensus areas, we’re confident in our ability to deliver on the next steps. We firmly believe that Amaru demonstrates not only that an alternative Cardano node implementation is possible, but also that it can deliver significant performance, testability, and maintainability improvements.

There’s no more doubt that Amaru contributes to the decentralization and resilience of the Cardano ecosystem.