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: Blink Labs, Cardano Foundation, dcSpark, Sundae Labs, and TxPipe. Each of them has a proven track record of building on Cardano and supporting our ecosystem.

Amaru itself is managed by an appointed maintainer committee in charge of different scopes. The current maintainer committee comprises of:

• Arnaud Bailly responsible for the consensus and simulation testing.
• Matthias Benkort responsible for the ledger & overall architecture.
• Pi Lanningham responsible for the ad hoc work and middleware integrations.
• Santiago Carmuega responsible for the p2p networking.
• Damien Czapla responsible for the project management, public relations & marketing.

Each member of the maintainer committee is in charge of a scope and has oversight on its delivery, which includes managing an associated budget.

Why build another node

One of Cardano's key assets is its legendary robustness and stability, which is mainly attributed to the existing Haskell node, which has been working without significant disruption for about five years now (counting since the Byron reboot, circa February 2020).

So why bother with another node? The answer is, of course, plural:

1. Better resource usage

Software is ultimately a collection of design decisions and trade-offs. Some of those trade-offs in the Haskell node have led to rather high resource usages (e.g., resident memory), thus leading to the creation of specific protocol parameters (e.g., min-utxo-value) as countermeasures to ensure resource usage remains somewhat bounded. Our analysis is that different (albeit acceptable) trade-offs would yield better resource usage.

2. Industry-grade observability

Observability is challenging, and it is even more so when rolling your own solution. With Amaru, we intend to embrace industry standards for monitoring, tracing, and logging to drastically enhance the user experience for operators seeking insights into their node's behaviour.

3. Enhanced interoperability

Amaru being primarily written in Rust means that we can more easily leverage an existing and thriving ecosystem of blockchain solutions and aim at multiple target platforms (e.g. web-assembly, RISC-V). This opens up not only to a wide variety of potential contributors but also to many new use cases that are much harder (not to say unrealistic) to achieve with a Haskell node.

4. Higher-assurance & robustness

Developing a new implementation of existing software means dissecting every part of the original implementation. Along the way, bugs and discrepancies with the specification are commonly found through conformance testing. Gaps in the documentation can also be identified and addressed. The development of Amaru has already proven this on several occasions. In the long run, more node implementations can be a synonym for reduced development time by allowing all implementations to converge faster towards better designs and more robust implementations.

5. Decentralization

In a world where Byzantine fault tolerance is at the centre and where decentralization is a paramount value, we believe that a single-node implementation presents a single point of failure and a central point of control. A new node not only increases the overall resilience of the network but also provides perspectives in terms of a roadmap and use cases.

---

With Amaru, we believe that we can reconcile these goals while preserving Cardano's focus on security and robustness. Like Haskell, Rust is a statically typed language that provides strong compile-time guarantees and fine-grained memory management. Its ecosystem is also well-equipped for high assurance, making it a sane choice for implementing blockchain solutions.

Executive summary

NOTE

All the scopes described are estimated in FTE (Full Time Employee) valued at $200k per annum.

Amaru is an ongoing project that is already a few months old, and resources have initially been allocated to bootstrap its development. Given the core nature of Amaru and in order to avoid becoming financially dependent on a single entity for its development, we are seeking ₳1.5M of additional funding for the second half of 2025.

The table below breaks down the current/estimated effort, the fraction of resources already secured from other sources of funding, and the resources needed. It covers the whole of 2025.

Scope	Owner	Estimated effort	Resources already secured	Resources needed
Ledger	Matthias	2.5 FTEs	1 FTE	1.5 FTEs
Consensus and simulation	Arnaud	2.5 FTEs	1 FTE	1.5 FTEs
Networking	Santiago	1 FTE	1 FTE	0 FTEs
Ad-hoc Mercenaries	Pi	2.5 FTEs	0 FTEs	2.5 FTEs
Project Management, Public Relations & Marketing	Damien	0.5 FTEs	0 FTEs	0.5 FTEs

The total resources without funding for 2025 adds up to 6 FTEs. Considering this budget ask is only for the second half of 2025, it halves to $600,000 (600K) once converted to USD ($). We then add a 25% contingency budget to cope with our optimistic bias: we are aware that our forecast is subject to underestimating complexity, overlooking challenges, and undervaluing the time and cost required to deliver.

