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.
- Yes 313.1K ₳ 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
- Yes 298.6K ₳ Rationale
Summary
Dingo is a Cardano node developed by Blink Labs in the Go programming language. Blink Labs is seeking 6.9 million ada to fund 12 months of development.
" Blink Labs is requesting 6,900,000 ADA from the Cardano Treasury to fund twelve months of full-time engineering on Dingo, our Go Cardano node. "
Blink Labs expects that by the end of the 12-month period Dingo will be a viable option for block producers.
After twelve months: - Dingo produces blocks on mainnet. - SPOs have a real alternative block producer. - Dijkstra works from day one. - Leios exists in Go alongside the Haskell reference. - The audit report is public. - Every ADA is accounted for on-chain.Conclusion
I am voting YES on this withdrawal. In my vote for the Amaru withdrawal, I spoke about a bug which would have been mitigated by node diversity. 6.9 million ada is a lot of ada, but not a lot of dollars, and like the Amaru budget, this hurts. But I think it'll be better for everyone long-term if we pay this. Dingo is core infrastructure, just about as core as infrastructure can get. We've been talking about node diversity for years. The poisoned transaction attack last year convinced me node diversity should be a priority. Blink Labs has a track record of quality work.
Signed,
William DoyleYour friendly neighbourhood DRep!
$computerman
drep1yfpgzfymq6tt9c684e7vzata8r5pl4w84fmrjqeztdqw0sgpzw3nt
- Yes 295.2K ₳ No rationale
- Yes 284.2K ₳ No rationale
- No 279.5K ₳ Rationale
FTE Go Engineer does not cost 250k a year
- Yes 271.5K ₳ No rationale
- No 258.6K ₳ Rationale
Governance Action Review
Governance Action:
Dingo: a Production-Grade Block Producer in Go by Blink LabsI 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
Dingo: a Production-Grade Block Producer in Go by Blink Labs.
Revisão de Ação de Governança
Ação de Governança:
Dingo: a Production-Grade Block Producer in Go by Blink LabsEstou 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
Dingo: a Production-Grade Block Producer in Go by Blink Labs. - Yes 245K ₳ No rationale
- Yes 238.2K ₳ No rationale
- Yes 223K ₳ No rationale
- Yes 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 Blink Labs team or their capabilities. I have full respect for their track record in the ecosystem, their contributions to open-source tools, and pushing for client/language diversity are valuable and well-regarded. The technical quality and potential long-term benefits of a mature Go-based node are 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-Eipstein cabal 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, immediate adoption drivers, DeFi liquidity incentives, regulatory/compliance tooling, or defenses against centralization threats.
- No 198.8K ₳ No rationale
- Yes 195.9K ₳ Rationale
This proposal represents a meaningful infrastructure advancement for Cardano backed by proven ecosystem contributors with a track record of delivery. Node diversity done well is not a vanity metric.
The team behind Dingo has demonstrated strong, long-term Cardano ecosystem commitment. Their Go-based node implementation is already showing tangible value in pre-production; measurable hardware cost reductions for SPOs, and critically, blocks are already being minted on Preview mainnet with sub 1GB RAM using Log-Structured Merge tree (LSM) optimisation. This isn't theoretical, it's a live proof of concept demonstrating protocol parity and resource efficiency at scale.
The Haskell node is undergoing LSM optimisation in parallel. Dingo's ability to achieve sub-1GB RAM footprint with LSM while minting mainnet blocks validates the approach and gives SPOs a genuinely efficient alternative, especially for resource-constrained cloud operators and bare-metal pools alike.
Critically, Dingo is being developed collaboratively with the existing Haskell node development team, not in isolation. This coordination ensures protocol parity and significantly mitigates fragmentation risks.
Language and implementation diversity strengthen network resilience. A production-grade Go alternative gives SPOs genuine choice based on their infrastructure constraints and preferences. This improves decentralisation.
The treasury investment is justified. Cardano's long-term value depends on robust, diverse infrastructure. Funding skilled agents to build that is core treasury work.
- Yes 190.9K ₳ No rationale
- No 190.2K ₳ No rationale
- Yes 182K ₳ No rationale
- Yes 180.9K ₳ No rationale
- Yes 160K ₳ No rationale
- Yes 142.3K ₳ Rationale
Node diversity is not optional; it is a necessary condition to achieve a robust security standard. The addition of Dingo as a Go-based node brings Cardano closer to the multi-client model that has already proven essential in other ecosystems.
Furthermore, this proposal offers a clear differentiating value: Go is one of the most widely used languages in blockchain infrastructure. Opening Cardano’s core to this ecosystem of millions of developers lowers barriers to entry, facilitates external audits, and accelerates enterprise adoption. The control structure is also solid: milestone-based disbursements and independent oversight with the ability to pause funding provide real guarantees for the treasury.
From a security perspective, node diversity is critical. With multiple independent implementations, the network can detect and reject errors before they become irreversible. Each additional node significantly reduces this risk.
Overall, this proposal is not simply funding development, but a structural investment in the security, decentralization, and accessibility of the Cardano ecosystem.
For all these reasons, I vote YES.
- Yes 137.3K ₳ No rationale
- Yes 131.6K ₳ No rationale
- Yes 111.7K ₳ No rationale
- No 109.4K ₳ Rationale
Treasury shouldn't fund three parallel solutions to the same core problem (Haskell node alternatives). Each implementation requires ongoing maintenance, security auditing, and ecosystem integration. Focus treasury resources on proven implementations rather than funding experimental redundancy.
- No 65.9K ₳ No rationale
- Yes 64.7K ₳ No rationale
- Yes 61.9K ₳ No rationale
- Yes 55.9K ₳ No rationale
- Yes 53K ₳ No rationale
- No 49.3K ₳ No rationale
- Abstain 48.6K ₳ No rationale
- Yes 48.5K ₳ No rationale
- Abstain 48.4K ₳ No rationale
- No 45.2K ₳ No rationale
- No 37.8K ₳ No rationale
- Yes 31.9K ₳ No rationale
- No 30K ₳ No rationale
- Yes 27.3K ₳ No rationale
- Yes 26.3K ₳ No rationale
- Yes 25.7K ₳ No rationale
- No 10.6K ₳ No rationale
- Yes 8.1K ₳ No rationale
- No 6.8K ₳ No rationale
- Yes 974.8 ₳ No rationale
- Yes 616.8 ₳ No rationale
- Yes 283.6 ₳ No rationale
- No 153.7 ₳ No rationale
- No 103.5 ₳ No rationale
- No 0 ₳ No rationale
- Yes 0 ₳ No rationale