Dingo Treasury Proposal (2026): Building a Production Ready Cardano Block Producer in Go

Hi!

I wanted to introduce Blink Labs’ treasury proposal here to everyone. We are asking to fund the next 12 months of Dingo, our open source Go implementation of a Cardano node, and I hope you’ll give this a read. We’ve done so much already, which I’ll tell you about, and with your support we can get to mainnet block production in Go for our ecosystem.

Proposal: Cardano Govtool
Full docs and metadata: GitHub - blinklabs-io/treasury-proposal · GitHub
This is the link with every bit of detail one might want :backhand_index_pointing_up:


Why This Proposal Matters

Cardano currently relies heavily on one node implementation for core network operations. Cardano has already funded multiple Rust based node efforts. Funding Dingo adds language and implementation diversity through Go, reducing shared risk across similar stacks and broadening the pool of engineers who can contribute.

Go is one of the world’s most widely used systems languages and many major blockchain implementations are written in Go. Expanding Cardano’s core infrastructure in Go lowers the barrier of entry for a large global developer pool and makes ecosystem onboarding easier.

Dingo helps by bringing:

  • More resilience through implementation diversity
  • More developer access by using Go, a language used widely across the industry
  • More long term public value through fully open source software

What We’ve Already Delivered

This is not a proposal to start from scratch. Even without full time staffing, Dingo has been in active development with 48 releases to date. In total, 1,226 commits. Over 150k lines of code.

Notable achievements:

  • Dingo currently boots:
    • From the very beginning of Cardano’s history (genesis), syncing everything.
    • From a trusted recent checkpoint (Mithril snapshot), so it gets up and running much faster.
  • Dingo was checked against 314 official conformance tests used to verify Cardano rules, and it passed every single one.
    • In plain terms: Dingo is behaving the way Cardano expects, with zero misses in that test set.
  • Dingo passes Plutus V1, V2, V3 conformance, with V4 work underway
    • Plutus is Cardano’s smart contract language, it’s a machine language. You write in something like Aiken and it compiles down to Plutus.
  • Dingo already supports the upcoming van Rossem hard fork, with Dijkstra work already in progress
  • We directly collaborate with IO Engineering on Leios implementation/testing.
    • Leios is Cardano’s planned scalability upgrade that lets the network process much more activity by splitting work into parallel parts, instead of doing everything in one single lane.
  • We directly collaborate with CF and Antithesis as Go works natively with Antithesis SDK.
    • Antithesis is an advanced automated testing that stress tests node software under extreme, randomized scenarios to uncover bugs before they happen for real.

Today, Dingo can be used as a practical node backend. You can use it for UTxO RPC, Mesh API, and to power services like Kupo or Ogmios. In general, anywhere you’d use a Cardano node today, you can use Dingo.


What This Proposal Delivers

What changes from day 1 to month 12:

Day 1:
Dingo is a capable Go node for data and integration use cases (UTxO RPC, Mesh API, and powering services like Kupo/Ogmios), but it is not yet a fully production ready mainnet block producer.

Month 12:
Dingo is production ready for mainnet block production, with hardening, scale testing and operational readiness completed.

Day 1:
Protocol support is strong but still progressing toward upcoming upgrade requirements.

Month 12:
Dingo is prepared for Dijkstra era changes and Plutus V4, reducing upgrade risk for operators and builders.

Day 1:
Security confidence comes from internal engineering quality and testing.

Month 12:
An independent external security audit is completed, and critical/high findings are remediated before production recommendation.

Day 1:
Node diversity exists as progress and promise.

Month 12:
Cardano has a second production-capable node implementation in a different language stack (Go), reducing single client risk and broadening contributor access.


Funding Request and Cost Model

We are requesting 6,900,000 ADA to fund a 12 month delivery plan.

Budget basis in USD (converted to ADA at submission assumptions):

| Category | Cost (USD) |
| Engineering (4 FTE x 12 months) | $1,000,000 |
| Operations (1 FTE x 12 months) | $250,000 |
| Infrastructure/CI/CD | $50,000 |
| Security Audit | $500,000 |
| Subtotal | $1,800,000 |
| Contingency (~15%) | $270,000 |
| Total | $2,070,000 |

