Amaru Treasury Withdrawal 2026
155 DReps voted · 51 with a rationale
Open a row to read the rationale.
- Yes 733.1K ₳ Rationale
Vote: YES.
This proposal supports innovation and client diversity, both important for the long-term resilience of the Cardano protocol and our blockchain ecosystem. - Yes 717.1K ₳ No rationale
- Yes 654.5K ₳ Rationale
📌 CARDANO TREASURY VOTE: AMARU NODE DEVELOPMENT — I VOTE YES
Cardano governance is currently voting on an important proposal:
Amaru Treasury Withdrawal 2026.This proposal funds the development of Amaru, an alternative Cardano node implementation written in Rust.
Requested budget:
₳10,142,000 ADA for development during 2026.As a DRep, I am voting YES.
👉 What Amaru is
Amaru is a new implementation of a Cardano node.
Today the network primarily relies on cardano-node (Haskell).
That means the network effectively depends on a single implementation of the protocol.Amaru introduces a second independent node, which can:
• increase network resilience
• strengthen decentralization
• reduce systemic risk
• attract new developers to the ecosystem
⚙️ Why this matters
In blockchain infrastructure, node diversity is critical.
If a network relies on only one implementation, it creates a monoculture risk.
A critical bug in that implementation could potentially affect the entire network.
Multiple implementations increase resilience.
This approach already exists in other major networks:
• Bitcoin Core
• btcd
• LibbitcoinDifferent implementations of the same protocol make the system more secure and decentralized.
💻 What the project plans for 2026
The Amaru team plans to deliver:
• Q1 — production-ready relay node
• Q2 — block-producing node
• Q3 — mainnet readiness
• experiments with new protocols such as Leios, Peras, and Phalanx
• integrations with Mithril, StarStream and L2 infrastructureThe project also focuses on low hardware requirements, enabling nodes to run even on constrained devices.
This can increase the number of operators and further decentralize the network.
💰 About the budget
Total request: approximately $3M.
For Layer-1 infrastructure development, this is within a normal range.
Building and maintaining a blockchain node involves:
• cryptography
• consensus algorithms
• networking protocols
• security audits
• large-scale testingThis is core infrastructure for the entire network.
🗣 My position
I support this proposal and vote YES because:
• it strengthens Cardano’s network resilience
• it reduces dependency on a single node implementation
• it expands the developer ecosystem
• it improves decentralizationInfrastructure projects like this are long-term investments in the future of the network.
🖤 My DRep ID
➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jr
You can find me in governance search as MREDGARCROSS.
More details
https://t.me/PROCENT666/338
🚀 LEDGER COLD WALLET COURSE | METAMASK
https://edgarbagdasarian.justclick.ru/order/LEDGERMETAMASK🔥 PRIVATE VIP CHAT SUBSCRIPTION
https://t.me/MREDGARCROSS_BOT🌐 ALL COURSES AND LINKS
https://mredgarcross.com/📌 Note: This post is informational and analytical in nature. It does not contain calls for protests or unlawful actions. The views expressed are the author’s personal analysis.
- Yes 624.8K ₳ Rationale
I'm voting yes because Amaru addresses Cardano's most dangerous systemic risk: the absence of a viable alternative node implementation. This isn't a discretionary application-layer bet, it's load-bearing infrastructure work that directly strengthens network security, decentralization, and long-term resilience. Relying on a single Haskell-based node creates a single point of failure where any bug, design flaw, or operational incident can propagate across the entire ecosystem. Multiple independent implementations provide cross-verification, remove systemic bottlenecks, and ensure that protocol upgrades are battle-tested across different codebases before reaching mainnet. Amaru's work in 2025 already uncovered bugs that could have impacted mainnet, validating the need for this second implementation perspective.
The team demonstrated fiscal discipline by returning over 920,000 ADA in unused 2025 funds to the treasury rather than artificially spending down the allocation. Their use of audited smart contracts, public financial journals, milestone-based disbursement, and transparent contingency structures sets a benchmark for responsible treasury management that all funded projects should emulate. The 2026 roadmap represents a structured transition from foundational engineering to production readiness: relay node completion in Q1, block production capability in Q2, and external security audit before mainnet deployment. The budget breakdown is competitive enough at 8.5 FTEs plus $1.13 million in fixed costs (security audit, Antithesis testing infrastructure, node diversity workshops, bug bounty), with a contingency buffer designed to protect deliverability under adverse market conditions while being return-obligated to the treasury.
Amaru's Rust implementation prioritizes low hardware requirements and seamless user experience, reducing operational burden for SPOs as staking rewards decline and scaling upgrades like Leios increase node requirements. This supports continued participation from smaller operators and preserves decentralization in practice, not just theory. The proposal also emphasizes rigorous network-level testing, middleware integration with ecosystem tools (indexers, sync layers), and collaboration across stakeholders to ensure Amaru becomes operationally useful, and not just technically impressive. Node diversity is expensive and resource-intensive, but it's justified by the increased resilience and reduced monoculture risk it delivers. Withholding this vote means accepting permanent single-client risk incompatible with the Constitution's demands on security and decentralization. - Yes 601.8K ₳ No rationale
- Yes 589.2K ₳ No rationale
- Yes 559.5K ₳ No rationale
- Yes 521.2K ₳ Rationale
Vote: YES. This proposal advances Cardano’s decentralization and long-term resilience by funding an open-source, interoperable second block-producing node implementation, which I consider critical and non-negotiable. The delivery plan includes concrete milestones and KPIs, and the treasury administration model (smart-contract controls, public journaling, audits) aligns with transparent, accountable governance. The team has already demonstrated responsible handling of funds through moderate spending and returning unused funds to the treasury.
- Yes 481.5K ₳ Rationale
- Yes 473.6K ₳ No rationale
- Yes 466.2K ₳ No rationale
- Yes 445.1K ₳ No rationale
- Yes 438.7K ₳ No rationale
- Yes 409.3K ₳ No rationale
- Yes 382.6K ₳ No rationale
- Yes 377.3K ₳ No rationale
- Yes 324.4K ₳ No rationale
- Yes 321.1K ₳ No rationale
- Yes 314.4K ₳ Rationale
I have decided to vote YES on the Amaru 2026 Treasury Withdrawal proposal. My decision is based on my core principles of strengthening Cardano's resilience through technical diversity, while maintaining high expectations for transparency and accountability.
A PDF version of this rationale is also made available.
I have decided to vote YES on the Amaru 2026 Treasury Withdrawal proposal. My decision is based on my core principles of strengthening Cardano's resilience through technical diversity, while maintaining high expectations for transparency and accountability.
1. Critical Need for Node Diversity
A second, independent node implementation is not a luxury; it is a necessity for a mature digital nation. By developing a full block-producing node in Rust, the Amaru team is providing an essential safeguard against "single point of failure" risks that come from relying on only one codebase (Haskell). This directly aligns with my commitment to Greater Decentralization and Long-Term Vision, ensuring that the Cardano network remains secure and robust as it scales.
2. Transparency and Proven Track Record
I appreciate the honesty presented in the 2025 Retrospective. The team has documented where they succeeded and where they faced delays (such as in the networking stack and mempool development). This level of openness, combined with their use of on-chain smart contracts for budget administration and a public financial journal, sets a high standard for treasury-funded projects. I am voting in favor because I believe this team has the technical skill and the integrity to deliver on their 2026 roadmap.
3. Budgetary Concerns & "Conservative" Scrutiny
I must be honest: the costs associated with this proposal are significant. The Full-Time Equivalent (FTE) rate and the fixed costs for testing platforms are, in my view, very high. As a DRep who advocates for Sustainable & Justifiable Treasury Spending, I did not look at these figures lightly.
However, I recognize that:
- Attracting and keeping high-quality blockchain engineers requires competitive pay.
- Cutting costs on security audits or testing infrastructure would be a mistake for a project of this importance.
- The proposal includes a clear way to return unused funds (especially from the market volatility buffer) back to the treasury.
Closing Thoughts
Supporting Amaru is an investment in the future of our digital nation. While the cost is high, the value of having a more resilient and diverse ecosystem is far greater. I am excited to see how this project strengthens Cardano's already solid decentralized foundations and helps us build an even more unstoppable ecosystem together.
- Yes 298.6K ₳ Rationale
This budget is painful, but I think in the long term this will be wise. In late November of last year, a bug was identified in the node implementation. It was possible to create a poisoned transaction that would take advantage of the bug and wreak havoc on the network. Before a fix could be deployed, some MORON decided to send such a poisoned transaction to mainnet. Predictably, the transaction wreaked havoc and caused a network bifurcation. Within a day, a fix was deployed and the network was healing. All things considered, Cardano weathered the storm admirably. However, had Cardano been in widespread global adoption, like we aim to someday be, this would have been a financial disaster on the order of many billions of dollars of damage.
Node diversity likely would have greatly mitigated this bug's impact on the network. Assuming the Amaru node does not use the same serialization library as the Haskell one, Amaru could have made this a much smaller emergency.
Signed,
William DoyleYour friendly neighbourhood DRep!
- Yes 295.2K ₳ No rationale
- Yes 279.5K ₳ No rationale
- Yes 271.5K ₳ No rationale
- Yes 260K ₳ Rationale
Node diversity is critical for the long-term resilience and decentralization of Cardano. Funding Amaru strengthens infrastructure by introducing an alternative Rust-based node implementation, reducing single-client dependency risk.
The roadmap is clearly defined, includes security audits and transparency measures, and contributes directly to core protocol robustness.
- No 258.6K ₳ Rationale
`## Governance Action Review
Governance Action:
Amaru Treasury Withdrawal 2026I am voting NO on this Treasury Withdrawal at this stage.
This vote should not be interpreted as a rejection of the proposal itself or of treasury funding in principle. My concern relates primarily to the timing and coordination of treasury allocations under the current governance environment.
At present, the ecosystem still lacks a sufficiently clear view of the full pipeline of proposals that may seek funding within the current NCL window.
Approving Treasury Withdrawals before proposers have had a meaningful opportunity to participate in a broader coordination process risks reinforcing an uncoordinated funding dynamic, where requests are assessed in isolation rather than in relation to the wider ecosystem’s needs, trade-offs, and budget constraints. My concern is not with individual submissions as such, but with the absence of a more collaborative and comparative process through which scope, budget, and priority can be better optimized across the current funding cycle.
Given the expectation that Intersect’s budgeting process may surface a broader set of requests in the coming weeks, I believe a short delay would likely improve decision quality and reduce the risk of inefficient allocation.
Approving withdrawals too early may also create downstream pressure to expand the NCL in order to accommodate proposals that emerge later but may prove strategically more relevant.
This should not be read as an attempt to block funding or paralyze governance. The ecosystem has already had roughly a full year to learn from the weaknesses of the previous cycle and to build a more credible coordination layer for the next one. That response has progressed more slowly than it should have.
I was willing to accept greater urgency last year because continuity of development mattered and the system was still in an early transition phase. But if we never reach the point where dReps are willing to demand greater accountability, coordination, and rigor, then the ecosystem simply carries the same loose standards into yet another funding cycle.
I do not consider that acceptable after the time already available to improve the process.
For these reasons, I believe it is preferable to delay approvals temporarily rather than normalize allocation decisions under incomplete and uncoordinated information.
This vote reflects a preference for better coordination and prioritization of treasury spending, not opposition to the goals of
Amaru Treasury Withdrawal 2026.
Revisão de Ação de Governança
Ação de Governança:
Amaru Treasury Withdrawal 2026Estou votando NÃO nesta Treasury Withdrawal neste momento.
Este voto não deve ser interpretado como uma rejeição da proposta em si ou do financiamento via tesouro em princípio. Minha preocupação está principalmente relacionada ao timing e à coordenação das alocações do tesouro no atual ambiente de governança.
No momento, o ecossistema ainda não possui uma visão suficientemente clara do conjunto completo de propostas que podem buscar financiamento dentro da janela atual de NCL.
Aprovar Treasury Withdrawals antes que os proponentes tenham tido uma oportunidade real de participar de algum processo mais amplo de coordenação corre o risco de reforçar uma dinâmica de financiamento descoordenada, na qual pedidos são avaliados isoladamente, em vez de serem analisados em relação às necessidades mais amplas do ecossistema, aos trade-offs existentes e às restrições orçamentárias.
Minha preocupação não é com submissões individuais em si, mas com a ausência de um processo mais colaborativo e comparativo por meio do qual escopo, orçamento e prioridade possam ser melhor otimizados ao longo deste ciclo de financiamento.
Considerando que o processo de orçamento conduzido pela Intersect pode trazer à tona um conjunto mais amplo de solicitações nas próximas semanas, acredito que um pequeno atraso provavelmente melhoraria a qualidade das decisões e reduziria o risco de alocações ineficientes.
Aprovar retiradas muito cedo também pode gerar pressão posterior para expandir o NCL, a fim de acomodar propostas que venham a surgir depois e que eventualmente se revelem mais relevantes do ponto de vista estratégico.
Isso não deve ser interpretado como uma tentativa de bloquear financiamento ou paralisar a governança. O ecossistema já teve aproximadamente um ano inteiro para aprender com as fragilidades do ciclo anterior e desenvolver uma camada de coordenação mais sólida para o próximo ciclo. Essa resposta avançou mais lentamente do que deveria.
No ano passado eu aceitei um maior senso de urgência porque a continuidade do desenvolvimento era importante e o sistema ainda estava em uma fase inicial de transição. No entanto, se nunca chegarmos ao ponto em que os dReps estejam dispostos a exigir maior accountability, coordenação e rigor, o ecossistema simplesmente carregará os mesmos padrões frouxos para mais um ciclo inteiro de financiamento.
Depois do tempo que já tivemos para melhorar o processo, não considero isso aceitável.
Por essas razões, acredito ser preferível adiar temporariamente as aprovações em vez de normalizar decisões de alocação baseadas em informações incompletas e descoordenadas.
Este voto reflete uma preferência por maior coordenação e melhor priorização do gasto do tesouro, e não uma oposição aos objetivos da
Amaru Treasury Withdrawal 2026.` - Yes 238.2K ₳ Rationale
Vote: YES
Rationale:
Node diversity isn't optional infrastructure—it's foundational security. Cardano currently relies heavily on a single Haskell node implementation. A production-ready alternative in Rust (Amaru) creates network resilience against implementation bugs, attracts different developer ecosystems, and proves the protocol's specification is truly portable.
What convinces me:
Track record of fiscal responsibility: Returned ₳920k+ in 2025 leftovers to treasury. They underspent their first allocation and sent funds back—this is rare and signals genuine stewardship.
Transparent operations: Audited smart contract treasury, public financial journals, milestone-based payments, quarterly reporting. The accountability mechanisms are robust.
Real progress delivered: Full ledger validation, consensus chain selection, deterministic simulation testing, on-disk state management—all working. This isn't vaporware.
Hardware accessibility: Demonstrated running on Raspberry Pi down to Pi Zero. Lower hardware requirements directly improve decentralization by reducing SPO entry costs.
Competitive pricing: $225k/FTE aligns with comparable core development proposals (IOE at $302-346k, Tweag at $332k). They're not overcharging.
Reasonable timelines: Relay by Q1, block production by Q2, mainnet readiness by Q3. Tight but achievable given 2025 progress.The ask: ₳10.1M for 8.5 FTEs over 12 months with ₳4M contingency only for market volatility (ADA < $0.50). Unused contingency returns to treasury.
Bottom line: This is exactly what treasury funds should support—critical infrastructure with clear deliverables, transparent accounting, and proven team execution. Node diversity strengthens Cardano's antifragility. Worth funding.
- Yes 223K ₳ No rationale
- Abstain 215.5K ₳ No rationale
- No 208.6K ₳ Rationale
First and foremost, I want to make it absolutely clear that this vote is not a reflection on the Amaru team or their capabilities. I have full respect for their track record in the ecosystem, their contributions to open-source tools, and pushing for node diversity are valuable and well regarded. The long term benefits of a modular, fully interoperable, block-producing node in Rust with lower hardware requirements, better accessibility for SPOs/developers, and enhanced network robustness is not in doubt here. The team has strong credentials, and their work deserves support in principle. However, at this moment in Cardano's lifecycle, I believe we are effectively in survival mode. The network faces ongoing challenges around adoption, treasury sustainability, competition from VC backed chains, real-world utility scaling, and existential risks to decentralization and growth. In my view, treasury funds should be reserved almost exclusively for proposals that directly address life-or-death priorities for Cardano. Examples of what I consider life-or-death priorities include: critical security fixes, consensus upgrades for scalability/security (e.g., Leios integration), immediate adoption drivers, DeFi liquidity incentives, regulatory/compliance tooling, or defenses against centralization threats.
- No 198.8K ₳ No rationale
- Yes 190.9K ₳ No rationale
- Yes 190.2K ₳ No rationale
- No 182K ₳ No rationale
- Yes 180.9K ₳ No rationale
- Yes 137.3K ₳ No rationale
- Yes 131.7K ₳ No rationale
- Yes 111.9K ₳ No rationale
- Yes 111.7K ₳ No rationale
- No 109.4K ₳ Rationale
Both Acropolis & Amaru target nearly identical technical goals using the same approach (Rust), with similar timelines. The main distinction is organizational (IOG vs PRAGMA consortium).
This represents clear duplication of treasury investment in parallel solutions to the same problem.
- Yes 64.7K ₳ No rationale
- Yes 61.9K ₳ No rationale
- Yes 55.9K ₳ No rationale
- Yes 49.3K ₳ No rationale
- No 48.6K ₳ No rationale
- No 45.2K ₳ No rationale
- No 30K ₳ No rationale
- Yes 26.3K ₳ No rationale
- Abstain 8.1K ₳ No rationale
- No 6.8K ₳ No rationale
- Yes 974.8 ₳ No rationale