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 16.4M ₳ No rationale
- No 14.1M ₳ No rationale
- Yes 13.3M ₳ Rationale
RCADA supports this treasury withdrawal as a strategically important investment in Cardano’s infrastructure resilience, decentralisation, and long-term ecosystem accessibility.
This proposal addresses a fundamental structural consideration within the network: reliance on a single production node implementation. By advancing Dingo—a Go-based Cardano node—toward mainnet block production readiness, it contributes directly to node diversity, which is essential for reducing systemic risk and improving network robustness. Multiple independent implementations strengthen Cardano’s ability to withstand client-specific defects, an approach that has proven critical in other blockchain ecosystems.
We recognise the substantial progress already demonstrated by the Blink Labs team. With a significant body of merged code, full Plutus V1–V3 conformance, and working implementations of key node components, this proposal represents the continuation of an already credible and actively developed infrastructure effort rather than a speculative or early-stage initiative.
The governance and treasury management structure presented is notably strong. The use of audited smart contract escrow mechanisms, milestone-based disbursements, independent oversight, and a public transaction journal establishes a high standard of accountability and transparency. These mechanisms align closely with responsible treasury usage and represent a positive precedent for future funding proposals.
We also acknowledge the broader strategic value of a Go-based implementation. Go is widely adopted across high-performance distributed systems and blockchain infrastructure, and its inclusion expands accessibility to a significantly larger developer ecosystem. This has potential long-term benefits for adoption, integration, and contributor growth within Cardano.
At the same time, we recognise and take seriously several concerns raised within the community.
First, questions around overall treasury coordination and budget visibility remain valid. The current environment, where multiple treasury withdrawal proposals are assessed independently, can make it difficult to evaluate cumulative impact and prioritisation across competing initiatives. While this is a systemic governance consideration rather than a deficiency specific to this proposal, it remains an area that requires continued improvement.
Second, we acknowledge the argument that funding multiple node implementations introduces long-term maintenance considerations and may risk spreading resources too thinly. These concerns are legitimate and highlight the importance of disciplined treasury management. However, we consider node diversity to be a foundational requirement rather than a discretionary enhancement. Progressing toward a multi-client ecosystem should not be treated as strictly sequential, as doing so may delay meaningful risk reduction at the protocol level.
Third, execution risk remains non-trivial. Delivering a production-ready block-producing node requires successful completion of consensus implementation, operational hardening at scale, and a comprehensive security audit. These risks are inherent to the scope of the work. However, they are explicitly acknowledged within the proposal and are mitigated through structured milestones, escrow-based disbursement controls, independent oversight, and contingency planning.
We also note minor shortcomings, such as the use of an outdated constitutionality checklist template, which, while not materially affecting the validity of the proposal, reflects an area for improvement in future submissions.
On balance, RCADA finds that this proposal meets the threshold for treasury funding. It combines demonstrated delivery capability, strong governance design, and clear ecosystem value. It represents a meaningful step toward improving Cardano’s infrastructure resilience and developer accessibility.
Our YES vote reflects support for this specific proposal and its merits. It should not be interpreted as a blanket endorsement of all future node implementations or ongoing funding without the same level of scrutiny. Each subsequent proposal must independently justify its value, cost, and alignment with ecosystem priorities.
RCADA remains committed to supporting initiatives that strengthen decentralisation, improve governance standards, and deliver long-term value to the Cardano ecosystem.
RCADA’s full vote assessment can be found here: “https://brolloks.github.io/rcada-drep-votes/
- Yes 12.8M ₳ Rationale
I am voting YES on governance action f35285db3c4e085ad331843b3007737952b8a322bb3216311edc37fdf44ad3da#0.
Dingo, a Go block producing node, is a clear net-value-add to our ecosystem, and Blink Labs is the only company that can deliver it.
Because of the security properties of Ouroboros, the Cardano network needs to reach a state where no single node has more than 50% of the stake. Without that, any single bug in the Haskell node threatens to permanently ratify a bad ledger state. For example, a bug in the Haskell node could ratify a ledger state with more than the 45 billion max supply of ADA, or corrupt wallet balance. We're lucky that the high-assurance engineering employed by Input Output has insulated us against such failures for 8 years, but the law of large numbers (and the increasing pace of innovation and change from Peras, Leios, and other large initiatives) tells us that it will happen eventually.
Such a bug would likely completely and permanently destroy trust in the network. Since we are already fighting with our hands tied behind our back in the arena of public perception, the network would likely not survive such a blow.
Instead, if the network operates with a diverse set of nodes, all with less than 50% of the stake, we are innoculated against such bugs. If the haskell node had 45% stake, and several alternative nodes had 55% of the stake, then such a bug would be rejected by the rest of the network well before making it past the 2160 block event horizon that makes it permanent.
Yes, Amaru is working on building an alternative node implementation in Rust, but a single alternative node alone cannot bring the stake distribution below 50% in the long term. Each additional node that gets built makes it easier to spread the stake across node implementations and reduces our risk of this kind of catastrophic total failure.
Of course, such diversity brings with it it's own risks and challenges; A bug in a node with a large portion of the stake can cause a short lived fork, which is economically disruptive, as we saw last year in the pig-chain fork. As such, we need these alternative nodes to be built by competent and proven teams who understand the responsibility and dangers of a non-conforming node. We need engineers who are dedicated not just to implementing what we know about the behavior of the Cardano node, but finding and implementing what we don't know.
For example, this is why I remain skeptical of AI driven node implementations. AI is very good these days, I use it every day to accelerate the work I do. But their skill is deceptive. Given the way they are trained, they are very good at implementing the things that have already been implemented many times. It is very easy for an AI coded node to appear to be progressing very quickly, implementing the things that are well known surface areas by this point: node to node protocols, node to client protocols, even a first pass at ledger validation.
But the bugs and subtle differences that lie off the beaten path can prove nearly incredibly damaging. These are the untrodden path, and it is much harder for an AI alone, without the guidance of an experienced engineer with deep Cardano expertise.
Indeed, by funding multiple teams, each with their own perspective, each building in a different language, but all collaborating and sharing notes, we dramatically increase the likelihood that all such efforts will be successful. The blindspots that a rust engineer, or one architectural design might have can be revealed by a completely different implementation. Because these teams share test suites and notes, each initiative is strengthened by the others, up to a point of diminishing returns.
This is why I believe it is valuable, even essential, to fund teams like Dingo.
You can find a larger writeup justifying my vote here.
- Abstain 12.2M ₳ Rationale
As Wada DRep, we vote abstain on this proposal. Our decision is not a rejection of the underlying technical ambition, but rather a reflection of a broader and necessary governance position regarding how the Cardano ecosystem approaches client diversity and the funding of core infrastructure.
We strongly recognise and support the importance of developing alternatives to the Haskell node. Client diversity is fundamental to decentralisation, resilience, and long-term network health. Reducing reliance on a single implementation mitigates systemic risks and opens the ecosystem to a broader developer base. In this regard, initiatives such as this are directionally aligned with Cardano’s strategic objectives, and we acknowledge the value they seek to bring.
However, we are increasingly concerned about the absence of a clearly defined framework guiding how many alternative node implementations the ecosystem should support and at what cost. As it stands, each proposal is evaluated in isolation, often appearing justified on its own merits, yet collectively contributing to a growing and uncoordinated financial burden on the treasury. Without a shared understanding of the desired level of client diversity, there is a risk of overextending resources toward parallel infrastructure without clear convergence or measurable thresholds for sufficiency.
This concern is further compounded by the economic nature of node implementations as public goods. Unlike other initiatives, node infrastructure does not inherently generate revenue, yet it requires continuous maintenance, upgrades, and security oversight. Each additional implementation therefore introduces not only an upfront development cost but also an ongoing financial obligation. In the absence of a sustainable funding model beyond treasury reliance, the ecosystem risks accumulating long-term liabilities without a clear path to self-sufficiency.
In the current governance era, where treasury access has been significantly broadened, we believe it is especially important to exercise discipline and intentionality in capital allocation. The ecosystem has already committed substantial resources to core infrastructure, including the continued development and maintenance of the Haskell node. While we welcome efforts such as Amaru that are already advancing alternative implementations, we believe this is an appropriate moment to pause and assess progress rather than accelerate further parallel investments.
We therefore recommend that the ecosystem facilitate a structured and inclusive discussion around node diversity. This should aim to define a target range for viable implementations, establish funding criteria, explore sustainable maintenance models, and determine how adoption and usage should influence continued support. Such a framework would provide clarity to proposers, confidence to DReps, and ensure that treasury resources are deployed in a manner that is both strategic and sustainable.
For these reasons, we vote abstain at this time. Our position reflects a call for coordination, prioritisation, and long-term thinking in how we fund and sustain critical infrastructure, and not ignorance of the importance of the problem this proposal seeks to address.
- Yes 11M ₳ No rationale
- No 10.8M ₳ No rationale
- No 10.5M ₳ Rationale
We already have Amaru proposal for node diversity. There is no urgent need for multiple proposals of a similar nature. It would be better to wait until next year
- Yes 8.8M ₳ Rationale
本提案に賛成票を投じます。Dingoは、Haskell実装に依存しないGo製ノードとしてCardanoにおけるノード実装の多様性を高める重要な取り組みであり、ネットワークの分散性とレジリエンスの向上につながると考えます。さらに、提案者であるBlink Labsは十分な技術的知見と開発実績を有していると判断し、本提案を支持します。\n\nI vote Yes on this proposal. Dingo is an important initiative that increases node implementation diversity in Cardano as a Go-based node independent of the Haskell implementation, contributing to the network’s decentralization and resilience. Furthermore, I consider Blink Labs to have sufficient technical expertise and a strong development track record, and therefore support this proposal.
- Yes 8.1M ₳ No rationale
- Yes 7.1M ₳ Rationale
We are in a tough market, for sure. I was always going to support node diversity proposals for Cardano in 2026. These alternative node implementation proposals by established yet independent Cardano teams have the added benefit of giving us more resilience, more surface area with non-Haskell developers, retaining a wider pool of Cardano-committed talent, and the ability of expanding the Cardano gene pool (code pool) - ensuring we have more options down the line. We have funded a lot of expensive fantasy projects through Catalyst. I mention that not because I want to single out Catalyst, but because I had lot of insight into projects that received funding in the past years. It is what it is. We are where we are. Putting all our eggs in the Haskell basket may seem cheaper, but it will not be. A biological analogy probably could work here. The more diverse the gene pool of a population - the more potential resilience it is likely to have when (not if!) the environment becomes adverse. The environment will turn against us, maybe it is already. Reliance on one node - could be the path to Cardano's eventual death on top of an ivory tower. I understand the need to be cautious with spending. It definitely is necessary. Yet, taking a misplaced revenge hammer to what is an internal insurance policy for a blockchain is no solution. Finally, I am happy to see teams like Amaru, Blink Labs and soon HLabs putting forth their own proposals. It is more expeditious, feedback can be received faster. DReps know what they are voting on. Personally, I hate bundled proposals - and this direct approach to funding is appreciated.
- Yes 6.8M ₳ No rationale
- No 6.2M ₳ Rationale
I completely agree with the importance of node language diversity, but I don't think this proposal should be a high priority right now. I support the idea, just not at this time.
- Yes 6M ₳ Rationale
I'm voting YES on the Dingo proposal by Blink Labs.The requested ₳6,900,000 is a relatively small, low-risk allocation relative to the Cardano treasury's overall size, making it a prudent step toward advancing essential node diversity. This proposal doesn't need to be funneled through the Intersect budgeting process; we should deliberately exercise direct treasury pathways when suitable to test and refine governance alternatives. Over-reliance on a single mechanism—even a collaborative one like Intersect—could inadvertently centralize decision-making, which runs counter to the decentralization we champion. Node diversity remains a foundational requirement for long-term network resilience and security, and we've consistently affirmed that Cardano should avoid dependence on any single large entity, consortium, or implementation. That same principle applies to funding: direct treasury proposals merit fair, case-by-case evaluation without mandatory redirection.On its merits, Blink Labs brings a proven track record of open-source contributions to the ecosystem. Supporting this initiative backs an independent team leveraging Go—a widely accessible language—ensuring we don't concentrate efforts on just one alternative (Haskell or otherwise). Genuine diversity demands multiple teams with varied skill sets and approaches, reducing single points of failure and fostering innovation across the protocol.This aligns squarely with community goals of building a more robust, decentralized Cardano while balancing progress with prudent risk management. It also resonates directly with my own objectives as a DRep: striking a thoughtful balance in governance actions that serve both short- and long-term ecosystem health, prioritizing continuous improvement.
- Yes 5.5M ₳ No rationale
- Yes 5.3M ₳ Rationale
Yes, market traction and protocol revenue should be prioritised. Blink labs has put together a solid proposal and I hope to see updates along the way.
- Yes 5.3M ₳ No rationale
- Yes 4.8M ₳ No rationale
- Yes 4.8M ₳ No rationale
- No 4.5M ₳ No rationale
- Yes 4.4M ₳ No rationale
- Yes 4.2M ₳ No rationale
- Yes 4.1M ₳ No rationale
- No 4M ₳ No rationale
- No 3.8M ₳ Rationale
While I recognize the potential value of additional Cardano node implementations—particularly one written in Go—and I respect the work this team has already done, I cannot support this proposal in its current form.
My decision follows a simple framework that I will apply consistently to similar proposals.
⸻
- Does this proposal require comparison with alternative approaches?
Yes.
Node implementations are among the most complex and mission-critical components of the Cardano protocol.
Cardano’s existing node—developed in Haskell—already follows rigorous engineering and review processes designed to maximize resilience and correctness. Even so, experts acknowledge that distributed systems at this scale are never completely risk-free.
Introducing additional node implementations increases the complexity of maintaining consensus across the network. Any divergence between clients could have severe consequences.
Because of this, alternative node implementations should not be evaluated in isolation. They must be assessed comparatively alongside other potential approaches, considering architecture, operational risk, and long-term maintenance implications.
This proposal therefore requires deep technical evaluation relative to competing designs, not a standalone yes/no vote.
⸻
- Does this proposal require expert prioritization and trade-off analysis?
Yes.
Proposals affecting protocol infrastructure involve trade-offs across multiple dimensions:
• network security
• engineering complexity
• ecosystem coordination
• long-term maintenance costs
• opportunity cost versus other protocol workThese decisions are best made through structured evaluation by domain experts who can compare alternatives and determine sequencing and priorities.
A global governance vote works well for many ecosystem initiatives, but core infrastructure decisions require coordinated technical review before they reach the treasury voting stage.
⸻
- Is it clear this team represents the strongest available option?
I have reservations.
As part of my due diligence, I reviewed the professional backgrounds and public work and posts of the team members.
While I respect the effort that has gone into this proposal, the documentation does not demonstrate why this team or approach should be prioritized over other potential teams or architectures that might pursue a similar goal.
When funding protocol-level infrastructure, the burden of proof should be very high.
⸻
- Should node development be funded as an isolated treasury withdrawal?
In my view, no.
Client diversity is not a standalone feature—it is a strategic infrastructure decision.
Multiple node implementations affect:
• protocol governance
• long-term maintenance obligations
• upgrade coordination
• security response processesFor these reasons, node development should emerge from a coordinated platform strategy, ideally guided by technical leadership evaluating multiple competing approaches.
Treasury funding may ultimately support such work—but only after a structured process determines which solution should be prioritized.
⸻
Conclusion
For these reasons, I cannot support this proposal in its current form.
My vote against this proposal should not be interpreted as opposition to additional node implementations. On the contrary, client diversity will certainly eventually become a critical part of Cardano’s long-term architecture.
However, decisions of this magnitude should arise from a coordinated technical strategy that compares alternatives and aligns incentives across the ecosystem—not from isolated vendor proposals presented directly to treasury voters based on the vendors own unilaterally defined KPIs, timeline, and cost.
- Yes 3.7M ₳ Rationale
Blink Labs is undoubtedly an excellent team, and node diversity remains a crucial element for Cardano’s long term security and resilience. Given the current stall in Catalyst funding and the importance of prioritizing core Cardano development over scattered projects, I believe this proposal represents a strong and strategic use of treasury resources. I support it as a worthwhile investment in the ecosystem’s foundational infrastructure.
- Yes 3.7M ₳ No rationale
- Yes 3.5M ₳ No rationale
- No 2.8M ₳ Rationale
As much as I love what Blink Labs has done with Dingo, I have already voted yes on one alternative node (Amaru), and I belive this is all the Cardano ecosystem can financially support at this time. Alternative nodes in different programming languages are important for longevity and long term security, but we just voted on huge spending for major infrastructure updates last year, and I believe any spending now needs to be focused on ROI for ADA holders and financial benefits for the chain. In the future I would look at voting yes to support a 3rd node, most likely in 5 years time unless the financial status of the Cardano ecosystem improves significantly sooner.
I would also like to see this proposal submitted as part of the Intersect budget process. This is a better way for the Cardano community to work together and establish a formal budget and spending system that is transparent and accountable.
- Yes 2.7M ₳ No rationale
- No 2.6M ₳ Rationale
I am voting “No” for one reason only — the requirement for a single large withdrawal of funds. We have already been burned by this approach enough times. Please split your request into milestones and submit each of them separately.
- Yes 2.5M ₳ No rationale
- Yes 2.5M ₳ Rationale
I'd like to see the multi block production vision realized. I'd like to start with 3 node types supported by the treasury and no more.
- Yes 2.5M ₳ Rationale
Cardanoの現状では、ブロック生成ノードは事実上単一実装であり、長期的には single point of failure のリスクを伴います。
その意味で、Goによる独立したノード実装を進める本提案は、ネットワークのレジリエンスとクライアント多様性の向上に資する重要な取り組みであり、技術的方向性は高く評価しています。
一方で、ストレージのスケーラビリティ検証は極めて重要です。将来のネットワーク規模においても安定して運用できることについて、今後の検証と説明の充実を期待します。
提案された予算規模と開発実績を踏まえると、費用対効果も良好と考えます。
以上を踏まえ、本提案を条件付きで支持します。
Cardano currently relies on a single block-producing node implementation, which may create a single point of failure risk over the long term.
In this sense, developing an independent Go-based node is an important effort that can improve network resilience and client diversity. I highly appreciate the technical direction of this proposal.
However, storage scalability verification is extremely important.
I hope to see further testing and clearer explanations showing that the system can operate reliably as the network grows.Considering the proposed budget and the team’s development track record, the cost-effectiveness also appears reasonable.
Based on these points, I support this proposal with conditions.
- Yes 2.5M ₳ Rationale
First Rationale:
I really think node diversity is very important to our continued growth as a blockchain. I also have a lot of respect for the Blink Labs team. Unfortunately, i see no semblance of balance in what is being funded through the treasury. We continually fund the technology but not the business development. I will likely be voting no on any additional nodes until there is a semblance of focus on business development in Cardano. If the value is there, I could be convinced. That said, the FTE costs associated with this proposal are way too high. Most teams in Cardano are barely making paychecks, it hardly makes sense to pay premier salaries for more node diversity at this time.Current Rationale (Changed to Yes): After speaking with the teams, it is clear that node diversity was as important as i thought. Spending the amount we do on maintenance of the main node made me a little sick to find out. Additionally, it is completely monopolized right now. In order for us to sufficiently be protected, 3 nodes should be the minimum.
It's also been made clear to me that this does align with pushing towards business and outside opportunities. It also brings down maintenance costs.
I still stand that the salaries are high, but not when it comes to the level of work that they would be completing. There are certainly specialists required in these roles.
I have changed my vote to "yes"
- Yes 2.4M ₳ No rationale
- Abstain 2.4M ₳ No rationale
- No 2.4M ₳ No rationale
- Yes 2.3M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
Vote: YES
This proposal represents a high-impact investment in core infrastructure resilience and decentralisation, which are foundational to Cardano’s long-term success. Today, block production relies on a single Haskell implementation, creating systemic risk. Dingo introduces a second independent node implementation in Go, materially improving network robustness—an approach proven effective in ecosystems like Ethereum.
Blink Labs has demonstrated credible delivery capability, with substantial prior output (1,000+ PRs, full Plutus conformance, working infrastructure components already in production). This is not a speculative idea, but an advanced, partially completed system requiring funding to reach mainnet readiness.
From a cost and ROI perspective, the proposal is reasonable and competitive. The requested 6.9M ADA (~$2.07M) covers a full year of engineering, audit, and delivery, and is priced conservatively relative to comparable efforts. The inclusion of a security audit, milestone-based escrow, independent oversight board, and on-chain accountability mechanisms significantly reduces execution risk and aligns with responsible treasury usage.
Importantly, the proposal is strongly aligned with the Cardano Constitution (v2.4):
Supports ecosystem growth and technical decentralisation
Includes transparent fund administration and auditability (Article IV)
Respects Net Change Limit constraints
Provides clear reporting, verifiability, and governance safeguardsStrategically, this also strengthens Cardano’s readiness for future upgrades such as Leios and Dijkstra, while expanding accessibility to a broader developer base via Go—supporting long-term ecosystem growth.
Overall, this is the kind of high-leverage, infrastructure-level investment the treasury should fund: it improves resilience, unlocks developer participation, and delivers lasting public goods under strong accountability frameworks.
This is the right thing to do for the network.
- No 2M ₳ Rationale
We voted NO because it's unclear whether SPOs are truly ready to use the alternative node, and we don't fully understand their needs and priorities. Investing in a solution with an uncertain adoption rate and unmeasurable benefits is quite risky. Not to mention the need for continued support in the coming years, which puts pressure on the entire ecosystem.
Currently, ADA prices are low, and we need to consider other, more pressing ecosystem needs. The builder community we're involved in has stated that because Catalyst paused funds 15 and 16, they lack the resources to continue building. Therefore, the funds need to be directed towards projects that directly impact user acquisition and growth.
- Yes 1.9M ₳ No rationale
- No 1.9M ₳ No rationale
- Yes 1.8M ₳ No rationale
- No 1.8M ₳ Rationale
I am voting No on Dingo: a Production-Grade Block Producer in Go by Blink Labs because, in fairness and to maintain consistency, proposals of this scale should be evaluated within the newly adopted Cardano Budget Process Framework. Applying the framework uniformly helps ensure transparent prioritization, comparability across proposals, and disciplined Treasury allocation. This decision should not be taken as a rejection of the underlying work—I am generally supportive of the effort and see its potential value—but I believe it is more appropriate to assess and fund it through the standard budgeting process going forward.
- Yes 1.7M ₳ 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.
- Abstain 1.7M ₳ No rationale
- Yes 1.7M ₳ Rationale
After much thought and discussion with tech minded individuals, I have decided to support this as the reward is high vs. the risk, I think it will be a positive for the ecosystem.
- Yes 1.7M ₳ No rationale