DRep Votes
Epoch Snapshot 570
  • Total Stake: ₳ 12.52B
  • Yes Votes (Stake)
    ₳ 3.95B
  • Total No (Stake)
    ₳ 1.48B
    Explicit No
    ₳ 21.13M
    No Confidence
    ₳ 178.42M
    Not Voted
    ₳ 1.29B
  • Total Abstain (Stake)
    ₳ 7.08B
    Explicit Abstain
    ₳ 49.03M
    Auto Abstain
    ₳ 7.03B
  • Total Committee Members: 7
  • Yes Votes
    7
  • Total No
    0
    Voted No
    0
    Not Voted
    0
  • Abstain Votes
    0

Abstract

Amaru is an open-source project implementing a new fully interoperable block-producing node for Cardano. It aims to improve the network's overall accessibility and robustness without compromising its safety and security.

This treasury withdrawal of ₳1.5M follows a previously submitted and now approved budget proposal. It is split across five script addresses each covering a scope of a work (ledger, consensus, mercenaries and marketing) and a contingency reserve.

Motivation

Who we are

Amaru is a multi-entity effort that currently sits under PRAGMA: a member-based, not-for-profit association for open-source 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. Each member of the maintainer committee is responsible for a scope of work and has oversight of its delivery, which includes managing the associated budget. The current maintainer committee comprises of:

  • Matthias Benkort responsible for the ledger & overall architecture with a budget of 1.5 FTEs (₳300,000) until end of 2025.

Managing treasury at: stake17xnev6rc25xwz8kg4qae8lq6dcg964z00py5gqgxd387pncv8fq8g

  • Arnaud Bailly responsible for the consensus and simulation testing, with a budget of 1.5 FTEs (₳300,000) until end of 2025.

Managing treasury at: stake17xd74ehu0l4d5mx0sfz4fd0r5jvw4v2jqkkfyjxrlwvnkhccrqj9l

  • Pi Lanningham responsible for the ad hoc work and middleware integrations (a.k.a mercenaries) with a budget of 2.5 FTEs (₳500,000) until end of 2025.

Managing treasury at: stake17xrh74lqhhxgzelfsn0wq5kcm4e5dmluprlcpg5mq30p5yqhgk7k8

  • Damien Czapla responsible for the project management, public relations & marketing with a budget of 0.5 FTE (₳100,000) until end of 2025.

Managing treasury at: stake17xrqac8khkprtpp2jz90mpkujjwye8dt6a9sjewrvjudx9ggg4u5y

  • Santiago Carmuega responsible for the p2p networking. Santiago oversees no part of the treasury budget whatsoever related to Amaru in 2025. The networking's funding has been fully secured through other mechanisms.

Additionally, Arnaud, Matthias, Pi and Damien are collectively responsible for the contingency scope with a budget of ₳300,000 until the end of 2025, corresponding to 25% of the sum of all other budgets as outlined in the budget proposal.

The contingency treasury's stake address is: stake178jztxzwynajcp4dva5gy9udmmnwg7ueffvf4c7hpjqhc7gtj5nzz


In total, we request ₳1,500,000 (1.5M ADA).


NOTES

  1. Efforts are estimated in FTE (Full-Time Employee) valued at $200K / ₳400K per annum.

  2. As outlined in the initial budget proposal, the withdrawal requests only account for resources that aren't currently covered by other means (e.g. sponsorship, employee payroll, Catalyst, ...). In particular, every scope owner highlighted above is fully covered outside of this withdrawal.

Building an alternative node

Amaru provides an alternative perspective and solution for both stake pool operators and developers, prioritizing a modular approach, a seamless user experience, and low hardware requirements. Additionally, the project is primarily implemented in Rust, which is well-suited for high assurance, thereby attracting new contributors to the core maintenance of the ecosystem.

For more details, please refer to the budget proposal which already covers in great length the project, its goals, its deliverables and its methodology

Why request funds from Cardano's treasury

Decentralized core infrastructure

Block-producing nodes (a.k.a. stake pools) and relays are at the heart of Cardano's infrastructure. Together, they constitute and support the Cardano network. Amaru aims at offering an alternative piece to this core infrastructure, thus becoming part of this core infrastructure. We firmly believe that decentralizing the core infrastructure—without disrupting its operational resilience—is a necessary step toward a more robust and secure network.

