거버넌스 제안 상세
제안서 상세 내용과 투표 현황을 확인하세요.
한글 버전
- Dingo는 현재 개발 중인 프로젝트로, 지난 1년 동안 1,290개 이상의 PR 병합과 Plutus V1/V2/V3 100% 적합성 달성 등 상당한 성과를 거두었음 .
- 현재 314개의 적합성 테스트를 통과했으며 VRF/KES 암호화, ChainSync, mempool 및 거버넌스 트랜잭션을 지원함 .
- 요청된 자금은 Ouroboros Praos 합의 완료, Dijkstra 하드포크 지원, CIP-0164 Linear Leios 구축을 통해 Dingo를 메인넷 블록 생성 가능 수준으로 끌어올리는 데 사용될 예정임 .
- 또한 적절한 보안 감사와 대규모 환경에서의 노드 신뢰성 확보를 위한 운영 강화 작업도 포함됨 .
- ■ 주석 *Go: 구글에서 개발한 프로그래밍 언어 **PR: 코드 변경 사항을 검토하고 병합하기 위한 요청 ***Plutus: 에이다의 스마트 컨트랙트 플랫폼 ****VRF/KES: 블록체인 보안 및 검증을 위한 암호화 기술 *****Mempool: 아직 블록에 포함되지 않은 트랜잭션 대기소 ******Ouroboros Praos: 에이다의 지분 증명 합의 알고리즘 *******Hard Fork: 블록체인의 이전 버전과 호환되지 않는 대규모 업데이트
- 고성능 네트워크 시스템에 적합한 Go 언어를 사용하여 에이다 핵심 인프라를 구축하고 있음 .
- 2021년부터 Dingo, gOuroboros, Plutigo 등 다양한 에이다 관련 프로젝트를 성공적으로 출시했음 .
- 현재 에이다는 단일 노드 구현체에 의존하고 있어 버그 발생 시 네트워크 전체가 위험할 수 있음 .
- Dingo는 Go 언어 기반의 독립적인 노드 구현을 통해 네트워크의 회복 탄력성과 다양성을 제공함 .
- Go 언어의 넓은 개발자 층을 활용하여 에이다 생태계에 대한 접근성을 획기적으로 높일 수 있음 .
- 지난 12개월 동안 1,290개의 PR을 처리하며 높은 개발 효율성과 전문성을 입증했음 .
- Leios 도입을 통해 에이다의 처리량을 30~50배 향상시키는 작업을 진행 중임 .
- 총 예산은 약 2.07M 달러이며, 이는 약 4.14M ₳에 해당함 .
- 모든 결과물은 Apache 2.0 라이선스의 오픈 소스로 공개되어 공공재로서의 가치를 지님 .
- 자금 지원이 없을 경우 메인넷 노드 운영 및 보안 감사 등 핵심 기능 구현이 지연될 수 있음 .
- ■ 주석 *Go: 구글에서 개발한 고성능 프로그래밍 언어 **Dingo: Blink Labs에서 개발 중인 Go 기반 에이다 노드 ***Ouroboros: 에이다의 지분 증명 합의 프로토콜 ****Plutus: 에이다의 스마트 컨트랙트 플랫폼 *****PR: 코드 변경 사항을 검토하고 병합하기 위한 요청 ******SPO: 에이다 네트워크에서 스테이크 풀을 운영하는 주체 *******Leios: 에이다의 처리량을 높이기 위한 새로운 합의 메커니즘 ********Apache 2.0: 자유로운 사용과 수정을 허용하는 오픈 소스 라이선스
- 현재 에이다 가격인 $0.30를 기준으로 총 6.9M ₳의 단일 국고 인출을 제안함 .
- 예산은 엔지니어링 1M USD, 운영 250,000 USD, 보안 감사 500,000 USD 등으로 구성됨 .
- 불확실성에 대비하여 약 15%인 270,000 USD의 예비비를 포함하였음 .
- SundaeSwap의 스마트 컨트랙트를 통한 에스크로 방식으로 자금을 관리함 .
- 독립적인 감독 위원회가 마일스톤 달성 여부를 검토하고 자금 집행을 승인함 .
- Q2에는 테스트넷 블록 생성 및 Leios 프로토타입 개발에 집중함 .
- Q3에는 메인넷 규모의 데이터 처리를 위한 저장소 확장성 및 안정화 작업을 수행함 .
- Q4에는 Dijkstra 하드포크 대응 및 Leios 통합을 완료할 예정임 .
- 2027년 Q1까지 보안 감사를 마치고 메인넷 운영 준비 및 생태계 통합을 완료함 .
- 모든 소프트웨어는 Apache 2.0 라이선스로 공개되며 투명하게 보고됨 .
- ■ 주석 *FTE: 전일제 근무 인원 **CI/CD: 지속적 통합 및 지속적 배포 ***DRep: 위임 대표 ****SPO: 스테이크 풀 운영자 *****VRF: 검증 가능한 랜덤 함수 ******KES: 키 진화 서명 *******PR: 풀 리퀘스트 ********CIP: 카르다노 개선 제안 *********UTxO: 미사용 트랜잭션 출력값 **********P2P: 개인 간 연결 네트워크
English
Blink Labs
We're a small engineering company focused exclusively on blockchain software integrated with Cardano. We build in Go because it's the right language for high-performance networked systems, and because Cardano benefits from having core infrastructure that millions of developers can actually read and work on. Our team includes a part-time documentation engineer and six part-time Paid Open Source Contributors who help maintain and expand the ecosystem.
We've been building on Cardano since 2021. Here's what we've shipped:
- Dingo (https://github.com/blinklabs-io/dingo): Our Go Cardano node: ChainSync, VRF/KES block forging primitives, Plutus evaluation, mempool, governance, UTxO RPC, Mini-Blockfrost, and Mesh (Rosetta) APIs. Not mainnet-ready yet, but 300+ merged PRs and 314/314 conformance tests.
- gOuroboros (https://github.com/blinklabs-io/gouroboros): Ouroboros mini-protocol library with full era support from Byron through Conway. 2,200+ tests, used by downstream projects.
- Plutigo (https://github.com/blinklabs-io/plutigo): Our Plutus script evaluator: V1, V2, V3 at 100% conformance. Integrated into Dingo.
- ouroboros-mock (https://github.com/blinklabs-io/ouroboros-mock): Conformance testing framework with 314 Amaru test vectors and ledger state mocking. Shared infrastructure.
- Adder (https://github.com/blinklabs-io/adder): Chain indexing and event notification pipeline with pluggable outputs. In production.
- nview (https://github.com/blinklabs-io/nview): Terminal-based node monitoring. Shipped.
- TxSubmit API (https://github.com/blinklabs-io/tx-submit-api): Transaction submission service. In production, Docker-based.
- Docker images: Cardano node and tooling containers, widely adopted by SPOs.
Beyond our own projects, we co-maintain several Go libraries across the Cardano ecosystem, including Apollo, Ogmigo, Kugo, and the UTxO RPC Go SDK.
Our prior Cardano funding has come from Project Catalyst (which funded gOuroboros development and initial Dingo work) and from self-funding. We're PRAGMA members, but we haven't received any funds from Amaru's treasury proposal or any other treasury withdrawal despite our membership. This proposal stands on its own.
Key Personnel
- Chris Gianelloni, Lead Architect. Designed and leads development of Dingo, gOuroboros, and the broader Go infrastructure stack. Architecture decisions, protocol implementation, and technical direction.
- Christina Gianelloni, COO. Marketing, community outreach, DRep engagement, AMAs, social media, and governance communications. She keeps the non-engineering side running so the developers can focus.
Why Dingo
Node Diversity Is Network Resilience
Cardano runs on a single node implementation for block production. Every block producer on the network runs the same code. A critical bug in one place (consensus defect, memory leak under load, vulnerability in production) hits all of them at once. There's no fallback.
Node diversity changes that. Amaru is building a Rust implementation, and Dingo brings Go. Multiple independent implementations mean a bug in one doesn't take down the whole network. Ethereum learned this the hard way. Their multi-client architecture has saved them repeatedly when individual clients hit bugs that would've been network-wide outages otherwise.
Go Ecosystem Accessibility
Cardano's core infrastructure is written in Haskell. Go has over 5 million active developers and ranks 7th on TIOBE. It's the language the industry already chose for blockchain nodes: Geth (Ethereum), btcd (Bitcoin), CometBFT (50+ Cosmos chains), AvalancheGo, Algorand, and Filecoin. A Go Cardano node isn't novel. It's overdue.
Dingo opens Cardano's node internals to those 5 million+ developers. Engineers at Google, Cloudflare, Docker can read this code, audit it, and contribute to it without learning a new language. This isn't about replacing Haskell. It's about making Cardano accessible to the developers who are actually out there.
Delivery Track Record and Cost Efficiency
We have a documented track record. Across Dingo, gOuroboros, and Plutigo, we've merged 1,290 non-dependency PRs in the past twelve months, 593 in the last quarter, accelerating. With 2-3 engineers. That works out to roughly 36 PRs per person per month, with 304,000+ lines of code added.
These numbers are backward-looking, not promises. The work shifts from protocol implementation to consensus hardening, which is different. But the engineering culture that produced those numbers is the same culture we're bringing to this proposal.
Development discipline: We write small PRs, about 236 lines each. On purpose. Smaller PRs mean faster review, lower merge risk, tighter feedback loops. It adds up: 304,000 lines of new code in twelve months.
Cost efficiency: Personnel cost is $1,250,000 for five FTEs ($250,000 per FTE). The rest is a one-time audit ($500,000), hosting ($50,000), and 15% contingency. Other funded node implementations priced at $0.50/ADA during the 2025 cycle. At that same price, our $2,070,000 total is roughly 4,140,000 ADA. We're not padding this.
Scalability Through Leios
CIP-0164 Linear Leios is where Cardano gets its next major throughput jump, 30-50x through a two-block-type architecture (Endorser Blocks and Ranking Blocks) with sortition-based voting and certificates. We're already working directly with IO Engineering on this, and Go's concurrency model (goroutines and channels) is basically purpose-built for the kind of pipeline concurrency Leios needs. Building it in Go alongside the Haskell reference also strengthens the spec. You find ambiguities faster when two teams implement the same protocol in two different languages.
Sustainability Through Open Source
Everything we build is Apache 2.0. Always has been, always will be. This work is a permanent public good. It doesn't go away if Blink Labs does.
What the Ecosystem Loses Without Funding
Without funding, Dingo continues on whatever time we can scrape together from existing resources. Concretely:
- Block production limited to local devnet only. The consensus work for live networks doesn't get done.
- No SPO story. Pool operators can't run it as a block producer. Node diversity stays a talking point, not a reality.
- Dijkstra support will still happen, but on a slower timeline.
- Leios in Go limited to client-side only. The spec-strengthening benefits of a full second implementation don't materialize.
- No audit. That takes real money.
The Cardano community has already invested in this stack through Catalyst and through years of our own time and money. Without this funding, that investment doesn't reach its potential.
We'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.
Budget Breakdown:
- Engineering (4 FTE Go engineers x 12 months): $1,000,000
- Operations (1 FTE x 12 months: infrastructure, COO, marketing & outreach): $250,000
- Security Audit (major firm): $500,000
- Infrastructure hosting & CI/CD: $50,000
- Subtotal: $1,800,000
- Contingency (~15% for scope uncertainty): $270,000
- Total: $2,070,000
Requested Amount: 6,900,000 ADA (at $0.30/ADA)
Notes on the Budget
- 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.
- 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.
- 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.
- 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.
- 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.
- Single withdrawal. Full amount in one treasury withdrawal, with milestones enforced by smart contract escrow and oversight board review.
Effort Estimate and Capacity Buffer
We 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%).
Our 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.
Why 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.
Administration of the Budget
Smart Contract Escrow
Funds are held and released through the SundaeSwap treasury-contracts (https://github.com/SundaeSwap-finance/treasury-contracts), a proven framework with two validators:
- treasury.ak: Holds all ADA withdrawn from the Cardano treasury. Everything gets locked here when the governance action is enacted.
- vendor.ak: Manages milestone-based vesting for Blink Labs. Payment schedule, payout dates, release conditions.
Both contracts have been independently audited by TxPipe and MLabs and are in production use on mainnet.
Blink Labs as Single Vendor
We're the sole vendor. All work comes from Blink Labs. No subcontractors. If something isn't delivered, you know exactly who to hold accountable.
Independent Oversight Board
An independent oversight board provides third-party governance:
- Pi Lanningham (SundaeSwap)
- Santiago Carmuega (TxPipe)
- Lucas Rosa (Aiken, Midnight)
Board members don't have a stake in Blink Labs. They co-sign disbursements, review milestones, and can halt funding if we're not delivering.
Permission Scheme
We use a least-friction permission model: no bottlenecks, but real oversight:
- Disburse (periodic release): Blink Labs initiates + any 1 board member co-signs
- Sweep early (return unused funds): Blink Labs + any 1 board member
- Reorganize (adjust milestone schedule): Blink Labs only
- Fund (initial vendor setup): Board majority
- Pause milestone: Any 1 board member
- Resume milestone: Board majority
- Modify project: Blink Labs + board majority
Day-to-day operations need one board signature. Structural changes need the full board. And any single member can hit pause if something looks off.
Delegation Policy
The 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.
Failsafe Sweep
Funds left in the contract after expiration automatically sweep back to the Cardano treasury. Enforced at the contract level. Can't be overridden.
Periodic Fixed Releases
Funds 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.
Reporting
Monthly Lightweight Updates
End of each month, we publish a status update:
- What shipped
- Key PRs, features, milestones
- Risks or blockers
- What's next
Updates go to the treasury-proposal repository (https://github.com/blinklabs-io/treasury-proposal) and community channels.
Quarterly Detailed Reports
Each quarter, a full report:
- Progress against each milestone
- Financial summary: received, spent by category, remaining
- Variance analysis for budget deviations
- Updated risk register
- Next quarter's plan
Quarterly reports coincide with disbursement requests, giving the board what they need to authorize releases.
Public Transaction Journal
Every 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.
Coding Sessions and Demos
We 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.
Constitutionality Checklist
This section checks the proposal against the Cardano Constitution (v2.4), following the PRAGMA mnemos format (https://github.com/pragma-org/mnemos).
Purpose
This 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.
Article III, Section 5: On-Chain Governance Actions
"Governance actions shall follow a standardized and legible format, including a URL and hash of any off-chain content."
Assessment: 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.
Article IV, Section 1: Budget for the Cardano Blockchain Ecosystem
"A budget for the Cardano Blockchain ecosystem shall be adopted on an annual basis through an on-chain governance action."
Assessment: COMPLIANT. Twelve months (~73 epochs), aligned with the annual cycle. Budget fully specified: engineering, audit, infrastructure, contingency.
Article IV, Section 2: Fund Administration
"Cardano Blockchain ecosystem budgets shall be administered by one or more budget administrators or administrators selected through a transparent process."
Assessment: 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.
Article IV, Section 3: Net Change Limit
"The Net Change Limit shall be observed by all treasury withdrawals during the applicable budget period."
Assessment: COMPLIANT. Doesn't violate the active NCL at submission. We'll operate within whatever NCL is in effect.
If 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.
Article IV, Section 4: Auditor
"An independent audit of all transactions funded from the Cardano treasury shall be possible."
Assessment: 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.
Guardrail TREASURY-04a
"Treasury withdrawals for budget proposals require greater than 50% of DRep active voting stake to vote Yes."
Assessment: 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.
Scope of Work
Twelve 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.
Where 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.
Q2: Testnet Block Production and Leios Prototype
Goal: 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.
What we'll deliver:
- 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.
- Hard fork combinator: protocol version negotiation and era transition so Dingo handles forks without restarting.
- Genesis bootstrap: the Ouroboros Genesis mechanism for nodes joining from scratch, including peer selection and chain validation during initial sync.
- Stable ChainSync from genesis to tip on preview and preprod. Graceful handling of interruptions, disconnections, rollbacks.
- 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.
- Conformance test expansion beyond the current 314 vectors to cover consensus edge cases and epoch boundaries.
Q3: Operational Hardening and Storage Scalability
Goal: Harden Dingo for long-running stability and address the known storage risks at mainnet data volumes.
What we'll deliver:
- Operational hardening: profiling under realistic workloads. Find memory leaks, optimize hot paths, establish performance baselines.
- 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.
- UTxO set management at mainnet cardinality: acceptable lookup latency and memory footprint.
- Mainnet-scale testing: Dingo against ~100M UTxOs, ~500 GB chain, realistic volumes. Sync, resource consumption, block production under load, crash recovery.
- Long-running stability: weeks of continuous operation. No leaks, no corruption, no degradation.
- Cross-node validation: automated parallel execution against the Haskell node, block-by-block comparison to catch ledger state discrepancies.
- Security audit kickoff with a major firm (Trail of Bits, NCC Group, or equivalent). Consensus correctness, crypto, network handling, DoS resistance.
Q4: Dijkstra Hard Fork Readiness and Leios Integration
Goal: 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.
What we'll deliver:
- Dijkstra protocol changes: ledger rules, new parameters, governance modifications. Dingo processes Dijkstra blocks the moment the fork happens.
- Plutigo V4: new builtins, updated cost models, any UPLC evaluator changes.
- Leios consensus integration: bringing the Q2 prototype to full integration with consensus and the Dijkstra protocol changes.
- Remaining mini-protocols: Node-to-Client gaps and LocalStateQuery completion for Haskell node feature parity. Downstream tools need this.
Q1 2027: Mainnet Readiness, Audit Completion, and Ecosystem Integration
Goal: Finish the audit, hit mainnet readiness, and deliver the ecosystem work that makes Dingo actually useful to people.
What we'll deliver:
- Security audit completion. All findings addressed. Critical and high-severity issues fixed before any mainnet recommendation. Full report published.
- 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.
- Ecosystem integration: the practical stuff: key management and KES rotation, db-sync compatibility or equivalent indexing, API parity for wallets, explorers, dApps.
- Mithril integration. Fast bootstrapping, sync in minutes instead of hours.
- Operator docs: deployment, configuration, monitoring, troubleshooting. The stuff you need to actually run this in production.
- P2P hardening: peer discovery, connection management, topology optimization.
Conclusion
Dingo 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.
The 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.
After twelve months:
- Dingo produces blocks on mainnet.
- SPOs have a real alternative block producer.
- Dijkstra works from day one.
- Leios exists in Go alongside the Haskell reference.
- The audit report is public.
- Every ADA is accounted for on-chain.
We've spent years building this. This proposal is what turns it into something the network can depend on.
All software is Apache 2.0. Everything is in the public treasury-proposal repository (https://github.com/blinklabs-io/treasury-proposal).
부가 정보
| 트랜잭션 해시 | f35285db3c4e085ad331843b3007737952b8a322bb3216311edc37fdf44ad3da |
|---|---|
| 블록 타임 | 1772841631 |
| Proposal ID | gov_action17dfgtkeufcy945e3ssanqpmn09ft3gezhvepvvg7msmlmaz260dqqjtsmpe |
| Proposal Index | 0 |
Blink Labs의 Go 기반 상용 등급 블록 프로듀서 Dingo에 대한 제안
현재 어디까지 왔나
📊 제안서 투표현황
DRep 투표현황
SPO 투표현황
헌법위원회 투표현황
📝 상세 설명
🇰🇷 한글 버전
- Dingo는 현재 개발 중인 프로젝트로, 지난 1년 동안 1,290개 이상의 PR 병합과 Plutus V1/V2/V3 100% 적합성 달성 등 상당한 성과를 거두었음 .
- 현재 314개의 적합성 테스트를 통과했으며 VRF/KES 암호화, ChainSync, mempool 및 거버넌스 트랜잭션을 지원함 .
- 요청된 자금은 Ouroboros Praos 합의 완료, Dijkstra 하드포크 지원, CIP-0164 Linear Leios 구축을 통해 Dingo를 메인넷 블록 생성 가능 수준으로 끌어올리는 데 사용될 예정임 .
- 또한 적절한 보안 감사와 대규모 환경에서의 노드 신뢰성 확보를 위한 운영 강화 작업도 포함됨 .
- ■ 주석 *Go: 구글에서 개발한 프로그래밍 언어 **PR: 코드 변경 사항을 검토하고 병합하기 위한 요청 ***Plutus: 에이다의 스마트 컨트랙트 플랫폼 ****VRF/KES: 블록체인 보안 및 검증을 위한 암호화 기술 *****Mempool: 아직 블록에 포함되지 않은 트랜잭션 대기소 ******Ouroboros Praos: 에이다의 지분 증명 합의 알고리즘 *******Hard Fork: 블록체인의 이전 버전과 호환되지 않는 대규모 업데이트
- 고성능 네트워크 시스템에 적합한 Go 언어를 사용하여 에이다 핵심 인프라를 구축하고 있음 .
- 2021년부터 Dingo, gOuroboros, Plutigo 등 다양한 에이다 관련 프로젝트를 성공적으로 출시했음 .
- 현재 에이다는 단일 노드 구현체에 의존하고 있어 버그 발생 시 네트워크 전체가 위험할 수 있음 .
- Dingo는 Go 언어 기반의 독립적인 노드 구현을 통해 네트워크의 회복 탄력성과 다양성을 제공함 .
- Go 언어의 넓은 개발자 층을 활용하여 에이다 생태계에 대한 접근성을 획기적으로 높일 수 있음 .
- 지난 12개월 동안 1,290개의 PR을 처리하며 높은 개발 효율성과 전문성을 입증했음 .
- Leios 도입을 통해 에이다의 처리량을 30~50배 향상시키는 작업을 진행 중임 .
- 총 예산은 약 2.07M 달러이며, 이는 약 4.14M ₳에 해당함 .
- 모든 결과물은 Apache 2.0 라이선스의 오픈 소스로 공개되어 공공재로서의 가치를 지님 .
- 자금 지원이 없을 경우 메인넷 노드 운영 및 보안 감사 등 핵심 기능 구현이 지연될 수 있음 .
- ■ 주석 *Go: 구글에서 개발한 고성능 프로그래밍 언어 **Dingo: Blink Labs에서 개발 중인 Go 기반 에이다 노드 ***Ouroboros: 에이다의 지분 증명 합의 프로토콜 ****Plutus: 에이다의 스마트 컨트랙트 플랫폼 *****PR: 코드 변경 사항을 검토하고 병합하기 위한 요청 ******SPO: 에이다 네트워크에서 스테이크 풀을 운영하는 주체 *******Leios: 에이다의 처리량을 높이기 위한 새로운 합의 메커니즘 ********Apache 2.0: 자유로운 사용과 수정을 허용하는 오픈 소스 라이선스
- 현재 에이다 가격인 $0.30를 기준으로 총 6.9M ₳의 단일 국고 인출을 제안함 .
- 예산은 엔지니어링 1M USD, 운영 250,000 USD, 보안 감사 500,000 USD 등으로 구성됨 .
- 불확실성에 대비하여 약 15%인 270,000 USD의 예비비를 포함하였음 .
- SundaeSwap의 스마트 컨트랙트를 통한 에스크로 방식으로 자금을 관리함 .
- 독립적인 감독 위원회가 마일스톤 달성 여부를 검토하고 자금 집행을 승인함 .
- Q2에는 테스트넷 블록 생성 및 Leios 프로토타입 개발에 집중함 .
- Q3에는 메인넷 규모의 데이터 처리를 위한 저장소 확장성 및 안정화 작업을 수행함 .
- Q4에는 Dijkstra 하드포크 대응 및 Leios 통합을 완료할 예정임 .
- 2027년 Q1까지 보안 감사를 마치고 메인넷 운영 준비 및 생태계 통합을 완료함 .
- 모든 소프트웨어는 Apache 2.0 라이선스로 공개되며 투명하게 보고됨 .
- ■ 주석 *FTE: 전일제 근무 인원 **CI/CD: 지속적 통합 및 지속적 배포 ***DRep: 위임 대표 ****SPO: 스테이크 풀 운영자 *****VRF: 검증 가능한 랜덤 함수 ******KES: 키 진화 서명 *******PR: 풀 리퀘스트 ********CIP: 카르다노 개선 제안 *********UTxO: 미사용 트랜잭션 출력값 **********P2P: 개인 간 연결 네트워크
🇺🇸 English
Blink Labs
We're a small engineering company focused exclusively on blockchain software integrated with Cardano. We build in Go because it's the right language for high-performance networked systems, and because Cardano benefits from having core infrastructure that millions of developers can actually read and work on. Our team includes a part-time documentation engineer and six part-time Paid Open Source Contributors who help maintain and expand the ecosystem.
We've been building on Cardano since 2021. Here's what we've shipped:
- Dingo (https://github.com/blinklabs-io/dingo): Our Go Cardano node: ChainSync, VRF/KES block forging primitives, Plutus evaluation, mempool, governance, UTxO RPC, Mini-Blockfrost, and Mesh (Rosetta) APIs. Not mainnet-ready yet, but 300+ merged PRs and 314/314 conformance tests.
- gOuroboros (https://github.com/blinklabs-io/gouroboros): Ouroboros mini-protocol library with full era support from Byron through Conway. 2,200+ tests, used by downstream projects.
- Plutigo (https://github.com/blinklabs-io/plutigo): Our Plutus script evaluator: V1, V2, V3 at 100% conformance. Integrated into Dingo.
- ouroboros-mock (https://github.com/blinklabs-io/ouroboros-mock): Conformance testing framework with 314 Amaru test vectors and ledger state mocking. Shared infrastructure.
- Adder (https://github.com/blinklabs-io/adder): Chain indexing and event notification pipeline with pluggable outputs. In production.
- nview (https://github.com/blinklabs-io/nview): Terminal-based node monitoring. Shipped.
- TxSubmit API (https://github.com/blinklabs-io/tx-submit-api): Transaction submission service. In production, Docker-based.
- Docker images: Cardano node and tooling containers, widely adopted by SPOs.
Beyond our own projects, we co-maintain several Go libraries across the Cardano ecosystem, including Apollo, Ogmigo, Kugo, and the UTxO RPC Go SDK.
Our prior Cardano funding has come from Project Catalyst (which funded gOuroboros development and initial Dingo work) and from self-funding. We're PRAGMA members, but we haven't received any funds from Amaru's treasury proposal or any other treasury withdrawal despite our membership. This proposal stands on its own.
Key Personnel
- Chris Gianelloni, Lead Architect. Designed and leads development of Dingo, gOuroboros, and the broader Go infrastructure stack. Architecture decisions, protocol implementation, and technical direction.
- Christina Gianelloni, COO. Marketing, community outreach, DRep engagement, AMAs, social media, and governance communications. She keeps the non-engineering side running so the developers can focus.
Why Dingo
Node Diversity Is Network Resilience
Cardano runs on a single node implementation for block production. Every block producer on the network runs the same code. A critical bug in one place (consensus defect, memory leak under load, vulnerability in production) hits all of them at once. There's no fallback.
Node diversity changes that. Amaru is building a Rust implementation, and Dingo brings Go. Multiple independent implementations mean a bug in one doesn't take down the whole network. Ethereum learned this the hard way. Their multi-client architecture has saved them repeatedly when individual clients hit bugs that would've been network-wide outages otherwise.
Go Ecosystem Accessibility
Cardano's core infrastructure is written in Haskell. Go has over 5 million active developers and ranks 7th on TIOBE. It's the language the industry already chose for blockchain nodes: Geth (Ethereum), btcd (Bitcoin), CometBFT (50+ Cosmos chains), AvalancheGo, Algorand, and Filecoin. A Go Cardano node isn't novel. It's overdue.
Dingo opens Cardano's node internals to those 5 million+ developers. Engineers at Google, Cloudflare, Docker can read this code, audit it, and contribute to it without learning a new language. This isn't about replacing Haskell. It's about making Cardano accessible to the developers who are actually out there.
Delivery Track Record and Cost Efficiency
We have a documented track record. Across Dingo, gOuroboros, and Plutigo, we've merged 1,290 non-dependency PRs in the past twelve months, 593 in the last quarter, accelerating. With 2-3 engineers. That works out to roughly 36 PRs per person per month, with 304,000+ lines of code added.
These numbers are backward-looking, not promises. The work shifts from protocol implementation to consensus hardening, which is different. But the engineering culture that produced those numbers is the same culture we're bringing to this proposal.
Development discipline: We write small PRs, about 236 lines each. On purpose. Smaller PRs mean faster review, lower merge risk, tighter feedback loops. It adds up: 304,000 lines of new code in twelve months.
Cost efficiency: Personnel cost is $1,250,000 for five FTEs ($250,000 per FTE). The rest is a one-time audit ($500,000), hosting ($50,000), and 15% contingency. Other funded node implementations priced at $0.50/ADA during the 2025 cycle. At that same price, our $2,070,000 total is roughly 4,140,000 ADA. We're not padding this.
Scalability Through Leios
CIP-0164 Linear Leios is where Cardano gets its next major throughput jump, 30-50x through a two-block-type architecture (Endorser Blocks and Ranking Blocks) with sortition-based voting and certificates. We're already working directly with IO Engineering on this, and Go's concurrency model (goroutines and channels) is basically purpose-built for the kind of pipeline concurrency Leios needs. Building it in Go alongside the Haskell reference also strengthens the spec. You find ambiguities faster when two teams implement the same protocol in two different languages.
Sustainability Through Open Source
Everything we build is Apache 2.0. Always has been, always will be. This work is a permanent public good. It doesn't go away if Blink Labs does.
What the Ecosystem Loses Without Funding
Without funding, Dingo continues on whatever time we can scrape together from existing resources. Concretely:
- Block production limited to local devnet only. The consensus work for live networks doesn't get done.
- No SPO story. Pool operators can't run it as a block producer. Node diversity stays a talking point, not a reality.
- Dijkstra support will still happen, but on a slower timeline.
- Leios in Go limited to client-side only. The spec-strengthening benefits of a full second implementation don't materialize.
- No audit. That takes real money.
The Cardano community has already invested in this stack through Catalyst and through years of our own time and money. Without this funding, that investment doesn't reach its potential.
We'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.
Budget Breakdown:
- Engineering (4 FTE Go engineers x 12 months): $1,000,000
- Operations (1 FTE x 12 months: infrastructure, COO, marketing & outreach): $250,000
- Security Audit (major firm): $500,000
- Infrastructure hosting & CI/CD: $50,000
- Subtotal: $1,800,000
- Contingency (~15% for scope uncertainty): $270,000
- Total: $2,070,000
Requested Amount: 6,900,000 ADA (at $0.30/ADA)
Notes on the Budget
- 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.
- 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.
- 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.
- 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.
- 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.
- Single withdrawal. Full amount in one treasury withdrawal, with milestones enforced by smart contract escrow and oversight board review.
Effort Estimate and Capacity Buffer
We 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%).
Our 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.
Why 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.
Administration of the Budget
Smart Contract Escrow
Funds are held and released through the SundaeSwap treasury-contracts (https://github.com/SundaeSwap-finance/treasury-contracts), a proven framework with two validators:
- treasury.ak: Holds all ADA withdrawn from the Cardano treasury. Everything gets locked here when the governance action is enacted.
- vendor.ak: Manages milestone-based vesting for Blink Labs. Payment schedule, payout dates, release conditions.
Both contracts have been independently audited by TxPipe and MLabs and are in production use on mainnet.
Blink Labs as Single Vendor
We're the sole vendor. All work comes from Blink Labs. No subcontractors. If something isn't delivered, you know exactly who to hold accountable.
Independent Oversight Board
An independent oversight board provides third-party governance:
- Pi Lanningham (SundaeSwap)
- Santiago Carmuega (TxPipe)
- Lucas Rosa (Aiken, Midnight)
Board members don't have a stake in Blink Labs. They co-sign disbursements, review milestones, and can halt funding if we're not delivering.
Permission Scheme
We use a least-friction permission model: no bottlenecks, but real oversight:
- Disburse (periodic release): Blink Labs initiates + any 1 board member co-signs
- Sweep early (return unused funds): Blink Labs + any 1 board member
- Reorganize (adjust milestone schedule): Blink Labs only
- Fund (initial vendor setup): Board majority
- Pause milestone: Any 1 board member
- Resume milestone: Board majority
- Modify project: Blink Labs + board majority
Day-to-day operations need one board signature. Structural changes need the full board. And any single member can hit pause if something looks off.
Delegation Policy
The 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.
Failsafe Sweep
Funds left in the contract after expiration automatically sweep back to the Cardano treasury. Enforced at the contract level. Can't be overridden.
Periodic Fixed Releases
Funds 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.
Reporting
Monthly Lightweight Updates
End of each month, we publish a status update:
- What shipped
- Key PRs, features, milestones
- Risks or blockers
- What's next
Updates go to the treasury-proposal repository (https://github.com/blinklabs-io/treasury-proposal) and community channels.
Quarterly Detailed Reports
Each quarter, a full report:
- Progress against each milestone
- Financial summary: received, spent by category, remaining
- Variance analysis for budget deviations
- Updated risk register
- Next quarter's plan
Quarterly reports coincide with disbursement requests, giving the board what they need to authorize releases.
Public Transaction Journal
Every 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.
Coding Sessions and Demos
We 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.
Constitutionality Checklist
This section checks the proposal against the Cardano Constitution (v2.4), following the PRAGMA mnemos format (https://github.com/pragma-org/mnemos).
Purpose
This 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.
Article III, Section 5: On-Chain Governance Actions
"Governance actions shall follow a standardized and legible format, including a URL and hash of any off-chain content."
Assessment: 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.
Article IV, Section 1: Budget for the Cardano Blockchain Ecosystem
"A budget for the Cardano Blockchain ecosystem shall be adopted on an annual basis through an on-chain governance action."
Assessment: COMPLIANT. Twelve months (~73 epochs), aligned with the annual cycle. Budget fully specified: engineering, audit, infrastructure, contingency.
Article IV, Section 2: Fund Administration
"Cardano Blockchain ecosystem budgets shall be administered by one or more budget administrators or administrators selected through a transparent process."
Assessment: 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.
Article IV, Section 3: Net Change Limit
"The Net Change Limit shall be observed by all treasury withdrawals during the applicable budget period."
Assessment: COMPLIANT. Doesn't violate the active NCL at submission. We'll operate within whatever NCL is in effect.
If 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.
Article IV, Section 4: Auditor
"An independent audit of all transactions funded from the Cardano treasury shall be possible."
Assessment: 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.
Guardrail TREASURY-04a
"Treasury withdrawals for budget proposals require greater than 50% of DRep active voting stake to vote Yes."
Assessment: 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.
Scope of Work
Twelve 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.
Where 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.
Q2: Testnet Block Production and Leios Prototype
Goal: 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.
What we'll deliver:
- 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.
- Hard fork combinator: protocol version negotiation and era transition so Dingo handles forks without restarting.
- Genesis bootstrap: the Ouroboros Genesis mechanism for nodes joining from scratch, including peer selection and chain validation during initial sync.
- Stable ChainSync from genesis to tip on preview and preprod. Graceful handling of interruptions, disconnections, rollbacks.
- 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.
- Conformance test expansion beyond the current 314 vectors to cover consensus edge cases and epoch boundaries.
Q3: Operational Hardening and Storage Scalability
Goal: Harden Dingo for long-running stability and address the known storage risks at mainnet data volumes.
What we'll deliver:
- Operational hardening: profiling under realistic workloads. Find memory leaks, optimize hot paths, establish performance baselines.
- 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.
- UTxO set management at mainnet cardinality: acceptable lookup latency and memory footprint.
- Mainnet-scale testing: Dingo against ~100M UTxOs, ~500 GB chain, realistic volumes. Sync, resource consumption, block production under load, crash recovery.
- Long-running stability: weeks of continuous operation. No leaks, no corruption, no degradation.
- Cross-node validation: automated parallel execution against the Haskell node, block-by-block comparison to catch ledger state discrepancies.
- Security audit kickoff with a major firm (Trail of Bits, NCC Group, or equivalent). Consensus correctness, crypto, network handling, DoS resistance.
Q4: Dijkstra Hard Fork Readiness and Leios Integration
Goal: 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.
What we'll deliver:
- Dijkstra protocol changes: ledger rules, new parameters, governance modifications. Dingo processes Dijkstra blocks the moment the fork happens.
- Plutigo V4: new builtins, updated cost models, any UPLC evaluator changes.
- Leios consensus integration: bringing the Q2 prototype to full integration with consensus and the Dijkstra protocol changes.
- Remaining mini-protocols: Node-to-Client gaps and LocalStateQuery completion for Haskell node feature parity. Downstream tools need this.
Q1 2027: Mainnet Readiness, Audit Completion, and Ecosystem Integration
Goal: Finish the audit, hit mainnet readiness, and deliver the ecosystem work that makes Dingo actually useful to people.
What we'll deliver:
- Security audit completion. All findings addressed. Critical and high-severity issues fixed before any mainnet recommendation. Full report published.
- 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.
- Ecosystem integration: the practical stuff: key management and KES rotation, db-sync compatibility or equivalent indexing, API parity for wallets, explorers, dApps.
- Mithril integration. Fast bootstrapping, sync in minutes instead of hours.
- Operator docs: deployment, configuration, monitoring, troubleshooting. The stuff you need to actually run this in production.
- P2P hardening: peer discovery, connection management, topology optimization.
Conclusion
Dingo 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.
The 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.
After twelve months:
- Dingo produces blocks on mainnet.
- SPOs have a real alternative block producer.
- Dijkstra works from day one.
- Leios exists in Go alongside the Haskell reference.
- The audit report is public.
- Every ADA is accounted for on-chain.
We've spent years building this. This proposal is what turns it into something the network can depend on.
All software is Apache 2.0. Everything is in the public treasury-proposal repository (https://github.com/blinklabs-io/treasury-proposal).