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 592.3M ₳ Rationale
Yoroi DRep votes YES on "Dingo: a Production-Grade Block Producer in Go by Blink Labs." Yoroi views this proposal as a constructive contribution to Cardano’s long-term infrastructure resilience and multi-client strategy.
Rationale
• Node diversity and resilience
Yoroi supports initiatives that strengthen network resilience by reducing dependence on a single node implementation. A Go-based node meaningfully contributes to a more robust and fault-tolerant Cardano infrastructure.
• Blink Labs’ contribution and delivery credibility
Blink Labs has demonstrated consistent commitment to Cardano through active open-source contributions and clear progress on Dingo. Their existing work provides confidence in their ability to continue delivering on this proposal.
• Alignment with Cardano’s long-term direction
Yoroi views this proposal as supportive of Cardano’s evolution toward a multi-client ecosystem and consistent with its broader 2030 strategic direction. In addition, a Go-based implementation expands accessibility, enabling a broader range of developers to engage with and contribute to core infrastructure.
Conclusion
Yoroi supports this proposal as a positive step toward broader node diversity and stronger infrastructure for the Cardano ecosystem. Yoroi looks forward to seeing Blink Labs continue building and delivering on this effort for the benefit of the wider Cardano community. - Yes 428.5M ₳ Rationale
I vote YES to "Dingo: a Production-Grade Block Producer in Go by Blink Labs".
I tested it on the mainnet before optimization, and the experience was seamless except for the storage requirements. There are also reports that it ran on the preview testnet with lower requirements than Haskell nodes.
I think it's important that it's written in Go, making it easier for SPOs to evaluate the software's nature and updates compared to Haskell.
Furthermore, price competition in node development is extremely important.
IOE / Amaru / Dingo
Total (USD): $48.4M / $3.04M / $2.07M
Duration: 12 months / 12 months / 12 months
FTEs: undisclosed / 8.5 / 4
FTE rate: ~$302-346k / $225k / $250k
Audit: $2.15M / $500k / $500k
Fund admin: Intersect / Smart contract + PRAGMA 5名 / Smart contract + 独立3名
Language: Haskell / Rust / Go私は「Dingo: a Production-Grade Block Producer in Go by Blink Labs」にYESを投票します。
私は最適化前のメインネットでの稼働を試しましたが、ストレージ等の必要要件以外はシームレスな体験でした。プレビューテストネットではHaskellノードよりも低い要件で稼働されたという報告もあります。
GO言語で記載されていることにより、Haskellよりも比較的SPOがソフトウェアの性質やアップデートを評価しやすくなっていることは重要に思います。
また、ノード開発の価格競争は非常に重要です。
IOE / Amaru / Dingo
Total (USD): $48.4M / $3.04M / $2.07M
Duration: 12 months / 12 months / 12 months
FTEs: undisclosed / 8.5 / 4
FTE rate: ~$302-346k / $225k / $250k
Audit: $2.15M / $500k / $500k
Fund admin: Intersect / Smart contract + PRAGMA 5名 / Smart contract + 独立3名
Language: Haskell / Rust / Go - Yes 297.4M ₳ Rationale
Summary
EMURGO, as a DRep, votes YES on the treasury withdrawal proposal titled "Dingo: a Production-Grade Block Producer in Go by Blink Labs," with rationale outlined below.
Rationale
EMURGO supports this proposal as a meaningful step toward strengthening node diversity within the Cardano ecosystem. Advancing multiple independent node implementations is important for improving network resilience, reducing reliance on a single codebase, and supporting the long-term decentralization of Cardano.
The Dingo project represents a credible and well-progressed effort toward delivering a production-grade Go-based node. Blink Labs has demonstrated strong technical capability and consistent contributions to the ecosystem through projects such as gOuroboros and Plutigo, alongside measurable progress on Dingo itself. EMURGO recognizes Blink Labs as a serious contributor whose work has already added value to the Cardano ecosystem.
From a strategic perspective, this proposal aligns with the Cardano 2030 Strategic Framework, particularly the primary core KPI of achieving ≥ 2 live, spec-conformant alternative full node clients. Supporting Dingo contributes directly to this objective while broadening Cardano’s technical base. A Go implementation also improves accessibility for a wider pool of developers and operators, supporting long-term ecosystem growth.
The proposal also includes milestone-based delivery, oversight mechanisms, and transparent reporting, providing a reasonable level of accountability for treasury funds. For these reasons, EMURGO votes YES. - Yes 240.8M ₳ No rationale
- Yes 221.8M ₳ Rationale
TL;DR: EDC votes YES on gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe;
We revised our vote on Dingo from NO to YES. Going forward, for node diversity, we will support the Haskell, Rust, Go, and TypeScript implementations.
Reasoning: If we introduce more than one node implementation, we need to add more than one additional implementation. Think of different node implementations as a multi-signature wallet controlled by two parties that do not trust each other. If one of the nodes introduces bugs or changes the ledger rules, whether intentionally or not, we do not want a 50/50 chain split. We want at least two honest and correct node implementations to prevent a situation similar to the one we had in November 2025.
We expect the maintenance cost to be significantly lower than the cost of implementing the different nodes now. Spend responsibly.
TL;DR: If you support node diversity, you need to choose at least two additional node implementations in addition to the Haskell one.
- Yes 174.4M ₳ Rationale
The Dingo team has done impressive work. Developer agility at the protocol level (how long it takes for the community to experiment and decide on shipping protocol-level improvements) continues to be one of the largest hurdles in the growth of the project, and Dingo seems to be the team furthest along in tackling this issue at this point.
The usage of Go over Rust is a very unfortunate choice when it comes to interoperability with a lot of the cryptography ecosystem (especially in zkVMs which I believe are the future of most projects) as well as poorer interoperability with Wasm (which I also believe is the future of the web for most use-cases).
However, with AI, which language you choose to get something done now-a-days is a lot less of an issue than it used to be in the past. As long as it's possible to write a good reference implementation of something in some language, AI is usually pretty good at converting it to another language passing the same set of test suites. That means that any work Blink Labs does generally to improve client diversity (documenting edge-cases, contributing to the specs, providing a high-quality implementation) benefits any other attempts.
At the same time, the growth of AI has made replacing the Haskell node also less important than it used to be (for the same reason)Given this, voting "Yes" for this proposal is a hard decision for me. However, I also recognize for the need to be pragmatic and move things forward, as cryptocurrencies cannot easily stand still waiting for the team to come and build the perfect thing. You have to work with what you've got, and we've got a good team with Blink Labs.
- Yes 160.5M ₳ No rationale
- Yes 135.1M ₳ Rationale
The Cardano Foundation votes YES. Node diversity is critical for network resilience. Funding a Go-based node (Dingo) alongside Haskell and Rust implementations will foster a highly secure, multi-client ecosystem.
A PDF version of this rationale is also made available.
Our support for this proposal is driven by the following key factors:
Strategic Value of a "Go" Node: Beyond pure diversity, Go (Golang) is one of the industry standards for high-performance blockchain infrastructure (e.g., Ethereum's Geth). By funding a production-grade Go node, Cardano opens its core infrastructure to an ecosystem of over 5 million Go developers. This significantly lowers the barrier to entry for enterprise integrations and cloud-native deployments.
Proven Delivery & Ecosystem Contribution: Blink Labs is an established participant within Cardano's open-source ecosystem. The team has either built or contributed to multiple projects (gOuroboros, Plutigo, Adder) and has a track record of delivering high-quality code. Additionally, their progress on Dingo is already measurable.
Ada price: We commend Blink Labs for pricing their ada request at a realistic, near-market rate of $0.30/ada, rather than the artificially high rates seen in other proposals. This is realistic budgeting and sets a standard.
Accountability & Oversight: The use of milestone-based disbursements signed off by an independent, three-person oversight board (Pi Lanningham, Santiago Carmuega, Lucas Rosa), who hold no stake in Blink Labs and possess the power to halt funding, provides strong downside protection for the Treasury while delivery is ongoing.
Constructive Feedback & Expectations
While we fully support this withdrawal, we note a few areas for improvement and future clarification:
Audit Scope & Quotes: While we fully-agree that a top-tier security audit before mainnet deployment is necessary, $500,000 is at the top end of the market. We strongly recommend that the team obtain competitive quotes and publish the audit's scope of work. Ideally, any excess funding from this line item will be returned to the treasury via the failsafe sweep.
Cost Synergies on Leios: The proposal notes that the CIP-0164 Linear Leios prototype will be built in parallel with IO Engineering. If there are shared learnings or parallel development efforts occurring, we expect the team to clarify the commercial relationship and leverage these synergies to ensure cost and time efficiencies for the Go implementation.
Proposal Discussion: Earlier DRep engagement and discussion in public forums such as the Cardano Forum can help improve community alignment with a proposal. This is purely an observation and a suggestion for future proposals to be as well-received as possible, as the circumstances of proposals can differ.
The Cardano Foundation votes YES. Funding Dingo is a strategic investment in Cardano's operational resiliency and developer accessibility, moving the network toward the multi-client gold standard.
NOTE on 'Internal Voting':
The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well. - No 93.3M ₳ Rationale
As a DRep, I have decided to vote NO on the proposal: Dingo: a Production-Grade Block Producer in Go by Blink Labs
My rationale:
I mentioned the reasons for supporting node diversity in the proposal regarding Amaru. The same applies to other implementations.
ID: gov_action19uhuy5uame2s60yrh6n8cyds8ps5q7tkh05dqlzmpcfy429p9w4qq5ll3g0
From a network perspective, it is ideal to have at least 3 node implementations with an even representation in the network based on stake (33.3%).
Why am I not supporting Dingo at this moment?
Intersect launched a budget process last week. I recommend that all projects seeking funding do so as part of this process. All DReps need to make decisions in the context of other proposals.
I will not approve any withdrawals during the Intersect process that will circumvent it. This is a fair approach with respect to other proposals. If a project does not want to participate in this process, it has to wait until it is finished and hope that the spending does not reach the NCL.
It is very likely that other projects like the Gerolamo node will seek funding. At this point, I do not know how many proposals regarding node diversity will be submitted. A first-come, first-served approach is not a suitable approach for such a large and important investment. It is necessary to select the best proposals and support them.
The community must first agree on how many alternative implementations we want to support. Are 3 enough for us, or do we want to support 4 (Haskell, Amaru, Dingo, Gerolamo, possibly others)? We do not know if SPOs will be willing to install alternative nodes and what their preferences are. This debate has not even started.
So, there is no reason to rush to fund alternative nodes. I will follow the debates on this topic and read the rationales.
There is still an active proposal regarding lowering the NCL to 300M ADA. Another one will likely be submitted. The debate on NCL is not closed yet, which is another source of uncertainty.
The budget is limited due to the low price of ADA. I have to think about the other needs of the ecosystem. Builders are making it clear that they don’t have the resources they need, following the cancellation of Catalyst Fund15 (and Fund16). This is another reason not to rush to support infrastructure investments.
Let’s ensure sufficient funding is secured for projects with a direct impact on acquiring new users. Cardano needs user growth. Node diversity has an indirect effect on this (network stability). This line of thinking is also supported by a significant part of the community, which makes it clear that we should prioritize investments in ecosystem growth over excessive investments in infrastructure.
It is necessary to realize that investing in an alternative node means ongoing support for the coming years. As the Ouroboros consensus and other layers develop, it will be necessary to fund maintenance and changes in all nodes once we start. This is another reason to find a consensus in advance among DReps about which versions we want to support and why. It is a permanent investment in a new team.
Another reason concerns the broader perception of decentralization.
I see node diversity as an investment in decentralization. I see block production and governance as one system. If there are flaws in the system, they must be addressed.
We cannot invest tens of millions of ADA in block production infrastructure and, at the same time, tolerate unfunded and centralized governance.
Imagine a basket with a limited budget for decentralization. Resources must be allocated where they are most needed. There is no point in investing in 2, 3, or even 4 node implementations in the same year, when in governance, the top 5 DReps with voting power of 33.1% can prevent the approval of Treasury Withdrawals, a hard fork, or a constitutional amendment.
We have 1000 registered DReps, but only 20-25% vote. Almost all proposals are approved just before expiration.
One CC member retired because they were not willing to continue working for free for governance. This halted governance. DReps had two options to prevent this situation from happening again, but they did not use either of them.
If we invested the funds that Dingo requires in governance, we could address many problems. We launched on-chain governance, so it is necessary to take care of it. The investment in Cardano decentralization will be unbalanced if we invest everything (from the basket) only in block production.
To be clear, I plan to support the development of more alternative nodes if there is a budget for it. However, only after the NCL debate is concluded, the community agrees on how many nodes we need, the SPOs express their preferences, and the budget for additional builders is secured. We need to know when Catalyst will be relaunched, with what budget, and what other alternatives we have for builders.
I encourage the Dingo team and everyone else to participate in the Intersect budget process.
- Yes 92.1M ₳ No rationale
- Yes 89.8M ₳ Rationale
SIPO DRep votes YES on Dingo: a Production-Grade Block Producer in Go by Blink Labs.
SIPO supports this proposal as a strategically important investment in Cardano's node diversity and long-term network resilience. Having already voted YES on Amaru (Rust implementation), SIPO's support for Dingo (Go implementation) follows the same principled logic: a multi-client architecture with three independent implementations — Haskell, Rust, and Go — is the proven model for critical blockchain infrastructure.
Why SIPO votes YES
Node diversity requires more than two implementations
SIPO voted YES on Amaru because node diversity is essential for network resilience. That reasoning applies equally to Dingo. Ethereum's multi-client architecture has repeatedly saved the network from catastrophic failures — most recently in March 2026, when a Prysm bug after the Fusaka upgrade caused a 25% drop in validator participation, coming within 9% of finality loss. The network survived because other clients continued operating. Cardano currently depends on a single Haskell implementation for block production. Haskell + Rust + Go provides the kind of defense-in-depth that Ethereum's experience proves necessary.Go is the industry standard for blockchain nodes
Go powers Geth (Ethereum), btcd (Bitcoin), CometBFT (50+ Cosmos chains), AvalancheGo, Algorand, and Filecoin. With over 5 million active developers and a 7th-place TIOBE ranking, Go opens Cardano's node internals to a massive developer pool. This is not about replacing Haskell — it is about making Cardano accessible to the developers who build the world's networked systems.Demonstrated engineering velocity
Blink Labs has merged 1,290+ non-dependency PRs in the past twelve months, with 593 in the last quarter alone — accelerating. With 2-3 engineers, that is approximately 36 PRs per person per month. Dingo passes 314/314 Amaru conformance tests and achieves 100% Plutus V1/V2/V3 conformance. These are objectively verifiable metrics, not promises.Leios co-implementation strengthens the specification
Dingo's plan to implement CIP-0164 Linear Leios alongside IO Engineering is strategically valuable beyond node diversity. When two teams implement the same protocol in two different languages, ambiguities in the specification surface faster. Go's concurrency model (goroutines and channels) is well-suited for the pipeline concurrency Leios requires.Cost efficiency and honest pricing
At 6,900,000 ADA ($2,070,000 at $0.30/ADA), this proposal is approximately 32% less than Amaru's 10,142,000 ADA request. The $250,000 per FTE is market-rate. Other treasury-funded implementations priced at $0.50/ADA — at which rate this proposal would be only 4,140,000 ADA.Sound governance structure
Funds are held in the audited SundaeSwap treasury smart contracts with an independent oversight board (Pi Lanningham / SundaeSwap, Santiago Carmuega / TxPipe, Lucas Rosa / Aiken-Midnight). Auto-abstain DRep delegation, no SPO delegation, failsafe sweep at contract expiration. Monthly updates, quarterly detailed reports, and a public transaction journal.
Expectations
- Q2 testnet block production as a hard gate: Clear, publicly documented gating criteria with reproducible evidence.
- Team scaling execution: Early reporting on recruitment of 3 Go developers to reach 4 FTE capacity.
- Differentiation from Amaru: Both teams should articulate distinct value propositions and share infrastructure where possible.
- Mainnet storage validation: Transparent reporting on Q3 storage scalability testing at ~100M UTxOs / ~500 GB.
- Post-funding sustainability: A clear maintenance plan after the 12-month treasury funding concludes.
- Security audit transparency: Full publication of findings and remediation of all critical issues before any mainnet recommendation.
- Contingency discipline: The 15% contingency must remain a risk buffer with transparent accounting.
Node diversity is not a luxury — it is infrastructure insurance. Combined with Amaru, the total node diversity investment of approximately 17M ADA represents less than 5% of the NCL — a proportionate allocation for one of Cardano's most important long-term resilience strategies.
For these reasons, SIPO DRep votes YES.
SIPODRepとして、本提案「Dingo: a Production-Grade Block Producer in Go by Blink Labs」に賛成（YES）を投じます。
SIPOは本提案を、Cardanoのノード多様性と長期的なネットワーク強靭性に対する戦略的投資として支持します。すでにAmaru（Rust実装）にYESを投じたSIPOが、Dingo（Go実装）を支持するのは同じ原則的論理の延長です：Haskell・Rust・Goの3つの独立した実装によるマルチクライアント体制こそ、重要なブロックチェーンインフラで実証されたモデルです。
SIPOがYESと判断する理由
ノード多様性には2実装では足りない
SIPOはネットワーク強靭性にノード多様性が不可欠という理由でAmaruにYESを投じました。同じ論理はDingoにも等しく適用されます。Ethereumのマルチクライアント体制は、壊滅的な障害からネットワークを繰り返し救ってきました。直近では2026年3月、Fusakaアップグレード後のPrysmバグによりバリデータ参加率が25%低下し、ファイナリティ喪失まで残り9%という危険水域に達しました。他のクライアントが稼働を継続したためネットワークは存続しました。Cardanoは現在ブロック生成においてHaskell単一実装に依存しています。Haskell + Rust + Goの組み合わせこそ、Ethereumの経験が必要性を証明した多層防御を実現します。Goはブロックチェーンノードの業界標準言語
GoはGeth（Ethereum）、btcd（Bitcoin）、CometBFT（50以上のCosmosチェーン）、AvalancheGo、Algorand、Filecoinを動かしています。500万人以上のアクティブ開発者とTIOBE指数7位というポジションにより、GoはCardanoのノード内部を膨大な開発者プールに開放します。これはHaskellの置き換えではなく、世界のネットワークシステムを構築している開発者へのアクセシビリティの拡大です。実証された開発ベロシティ
Blink Labsは過去12ヶ月で1,290以上の非依存PRをマージし、直近四半期だけで593件と加速しています。2-3名のエンジニアで月約36 PR/人のペースです。Dingoは314/314のAmaruコンフォーマンステストに合格し、Plutus V1/V2/V3の100%準拠を達成しています。これらは約束ではなく、客観的に検証可能な指標です。Leios並行実装が仕様品質を高める
DingoがIO EngineeringとともにCIP-0164 Linear Leiosを並行実装する計画は、ノード多様性を超えた戦略的価値があります。2つのチームが同じプロトコルを2つの異なる言語で実装すると、仕様の曖昧さがより早く浮上します。Goの並行処理モデル（goroutineとchannel）はLeiosが必要とするパイプライン並行処理に適しています。コスト効率と誠実な価格設定
6,900,000 ADA（$0.30/ADAで$2,070,000）は、Amaruの10,142,000 ADA申請と比較して約32%低額です。FTE単価$250,000は市場水準です。他のトレジャリー資金実装が$0.50/ADAで価格設定した中、同水準なら4,140,000 ADAに相当します。健全なガバナンス構造
資金は監査済みSundaeSwapトレジャリーSmart Contractに保持され、独立Oversight Board（Pi Lanningham / SundaeSwap、Santiago Carmuega / TxPipe、Lucas Rosa / Aiken-Midnight）が監督します。Auto-abstain DRep委任、SPO委任なし、契約満了時の自動sweepが契約レベルで強制されます。
期待事項
- Q2テストネットブロック生成をハードゲートとして：明確で公開されたゲート条件と再現可能な証跡を期待します。
- チームスケーリングの実行：4 FTE体制に向けた3名のGo開発者採用進捗の早期報告を求めます。
- Amaruとの差別化：両チームがそれぞれの独自価値を明示し、可能であればインフラを共有することを期待します。
- メインネットストレージの検証：Q3における約1億UTxO/約500GBでのストレージスケーラビリティテストの透明な報告を求めます。
- 資金終了後の持続可能性：12ヶ月のTreasury資金終了後の明確なメンテナンス計画を求めます。
- セキュリティ監査の透明性：結果の完全公開とメインネット推奨前の全重大問題の是正を期待します。
- コンティンジェンシーの規律：15%のコンティンジェンシーはリスクバッファであり、透明な会計を維持すべきです。
ノード多様性は贅沢品ではなくインフラ保険です。Amaruと合わせたノード多様性への総投資額約17M ADAはNCLの5%未満であり、Cardanoの最も重要な長期的強靭性戦略の一つとして適切な配分です。
以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。
- No 89.3M ₳ Rationale
Node diversity is extremely important for the ecosystem. However, there are several different initiatives seeking funding this year for node development and this proposal should be compared alongside the others once we see them during the Intersect budget process. So, this is a "no" vote as to timing. This proposal should be considered later.
- Yes 89.2M ₳ Rationale
I was deeply impressed by the advice of such talented engineers, and it led me to reconsider my view of this proposal.
In light of the astonishing recent advances in AI models, I felt that we should distribute stake across multiple nodes in order to avoid risks beyond what we can even imagine. Cardano has maintained a highly secure chain through research based on peer-reviewed papers, but the single-node structure has become its one remaining weakness. I concluded that Amaru and Dingo, with their different architectural approaches, can help minimize the impact of vulnerabilities.
That said, this change should also be seen as acknowledging Blink Labs track record to date, and it does not necessarily apply to all node development efforts.
- Yes 77.3M ₳ No rationale
- Yes 76.1M ₳ Rationale
This is the closest alternative node client to mainnet block production readiness. It is an absolute must for the ecosystem.
A PDF version of this rationale is also made available.
nVoting no to Dingo is voting no to the alternative node that is closest to mainnet readiness at the lowest cost to deliver. \n\nThe value proposition of Dingo is insane, they are so far along, this will push them to the finish line and Cardano will have its first alternative node client, which will create competition and drive down development costs for all the other nodes in the ecosystem.
- Abstain 74.7M ₳ Rationale
Proposal itself is good. Therefore, I don't like to vete No. However, the importance of this proposal for the current Cardano situation is not reached to vote Yes. So I want to put abstain vote in present.
- Abstain 71.3M ₳ Rationale
I now vote ABSTAIN. Blink Labs' recent progress and community discussions proved Dingo's value. Though Treasury conservation & strategy prevents a YES for me right now, I will not stand in the way of this stellar team. This ABSTAIN is a formal nod of respect & acknowledgement of their hard work.
A PDF version of this rationale is also made available.
As a representative of my loyal delegates, this marks the first time I have ever changed a vote, which speaks to the deep consideration I have given this specific proposal since my last vote.
My initial NO vote was rooted in strict fiscal pragmatism. At the time, I felt strongly that funding a third node implementation was a luxury we could not afford, and that we needed to wait for Amaru's progress before taking on another permanent Treasury commitment.
However, over the past few weeks, I have actively listened to the Blink Labs team discuss Dingo in deeper detail across community Spaces. I have been genuinely impressed by the tangible progress they are making. Their passion and talent are undeniable, and they have successfully demonstrated the extreme, long-term value that increased node diversity brings to the resilience of the Cardano ecosystem, along with lots of other benefits Dingo will allow.
While my core philosophy regarding Treasury conservation means I still cannot comfortably support this with a YES vote right at this exact moment, I have realized that I do not want to stand against something I believe is highly valuable and impactful in addition to Amaru. I refuse to let my voting weight act as a roadblock to a passionate team of builders who I truly believe can deliver on their promises.
Therefore, my ABSTAIN vote is a formal nod of respect to the importance of node diversity and to Blink Labs. I am stepping aside to let the broader community decide this proposal's fate, without standing in the way.
- Yes 70.8M ₳ No rationale
- No 68M ₳ Rationale
I understand the importance of node diversity and recognize the technical progress made by the Dingo project. However, I am not able to support this proposal at this stage.
First, I feel that there is not yet a clearly defined framework or shared criteria within the ecosystem regarding how many alternative node implementations should be supported, how they should be prioritized, or how adoption among SPOs will be achieved. As multiple node implementations are being considered in parallel, funding them individually could lead to inefficient allocation of resources or unnecessary overlap.
Second, investing in an alternative node implementation is not a one-time expense, but a long-term commitment. As the protocol evolves, continuous support will be required for maintenance, upgrades, and compatibility with future changes. For this reason, I believe such decisions should be made within a broader strategic context rather than on a proposal-by-proposal basis.
In addition, given the limited treasury resources, I believe it is also important at this stage to prioritize initiatives that more directly contribute to user growth, developer onboarding, and real-world adoption. While node diversity is important for network resilience, its impact is more indirect and should be carefully weighed against other opportunities.
Finally, there is still uncertainty regarding actual adoption. It is not yet clear to what extent SPOs would operate alternative node implementations in practice, which makes it difficult to fully assess the expected return on this investment.
For these reasons, I believe that funding decisions for alternative node implementations should be considered after clearer alignment has been achieved on overall priorities, strategy, and long-term sustainability.
本提案におけるノード多様性の重要性や、Dingoの技術的な進展については理解しています。ただし、現時点では本提案を支持するには至りません。
まず、代替ノード実装の数や役割、優先順位、そしてSPOによる実際の採用をどのように進めていくのかについて、エコシステム全体として明確な方針や共通の基準がまだ整理されていないと感じています。複数のノード実装が同時に検討されている中で、個別に資金配分を行うことは、結果として非効率な資源配分や重複につながる可能性があると考えています。
また、ノード実装への投資は一度きりの支出ではなく、今後のプロトコルの進化やハードフォーク対応に伴って、継続的な保守や開発コストが発生します。そのため、単体の提案ごとではなく、より広い戦略の中で慎重に判断する必要があると考えています。
さらに、トレジャリー資金には限りがある中で、現段階ではユーザー獲得や開発者の参入促進、実利用の拡大といった、より直接的にエコシステムの成長につながる分野への投資も重要だと感じています。ノード多様性は重要な要素ではありますが、その効果は間接的であるため、他の提案との比較の中で慎重に評価すべきだと考えています。
最後に、SPOによる実際の採用についても現時点では不確実な部分が多く、本提案による投資対効果を判断する上で十分な見通しがあるとは言い切れないと感じています。
以上の点を踏まえ、代替ノード実装への資金配分については、エコシステム全体の優先順位や戦略、持続可能性についてもう少し整理が進んだ段階で検討すべきだと考えています。
- Yes 65.7M ₳ Rationale
Requested amount is massive but knowing Acropoli was booted and Amaru isn't there yet it's necessary
- Yes 62.7M ₳ No rationale
- No 53.8M ₳ No rationale
- Yes 51.1M ₳ Rationale
Same rationale as the Amaru proposal. Having multiple cardano nodes is a security need and should be funded for the greater good of the blockchain.
- Abstain 49.8M ₳ Rationale
I am voting Abstain on the 'Dingo: a Production-Grade Block Producer' treasury withdrawal, not because of the proposal itself, but due to concerns about the overall voting process.
At the moment, there is an approved total budget (350M), yet funding requests are being submitted independently as separate governance actions. This creates a fragmented and unclear landscape: it's difficult to understand the total number of proposals, the combined requested amount, or how close we are to exceeding the available budget.
Without this broader context, it becomes challenging to properly prioritize proposals, assess trade-offs, or compare similar initiatives. If the total requested funds exceed the budget, there is no clear framework for how decisions should be made across competing proposals.
For these reasons, I believe the current process lacks the structure needed for effective decision-making, and I am abstaining on that basis rather than on the merits of this specific proposal.
- No 49.7M ₳ Rationale
I am voting No on this proposal. I appreciate Dingo's technical capabilities and Catalyst contributions, but must reluctantly vote No, as with Amaru, due to treasury minimization principles. Reflecting on the problems observed over the past year: while technical improvements advanced, ADA experienced severe price inflation. Treasury withdrawals, despite their stated purpose of funding sound projects, impose economic costs that pressure SPOs and discourage new participants. This structural contradiction is weakening the staking foundation that secures Cardano. Cardano's security derives from staking, not treasury spending. Robust staking requires price stability and fair economic conditions. Minimizing treasury expenditure aligns with this fundamental proof-of-stake principle. Node diversity should be funded through voluntary investment, not treasury. If alternative implementations provide safety or economic benefits, SPOs will naturally invest in them. This market mechanism validates genuine value and eliminates implementations lacking real utility. Treasury funding bypasses this essential test. Treasury should fund only protocol development. The current treasury proposal system operates on a "first-come-first-served" basis without an annual budget framework, forcing decisions through incomplete deliberation while overall project importance and budget appropriateness remain opaque. Furthermore, node diversity implementations can proliferate indefinitely—funding them one by one will clearly strain the treasury. Approving implementations without clear boundaries invites indefinite category expansion. Voting No to protect staking economics and reserve treasury for protocol essentials. [Japanese version follows] 私は本提案に反対票を投じます。Dingoの技術力とCatalystでの貢献は評価していますが、Amaruと同様に、トレジャリー最小化の原則から、残念ながら反対票を投じることになりました。この一年で見てきた問題をもとに検討すると、技術的改善が進んだ一方で、ADAは深刻なインフレを経験しました。トレジャリー出金は、健全なプロジェクトに資金を提供しているという建前ながら、SPOに圧力をかけ、新規参加者を阻害する経済的コストを課しています。この構造的矛盾は、Cardanoを支えるステーキング基盤を弱体化させています。Cardanoの安全性はトレジャリー支出ではなく、ステーキングから生まれます。健全なステーキングには価格の安定性と公平な経済環境が必要です。トレジャリー支出を最小化することは、このProof-of-Stakeの基本原則に準拠した判断です。ノード多様性は任意の出資によってまかなわれるものであり、トレジャリーではありません。ノードが安全性や経済的な利点に基づくのであれば、SPOたちが自ら出資するでしょう。この市場メカニズムが真の価値を検証し、実用性のない実装を排除します。トレジャリー資金はこの本質的なテストを迂回します。トレジャリーはプロトコル開発のみに資金を提供すべきです。現在のトレジャリー提案は、年間予算という枠組みがない状態で「早い者勝ち」原則によって資金が投下され、そのプロジェクトの全体としての重要度や予算妥当性が不透明なまま、不完全な議論によって判断を強制されています。また、ノード多様性は無数に存在し得るものであり、１つ１つに出資していてはトレジャリーを圧迫することは明確です。明確な境界なしに実装を承認することは、このカテゴリーの無限の拡大を招きます。ステーキングによるエコシステムを守り、トレジャリーをプロトコルのコア開発のみに限定するため、反対票を投じます。
- Yes 48.4M ₳ No rationale
- No 42.4M ₳ No rationale
- Yes 40M ₳ No rationale
- Abstain 38.1M ₳ No rationale
- Yes 36.8M ₳ No rationale
- Yes 34.4M ₳ No rationale
- Yes 34.3M ₳ Rationale
Dingo represents the third independent node implementation for Cardano (after the Haskell cardano-node and the Rust-based Amaru), written in Go – one of the most widely used systems programming languages in the world. Go’s popularity among infrastructure engineers, cloud-native developers, and DevOps professionals means Dingo dramatically expands the potential contributor base for Cardano’s core node software. This is essential for long-term ecosystem sustainability.
Having three independent node implementations across three different programming languages (Haskell, Rust, Go) provides exceptional resilience against implementation-specific bugs, supply-chain attacks, and compiler vulnerabilities. If a critical bug affects one implementation, the network can continue to operate through the others. This multi-implementation model is proven in mature blockchain ecosystems like Ethereum (Geth, Nethermind, Besu, Erigon).
Blink Labs has a strong track record in the Cardano ecosystem, having built and maintained numerous open-source Go libraries and tools including gouroboros (Ouroboros protocol implementation in Go), Adder, Bursa, and others. Their deep familiarity with Cardano’s protocol internals from the Go perspective gives confidence in their ability to deliver a production-grade node. Dingo already supports full chain sync, 41 UTXO validation rules, Plutus execution across all versions, block production, and multiple API interfaces.
Dingo’s built-in API servers (Blockfrost-compatible, UTxO RPC) and native Mithril bootstrap support make it especially attractive for infrastructure operators and application developers who want a single binary that serves both consensus and data access needs. This integrated approach reduces operational complexity compared to running separate node and indexer stacks.
Some community voices, such as SnekArmy, have raised concerns about whether Cardano needs more infrastructure spending in current market conditions. However, node diversity is a long-term strategic investment that cannot be paused and resumed easily – the teams, knowledge, and codebases require sustained investment. Voting YES ensures continuity of a critical infrastructure project that strengthens Cardano’s competitive position against multi-client ecosystems. - Yes 32.3M ₳ Rationale
Yes. Go-language alt node by Blink Labs advances client diversity (Cardano 2030 KPI), opens node ecosystem to 5M+ Go devs, supports Leios throughput roadmap. Milestone-gated escrow, independent oversight board. Consistent with Amaru Yes vote.
A PDF version of this rationale is also made available.
Voting Yes. Direct parallel to Amaru (which I supported) - this is the Go-language alternative node, and the same Cardano First logic applies:
- Decentralization: Dingo is a production-grade Cardano block producer in Go. Another point on the client-diversity curve, directly aligned with the Cardano 2030 KPI. Network resilience comes from heterogeneous implementations, not redundant copies of the same codebase.
- Scalability: Blink Labs is building Leios alongside IO Engineering. Yes also signals support for the throughput roadmap.
- Adoption: Go is the language of cloud-native infrastructure (Kubernetes, Docker, Prometheus, Terraform). Dingo opens Cardano's node ecosystem to 5M+ Go developers and DevOps practitioners - a developer pool we cannot reach with Haskell alone.
- Economic Sustainability: Same SundaeSwap treasury-contracts escrow framework as Amaru, with an independent oversight board (Pi Lanningham, Santiago Carmuega, Lucas Rosa). Priced lower per-ADA than Amaru's previous cycle ($0.30 vs $0.50 reference), and the team has a track record (Blink Labs has been shipping Cardano Go tooling for years).
- Governance Transparency: Open source, milestone-gated, oversight board, auto-abstain delegation. Standard constitutional alignment.
Consistent with my Amaru and HLabs Yes votes - alt clients are non-negotiable infrastructure for Cardano's long-term health. Yes.
- Yes 31M ₳ Rationale
I am voting Yes on this proposal.
Network decentralization and security benefit greatly from having multiple independent node
implementations, and Dingo contributes meaningfully to that diversity. Blink Labs has a strong
track record, having delivered several important projects such as gOuroboros and Plutigo, and
their consistent contributions demonstrate the capability required for this work.While Amaru (Rust implementation) is currently ahead, having an additional implementation—or even
two—strengthens Cardano’s long‑term resilience and reduces reliance on any single codebase.Although 6.9M ADA is a substantial amount, the detailed budget breakdown shows that the costs are
allocated to essential areas such as engineering, auditing, infrastructure, and operations. The
structure appears reasonable and not inflated. For these reasons, I support this proposal. - Abstain 30.5M ₳ No rationale
- Yes 28.2M ₳ Rationale
Getting an alternate node to a Leios-ready state producing blocks on mainnet for 6.9M ADA is an absolute steal. Consider the costs that it has taken Cardano so far just to get the Haskell node to where it is at. Furthermore, Blink Labs has been consistently building open-source, foundational tools used by the entire Cardano community for years, and often for free. The $250k/yr ask per FTE makes sense when you consider the risks associated with ADA volatility, governance hangups, etc. Finally, alternate nodes specifically is one of the primary things I identified as a the highest need for Cardano right now. For these reasons I am happy to vote in favor of funding Dingo.
- Yes 27.9M ₳ No rationale
- No 27.4M ₳ No rationale
- Yes 26.1M ₳ No rationale
- Yes 25.9M ₳ No rationale
- Yes 25.2M ₳ Rationale
I am voting YES on Dingo: a Production-Grade Block Producer in Go by Blink Labs. I very strongly believe we absolutely must prioritize market traction and protocol revenue above all else. That being said there is immense value in reducing costs associated with node development/maintenance and SPO infrastructure overhead. Node diversity also reduces the surface area of attack relevant to censorship resistance of Cardano. I also believe it critical to continue supporting great ecsoystem contributors. Reporting from the front lines of adoption, the Blink team has earned this one.
- Yes 22.7M ₳ Rationale
bark bark bark
- No 22M ₳ No rationale
- No 22M ₳ Rationale
I am currently choosing to ABSTAIN/VOTE NO on the Dingo proposal. While I acknowledge the strategic importance of node diversity, I cannot reconcile the requested budget of 6.9 million ADA with the stated work scope and current ecosystem priorities.
- Financial Disproportion: The proposal requests an investment of ~$2M USD (at $0.30/ADA) for a 12-month development cycle. The breakdown, which includes a $500,000 security audit, appears inflated. We must demand a more granular, line-item budget disclosure to ensure that we are not paying a 'decentralization premium' that exceeds the project's actual engineering value.
- Lack of Comparative Analysis: The proposal fails to evaluate why a Go-based node is the most cost-effective path to network resilience. We have not seen a comparative analysis of other potential node implementations (e.g., Gerolamo) or a cost-benefit study against other infrastructure needs. In a capital-constrained environment, we must prioritize initiatives based on rigorous comparative data, not isolated vendor pitches.
- Strategic Sequencing: We are currently in the midst of defining the 2026 Budget Framework via Intersect. I believe all infrastructure proposals of this magnitude should be channeled through this framework. This would allow dReps to evaluate the Dingo proposal alongside other infrastructure needs, ensuring that 6.9 million ADA is indeed our highest-ROI allocation.
I invite the Blink Labs team to resubmit this proposal as part of the formal Intersect 2026 budget process. I am open to funding node diversity, but only through a transparent, comparative, and structured budgetary framework that proves its priority relative to the broader needs of our ecosystem."
- Yes 21.2M ₳ Rationale
I vote YES on the treasury withdrawal proposal “Dingo: a Production-Grade Block Producer in Go by Blink Labs” (gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe).
It is refreshing to see a continued return to detailed, well-composed governance action proposals, backed by numerous supporting links, after a recent drop in proposal quality. The Blink Labs team has a history of developing open source software for the Cardano ecosystem and are seeking funding for the continued development of a Cardano node written in the Go programming language.
I have already seen some comments like “no use case” and “a hobby project” from early voting DReps and so did some digging into current applications using Go in the wider world today. I knew IPFS was built on Go having installed it on a server at home already but beyond that I hadn’t quite appreciated the scale of its use in cloud infrastructure and distributed systems. Ethereum's primary execution node client Geth (short for Go Ethereum) accounts for ~66% of the Ethereum networks execution layer nodes as of October 2025 (having held a previous high of ~85%), while Go is also utilised across the Cosmos SDK, Docker and Kubernetes, and Hyperledger Fabric to name but a few instances. Its wide application across cloud computing, microservices and DevOps tools is supported by a global community of ~5 million+ developers. Investing in a Go node would not be merely funding a “hobby project”, it would be a strategic investment in opening Cardano up to a large developer community, predominantly in enterprise and cloud infrastructure fields.
This doesn’t appear to simply be a case of a team looking to cash in on a potential “node diversity goldrush”, coming so soon after the recent Amaru node proposal, they have a track record of work and delivery in the Cardano ecosystem and operate with a dedication to open source practices. While some DReps have expressed concerns regarding some of the quoted FTE rates within this proposal, it does feel like it could be an acceptable trade-off for the potential upside that a successful Go node implementation could bring by opening the Cardano ecosystem up to a much wider developer talent pool and the wider cloud computing/distributed systems space.
I have also seen some comments along the lines of “not necessary, everyone will use the Rust node”. This is also short-sighted. Funding node diversity to reduce the single node client risk to then all move to that same new client would be counter-intuitive to the intended decentralisation effort. Having a third node client here would be more beneficial to that end, not detrimental. The event of November 2025 highlighted the need for greater node diversity, now more than ever.
While a largely well written and documented proposal, it is worth noting for a moment that the Constitutionality Checklist does contain some errors. This practice of self-awareness has been much welcomed as governance progressed through its first year as it helped reduce bad proposals being submitted. Unfortunately, although stating that the checklist included here follows Constitution 2.4, it actually utlises an older template from Pragma that has not yet been updated since the previous Constitution (https://github.com/pragma-org/mnemos/blob/3402a6f12ffb042783112eeb5d3f30ae4f3965d4/BudgetInfoActionProposalTemplate.md) and as a result references incorrect Constitution articles within the proposal. While not a deal breaker here as a “Constitutionality Checklist” is largely an exercise in “self-awareness” and ultimately it is the Constitutional Committee that decides what is and what isn’t constitutional, it is an unfortunate blemish on what was otherwise a well put together proposal document. I have reached out to the proposer and it has been confirmed that the template used will be updated to reflect the new relevant sections of the Constitution, namely Article II Sections 6 & 7, for anyone else seeking to reference the template in the future.
- Yes 21.1M ₳ No rationale
- No 20.3M ₳ No rationale
- Yes 19.9M ₳ Rationale
A block production node written in Go with Apache 2.0 license helps our ecosystem in client diversity. I have a good impression of the dev team.
- Yes 17.1M ₳ Rationale
Dingo: a Production-Grade Block Producer in Go by Blink Labs
- No 16.7M ₳ Rationale
This is not a judgment on Blink Labs’ talent or the value of node diversity. The issue is prioritization and strategy.
Fiscal prioritization: Funding a third node implementation is a luxury we likely can’t afford right now. We should focus resources on getting one alternative node to production and then budget realistically for its ongoing maintenance before adding more permanent obligations.
Strategic coordination gap: Node diversity is important, but we lack an ecosystem-level plan for how many node implementations we intend to fund, in what sequence, and how we ensure SPO adoption. Treasury withdrawals shouldn’t be decided on a first-come basis for core infrastructure.
Cost sensitivity: The request is 6.9M ADA for 12 months, including premium FTE assumptions, a large audit line, and contingency. In the current treasury environment, this needs stronger comparative justification against alternatives and against other urgent ecosystem needs.
I’d be open to revisiting Dingo once we have a clearer multi-node strategy, a defined sequencing plan, and a budget view that includes long-term maintenance commitments.