With this contingency, we end up at $750,000 (750K). Finally, using a conservative conversion rate of 0.5 ADA (₳) per USD ($) at the date of the withdrawal, we formulate a budget of ₳1,500,000 (1.5M).

NOTE

The Networking scope described in our design documentation is included in our proposal for reference but is already covered by a Catalyst proposal. It is fully managed by Santiago.

Administration of the budget

The Amaru maintainer committee will ensure direct administration of the budget, assisted with an on-chain smart contract (developed in open source, still incomplete, but aimed to be done and fully audited by the time of the first withdrawal).

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

In addition, the smart contract's role is to ensure that the expenditure of funds is done in accordance with the scope defined in this budget and authorized by the relevant scope owners.

We recognize the following capabilities of this contract:

1. Standard withdrawal: A scope owner asks other scope owners for money to be withdrawn from his scope.
2. Contingency withdrawal: A scope owner asks other scope owners to withdraw an amount from the contingency funds.
3. Scope reconciliation: A scope owner asks other scope owners for a change of ownership (or a reallocation of budget).
4. Contingency refund/closing: scope owners ask to send the leftovers from the contingency budget to be sent back 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 would be irremediably lost, thus preventing any further decision, a failsafe mechanism allows all unconsumed funds to be sent back to the Cardano treasury.

Reporting

Quarterly reports

Following PRAGMA's Decision Record 006, progress on Amaru shall be at least 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 recurrent interaction will provide an overview of the project with a long-term perspective and support the maintainers' committee in aligning priorities and identifying the next steps. The outcome of these reviews will be publicly available as documentation in Amaru's GitHub repository.

Regular demos

Amaru is demo-driven. We strive to integrate early and provide runnable examples showcasing the latest features as the project is being developed. The cadence for these demos is around 4 to 6 weeks, as illustrated on the existing track record.

We will naturally continue to record and post demos regularly.

Constitutionality checklist

Being one of the first proposals of this nature ever submitted, it is easy to get things wrong. In an effort to convince ourselves of its constitutionality, we thought relevant to include a checklist of the points we cover and for each, our interpretation of the Cardano Constitution.

Purpose

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

Article III.5: the process of on-chain governance

• We have submitted this proposal in a standardized, legible format, which includes a URL and hash of all documented off-chain content. We believe our rationale to be detailed and sufficient. The proposal contains a title, abstract, reason for the proposal and relevant supporting materials.

Article IV.1: proposing budgets

• This proposal accords with the provisions of this article as it is intended to cover the maintenance and future development of the Cardano Blockchain.

• This proposal covers a shorter period than 73 epochs, which is permitted in this section of the Constitution, to match the Net-Change Limit period.

Article IV.2: funds administration

• 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, meeting the requirements of this clause, which requires a process that may include an administrator.

Article IV.3: Net-Change Limit

• Being of ₳1.5M and covering the second half of 2025, this proposal and the treasury withdrawals it would enable do not violate the currently agreed upon Net-Change Limit.

Article IV.4: Auditor

• This proposal makes provisions for an auditor (covered by the Ad-hoc mercenaries scope).

Guardrails

• This proposal is subject to TREASURY-04a in that it defines a Cardano blockchain ecosystem budget. It requires a threshold greater than 50% of the DReps' active voting stake to be considered approved and enable subsequent withdrawals pertaining to this budget.

Conclusion

The Amaru project represents a major step towards node diversity through the development of 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.

In addition to this budget, we provide a detailed document outlining:

• explicit assumptions about the project, the valuation and the scopes covered;
• comparisons to similar projects of developing blockchain nodes; and
• the methodology used for managing the project, its deliveries, its finance and its governance.

Through rigorous design and execution phases, we have outlined actionable scopes, realistic timelines, and comprehensive resource allocations. The detailed breakdown of scopes, funding and resources already secured reflects our commitment to transparency and efficiency. While we remain optimistic about our forecasts, we acknowledge the complexities involved and have incorporated contingencies to address unforeseen challenges.

More than a mere budget, this proposal is an invitation to collaborate and innovate together. The Amaru project is ambitious yet achievable through the collective effort of our contributors and the broader Cardano community. By focusing on building, learning, and demonstrating tangible progress, Amaru paves the way for a more resilient and decentralized Cardano ecosystem, ensuring long-term reliability and innovation.

Let's build the future of Cardano together.