Additionally, supporting the blockchain base layer should be a shared responsibility. Stakepool operators already share the burden of operating the network, and it is time to share the responsibility for its development and technical evolution. Amaru makes a significant leap in sharing this responsibility, not only by incrementally delivering a capable block-producing node for the network but also by paving the way for those who come after through documentation, conformance tests and engineering specifications.

By its very nature, Amaru is a project that aligns with Cardano's vision. As a core infrastructure component, it is also challenging and undesirable to articulate a business model around the project without compromising its essence. We believe that because of these reasons, Amaru qualifies for treasury withdrawals.

Open source & neutrality

The project is, of course, open source. We have linked the code repository throughout this document and referred to it also in the original budget proposal. As outlined in the budget proposal, not only is the code public, but the project's progress, evolutions, and decisions are also publicly available. The team strives to remain accessible through public forums and regular touchpoints open to all.

The core team comprises individuals from various entities and backgrounds. And, while not obvious, this is a situation very dear to us. To preserve Amaru's neutrality and openness, we must ensure that core contributors are not tied to a single actor. Cardano's treasury offers a perfect solution to this problem as it virtually represents a source of funding that is everyone and no one at the same time.

Receiving funding from the Cardano treasury makes the Amaru team accountable towards the Cardano community. It turns the Cardano community into our ultimate stakeholder, which is both good and desirable for a project of this nature.

Rationale

Administration of the budget

The Amaru maintainer committee ensures direct administration of its budget, assisted by an on-chain smart contract. Off-chain, the fund management, responsibilities and remuneration of contributors follow PRAGMA's Maintainer Committee Framework. Additionally, the smart contract's role is to ensure that funds are expended under the scope of work defined in this budget and authorized by the relevant scope owners.

Our final solution is built as an extension of the treasury management contract presented by Sundae Labs in the context of a mission for Intersect. Our additions enable, most importantly, the dynamic definition of scope owners and their adjustment if necessary (e.g., key loss, departure, death) upon approval by the PRAGMA general assembly (requiring 5 signatures out of 5 members).

While already extensively tested, our final solution is still being audited at the moment of writing this proposal. We do not wish to rush the auditors or take any risk regarding treasury management.

However, due to time constraints stemming from the need to continue paying contributors whose payroll expires in the upcoming weeks, we have decided to proceed with a simplified setup and migrate to our final setup once it is ready.

The simplified setup relies entirely on the initial solution designed and developed by Sundae Labs, which has been extensively tested and fully audited by two independent parties (attached as external references to this proposal). We have also audited, tested and experimented with this solution on our own.

Initial setup

We define 5 Amaru treasuries: one for each scope of work and one for the contingency budget.

The same smart contract governs each treasury, although it is configured differently in each case. It ensures funds coming from either UTxOs or reward accounts move according to specific operations with a precise semantic:

  • reorganize: allows for the collection and combination of multiple sources (e.g., multiple UTxOs) into another distribution with at least as many assets. This action is typically used to consolidate multiple UTxOs into a single one for easier treasury management.

  • sweep: after an agreed-upon expiration date, allows sending all ada leftovers (unconsumed budgets) back to the Cardano's treasury. Any native asset (e.g. USDM) is kept within the contract. The action can also be triggered at an earlier stage through a specific authorization.

  • disburse: allow payment of funds (ada or native assets) into an arbitrary address, up until the budget's expiration date. Only native assets can be disbursed beyond the expiration date to allow converting them back to ada.

  • fund: disburse funds into another set of on-chain validators ('vendors') pre-configured with a payment schedule. We will not make use of this operation. It is fully disabled in our setup. Disbursement will only happen through the disburse action.

In addition to rules specified as part of the smart contract, each operation also defines a set of permissions. Permissions can take the form of a multisig or another script.

In the initial setup, we configure each treasury with permissions as follows:

  • The reorganize operation can be fully authorized by the respective scope owner alone. In the case of the contingency budget, any scope owner is capable of authorizing a 'reorganize' operation.

  • The sweep operation requires 3 out of 4 authorizations until the end of 2025. It can be performed by any ada holder after that date.

  • disburse operation requires 3 out of 4 authorizations until the end of 2025. Disbursement of ada is forbidden after that date.

  • The fund operation is entirely disabled using a permission setting that is impossible to satisfy.

Final setup

In a second phase, once the external audit has been finalized and our confidence in the contract is sufficient, we'll move towards our final vision for the 2025 budget management. This second solution is still smart-contract-based and builds upon the initial solution.