We ultimately priced at $0.30 ADA, $2,070,000 USD which is 6,900,000 ADA

Full Time Employee assumption: $250,000 per FTE (all in), including compensation, overhead and required equipment/support. This corresponds to an effective billable rate of about $120 an hour.

One quarter of this budget is for a security audit we request to have completed by a credible external auditor. To date, no such audit has been performed on any Cardano node and we believe it is a wise step for the ecosystem.


Why $250k per FTE is reasonable

At first glance, $250k/year can seem high without context. We are hiring for a niche profile: engineers with blockchain protocol experience.

Reference points from other Cardano treasury proposals include:

Treasury funded FTE costs include total employment burden, not just salary: taxes, benefits, paid leave, equipment and operating overhead.

Blink Labs also operates under governance and payout uncertainty:

  • Future withdrawals are not guaranteed
  • Treasury governance timelines can affect continuity and runway
  • On-chain fund administration adds operational complexity compared to traditional financing


Capacity and Delivery

Estimated work: 37 engineer months
Team capacity: 48 engineer months (4 engineers x 12 months)
Buffer: 11 engineer months (~25%)

This buffer is intentional for audit findings, protocol evolution and hardening work.

Milestone Plan

Q2: Testnet block production readiness and Leios prototype progress
Q3: Operational hardening, storage scalability, long run stability, audit kickoff
Q4: Dijkstra readiness, Plutus V4 path, deeper Leios integration
Q1 2027: Audit completion, only then we can conclude mainnet block production readiness, operator/docs/integration work


Treasury Administration and Safeguards

  • Funds managed via audited SundaeSwap treasury contracts (treasury.ak, vendor.ak)
  • Funds are converted to stablecoin after disbursement to manage ADA price volatility and preserve delivery runway
  • Independent oversight board cosigns disbursements and can pause when needed
  • Milestone based vesting/release structure
  • Public transaction journal for on-chain transparency
  • Monthly updates and quarterly detailed progress + financial reports
  • Unused funds sweep back to treasury at contract expiration


Open Source Commitment

All work is Apache 2.0 open source. This is intended to be durable public infrastructure for Cardano, not closed IP.

Community Review

We welcome direct scrutiny from SPOs, DReps, developers and governance participants.

If you have questions on technical scope, budget assumptions, milestone criteria, or oversight controls, we’ll answer them publicly in this thread.

4 Likes

Thanks for sharing the proposal and for the work already done on Dingo. Impressive! Reading through the proposal raised a few things I’m curious about from an operational perspective: Since the goal is eventually to support mainnet block production, I’m wondering how the team is thinking about the path toward real world SPO adoption. For client diversity to meaningfully reduce single client risk, stake pool operators would eventually need to run the client in production, so it would be interesting to know whether there are plans for pilot pools, testnet operator programs, or other ways of involving SPOs during the development phases.

I also noticed the proposal allocates a substantial budget for an external security audit, which is encouraging given how critical node software is for the network. It would be helpful for the community to understand a bit more about the expected scope of that audit for example whether it is intended to cover the full consensus implementation, networking layer, and block production logic, and whether there are particular audit firms already being considered.

Finally, since node implementations typically need ongoing updates as the protocol evolves through new eras and upgrades, I’m curious how the team is thinking about long term maintenance beyond the initial 12 month delivery period. Understanding the sustainability model after the funded phase would help clarify how Dingo continues to evolve alongside the protocol over time. If some of these points are already documented elsewhere, I’d be happy to read further.

1 Like

So happy that you asked, thank you!
Yes including SPO’s in development would be in the testnet block production readiness stage. Definitely open to more SPO’s who will want to test.

The audit covers full consensus implementation, networking layer, block production logic and cryptographic libraries, so everything except the core standard lib libraries that were recently audited.

We’re looking to boost the team to get this over the ‘block production in mainnet’ line. We do not need that staffing for maintenance. I dont have a current figure for years 2-5, trying to see how this goes before I plan too far out, but it will be less as we all know maintenance needs are less.

2 Likes

Appreciate the response, thanks for clarifying.