drep1y23tfs3c25kfm...

I am voting NO on the Dingo proposal because I believe it represents unnecessary redundancy. With the community already supporting the development of a second node implementation (Amaru), allocating another 6.9M ADA to a third implementation—managed by a private company rather than a non-profit—is not a prudent use of treasury funds. Furthermore, the $250k per FTE personnel costs and the recurring $500k audit fees across multiple projects suggest a lack of capital efficiency in our core infrastructure funding.

I am voting NO because this framework creates an exclusionary 'pay-to-play' system. The 1,000 ADA entry fee and 100,000 ADA minimum request size protect the interests of large organizations while shutting out the grassroots developers who are the heartbeat of Cardano. Furthermore, I oppose the use of off-chain filters to decide on-chain outcomes. Governance should remain as direct and permissionless as possible, without institutional gatekeepers.

DRep Rationale: Why I am voting "NO" on Amaru 2026

While I value the technical expertise of the Amaru team and the importance of node diversity, I am voting NO on this withdrawal for the following reasons:

Inefficient Treasury Allocation: The 4M ADA "market contingency" buffer is excessive. It locks up significant community capital that could be used for other initiatives. I prefer a model where projects request additional funds if market conditions shift, rather than over-budgeting by 40%.

Performance vs. Cost: The 2025 retrospective shows that key deliverables like Block Production and Mempool implementation are behind schedule. I cannot support a 10.1M ADA expansion until the primary goals of the previous funding round are fully realized and stable.

High Overhead: The fixed costs (Audit and Testing) and high FTE rates set a high-cost precedent for Cardano development. I am looking for proposals that demonstrate more aggressive cost-optimization for the benefit of the ADA holders.

I encourage the Amaru team to return with a more focused, milestone-driven proposal that addresses the current delays without the heavy contingency padding.