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.
- No300.6K ₳No rationale
- Yes298.9K ₳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
- YesChanged294.4K ₳History
Earlier votes
No4mo agoSuperseded
- Yes285.3K ₳No rationale
- YesRevoted271.8K ₳History
Earlier votes
Yes4mo agoSuperseded
- No261K ₳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. - Yes245.5K ₳No rationale
- No238.8K ₳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.
- No234.2K ₳Rationale
FTE Go Engineer does not cost 250k a year
- Yes233.2K ₳No rationale
- Yes223.6K ₳No rationale
- Yes215.5K ₳No rationale
- No199K ₳No rationale
- Yes196.1K ₳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.
- No191.1K ₳No rationale
- Yes182.2K ₳No rationale
- Yes178.9K ₳No rationale
- Yes171.1K ₳No rationale
- Yes159.6K ₳No rationale
- Yes142.5K ₳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.
- Yes138.4K ₳No rationale
- Yes137.4K ₳No rationale
- Yes110.9K ₳No rationale
- No109.5K ₳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.
- Yes108.3K ₳Rationale
The primary driver for my yes vote on this proposal is the critical need for client diversity. Relying on a single client implementation creates a single point of failure and while the ecosystem is currently developing a Rust node, having only two implementations remains a precarious position. Creating a Go-based block producer would bring our total to three distinct clients and, in my view, this is the absolute bare minimum for a resilient, high-security chain. We saw the necessity of this first-hand during the November 2025 chain split incident, where a bug in a single implementation caused significant network disruption. A mature ecosystem with three independent, production-grade clients would be far more resilient, as a consensus bug in one codebase is unlikely to be mirrored in the others.
Blink Labs is a respected team with a proven track record of delivery. Their technical competence is evident in the proposal’s depth. While the funding request is substantial, the costing is realistic given the specialized engineering skillset required to build a performant node. This is a high-value infrastructure investment.
I do have reservations regarding the timing of this request, though these are structural concerns rather than a critique of Blink Labs. Under our current governance framework, we are voting on this significant withdrawal before seeing the broader context, specifically upcoming budget proposals from Intersect and other major entities.
Without a side-by-side comparison of all competing priorities, it is difficult to assess the opportunity cost. For example, a DRep focused more heavily on DeFi liquidity might hesitate to commit funds so early in the cycle. However, this is a flaw in our current governance process and not something the proposer is doing wrong.
Despite the lack of a bigger budget view, I believe node diversity is too important an infrastructure requirement to pass up on. The risk of another chain disruption outweighs the benefit of waiting for a more organized budgetary timeline. Blink Labs is using the system as intended, and the technical necessity of their work justifies the investment - Yes68.8K ₳No rationale
- No64.4K ₳No rationale
- Yes55.9K ₳Rationale
good team and project.
minor complaints/questions, butA PDF version of this rationale is also made available.
Apart from inflated costs for Christina, I dont have anything materially against this proposal. In fact, I find 3 node implementations substantially better than 2. On the one hand, this is positive for Amaru, as SPOs and everyone else running nodes, will now REALLY have to actively choose what they run, which means more eyes fall on Amaru and there is more noise around alternatives. Potentially even more noise around Cardano in general. On the other hand, this is positive for Cardano, as even the best split between 2 node implementations (50/50) is not enough for a majority chain rule to decide which side is which upon a bug. A 3 way split (albeit that never will reach 33/33/33) is much more resilient.
Blinklabs/Dingo is a solid team to develop a third implementation, while proving since years of Catalyst development for this, they can, and do deliver.
The proposal is well laid out, and, apart from weak/unprofessional language, good enough in my opinion.
I would like to see/understand what precise differences the 3 implementations have from another and where Dingo stands out and what it brings to the table.
"Its written in Go" is not an argument or a feature. Its just a choice.E.g. With Amaru not being able to sync from scratch but only snapshots to become ultralightweight is a clear differentiation. - would Dingo cover this?
- No50.5K ₳No rationale
- YesChanged49.6K ₳Rationale
After further education on the use case and benefits of an additional Node block producer in the ecosystem and also the need for alternatives in that lane of infrastructure I have chosen to Change my vote from ABSTAIN due to future funding requirements to YES. If we as a community are afraid to invest in the infrastructure of the blockchain we run the risk of stagnation and obsolescence. Innovation is spurred by the existence of alternative options. BLINK LABS has proven its value to this community and this ecosystems technological growth, I find value in the Innovation of the blockchain
Lourde DRep Ouroborus Imperator AeternalisEarlier votes
Abstain3mo agoSuperseded
I choose to abstain from this vote not due to lack of confidence in the very capable and talented team at blink labs but because of the current situation in the market, the current value of ADA ($0.245) and the consistent extraction of Treasury funds. Blink Labs has a proven in storied track record in providing quality and reliable applications for the community but at the currently unsustainable pricing of ADA regardless of the long-term withdrawal scheduling it is my stance that an additional maintenance requirement and upgrade schedule for this block producer will cause further drain from the treasury in future unless some type of payment structure can be pinpointed that will not require future Treasury value extraction for said maintenance and upgrades. While I do agree that an additional block producing node has value to the overall community infrastructure I would like to see this plan fleshed out to address the need for future funding for developers to complete upgrades or maintenance in case of hard forks and various other unforeseen changes. I find unquestionable value in Blink labs they have stood by this community throughout the years, throughout the bear markets, and throughout the bull markets, I would just like to see more information for future implementation before voting YES because this is not a NO it is an ABSTAIN due to lack of future funding needs information.
Lourde DRep Ouroborus Imperator Aeternalis - Yes48.6K ₳Rationale
agreed/'.
- Abstain46.5K ₳Rationale
I am not deeping dive into this yet. So I remain abstain
- No45.2K ₳No rationale
- Yes30.9K ₳No rationale
- No29.3K ₳No rationale
- Abstain28.2K ₳Rationale
This is a strong and technically compelling proposal with clear value for the Cardano ecosystem. The case for client diversity is well made, and Dingo’s progress (conformance tests, Plutus support, and existing tooling) demonstrates real execution capacity. The emphasis on open source, auditability, and structured milestone-based funding is also a positive signal.
However, I am choosing to abstain due to several important uncertainties:
High funding request (6.9M ADA): While justified in detail, this remains a significant allocation, and it’s difficult to benchmark cost efficiency against other node implementation efforts at this stage.
Execution risk: Delivering a production-ready node including consensus, hard forks, and security hardening is extremely complex, especially within a 12-month timeline.
Dependence on evolving components: Critical elements like Leios (CIP-0164) and the Dijkstra hard fork are still evolving, which introduces additional uncertainty in scope and delivery.
Ecosystem overlap: With other node initiatives (e.g., Rust-based clients), it’s not yet fully clear how resources should be optimally distributed across competing approaches.
Governance maturity question: This proposal tests whether the current treasury process is ready to fund large-scale, high-impact infrastructure at this level.
In summary, I recognize the strategic importance of this work, but I am not yet fully confident in the timing, cost clarity, and execution certainty required to support or reject it decisively.
- Yes26.7K ₳Rationale
Blink labs is trusted. I vote yes.
- Yes25.7K ₳No rationale
- NoRevoted15.3K ₳History
Earlier votes
No4mo agoSuperseded
- No10.6K ₳Rationale
I'm not in favor of the proposal, so I vote no.
- Yes8.1K ₳No rationale
- No6.7K ₳No rationale
- Yes4.7K ₳No rationale
- Yes4.4K ₳No rationale
- Yes682 ₳No rationale
- Yes618.5 ₳No rationale
- No153.7 ₳No rationale
- No123.6 ₳No rationale
- NoRevoted0 ₳History
Earlier votes
No4mo agoSuperseded
- Yes0 ₳No rationale