It is motivated by the desire to allow rotating credentials associated with scope owners to cope with two main issues:

  1. the loss of key from a scope owner;
  2. the departure of a scope owner from the project.

Relying on a rigid setup which statically defines the scope owners is risky and unpractical. So instead, we recognize the following additional capabilities to the final solution:

  • Credential rotation: In case of loss of credentials or departure of a scope owner, a mechanism allows rotating credentials to new scope owners upon approval by all (5 out of 5) PRAGMA members.

Financial audit

The 'ad-hoc' scope of work makes provision for a financial auditor who will be picked at a later stage.

To facilitate the work of the auditor, we will attach metadata with key 1694 to transactions spending from the smart contracts, in accordance with CIP-100.

Initial metadata describing each Initial Setup(s) have already been published and are visible on-chain.

Scope / Budget Transaction Id
Ledger cd25ce7b027fea4e28d5075691aa5822baa859bc74cc79db0377043bc9f383c7
Consensus e5be93f2530c51e0b1582e5a0e99ccb1235e4395a41c7196d06c4daea3eafe66
Mercenaries 0729a234e4e12b945f06189ca479681e49ffcc116fb3713720bada72180fe27c
Marketing 5697f433442317f04f539baecdf71fee01b3e8453c658a4d782648bc1e4f4490
Contingency 44ae2c263b2115023e4b137f718549fcac78c0a59b7983e918d9e79d1a503b3c

To further ease this process for the least technologically inclined, we will also collect in a publicly available journal an audit log of these transactions and a human-readable version of their metadata.

Constitutionality self-assessment

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

Purpose

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

Article III.5: on-chain governance process

  • [x] 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 includes a title, abstract, rationale for the proposal, and relevant supporting materials.

Article IV.1: budgets

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

Article IV.3: net-change limit

Article IV.4: auditor & contractual obligations

  • [x] This proposal makes provisions for a financial auditor (covered by the 'ad-hoc' scope). The auditor will be picked at a later stage, and their work will be facilitated through the publication of metadata alongside any movement of funds out of the smart contracts.

  • [x] Our off-chain legal framework knwon as PRAGMA's Maintainer Committee Framework makes provision for a dispute resolution for contractors receiving an allocation in the context of this treasury withdrawal. It explicitly states that Any dispute arising out of or in connection with this Agreement shall be subject to the jurisdiction of the ordinary courts of Zurich.

Article IV.5: vesting rules

  • [x] The use of intermediary smart contracts is used prior to any disbursement of funds to beneficiaries. In particular, we intend to attach on-chain metadata to facilitate financial audits.

  • [x] Our on-chain smart contract solution simultaneously enforces that:

    1. funds (at the contract) cannot be delegated to an SPO; and
    2. funds (at the contract) shall be delegated to an auto-abstain DRep.

Note that we cannot prevent others from creating undelegated UTxOs at the contract's address. Yet, the contract stipulates that the outputs of each operation (e.g., reorganize) carry delegation rights in accordance with this provision.

Guardrails

  • [x] TREASURY-01a - There's is currently an approved Net-Change limit of ₳350,000,000 finishing at the conclusion of Epoch 604 in December 2025.

  • [x] TREASURY-02a - At the moment of proposing this, there hasn't been any enacted treasury withdrawal for the current period covered by the Net-Change limit. Being of ₳1.5M, this withdrawal is, at the moment of proposing it, within the Net-Change Limit.

  • [x] TREASURY-03a - This withdrawal is denominated in ada.

  • [x] TREASURY-04a - This withdrawal follows a budget proposal that the DReps have agreed on with a threshold of greater than 50% of the active voting stake.

Notations & definitions

  • We denote 'ADA' as throughout this proposal. We may use either notation interchangeably.

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.

This withdrawal aims to clearly outline a transparent budget management process, leveraging the capabilities of our chain to enforce this process as reasonably possible in the given timeframe.

Being an ongoing project, Amaru comes with its own set of constraints. Yet, we try our best to pioneer what we think could be one of Cardano's most pivotal moments.

References

Proposal Information
  • Type
    Treasury Withdrawal
  • Status
    Enacted
  • Submitted On
    Jun 25, 2025
  • Enacted On
    Jul 18, 2025
  • Proposal Tx
  • Voting Parties
    DRepCC