Dingo: a Production-Grade Block Producer in Go by Blink Labs
200 DReps voted · 83 with a rationale · 19 changed their vote
Open a row to read the rationale.
- Yes1.6M ₳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. - Yes1.6M ₳Rationale
Dingo is an incredible value added for the long term reliability of the network.
The choice of independent submission is more than appropriate for a properly decentralized (and not subject to third parties) decision making.
- No1.6M ₳No rationale
- Yes1.5M ₳No rationale
- No1.4M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳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.
- NoRevoted1.4M ₳History
Earlier votes
No4mo agoSuperseded
- Yes1.3M ₳No rationale
- NoChanged1.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.
Earlier votes
Yes4mo agoSuperseded
- Abstain1.2M ₳No rationale
- Yes1.2M ₳No rationale
- No1.1M ₳No rationale
- No1.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.
- Yes971.5K ₳No rationale
- Yes964.1K ₳No rationale
- No931.8K ₳No rationale
- Yes891.3K ₳No rationale
- Yes881.2K ₳No rationale
- No861.5K ₳No rationale
- No825.2K ₳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. - Yes798.6K ₳No rationale
- Abstain798.4K ₳No rationale
- Yes776.8K ₳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
- Yes763.4K ₳No rationale
- Yes761.1K ₳No rationale
- Yes759K ₳No rationale
- No756.5K ₳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.
- No731.5K ₳No rationale
- No717.5K ₳No rationale
- No705.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.
- YesChanged625.9K ₳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.Earlier votes
No3mo agoSuperseded
I'm voting no and not because I doubt the team's talent, the project's technical merit, or node diversity's strategic importance, but because this proposal lacks sufficient accountability mechanisms, independent oversight, and milestone-based funding discipline to responsibly deploy 6.9 million ADA. This is a request for negotiation, not rejection. The Blink Labs team represents some of the best technical talent in Cardano, and Dingo's progress is real: 1,290+ merged PRs, 314 passing conformance tests, Plutus V1/V2/V3 at 100% conformance. I want to support this work. But the proposal's structure creates unacceptable risk exposure that must be addressed before I can approve treasury deployment at this scale.
The core problem is the project’s governance concentration and insufficient independent oversight. The proposal budgets 5 FTEs for 12 months but only names 2 individuals at submission, at 1 developer and 1 admin. There are no milestones tied to hiring the additional 3 engineers, or staffing at all, meaning funds could be disbursed before the capacity to execute exists. The independent oversight board consists of 3 members: Pi Lanningham (SundaeSwap), Santiago Carmuega (TxPipe), and Lucas Rosa (Aiken, Midnight), while all are outstanding community members and contributors, they are all developers. The board is too small and too developer-focused, I need to see at least one domain-independent member, preferably a financial officer or project manager who can evaluate budgeting, milestone delivery, and fiscal discipline from outside the technical bubble. Funding disbursements require only Blink Labs initiation plus any 1 board member co-signature. That's effectively 2 out of 5 signatures controlling access to 6.9 million ADA. That concentration is unacceptable for a treasury withdrawal of this magnitude.
The single-withdrawal structure compounds this risk. The proposal requests the entire 6.9 million ADA upfront, with milestone-based releases governed by smart contract escrow and quarterly board reviews. But the permission scheme allows disbursements with minimal friction, Blink Labs plus one board signature. The failsafe sweep mechanism returns unused funds to the treasury after contract expiration, which sounds protective until you realize it introduces a race constraint: complete the work before expiration or lose funding. That creates unnecessary pressure favoring speed over quality, which is exactly the wrong incentive structure for consensus-critical infrastructure. I would strongly prefer milestone-based disbursement withdrawals, submitted in separate governance actions tied to comprehensive deliverables with explicit evidence of completion before the next tranche releases. That enforces accountability at the governance layer, not just the contract layer.
The proposal also raises staffing and budget concerns. The team stated publicly that "AI isn't replacing 'expensive' devs. It's making them cheaper with higher delivery." That's fine as a technical observation, but it raises the question: are we paying a single developer using AI agents the salary that three developers could sustain on? The budget allocates $1,000,000 for 4 FTE Go engineers at $250,000 per FTE all-in. That's premium compensation, and higher than most Cardano teams are paying. If AI tooling meaningfully amplifies individual developer productivity, the FTE count or per-FTE cost should reflect that efficiency gain. Milestones are strictly governed by code delivery and correctness, but budgeting explicitly names hiring of engineers as a significant portion of the ask. If the hiring hasn't happened yet and milestones aren't tied to staffing capacity, we're approving funding for theoretical team composition rather than actual execution readiness. The entire Cardano ecosystem is under great financial strain and it is imperative that everyone does their part to cut costs and be as efficient as possible, so I ask this team if they can also do more with less.
The proposal also exists in a strategic vacuum. Multiple alternative node implementations are being considered in parallel, we have Amaru, Dingo, Gerolamo, and potentially a vibe-node. Funding them individually on a first-come, first-served basis risks inefficient resource allocation and unnecessary overlap. Node diversity is critical, but the ecosystem hasn't agreed on how many alternative implementations we need, how they should be prioritized, or how SPO adoption will be achieved. Investing in alternative nodes is not a one-time expense, it's a permanent commitment. As Ouroboros Praos, Dijkstra, Leios, and future upgrades evolve, continuous support is required for maintenance, compatibility, and feature parity. Once we start funding a second or third node, we're committing to ongoing multi-team maintenance indefinitely. That decision should be made within a broader strategic framework, not proposal-by-proposal on treasury urgency.
Given limited treasury resources with ADA at depressed price levels, I also question whether now is the right time to fund a third node implementation when builders are making it clear they lack resources. Node diversity has indirect impact on user growth through network stability and resilience. Direct impact comes from business development, user onboarding, developer tooling, and real-world adoption initiatives. We should not invest tens of millions of ADA in block production infrastructure while tolerating underfunded and centralized governance and dismal MAUs and network utilization. If we're allocating from a limited decentralization budget, governance decentralization, and network adoption must be addressed alongside infrastructure decentralization.
The Blink Labs team has also stated publicly they will continue developing Dingo even without approval of this treasury withdrawal, with delayed development and delivery timelines. That further supports resubmission without major disruption to the project. This no vote is not rejection, it's a request for the team to strengthen accountability structures, add independent oversight, tie milestones to staffing capacity, and consider phased treasury withdrawals instead of a single upfront deployment. Since the new Constitution removed Budget Info Action requirements prior to Treasury Withdrawal Actions, the only avenue for negotiation is voting no and requesting resubmission with improved terms. I want to fund this work, but I need better governance safeguards first. I vote no, with encouragement to revise and resubmit. - No605.7K ₳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
- Yes590.5K ₳No rationale
- Yes589.7K ₳Rationale
I vote yes for node diversity
- Yes535.2K ₳Rationale
LGTM
- Yes533.9K ₳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
- No499K ₳Rationale
- Yes479.9K ₳No rationale
- Yes473.9K ₳No rationale
- Yes466.2K ₳No rationale
- Yes442.9K ₳No rationale
- No414.2K ₳No rationale
- Yes409.7K ₳No rationale
- Yes383K ₳No rationale
- Yes381.1K ₳No rationale
- YesRevoted325.4K ₳History
Earlier votes
Yes3mo agoSuperseded
- Abstain320.4K ₳No rationale
- Yes314.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.
- Yes313.4K ₳Rationale
I vote YES on this proposal as i believe it to support greater client diversity and resilience within the Cardano ecosystem. Recent events have highlighted the risks of relying too heavily on a single implementation, and funding alternative node clients strengthens decentralization and reduces operational risk.
The proposing team also has an established track record of delivering open source tooling within Cardano, which gives confidence that this is more than a speculative or experimental effort