Dingo: a Production-Grade Block Producer in Go by Blink Labs

{
  "_meta": {
    "schema_version": "1.2.0",
    "ingested_at": "2026-06-02",
    "source": "Koios TreasuryWithdrawal",
    "proposal_id": "gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe",
    "title": "Dingo: a Production-Grade Block Producer in Go by Blink Labs",
    "proposer": "Chris Gianelloni",
    "requested_budget_ada": 6900000,
    "summary": "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. Dingo is a work in progress, and that's the whole point of this proposal. But it's a substantial one: 1,290+ non-dependency PRs merged in the past year, Plutus V1/V2/V3 at 100% conformance, 314 passing conformance tests, VRF/KES crypto, ChainSync, mempool, and governance transaction support. This funding gets Dingo the rest of the way to mainnet block-production readiness: Ouroboros Praos consensus completion, Dijkstra hard fork support, CIP-0164 Linear Leios built alongside IO Engineering, a proper security audit, and the operational hardening that makes a node reliable at scale."
  },
  "id": "onchain-dingo-a-production-grade-block-producer-in-go-by-blink-labs",
  "identity": {
    "title": "Dingo: a Production-Grade Block Producer in Go by Blink Labs",
    "proposer_name": "Chris Gianelloni"
  },
  "source": {
    "channels": [
      "onchain"
    ],
    "hydra_id": "gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe",
    "onchain_action_id": "gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe",
    "onchain_tx_hash": "f35285db3c4e085ad331843b3007737952b8a322bb3216311edc37fdf44ad3da"
  },
  "classification": {
    "official_pillar_primary": [],
    "official_pillar_secondary": [],
    "working_category_suggestion": null,
    "tags": []
  },
  "ask": {
    "ada_amount": 6900000,
    "currency_basis": "ada_flat",
    "raw_ask_text": "6,900,000 ADA TreasuryWithdrawal on-chain."
  },
  "lifecycle": {
    "pipeline_state": "ratified",
    "proposed_epoch": 617,
    "expiration_epoch": 624,
    "ratified_epoch": 624,
    "enacted_epoch": 625,
    "dropped_epoch": null,
    "expired_epoch": null
  },
  "links": {
    "adastat_url": "https://adastat.net/governances/gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe",
    "meta_url": "ipfs://bafkreibeffgc4ow5rxbttesgqqe36copa5rejtsw6b4jruwow2p3wahxtq",
    "other": [
      "https://github.com/blinklabs-io/treasury-proposal",
      "https://github.com/blinklabs-io/dingo",
      "https://github.com/blinklabs-io/gouroboros",
      "https://github.com/blinklabs-io/plutigo",
      "https://github.com/blinklabs-io/ouroboros-mock"
    ]
  },
  "content": {
    "abstract": "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. Dingo is a work in progress, and that's the whole point of this proposal. But it's a substantial one: 1,290+ non-dependency PRs merged in the past year, Plutus V1/V2/V3 at 100% conformance, 314 passing conformance tests, VRF/KES crypto, ChainSync, mempool, and governance transaction support. This funding gets Dingo the rest of the way to mainnet block-production readiness: Ouroboros Praos consensus completion, Dijkstra hard fork support, CIP-0164 Linear Leios built alongside IO Engineering, a proper security audit, and the operational hardening that makes a node reliable at scale.",
    "rationale": "Executive Summary of Costs\n\nWe're requesting a single treasury withdrawal to cover twelve months of development. All amounts are in USD with ADA conversion at the time of the governance action, plus a contingency buffer for price volatility.\n\nBudget Breakdown:\n- Engineering (4 FTE Go engineers x 12 months): $1,000,000\n- Operations (1 FTE x 12 months: infrastructure, COO, marketing & outreach): $250,000\n- Security Audit (major firm): $500,000\n- Infrastructure hosting & CI/CD: $50,000\n- Subtotal: $1,800,000\n- Contingency (~15% for scope uncertainty): $270,000\n- Total: $2,070,000\n\nRequested Amount: 6,900,000 ADA (at $0.30/ADA)\n\nNotes on the Budget\n\n- Engineering is the core cost: four full-time Go engineers for twelve months. The $250,000 per FTE is all-in: wages, benefits, and hardware. These are Blink Labs employees, not contractors. We'll need to hire three Go developers to reach full capacity, and may promote from our existing Paid Open Source Contributor team.\n\n- Operations is split across an infrastructure engineer (CI/CD, testnet and mainnet node ops, deployment, monitoring) and the COO (marketing, community outreach, governance comms, DRep engagement, social media). The $50,000 infrastructure line is cloud hosting only; the human effort is under operations.\n\n- Security audit is budgeted at about $500,000 for a thorough review by a major firm (Trail of Bits, NCC Group, or equivalent). Before we recommend anyone run Dingo as a block producer, we want someone to try to break it.\n\n- ADA price basis. We're using $0.30/ADA because that's approximately what ADA costs right now. Other treasury-funded implementations priced at $0.50 during the 2025 cycle. At that price, our $2,070,000 would be roughly 4,140,000 ADA. We'd rather price honestly and let the numbers speak.\n\n- Contingency is about 15%. Dijkstra CDDL specs aren't published. Leios is evolving. The audit might find things that need fixing. Since we priced at near-market rather than $0.50, price volatility is less of a concern. Our hedge is converting to stablecoin or fiat upon receipt.\n\n- Single withdrawal. Full amount in one treasury withdrawal, with milestones enforced by smart contract escrow and oversight board review.\n\nEffort Estimate and Capacity Buffer\n\nWe want to be upfront about how estimated work maps to funded capacity. Our engineering assessment in engineer-months: mainnet block production (6), Dijkstra hard fork (5), CIP-0164 Linear Leios (6), operational hardening (6), feature parity (8), ecosystem integration (6). Total estimated work: 37 engineer-months. Team capacity (4 engineers x 12 months): 48. Buffer: 11 (25%).\n\nOur measured velocity over the past year is about 36 non-dependency PRs per person per month across Dingo, gOuroboros, and Plutigo, well above what other Cardano node teams have shown. We've adjusted our estimates to account for the shift from protocol implementation to the harder work of consensus hardening and operational readiness.\n\nWhy the buffer: specs aren't done, the audit could surface serious findings, and Leios is a moving target. If things go well, the extra capacity goes into community-prioritized items. Unused ADA sweeps back to the treasury at contract expiration. That's enforced at the contract level, not a promise.\n\nAdministration of the Budget\n\nSmart Contract Escrow\n\nFunds are held and released through the SundaeSwap treasury-contracts (https://github.com/SundaeSwap-finance/treasury-contracts), a proven framework with two validators:\n\n- treasury.ak: Holds all ADA withdrawn from the Cardano treasury. Everything gets locked here when the governance action is enacted.\n- vendor.ak: Manages milestone-based vesting for Blink Labs. Payment schedule, payout dates, release conditions.\n\nBoth contracts have been independently audited by TxPipe and MLabs and are in production use on mainnet.\n\nBlink Labs as Single Vendor\n\nWe're the sole vendor. All work comes from Blink Labs. No subcontractors. If something isn't delivered, you know exactly who to hold accountable.\n\nIndependent Oversight Board\n\nAn independent oversight board provides third-party governance:\n\n- Pi Lanningham (SundaeSwap)\n- Santiago Carmuega (TxPipe)\n- Lucas Rosa (Aiken, Midnight)\n\nBoard members don't have a stake in Blink Labs. They co-sign disbursements, review milestones, and can halt funding if we're not delivering.\n\nPermission Scheme\n\nWe use a least-friction permission model: no bottlenecks, but real oversight:\n\n- Disburse (periodic release): Blink Labs initiates + any 1 board member co-signs\n- Sweep early (return unused funds): Blink Labs + any 1 board member\n- Reorganize (adjust milestone schedule): Blink Labs only\n- Fund (initial vendor setup): Board majority\n- Pause milestone: Any 1 board member\n- Resume milestone: Board majority\n- Modify project: Blink Labs + board majority\n\nDay-to-day operations need one board signature. Structural changes need the full board. And any single member can hit pause if something looks off.\n\nDelegation Policy\n\nThe treasury contract enforces auto-abstain DRep delegation and no SPO delegation for all funds in escrow. Treasury funds don't influence governance votes or staking.\n\nFailsafe Sweep\n\nFunds left in the contract after expiration automatically sweep back to the Cardano treasury. Enforced at the contract level. Can't be overridden.\n\nPeriodic Fixed Releases\n\nFunds release on a fixed schedule in the vendor contract, subject to board co-signature. Predictable cash flow for us, halt capability for the board. The schedule aligns with quarterly milestones in the Scope of Work.\n\nReporting\n\nMonthly Lightweight Updates\n\nEnd of each month, we publish a status update:\n\n- What shipped\n- Key PRs, features, milestones\n- Risks or blockers\n- What's next\n\nUpdates go to the treasury-proposal repository (https://github.com/blinklabs-io/treasury-proposal) and community channels.\n\nQuarterly Detailed Reports\n\nEach quarter, a full report:\n\n- Progress against each milestone\n- Financial summary: received, spent by category, remaining\n- Variance analysis for budget deviations\n- Updated risk register\n- Next quarter's plan\n\nQuarterly reports coincide with disbursement requests, giving the board what they need to authorize releases.\n\nPublic Transaction Journal\n\nEvery on-chain transaction (disbursements, claims, sweeps, reorganizations) gets recorded in a public journal (https://github.com/blinklabs-io/treasury-proposal/tree/main/journal). Transaction hash, action type, amount, signers, justification, on-chain metadata hash. SundaeSwap metadata standard. Anyone can verify against the chain.\n\nCoding Sessions and Demos\n\nWe do periodic live coding sessions and demos so the community can see the work firsthand. Active development, architectural decisions, Dingo capabilities as they're built. Announced on X/Twitter and the Cardano Forum, recorded for later.\n\nConstitutionality Checklist\n\nThis section checks the proposal against the Cardano Constitution (v2.4), following the PRAGMA mnemos format (https://github.com/pragma-org/mnemos).\n\nPurpose\n\nThis proposal requests a treasury withdrawal to fund Dingo's development to production readiness: a second full Cardano node capable of data service and block production, with Dijkstra support and a Leios implementation.\n\nArticle III, Section 5: On-Chain Governance Actions\n\n\"Governance actions shall follow a standardized and legible format, including a URL and hash of any off-chain content.\"\n\nAssessment: COMPLIANT. CIP-108 metadata. On-chain action references off-chain metadata via URL (GitHub commit-hash pinned, IPFS mirror via Blockfrost) with blake2b-256 hash. Self-contained, human-readable, CIP-108 compliant.\n\nArticle IV, Section 1: Budget for the Cardano Blockchain Ecosystem\n\n\"A budget for the Cardano Blockchain ecosystem shall be adopted on an annual basis through an on-chain governance action.\"\n\nAssessment: COMPLIANT. Twelve months (~73 epochs), aligned with the annual cycle. Budget fully specified: engineering, audit, infrastructure, contingency.\n\nArticle IV, Section 2: Fund Administration\n\n\"Cardano Blockchain ecosystem budgets shall be administered by one or more budget administrators or administrators selected through a transparent process.\"\n\nAssessment: COMPLIANT. Audited SundaeSwap smart contracts with an independent oversight board: Pi Lanningham (SundaeSwap), Santiago Carmuega (TxPipe), and Lucas Rosa (Aiken, Midnight). Board members are not Blink Labs stakeholders. Permissions, disbursement schedule, and oversight fully specified. Emergency halt and dispute resolution authority included.\n\nArticle IV, Section 3: Net Change Limit\n\n\"The Net Change Limit shall be observed by all treasury withdrawals during the applicable budget period.\"\n\nAssessment: COMPLIANT. Doesn't violate the active NCL at submission. We'll operate within whatever NCL is in effect.\n\nIf no NCL exists when this action is evaluated, we suggest: withdrawal shouldn't exceed 6,900,000 ADA, evaluated on merits against treasury balance and other requests. This is guidance, not a substitute for a properly enacted NCL.\n\nArticle IV, Section 4: Auditor\n\n\"An independent audit of all transactions funded from the Cardano treasury shall be possible.\"\n\nAssessment: COMPLIANT. Public transaction journal with full provenance: hashes, amounts, signers, justifications. SundaeSwap contracts enforce fund flows on-chain. Anyone can verify. Quarterly financials published with category-level detail.\n\nGuardrail TREASURY-04a\n\n\"Treasury withdrawals for budget proposals require greater than 50% of DRep active voting stake to vote Yes.\"\n\nAssessment: ACKNOWLEDGED. Requires >50% DRep active voting stake. We're doing active outreach, community engagement, and AMAs so delegates have full information about what we're building, what it costs, and how we're held accountable.\n\nScope of Work\n\nTwelve months, four quarters, concrete deliverables mapped to vendor contract milestones. All work on the existing Dingo (https://github.com/blinklabs-io/dingo), gOuroboros (https://github.com/blinklabs-io/gouroboros), Plutigo (https://github.com/blinklabs-io/plutigo), and ouroboros-mock (https://github.com/blinklabs-io/ouroboros-mock) codebases. Apache 2.0.\n\nWhere we're starting from: Dingo today syncs from genesis through all eras (Byron through Conway), has VRF/KES block forging primitives, passes 314 Amaru conformance tests (via the ouroboros-mock harness), evaluates Plutus V1/V2/V3 at 100% conformance, handles mempool management and governance transactions, supports P2P networking, and runs on multiple storage backends (Badger for blocks, SQLite for metadata, in-memory for testing). What it can't do yet: produce blocks in a live consensus environment. That's what Q2 is for.\n\nQ2: Testnet Block Production and Leios Prototype\n\nGoal: Get Ouroboros Praos consensus complete enough for Dingo to produce blocks on a test network, and begin the Leios prototype. This is the hardest quarter; consensus is where the real complexity lives.\n\nWhat we'll deliver:\n\n- Full Ouroboros Praos consensus: epoch transitions, slot leader election verification, chain selection, and the remaining behaviors needed for Dingo to produce and validate blocks as a full participant.\n- Hard fork combinator: protocol version negotiation and era transition so Dingo handles forks without restarting.\n- Genesis bootstrap: the Ouroboros Genesis mechanism for nodes joining from scratch, including peer selection and chain validation during initial sync.\n- Stable ChainSync from genesis to tip on preview and preprod. Graceful handling of interruptions, disconnections, rollbacks.\n- CIP-0164 Linear Leios prototype, built with IO Engineering. Two-block-type architecture (Endorser Blocks, Ranking Blocks) with sortition-based voting and certificates for 30-50x throughput. New block types, serialization, vote validation, pipeline timing, mini-protocols for EB and vote diffusion. We track the spec and feed ambiguities back to the research team. That's half the value of a second implementation.\n- Conformance test expansion beyond the current 314 vectors to cover consensus edge cases and epoch boundaries.\n\nQ3: Operational Hardening and Storage Scalability\n\nGoal: Harden Dingo for long-running stability and address the known storage risks at mainnet data volumes.\n\nWhat we'll deliver:\n\n- Operational hardening: profiling under realistic workloads. Find memory leaks, optimize hot paths, establish performance baselines.\n- Storage scalability: our current backends (Badger, SQLite) haven't been tested at mainnet scale (~100M UTxOs, ~500 GB chain). Benchmarking, bottleneck identification, optimizations or migrations as needed.\n- UTxO set management at mainnet cardinality: acceptable lookup latency and memory footprint.\n- Mainnet-scale testing: Dingo against ~100M UTxOs, ~500 GB chain, realistic volumes. Sync, resource consumption, block production under load, crash recovery.\n- Long-running stability: weeks of continuous operation. No leaks, no corruption, no degradation.\n- Cross-node validation: automated parallel execution against the Haskell node, block-by-block comparison to catch ledger state discrepancies.\n- Security audit kickoff with a major firm (Trail of Bits, NCC Group, or equivalent). Consensus correctness, crypto, network handling, DoS resistance.\n\nQ4: Dijkstra Hard Fork Readiness and Leios Integration\n\nGoal: Achieve full Dijkstra readiness (including Plutus V4). Leios and Dijkstra are expected to ship in the same hard fork, so the Q2 prototype work feeds directly into final integration here.\n\nWhat we'll deliver:\n\n- Dijkstra protocol changes: ledger rules, new parameters, governance modifications. Dingo processes Dijkstra blocks the moment the fork happens.\n- Plutigo V4: new builtins, updated cost models, any UPLC evaluator changes.\n- Leios consensus integration: bringing the Q2 prototype to full integration with consensus and the Dijkstra protocol changes.\n- Remaining mini-protocols: Node-to-Client gaps and LocalStateQuery completion for Haskell node feature parity. Downstream tools need this.\n\nQ1 2027: Mainnet Readiness, Audit Completion, and Ecosystem Integration\n\nGoal: Finish the audit, hit mainnet readiness, and deliver the ecosystem work that makes Dingo actually useful to people.\n\nWhat we'll deliver:\n\n- Security audit completion. All findings addressed. Critical and high-severity issues fixed before any mainnet recommendation. Full report published.\n- Mainnet block production readiness. This is where it all comes together: consensus, hardening, audit. \"Ready\" means tested at scale, audited, stable, capable of everything an SPO needs.\n- Ecosystem integration: the practical stuff: key management and KES rotation, db-sync compatibility or equivalent indexing, API parity for wallets, explorers, dApps.\n- Mithril integration. Fast bootstrapping, sync in minutes instead of hours.\n- Operator docs: deployment, configuration, monitoring, troubleshooting. The stuff you need to actually run this in production.\n- P2P hardening: peer discovery, connection management, topology optimization.\n\nConclusion\n\nDingo is further along than most alternative node implementations get before their first treasury ask: 300+ PRs, 314 passing conformance tests, Plutus at 100% across three versions. But it's not mainnet-ready. This proposal funds the work to get it there: consensus completion, operational hardening, a proper audit, Dijkstra support, and Leios.\n\nThe risks are real. Storage at mainnet scale, an evolving Leios spec, whatever the audit turns up. We've planned for those: dedicated scope, IO Engineering collaboration, contingency, smart contract escrow, independent oversight.\n\nAfter twelve months:\n\n- Dingo produces blocks on mainnet.\n- SPOs have a real alternative block producer.\n- Dijkstra works from day one.\n- Leios exists in Go alongside the Haskell reference.\n- The audit report is public.\n- Every ADA is accounted for on-chain.\n\nWe've spent years building this. This proposal is what turns it into something the network can depend on.\n\nAll software is Apache 2.0. Everything is in the public treasury-proposal repository (https://github.com/blinklabs-io/treasury-proposal)."
  },
  "metadata": {
    "open_source": "unknown",
    "has_prior_delivery": null,
    "duplicate_of_existing_solution": "unknown"
  },
  "treasury_return": {
    "has_return_clause": false,
    "mechanisms": [],
    "treasury_favourability": "unknown",
    "treasury_favourability_confidence": "low",
    "treasury_favourability_set_by": "ai"
  },
  "ecosystem_demand": {
    "evidence_level": "unknown",
    "evidence_level_confidence": "low",
    "evidence_level_set_by": "ai"
  },
  "incumbents": {
    "has_existing_solution": "unknown",
    "has_existing_solution_confidence": "low",
    "has_existing_solution_set_by": "ai"
  },
  "relationships": {
    "bundle_with": [],
    "supersedes": null,
    "competes_with": [],
    "depends_on": [],
    "notes": ""
  }
}