Dingo: a Production-Grade Block Producer in Go by Blink Labs
200 DReps voted · 74 with a rationale
Open a row to read the rationale.
- No 1.6M ₳ No rationale
- Yes 1.5M ₳ Rationale
I support this proposal and vote YES.
This proposal funds a credible, already-progressing effort to deliver a second production-ready Cardano node implementation in Go, with clear benefits to network resilience, developer accessibility, and protocol robustness.
Rationale:
Client diversity is critical infrastructure: Cardano currently relies on a single block-producing node implementation. Dingo meaningfully advances multi-client resilience, reducing systemic risk.
Strong execution track record: Blink Labs demonstrates sustained delivery (1,000+ PRs, full Plutus conformance, working protocol components), indicating high likelihood of completion.
Clear and bounded scope: The roadmap—from Praos completion through Dijkstra and Leios integration to audit and mainnet readiness—is well-structured and technically coherent.
Governance-aligned fund management: The use of audited escrow contracts, milestone-based releases, and an independent oversight board provides strong accountability.
Conclusion:This is a high-impact infrastructure investment with strong transparency, credible delivery capacity, and clear alignment with Cardano’s long-term decentralization and scalability goals.
- Yes 1.5M ₳ No rationale
- Yes 1.4M ₳ Rationale
This is a long-term strategic project that has already reached several milestones. Even if multi-node diversity is not the highest priority under the current conditions, the project should be continued.
- No 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- No 1.4M ₳ No rationale
- No 1.2M ₳ Rationale
I vote NO on this proposal because, although a production-grade Go node could improve resilience and add long-term value, I do not think this is the right funding priority now. Cardano is already committing substantial resources to infrastructure, and I currently prefer stronger focus on application growth, user adoption, TVL, transaction activity, and healthier ecosystem funding balance. My concern is therefore mainly about timing and treasury sequencing, not about dismissing the technical ambition or Blink Labs’ work altogether. I would be more open to this type of investment later, once broader budget priorities are clearer and the case for expanding beyond the current node roadmap is more compelling.
- Abstain 1.2M ₳ No rationale
- Yes 1.2M ₳ Rationale
Node diversity will be good for the Cardano ecosystem; if not for the software itself, then certainly for enabling multiple actors to develop and maintain the Cardano protocol. This improves decentralization, as we no longer rely on a single company that might have too much power, resulting in a more secure network.
Ideally, the treasury could/should (partly) fund 3 to 5 different node implementations in my view.
The Dingo team already has a proven track record, work has already been done with Catalyst funding, and the requested amount seems reasonable.
That’s why I’m voting YES on this proposal. - No 1.1M ₳ No rationale
- Yes 1.1M ₳ No rationale
- No 1M ₳ Rationale
The Dingo proposal demands an exorbitant 6.9 million ADA for a Go-based node that blatantly duplicates our ongoing efforts to achieve client diversity.
Funding critical infrastructure development against unpublished specifications is fiscally irresponsible, highly premature, and severely contradicts the prudent treasury administration mandated by the spirit of our Constitution.
My mandate is to protect this treasury from bloat and poorly timed execution. **We cannot finance every developer's preferred language port simply because they possess the technical capability to write it. **
Cardano is at a stage where the vault needs to be locked and governed with rigorous business strategy, demanding foundational stability and proven necessity before opening it to the whims of developers and so-called builders who don't deliver measurable value at all.
- Yes 1M ₳ No rationale
- Yes 955.2K ₳ No rationale
- Yes 941.2K ₳ No rationale
- No 922.9K ₳ No rationale
- Yes 881.3K ₳ No rationale
- No 860.4K ₳ No rationale
- No 818K ₳ Rationale
This is more of a Nice to have than a must right now. Definetly node diversity is important but we need to be aware that expanding developing and maintenance fronts before growing to a sustainable daily Transactions rate might be counter productive.
Also the budget numbers seem high. We thank the proposing team and invite them to resubmit when the time is right with a revised budget. - Yes 804.1K ₳ No rationale
- Yes 798.4K ₳ No rationale
- Yes 791.4K ₳ Rationale
Node diversity is an enabler of potential new adoption of developers and integrations. Having many node versions only adds to the distribution of control over the codebase, as having a node that is not directly controlled by founding entities is a signal that the strength of the community is growing. Node diversity is not a task that should be given to these founding entities, if we care about blockchain first-principles.
Funding a node that has great organization, high likelihood of completion, and a team of developers capable of delivering a quality product is something I believe is net positive for the ecosystem
- Abstain 785.2K ₳ No rationale
- Yes 765.1K ₳ No rationale
- No 762.8K ₳ No rationale
- Yes 762.6K ₳ No rationale
- No 749K ₳ Rationale
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.
- Yes 738.5K ₳ No rationale
- No 733.1K ₳ Rationale
Vote: NO.
While the work is promising, I do not believe the current funding request is sufficiently justified at this stage and market moment.
- No 717.1K ₳ No rationale
- No 654.5K ₳ Rationale
📌 CARDANO TREASURY VOTE: DINGO NODE — I VOTE NO
Cardano governance is currently voting on the proposal “Dingo: a Production-Grade Block Producer in Go.”
Blink Labs is requesting ₳6,900,000 ADA from the Cardano Treasury to develop a new Cardano node implementation written in Go.
As a DRep, I vote NO on this proposal.
🔎 Proposal Summary
The Dingo project aims to build a third Cardano node implementation capable of:
• syncing the blockchain
• validating transactions and smart contracts
• participating in Ouroboros consensus
• producing blocksIn other words, it would become another block-producing node client for the network.
⚠️ Why I Vote NO
The Cardano community recently approved major funding for the Amaru node, an alternative node implementation written in Rust.
The Amaru treasury withdrawal totals ₳10,142,000 ADA.
Amaru is intended to become the second full node implementation for Cardano, but it has not yet reached mainnet production.
Now we are being asked to fund a third node implementation before the second one is even deployed.
💰 Treasury Responsibility
The situation now looks like this:
• cardano-node (Haskell) — current primary implementation
• Amaru (Rust) — recently funded alternative node
• Dingo (Go) — requesting additional treasury fundingBut the second implementation has not yet proven itself in production, and already a third is requesting funding.
Treasury funds belong to the entire ecosystem and must be used carefully and strategically.
🗳 My Vote
I vote NO on the proposal “Dingo Treasury Withdrawal — ₳6,900,000 ADA.”
My position:
• first launch and evaluate Amaru
• then assess whether additional node implementations are necessary
• the treasury should not become a funding source for every new client proposalCardano benefits from node diversity, but funding multiple node implementations simultaneously without proven need risks misusing treasury resources.
🖤 My DRep ID:
➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jrYou can find me under the name MREDGARCROSS.
I registered as a DRep and am ready to help shape the future of the ecosystem.
More details 👉 https://t.me/PROCENT666/338
- Yes 624.8K ₳ Rationale
I'm switching my vote to yes because while my governance concerns remain valid, they're outweighed by the strategic necessity of supporting proven builders who shipped before asking, the momentum of broad community consensus, and the reality that standing against widely-supported progress over process concerns is counterproductive governance. The Blink Labs team has earned this opportunity through execution, not promises.
My original no vote highlighted legitimate risks: governance concentration with only 2 named FTEs despite 5 budgeted, a 3-member developer-focused oversight board lacking financial/project management expertise, and 2-of-5 signature control over 6.9 million ADA. Those concerns haven't disappeared. But I'm revising my position because the context matters more than I initially weighted it. Blink Labs built Cardano's entire Golang ecosystem, infrastructure the network unknowingly depends on daily. That should be championed, not penalized with excessive bureaucratic hurdles. They demonstrated execution capacity as Dingo is already minting blocks on preview testnet, making it technically the furthest-along alternative node implementation. This isn't speculative funding for theoretical capacity; it's resourcing proven builders to finish what they started.
The ecosystem reality also shifted my calculus. All founding entities support Dingo, and the Constitutional Committee backs it unanimously. Cardano Foundation secured Amaru funding, IOG maintains the legacy Haskell node, both can request ongoing funding year over year and receive it as they should. A third node from an independent community team balances fairness on future asks and reduces reliance on founding entity monopolies. Node diversity isn't a luxury when Cardano's security model depends on distributed infrastructure resilience. We're in a decentralized ecosystem; if the Blink Labs team believes building a Go node is their highest-value contribution, I have to respect that self-assessment even if I'd prefer their talent deployed elsewhere. They could earn this compensation in other industries, they have the skill, location, and experience. Retaining top-tier talent requires competitive contracts, especially for infrastructure work that doesn't offer startup equity upside or future growth multiples.
The wage allocation still stings, $250,000 per FTE all-in is premium compensation higher than most Cardano teams, including NMKR's CEO in one of the world's most expensive countries. In times of depressed ADA prices and builder funding shortages, it's a bitter pill. But building a production-grade consensus node isn't comparable to startup equity gambling where you underpay early for potential big payouts later. This is contract infrastructure work requiring sustained expertise, and the market rate is what it is. If AI tooling amplifies productivity as the team suggests, we're paying for output velocity, not just headcount. The alternative is potentially losing this team to better-compensated opportunities, far more costly on the ecosystem than a single cycle budget optimization.
My preference for milestone-based treasury withdrawals with separate governance actions per tranche remains unchanged. The single 6.9 million ADA withdrawal with smart contract escrow and quarterly board reviews isn't ideal governance architecture. But the perfect shouldn't kill the good. The oversight board, Pi Lanningham, Santiago Carmuega, Lucas Rosa are respected community contributors, and while I'd still prefer domain-independent financial oversight, their technical judgment carries weight. The failsafe sweep returning unused funds to treasury after expiration provides backstop accountability even if it creates time pressure.
I also acknowledge that multiple alternative nodes (Amaru, Dingo, Gerolamo, potentially others) create coordination challenges and permanent maintenance commitments. The ecosystem hasn't agreed on how many implementations we need or how SPO adoption gets achieved. But waiting for perfect strategic consensus means indefinite paralysis. Dingo has momentum, community support across diverse stakeholder groups, and technical readiness. Voting no to force broader node diversity strategy discussions punishes the one team that actually shipped code while we debate frameworks.
The Blink Labs team stated they'll continue Dingo development without treasury approval, just with delayed timelines. That demonstrates commitment but also means blocking this proposal doesn't kill the project, but it just slows it and signals the treasury won't back independent builders who prove execution before asking. That's the wrong precedent. My original no vote was a negotiation request for stronger safeguards. The team didn't revise the proposal, but the community spoke: Constitutional Committee unanimous support, founding entity backing, broad DRep endorsement. Refusing to adapt my position in the face of that consensus makes me an obstacle, not a guardian of fiscal discipline.
Cardano needs this. Node diversity is existential for decentralization, and Blink Labs earned the right to finish what they started. My governance concerns are real, but they are process objections in the face of substantive progress. I'm switching to yes because supporting proven builders, respecting community consensus, and advancing critical infrastructure outweighs my preference for more conservative treasury deployment mechanics and oversight. - Yes 601.8K ₳ No rationale
- Yes 589.2K ₳ Rationale
I vote yes for node diversity
- Yes 536.5K ₳ Rationale
LGTM
- Yes 534.3K ₳ Rationale
Node diversity is very important and with Dingo already in full production the time is now to fund these endeavors as other blockchain projects lay off and lose resources. Lets push the tech and code stack even further
- No 481.5K ₳ Rationale
- Yes 471.9K ₳ No rationale
- Yes 466.2K ₳ No rationale
- Yes 445.1K ₳ No rationale
- Yes 443.5K ₳ No rationale
- No 438.7K ₳ No rationale
- No 426.2K ₳ No rationale
- Yes 409.3K ₳ No rationale
- Yes 382.6K ₳ No rationale
- Yes 377.3K ₳ No rationale
- Yes 324.4K ₳ No rationale
- Abstain 321.1K ₳ No rationale
- Yes 314.4K ₳ Rationale
I have decided to vote "YES" on the funding request for the Dingo Go node, although I initially considered voting "NO."
A PDF version of this rationale is also made available.
I have decided to vote "YES" on the funding request for the Dingo Go node, although I initially considered voting "NO".
As someone who maintains a conservative approach to treasury spending, I was reluctant to fund a third node implementation. Since we already have the Amaru (Rust) node being developed alongside our foundational Haskell node, I felt that our need for network resilience and node diversity was already met.
However, I deeply respect the Blink Labs team and value their ongoing work for our ecosystem. Because I am not a developer myself, I wanted to be certain I wasn't missing any important technical details. Therefore, I relied on AI-driven research to better understand the proposal.
Through this research, I realized that the Go implementation (Dingo) brings several important new characteristics to Cardano that go beyond just network resilience:
Cheaper and Easier dApp Deployment: Dingo includes built-in APIs and indexing. This lowers the infrastructure overhead, making it much more cost-effective and easier for developers to build and launch dApps.
Bridging the Gap to Enterprise Adoption: Go is the industry standard for modern tech and cloud computing. Dingo makes it much easier for traditional businesses to adopt Cardano and connect it to the systems they already use.
Accelerating the Leios Hard Fork: Dingo's architecture provides a valuable testing ground for the upcoming Leios upgrade, helping us prepare to scale the network safely and efficiently.
Closing Thoughts:
While the requested budget is substantial, I now view this not just as funding for an extra node, but as a strategic investment to grow our ecosystem, make it easier for developers to build, and attract larger enterprises to Cardano.