## Team & Budget Administration ### Who we are [Amaru](https://github.com/pragma-org/amaru) is a multi-entity effort that currently sits under [PRAGMA](https://pragma.io): 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](https://github.com/Dam-CZ) - **Core development**, managed by [Matthias Benkort](https://github.com/KtorZ) - **Network compliance & Cardano-level Testing**, managed by [Paolo Veronelli](https://github.com/paolino) - **Middleware integrations**, managed by [Pi Lanningham](https://github.com/Quantumplation) In addition to the scope owners who constitute the maintainer committee, [many great developers](https://amaru.global/about/) have been relentlessly contributing to Amaru, among them [Julien](https://github.com/jeluard), [Arnaud](https://github.com/abailly), [Joshua](https://github.com/yHSJ), [Geoff](https://github.com/geofflittle), [Eric](https://github.com/etorreborre), [Stevan](https://github.com/stevana), [Lucas](https://github.com/rvcas), [Roland](https://github.com/rkuhn), [Jonathan,](https://github.com/jonathanlim222) and [Ethan,](https://github.com/rrruko) to name a few. ### Budget Administration The [Amaru](https://github.com/pragma-org/amaru) maintainer committee will ensure **direct budget administration**, assisted by an [on-chain smart contract](https://github.com/pragma-org/amaru-treasury). The fund management, responsibilities, and remuneration of contributors will follow PRAGMA’s legal framework, as provided in the annex under [PRAGMA Maintainer Committee Framework](https://ipfs.io/ipfs/bafkreiabxyva5lfm6zztg7tnktxvvbbucljrce7hlrp4p6hropqzfaip3y). 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](https://github.com/pragma-org/PDRs/tree/main/PDR-0006-Project-Reporting), progress on [Amaru](https://github.com/pragma-org/amaru) shall be **reported quarterly**. The content of [these reports](https://pragma.io/projects/amaru#quarterly-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 ![2025_12_15_Amaru_Scopes_v2](https://hackmd.io/_uploads/SycbJixQbe.jpg) | Scope | Estimated (FTEs) | Already Funded (FTEs) | Asked (FTEs) | Fixed costs ($) | | :--- | ---: | ---: | ---: | ---: | | Core Development | 5 | 1.5 | **3.5** | `$500k` | | Operations & Use cases | 2.5 | 0.5 | **2** | `$130k` | | Network Compliance & Cardano-level Testing | 1.5 | 0.5 | **1** | `$500k` | | Middleware Development | 2 | 0 | **2** | `$0` | | | | | | | | **Total** | _11 FTEs_ | _2.5 FTEs_ | 8.5 FTEs | `$1.13M` | 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](ipfs://bafybeidrfx7yxy54xg7crp2n4s2uxflmxaafebf5py4xi2ze75nya3sp5a) is available in annex. ### Total Ask ![2025_12_15_Amaru_Scopes_final](https://harlequin-able-tick-937.mypinata.cloud/ipfs/bafkreihxhyv7sm4wamfjxhvgkplmdgfjtqtglykn3rooq3yydstawvpqei) #### 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](github.com/pragma-org/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](ipfs://bafybeidrfx7yxy54xg7crp2n4s2uxflmxaafebf5py4xi2ze75nya3sp5a) 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](ipfs://bafybeidrfx7yxy54xg7crp2n4s2uxflmxaafebf5py4xi2ze75nya3sp5a) 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](https://explorer.cardano.org/governance-action/gov_action1m3xx08yv788vfxqh6nfvrjtvmqpwezsy0ggaczctkyjmttc2wmxsq4jsr7q) 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](ipfs://bafybeidrfx7yxy54xg7crp2n4s2uxflmxaafebf5py4xi2ze75nya3sp5a); 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](https://github.com/pragma-org/amaru-treasury/tree/main/journal) 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](https://github.com/pragma-org/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](ipfs://bafkreihjsdpolefycwjt75nnslqdbweu5pcyffzv6pjuknpc7bldmp2ch4) 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](ipfs://bafybeidrfx7yxy54xg7crp2n4s2uxflmxaafebf5py4xi2ze75nya3sp5a) 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](https://github.com/pragma-org/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 | 🎯 Main Objective | Owner | | --- | --- | | To reach feature parity with the Haskell node and keep up with the updates on the Cardano network/protocol | [Matthias Benkort](https://github.com/KtorZ) | #### 📦 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) | Indicator | Target | | --- | --- | | Ledger rules coverage (via acceptance test scenarios) | 100% | | Fuzzers coverage for serialisation / deserialisation of primitive types (c.f. CDDL) | 100% | | Resident memory usage | <1GB | | Average CPU Usage | <1% | | Block diffusion time (fetch + validation + sharing) | <1s | | Acceptance time to mempool | <100ms | | Manageable network peers | >10 | ##### 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) | Indicator | Target | | --- | --- | | Coverage of the new Plutus builtins in tests and benchmarks | 100% | | Single-script evaluation (turbo-benchmark) | <2ms | | Readiness before hard fork point | >1 week | ##### 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) | Indicator | Target | | --- | --- | | Resident memory usage | <1GB | | Average CPU Usage | <1% | | Block diffusion time (fetch + validation + sharing) | <1s | | Acceptance time to mempool | <100ms | | Missed slots when leader (excluding slot battles) | 0 | ##### 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) | Indicator | Target | | --- | --- | | Resident memory usage | <1GB | | Average CPU Usage | <1% | | Block diffusion time (fetch + validation + sharing) | <1s | | Acceptance time to mempool | <100ms | | Missed slots when leader (excluding slot battles) | 0 | | Unpatched major security vulnerabilities or major defects | 0 | | SPO (i.e. users) satisfaction | >80% | ##### 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 | 🎯 Main Objective | Owner | | --- | --- | | To facilitate operations & management of the project and pursue interesting use cases. | [Damien Czapla](https://github.com/Dam-CZ) | #### 📦 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) | Indicator | Target | | --- | --- | | Time to setup and 'get started' without help | <1 day | ##### 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) | Indicator | Target | | --- | --- | | Node implementations represented | >50% | | Attendees satisfaction | >80% | | Effectiveness at 6 months (completed actionnable items / total items) | >50% | ##### 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) | Indicator | Target | | --- | --- | | Time to setup and 'get started' with running a node in-browser | <1 day | | Block validation (fetch + validation) | <1s | | Supported browsers | Chrome >= v143 | ##### 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) | Indicator | Target | | --- | --- | | % of operational procedures documented and integrated in the UI | >80% | ##### 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) | Indicator | Target | | --- | --- | | Retention/conversion rate (bounty hunters turned contributors) | >25% | | Relevance of submission (number of valid submissions / total number of submission) | >50% | ##### 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) | Indicator | Target | | --- | --- | | Node implementations represented | >3 | | Attendees satisfaction | >80% | | Effectiveness at 6 months (completed actionnable items / total items) | >50% | ##### 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) | Indicator | Target | | --- | --- | | Unforeseen incidents | 0 | ##### 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) | Indicator | Target | | --- | --- | | Resident memory usage | <1GB | | Average CPU Usage | <1% | | Block diffusion time (fetch + validation + sharing) | <1s | | Ledger throughput (no consensus) | >100 tx/s | | Time to benchmark from any release | <1 day | ##### 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) | Indicator | Target | | --- | --- | | Reliability ($rac{ ext{% delivered on schedule}}{ ext{% late or undelivered}}$) | 100% | | Forecast accuracy ($rac{actual - estimate}{estimate}$) | ~0 | | Scope creep rate ($rac{ ext{total unplanned}}{ ext{total done}}$) | 0% | ##### 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) | Indicator | Target | | --- | --- | | Social media engagement rate ($rac{likes + shares + comments}{impressions}$) | >2% | | Posting frequency | >once a week | | X organic followers | +100% | ##### 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 | 🎯 Main Objective | Owner | | --- | ---| | To create a robust Cardano network level testing environment, find vulnerabilities, edge cases and interesting scenarios to make the Cardano network more resilient in the long-run. | [Paolo Veronelli](https://github.com/paolino) | > **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) | Indicator | Target | | --- | --- | | Utilization of the Antithesis cluster (idle time / total time) | >25% | | Manual tests ratio (test runs done manually vs triggered via on-chain transactions) | 0% | ##### 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) | Indicator | Target | | --- | --- | | % of automated tests passed against reference test suite | 100% | | MTTR (Mean Time To Recover) from found vulnerabilities | <48h | | Open Critical Vulnerabilities | 0 | ##### 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 | 🎯 Main Objective | Owner | | --- | --- | | To drive integration of Amaru into relevant and most-used infrastructure middleware and tools in the ecosystem. | [Pi Lanningham](https://github.com/Quantumplation) | > **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](https://github.com/CardanoSolutions/kupo) and [Dolos](https://github.com/txpipe/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) | Indicator | Target | | --- | --- | | API Coverage | 100% | | Synchronization time (mainnet, full index, from snapshot) | <16h | ##### 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](http://github.com/input-output-hk/mithril) client in Amaru to ease bootstrapping and offer a seamless entry point to the Cardano network. - Integrate an optional [Mithril](http://github.com/input-output-hk/mithril) signer in Amaru to provide out-of-the-box participation to Mithril’s security. ##### Key Performance Indicators (KPIs) | Indicator | Target | | --- | --- | | % total stake running Mithril signers via Amaru | 5% | ##### 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](https://pragma.io/projects/amaru/#journey) 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](https://github.com/cardano-scaling/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](https://antithesis.com) 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,](https://github.com/pragma-org/amaru-treasury) with an active community conversing on [PRAGMA’s Discord](https://discord.gg/q5XZMZhrUY). We also have a [development log](https://github.com/pragma-org/amaru/wiki) 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](https://pragma.io/projects/amaru/#Deterministic%20simulations%2C%20ledger%20rules%26%20%20P2P%20Networking) - [`2025/09` | More ledger rules, distributed traces and conformance testing](https://pragma.io/projects/amaru#More%20ledger%20rules%2C%20distributed%20traces%20and%20conformance%20testing) - [`2025/06` | Ledger rules, time travelling & node-to-node conversations](https://pragma.io/projects/amaru#Ledger%20rules%2C%20time%20travelling%20%26%20node-to-node%20conversations.) - [`2025/03` | Deterministic simulations, ledger rules & P2P Networking](https://pragma.io/projects/amaru#Deterministic%20simulations%2C%20ledger%20rules%26%20P2P%20Networking) - [`2025/02` | Stake distribution, multi-chain consensus & simulation testing](https://pragma.io/projects/amaru#Stake%20distribution%2C%20multi-chain%20consensus%20%26%20simulation%20testing.) - [`2024/12` | On-disk ledger state & observability](https://pragma.io/projects/amaru#On-disk%20Ledger%20State%20%26%20Observability) - [`2024/10` | First steps: Simple peer-to-peer network with a single block producer](https://pragma.io/projects/amaru/#First%20Steps) - **Treasury smart contract**: A [fully audited](https://github.com/pragma-org/amaru-treasury/blob/265918afa7dfc1e4daeb40b1b1ecfb2f4c995607/audit-report-2025-08-05-txpipe-shop.pdf), [deeply tested](https://github.com/pragma-org/amaru-treasury/blob/265918afa7dfc1e4daeb40b1b1ecfb2f4c995607/validators/permissions.test.ak) and open-source treasury smart contract. - **Public financial journal**: A [public journal](https://github.com/pragma-org/amaru-treasury/tree/265918afa7dfc1e4daeb40b1b1ecfb2f4c995607/journal#journal) updated regularly with payouts and delivered milestones from contributors. - **Website**: Information, documentation and progress on Amaru are now available at [amaru.global](https://amaru.global). #### 🟢 Legal Framework - **Framework**: a [legal framework](https://ipfs.io/ipfs/bafkreiabxyva5lfm6zztg7tnktxvvbbucljrce7hlrp4p6hropqzfaip3y) 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](https://github.com/pragma-org/amaru-treasury/tree/265918afa7dfc1e4daeb40b1b1ecfb2f4c995607/journal#journal). #### ⭐️ Node Diversity Workshop(s) We organised and fully funded the second [Node diversity workshop in Toulouse](https://forum.cardano.org/t/cardano-node-diversity-workshop-2-toulouse-22-23-september-2025/150304). 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.