A
# Cardano Budget 2026 — Voting Intentions, Analysis & Proposer Feedback

> Machine-readable export of https://adatool.net/b69-share2
> This page contains the SAME content as the interactive page, rendered as plain Markdown for AI/LLM ingestion. No JavaScript required.

- Generated (voting intentions): 2026-05-28
- Caveat (EN): Voting reasons are updated in stages: (1) original reasons as of 2026-05-28, (2) responses to feedback up to 2026-06-02, and (3) final voting reasons as of 2026-06-10 (votes also updated). (1) and (2) are preserved and still viewable inside each proposal. I have reviewed all feedback received up to now. This is not a final lock-in — I will keep reviewing new feedback as much as possible until voting closes (though I may not be able to respond to every item depending on volume).
- Caveat (JA): 投票理由は段階的に更新しています: ①2026-05-28 の当初理由、②2026-06-02 までのフィードバック返答、③2026-06-10 の最終投票理由(投票も更新)、④2026-06-12 の追記(Wirexは投票をNO→Abstainに変更)。①②は消さずに各提案内で引き続き閲覧できます。現時点までに頂いたフィードバックはすべて確認済みです。これは最終確定ではなく、今後(投票締切まで)届くフィードバックも可能な限り確認を続けます(件数によっては全てに返答できない可能性があります)。
- Total proposals: 69
- Proposer feedback collected: 93 items across 40 proposals (last updated 2026-06-02)

Voter: a Japanese ADA DRep (YUTA, @yutazzz). "Prior analysis" = the per-criterion rationale from the earlier /b69-share snapshot. "Proposer feedback" = responses from proposers on the Hydra voting platform and on X, directed at the voter. Proposer feedback is reproduced verbatim; summaries are neutral (no value judgment).

## ⚠️ If you cannot read this whole document in one fetch

This combined document is long. Each proposal also has its OWN short page that always fits in one fetch and is RICHER (it additionally includes the full proposal text and ALL Hydra comments):

    https://adatool.net/b69-share2/llm/<N>     where <N> = 1..69

Fetch those individually for any proposal you need. The full per-proposal index (with the data needed to pick) is immediately below.

## Vote tally

- NO: 45
- YES: 15
- Abstain: 9

---

## Index — all 69 proposals (with per-proposal URLs)

| # | Vote | ADA | Feedback | Title | Full per-proposal page |
|---|------|-----|----------|-------|------------------------|
| 1 | NO | 65,405,000 | 1 | Diversify Cardano treasury into prime, yield-bearing real-estate | https://adatool.net/b69-share2/llm/1 |
| 2 | YES | 25,400,000 | 0 | Intersect: Governance coordination and technical stewardship for the Cardano ecosystem | https://adatool.net/b69-share2/llm/2 |
| 3 | NO | 20,871,418 | 2 | The Marketing Powered Demand Engine for Cardano | https://adatool.net/b69-share2/llm/3 |
| 4 | NO | 20,600,000 | 0 | Wormhole Cross-Chain Infrastructure for Cardano: Institutional RWAs, Native Multichain Stablecoins | https://adatool.net/b69-share2/llm/4 |
| 5 | NO | 20,600,000 | 2 | Cardano Builder DAO | https://adatool.net/b69-share2/llm/5 |
| 6 | NO | 15,820,800 | 1 | Project Janus: A Roadmap to Decentralized Bridge Authorization and Generalized Cross-Chain Messaging | https://adatool.net/b69-share2/llm/6 |
| 7 | NO | 14,304,640 | 7 | Innovation & Growth DAO | https://adatool.net/b69-share2/llm/7 |
| 8 | NO | 13,150,479 | 3 | A High-Performance Partner Chain Factory using Ouroboros Tachýs | https://adatool.net/b69-share2/llm/8 |
| 9 | NO | 9,373,803 | 3 | Support Cardano 2030: A Techstars Strategy for Global Ecosystem Adoption & Utility | https://adatool.net/b69-share2/llm/9 |
| 10 | NO | 8,583,334 | 0 | Amplify Cardano: Ecosystem Accelerator + Community-Led Marketing & Events Fund | https://adatool.net/b69-share2/llm/10 |
| 11 | Abstain | 7,890,487 | 12 | Security Threat Assessment Guard (STAG): Continuous Security Assurance for the Cardano Ecosystem | https://adatool.net/b69-share2/llm/11 |
| 12 | NO | 6,200,600 | 3 | Cardano Startup Mainnet Runway (CSMR) | https://adatool.net/b69-share2/llm/12 |
| 13 | NO | 6,180,000 | 2 | Cardano Tooling DAO | https://adatool.net/b69-share2/llm/13 |
| 14 | NO | 5,150,000 | 0 | DeltaDeFi: Cardano Flagship Exchange: 5,000,000 Treasury Loan with Perpetual Upside | https://adatool.net/b69-share2/llm/14 |
| 15 | NO | 4,601,000 | 6 | Paid Open Source Model - Continued | https://adatool.net/b69-share2/llm/15 |
| 16 | NO | 4,372,865 | 3 | Cardano Enterprise Adoption: Production Ticketing Platform | https://adatool.net/b69-share2/llm/16 |
| 17 | Abstain | 3,965,500 | 1 | Indigo Innovation Proposal: V2030RS, Tokenized RWA, BTC-Fi & Privacy | https://adatool.net/b69-share2/llm/17 |
| 18 | Abstain | 3,961,538 | 0 | Bringing Real-World Payments to Cardano with Wirex | https://adatool.net/b69-share2/llm/18 |
| 19 | Abstain | 3,810,423 | 0 | Mithril Protocol | https://adatool.net/b69-share2/llm/19 |
| 20 | Abstain | 3,599,850 | 0 | DeFi Ecosystem Connectivity via Ledger Wallet with Clear Signing | https://adatool.net/b69-share2/llm/20 |
| 21 | Abstain | 3,489,366 | 2 | Eryx: Zero-Knowledge Capabilities | https://adatool.net/b69-share2/llm/21 |
| 22 | YES | 3,399,000 | 0 | Dano Finance: DeFi Kernel, American Options, and Orderbook SDK | https://adatool.net/b69-share2/llm/22 |
| 23 | NO | 3,006,828 | 3 | GOV.EXE by TxPipe & gf Consulting Group: Public Project Execution Integrity, Pilot in Argentina | https://adatool.net/b69-share2/llm/23 |
| 24 | NO | 2,950,000 | 1 | DeFi Rails & Deployment Pilot Program | https://adatool.net/b69-share2/llm/24 |
| 25 | NO | 2,922,885 | 3 | MLabs - TrueInventory: An accessible blockchain inventory for videogame developers | https://adatool.net/b69-share2/llm/25 |
| 26 | NO | 2,664,095 | 1 | Governance Coalition: Governance Prototype and RFP Program | https://adatool.net/b69-share2/llm/26 |
| 27 | NO | 2,500,000 | 1 | DeFi US App-Layer and Demand Activation and Capital Execution Pilot Program | https://adatool.net/b69-share2/llm/27 |
| 28 | NO | 2,218,620 | 0 | Cardano app on Ledger maintained by Ledger Technologies SAS | https://adatool.net/b69-share2/llm/28 |
| 29 | NO | 2,193,900 | 2 | Libertum: Institution-Grade Participation Infrastructure for Cardano Real-World Assets | https://adatool.net/b69-share2/llm/29 |
| 30 | NO | 1,874,600 | 1 | Autonomous AI Finance on Cardano with ClawBank | https://adatool.net/b69-share2/llm/30 |
| 31 | NO | 1,802,500 | 0 | Marlowe V2 | https://adatool.net/b69-share2/llm/31 |
| 32 | YES | 1,684,050 | 1 | Tx3 by TxPipe: Open API Layer for Cardano's dApp Protocols | https://adatool.net/b69-share2/llm/32 |
| 33 | NO | 1,596,500 | 1 | Hub-Network Liquidity: A Protocol for Revenue-based Finance at Network Scale | https://adatool.net/b69-share2/llm/33 |
| 34 | NO | 1,524,400 | 1 | Cardano Content Creator Consortium (C4): Ecosystem Video Content Production, Marketing & Education | https://adatool.net/b69-share2/llm/34 |
| 35 | NO | 1,519,250 | 0 | Cardano Business Development Network: Accelerating Enterprise Adoption Through Coordinated BD Hubs | https://adatool.net/b69-share2/llm/35 |
| 36 | NO | 1,484,333 | 2 | MLabs - Covenant 2: Cross-Language Support and Developer Experience | https://adatool.net/b69-share2/llm/36 |
| 37 | NO | 1,441,996 | 0 | Evolution SDK 2026. Hardening to v1.0, Modern DevEx, and the Agent Economy | https://adatool.net/b69-share2/llm/37 |
| 38 | Abstain | 1,401,361 | 3 | MLabs: Better arrays for everyone | https://adatool.net/b69-share2/llm/38 |
| 39 | NO | 1,390,508 | 2 | Ecosera: The End-to-End Clinical Research Ecosystem — From Trial Funding to Drug Approval on Cardano | https://adatool.net/b69-share2/llm/39 |
| 40 | Abstain | 1,366,456 | 2 | MLabs: Encrypted Programmable Tokens with TFHE | https://adatool.net/b69-share2/llm/40 |
| 41 | NO | 1,350,330 | 1 | Enhance Swarm Treasury System with Open Social Governance | https://adatool.net/b69-share2/llm/41 |
| 42 | NO | 1,339,000 | 0 | Open Sourced RWA Tokenization Framework with Revenue Share Model | https://adatool.net/b69-share2/llm/42 |
| 43 | Abstain | 1,337,763 | 3 | MLabs - Cardano Tx Library: JavaScript/TypeScript Interface, Koios Backend, Hard Fork Maintenance | https://adatool.net/b69-share2/llm/43 |
| 44 | NO | 1,311,190 | 2 | Integration of Cardano into the Houdiniswap Aggregator | https://adatool.net/b69-share2/llm/44 |
| 45 | YES | 1,310,960 | 0 | Hardware Wallet Maintenance 2026 | https://adatool.net/b69-share2/llm/45 |
| 46 | NO | 1,256,600 | 0 | zkFold Open Source Cardano Infrastructure 2026 | https://adatool.net/b69-share2/llm/46 |
| 47 | YES | 1,240,000 | 0 | 2027 Objectives, Research validation & Market Pilots - IntersectCPC | https://adatool.net/b69-share2/llm/47 |
| 48 | YES | 1,193,000 | 0 | Intersect Technical Steering Committee Support | https://adatool.net/b69-share2/llm/48 |
| 49 | NO | 1,171,903 | 1 | MLabs - Cardano.nix: 2026 Maintenance, Operator Tooling, and Dijkstra Readiness | https://adatool.net/b69-share2/llm/49 |
| 50 | NO | 1,167,325 | 3 | MLabs - Grumplestiltskin 2: Pasta Curve Builtins and Kimchi PLookup Proof-of-Concept | https://adatool.net/b69-share2/llm/50 |
| 51 | YES | 1,162,746 | 1 | MLabs Core Tool Maintenance & Enhancement: Plutarch and Ply | https://adatool.net/b69-share2/llm/51 |
| 52 | YES | 1,153,600 | 0 | Daedalus Wallet Maintenance and Improvements 2026-2027 | https://adatool.net/b69-share2/llm/52 |
| 53 | NO | 982,433 | 3 | Catalyze Africa: Building Scalable Projects from CATS 2026 | https://adatool.net/b69-share2/llm/53 |
| 54 | YES | 952,750 | 0 | Nula: Cardano's token streaming protocol | https://adatool.net/b69-share2/llm/54 |
| 55 | NO | 929,699 | 0 | Cardano Enterprise Activation Sandbox | https://adatool.net/b69-share2/llm/55 |
| 56 | YES | 758,762 | 1 | MLabs: Post-quantum signature verification support | https://adatool.net/b69-share2/llm/56 |
| 57 | NO | 734,730 | 1 | MLabs: Open-Sourcing FeesaSwap as Live Fee Abstraction Infrastructure on Cardano | https://adatool.net/b69-share2/llm/57 |
| 58 | NO | 653,947 | 1 | Infrastructure for Quality Certification and Traceability in the Floriculture Industry | https://adatool.net/b69-share2/llm/58 |
| 59 | NO | 600,000 | 0 | Cardano Budget Committee: Budget Process Improvement and Treasury Transparency (2026-2027) | https://adatool.net/b69-share2/llm/59 |
| 60 | NO | 556,200 | 0 | Full Integration of CIP-113 with Clear Signing across Ledger Products | https://adatool.net/b69-share2/llm/60 |
| 61 | YES | 540,750 | 0 | Oura by TxPipe: Maintaining Cardano's Event Pipeline | https://adatool.net/b69-share2/llm/61 |
| 62 | YES | 540,750 | 0 | UTxO RPC by TxPipe: Maintaining Cardano's Integration Standard, Year 2 | https://adatool.net/b69-share2/llm/62 |
| 63 | YES | 540,750 | 0 | Dolos by TxPipe: Maintaining Cardano's Lightweight Data Node, Year 2 | https://adatool.net/b69-share2/llm/63 |
| 64 | YES | 540,750 | 0 | Pallas by TxPipe: Maintaining Cardano's Core Rust Libraries, Year 2 | https://adatool.net/b69-share2/llm/64 |
| 65 | NO | 442,900 | 3 | Civics Committee Governance Expert Led, Sustainable Education Program | https://adatool.net/b69-share2/llm/65 |
| 66 | YES | 432,600 | 0 | BloxBean Java/JVM Toolchain for Cardano: 2026 Maintenance & New Initiatives | https://adatool.net/b69-share2/llm/66 |
| 67 | NO | 412,000 | 0 | Formal Verification in Lean 4 and Blaster — Cardano Auditor Training Program 2026 | https://adatool.net/b69-share2/llm/67 |
| 68 | NO | 343,814 | 1 | High-performance Rust Ogmios Client | https://adatool.net/b69-share2/llm/68 |
| 69 | NO | 339,900 | 0 | Cardano MCP by Lido Nation & 2 Lovelaces | https://adatool.net/b69-share2/llm/69 |

---

## Full records (all proposals inline below)

Note: each section below is the summary-level record. For the FULL proposal text + all Hydra comments, use the per-proposal page https://adatool.net/b69-share2/llm/<N>.

## 1. Diversify Cardano treasury into prime, yield-bearing real-estate

- Proposal ID: 69fd95dfb05ff80adc7d5c5c
- Requested: 65,405,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd95dfb05ff80adc7d5c5c
- Category: dApp - RWA
- Applicable criteria: C1, C9, C10
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. With regard to C1, my concerns are not alleviated. Furthermore, as other DReps have also pointed out, the very theory of diversifying the treasury through real-estate investment creates a risk that is difficult to justify.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。C1については懸念は軽減されません。また他のDRepも指摘するように、不動産投資を通じてトレジャリーを多様化するという理論自体が正当化しづらいリスクを生んでいます。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-RWA / treasury diversification]. Non-applicable: C2 (Foncière Renaissance is a real-estate fund, not a Cardano builder, so 'no Cardano-native track record' is by design — C2 inapplicable for treasury LP allocation), C3 (RWA fund process metrics are reasonable in BD context), C4 (treasury LP allocation has IRR as return mechanism, even if disputed), C5, C6, C7 (CoI not the central concern), C8 (no prior Cardano funding to attribute), C11.

**Applicable: C1, C9, C10**. Applying:

• **C1 — Tx/TVL contribution materiality**: RWA tokenized funds do not generate transactions at scale. Empirical reference: BlackRock BUIDL is the world's largest tokenized fund at **$147M AUM with only 1,359 cumulative transactions over 2 years** = approximately **50 tx/month with 54 holders** (per BUIDL public Etherscan data). Bridge Fund's 'several thousand tx/year' projection = **0.02-0.05% of Cardano's monthly 800K tx baseline** — within observational noise rather than meaningful contribution. The TVL +€100M figure also depends on raising €85M from external LPs; **only €15M is reliably committed by the Treasury**.

• **C9 — Thesis validation**: Two unsupported assertions:
  1. **'10% net IRR target'**: no comparable historical realized IRR data is disclosed for Foncière Renaissance or similar funds. Real estate IRR is path-dependent (interest rates, regional market cycles); without historical realized IRR, 10% is a marketing target, not an evidenced projection.
  2. **No precedent of any blockchain Treasury acting as LP** is cited. This is a category-novel investment for any blockchain treasury — pilot-stage, not validated thesis.

• **C10 — NCL allocation share (major concern)**: 65,405,000 ADA requested = **18.7% of the 350M ADA Net Change Limit for the 2026-27 budget cycle**. Per my voting policy: '<5% (proceed), 5-15% (scrutiny), >15% (major concern)' — this proposal hits the **major concern** band. A single proposal consuming nearly one-fifth of 18-month Treasury capacity crowds out other priority initiatives (USDCx integration, infrastructure, etc.).

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-RWA / treasury diversification]。 非適用: C2 (Foncière Renaissance は real-estate fund で Cardano builder ではない、 'no Cardano-native track record' は by design — treasury LP allocation には C2 inapplicable), C3 (RWA fund process metric は BD context で合理), C4 (treasury LP allocation は IRR を return mechanism に持つ、 dispute あるが), C5, C6, C7 (CoI は central concern ではない), C8 (attribution する prior Cardano funding なし), C11。

**適用: C1, C9, C10**。 適用:

・**C1 — Tx/TVL 寄与度**: RWA tokenized fund は scale で transaction 生成せず。 Empirical reference: BlackRock BUIDL は世界最大 tokenized fund で **$147M AUM、 2 年間で累積 1,359 tx のみ** = 約 **50 tx/月 with 54 holders** (BUIDL 公開 Etherscan data より)。 Bridge Fund の 'several thousand tx/year' 予測 = **Cardano 月次 800K tx baseline の 0.02-0.05%** — meaningful contribution ではなく observational noise 範囲内。 TVL +€100M figure は external LP からの €85M raise 依存で、 **Treasury の reliably committed 額は €15M のみ**。

・**C9 — thesis 検証**: 2 つの unsupported assertion:
  1. **'10% net IRR 目標'**: Foncière Renaissance や類似 fund の comparable historical realized IRR data 開示なし。 Real estate IRR は path-dependent (interest rate, regional market cycle); historical realized IRR なしでは 10% は marketing target で evidenced projection ではない。
  2. **Blockchain Treasury が LP となる先例の citation なし**。 これは any blockchain treasury にとって category-novel investment — pilot-stage で validated thesis ではない。

・**C10 — NCL 配分比率 (重大懸念)**: 65,405,000 ADA requested = **2026-27 budget cycle の 350M ADA Net Change Limit の 18.7%**。 投票ポリシーより: '<5% (進行), 5-15% (精査), >15% (重大懸念)' — 本提案は **重大懸念** 帯。 単一提案が 18 ヶ月 Treasury capacity の 5 分の 1 弱を消費 = 他 priority initiative (USDCx integration, infrastructure 等) を crowd out。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd95dfb05ff80adc7d5c5c#comment-6a058551a7468bb49bf8464c
- Summary (EN): Counter-evidence: C1 TVL is fiat-backed Parisian prime real estate (Big Four audited, multi-year locked, zero-rewards), arguably more durable than ADA-locked TVL. C9 cites €25M live raise on George V POC, 5 years tokenization track record, BCG/JPM RWA forecasts, BlackRock BUIDL/Franklin FOBXX precedent. C10 acknowledges 18.1% NCL ask, offers split across 2 cycles (~8% each) to stay under 15%.
- Summary (JA): 反証データ提示: C1のTVLは仏プライム不動産にBig Four監査+1:1担保+長期ロック+報酬ゼロで、ADAロックTVLより耐久的と主張。C9はGeorge V POCで€25M募集中、5年トークン化実績、BCG/JPM RWA予測、BlackRock BUIDL/Franklin FOBXXの先例。C10は18.1% NCLを認め、2サイクル分割 (~8%ずつ)で15%上限内に収める案を提示。

Full text:

Thanks for the rigorous review and the transparent criteria. Counter-evidence on C1, C9, C10:

C1 (TVL/Tx materiality):

Bridge Fund TVL is fiat-backed real estate, not narrative, not farming-incentivized. Three quality markers: (i) 1:1 collateralized by Big Four-audited Parisian prime real estate; (ii) multi-year locked via standard 7-10y institutional value-add cycle; (iii) zero rewards mechanism, retention is structural. This is a Tier 1 equivalent: not ADA-locked, but fiat-backed and crypto-cycle-uncorrelated, arguably outperforming ADA-locked TVL on durability.

C9 (Thesis validation):

Empirical anchors, not narrative: (1) Pilot live: €25M raise in execution on our George V POC, sourced from existing CGP/FO/crypto holder network; (2) 5 years tokenizing equity and debt in production on other chains; (3) Quantitative sizing: BCG/JPM/McKinsey project $10-16T RWA by 2030; (4) Direct precedent at scale: BlackRock BUIDL ($500M+), Franklin Templeton FOBXX ($400M+); (5) NDA banking partner: identity disclosed under NDA to 3 community-designated DReps for public validation, explicitly proposed in the original document.

C10 (NCL allocation):

Acknowledged: 63.5M ADA = 18.1% of 350M NCL. Two structural mitigants:

(a) LP recycling: this is not a grant. Treasury recovers principal + target net IRR 10% at maturity.

(b) If C10 remains a blocker, we are open to splitting the request across two NCL cycles (\~8% each) to preserve the cornerstone-LP role without breaching 15%. Happy to formalize in an updated milestone schedule.

Open to public follow-up on any of these.

---

## 2. Intersect: Governance coordination and technical stewardship for the Cardano ecosystem

- Proposal ID: 69e7a834d6a29288536b1200
- Requested: 25,400,000 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e7a834d6a29288536b1200
- Category: Governance coordination
- Applicable criteria: C8, C10
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

1. Reduce cost and ease community governance fatigue: please consolidate or shrink committees — fewer committees, fewer seats, more streamlined.
2. Redesign the organisational governance mechanism from zero so committee elections cannot be gamed (not weak measures like credit-card name checks).

### Voting reason (JA, as of 2026-05-28)

1. コスト削減及び、コミュニティのガバナンス疲れやリソースの限界の意味も含め:委員会の数を減らす、統合する、人数を減らす、など、より簡素化、スリム化を進めてほしい。
2. 組織のガバナンスの仕組みをゼロベースで見直して、委員会選挙で不正をできないようにする必要があります。(クレカの名義チェックをするなどの弱い予防策ではなく)

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Intersect: Governance coordination and technical stewardship (**25.4M ADA / NCL 7.26%**).

**Main reasons**

**1. NCL 7.26% is in the scrutiny band, and the ask is reduced cycle-over-cycle**
- Per voting policy: 5-15% NCL = scrutiny band.
- 25.4M ADA = 7.26% of 350M NCL.
- Per proposal: "overall ask has reduced from $7.875M to $6.35M" — the proposer cut $1.5M USD (~6M ADA at $0.25) while preserving critical functions.
- Direction of travel is right (ecosystem maturation = less scaffolding cost).

**2. Concrete technical-stewardship delivery evidence**
- Per proposal: Intersect has already "coordinated two network upgrades, is preparing for a third, and led ecosystem coordination during the November 2025 chain partition incident".
- The November 2025 chain partition is a verifiable event (recorded in Cardano node logs and public incident reports).
- Network-upgrade coordination is the kind of work where "no news = success".
- Multi-client Cardano (Amaru enacted; Dingo + Gerolamo in development) increases coordination workload, not decreases it.

**3. Intersect's role at the meta-governance layer is non-substitutable**

| Function | Substitute available? |
|---|---|
| MBO coordination layer | none — IOG is winding down this role |
| Network upgrade coordination | no community substitute at scale |
| Chain incident response (November 2025 precedent) | none — Intersect was the responder |
| Haskell repository stewardship | Intersect coordinates IOG + community contributors |
| CIP review + Hard Fork Working Group | TSC sub-bodies (funded separately) |
| Bug Bounty + Security Council | funded separately per proposal text |

Substitution would require building an alternative body — significant coordination cost and multi-year delay.

**4. Cycle-over-cycle history**
- Year 1 (2025 cycle equivalent): $7.875M ask.
- Year 2 (2026 cycle, this proposal): $6.35M ask.
- Reduction = 19% year-over-year in USD terms.
- Cost reduction while preserving core functions is the right direction for a maturing meta-governance body.

**5. 7.26% NCL covers a wide scope**
- Coordinates 2-3 network upgrades per cycle.
- Stewards Haskell repos.
- Runs incident response.
- Operates the infrastructure for CIP review + Hard Fork Working Group + Parameter Committee (TSC-separate).
- Runs Bug Bounty + Security Council (Bug Bounty separately scoped).
- Per-function cost is not the headline; package cost reflects the absence of an alternative body.

**6. Three parallel proposals are MBO-contingent**
- TSC (1.19M ADA), Budget Committee (600K ADA), and CPC (1.24M ADA) are all contingent on this MBO approval.
- MBO is the keystone — declining MBO triggers cascading withdrawals.

**Conclusion**: Default YES at scrutiny-band size given (a) cycle-over-cycle USD reduction, (b) verifiable delivery (November 2025 incident + 2 upgrades + 3rd in preparation), (c) non-substitutable meta-governance role, (d) MBO is the keystone for the parallel committee proposals.

### Prior detailed analysis (JA)

**Vote: YES** — Intersect: Cardano エコシステムのガバナンス調整と技術運営(**25.4M ADA / NCL 7.26%**)に YES。

**主な理由**

**1. NCL 7.26% は精査帯。ただし要求額はサイクル間で削減**
- 投票方針:NCL 5-15% = 精査帯。
- 25.4M ADA = NCL 350M の 7.26%。
- 提案書より:「総額要求は $7.875M から $6.35M に削減」— 提案者は重要機能を保ったまま $1.5M USD($0.25 換算で 約 6M ADA)を削減。
- 方向は正しい(エコシステム成熟 = 足場コスト減)。

**2. 技術運営の納品証拠が具体的**
- 提案書より:Intersect は既に「2つのネットワークアップグレードを調整、3つ目を準備中、2025年11月のチェーン分断時にはエコシステム調整を主導」。
- 2025年11月のチェーン分断は検証可能なイベント(Cardano ノードログと公開インシデント報告に記録)。
- ネットワークアップグレード調整は「無事故 = 成功」型の業務。
- マルチクライアント化(Amaru 採用、Dingo / Gerolamo 開発中)は調整作業量を増やす方向で、減らさない。

**3. メタガバナンス層での Intersect の役割は代替不能**

| 機能 | 代替の可否 |
|---|---|
| MBO 調整層 | なし — IOG は本役割から退き中 |
| ネットワークアップグレード調整 | 同規模のコミュニティ代替なし |
| チェーンインシデント対応(2025年11月の先例) | なし — Intersect が対応者 |
| Haskell リポジトリ管理 | Intersect が IOG + コミュニティ貢献者を調整 |
| CIP レビュー + ハードフォーク作業部会 | TSC サブ本体(別途資金) |
| バグバウンティ + セキュリティカウンシル | 提案書本文より別途資金 |

代替には別本体の構築が必要 — 多大な調整コストと数年の遅延。

**4. サイクル横断の履歴**
- Year 1(2025 サイクル相当):$7.875M 要求。
- Year 2(2026 サイクル、本提案):$6.35M 要求。
- USD ベースで前年比 19% 減。
- 重要機能を保ったまま費用を削減する方向は、成熟しつつあるメタガバナンス本体として正しい。

**5. NCL 7.26% で広い範囲をカバー**
- サイクル当たり 2-3 のネットワークアップグレード調整。
- Haskell リポジトリ管理。
- インシデント対応。
- CIP レビュー + ハードフォーク作業部会 + パラメータ委員会の基盤運営(TSC は別)。
- バグバウンティ + セキュリティカウンシル運営(バグバウンティは別途範囲)。
- 機能あたり単価が見出しではない。パッケージ価格は「代替本体なし」を反映している。

**6. 3つの並行提案が MBO 承認に連動**
- TSC(1.19M ADA)、Budget Committee(600K ADA)、CPC(1.24M ADA)は本 MBO 承認に連動。
- MBO は要石 — MBO 否決は連動的な取り下げを誘発する。

**結論**:精査帯の規模ながら、(a) サイクル横断での USD ベース削減、(b) 検証可能な納品(2025年11月のインシデント + 2 アップグレード + 3 つ目準備中)、(c) 代替不能なメタガバナンス役割、(d) 並行委員会提案の要石、で YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 3. The Marketing Powered Demand Engine for Cardano

- Proposal ID: 69e21a177a2045bdd2281d1a
- Requested: 20,871,418 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e21a177a2045bdd2281d1a
- Category: Marketing / events
- Applicable criteria: C1, C3, C8, C10
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Echoing other reviewers, three concerns. Otherwise the proposal isn't bad; hope to see an improved version via on-chain governance action.

1. W4 Cardano supply-chain solution is immature, no real market exists. Negligible vs. the DeFi market.
2. Need clearer definition of who receives generated leads, in which CRM, and how leads convert into deals / implementation / on-chain activity.
3. The $0.17/ADA buffer is excessive.

### Voting reason (JA, as of 2026-05-28)

他のレビュアーのコメントにあるように次の3点を懸念とします。それを除くと悪くはない可能性があり、オンチェーンガバナンスアクションで改善版が提出されることを願います。

1. W4 の Cardano のサプライチェーン解決策は未成熟で市場が存在しない。 DeFi 市場と比べれば誤差の範囲。
2. 「獲得したリードを誰が受け取り、 どの CRM で管理し、 どう商談・実装・オンチェーン活動に繋げるのか」のより詳細な定義
3. ADA/USD 0.17 のバッファーは過大です。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

The UK/Germany/Switzerland are described as the "optimal blend of audience size, adoption rate, and operational ease" (p.30). However, when checked against the data in your own Appendix on pp.22-23, these three countries can only be selected because regions with even higher audience size and adoption rates are excluded — that is, only in the case where operational feasibility is effectively the deciding factor. The proposal presents the three elements as an equal blend, but in reality one element dominates, and moreover that dominant factor (EUR payments, European events, local-language reach) reflects not ecosystem optimality but the agency's operational convenience.

It is currently withdrawn, but why was supply chain listed originally? On what kind of supporting data? If one analyzes Cardano chain Tx even a little, wouldn't it fail to come up as an option? This vertical was merely inherited from the Strategy Framework, and there is no trace of verification against the on-chain reality.

The proposal invests 20.87M ADA into the top of the funnel (awareness, lead generation), but Cardano's actual bottleneck is the conversion supply from pilot → production deployment. Moreover, in Comment 16 the proposer themselves explicitly disclaims responsibility for that conversion, stating that "deal motion is the job of the receiving side" and that they "do not claim to drive production integration." In other words, the process that generates the most value is outside the scope of the proposal.

Regarding Tx/MAU/protocol revenue, the proposer explicitly states that attribution is impossible, saying they "cannot claim sole attribution" and referring to "downstream effect." From the perspective of my voting criteria, that is a downside.

De'Longhi/Bosch/BMW are marketing track records of global consumer-goods brands that have existing products and sales channels. Cardano has neither an established enterprise product nor sales channels. The claim that "the methodology for selling a BMW is directly transferable to enterprise blockchain adoption" has not been demonstrated.

The "Cardano supply-chain traceability" that WP4 advertises has almost no real substance to back it on-chain (production operation, Tx). The fact that the proposer repeatedly calls the supply chain "replaceable" is evidence that they themselves cannot determine what to showcase, and the largest tranche (about 46%) is allocated to the self-contradiction of "an evidence-driven campaign for a vertical that has no evidence." At the very least, this is something that should have been settled before the proposal was submitted. Looking at the current transaction statistics, I myself cannot advise what could be promoted other than DeFi, so I cannot even imagine what this might turn into.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

UK/独/瑞は「audience規模・普及率・運用容易性の最適な blend」と説明される(p.30)。ただし自社 Appendix p.22-23 のデータに照らすと、この3国を選べるのは 、それよりもaudience規模・普及率が高い地域が除外されているため、operational feasibility が事実上の決定要因である場合に限られる。提案は3要素を均等な blend として提示するが実際は一要素が支配しており、しかもその支配要因(EUR決済・欧州イベント・現地語到達)は ecosystem 最適性ではなく代理店の運用都合だ。

現在撤回されているがなぜ当初サプライチェーンと記載したのか?どのような裏付けのデータか?cardanoチェーンのTxを少し分析すればそれは選択肢に上がらないのではないか?この垂直はStrategy Frameworkから継承されただけで、オンチェーン実態と突き合わせた検証の形跡が無い。

20.87M ADAをトップオブファネル(認知・リード生成)に投じるが、Cardanoの実ボトルネックは pilot→本番デプロイの転換供給。しかも提案者自身がComment 16で「deal motion は受け取った側の仕事」「本番統合を駆動するとは主張しない」と転換責任を明示的に放棄。つまり最も価値を生む工程は提案の対象外。

Tx/MAU/protocol revenue については提案者が「sole attribution は主張できない」「downstream effect」と帰属不能を明言。それは私の投票基準からみると、ダウンサイドの影響です。

De’Longhi/Bosch/BMW は既存製品と販売チャネルを持つグローバル消費財ブランドのマーケ実績。Cardano は確立した企業向けプロダクトも販売チャネルも持たない。「BMWを売る方法論が企業ブロックチェーン採用に直接転用可能」という主張は論証されていない。

WP4が宣伝する「Cardanoの供給網トレーサビリティ」は、オンチェーンに裏付ける実体(本番稼働・Tx)がほぼ存在しない。提案者が供給網を「差替え可能」と繰り返すのは、何をshowcaseするか自ら確定できていないことの証左であり、最大トランシェ(約46%)が「証拠の無い垂直の証拠主導キャンペーン」という自己矛盾に充てられている。少なくとも、これは提案書提出前に確定しておくべきものです。現在のトランザクションの統計をみると、defi以外に何を宣伝すればいいのか、私もアドバイスできませんので、これが何になる可能性があるのか想像もつきません。

### Prior detailed analysis (EN)

**Vote: NO** on The Marketing Powered Demand Engine for Cardano (**20.87M ADA / NCL 5.96%**).

**Main reasons**

**1. NCL 5.96% is in the scrutiny band for a single-purpose marketing campaign**
- 20.87M ADA = 5.96% of NCL (scrutiny band per voting policy: 5-15%).
- For comparison: Intersect MBO at 7.26% NCL covers the entire meta-governance for the ecosystem (network upgrades, Haskell stewardship, incident response).
- 5.96% NCL for a marketing campaign is the largest single-purpose marketing spend in the cycle.
- A single $5.2M USD (at ADA $0.25) marketing campaign is unusually large for Treasury allocation.

**2. Headline KPIs are paid impressions, not Cardano transactions**

| KPI | Target |
|---|---|
| Paid impressions | 45M+ |
| Native views (guaranteed) | 320,000 |
| Clicks to Cardano Hub | 300,000+ |
| Pilot markets | UK + Germany + Switzerland (3) |
| Verticals | Institutional DeFi + Supply Chain Traceability |

All metrics are top-of-funnel (impression / click / view) with no commitments on:
- Number of enterprise pilots converted to Cardano deployment.
- Transactions generated on Cardano from converted enterprises.
- TVL contribution from institutional DeFi conversions.

"Three-stage funnel (Attention → Proof → Qualified Leads)" specifies the top of the funnel, not the bottom (production deployment + transaction generation). Cost per click: $5.2M / 300,000 clicks = **$17.30 per click to Cardano Hub** — expensive even by enterprise B2B marketing standards (typical $3-15 per click).

**3. The real Cardano BD bottleneck is enterprise-pilot supply, not lead volume**
- Cardano's existing BD pipeline (Cardano Foundation + STORM + Catalyst Pilots) already generates named pilot leads.
- The bottleneck is conversion from named pilots to production deployment, not lead-volume capacity.
- Pumping 300K additional clicks into the pipeline does not address the production-conversion bottleneck.
- Diagnosis mismatch: marketing spend addresses awareness (top of funnel) when the actual bottleneck is deliverable supply (bottom of funnel).

**4. Overlap with parallel Cardano BD proposals**

| Function | Overlapping Budget #69 proposal | Cost |
|---|---|---|
| Enterprise pilot pipeline | Cardano BD Network (regional hubs) | 1.52M ADA |
| Enterprise activation | Cardano Enterprise Activation Sandbox | 929K ADA |
| Activation programme | Cardano Activation Program (CAP) | 6.2M ADA |
| DeFi activation | Cardano DeFi Activation & Deployment | similar template |
| Marketing-driven enterprise demand | **Marketing Powered Demand Engine (this)** | **20.87M ADA** |
| Enterprise vertical (institutional DeFi) | Wormhole institutional RWA infrastructure | 20.6M ADA |

Multiple parallel proposals competing for similar Cardano-enterprise-demand-generation function. Marketing Demand Engine is 4-13x larger than other BD-network proposals.

**5. KPI verification problem at a single-disbursement scale**
- 12-month pilot with no per-milestone disbursement schedule specified.
- Marketing campaign return on investment is notoriously hard to attribute (lead-source-mix problem, multi-touch attribution complexity).
- Without per-quarter milestone gates tied to converted-pilot count (not click count), a DRep cannot halt disbursement if KPI underperforms.

**6. Vision 2030 framing is asserted, not anchored**
- The proposal frames Cardano as "The Blockchain for Serious Business" — a positioning statement.
- Marketing copy quality is not a Cardano-outcome metric.
- Any well-funded blockchain marketing campaign produces similar positioning copy. Attribution to Cardano-transaction growth requires deliverable supply that the marketing campaign itself does not create.

**Recommend NO** because: (a) scrutiny-band NCL 5.96% for single-purpose marketing is structurally unusual, (b) KPIs are top-of-funnel without transaction-outcome commitments, (c) the actual bottleneck (enterprise-pilot conversion supply) is misdiagnosed as awareness, (d) overlap with 5+ parallel BD-activation proposals creates category saturation. At this stage of the funding cycle, Treasury capital allocation should favour deliverable-supply investment over awareness investment.

### Prior detailed analysis (JA)

**Vote: NO** — The Marketing Powered Demand Engine for Cardano(**20.87M ADA / NCL 5.96%**)に NO。

**主な理由**

**1. NCL 5.96% は精査帯。単一目的のマーケティング施策としては異例の規模**
- 20.87M ADA = NCL の 5.96%(投票方針:5-15% は精査帯)。
- 比較:Intersect MBO は NCL 7.26% でエコシステム全体のメタガバナンス(ネットワークアップグレード、Haskell 管理、インシデント対応)をカバー。
- マーケティング単一目的に NCL 5.96% は、サイクル中もっとも大きい単目的マーケティング支出。
- 単一の $5.2M USD(ADA $0.25 換算)マーケティング施策は、トレジャリー配分として桁外れに大きい。

**2. 中心 KPI は有料インプレッションで、Cardano の取引ではない**

| KPI | 目標 |
|---|---|
| 有料インプレッション | 45M+ |
| ネイティブビュー(保証) | 320,000 |
| Cardano Hub へのクリック | 300,000+ |
| 試行市場 | 英国 + ドイツ + スイス(3市場) |
| 業種 | 機関 DeFi + サプライチェーン追跡 |

すべての指標がファネル上部(インプレッション / クリック / ビュー)。以下のコミットがない:
- Cardano デプロイに転換されたエンタープライズパイロット数。
- 転換企業から Cardano 上に生まれた取引数。
- 機関 DeFi 転換からの TVL 寄与。

「3段階ファネル(Attention → Proof → Qualified Leads)」はファネル上部を特定するが、下部(本番デプロイ + 取引生成)は特定していない。クリック単価:$5.2M / 300,000 クリック = **Cardano Hub へのクリック当たり $17.30** — エンタープライズ B2B マーケの基準でも高い(一般に $3-15/クリック)。

**3. 本当のボトルネックはリード量ではなく、エンタープライズパイロットの供給**
- Cardano の既存 BD(Cardano Foundation + STORM + Catalyst Pilots)は既に名前付きパイロットリードを生成している。
- ボトルネックは「名前付きパイロット → 本番デプロイ」の転換であり、リード量の容量ではない。
- パイプラインに 30 万クリックを追加しても、本番転換のボトルネックには届かない。
- 診断の不整合:本当のボトルネックは納品側の供給(ファネル下部)。マーケティング支出は認知(ファネル上部)にしか効かない。

**4. 並行する Cardano BD 提案との重複**

| 機能 | 重複する Budget #69 提案 | 費用 |
|---|---|---|
| エンタープライズパイロットパイプライン | Cardano BD Network(地域ハブ) | 1.52M ADA |
| エンタープライズ活性化 | Cardano Enterprise Activation Sandbox | 929K ADA |
| 活性化プログラム | Cardano Activation Program (CAP) | 6.2M ADA |
| DeFi 活性化 | Cardano DeFi Activation & Deployment | 同テンプレ |
| マーケ駆動のエンタープライズ需要 | **Marketing Powered Demand Engine(本提案)** | **20.87M ADA** |
| エンタープライズ垂直(機関 DeFi) | Wormhole 機関 RWA 基盤 | 20.6M ADA |

似た「Cardano エンタープライズ需要創出」機能を巡る並行提案が複数。本提案は他の BD ネットワーク系提案より 4-13 倍大きい。

**5. 単一支給規模での KPI 検証の問題**
- 12 か月の試行でマイルストーン段階払いが未指定。
- マーケティング施策の ROI 帰属は元々難しい(リード源の混在、マルチタッチ帰属の複雑さ)。
- クリック数ではなく転換パイロット数に紐付く四半期マイルストーンゲートがないと、KPI 未達のときに DRep が出金を止められない。

**6. Vision 2030 の枠組みは主張のみで、根拠がない**
- 提案書は Cardano を「The Blockchain for Serious Business」と位置付ける — 表明声明。
- マーケコピーの良し悪しは Cardano の成果指標ではない。
- 資金のあるブロックチェーンのマーケ施策はどこも似た声明を出せる。Cardano 取引成長への帰属には、マーケ施策自体が作らない「納品側の供給」が必要。

**NO 推奨**:(a) 単一目的マーケに精査帯の NCL 5.96% は構造的に異例、(b) KPI がファネル上部のみで取引成果のコミットがない、(c) 真のボトルネック(エンタープライズパイロットの転換供給)を認知と誤診断、(d) 5+ の並行 BD 活性化提案との重複でカテゴリ飽和。本サイクル段階では、トレジャリー資金配分は認知投資より納品供給投資を優先すべき。

### Proposer feedback (2)

#### Feedback 1 — source: twitter, author: SPforCardano
- Author note: CONFIRMED: bio "Cardano Budget Proposal by Serviceplan Group"
- URL: https://twitter.com/SPforCardano/status/2059710682262556976
- Summary (EN): Serviceplan (proposer) responds to the three concerns with structural concessions: (1) the Supply Chain vertical (W4) is gated and revisable with the GMC within the Strategy 2030 verticals; (2) lead handover to be defined collaboratively with the community before funds flow; (3) open to reducing the ADA/USD buffer to ~20% anchored to a milestone. Posted full reply + DM.
- Summary (JA): Serviceplan (提案者) が 3 懸念に構造的譲歩で回答: (1) W4 サプライチェーンは gated で GMC と改訂可能、 (2) リード引き渡しは資金流入前にコミュニティと協働で定義、 (3) ADA/USD バッファーをマイルストーン連動の ~20% に下げる用意。 全文返信 + DM。

Full text:

@yutazzz appreciate the structured feedback. @Padierfind already addressed several of these points well, so let me focus on the structural concessions we're prepared to commit to. Two things worth saying upfront though: the verticals in our proposal aren't picks we made on our own. Throughout the conception phase we ran the proposal past a wide range of Cardano stakeholders to make sure it reflected real needs.

[May 28: Supply Chain is gated, revisable with the GMC within the four Strategy 2030 verticals. Lead handover: defined collaboratively with the community before funds flow, the receiving stack isn't ours to name unilaterally. Buffer: open to 20% anchored to a milestone.]

#### Feedback 2 — source: twitter, author: SPforCardano
- Author note: CONFIRMED: Serviceplan Group (proposer); signed -Yves
- URL: https://twitter.com/SPforCardano/status/2061458319852671472
- Summary (EN): Serviceplan (Yves, proposer) clarifies the ask is split: a Yes is €1.62M unconditional plus €1.36M contingent — WP4 only releases if the WP3 DeFi KPI checkpoint is hit and stays revisable with the GMC before deployment. Also notes the ADA/USD buffer was moved from 30% to 20% anchored to recent spot, with a slippage cap open for discussion.
- Summary (JA): Serviceplan (提案者 Yves) が、要求額は分割だと明確化: Yes は €1.62M が無条件 + €1.36M が条件付き — WP4 は WP3 の DeFi KPI チェックポイント達成時のみ解放され、展開前に GMC と改訂可能。ADA/USD バッファーも 30%→20% (直近スポット連動) に下げ、スリッページ上限は協議の余地ありとする。

Full text:

@yutazzz @yutazzz one clarification worth surfacing, since it seems to be behind a lot of the No votes: WP4 was never an unconditional ask.
It only releases if the WP3 DeFi KPI checkpoint is hit, and stays revisable with the GMC before deployment. So a Yes is €1.62M unconditional, plus €1.36M contingent on both performance and continued community alignment. That's not coming across clearly.
You said your vote's open to change with feedback, so worth a fresh look. On the buffer we've also moved from 30% to 20%, anchored to recent spot, with a slippage cap open for discussion.
Full breakdown is in this thread https://t.co/VEGBgvo4xy
Let us know you thoughts. -Yves

---

## 4. Wormhole Cross-Chain Infrastructure for Cardano: Institutional RWAs, Native Multichain Stablecoins

- Proposal ID: 69fce80ae1ab5d003a0cab6c
- Requested: 20,600,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fce80ae1ab5d003a0cab6c
- Category: dApp - cross-chain
- Applicable criteria: C1, C4, C5, C8, C10
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Given overlap with the already-funded LayerZero integration and the current state of NCL headroom, this is hard to approve realistically.

### Voting reason (JA, as of 2026-05-28)

LayerZero との統合の重複、 そして現在の NCL 残額の状況から見て、 現実的にこれを承認することが難しい。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO** on Wormhole Cross-Chain Infrastructure for Cardano (**20.6M ADA / NCL 5.89%**).

**Main reasons**

**1. NCL 5.89% — scrutiny band, with a single $5M upfront disbursement**
- Per voting policy: under 5% proceed / 5-15% scrutiny / over 15% major concern.
- 20.6M ADA = 5.89% of 350M NCL = scrutiny band.
- Per proposal: a single $5M USD Treasury withdrawal on vote approval, with milestone reporting after disbursement.
- This is the cycle's largest single dApp-infrastructure ask for a multi-chain bridge whose primary user base is on other chains.

**2. Direct overlap with Pentad Critical Integrations TW #77, which already includes LayerZero**
- Per Pentad (TW #77, 70M ADA Critical Integrations Budget, ratified epoch 605): LayerZero is one of four named Critical Integrations alongside Circle USDCx, Dune analytics, and Pyth Oracle.
- LayerZero status: announced, funded, deployment in progress, not yet live as of 2026-05-10.
- Wormhole and LayerZero are direct competitors at the cross-chain messaging and token-transfer layer.
- Approving Wormhole at 20.6M ADA while LayerZero deployment is in flight under TW #77 creates duplicate cross-chain infrastructure funding.

**3. Most claimed institutional partners are not yet on Cardano**

| Claimed partner | Status |
|---|---|
| Securitize ($4B+ in tokenized assets: BlackRock BUIDL, Apollo, Hamilton Lane, VanEck) | live on Ethereum + selected chains; Cardano deployment not committed |
| DigiFT ($205M: UBS uMINT, Invesco, China Merchants Bank) | live elsewhere; Cardano not in current production set |
| M0 ($779M wholesale stablecoin, MetaMask mUSD, Noble USDN) | Ethereum + Noble chain; Cardano in pipeline |
| Sky/USDS, RLUSD, Transfero BRZ, Folks Finance, Centrifuge, tBTC, sBTC | all "pipeline partners" per proposal — not committed Cardano deployments |

- Wormhole's $70B+ cumulative volume is real, but predominantly between Solana, Ethereum, and other non-Cardano chains.
- Cardano-specific volume projection in the proposal: 50,000+ messages in Year 1. At a Cardano L1 fee of ~0.17 ADA per transaction, that is ~8,500 ADA per year in fee revenue.
- The proposal's "36-48 month break-even" claim against a 20.6M ADA grant does not match those numbers (at 8,500 ADA per year, break-even would be ~2,400 years).

**4. Transaction-contribution math**
- Cardano monthly transaction baseline: ~700-800K (per ADAtool db-sync 2024-2026).
- 50,000 Year-1 Wormhole messages ≈ 4,200 per month = 0.5-0.6% of Cardano monthly transactions.
- For reference: BlackRock BUIDL generates ~50 transactions per month at $147M AUM. High-AUM tokenized funds generate low transaction volume, so Wormhole's institutional-RWA pipeline, if it materialises, would be similarly low-frequency.

**5. Concentration risk**
- The 2024 Wormhole hack cost $325M — the largest single bridge exploit by USD value.
- Funding Wormhole at 5.89% NCL concentrates Cardano's bridge layer on a single externally controlled protocol.
- A multi-bridge framework like Pentad (with LayerZero and others) is the safer architecture for Cardano L1.

**Recommend NO**: scrutiny-band scope + overlap with LayerZero pending under TW #77 + a Year-1 transaction projection that does not justify the ask. Pentad already covers LayerZero; redirect Cardano cross-chain capacity through that existing governance route.

### Prior detailed analysis (JA)

**Vote: NO** — Wormhole Cross-Chain Infrastructure for Cardano(**20.6M ADA / NCL 5.89%**)に NO。

**主な理由**

**1. NCL 5.89% — 精査帯、しかも承認時に $5M を一括払い**
- 投票方針:5%未満は通常進行、5-15% は精査、15%超は重大懸念。
- 20.6M ADA = NCL 350M の 5.89% = 精査帯。
- 提案書より:投票承認時に $5M USD を一括出金。マイルストーン報告は出金後。
- 本サイクル最大の単一 dApp 基盤要求。主要利用者層が Cardano 外にあるマルチチェーンブリッジに対するもの。

**2. Pentad Critical Integrations TW #77(LayerZero を含む)との直接重複**
- Pentad(TW #77、70M ADA、epoch 605 で批准):LayerZero は4つの主要統合の1つ(他は Circle USDCx、Dune 分析、Pyth Oracle)。
- LayerZero の状況:発表済み、資金確保、デプロイ進行中、2026-05-10 時点で稼働開始前。
- Wormhole と LayerZero はクロスチェーンのメッセージングとトークン転送層で直接競合する。
- TW #77 で LayerZero のデプロイが進む中、Wormhole に 20.6M ADA を承認すると、クロスチェーン基盤の二重投資になる。

**3. 主張されている機関パートナーの多くは、まだ Cardano 上にいない**

| 主張されたパートナー | 状況 |
|---|---|
| Securitize($4B+:BlackRock BUIDL、Apollo、Hamilton Lane、VanEck) | Ethereum と一部チェーンで稼働。Cardano への展開は確約されていない |
| DigiFT($205M:UBS uMINT、Invesco、招商銀行) | 他で稼働。Cardano は現状の本番セットに入っていない |
| M0($779M、MetaMask mUSD、Noble USDN) | Ethereum + Noble。Cardano は予定 |
| Sky/USDS、RLUSD、Transfero BRZ、Folks Finance、Centrifuge、tBTC、sBTC | 提案書上いずれも「予定パートナー」。Cardano 展開の確約ではない |

- Wormhole の累積 $70B+ は事実だが、その大半は Solana、Ethereum、Cardano 以外のチェーン間。
- 提案書の Cardano 固有の見込み:Y1 で 50,000+ メッセージ。Cardano L1 手数料 約 0.17 ADA/件 なら、年 約 8,500 ADA の手数料収入。
- 提案書の「36-48か月で損益分岐」は、20.6M ADA を年 8,500 ADA で回収すると 約 2,400 年かかる計算と整合しない。

**4. 取引寄与の計算**
- Cardano の月次取引ベースライン:約 700-800K 件(ADAtool db-sync 2024-2026)。
- Y1 で 50,000 件の Wormhole メッセージ = 月 約 4,200 件 = Cardano 月次取引の 0.5-0.6%。
- 参考:BlackRock BUIDL は $147M AUM で月 約 50 件。AUM の大きいトークン化ファンドは件数が少ない傾向で、Wormhole の機関 RWA パイプラインが実現しても同じく低頻度になる。

**5. 集中リスク**
- 2024 年の Wormhole ハックは $325M を喪失。USD ベースで史上最大の単一ブリッジ事故。
- NCL 5.89% を Wormhole 単独に振ると、Cardano のブリッジ層を外部統制下の単一プロトコルに集中させることになる。
- Pentad のような複数ブリッジ枠組み(LayerZero などを含む)の方が、Cardano L1 にとって安全な構造。

**NO 推奨**:精査帯の規模 + TW #77 下で進む LayerZero との重複 + 要求額を正当化しない Y1 取引見込み。LayerZero は既に Pentad で扱っているので、クロスチェーン施策は既存ガバナンス経由で進めるべき。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 5. Cardano Builder DAO

- Proposal ID: 69ebc7cdd73bae0eb2a9952d
- Requested: 20,600,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ebc7cdd73bae0eb2a9952d
- Category: Secondary grant DAO
- Applicable criteria: C2, C5, C8, C11
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

1. The rebuttal cites Tx figures but provides no verifiable data demonstrating causation between CBDAO funding and those Tx counts.

2. I do not see this as 'a process by which domain-credentialed members are elected.' Asking DReps to participate in yet another election adds to DRep fatigue and is unlikely to attract sufficient quality participation. At submission time, specific council member names should have been listed so DReps could vote on them. I'd rather focus on on-chain governance actions and avoid these auxiliary off-chain elections; and I cannot trust the outcome of an election most DReps will not realistically participate in.
The 4 seats elected by DAO membership ultimately returns to the conflict-of-interest concern. If any seats are to come from DAO members, they should be pre-selected with names and CVs in the proposal, and DReps should vote on them. I do not trust the selection process as currently described.

### Voting reason (JA, as of 2026-05-28)

1. 返答には、 返答の中の Tx の数値、 およびそれらが資金調達されて追加された機能との因果関係がある点を検証可能なデータが添付されていません。

2. 返答について、 私はこれを「専門知識のあるメンバーが選出されるプロセス」だと思いません。 DRep にさらなる選挙への関与を求めることは申し訳ありませんが、 さらに DRep を疲弊させるものであり、 これに十分な DRep の参加を得るのは本当に容易ではないでしょう。 提案書の提出時点で具体的なメンバー名を言及し、 それに対して DRep が投票できるようにすべきでした。 私はできればオンチェーンガバナンスアクションに集中したく、 こうした付随的なオフチェーン選挙への関与を避けたいと考えており、 かつ将来起こるおそらく大半の DRep が参加しないであろう選挙の結果を信頼できません。
4 席の DAO メンバーからの選出は結局のところ利益相反の議論に戻ってきます。 少なくとも DAO メンバーから何かを選出する予定であった場合は、 それを選出して、 その人々の名前と経歴をこの提案書に記載することを確認できた上で、 それに対して DRep が投票できるようにすべきです。 私はこの選出プロセスを信頼しません。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the reply. I do not trust a mechanism in which participants vote on each other, nor undefined council members. You say voting is currently underway, but I checked the linked page and could not tell who has been elected or who the council members currently are. I was also unable to obtain data demonstrating a causal relationship between past Tx increases and the funding provided.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返信をありがとうございます。私は参加者同士が投票し合う仕組みや、あるいは未定義のcouncilメンバーを信頼しません。現在投票中とのことですが、リンク先を確認しましたが誰が選出され現在誰がcouncilなのかわかりませんでした。また過去のTx増加と資金提供の因果関係を示すデータを入手できませんでした。

### Prior detailed analysis (EN)

**Categorisation**: [Secondary grant DAO]. Non-applicable criteria: C1 (sub-DAO does not directly generate Tx), C3 (sub-DAO process metrics are appropriate), C4 (sub-DAO is grant-distributing, not commercial), C6 (no L1 use case), C7 (CoI applies but subsumed under C11), C9 (not speculative thesis), C10 (NCL share covered separately).

**Applicable criteria: C2 (track record as grant judge), C5 (non-duplication), C8 (past funding outcome), C11 (secondary-DAO restrictions)**. Applying:

• **C2 — Track record as judge (note: members are builders, not DReps)**: Per the proposal text — 'requesting members of the CB DAO are not permitted to receive funding from other DAOs at the same time' — the DAO's voting members are themselves builders / requesting parties (with overlap between decision-makers and recipients). 2025 Round 1+2 operated this way: **builders voted on each other's funding proposals**. Some DReps may participate, but the core voting structure is builder self-judgment. This is NOT a fixed expert grant-judging team (Y Combinator, Techstars, Plug and Play, Draper University) — it's a member-based DAO with structural self-voting. No equivalent measurable success record in Cardano grant distribution judgment exists. Fails C2.

• **C8 — Round 1 outcome attribution (anchored to my /cbdao-tracker measurement)**: CBDAO 2025 received 12M ADA, distributing 11.1M across 34 projects in Round 1+2. Per Intersect TW data, CBDAO 12M ADA is 4/4 milestones fully delivered. Per ADAtool db-sync 1-month measurement (monthly tx baseline ~772K, top-38 cutoff = 2,517 tx/month), only 3 of CBDAO Round 1's 14 funded projects rank in the top 38: DexHunter (~4.1M tx all-time), CSwap (~408K all-time), Masumi (~22K all-time). **DexHunter and CSwap held top-tier positions before CBDAO funding** (DexHunter is established 2024 aggregator; CSwap is established mid-tier DEX). **Masumi is a possible counter-example** — small base pre-funding, measurable Tx growth during funding period. However, controlled experiment-style causality cannot be confirmed. The remaining 11 funded projects (Vespr, Anvil, Strike, Flux Point Studios, Metera, Snek, Handle, Xerberus, TapDano, Gero, Wanchain in R1; UTXOS, Walkers, Cexplorer, BankFi in R2) have no clear Tx attribution from CBDAO funding. **Net assessment: CBDAO funding cannot be empirically shown to have created new Tx generators; subsidies appear to have flowed primarily to either (a) projects already generating Tx independently before CBDAO funding, or (b) projects not generating measurable Tx at all — with Masumi as a possible exception. The 'creating new Tx' middle ground is largely absent.**

• **C11 — Scale-up justification + CoI**: 2026 ask 20.6M ADA = +72% scale-up over 2025's 12M. Round 1 outcome (above) does not empirically support the +72% increase. **Self-voting realised in practice**: 2025 Round 1+2 operated with builder-members voting on each other's funding proposals (per proposal text on member structure + reported operation). This is the textbook structural CoI — decision-makers and recipients overlap by design, no exclusion threshold, no independent review. Fails C11.

• **C5 — Two-step funding removes DRep oversight (DRep-capacity constraint, not tooling)**: Direct TW is straightforwardly auditable within a typical DRep attention budget (one recipient, one set of deliverables). **A secondary-grant DAO splits visibility into two layers**, both practically unobservable to individual DReps — **NOT because tooling is missing** (CBDAO publishes dashboards, Catalyst has long-running ones, ADAtool maintains /cbdao-tracker externally), **but because DReps are an unspecified mass of mostly-unpaid volunteers with day jobs whose governance attention is bounded by personal time/resources**. Core attention naturally goes to on-chain GAs (constitutional minimum); continuously tracking CBDAO's internal per-cycle allocation decisions across dozens of downstream proposals — voting cycles, milestone reviews, dispute resolutions — is outside what most DReps can fit in regardless of how usable the dashboard is. (1) Empirically: **none of the DReps I have spoken with can monitor Catalyst or CBDAO fund-allocation outcomes at the individual-recipient level**. The /cbdao-tracker measurement above (R1 attribution analysis) required dedicated external tooling effort + analysis time most individual DReps don't have. (2) Same capacity constraint applies to verifying CBDAO's internal governance (member capture / allocation bias / self-dealing) — additionally hampered by internal voting records / CoI disclosures / per-decision rationale not normally produced at audit-grade granularity. Self-voting (C11) compounds this. Direct TW is structurally preferable; the Constitutional amendment lowering direct-TW barriers (17 active TWs requesting 74.1% of 350M NCL, claims pending vote) makes this argument stronger. Fails C5.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [二次配布 DAO]。 非適用: C1 (sub-DAO は直接 Tx 生成せず), C3 (sub-DAO の process metric は適切), C4 (sub-DAO は grant 配分で commercial ではない), C6 (L1 use case なし), C7 (CoI は C11 に subsumed), C9 (speculative thesis ではない), C10 (NCL share は別途検討)。

**適用基準: C2 (判定者としての track record), C5 (機能重複), C8 (過去資金 outcome), C11 (二次 DAO 制限)**。 適用:

・**C2 — 判定者としての track record (注: members は builders、 DRep ではない)**: 提案書 text — 'requesting members of the CB DAO are not permitted to receive funding from other DAOs at the same time' — より、 DAO の voting members は自身が builders / requesting party (decision-maker と受給者が overlap)。 2025 Round 1+2 はこの構造で運営 — **builders が互いの funding 提案に投票** していた。 一部 DRep も参加可能だが、 core voting 構造は builder の self-judgment。 これは fixed expert grant-judging team (Y Combinator, Techstars, Plug and Play, Draper University) **ではない** — 構造的 self-voting を持つ member-based DAO。 Cardano grant 配分判断で等価の measurable success record は存在せず。 C2 不合格。

・**C8 — Round 1 outcome attribution (/cbdao-tracker measurement に anchor)**: CBDAO 2025 は 12M ADA 受領、 Round 1+2 で 34 projects に 11.1M 配布。 Intersect TW data より CBDAO 12M ADA は 4/4 milestones 完全 delivered。 ADAtool db-sync 1ヶ月 measurement (月次 tx baseline ~772K, top-38 cutoff = 2,517 tx/月) より、 CBDAO Round 1 の 14 funded projects のうち top 38 入りは 3 件のみ: DexHunter (~4.1M tx all-time), CSwap (~408K all-time), Masumi (~22K all-time)。 **DexHunter と CSwap は CBDAO 資金以前から top-tier position 保持** (DexHunter は 2024 established aggregator; CSwap は established mid-tier DEX)。 **Masumi は反例の可能性** — pre-funding base 小、 funding 期間中 measurable Tx 成長。 但し controlled experiment 式の causality は確認不能。 残り 11 funded projects (Vespr, Anvil, Strike, Flux Point Studios, Metera, Snek, Handle, Xerberus, TapDano, Gero, Wanchain in R1; UTXOS, Walkers, Cexplorer, BankFi in R2) は CBDAO 資金からの clear Tx attribution なし。 **Net assessment: CBDAO 資金が新規 Tx generator を創出したことは empirically 証明できず; subsidy は primarily (a) CBDAO 資金前から independent に Tx 生成していた project か、 (b) measurable Tx を全く生成していない project の どちらかに流れた印象 — Masumi が例外候補。 '新規 Tx を創出' という中間地帯はほぼ不在**。

・**C11 — scale-up justification + CoI**: 2026 ask 20.6M ADA = 2025 の 12M に対し +72% scale-up。 Round 1 outcome (上記) は +72% increase を empirically support せず。 Self-voting risk: rotating member DAO 内で互いの project 提案に投票可能。 C11 不合格。

・**C5 — 2 段階 funding が DRep 監督を奪う (DRep-capacity 制約、 tooling 不在ではない)**: 直接 TW なら典型的 DRep attention budget 内で straightforwardly 監督可能 (受給者 1、 deliverable 1)。 **二次 grant DAO は可視性を 2 層に分け**、 両層とも individual DRep には実務上 observe 不可能 — **tooling が無いからではなく** (CBDAO は dashboard を publish、 Catalyst にも長年あり、 ADAtool が /cbdao-tracker を外部で維持)、 **DRep が不特定多数の、 ほぼ無償で本業のあるボランティアで、 governance attention が本人の時間/リソースに bound されているから**。 中核 attention は on-chain GA review (憲法上の最低限) に向く; CBDAO 内部の per-cycle 配分判断を数十の downstream 提案にわたって継続追跡 (投票 cycle、 milestone レビュー、 dispute resolution) することは、 dashboard がいかに使いやすくても大多数の DRep が時間的に収められない。 (1) Empirically: **私が会話した DRep の中で、 Catalyst や CBDAO の fund 配分 outcome を individual-recipient レベルで監督できている人は 1 人もいない**。 上記 /cbdao-tracker measurement (R1 attribution 分析) は dedicated な外部 tooling 努力 + 分析時間を要するもので、 大多数の individual DRep は持たない。 (2) 同じ capacity 制約が CBDAO 内部 governance (member capture / allocation bias / self-dealing) の検証にも適用 — 内部 voting record / CoI disclosure / per-decision rationale が通常 audit-grade 粒度で生産されないことでさらに悪化。 Self-voting (C11) はこれを compound。 Feasible なら直接 TW が structurally 望ましく、 憲法改正で直接 TW barrier が下がった今 (17 active TWs が NCL の 74.1% を請求中、 投票 pending)、 本論は **強くなる**。 C5 不合格。

よって本提案はこれらを満たさない。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ebc7cdd73bae0eb2a9952d#comment-6a05d3a1ceb7fef00be0e458
- Summary (EN): Posts a full rebuttal document (docsend) addressing C2/C5/C8/C11 concerns. Asks YUTA and the broader DRep community to reconsider the NO vote based on the structured counterpoints.
- Summary (JA): C2/C5/C8/C11への詳細反論文書 (docsend) を提示し、YUTAおよびDRepコミュニティに対しNO投票の再検討を要請。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C8, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Yuta, as the grassroots builder layer on Cardano, we appreciate your work and dedication to the ecosystem. We ask that you consider our rebuttal and reconsider your NO vote on the Cardano Builder DAO.

For the broader dRep community, Yuta makes good points and we feel we have good counterpoints that satisfy his concerns. 

Our rebuttal:  https://docsend.com/view/nm2nqwvut4gk2z2d

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ebc7cdd73bae0eb2a9952d#comment-6a1ddf1dceb7fef00be0e501
- Summary (EN): Proposer thanks YUTA and says the DAO has prepared a collective response to the rationale, linking to an external document.
- Summary (JA): 提案者はYUTAに謝意を示し、DAOとして合理的根拠への回答を共同でまとめ、外部ドキュメントへのリンクを提示している。

Full text:

Hi Yuta,

Thank you for your commitment to Cardano Governance. We have worked together as a DAO to respond to your current rationale.

Response here: https://docsend.com/view/yrf3kyv59xebqgit

---

## 6. Project Janus: A Roadmap to Decentralized Bridge Authorization and Generalized Cross-Chain Messaging

- Proposal ID: 69fdbabbe1ab5d003a0cab77
- Requested: 15,820,800 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdbabbe1ab5d003a0cab77
- Category: dApp - cross-chain
- Applicable criteria: C1, C5
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; my concerns about C1 are not alleviated. As for C5, there is a point made in another comment that "L0's DVN is fully modular and customizable. If you want to use Mithril for outbound, you just deploy an L0 DVN that does so." A response to this is needed.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、C1についての懸念は軽減されていません。C5について、「L0 の DVN は完全にモジュラーでカスタマイズ可能。Mithril を outbound に使いたいなら、それを行う L0 DVN をデプロイすればよい」という指摘が別のコメントであります。これについての返答が必要です。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-bridge]. Non-applicable: C2 (ChainPort has Cardano-relevant track record), C3 (bridge-specific KPI not the primary issue), C4 (Treasury return considered secondary), C7, C8 (no prior Cardano Catalyst funding to attribute), C9 (bridge demand is generally validated, just not for parallel infrastructure), C10, C11.

**Applicable: C1, C5**. Applying:

• **C5 — Functional duplication with LayerZero (TW #77 Pentad Critical Integrations, vendor-confidential ₳70M pool)**: Per Pentad public announcements (@Cardanians_io 197♥ snapshot 2026-05-07), LayerZero is one of four named Pentad Critical Integrations alongside Circle USDCx ✅, Dune analytics ✅, Pyth Oracle ✅ — **LayerZero status: ⏳ pending (announced + funding committed, deployment ongoing, NOT yet live on Cardano mainnet as of 2026-05-10)**. Funding flows through TW #77 (Withdraw ₳70M for Cardano Critical Integrations Budget, ratified epoch 605, Pentad-led, vendor identities confidential pending integration completion). **Tier A-ish (funded + announced + deployment-in-progress)** but NOT yet live.

  LayerZero global footprint (off-Cardano): 160+ chains, $200B cumulative cross-chain volume, $90B liquidity (LayerZero public docs).

  Project Janus's three pillars overlap with what LayerZero will provide once deployed:
  - **Janus DVN** (Decentralized Verifier Network) ↔ LayerZero DVN
  - **Janus CCT / OFT-equivalent** (Cross-Chain Token / Omnichain Fungible Token) ↔ LayerZero OFT standard
  - **Janus GMP** (Generalized Messaging Protocol) ↔ LayerZero GMP

  This asks DReps to pay twice for the same set of problems — Pentad has already committed funding for LayerZero deployment via TW #77; approving Project Janus's ₳30.6M creates parallel funding for the same use cases.

• **C1 — Tx contribution structurally negligible**: ChainPort (the primary identified deliverer in the Janus proposal) has cumulative track record of **97,000 total ports across 47+ chains over 2+ years of operation** (per ChainPort public stats as of July 2025). The Cardano share is a fraction of that 97K total, translating to **a few hundred tx/month at most** for the Cardano leg. Bridges by their nature generate lower-frequency transactions than DEX or lending infrastructure. Even if Project Janus achieves 10× the typical ChainPort Cardano share, the contribution is on the order of **0.25-1% of Cardano's current monthly 800K tx** baseline. With LayerZero deployment funded (TW #77) and likely to mature during the funding cycle, ChainPort's market-share assumptions themselves require re-evaluation downward.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-bridge]。 非適用: C2 (ChainPort は Cardano-relevant track record あり), C3 (bridge-specific KPI は primary issue ではない), C4 (Treasury return は secondary), C7, C8 (attribution する prior Cardano Catalyst funding なし), C9 (bridge demand は一般的に validated、 但し parallel infra に対しては別問題), C10, C11。

**適用: C1, C5**。 適用:

・**C5 — LayerZero との機能重複 (TW #77 Pentad Critical Integrations, vendor 機密 ₳70M pool)**: Pentad 公開アナウンス (@Cardanians_io 197♥ 2026-05-07 snapshot) より、 LayerZero は Pentad Critical Integrations 4 つの named 統合の 1 つ (Circle USDCx ✅, Dune analytics ✅, Pyth Oracle ✅ と並ぶ) — **LayerZero status: ⏳ pending (announced + funding committed, deployment 継続中、 2026-05-10 時点 Cardano mainnet に **まだ live でない**)**。 資金は TW #77 (Withdraw ₳70M for Cardano Critical Integrations Budget, epoch 605 ratified, Pentad 主導, integration 完了まで vendor identity 機密) 経由。 **Tier A-ish (funded + announced + deployment-in-progress)** だが まだ live ではない。

  LayerZero global footprint (off-Cardano): 160+ chains, $200B 累積 cross-chain volume, $90B liquidity (LayerZero 公開 docs)。

  Project Janus の 3 pillar は LayerZero が deploy されれば提供する機能と重複:
  - **Janus DVN** (Decentralized Verifier Network) ↔ LayerZero DVN
  - **Janus CCT / OFT-equivalent** (Cross-Chain Token / Omnichain Fungible Token) ↔ LayerZero OFT 標準
  - **Janus GMP** (Generalized Messaging Protocol) ↔ LayerZero GMP

  これは DRep に同じ問題群を 2 度支払うことを要求する — Pentad は既に TW #77 経由で LayerZero 展開資金を commit; Project Janus の ₳30.6M 承認は同じ use case に対する parallel funding を生む。

・**C1 — Tx 寄与は構造的に negligible**: ChainPort (Janus 提案書で identified された primary deliverer) は **47+ chains 横断で 2+ 年 operation で累積 97,000 total ports** (ChainPort 公開 stats 2025 年 7 月時点)。 Cardano share は 97K total の一部分で、 Cardano leg として **最大数百 tx/月** に translate。 Bridge は本質的に DEX や lending infra より低頻度 tx を生成。 Project Janus が ChainPort 典型 Cardano share の 10× を achieve しても、 寄与は **Cardano 現在の月次 800K tx baseline の 0.25-1%** order。 LayerZero deployment が TW #77 経由で資金確保され funding cycle 中に mature する見込みのため、 ChainPort の market-share assumption 自体が下方修正要。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdbabbe1ab5d003a0cab77#comment-6a1020cb05e47100cbda5c18
- Summary (EN): Substantial revisions since the comment: budget down to 15.82M ADA (from 30.57M), WP4 (growth incentives/LBE/grants) removed, audits commissioned by CF/Intersect/CC rather than from the proposal, admin-key transfer is a binding milestone gated by 4 criteria (clean audits, decentralized monitor live, 90d incident-free, signers disclosed). Argues Janus is additive: Mithril for Ouroboros-anchored verification, SPOs as DVN signers, CCT standard published as Plutus CIP for any bridge to adopt.
- Summary (JA): コメント後に大幅改訂: 予算を30.57M ADAから15.82M ADAに削減、WP4 (成長インセンティブ/LBE/助成) を全削除、監査はCardano Foundation/Intersect/CCが委託 (提案外)、admin-key移管は4条件 (クリーン監査、分散モニター稼働、90日無事故、署名者公開) に縛られた拘束的マイルストーンに。Janusは並行ブリッジではなく付加層: MithrilでOuroboros基準の検証、SPO自身がDVN署名者、CCT標準はPlutus CIPとして公開済みで任意ブリッジが採用可能。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C1, C5).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi yuta.zzz, thanks for commenting. 

The proposal has changed quite a bit since this comment, so worth flagging the shifts.

On duplication: Janus isn't a parallel bridge. The deliverables sit underneath what other providers already offer. Mithril anchors verification to Ouroboros, which external validator networks can't do. The DVN signers are Cardano SPOs rather than third-party operators. The CCT standard is published as an open Plutus CIP, so any bridge already live or pending can adopt it. The work is additive.

What's changed since May 11:

- Budget down to 15,820,800 ADA (from 30.57M)
- WP4 removed entirely (growth incentives, LBE, ecosystem grants)
- Audits commissioned by the Cardano Foundation, Intersect, and the Constitutional Committee, not paid for from the proposal
- Admin key transfer is a binding milestone gated by four criteria: audits clean, decentralized monitor live, 90 days incident-free, signer set disclosed

Open to going deeper if useful. Thank you very much!

---

## 7. Innovation & Growth DAO

- Proposal ID: 69fc50fd89371182537b309e
- Requested: 14,304,640 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e
- Category: Secondary grant DAO
- Applicable criteria: C2, C5, C8, C11
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the reply. I cannot trust the decisions of an arbitrary, small subset of the kind of DReps who can devote a comparatively large amount of time to governance.
This would be a very small set of DReps. Conversely, if a high participation threshold were set, such as participation of more than 67% of the stake, it would become difficult to fulfill the original intent of this proposal. I hope you will submit a fixed subset of decision-making members along with their backgrounds.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返信をありがとうございます。私は任意の比較的ガバナンスに時間を費やせる種類の少数のDRepのサブセットの決断を信頼できません。
これは非常に少ないDRepのセットになるでしょう。逆に、ステークの67%以上の参加など高い参加閾値を設けると、この提案書の元の趣旨を満たしづらくなるでしょう。固定された意思決定メンバーのサブセットを経歴と共に提出することを願います。

### Prior detailed analysis (EN)

**Categorisation**: [Secondary grant DAO]. Non-applicable: C1, C3, C4, C6, C7 (subsumed under C11), C9, C10.

**Applicable: C2, C5, C8, C11**. Applying:

• **C2 — Track record as judge**: Per the proposal summary, this is a **DRep-governed** funding mechanism — DReps act as judges with CoI rules, rationale requirements, and capped compensation. This is **different** from the Builder DAO / Tooling DAO Initiative-DAO-framework pattern (which uses builder-members voting on each other's proposals). Structurally, DRep-as-judge is less captured than builder-self-voting. However, no fixed expert team with verifiable Cardano grant-judgment track record exists; rotating DReps don't have measurable success record in startup-stage allocation judgment. The proposers have not published a comparable allocation track record.

• **C8 — Past funded projects attribution**: As proposal itself states, direct alignment is limited to governance metrics; Tx/TVL falls under 'indirect alignment' dependent on funded projects. The grant pool is forwarded to other proposers; outcome attribution chain is two-step indirect.

• **C11 — Operating cost ratio**: Per the proposal's own breakdown:
  - Setup: 1.188M ADA
  - Council compensation: 500K ADA
  - DAO Service provider: 600K ADA
  - DRep Rewards: 600K ADA
  - Final reward: 100K ADA
  - Intersect admin: 417K ADA
  - **Total operating cost: ~3.4M ADA = 24% of total budget**

  Typical grant programs (Y Combinator, Techstars, AWS Activate, Catalyst Fund operations) operate at **5-10% overhead**. 24% is 2.4-4.8× the benchmark range. Per /tx-roi data on past similar structures (Wada 27 Catalyst proposals = 1.81M ADA / 0 verifiable outcome), high-overhead community-DAO patterns historically have not produced measurable Cardano outcomes.

• **C5 — Two-step funding removes DRep oversight (decisive structural concern)**: A direct Treasury Withdrawal is straightforwardly auditable — one recipient, one set of deliverables, one accountability path. **A secondary-grant DAO splits that visibility into two layers, and both layers are practically unobservable to individual DReps — NOT because tooling is missing, but because of DRep-capacity constraints**:

  1. **Where the funds actually go (secondary grant recipients)**: Secondary DAOs typically publish dashboards (CBDAO has one, Catalyst has long-running ones, this proposal will likely include one too) — these tools EXIST. The structural problem is on the consumer side: **DReps are an unspecified mass of mostly-unpaid volunteers with day jobs**. Capacity for governance is bounded by personal time and resources, and core attention naturally goes to reviewing on-chain GAs (the constitutional minimum). Continuously tracking a secondary DAO's internal allocation decisions across dozens of downstream proposals — voting cycles, milestone reviews, dispute resolutions — is outside what most DReps can fit in, no matter how usable the dashboard. Empirically: among DReps I have spoken with, **not a single one can monitor Catalyst or CBDAO fund-allocation outcomes at the individual-recipient level**.

  2. **Whether the secondary DAO's own internal governance is operating properly** (no internal fraud, no member capture, no allocation bias toward affiliated parties): same DRep-capacity constraint applies, made worse by internal voting records / CoI disclosures / per-decision rationale not normally being produced at audit-grade granularity.

  Both oversight dimensions failing simultaneously is the structural problem with secondary-grant-DAO patterns. **Direct TW is structurally preferable when feasible** — fits within typical DRep attention budget. The Constitutional amendment lowering direct-TW barriers makes this argument stronger, not weaker. (For context: Intersect TW data shows 17 active TWs requesting 259M ADA = 74.1% of 350M NCL if all ratified — direct TW path is being actively used.)

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [二次配布 DAO]。 非適用: C1, C3, C4, C6, C7 (C11 に subsumed), C9, C10。

**適用: C2, C5, C8, C11**。 適用:

・**C2 — 判定者としての track record**: 提案書 summary より、 これは **DRep-governed** funding mechanism — DRep が CoI rules / rationale requirements / capped compensation 付きで判定者として機能。 これは Builder DAO / Tooling DAO の Initiative DAO framework pattern (builder-members が互いの提案に投票) と **異なる構造**。 構造的に DRep-as-judge は builder-self-voting より capture 耐性高い。 但し、 Cardano grant 判断で verifiable track record を持つ固定専門 team はなく、 rotating DRep は startup-stage allocation 判断で measurable 成功 record を持たない。 提案者は比較可能な配分 track record を公開していない。

・**C8 — 過去 funded projects attribution**: 提案書自身が direct alignment は governance metric に限定、 Tx/TVL は funded project 依存の 'indirect alignment' と記載。 Grant pool は他提案者に forward され、 outcome attribution chain は 2-step indirect。

・**C11 — 運営費比率**: 提案書自身の breakdown より:
  - Setup: 1.188M ADA
  - Council compensation: 500K ADA
  - DAO Service provider: 600K ADA
  - DRep Rewards: 600K ADA
  - Final reward: 100K ADA
  - Intersect admin: 417K ADA
  - **運営費合計: ~3.4M ADA = 全予算の 24%**

  典型 grant program (Y Combinator, Techstars, AWS Activate, Catalyst Fund operations) は **5-10% overhead** で運営。 24% は benchmark の 2.4-4.8×。 /tx-roi data より past 類似構造 (Wada 27 Catalyst proposals = 1.81M ADA / 検証可能 outcome 0) の high-overhead community-DAO パターンは歴史的に measurable Cardano outcome を生んでいない。

・**C5 — 2 段階 funding が DRep 監督を奪う (decisive な構造的懸念)**: 直接 Treasury Withdrawal なら監督は straightforward — 受給者 1、 deliverable 1、 説明責任 path 1。 **二次 grant DAO はこの可視性を 2 層に分け、 両層とも individual DRep には実務上 observe 不可能 — tooling が無いからではなく、 DRep-capacity の構造的制約による**:

  1. **資金が実際にどこに行ったか (二次 grant 受給者)**: 二次配布 DAO は通常 dashboard を publish (CBDAO にもあり、 Catalyst にも長年あり、 本提案にもおそらく含まれる) — tooling 自体は **存在する**。 構造的問題は consumer 側: **DRep は不特定多数の、 ほぼ無償で本業のあるボランティア**。 governance に充てられる capacity は本人の時間とリソースに bound され、 中核 attention は on-chain GA review (憲法上の最低限) に向く。 二次 DAO 内部の数十の downstream 提案にわたる配分判断 — 投票 cycle、 milestone レビュー、 dispute resolution — を継続追跡することは、 dashboard がいかに使いやすくても大多数の DRep が時間的に収められない。 Empirically: **私が会話した DRep の中で、 Catalyst や CBDAO の fund 配分 outcome を individual-recipient レベルで監督できている人は 1 人もいない**。

  2. **二次 DAO 自身の内部 governance が適切に動作しているか** (内部不正なし、 member capture なし、 affiliated parties への allocation bias なし): 同じ DRep-capacity 制約が適用され、 内部 voting record / CoI disclosure / per-decision rationale が通常 audit-grade 粒度で生産されないことでさらに悪化。

  この 2 つの監督次元が **同時に fail する** ことが、 二次 grant DAO パターンの構造的問題。 **Feasible なら直接 TW が structurally 望ましい** — 典型的 DRep attention budget 内に収まる。 憲法改正で直接 TW barrier が下がった今、 本論は弱くなるのではなく強くなる。 (Context: Intersect TW data では 17 active TWs が 259M ADA = NCL 350M の 74.1% を全 ratify 想定で請求中 — 直接 TW path は actively 使用されている。)

よって本提案はこれらを満たさない。

### Proposer feedback (7)

#### Feedback 1 — source: hydra, author: cardanoyoda
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a0227e95141bb70a939daf3
- Summary (EN): Differentiates I&G DAO from Builder/Tooling DAOs: DRep-governed (builders don't fund themselves), capped compensation, milestone disbursement, third-party assurance, COI rules, unused funds returned. Argues C5 because direct Treasury Withdrawals don't scale for 20k–300k ADA small-ticket proposals.
- Summary (JA): I&G DAOはBuilder/Tooling DAOと異なり、DRep主導 (ビルダーが自らに資金を出さない)・報酬上限・マイルストーン分割・第三者監査・COI規程・残余返却を備える。20k〜300k ADAの小規模案件にTWは効率的でないとしてC5の見方に反論。

Full text:

Thanks Yuta, appreciate the review and clear rationale.

I think the NO conclusion treats Innovation & Growth DAO as if it were the same as Builder DAO/Tooling DAO. It isn’t.

The biggest difference is governance design: builders are not voting to fund themselves. This model is DRep-governed, with public rationales, conflict-of-interest rules, capped compensation, milestone-based disbursement, reporting, third-party assurance, and unused funds returned to Treasury. That directly reduces the capture risks common in secondary grant DAOs.

On C2: DReps are not YC investors, but Cardano already trusts DReps with Treasury decisions. This DAO simply creates a more structured process for smaller proposals through proposal comparison, feedback, milestone oversight, and transparent voting.

It also ignores contributor experience. Jurgen Proschinger has 30+ years of leadership experience and direct exposure to venture development/funding environments. Rodrigo Pacini is a former Catalyst reviewer, milestone reviewer, funded proposer, and governance researcher. Other contributors have experience with private investors, VC funding, and treasury proposals.

On C5: direct Treasury Withdrawals are not efficient for every proposal. A 20k–300k ADA research, tooling, education, governance, or community proposal should not face the same process as multi-million ADA requests. This DAO fills that missing small-ticket layer.

On C8: attribution concerns are fair, but this proposal explicitly includes milestone reviews, portfolio reporting, final closeout reporting, and fund recovery mechanisms. That creates more accountability than many current funding routes.

On C11: the question shouldn’t be whether secondary DAOs are risky, they are. The question is whether this design reduces those risks enough to justify a pilot. I believe it does.

Cardano needs a funding layer between Catalyst and large Treasury withdrawals. This proposal is designed to fill that gap.

#### Feedback 2 — source: hydra, author: cardanoyoda
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a0411c3038cf72ed1e64e6b
- Summary (EN): Proposes structural changes: only active DReps (≥95% participation on last 40 proposals + regular rationales) can join; the DAO can pay external experts; splits 600k ADA into 200k for experts + 400k for DRep rewards. Asks whether this addresses the oversight concern.
- Summary (JA): 構造変更を提案: 過去40提案で参加率95%以上+定期的なrationale提供のアクティブDRepのみ加入可能。外部専門家への支払いも可能で、600k ADAを外部専門家200k + DRep報酬400kに分割。これで懸念が緩和するか問う。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C8, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi Yuta,

Thanks for the feedback.

DReps have been given a mandate by ADA holders to decide on much larger allocations in on-chain governance. It seems inconsistent if we deny them the right to decide on smaller allocations.

DReps have a track record. These are their decisions made in on-chain governance and their rationales.

Only active DReps can join the DAO. The Board will only allow a DRep to join the DAO if his participation in on-chain governance is 95% for the last 40 proposals and he regularly provides a rationale. 

The DAO can pay external experts. This possibility is considered in the design. It is important to realize that paying experts means increased costs. We can divide the 600K ADA into two parts. 200K ADA for external experts and 400K ADA for DRep rewards.

Would this help change your mind?

#### Feedback 3 — source: hydra, author: cardanoyoda
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a041a510dcaa7f9767cd4e8
- Summary (EN): Proposer response (auto-summary): Hi Yuta, Thanks for the feedback. The operation cost is 24% because it is fixed (₳3.4M) while the distribution budget (₳12M ADA) is dynamic. In the context of the distribution budget, the operational cost seems to be relatively high. Regard
- Summary (JA): 提案者の返信 (自動要約): Hi Yuta, Thanks for the feedback. The operation cost is 24% because it is fixed (₳3.4M) while the distribution budget (₳12M ADA) is dynamic. In the context of the distribution budget, the operational cost seems to be relatively high. Regard

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C8, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi Yuta,

Thanks for the feedback.

The operation cost is 24% because it is fixed (₳3.4M) while the distribution budget (₳12M ADA) is dynamic. In the context of the distribution budget, the operational cost seems to be relatively high.

Regarding the rewards for DReps and board members, I dare say that they are reasonable and necessary.

The disparity arises because this is a pilot that distributes ₳12M, i.e. ₳4M ADA in 3 rounds. If we decrease it to ₳1,5M per round, then the operation cost would be the same as the budget for distribution. You would get about 50%. 

If we increased the budget to ₳45M (3 rounds with ₳15M), we would fit into the operation cost of 5-10%. 

Please look at it from a different perspective. Our goal was to deliver a platform that may be missing in the ecosystem, but the operational costs will be cheaper.

For context:

IO requested ₳69,459,000 for Catalyst Funds 14-16. ₳61M was to be deployed across three funding rounds. So the operating costs were ₳8,459M. That makes ₳2.8M per round.

That was at ADA ≈ $0.50. Now the rate is at ADA ≈ $0.25.

Catalyst needed $1.4M per round, while DAO only needs $283K.

In this perspective, DAO has 5x lower costs per round than Catalyst has requested in the past. At the same time, each round we want to distribute 5x smaller budget than Catalyst (₳4M vs ₳20M).

Will this perspective change your mind?

#### Feedback 4 — source: hydra, author: cardanoyoda
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a041d1ef4bf5dd313f5cee4
- Summary (EN): Counters the oversight argument: DReps in DAOs get reward-funded time to do milestone reviews; requiring code-review for all on-chain proposals would be inconsistent. Plans a long-term 'DRep DAO' to oversee other DAOs as another layer of accountability.
- Summary (JA): 監督性への反論: DAO内のDRepは報酬予算によりマイルストーン審査の時間を確保。全オンチェーン提案にコードレビュー要求するなら一貫性を欠くと指摘。将来的に他DAOを監督する「DRep DAO」を追加層として構想。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C8, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi Yuta,

Thanks for the feedback.

I would like to address your feedback regarding oversight and the division of visibility into two layers.

It is true that regular DReps do not have time to devote to governance. That is why we dedicated a budget for rewards. DReps in DAOs approach the distribution of funds responsibly. They are willing to dedicate the necessary time for reasonable compensation.

If you applied your argument to other proposals, you would probably have to require DReps to do milestone reviews for all on-chain proposals, probably including code reviews. This feels inconsistent.

A DAO is subject to a standard process like any other proposal.

Moreover, a DAO is open. Active DReps can join the DAO, make decisions, propose changes to the processes, and oversee it.

Our long-term plan is to create a DRep DAO that should oversee all other DAOs that will distribute funds. This will be another layer of oversight. Of course, this DAO will be open to all DReps.

Does this change your opinion on the proposal, or do you need more information?

#### Feedback 5 — source: hydra, author: cardanoyoda
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a041f8e05e47100cbda5bb5
- Summary (EN): Argues TW doesn't scale for 100–1000 small proposals/year; active DReps can process more if compensated. Frames DAOs as scaling mechanism that keeps distribution in Cardano hands rather than outsourcing to third parties. Cites Constitutional support for DAOs.
- Summary (JA): TWは年100〜1000件の小規模提案を捌けない。報酬を得たアクティブDRepはより多くを処理可能。DAOを分配のスケーリング機構として位置づけ、第三者外注ではなくCardano内に保持する手段として正当化。憲法もDAO創設を支持と言及。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C8, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi Yuta,

Thanks for the feedback.

Regarding the preference for TW as the primary funding vehicle, you have to realize that it doesn't scale.

The number of budget applicants is relatively constant. It can be 100 to 1000 proposals per year in the range of ₳30K to ₳50M (Catalyst-like proposals vs. IO-like proposals).

I dare say that using on-chain governance for smaller proposals is inefficient. As you say yourself, the attention budget of DReps is limited.

However, there are passive DReps and active DReps. Active DReps can process more proposals. There is no reason to prevent active DReps from doing more work. 

Governance has to scale. We can't overwhelm DReps with a large number of proposals and hope that they can process them. We already know that they can't.

From my point of view, it makes sense to limit the number of TWs to larger asks and use alternative funding vehicles for smaller asks.

Try to look at it in the context of decentralization. We can, of course, pay expensive third parties to distribute Treasury ADA. In the extreme case, we don’t need on-chain governance. We can just give control of the Treasuries to a third party.

I think the ability to efficiently distribute ADA should remain in the Cardano ecosystem. DAOs should be a legitimate part of governance. The Constitution even supports the creation of DAOs.

Will this change your mind?

#### Feedback 6 — source: hydra, author: agora.cardano
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a058fe0f4bf5dd313f5ceee
- Summary (EN): Proposer states they have published a detailed response arguing that the rationale's conclusions rest on incomplete comparisons, incorrect budget aggregation, and assumptions that do not fit the DAO's design, addressing DRep oversight capacity, operational-overhead calculations, and benchmark comparability.
- Summary (JA): 提案者は詳細な回答を公開したと述べ、合理的根拠の結論は不完全な比較・予算カテゴリの誤集計・DAOの設計に当てはまらない前提に基づくと主張し、DRepの監督能力、運用オーバーヘッド計算、ベンチマークの比較可能性について反論している。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C8, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

I have published a detailed response addressing the concerns and rationale presented in YUTA’s evaluation framework regarding the Innovation & Growth DAO proposal.

The full response clarifies misconceptions, methodological inconsistencies, and interpretation issues that, in my view, led to conclusions that do not accurately reflect the proposal’s intended design, governance model, accountability structure, or operational framework.

The document addresses all major criticism points individually, including:

- DRep oversight capacity;
- operational-overhead calculations;
- benchmark comparability;

The response also includes public references, historical Catalyst comparisons, and additional context that could not fully fit within the original Intersect proposal template due to character limits.

Importantly, this is not an attempt to dismiss community feedback. The proposal itself has already gone through multiple refinement iterations with active input from highly engaged DReps and the Innovation & Growth DAO remains open to improving areas where valid concerns are identified.

However, after reviewing the criticism carefully, I believe several of the core conclusions were based on incomplete comparisons, incorrect aggregation of budget categories, or assumptions that do not fully apply to the actual structure and purpose of the DAO.

[**Full response**](https://hackmd.io/@CEF-RDdySpK5AabybGaN7g/SkKO_MbkMl)

#### Feedback 7 — source: hydra, author: agora.cardano
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc50fd89371182537b309e#comment-6a05f3b4ceb7fef00be0e459
- Summary (EN): Proposer posts a short link to additional feedback material.
- Summary (JA): 提案者は追加のフィードバック資料へのリンクを短く投稿している。

Full text:

Feedback: https://bit.ly/3PGLwbd

---

## 8. A High-Performance Partner Chain Factory using Ouroboros Tachýs

- Proposal ID: 69e8c0e2ae91c89d305701f5
- Requested: 13,150,479 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e8c0e2ae91c89d305701f5
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. I personally find this very interesting and understand the argument that, given the long development horizon, investment should start before consumption demand materialises. But given the ADA amount and current-priority profile, I want to lower this in the priority stack.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 個人的にはとても興味深い取り組みだと思いますし、 作業期間が長いため利用したいと考える段階に至る前に投資を始めるべきという意見は理解できますが、 この金額および現在の需要から見たプライオリティから考えると、 優先度を下げたいと思います。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; this is interesting over the long term, but I consider its priority to be somewhat lower at present. This is not something that contributes to Cardano L1's Tx or TVL, nor something that increases partner chains; it is basically something that makes it easier to spin up another L1. Over the long term that benefit may possibly materialize, but I believe the current focus should probably be on the partner-chain toolkit, on Cardano L1 itself, or on the DeFi built on top of it.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます、これは長期的には興味深いですが、現状やや優先度は下がると考えています。これはCardano L1のTxやTVLに貢献するようなものやパートナーチェーンを増やすようなものではなく、基本的には別のL1を生み出しやすくするものであり、長期的に見るとそのメリットが生まれる可能性があるかもしれませんが、おそらく現在の焦点はパートナーチェーンツールキットやCardano L1そのものやその上にあるDefiにあると考えています。

### Prior detailed analysis (EN)

**Vote: NO** on Ouroboros Tachýs Partner Chain Factory (**13.15M ADA / NCL 3.76%**).

**Main reasons**

**1. Current Cardano partner chain demand is unvalidated**
- Cardano-derived partner chains in production: **2** (Vector = AFF itself, the proposer; Midnight = IOG bespoke privacy chain)
- Independent third-party Cardano partner chain builders: **0**
- The proposal's demand validation KPI is 'minimum 1 institutional or enterprise builder team publicly commits to evaluating Tachýs by M15' — this is a future objective, not validated commitment at funding time
- $3.29M for 'minimum 3 builders engaged' target = **cost-per-engaged-builder $1.1M**

**2. Vector's outcome attribution is not yet established**
- AFF (Apex Fusion Foundation) launched Vector in **2025-12** (~5 months in production as of evaluation)
- Vector is at 'open for project onboarding' stage, not a fully populated ecosystem
- Vector tenant / usage data is not publicly disclosed
- Vector was launched **before adopting Tachýs** (currently uses Cardano-derived consensus); Tachýs itself has **zero production deployment** as of 2026-05
- The proposal's WP7 M15 deliverable schedules the first Tachýs deployment on Vector mainnet
- I.e., Tachýs production proof-of-concept arrives only at the 15-month mark of this funding cycle — initial achievement at funding cycle end

**3. Scope is anchored to projected demand, not current demand**

| Item | Value |
|---|---|
| Consortium size | 6 partners |
| Duration | 15 months |
| Budget | $3.29M |
| WP1 PM overhead | 16% ($526K) |
| Dedicated FTE roles | 3 (Technical Delivery Lead + Programme Delivery Lead + Ecosystem Engagement Lead) |

Comparable maintainer benchmarks (Substrate for Polkadot, Cosmos SDK) presuppose multi-billion-dollar mature ecosystems with extensive existing parachain demand. Tachýs consortium scope is anchored to projected institutional adoption, but the current Cardano partner-chain ecosystem (Vector + Midnight = 2 chains, third-party builders = 0) does not justify it. **Scope is not anchored to actual builder demand.**

### Prior detailed analysis (JA)

**Vote: NO** — Ouroboros Tachýs Partner Chain Factory (**13.15M ADA / NCL 3.76%**) に NO 投票します。

**主な理由**

**1. 現在の Cardano partner chain demand が未検証**
- Cardano-derived partner chains in production: **2** (Vector = AFF 自身が proposer 内、 Midnight = IOG bespoke privacy chain)
- Independent third-party Cardano partner chain builders: **0**
- 本提案 demand validation KPI は 'minimum 1 institutional or enterprise builder team publicly commits to evaluating Tachýs by M15' で、 validated commitment ではなく future objective
- $3.29M で 'minimum 3 builders engaged' target は **cost-per-engaged-builder $1.1M**

**2. Vector の outcome attribution が未確立**
- AFF (Apex Fusion Foundation) が Vector を **2025-12 launch** (評価時点で ~5 ヶ月 production)
- 'Open for project onboarding' stage で fully populated ecosystem ではなく
- Vector tenant / usage data が public に開示されていない
- 加えて Vector は **Tachýs 採用前** (現 Cardano-derived consensus 使用) で launched。 Tachýs 自体は 2026-05 時点で **zero production deployment**
- 本提案 WP7 M15 deliverable で Vector mainnet への first Tachýs deployment が予定
- つまり Tachýs production proof-of-concept は本 funding cycle 内で 15 ヶ月後に initial achievement

**3. Scope が projected demand に基づき、 current demand に基づかない**

| Item | Value |
|---|---|
| Consortium 規模 | 6 partners |
| Duration | 15 ヶ月 |
| Budget | $3.29M |
| WP1 PM overhead | 16% ($526K) |
| 3 dedicated FTE roles | Technical Delivery Lead + Programme Delivery Lead + Ecosystem Engagement Lead |

Comparable maintainer benchmark (Substrate for Polkadot、 Cosmos SDK) は multi-billion dollar mature ecosystem with extensive existing parachain demand が前提。 Tachýs consortium scope は projected institutional adoption に基づくが、 Cardano partner chain ecosystem 現状 (Vector + Midnight 2 chains、 third-party builder 0) では justification 弱い。 **Scope は現実の builder demand に anchor されていない**。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e8c0e2ae91c89d305701f5#comment-6a103af7f4bf5dd313f5cf4d
- Summary (EN): C5 rebuttal: argues Vector and Midnight are application/bespoke chains, not reusable open partner-chain toolkits — so non-duplication holds. The gap of a third-party builder ecosystem is the demand they aim to close, not evidence the infra is unneeded.
- Summary (JA): C5反論: VectorとMidnightはアプリ用/専用チェーンであり再利用可能なオープン・パートナーチェーン・ツールキットではないため重複しないと主張。第三者ビルダー・エコシステムの不在こそ埋めるべきギャップだと述べる。

Full text:

Yuta — thank you for the detailed, structured rationale. This is exactly the kind of engagement that improves governance. Let me address each criterion directly.

**C5 — Non-duplication** We agree there are currently two Cardano-derived chains in production. That is precisely the problem the proposal exists to solve. The non-duplication criterion asks whether another funded/live project already supplies what we propose to build — the answer is no. Neither Vector nor Midnight provides a reusable, open-source partner chain toolkit available to independent builders. Vector is an application chain built *using* our work; Midnight is an IOG bespoke chain with no open toolkit. The absence of a third-party builder ecosystem is the demand gap we are building infrastructure to close, not evidence that the infrastructure is unnecessary.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e8c0e2ae91c89d305701f5#comment-6a103b0705e47100cbda5c1b
- Summary (EN): C8 rebuttal: relevant track record is the consortium's delivery of cardano-node, Ouroboros and every hard fork through Plomin — strongest possible signal for an infrastructure proposal. Vector is live and open for project onboarding; Tachys mainnet at M15 is correctly sequenced.
- Summary (JA): C8反論: 実績はVectorの5ヶ月運用ではなく、cardano-node・Ouroboros 実装・Byron〜Plominの全ハードフォークを納品してきたコンソーシアムそのもの。Vectorは稼働中でプロジェクト受け入れ可能、Tachysメインネット投入はM15で順序として妥当と主張。

Full text:

**C8 — Past funding outcome** The relevant track record here is not Vector's five months in production — it is the team's delivery of the Cardano node, implementation of Ouroboros, and every hard fork from Byron through Plomin. This consortium built and maintained the protocol that underpins every ADA transaction. That is the strongest possible C8 signal for an infrastructure proposal of this kind. On Vector specifically: it is live, producing blocks, and open for project onboarding. That it is early-stage is expected — it launched in December 2025. We agree that Tachys production deployment arrives at M15 on Vector mainnet; this is sequenced correctly for a protocol implementation milestone, not a concern about delivery intent.

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e8c0e2ae91c89d305701f5#comment-6a103bb57d5f66c54876627c
- Summary (EN): C9 rebuttal: signed LOI with Trace Labs (OriginTrail) to integrate the DKG as shared-context layer for agentic apps on Tachys — concrete third-party demand. Cites Substrate/Cosmos SDK precedent of infrastructure being funded before parachain/IBC ecosystems existed.
- Summary (JA): C9反論: Trace Labs (OriginTrail)とDKG統合のLOIに署名済みで、Tachysパートナーチェーン上のエージェント型アプリ向け共有コンテキスト層として実需の証拠。Substrate/Cosmos SDKもパラチェーン/IBC エコシステム成立前に資金提供された前例として挙げる。

Full text:

**C9 — Thesis validation** We have now signed a Letter of Intent with Trace Labs (OriginTrail) — developers of the leading Decentralised Knowledge Graph for trusted AI — specifically to integrate the OriginTrail DKG as the shared-context layer for agentic applications on Tachys partner chains. This is a named third-party organisation committing to evaluate and build on Tachys. It is signed, not projected, so is evidence of real demand. In addition, we have further engagement with prospective users that we are not yet able to publicly evidence. We would also note that Substrate and the Cosmos SDK were funded as shared infrastructure before the parachain and IBC ecosystems existed. The thesis that open shared infrastructure creates builder demand is one of the most validated in the industry. We are asking the Cardano treasury to make the same bet — with a team that has already delivered the base layer.

The signed LOI is available here: [https://drive.google.com/file/d/1IBlRBlX8XOahF1QsHiqz-JhU7tsZjdLl/view?usp=share\_link](https://drive.google.com/file/d/1IBlRBlX8XOahF1QsHiqz-JhU7tsZjdLl/view?usp=share_link)

We appreciate your continued engagement.

Kevin Hammond CEO, Ensurable Systems / Lead, Tachys Consortium

---

## 9. Support Cardano 2030: A Techstars Strategy for Global Ecosystem Adoption & Utility

- Proposal ID: 69f8328b93fdcc8059d4cc20
- Requested: 9,373,803 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8328b93fdcc8059d4cc20
- Category: Marketing / events
- Applicable criteria: C3, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. I understand the point that you do not commit to outcome KPIs, but this is a factor that tilts me toward NO. I also think it would be possible to set an intermediate KPI between outcome KPIs and process KPIs. Regarding the past track record, I am also concerned that the Cardano-attributable on-chain outcomes currently appear thin.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。成果KPIをコミットしない点を理解しましたが、これはNOに傾く要素です。また、成果KPIとプロセスKPIの中間的なKPIを設定することも可能だと思います。過去の実績について、Cardano帰属のオンチェーン成果が現状薄いように見える点も懸念しています。

### Prior detailed analysis (EN)

**Categorisation**: [Marketing/events / accelerator]. Non-applicable: C1, C2, C4, C5, C6, C7, C10, C11.

**Applicable: C3, C8**. Applying:

• **C3 — KPI = outcome (zero Cardano-specific commitments)**: All proposed KPIs are process metrics — masterclass attendance, mentorship utilization, pitch readiness, Techstars Accelerator acceptance rate. No commitments on Cardano-specific:
  - Deployment count (named projects committing to deploy on Cardano)
  - Tx generation
  - TVL contribution
  '$3B TVL / 1M MAU by 2030' is cited as Cardano-wide ecosystem target, not as Techstars-attributable commitment. The proposal cannot make Techstars accountable to that target.

• **C8 — Prior F13 Cardano funding outputs unverified**: Per public Catalyst funding records, Project 1300182 (claimed by proposer as F13 Cardano funding precedent) has the following verification gap:
  - Proposal claims 'great success'
  - No verifiable outcome metrics presented in current proposal: graduates deployed on Cardano (count), tx/TVL generated, retention beyond program end, etc.
  - Per /tx-roi backend, no verifiable production tx attributable to F13 graduates as a cohort

  Without past period outcome attribution, the +funding for 2030 strategy cycle cannot be evidence-supported.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [Marketing/events / accelerator]。 非適用: C1, C2, C4, C5, C6, C7, C10, C11。

**適用: C3, C8**。 適用:

・**C3 — KPI = outcome (zero Cardano-specific commitment)**: 全 KPI は process metric — masterclass 参加, mentorship 利用, pitch readiness, Techstars Accelerator acceptance rate。 Cardano-specific commitment なし:
  - Deployment 数 (Cardano deploy commit する named project)
  - Tx 生成
  - TVL 寄与
  '$3B TVL / 1M MAU by 2030' は Cardano-wide ecosystem target として cite で、 Techstars-attributable commitment ではない。 提案書は Techstars をその target に accountable にできない。

・**C8 — 過去 F13 Cardano funding outputs 未検証**: 公開 Catalyst funding records より、 Project 1300182 (提案者が F13 Cardano funding precedent として claim) の verification gap:
  - 提案書は 'great success' 主張
  - 現提案書に verifiable outcome metric 提示なし: Cardano deploy graduate (数), tx/TVL 生成, program 終了後 retention 等
  - /tx-roi backend より、 cohort としての F13 graduates に帰属可能 production tx なし

  Past period outcome attribution なしでは、 2030 strategy cycle への +funding を evidence-support できない。

よって本提案はこれらを満たさない。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8328b93fdcc8059d4cc20#comment-6a06bfdbf4bf5dd313f5cef6
- Summary (EN): Brief acknowledgement: thanks YUTA for the C3 & C8 insights, says they are collecting data and refining the relevant sections, will reply again once the proposal is updated.
- Summary (JA): 短い受け答え: C3とC8に関する指摘に感謝し、データを収集中で該当セクションを改訂中、更新後に再度コメント予定とのこと。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C3, C8).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi! Thank you for your comment and the insights related to C3 & C8. I'm collecting data, refining the relevant sections, and will comment here again once the proposal is up to date and compliant with the above.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8328b93fdcc8059d4cc20#comment-6a1d2774f4bf5dd313f5cf7d
- Summary (EN): Proposer provides Fund 13 / prior Techstars cohort performance data (377 applications, 18 startups, mainnet deployments, MAUs, paying customers, external capital raised, SDK integrations), noting the program is an early-stage pre-accelerator and data collection is still ongoing.
- Summary (JA): 提案者はFund13/前回のTechstarsコホートの実績データ(377件の応募、18スタートアップ、メインネット展開、MAU、有料顧客、外部資金調達、SDK統合)を提示し、本プログラムは初期段階のプレアクセラレーターでデータ収集が継続中だと説明している。

Full text:

Dear Drep,

Thank you for your comment. Please find below additional information that we hope will be useful. We remain available to explore any item further.

**1. Project Catalyst Fund 13, i.e., previous Techstars Cardano Cohort performance:**

**Introductory notes:&#160;**

- Data collection is ongoing because the cohort graduated only **5 months ago.**
- To provide proper context for the F13/previous cohort results below, it is essential to clarify the stage of our interventions: **the Techstars** **Founder Catalyst program is a** **pre-accelerator and investment-readiness program.** We work with very early-stage founders. Many of these innovators join our cohorts with **only a basic MVP, and they are frequently not yet incorporated.** 

Our 2025 Techstars Founder Catalyst for Cardano Builders demonstrated a clear return on ecosystem investment, attracting **377 applications from 15 countries** and resulting in an elite cohort of **18 startups**. Below are some highlights: 

- **Mainnet Deployments & Transactions:** 
**Startup D** launched live on the Cardano mainnet on **February 6, 2026**. **Startup A** has securely anchored **2,330 patient medical records** through 80+ mainnet infrastructure transactions.
- **MAU & Users:** 
**Startup E** leads with **200K+ active users** and 10M+ completed notarizations. 
**Startup C** commands **2,000 MAUs** comprised entirely of the Cardano community.
- **Revenue & Customers:** 
**Startup C** has secured **10 paying B2B customers**
**Startup E** has signed **15 Tier-1 enterprise clients**.
- **External Capital:** 
**Startup B** raised **$205,000** post-program, complementing an over-funded **$300K early-bird token round** raised by a cohort company during the program execution.
- **Developer Partnerships:** 
**120 projects** have actively deployed or integrated **Startup C’s SDK** into their operations.

*This continues in my next comment*

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8328b93fdcc8059d4cc20#comment-6a1d277f5141bb70a939dbab
- Summary (EN): Proposer explains why it does not commit to pre-program deployment or fundraising KPIs, arguing mainnet integration depends on founders and community support beyond its control, and that it prioritizes operational honesty over inflated speculative numbers.
- Summary (JA): 提案者は、プログラム前にデプロイや資金調達のKPIを約束しない理由を説明し、メインネット統合は自社の管理外にある創業者や community の支援に依存するため、誇張した推測値より運用上の誠実さを優先すると主張している。

Full text:

**2. Committing to KPIs and** **projected conversion to active Cardano deployment (KPI = outcome, not process)**

- Projecting conversion to active Cardano deployment or future fundraising is an inherently tricky exercise.
- While past data and success metrics provide a solid foundation, future deployment is a community-owned effort. It depends on what the founders decide to do and the level of support from the wider Cardano community.
- Techstars ensures founders are investment-ready and technically prepared for the ecosystem. We also ensure founders get the required support in program from Cardano Contributors: contributors might include individuals from Fluid Tokens, Harmonic Labs, Anastasia Labs, or Zetta Capital. However, the final mainnet integration involves variables beyond our control. For this reason, we avoid committing to deployment and fundraising KPIs pre-program (before we know the founders we will be working with).
- Although market practice is often to supply highly ambitious, inflated numbers to enhance proposal perception, we prioritize operational honesty and transparency over speculative commitments and showcase past successes to strengthen our proposal.

---

## 10. Amplify Cardano: Ecosystem Accelerator + Community-Led Marketing & Events Fund

- Proposal ID: 69f293527822b26563397afd
- Requested: 8,583,334 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f293527822b26563397afd
- Category: Marketing / events
- Applicable criteria: C3, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

フィードバックなし

### Prior detailed analysis (EN)

**Categorisation**: [Marketing/events / accelerator]. Non-applicable: C1, C2 (Rare Network has cited track record), C4, C5, C6, C7, C9, C10, C11.

**Applicable: C3, C8**. Applying:

• **C3 — KPI = outcome (Cardano network outcomes absent)**: Proposed KPIs center on:
  - Tier-1 listings (exchange listing output for selected projects)
  - Project-specific SOWs (individual project market metrics)
  - Media reach
  - Events delivered
  These are output/marketing metrics for selected commercial entities, not Cardano network commitments. 'Tier-1 listing' is market positioning achievement for selected projects, not a Cardano network outcome.

  **Selection criteria select 'already-successful top projects'**: per proposal, criteria include token market cap, sustained TVL, DAU, Tx, DeFi traffic share, Tier-1 listing suitability. These pass projects already at scale. **Marketing amplifies product-market fit; does not create it**. Solana Jupiter at zero-TVL launch would not have been selected under these criteria.

• **C8 — Past funding pattern (Rare Network / Rare Evo track record)**: Two prior funding streams exist — both should be evaluated, neither is presented with outcome data in the current proposal:

  1. **TW #47 — Cardano Summit 2025 and regional tech events (₳6M, ratified epoch 575, 2025-07)**: Per the on-chain TW abstract — 'spearheaded by the Cardano Foundation and fortified by regional ecosystem partners (**EMURGO, Rare Evo, Wada, Catalyst Africa Town Hall, Ada Solar**)'. CF was the prime; **Rare Evo was one of five regional partners**, executing a regionally-focused Summit event (US/North America scope). The 'Unified Events Campaign' branding seen on @RareNetworkWeb3 X posts (Hong Kong, Tokyo, Paris, Miami, Duke) appears to be the year-long executed series under this 2025 TW funding plus follow-on activity. **This is a material prior cycle to evaluate Rare Network on — but the current Budget #69 proposal does not present empirical Cardano network outcomes from it**. Required: per-event attribution data (new wallets in the post-event 30-day window, dev signups, dApp pilots, on-chain Tx attributable to event audiences). Currently absent.

  2. **F14 Catalyst Amplify Cardano pilot** (per /tx-roi: 4 prior Catalyst proposals = 50,400 ADA total). Ekklesia X endorsement from @_____: 'The Amplify Cardano pilot through Project Catalyst Fund 14 delivered real results, and this 18 month proposal is a direct extension of a model that's already running' — but no per-cohort cohort-attribution data is cited.

  Cited record (60+ activations, average 2,000 attendees, 1M video views, 5 years of Rare Evo) consists of process/output metrics. **No documented Cardano network-attributable outcomes** from either funding stream:
  - TVL increase (attributable to Rare events under TW #47)
  - Permanent developer onboarding (count of devs who became active Cardano contributors)
  - New Cardano DApp launches (attributable to Rare cohort)
  - Wallet creation uplift (attributable to Rare audiences)
  - Tx impact

  The gap is that Rare Evo's regional-partner outcome contribution from TW #47 isn't presented as the empirical foundation for the Budget #69 scale-up ask.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [Marketing/events / accelerator]。 非適用: C1, C2 (Rare Network cited track record あり), C4, C5, C6, C7, C9, C10, C11。

**適用: C3, C8**。 適用:

・**C3 — KPI = outcome (Cardano network outcome 欠如)**: 提案書 KPI 中心:
  - Tier-1 listing (selected project 向け取引所 listing output)
  - Project-specific SOWs (個別 project market metric)
  - Media reach
  - Events delivered
  これらは selected commercial entity 向け output/marketing metric で Cardano network commitment ではない。 'Tier-1 listing' は selected project の market positioning 達成で Cardano network outcome ではない。

  **選定基準は 'already-successful top project' を選ぶ**: 提案書より基準は token mcap, sustained TVL, DAU, Tx, DeFi traffic share, Tier-1 listing suitability。 既に scale 達成 project のみ pass。 **Marketing は product-market fit を amplify、 create はしない**。 Solana Jupiter は zero-TVL launch 時にこの基準で選ばれなかった。

・**C8 — 過去資金 pattern (Rare Network / Rare Evo track record)**: 2 つの prior funding stream が存在、 両方とも評価対象だが、 現提案書はいずれの outcome data も提示していない:

  1. **TW #47 — Cardano Summit 2025 and regional tech events (₳6M、 epoch 575 ratified、 2025-07)**: On-chain TW abstract より — 'Cardano Foundation が spearhead、 regional ecosystem partners (**EMURGO, Rare Evo, Wada, Catalyst Africa Town Hall, Ada Solar**) が補強' — CF が prime で **Rare Evo は 5 つの regional partners の 1 つ**、 regionally focused (US/北米 scope) Summit event を執行する役割。 @RareNetworkWeb3 X 投稿 (Hong Kong, Tokyo, Paris, Miami, Duke) で見られる 'Unified Events Campaign' branding は本 2025 TW 資金 + 後続活動の 1 年規模 executed series。 **これは material な prior cycle — but 現 Budget #69 提案書は そこからの empirical Cardano network outcome を提示していない**。 必要: per-event attribution data (event 後 30 日 window で生成された新 wallet、 dev signup、 dApp pilot、 event audience 帰属可能 on-chain Tx) — 現在 absent。

  2. **F14 Catalyst Amplify Cardano pilot** (/tx-roi より: 4 prior Catalyst proposal = 50,400 ADA total)。 Ekklesia X endorsement @_____: 'The Amplify Cardano pilot through Project Catalyst Fund 14 delivered real results, and this 18 month proposal is a direct extension of a model that's already running' — 但し per-cohort cohort-attribution data は cite なし。

  Cited record (60+ activations, 平均 2,000 attendees, 1M video views, 5 年 Rare Evo) は process/output metric。 **いずれの funding stream からも Cardano network 帰属可能 outcome 文書化なし**:
  - TVL 増 (TW #47 下の Rare events 帰属可能)
  - Permanent developer onboarding (active Cardano contributor になった dev 数)
  - 新 Cardano DApp launch (Rare cohort 帰属可能)
  - Wallet creation uplift (Rare audiences 帰属可能)
  - Tx impact

  gap は Rare Evo の regional-partner outcome 寄与 (TW #47) が Budget #69 scale-up ask の empirical foundation として提示されていないこと。

よって本提案はこれらを満たさない。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 11. Security Threat Assessment Guard (STAG): Continuous Security Assurance for the Cardano Ecosystem

- Proposal ID: 69e90478d699758cde5d4a5e
- Requested: 7,890,487 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C10
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

As one developer noted, this kind of work is better funded as an outcome-based bug bounty rather than a large up-front grant. Bug-bounty design also incentivises teams other than the proposer to actively perform security validation.

### Voting reason (JA, as of 2026-05-28)

ある開発者が指摘しているように、 このような取り組みは多額の前払いではなく、 バグ報奨金のような成果報酬方式にする方が良いでしょう。 これにより、 提案書提出者チーム以外のチームが積極的にセキュリティ検証を行う動機にもなります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Given the recent increase in security incidents, the growth of AI, and the drawbacks of bug bounties, this may be necessary. Would it be possible to gather endorsement voices from ecosystem developers?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

最近のセキュリティ事案の増加とAIの成長、バグバウンティのデメリットを考えると、これは必要なのかもしれません。エコシステムの開発者の推薦の声を集めることは可能ですか?

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on STAG (**7.89M ADA / NCL 2.25%**).

**Main reason (decisive — parent-budget opacity makes STAG unevaluable)**

**Ensurable Systems is named in TWO Budget #69-adjacent proposals at the same time, with no breakdown showing what each pays for:**

| Proposal | Amount | Ensurable Systems role |
|---|---|---|
| **IO & Ensurable Systems: Cardano Maintenance Initiative** (active TW) | **62.1M ADA** (~17.7% of NCL) | Named **co-prime with IO** for Cardano maintenance — includes security work |
| **STAG** (this proposal) | **7.89M ADA** | Named in 4-org red-team consortium for Cardano security |

The 62.1M Maintenance Initiative is large for what it calls 'maintenance' and **does not publish a budget breakdown**. Without that breakdown, DReps cannot determine:
- How much of the 62.1M is allocated to security work
- How much of that security work is at Ensurable Systems specifically
- Whether STAG's 7.89M security ask is **additive new work**, or **double-billing** for security work Ensurable Systems is already contracted to do under the 62.1M

Approving STAG while the 62.1M parent is opaque creates an unavoidable risk: paying Ensurable Systems twice for the same security scope. **The structural problem is not STAG itself — it is the evaluative impossibility caused by the 62.1M Maintenance Initiative's lack of breakdown.**

**Other concerns (smaller, but still real)**

**1. STAG addresses a real multi-client Cardano security gap** — this is genuine. Cardano now has multiple node implementations (Amaru, Dingo, Gerolamo in development), and cross-implementation edge-case bugs are a real concern (like Ethereum's geth/besu/erigon/nethermind divergences). The consortium (QuviQ AB, Predictable Network Solutions, Well Typed LLP, Ensurable Systems) is high-credibility. The category is not the problem.

**2. Independence framing is sound** — funding via community treasury rather than IOG/CF/Intersect is a real argument for independence. A security team funded by the entities it scrutinises is structurally compromised.

**3. Other transparency gaps in STAG itself**
- Per-org budget allocation across the 4 organisations is not specified
- Workflow between STAG findings, Intersect Security Council, and the Bug Bounty Programme is not fully defined
- 18-month commitment with opt-out checkpoints is structurally different from milestone-gated disbursement (cleaner: 6-month tranches with explicit DRep re-approval)

**Recommend resubmission requires both**:
1. **The 62.1M parent (IO & Ensurable Systems Maintenance Initiative) publishes a budget breakdown** showing what Ensurable Systems is paid to do under that contract — without this, STAG cannot be cleanly evaluated.
2. **STAG itself publishes**: (a) per-org budget breakdown, (b) workflow definition with Intersect Security Council + Bug Bounty, (c) cleaner milestone-gated disbursement.

*The category (multi-client cross-implementation security) is genuinely valuable. The NO-recommend-resubmit reflects: same vendor appearing in two proposals at the same time without breakdown is a transparency-first concern that must be resolved before either proposal can be approved cleanly.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — STAG(**7.89M ADA / NCL 2.25%**)。

**決定的な懸念 — 親予算の不透明性により STAG を単独で評価できない**

**Ensurable Systems が Budget #69 関連の 2 つの提案に同時に名前付きで登場しており、 それぞれが何を支払うかの内訳がない**:

| 提案 | 金額 | Ensurable Systems の役割 |
|---|---|---|
| **IO & Ensurable Systems: Cardano Maintenance Initiative**(active TW) | **62.1M ADA**(NCL の約 17.7%) | **IO と共同 prime** で Cardano maintenance を担当 — security 作業を含む |
| **STAG**(本提案) | **7.89M ADA** | 4 組織 red-team コンソーシアムの 1 つとして Cardano security 担当 |

62.1M の Maintenance Initiative は「メンテナンス」 と呼ぶには金額が大きく、 そして **内訳を公開していません**。 内訳がない以上、 DRep は次のことを判断できません:
- 62.1M のうち security 作業にいくら割り当てられているか
- そのうち Ensurable Systems 担当分はいくらか
- STAG の 7.89M security 要求が **新規追加の work** なのか、 それとも **62.1M で Ensurable Systems が既に契約済みの security work と二重請求** になっているのか

62.1M の親予算が不透明な状態で STAG を承認すると、 同じ security 範囲について **Ensurable Systems に二重に支払う risk** が避けられません。 **構造的な問題は STAG 自体ではなく、 62.1M Maintenance Initiative に内訳がないために評価が不能になっていることです。**

**その他の懸念(より小さいが、 実在)**

**1. STAG はマルチクライアント Cardano の実在のセキュリティ空白に対処** — これは genuine。 Cardano は now マルチクライアント化 (Amaru, Dingo, Gerolamo が開発中)、 実装間のエッジケースバグは実在の懸念 (Ethereum の geth/besu/erigon/nethermind 分岐前例と同じ)。 コンソーシアム (QuviQ AB, Predictable Network Solutions, Well Typed LLP, Ensurable Systems) は信頼性が高い。 カテゴリ自体は問題ではない。

**2. 独立性の議論は妥当** — コミュニティトレジャリー資金 (IOG/CF/Intersect ではなく) は independence の real な argument。 監査対象の組織から資金を受ける敵対的セキュリティチームは構造的に妥協が入る。

**3. STAG 自体にもその他の transparency gap**
- 4 組織への組織ごと予算配分が未指定
- STAG findings、 Intersect セキュリティカウンシル、 バグバウンティ間のワークフローが完全には定義されていない
- 18 か月コミット + オプトアウトチェックポイントは、 マイルストーン段階払いとは構造が違う(より明快: 6 か月単位の段階払い + 各時点で DRep 再承認)

**再提出に必要なもの 2 つ**:
1. **親予算(IO & Ensurable Systems Maintenance Initiative 62.1M)が予算内訳を公開** — Ensurable Systems が当該契約下で何を支払われているかを示す。 これなしでは STAG は単独で評価不能。
2. **STAG 自体が公開**: (a) 組織ごと予算内訳、 (b) Intersect セキュリティカウンシル + バグバウンティとのワークフロー定義、 (c) より明快なマイルストーン段階払い。

*カテゴリ (マルチクライアント実装横断 security) は本当に valuable。 NO-resubmit の根拠は、 **同一 vendor が複数提案に同時登場しており内訳がないという transparency-first concern**。 これが解決されない限り、 どちらの提案も clean に承認できない。*

### Proposer feedback (12)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de8e605e47100cbda5c51
- Summary (EN): Proposer agrees DReps should be able to tell whether two same-organization proposals fund the same work, and asserts STAG does not duplicate the IO & Ensurable Systems Maintenance Initiative despite overlapping security language, because they fund different functions.
- Summary (JA): 提案者は、同一組織の2つの提案が同じ作業に資金提供しているかをDRepが判断できるべきだと同意し、セキュリティ用語が重複していてもSTAGはIO & Ensurable Systemsのメンテナンスイニシアチブを重複しないと主張する。両者は異なる機能に資金提供しているためである。

Full text:

Thank you for the detailed review and for clearly raising the concern. We agree that DReps should be able to determine whether two proposals involving the same organisation fund the same work or genuinely distinct responsibilities.

Our position is that STAG does not duplicate the IO & Ensurable Systems Cardano Maintenance Initiative. The two proposals do use some overlapping security language because both sit within Cardano’s security posture, but they fund different functions.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de9050dcaa7f9767cd599
- Summary (EN): Proposer contrasts the Maintenance Initiative (bug fixing, releases, CI/CD, monitoring, incident response) with STAG as an independent adversarial security assurance program that hunts for vulnerability classes hard to catch in normal maintenance.
- Summary (JA): 提案者は、メンテナンスイニシアチブ(バグ修正、リリース、CI/CD、監視、インシデント対応)とSTAGを対比し、STAGは通常のメンテナンスでは捕捉しにくい脆弱性クラスを探索する独立した敵対的セキュリティ保証プログラムだと説明している。

Full text:

1. Maintenance vs STAG

The maintenance proposal focuses on keeping Cardano’s core infrastructure operating safely and reliably. That includes bug fixing, hot fixes, release support, CI/CD, monitoring, component maintenance, incident response, and collaboration with the Security Council.

STAG, in contrast, is not a maintenance contract. It is an independent adversarial security assurance programme. Its purpose is to search for classes of vulnerabilities before they become incidents, especially across the areas that are difficult to test through normal maintenance workflows: cross-client divergence, consensus edge cases, ledger interpretation, compiler behaviour, UPLC execution, wallet and client assumptions, network protocol behaviour, and mainnet performance risks.

....

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de932a7468bb49bf846e9
- Summary (EN): Proposer distinguishes the two proposals by purpose, nature of work, outputs, relationship to incidents, independence model, and Ensurable Systems' role, arguing Ensurable's presence in both reflects relevant expertise rather than duplicate scope.
- Summary (JA): 提案者は両提案を目的・作業の性質・成果物・インシデントとの関係・独立性モデル・Ensurable Systemsの役割で区別し、Ensurableが両方に登場するのはスコープ重複ではなく関連する専門性の表れだと主張している。

Full text:

...

A simple way to distinguish the two is by looking at what each is designed to do.

Primary purpose

- The Maintenance Initiative is designed to keep production infrastructure maintained, tested, released, monitored, and supported.
- STAG is designed to actively hunt for vulnerabilities, systemic weaknesses, and cross-stack security risks.

Nature of the work

- The Maintenance Initiative is operational maintenance and engineering stewardship.
- STAG is independent adversarial analysis and red-team assurance.

Main outputs

- The maintenance initiative includes fixes, releases, monitoring, operational support, incident response, and component maintenance.
- STAG produces verified findings, threat models, risk reports, test artefacts, responsible disclosure outputs, and public-domain assurance outputs.

Relationship to incidents

- The Maintenance Initiative responds to, fixes, and supports the resolution of known issues.
- STAG looks for unknown issues and escalates them before they can be exploited.

Independence model

- The Maintenance Initiative is delivered as part of an IO-led maintenance function.
- STAG is community-funded and independent of IO, CF, and Intersect.

Where Ensurable Systems fits

- In the Maintenance Initiative, Ensurable Systems is a specialist engineering partner supporting maintenance and stewardship.
- In STAG, Ensurable Systems is one of four organisations in a red-team consortium.

The fact that Ensurable Systems appears in both proposals reflects relevant expertise rather than duplicate scope. We want to be as specific as we can about what that scope is.


...

#### Feedback 4 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de95f038cf72ed1e64f23
- Summary (EN): Proposer details that Ensurable Systems' maintenance scope (coordination, release management, performance evaluation, design input) excludes adversarial security work, that QuviQ/PNSol/Well Typed have no maintenance involvement (~60% of STAG effort), and that the COI policy and handoff design prevent double billing.
- Summary (JA): 提案者は、Ensurable Systemsのメンテナンス範囲(調整、リリース管理、性能評価、設計助言)は敵対的セキュリティ作業を含まないこと、QuviQ/PNSol/Well Typedはメンテナンスに関与せず(STAGの作業の約60%)、利益相反方針とハンドオフ設計が二重請求を防ぐことを詳述している。

Full text:

...

Within the Maintenance Initiative, Ensurable Systems' scope covers technical coordination, release management, performance evaluation, and design input to ledger, consensus, and CLI where appropriate. It does not include independent adversarial security analysis, red-teaming, cross-implementation divergence testing, or any of the work described in the STAG work packages.  Ensurable Systems is a co-delivery partner with IOG, who are responsible for the direction of the maintenance programme.

Within STAG, Ensurable Systems' primary focus is wallet and client security (WP6), UPLC and smart contract execution layer security (WP1), and compiler toolchain security (WP2) — none of which fall within its maintenance remit. Ensurable also leads consortium coordination, AI tooling infrastructure, and overall risk assessment synthesis (WP5).

Critically, the other three STAG consortium members - QuviQ, PNSol, and Well Typed — have no involvement in the Maintenance Initiative in any capacity. The majority of STAG's technical delivery (approximately 60% of programme effort) sits with these three organisations, entirely outside the maintenance perimeter.

We believe the functional scope separation described above is sufficient for DReps to evaluate whether STAG represents additive new work — but we recognise that is a judgement DReps must make for themselves, and we support that scrutiny.

The conflict of interest policy in Appendix C of the proposal governs any case where work packages might intersect, including mandatory disclosure, recusal from severity classification and disclosure decisions, and escalation to Intersect where necessary.

The handoff between the two is intentional. STAG finds and validates risks. The relevant maintainer or repository owner then resolves them. That separation avoids double billing: STAG is not paid to maintain the Cardano node under this proposal, and maintenance is not paid to deliver an independent cross-stack red-team programme.

...

#### Feedback 5 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de9867d5f66c5487662a8
- Summary (EN): Proposer cites Michael Karg, owner of the IO maintenance proposal, who at a STAG X Space distinguished reactive operational-security maintenance from STAG's deliberate, proactive adversarial approach and called STAG's work something beyond maintenance.
- Summary (JA): 提案者は、IOメンテナンス提案の責任者Michael KargがSTAGのX Spaceで、反応的な運用セキュリティのメンテナンスとSTAGの意図的・能動的な敵対的アプローチを区別し、STAGの作業はメンテナンスを超えるものだと述べた発言を引用している。

Full text:

...

This distinction was also addressed directly by Michael Karg, owner of this year’s IO maintenance and support proposal, during the [STAG X Space](https://x.com/ensurablesys/status/2057804936075771985) (quote here [https://youtu.be/3H3M0NjULP8](https://youtu.be/3H3M0NjULP8)), ([https://x.com/ensurablesys/status/2057804936075771985](https://x.com/ensurablesys/status/2057804936075771985)) on 22 May 2026.

Michael explained that the maintenance proposal covers operational security, including network monitoring, incident management, disaster recovery, and QA-driven testing at the component and system level. However, he drew a clear distinction between that and STAG’s adversarial security model:

“While we do cover the basics with the IO maintenance and support proposal and while we have a heavy focus on the operational aspect, it is still a reactive approach to security, which is fine for maintenance. But if you want to be deliberate and proactive, STAG is really the thing that you want.”

He also described STAG’s approach as “something completely different” from maintenance and “something that goes way beyond maintenance", adding that security hardening through STAG’s proposed work packages is “not something that goes under maintenance” and delivers “a very clear value".

#### Feedback 6 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de9b95141bb70a939dbb1
- Summary (EN): Proposer addresses the missing per-org budget concern by providing a per-vendor and per-work-package breakdown (person-months, USD, and ADA for Ensurable, QuviQ, PNSol, Well Typed, plus shared costs), noting the Hydra form lacked space for this detail.
- Summary (JA): 提案者は組織別予算の欠如という懸念に対し、ベンダー別・ワークパッケージ別の内訳(Ensurable、QuviQ、PNSol、Well Typedのperson-month・USD・ADA、および共通費)を提示し、Hydraフォームにこの詳細を載せる余地がなかったと説明している。

Full text:

2. STAG financial breakdown

We note that your rationale identified the absence of per-org budget allocation as a concern. The [full proposal](https://drive.google.com/file/d/1yXqbzg-o9_EFrhZOhQf0Tuya2ij5ury6/view?usp=sharing) does break down the STAG budget by vendor as well as by workpackage (Section 3, Budget Breakdown by Partner), and also gives person-month allocations for each partner.  Unfortunately, the Hydra form did not provide enough space for this level of detail to be included there as well.  We are happy to repeat this.

Ensurable Systems: 24.8 PM / $516,667 / 2,066,667 ADA — primary work packages WP1–3, WP5–6

QuviQ: 20.4 PM / $425,000 / 1,700,000 ADA — primary work packages WP1–3

PNSol: 18.9 PM / $393,750 / 1,575,000 ADA — primary work packages WP4, WP7

Well Typed: 10.8 PM / $225,000 / 900,000 ADA — primary work packages WP2–5 Shared costs: $354,750 / 1,419,000 ADA — all WPs

The breakdown of effort from the full proposal is:

WP1 (UPLC & Smart Contract Execution): Ensurable 4.8 PM, QuviQ 10.8 PM — total 15.6 PM

WP2 (Compiler Toolchain): Ensurable 2.0 PM, QuviQ 4.8 PM, Well Typed 3.6 PM — total 10.4 PM

WP3 (Ledger Security): Ensurable 4.2 PM, QuviQ 4.8 PM, Well Typed 3.6 PM — total 12.6 PM

WP4 (Consensus & Network): Well Typed 3.0 PM, PNSol 5.4 PM — total 8.4 PM

WP5 (CLI, AI Tooling & Reporting): Ensurable 5.4 PM, Well Typed 0.6 PM — total 6.0 PM

WP6 (Wallet & Client): Ensurable 8.4 PM — total 8.4 PM

WP7 (Mainnet Performance): PNSol 13.5 PM — total 13.5 PM

Total: Ensurable 24.8 PM, QuviQ 20.4 PM, Well Typed 10.8 PM, PNSol 18.9 PM — programme total 74.9 PM

#### Feedback 7 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1de9d605e47100cbda5c52
- Summary (EN): Proposer presents STAG's threat detection and escalation workflow from target selection through validation, severity classification, 24-hour reporting of critical findings, Security Council triage, remediation by maintainers, and STAG re-validation, arguing this avoids consuming STAG funds for maintenance work.
- Summary (JA): 提案者はSTAGの脅威検出・エスカレーションのワークフロー(対象選定から検証、深刻度分類、重大な発見の24時間以内報告、Security Councilのトリアージ、メンテナーによる修正、STAGの再検証まで)を提示し、これによりメンテナンス作業にSTAG資金を使わずに済むと主張している。

Full text:

3. Threat detection and escalation workflow

STAG should be understood as an active threat-management layer. It continuously looks for exploitable weaknesses, validates them, and escalates them into the appropriate remediation path.

Suggested workflow:

Threat intelligence/target selection

        ↓

Adversarial analysis, fuzzing, modelling, review, monitoring

        ↓

Potential finding identified

        ↓

Internal STAG validation

        ↓

Reproduction, impact analysis, affected component mapping

        ↓

Severity classification

        ↓

Critical or high severity?

        ↓

YES: report within 24 hours to the Security Council and affected maintainers

NO: include in scheduled responsible disclosure/reporting process

        ↓

Security Council triage

        ↓

Remediation owner assigned

        ↓

The maintenance team, implementation team, wallet team, or repository steward acts

        ↓

Patch, mitigation, configuration change, documentation, or release

        ↓

STAG validates the resolution.

        ↓

Security Council confirms closure

        ↓

Public reporting where safe, with sensitive details withheld until resolved

        ↓

Monthly or milestone reporting to DReps and the community


This is also how STAG complements the maintenance contract. Where a finding requires code changes, hot fixes, release management, or operational response, that work belongs to the relevant maintainer or maintenance function. STAG’s role is to detect, verify, escalate, and validate. It should not consume STAG funds to perform maintenance work already covered elsewhere.

#### Feedback 8 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1dea08038cf72ed1e64f24
- Summary (EN): Proposer responds to the suggestion that a bug bounty would be preferable, arguing bug bounties and dedicated red teams are complementary (citing Ethereum and Solana running both) and that bounties are reactive, lack systematic full-stack coverage, and cannot do cross-implementation divergence analysis.
- Summary (JA): 提案者は、バグバウンティの方が望ましいという指摘に対し、バグバウンティと専門のレッドチームは補完的だ(EthereumやSolanaが両方を運用していると引用)と反論し、バウンティは反応的でフルスタックの体系的カバレッジを欠き、実装間の乖離分析もできないと主張している。

Full text:

4. How STAG differs from the Bug Bounty Program

Your review includes a comment from a developer that this work would be better funded as an outcome-based bug bounty rather than a large up-front grant, on the basis that bug bounties also incentivise teams other than the proposer to perform security validation.

This is a reasonable design question, and we want to address it directly. Bug bounties and dedicated red teams are not substitutes — they are complementary, as the structure of Ethereum's and Solana's security infrastructure demonstrates. Ethereum operates both a dedicated internal red team (EF Security) and a $1,000,000 maximum bug bounty. Solana operates both a foundation security incident-response function and a $2,000,000 bounty. Neither ecosystem treats the bounty as a replacement for the dedicated team.

A bug bounty is reactive and probabilistic. It invites external researchers to report what they happen to find, rewards valid reports, and provides a triage path. It does not generate systematic coverage of the full stack, it cannot direct attention to the highest-risk areas, and it cannot perform the cross-implementation divergence analysis that STAG's WP4 is specifically designed to deliver - work that requires deep comparative knowledge of multiple node codebases simultaneously and that no external researcher is positioned to conduct.

...

#### Feedback 9 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1dea265141bb70a939dbb2
- Summary (EN): Proposer tabulates differences between the Bug Bounty Program and STAG (model, who finds issues, trigger, scope, incentive, output) and argues per-finding payment incentives create pressure to delay disclosure, whereas STAG's milestone funding makes the 24-hour disclosure SLA credible.
- Summary (JA): 提案者はバグバウンティプログラムとSTAGの違い(モデル、発見者、トリガー、スコープ、インセンティブ、成果物)を表で示し、発見ごとの報酬は開示の遅延を促す圧力を生むが、STAGのマイルストーン型資金は24時間開示SLAを信頼できるものにすると主張している。

Full text:

...
A simple way to distinguish the two:

Model

- The Bug Bounty Program is a reactive disclosure programme.
- STAG is proactive adversarial assurance.

Who finds issues

- Under the Bug Bounty Program, issues are found by external researchers and community contributors.
- Under STAG, issues are found by a dedicated expert consortium.

Trigger

- The Bug Bounty Program is triggered when someone submits a report.
- STAG is triggered by continuous planned security work.

Scope

- The Bug Bounty Program applies to defined eligible systems and repositories.
- STAG applies to full protocol-stack risk analysis as defined in the proposal.

Incentive

- The Bug Bounty Program rewards valid vulnerabilities.
- STAG is a funded programme with milestone reporting.

Output

- The Bug Bounty Program produces validated vulnerability reports and rewards.
- STAG produces threat models, findings, test artefacts, reports, escalation, and validation.

Relationship between the two

- STAG findings may enter the same responsible disclosure and triage pathway where appropriate.
- The Bug Bounty Program remains a public intake channel for independent vulnerability reports.

There is also a specific structural problem with applying outcome-based bug bounty design to responsible disclosure of critical vulnerabilities in live infrastructure. A per-finding payment incentive creates pressure to delay disclosure until payment is confirmed — exactly the wrong dynamic for a programme whose core commitment is to report critical findings to the Security Council within 24 hours of discovery. STAG's milestone-based funding structure is not incidental to its design; it is what makes the 24-hour disclosure SLA credible.

To avoid any ambiguity, STAG-funded findings should not also be claimed as bug bounty rewards by STAG consortium members. The Bug Bounty Program remains available to independent external researchers, while STAG provides the ecosystem with a dedicated continuous assurance function.

#### Feedback 10 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1dea3f7d5f66c5487662a9
- Summary (EN): Proposer explains the Month 6 and Month 12 governance checkpoints are active opt-out mechanisms (mandatory 30-day review, published assessments, termination vote, return of undisbursed ADA) and justifies the 18-month structure as needed for security continuity across hard forks rather than to avoid scrutiny.
- Summary (JA): 提案者は6か月目と12か月目のガバナンスチェックポイントが能動的なオプトアウト機構(必須の30日レビュー、評価の公開、解約投票、未払いADAの返還)だと説明し、18か月構造はハードフォークを跨ぐセキュリティの継続性のために必要であり監視を回避するためではないと正当化している。

Full text:

5. On milestone-gated disbursement

Your rationale notes a preference for six-month tranches with explicit DRep re-approval over the current 18-month commitment with opt-out checkpoints. We agree the distinction matters and want to be clear about how the opt-out mechanism works in practice.

The Month 6 and Month 12 governance checkpoints are not passive. Failure to meet either the severity-weighted finding impact score or the Cardano security posture score interim targets triggers a mandatory 30-day review, with full published materials — Ensurable Systems' account, the Security Council's independent assessment, and the community's right to call a termination vote. Undisbursed ADA is returned to the treasury on termination. The programme does not disburse 18 months of funding upfront; drawdown occurs at milestone completion as administered by Intersect.

We chose 18 months rather than sequential 6-month funding cycles deliberately, and the rationale is set out in full in Section 1 of the proposal. Security assurance of complex evolving infrastructure requires continuity across hard forks and protocol upgrades; a 12 or 6-month cycle front-loads setup cost and leaves insufficient time to iterate on findings and re-test after fixes are applied. The community retains full exit rights at Month 6 and Month 12; the 18-month structure is about delivery effectiveness, not about insulating the programme from governance scrutiny.

#### Feedback 11 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1dea6dceb7fef00be0e503
- Summary (EN): Proposer restates its closing position that Ensurable Systems' maintenance role does not overlap with its STAG focus areas, that the other three consortium members have no maintenance involvement, and that maintenance and STAG are distinct functions.
- Summary (JA): 提案者は締めくくりの立場として、Ensurable Systemsのメンテナンス役割はSTAGの注力領域と重複せず、他の3つのコンソーシアムメンバーはメンテナンスに関与しておらず、メンテナンスとSTAGは別個の機能だと改めて述べている。

Full text:

6. Closing position


We understand and respect the transparency-first governance concern your rationale raises. It is a fair concern, and we have tried to address it as specifically as we can.

To summarise what we can now say clearly: Ensurable Systems' role in the Maintenance Initiative covers technical coordination, release management, performance evaluation, and design input — not independent adversarial security analysis. Ensurable Systems' STAG focus areas (wallet, UPLC, compiler toolchain) do not overlap with that scope. QuviQ, PNSol, and Well Typed have no involvement in the Maintenance Initiative. We believe the functional scope separation is sufficient for evaluation but acknowledge that judgement belongs to DReps.

However, the work itself is distinct. Maintenance is about keeping Cardano’s infrastructure running, maintained, released, and repaired. STAG is about independently finding and escalating the vulnerabilities that normal maintenance, bug bounty submissions, and single-client reviews may miss.

...

#### Feedback 12 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e90478d699758cde5d4a5e#comment-6a1dea785141bb70a939dbb3
- Summary (EN): Proposer lists seven explicit boundary statements (STAG does not perform production maintenance, does not replace the bug bounty, does not duplicate IO security work, etc.) and argues the ecosystem needs multi-client cross-implementation security assurance.
- Summary (JA): 提案者は7つの明確な境界の主張(STAGは本番メンテナンスを行わない、バグバウンティを置き換えない、IOのセキュリティ作業を重複しない等)を列挙し、エコシステムには複数クライアントの実装横断的なセキュリティ保証が必要だと主張している。

Full text:

...

The strongest way to address the concern is not to collapse STAG into maintenance but to make the boundaries explicit:

1. STAG does not perform production maintenance under this budget.
2. STAG does not replace the Bug Bounty Program.
3. STAG does not duplicate IO’s internal security or maintenance work.
4. STAG delivers independent adversarial assurance across the full protocol stack.
5. Findings are escalated to the Security Council and relevant maintainers for resolution.
6. Work package budgets, partner-level effort allocations, and milestone reporting provide the accountability layer.
7. Month 6 and Month 12 opt-out checkpoints give DReps governance control if delivery is not meeting expectations.

The category – multi-client cross-implementation security assurance for a protocol with billions of dollars of value at stake and multiple node implementations approaching production - is one we believe the ecosystem genuinely needs. We hope this response gives DReps the information they need to evaluate STAG on its actual scope and merits.

---

## 12. Cardano Startup Mainnet Runway (CSMR)

- Proposal ID: 69fdc4a5b05ff80adc7d5c62
- Requested: 6,200,600 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdc4a5b05ff80adc7d5c62

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. At present, I do not think you have fully demonstrated evidence of demand that would generate Tx commensurate with this investment amount.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。現状、当投資額に見合うTxを生み出す需要の証拠を示しきれていないと思います。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdc4a5b05ff80adc7d5c62#comment-6a0c8fa60dcaa7f9767cd51c
- Summary (EN): Targeted edits: C6 removes the sub-cent micropayment example, replacing with four economically-viable integration paths (compliance receipts, Cardano-native payments, verifiable credentials, smart contract settlement). C9 defines on-chain tx precisely as L1 mainnet. C1 adds hard quality gate: 500 L1 tx in 30 days, 10+ wallets, ≥1 paying external customer, 60-day retention.
- Summary (JA): ピンポイントの修正: C6で1セント未満マイクロペイメント例を削除し、経済的に成立する4経路 (コンプライアンス受領証、Cardano-nativeペイメント、検証可能クレデンシャル、スマートコントラクト決済) に置換。C9でオンチェーンtxをL1メインネットと厳密定義。C1にハードな品質ゲート (30日で500 L1 tx、10+ wallet、外部有償顧客1+、60日間リテンション確認) を追加。

Full text:

Thank you for the detailed rationale. We have read it carefully and made targeted changes to address each point.

On C6: you are correct that sub-cent micropayments are not economically viable on Cardano L1 at current fee levels. The proposal over-indexed on a specific payment protocol example, which created a misleading impression about the primary transaction generators. We have removed that framing entirely. CSMR's four integration pathways are now: on-chain compliance receipts, Cardano-native payment infrastructure, verifiable credentials, and smart contract settlement. All four generate L1 transactions at fee-to-value ratios that are economically viable on Cardano today. The proposal is explicitly technology-neutral on which Cardano-native payment approach cohort companies use.

On C9: the proposal now defines on-chain transactions precisely as L1 Cardano mainnet transactions. Any L2 activity would be reported separately and excluded from the primary KPI. The capital efficiency metric is now unambiguous.

On C1: WP3 now includes hard transaction quality thresholds — 500 on-chain transactions within 30 days, from 10+ distinct wallet addresses, with at least one paying external customer, confirmed by a 60-day retention check. This directly addresses the bot-padding and self-generation concern.

We would welcome a re-review against your voting criteria after these changes. Happy to answer any follow-up questions here.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdc4a5b05ff80adc7d5c62#comment-6a17fc910dcaa7f9767cd57a
- Summary (EN): Asks for re-categorization: with x402 removed, CSMR is a startup onboarding program (BD-network class). Under YUTA's own framework, BD/adoption proposals exclude C6 and have a different C9 bar. Target companies use compliance/credential anchors economically viable at ~0.17 ADA per event.
- Summary (JA): 再カテゴライズ要請: x402削除後のCSMRはBDネットワーク型のスタートアップ・オンボーディング・プログラム。YUTAの枠組み自体ではBD/採用型はC6対象外でありC9の基準も異なる。対象企業は ~0.17 ADA/eventで経済的に成立するコンプライアンス・クレデンシャル系を使う。

Full text:

One additional point we should have made more explicitly: the NO vote is driven by the "speculative finance / x402 micropay" categorization. That categorization no longer applies to the updated proposal — x402 has been removed entirely.

CSMR is a startup onboarding program. We find European companies with existing paying customers, pay them milestone-gated stipends to integrate Cardano into their existing product, and verify the result in on-chain transactions. Under your own framework, BD network and adoption program proposals exclude C6, and the C9 bar is different.

The companies we are targeting do not care about Cardano specifically. A compliance tool anchoring GDPR audit logs on-chain does not need sub-cent fees or sub-second finality — it needs tamper-proof timestamping at \~0.17 ADA per event, which is economically sound. A verifiable credential issued to a merchant costs one transaction. These are the actual use cases, not agent micropayments.

If you re-read the updated proposal as an onboarding program rather than a payment protocol play, we believe it does not trigger C6 under your framework at all. We would genuinely welcome your view on the re-categorization.

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdc4a5b05ff80adc7d5c62#comment-6a1db3515141bb70a939dbae
- Summary (EN): Proposer argues the proposal should be re-categorized from speculative finance/x402 to BD network/startup onboarding (x402 having been removed), which under YUTA's own framework excludes the decisive C6 criterion, and re-applies criteria C1-C9 to argue the BD-network categorization yields a different verdict.
- Summary (JA): 提案者は、x402が削除されたため本提案を投機的金融/x402からBDネットワーク/スタートアップオンボーディングへ再分類すべきだと主張し、YUTA自身のフレームワークではこれにより決定的なC6基準が除外されるとし、C1〜C9を再適用してBDネットワーク分類では異なる判定になると論じている。

Full text:

Thank you for the June 2nd re-review commitment. 

One structural point we believe warrants reconsideration before then.

The current rationale applies C1, C3, C6, C9 under "speculative finance / x402 micropay." x402 has been fully removed. The correct category is BD network / startup onboarding.

Per your own framework, C6 is explicitly excluded from BD network proposals. It applies to "high-frequency interactive use cases (orderbook, x402 micropay, agent commerce)" -- not to programs where companies anchor compliance events or issue credentials on Cardano. That exclusion removes the decisive NO criterion.

Re-applying your framework to BD network:

C1 (applies): Target is 51,700 tx/month = 6.5% of the 800K baseline, above your 1% materiality threshold. Hard quality gate: 500 L1 tx in 30 days, 10+ distinct wallets, 1+ paying external customer, 60-day retention check. Bot-padding concern is directly addressed.

C2 (applies): You cited NMA positively in your CBDAO rationale: "NMA: Active Masumi engagement since Oct 2024 (per Masumi public docs + per Intersect TW where Masumi has 28.7K tx footprint)." That is our Cardano-native track record.

C3 (applies): Milestone payments release only against verified L1 tx count, wallet diversity, and paying customer confirmation. These are outcome KPIs, not process metrics.

C4 (applies to BD network): Excess ADA above USD-capped milestone value returns to Treasury by contract. Undelivered milestones = unreleased funds. Milestone-gating is the return mechanism.

C7 (applies): NMA is not a fund allocator. Companies receive stipends directly via Intersect smart contract. No self-voting structure.

C9 (applies): Thesis is validated. GRID profiles 25,000+ EU startups. Cohort candidates pre-qualified. Named integration partners: Anastasia Labs and TxPipe.

The updated proposal does not trigger C6 under your framework. 

We believe a BD network re-categorization results in a different verdict.

---

## 13. Cardano Tooling DAO

- Proposal ID: 69fb466181aade1f18481c1e
- Requested: 6,180,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb466181aade1f18481c1e
- Category: Secondary grant DAO
- Applicable criteria: C2, C5, C7, C11
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. (See the Cardano Builder DAO entry above.)

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 (Cardano Builder DAO のコメントを参照)

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the reply. I do not trust a mechanism in which participants vote on each other, nor undefined council members. You say voting is currently underway, but I checked the linked page and could not tell who has been elected or who the council members currently are. I was also unable to obtain data demonstrating a causal relationship between past Tx increases and the funding provided.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返信をありがとうございます。私は参加者同士が投票し合う仕組みや、あるいは未定義のcouncilメンバーを信頼しません。現在投票中とのことですが、リンク先を確認しましたが誰が選出され現在誰がcouncilなのかわかりませんでした。また過去のTx増加と資金提供の因果関係を示すデータを入手できませんでした。

### Prior detailed analysis (EN)

**Categorisation**: [Secondary grant DAO]. Non-applicable: C1, C3, C4, C6, C8 (no prior Tooling DAO cycles to attribute), C9, C10.

**Applicable: C2, C5, C7, C11**. Applying:

• **C5 — Functional duplication with CBDAO framework**: Proposal explicitly states (per proposal text): 'Cardano Builder DAO was the first successful pilot implementation of the Initiative DAO framework' — replicating CBDAO's framework for the tooling vertical. Given CBDAO's empirical outcome (per /cbdao-tracker measurement: most funded projects held positions independent of CBDAO funding; 3 of 14 R1-funded projects in top 38; Masumi possibly excepted), justification for replicating same structural pattern in tooling vertical does not hold.

• **C2 — Track record as judge (member-builders self-voting, not DRep judges)**: Members are builders / tooling-project contributors (inherited from CBDAO Initiative DAO framework where members vote on each other's proposals — 2025 R1+R2 operated this way). Distribution decision-makers and recipients overlap by design. 'Builder DAO experience' is claimed as basis but this is distinct from a measurable success record of judgment outcomes. A fixed expert team with measurable judgment track record (e.g., Y Combinator, Techstars) could be entrustment-eligible — Tooling DAO is not.

• **C7 — CoI without enforceable safeguards**: Members self-vote on each other's proposals (per proposal mechanic). Self-voting is a structural CoI without explicit safeguards (exclusion thresholds, allocation caps for member-affiliated projects, independent review).

• **C11 — Default-NO criteria check**:
  - (a) Fixed expert team: ✗ rotating members
  - (b) Operating overhead ≤10%: must check, but typical Initiative DAO framework targets 15-25%
  - (c) No self-voting: ✗ self-voting allowed
  Fails 2 of 3 exception conditions.

• **C5 (additional) — Two-step funding removes DRep oversight (DRep-capacity constraint, not tooling)**: Direct TW is straightforwardly auditable within a typical DRep attention budget (one recipient, one set of deliverables). **A secondary-grant DAO splits visibility into two layers**, both practically unobservable to individual DReps — **not because tooling is missing** (CBDAO has dashboards, Catalyst has long-running ones, Tooling DAO will likely include one), **but because DReps are an unspecified mass of mostly-unpaid volunteers with day jobs whose governance attention is bounded by personal time/resources**. Core attention goes to on-chain GAs; continuously tracking a secondary DAO's per-cycle allocation decisions across dozens of downstream proposals — even with a usable dashboard — is outside what most DReps can fit in. Empirically: among DReps I have spoken with, **none can monitor Catalyst or CBDAO fund-allocation outcomes at the individual-recipient level**, AND the same constraint applies to verifying the secondary DAO's internal governance (member capture / allocation bias / self-dealing). Direct TW is structurally preferable. (Context: 17 active TWs request 259M ADA = 74.1% of 350M NCL if all ratified — direct TW path is actively used.)

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [二次配布 DAO]。 非適用: C1, C3, C4, C6, C8 (attribute する prior Tooling DAO cycle なし), C9, C10。

**適用: C2, C5, C7, C11**。 適用:

・**C5 — CBDAO framework との機能重複**: 提案書直接引用: 'Cardano Builder DAO was the first successful pilot implementation of the Initiative DAO framework' — CBDAO framework を tooling vertical に replicate。 CBDAO の empirical outcome (/cbdao-tracker measurement より: 大半の funded project は CBDAO 資金 independent に top tier; R1 funded 14 件中 3 件のみ top 38; Masumi 反例の可能性) を踏まえ、 同 structural pattern を tooling vertical に replicate する justification は成立せず。

・**C2 — 判定者としての track record (member-builders による self-voting、 DRep 判定者ではない)**: Members は builders / tooling-project contributor (CBDAO Initiative DAO framework から継承、 2025 R1+R2 で members が互いの提案に投票していた構造と同じ)。 配分判定者と受益者は design 上 overlap。 'Builder DAO experience' を基盤 claim するが、 measurable success record of judgment outcome とは distinct。 Measurable judgment track record を持つ固定専門 team (Y Combinator, Techstars 等) は entrustment-eligible 可能 — Tooling DAO は該当せず。

・**C7 — Enforceable safeguard なし CoI**: メンバーが互いの提案に self-vote (proposal mechanic より)。 Self-voting は明示的 safeguard (exclusion threshold, member-affiliated project への allocation cap, independent review) なしの構造的 CoI。

・**C11 — Default-NO 例外条件 check**:
  - (a) 固定専門 team: ✗ rotating member
  - (b) 運営費 ≤10%: 要確認だが典型 Initiative DAO framework は 15-25% target
  - (c) Self-voting なし: ✗ self-voting 許可
  3 例外条件のうち 2 つ不合格。

・**C5 (追加) — 2 段階 funding が DRep 監督を奪う (DRep-capacity 制約、 tooling 不在ではない)**: 直接 TW なら典型的 DRep attention budget 内で straightforwardly 監督可能 (受給者 1、 deliverable 1)。 **二次 grant DAO は可視性を 2 層に分け**、 両層とも individual DRep には実務上 observe 不可能 — **tooling が無いからではなく** (CBDAO にも dashboard あり、 Catalyst にも長年あり、 Tooling DAO にもおそらく含まれる)、 **DRep が不特定多数の、 ほぼ無償で本業のあるボランティアで、 governance attention が本人の時間/リソースに bound されているから**。 中核 attention は on-chain GA に向く; 二次 DAO の per-cycle 配分判断を数十の downstream 提案にわたって継続追跡することは、 使いやすい dashboard があっても大多数の DRep が時間的に収められない。 Empirically: 私が会話した DRep の中で **Catalyst や CBDAO の fund 配分 outcome を individual-recipient レベルで監督できている人は 1 人もいない**、 そして同じ制約が二次 DAO 内部 governance (member capture / allocation bias / self-dealing) の検証にも適用。 直接 TW が structurally 望ましい。 (Context: 17 active TWs が 259M ADA = NCL 350M の 74.1% を全 ratify 想定で請求中 — 直接 TW path は actively 使用されている。)

**Counter-evidence (2026-05-10 X community search)**: TapTools (146 pts) endorsed Tooling DAO: 'APIs, SDKs, explorers, analytics, and open-source tooling are critical infrastructure for the ecosystem'。 CardanoToolsDAO は 1M+ monthly visits + 1B+ API requests を claim。 これは C5 'CBDAO replication' 論が engage していなかった empirical usage。 **C7 (self-vote) + C11 (secondary-DAO restrictions) concern は依然 valid だが NO は too strong — NO-recommend-resubmit (scope に explicit CoI safeguards 付き) を推奨**。

よって本提案は依然これらを満たさない (但し scope 改訂で再考可能)。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb466181aade1f18481c1e#comment-6a0dbde1038cf72ed1e64ea7
- Summary (EN): Submits a full response document (docsend) explicitly written against YUTA's bar. Promises to engage on merits, concede where YUTA is right, and put concrete structural commitments on the table.
- Summary (JA): YUTAの基準に沿った全文回答 (docsend) を提出。論点ごとに是々非々で対応し、YUTAが正しい部分は認め、具体的な構造的コミットメントを提示すると宣言。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C5, C7, C11).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Yuta, thank you for the depth of your Budget #69 analysis. As with the Cardano Builder DAO response, this document is written against the bar you have set in your rationales, not below it. We will engage on the merits, concede where you are right, and put concrete structural commitments on the table where we can.

Full Response: https://docsend.com/view/57m4484nwhiy5gk6

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb466181aade1f18481c1e#comment-6a1ddf645141bb70a939dbb0
- Summary (EN): Proposer says it worked with the builder DAO to address concerns about the DAO framework and links to the shared collective response.
- Summary (JA): 提案者はビルダーDAOと協力してDAOフレームワークへの懸念に対応したと述べ、共有された共同回答へのリンクを示している。

Full text:

Hi Yuta,

We have worked with the builder DAO to address your concerns regarding the DAO framework.

You can view the response here or on the builder DAO proposal comments: Hi Yuta,

Thank you for your commitment to Cardano Governance. We have worked together as a DAO to respond to your current rationale.

Response here: [https://docsend.com/view/yrf3kyv59xebqgit](https://docsend.com/view/yrf3kyv59xebqgit)

---

## 14. DeltaDeFi: Cardano Flagship Exchange: 5,000,000 Treasury Loan with Perpetual Upside

- Proposal ID: 69f70e22ae91c89d30570211
- Requested: 5,150,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f70e22ae91c89d30570211
- Category: dApp - DeFi
- Applicable criteria: C1, C4, C6, C9
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Excellent team with strong Hydra expertise, but no demand evidence for a hybrid CEX/DEX form factor has been presented so far.

### Voting reason (JA, as of 2026-05-28)

素晴らしいチームで Hydra の知識に長けていることは間違いないが、 現在のところ CEX と DEX の中間形態の需要の証拠を提示できていない。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on DeltaDeFi: Cardano Flagship Exchange ₳5M Treasury Loan with Perpetual Upside (**5.15M ADA / NCL 1.47%**).

**Main reasons**

**1. The previous draft was rejected — and the current ask is 3.3x larger**
- Prior version: ₳1.5M over 6 months, rejected with ~82.6% of DRep voting power against.
- Current version: ₳5M over 24 months — **3.3x larger ask** than the rejected draft.
- The proposer cites changes addressing five common objections (repayable loan + concrete liquidity milestones + decentralisation milestones + KPI dashboard removed + 3-month mainnet evidence).
- But scaling the ask 3.3x while addressing objections is a structural mismatch.

**2. Live mainnet metrics — modest scale**

| Metric | Value |
|---|---|
| Mainnet since | Cardano Summit 2025 (~7 months at evaluation time) |
| In-house market-making capital | **$20,000** |
| Best ADA execution price | 20 bps spread on ADA/USDCx |
| Cumulative matched volume | **$607,000** |
| Active traders | **169** |

$607K cumulative volume in 7 months ≈ $86K/month = $2.9K/day. 169 active traders is a small power-user community, not retail scale. The 20 bps ADA/USDCx spread is competitive, but the volume scale is below typical exchange listing thresholds.

**3. Hydra-based order book is innovative but stacks execution risk**
- DeltaDeFi uses Hydra L2 for a low-latency order book.
- Hydra production maturity is itself still in progress (per ADAtool /hydra-demo page, hydra-node 2.0.0 deposit-based heads as of 2026-04-28).
- Building a flagship order book on an emerging L2 stack is compound execution risk.

**4. Loan terms: perpetual upside is interesting but depends on volume growth**

| Term | Detail |
|---|---|
| Loan principal | ₳5,000,000, disbursed across 24 months in two pools |
| Repayment trigger | 50% of retained trading fees remitted monthly until ₳5M repaid |
| Post-repayment | 15% of retained trading fees in perpetuity to ADA holders |
| Administrator | Intersect via 2025 TRSC framework with third-party assurer |

The perpetual upside is a positive structural commitment. But repayment depends on DeltaDeFi actually generating fee revenue, and current revenue ($607K over 7 months) produces minimal fee remittance.

**5. Repayment math at current state**
- Current monthly volume $86K × typical 30 bps round-trip fee = ~$260/month fee revenue.
- $260/month × 50% Treasury repayment share = $130/month → repaying ₳5M (~$1.25M USD) at $130/month would take 800+ years at current state.
- Volume must grow 10-100x for repayment to be plausible. Order-book DEX volume growth depends on liquidity attracting more liquidity — and $607K cumulative is below the threshold that typically starts that flywheel.

**Recommend resubmission** with: (a) ask size matched to current evidence ($607K volume / 169 traders supports a smaller-scope pilot, not ₳5M), (b) volume-growth milestone gates so Treasury can halt disbursement if thresholds are not met, (c) Hydra-readiness contingency clause, (d) historical burn rate vs runway clarification.

*The model (repayable loan + perpetual revenue share to ADA holders) is structurally interesting and Cardano-aligned. The ask size is what is mismatched to current evidence.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — DeltaDeFi: Cardano 旗艦 DEX ₳5M トレジャリーローン(永続還元付き)(**5.15M ADA / NCL 1.47%**)に NO(再提出推奨)。

**主な理由**

**1. 前回案は否決済み。今回案は要求額が 3.3 倍**
- 前回:₳1.5M / 6か月。DRep 投票力 約 82.6% の反対で否決。
- 今回:₳5M / 24か月。否決された案の **3.3 倍の要求額**。
- 提案者は5つの代表的な反対意見への対応(返済可能なローン + 具体的な流動性マイルストーン + 分散化マイルストーン + KPI ダッシュボード削除 + 3か月のメインネット実績)を挙げている。
- ただし、反対意見に応えつつ要求を 3.3 倍にするのは構造的にちぐはぐ。

**2. メインネット指標は控えめ**

| 指標 | 値 |
|---|---|
| メインネット開始 | Cardano Summit 2025(評価時点 約7か月) |
| 自社マーケットメイク資本 | **$20,000** |
| ADA の最良執行 | ADA/USDCx で 20 bps スプレッド |
| 累積マッチ量 | **$607,000** |
| アクティブトレーダー | **169 名** |

7か月で累積 $607K ≒ 月 $86K = 日 $2.9K。アクティブ 169 名はパワーユーザー層で、リテール規模ではない。20 bps の ADA/USDCx スプレッドは競争力があるが、規模が通常の取引所上場の閾値より低い。

**3. Hydra ベース板取引は革新的だが、実装リスクが重なる**
- DeltaDeFi は低遅延板取引に Hydra L2 を使う。
- Hydra 本番成熟は進行中(ADAtool /hydra-demo より、2026-04-28 時点で hydra-node 2.0.0 デポジット型ヘッド)。
- 立ち上げ途中の L2 スタックの上に旗艦の板取引を構築するのは、実装リスクの直列接続。

**4. ローン条件:永続還元は興味深いが、出来高成長次第**

| 項目 | 内容 |
|---|---|
| 元本 | ₳5,000,000、24か月にわたり2プールで支給 |
| 返済トリガー | ₳5M 完済まで、保持手数料の 50% を月次送金 |
| 完済後 | 保持手数料の 15% を ADA 保有者に永続還元 |
| 管理者 | 2025 TRSC 枠組み + 第三者保証付き Intersect |

永続還元は前向きな構造的コミット。ただし返済は DeltaDeFi が実際に手数料収入を生むことに依存し、現状(7か月で $607K)の収益では送金額が極小。

**5. 現状での返済計算**
- 月 $86K × 一般的な往復 30 bps = 月 約 $260 の手数料収入。
- $260/月 × トレジャリー側 50% = $130/月。₳5M(≒ $1.25M USD)を $130/月で返すと現状ペースで 800+ 年。
- 返済計算が妥当になるには出来高が 10-100 倍成長する必要がある。板取引 DEX の出来高は流動性が流動性を呼ぶ循環に乗ってから伸びる。累積 $607K は通常その循環が回り始める閾値の下。

**再提出推奨**:(a) 現状実績に見合う要求額($607K の出来高 / 169 名なら小規模パイロット相当で ₳5M ではない)、(b) 閾値未達なら出金を止められる出来高マイルストーンゲート、(c) Hydra の成熟に応じたスコープ転換条項、(d) 過去のバーンレートとランウェイの説明。

*仕組み(返済可能ローン + ADA 保有者への永続収益分配)は構造的に興味深く、Cardano と整合している。問題は現状実績に対して要求額が大きすぎる点。*

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 15. Paid Open Source Model - Continued

- Proposal ID: 69ea4790d73bae0eb2a99522
- Requested: 4,601,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522
- Category: Governance coordination
- Applicable criteria: C3, C5, C8, C11
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

It is fatal that a 'Continued' proposal does not quantitatively articulate the outcomes of the prior round.

### Voting reason (JA, as of 2026-05-28)

「Continued」の提案書で過去の成果が定量的に明確に記載されていないのは致命的です。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Let me ask frankly. Regarding the previous underspend, the OSC itself cites as causes "insufficient applications" (in the Treasury Repayment field) and "processing delays by the Administrator (Intersect)." In light of this, just three points.
1. If insufficient applications were the main cause, why are you requesting the same scale again this time (40 Maintainers, 20 Tooling items)? Where is the new mechanism to generate demand?
2. Why are you maintaining Intersect-as-Administrator again this time, when it was the delay factor? Apart from adding reporting and auditing on top, is there any element that structurally changes execution?
3. The designers of POSM/OSPO have put forward a replacement proposal (dOSPO) on the grounds that "structural problems cannot be solved internally." How do you respond to this? Why "continuation" rather than "redesign"?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。率直に伺います。前回の未消化について、OSC ご自身が原因として「申請不足」(Treasury Repayment 欄)と「Administrator(Intersect)の処理遅延」を挙げておられます。これを踏まえ、3点だけ。
1. 申請不足が主因なら、なぜ今回も同じ規模(Maintainer 40名・Tooling 20件)を要求するのですか。需要を生み出す新しい仕組みはどこにありますか。
2. 遅延要因である Intersect-as-Administrator を今回も維持するのはなぜですか。報告・監査の上乗せ以外で、執行を構造的に変える要素はありますか。
3. POSM/OSPO の設計者が「内部では構造的問題を解決できない」として置き換え提案(dOSPO)を出しています。これにどうお答えになりますか。なぜ「再設計」ではなく「継続」なのでしょうか。

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on Paid Open Source Model - Continued (OSC/OSO, **4.6M ADA / NCL 1.31% over 18 months**).

**Main reasons**

**1. Secondary-grant structure with double-funding risk**

OSC/OSO is a meta-funding entity: it receives Treasury funds and redistributes to ecosystem partners. Per proposal text, named partners in the 2025 cycle include:
- **TxPipe** (also receiving direct Treasury Withdrawals + Budget #69 Year-2 maintenance asks)
- **Andamio**
- **STORM Partners**
- **Chinstrap Community**

Double-funding risk: TxPipe receives 2025 OSC pass-through + direct TW + Budget #69 maintenance proposals + the new Tx3 proposal. Without explicit per-channel separation, a DRep cannot verify non-overlap.

**2. Scope definition is vague at the aggregate level**

| Strategic objective | What is concretely promised |
|---|---|
| Sustainable open-source development | "Structured funding for maintainers, maintainer needs, and critical tooling" — not enumerated |
| Security and risk mitigation | "Bug bounties and incident monitoring" — overlaps with the Security Council |
| Developer pipeline and retention | "Developer Advocacy and related working groups" — overlaps with Intersect MBO |
| Ecosystem stability | "Strategic events + dev metrics tracking + public reporting" — overlaps with Intersect MBO |

- No itemised maintainer list with proposed allocation.
- No per-objective budget breakdown.
- A DRep cannot evaluate whether 4.6M ADA matches scope.

**3. Scope overlap with parallel Intersect / TxPipe proposals**

| OSC/OSO scope | Parallel Budget #69 proposal | Overlap question |
|---|---|---|
| "Structured funding for maintainers" | TxPipe Y2 maintenance bundle (Pallas + UTxO RPC + Dolos + Oura, ~2.16M ADA combined) | Are these maintainers funded twice? |
| "Critical tooling" | MLabs Core Tool Maintenance (Plutarch + Ply, 1.14M ADA) | Already direct-funded? |
| "Bug bounties + incident monitoring" | Intersect MBO budget includes Security Council + Bug Bounty | OSC funds the same? |
| "Developer Advocacy" | Intersect MBO budget covers technical workshops | OSC adds incremental? |

The proposal mentions a "Developer Advocate program paid in ADA" which distinguishes one specific feature, but the broader scope-overlap question is unanswered.

**4. Performance-based language without concrete KPIs**
- "Performance-based open-source sustainability" is stated.
- No specific metric ties (maintainer-week delivery? bug-fix throughput? tooling-uptime SLA? CI pass rates?).
- 18-month duration with no milestone disbursement framework specified.

**5. 2025 cycle outcomes are not enumerated**
- Proposal is "continued" — implying a 2025 cycle predecessor was funded.
- The proposal does not enumerate: which maintainers got funded in 2025, what they delivered, conversion of OSC funding to upstream-merged contributions, attrition rate of funded maintainers.
- Without 2025 outcome data, a DRep cannot evaluate whether 2026 continuation is justified or what scope adjustments are appropriate.

**Recommend resubmission** with: (a) per-maintainer / per-ecosystem-partner allocation table, (b) explicit non-overlap with TxPipe Year-2 / MLabs Core Tool Maintenance / Intersect MBO scopes, (c) 2025-cycle outcome enumeration (funded maintainers + deliverables + conversion to upstream PR merges), (d) milestone-gated disbursement schedule for the 18-month period.

*The OSC/OSO model is structurally valuable. NO-resubmit reflects the transparency and non-overlap gap, not opposition to paid open-source funding as a category.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — Paid Open Source Model - Continued(OSC/OSO、**4.6M ADA / NCL 1.31% / 18か月**)に NO(再提出推奨)。

**主な理由**

**1. 二次配分構造で二重資金リスクあり**

OSC/OSO はメタ配分主体:トレジャリー資金を受領し、エコシステムパートナーに再配分する。2025 サイクルの名前付きパートナー(提案書本文):
- **TxPipe**(Treasury Withdrawal 直接受領 + Budget #69 Y2 保守要求も並行)
- **Andamio**
- **STORM Partners**
- **Chinstrap Community**

二重資金リスク:TxPipe は 2025 OSC 経由の配分 + Treasury Withdrawal 直接 + Budget #69 保守提案 + 新規 Tx3 提案を並行で受け得る。チャネルごとの切り分けがないと、DRep は重複なしを検証できない。

**2. スコープ定義が大まかすぎる**

| 戦略目標 | 具体的に約束されているもの |
|---|---|
| 持続可能なオープンソース開発 | 「保守者、保守者のニーズ、重要ツールへの構造化された資金」— 列挙なし |
| セキュリティとリスク低減 | 「バグバウンティとインシデント監視」— セキュリティカウンシルと重複 |
| 開発者パイプラインと定着 | 「Developer Advocacy と関連ワーキンググループ」— Intersect MBO と重複 |
| エコシステムの安定 | 「戦略イベント + 開発指標の追跡 + 公開報告」— Intersect MBO と重複 |

- 保守者の項目別リストと配分の明示なし。
- 目標ごとの予算分けなし。
- 4.6M ADA が範囲と見合うかを DRep が評価できない。

**3. 並行する Intersect / TxPipe 提案とのスコープ重複**

| OSC/OSO の範囲 | 並行 Budget #69 提案 | 重複に関する疑問 |
|---|---|---|
| 「保守者への構造化された資金」 | TxPipe Y2 保守バンドル(Pallas + UTxO RPC + Dolos + Oura、合計 約 2.16M ADA) | 同じ保守者が二重で支援される? |
| 「重要ツール」 | MLabs コアツール保守(Plutarch + Ply、1.14M ADA) | 既に直接資金提供? |
| 「バグバウンティ + インシデント監視」 | Intersect MBO 予算にセキュリティカウンシル + バグバウンティ | OSC が同じものに資金? |
| 「Developer Advocacy」 | Intersect MBO 予算がテクニカルワークショップを含む | OSC が追加で何を入れる? |

提案書には「ADA で支払う Developer Advocate プログラム」の言及があるが、これは1つの具体機能の区別であり、広い範囲の重複問題は未解決。

**4. パフォーマンスベースを掲げるが、具体的 KPI なし**
- 「パフォーマンスベースのオープンソース持続性」と謳う。
- 具体的な指標との紐付けがない(保守者週次の納品?バグ修正のスループット?ツールの稼働 SLA?CI 通過率?)。
- 18 か月期間でマイルストーン出金の枠組みが未指定。

**5. 2025 サイクルの結果が列挙されていない**
- 提案は「継続」とされ、2025 サイクルに先行案件があったことを含意。
- 提案書は列挙していない:2025 で資金を受けた保守者、その納品物、OSC 資金から上流へのマージ貢献への転換率、資金提供を受けた保守者の離脱率。
- 2025 の結果データなしには、DRep は 2026 継続の妥当性や範囲調整を評価できない。

**再提出推奨**:(a) 保守者 / エコシステムパートナーごとの配分表、(b) TxPipe Y2 / MLabs コアツール保守 / Intersect MBO との範囲の明示的な非重複、(c) 2025 結果の列挙(資金を受けた保守者 + 納品 + 上流 PR へのマージ転換)、(d) 18 か月期間のマイルストーン段階払い計画。

*OSC/OSO モデル自体は構造的に有用。NO 再提出は透明性と非重複の不足を反映しており、カテゴリへの反対ではない。*

### Proposer feedback (6)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522#comment-6a1e036b5141bb70a939dbb5
- Summary (EN): Proposer (OSC) clarifies that no entity has guaranteed funding under POSM, detailing that TxPipe received ~44k ADA for a one-off GitHoney tool modification, that STORM Partners and Chinstrap have no dedicated funding (Accelerator not active), and that Andamio's platform fees are capped at under 500 ADA/month (1/6).
- Summary (JA): 提案者(OSC)はPOSMの下でいかなる事業体にも保証された資金はないと明確化し、TxPipeはGitHoneyツールの一回限りの改修で約44k ADAを受領したこと、STORM PartnersとChinstrapには専用資金がない(アクセラレーターは未稼働)こと、Andamioのプラットフォーム料金は月500 ADA未満に上限設定されていることを詳述している(1/6)。

Full text:

> The OSC Proposal does not guarantee funding to any specific entity. In our proposal, the callout to organizations already working on Cardano was designed to show how Intersect OSC is working with the community to achieve a shared goal. Any specified value provided/awarded to any known entity is by contract for work that is specific to OSC programs and does not present any conflict of interest RE: active maintenance or development work.

TxPipe has been a partner engaged with explicit purpose and does not have any guaranteed funding under the Paid Open Source Model. For transparency: TxPipe received \~44k ADA to modify the GitHoney tool for potential use under the Bug Bounty Program. GitHoney has not been the target of any other treasury funding, and in the POSM Continued, there is currently no direct or promised funding for TxPipe.

[https://opensourcecommittee.docs.intersectmbo.org/about/paid-open-source-model-posm/bug-bounty-program/tx-pipe-contract-githoney](https://opensourcecommittee.docs.intersectmbo.org/about/paid-open-source-model-posm/bug-bounty-program/tx-pipe-contract-githoney)

As a result of this temporary partnership, the Cardano ecosystem has a solid tool in place to coordinate and act promptly and efficiently on potential vulnerabilities that can put in serious risk the Cardano core infrastructure.

STORM Partners and Chinstrap were potential partners via the Accelerator Program. The Accelerator program is not yet active and the funds may be returned, Therefore no dedicated funding has gone to these partners, nor is there a confirmed amount to which they would receive.

Andamio has supplied a functioning tool, a platform for which the OSC is able to more accurately manage micro-payments. Per exclusive agreement, the usage fees for the Andamio Platform, specific to the OSC use case were capped at a nominal figure which would award a max of >500 ADA per month (less than a Committee Member stipend)

1/6

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522#comment-6a1e03b7038cf72ed1e64f25
- Summary (EN): Proposer (OSC) responds to the vague-scope concern by explaining POSM is intentionally a programmatic framework rather than a fixed procurement contract, naming four operational areas and several programs with work packages, acceptance criteria, and phased funding, and meant to complement rather than replace governance bodies (2/6).
- Summary (JA): 提案者(OSC)はスコープが曖昧という懸念に対し、POSMは固定的な調達契約ではなく意図的にプログラム型のフレームワークだと説明し、4つの運用領域と、ワークパッケージ・受入基準・段階的資金を伴う複数のプログラムを挙げ、ガバナンス機関を置き換えるのではなく補完することを意図していると述べている(2/6)。

Full text:

> \*\*2. Scope definition is vague at the aggregate level\*\*

The concern regarding scope definition is understandable, however the Paid Open Source Model (POSM) is intentionally structured as a programmatic framework rather than a fixed procurement contract with fully predefined allocations.

The proposal identifies four primary operational areas: maintainer sustainability and tooling support, security and incident response coordination, developer onboarding and advocacy, and ecosystem reporting and strategic engagement. These areas are broad because the operational needs of an open source ecosystem change over time based on network upgrades, maintainer availability, security priorities, and ecosystem growth.

For that reason, the proposal does not attempt to permanently lock funding to a static list of maintainers or repositories at the aggregate proposal level. Instead, funding is expected to flow through defined programs, milestone reviews, reporting requirements, and ongoing oversight processes.

These programs do not operate without structure. Individual work packages, acceptance criteria, reporting expectations, and phased funding approaches are included throughout the proposal. Programs such as the Maintainer Retainer Program, Tooling Sustainability Program, Bug Bounty Program (Intersect), and Developer Advocate Program each define intended operational outcomes and areas of responsibility.

Regarding overlap concerns, the proposal is intended to support operational execution and ecosystem sustainability efforts that complement existing structures within Intersect and the broader Cardano ecosystem, rather than replace governance bodies or committee responsibilities.

2/6

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522#comment-6a1e03ce05e47100cbda5c53
- Summary (EN): Proposer (OSC) lists predefined costs (3k ADA/month per Community Maintainer, 5k ADA/month per Developer Advocate, $5k-$50k tooling support) and an 18-month runway with one Developer Advocate cohort and max 40 maintainers, stating the math aligns with minimal overage (3/6).
- Summary (JA): 提案者(OSC)は事前定義のコスト(コミュニティメンテナー1人あたり月3k ADA、Developer Advocate 1人あたり月5k ADA、ツール支援$5k〜$50k)と、Developer Advocate 1コホート・最大40名のメンテナーを擁する18か月のランウェイを列挙し、計算上の超過は最小限だと述べている(3/6)。

Full text:

> \*\*2. Scope definition is vague at the aggregate level\*\*

Predefined Costs:

-3k ADA per Community Maintainer per month, enough to qualify as a reward, not comparable to a ‘new development’ wage.

-5k ADA per Developer Advocate per month - representative of the increased expected responsibilities of Developer Advocates.

-$5k to $50k tooling support (paid in ADA designed to fuel transaction volume) Strict guidelines for payment/contract band approvals

-18 month Program Runway (1 Cohort of Developer Advocates, Max 40 Maintainers, the math for each programs aligns with very minimal overage (overages detailed and assigned in the WP estimated costs.

3/6

#### Feedback 4 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522#comment-6a1e0435ceb7fef00be0e508
- Summary (EN): Proposer (OSC) addresses scope-overlap concerns with parallel TxPipe and MLabs proposals, stating funding is application-based with no direct funding promised to TxPipe, that OSC selected only 2 of 5 MLabs submissions, that OSC does not fund Security Council/Bug Bounty (in Intersect's main budget), and that Developer Advocacy is bottom-up versus Intersect's top-down coordination (4/6).
- Summary (JA): 提案者(OSC)は並行するTxPipeやMLabsの提案とのスコープ重複の懸念に対応し、資金は申請ベースでTxPipeへの直接資金の約束はないこと、OSCはMLabsの5件中2件のみ選定したこと、OSCはSecurity Council/バグバウンティに資金提供しない(Intersect本予算に含まれる)こと、Developer AdvocacyはIntersectのトップダウン調整に対しボトムアップであることを説明している(4/6)。

Full text:

> \*\*3. Scope overlap with parallel Intersect / TxPipe proposals\*\*

| "Structured funding for maintainers" | TxPipe Y2 ... | Are these maintainers funded twice? |

There is no direct funding within this proposal promised to TxPipe or any other entity or business on Cardano. Funding is application based and previous funding is a factor prior to providing additional funds. 

| "Critical tooling" | MLabs Core Tool Maintenance (Plutarch + Ply, 1.14M ADA) | Already direct-funded? |

To be released in upcoming reports, MLabs submitted 5 projects for funding, Only 2 were selected by OSC, each request was asked vigorous questions and featured multiple debates via OSC Meetings. 

| "Bug bounties + incident monitoring" | Intersect MBO budget includes Security Council + Bug Bounty | OSC funds the same? |

OSC has not requested to fund these programs as they have been included in the Intersect (main) budget. The OSC Proposal mentions supporting these programs as they were originally inspired/started under the Paid Open Source Model. 

| "Developer Advocacy" | Intersect MBO budget covers technical workshops | OSC adds incremental? |

Rigorous review from Intersect Board, Intersect Steering Committee and Intersect Executives has been completed. Any technical workshop provided by Intersect is specific to coordination within the ecosystem. Developer Advocates are focused on New Developers to Cardano, and scaling newer contributors in line with the Contribution Ladder. Intersect’s Technical Coordination looks at the ecosystem top-down, where as the Developer Advocate program is from the bottom up. 

The proposal mentions a "Developer Advocate program paid in ADA" which distinguishes one specific feature, but the broader scope-overlap question is unanswered.

The concern here is unclear, the purpose behind specifying ADA as the ‘reward’ currency, regards creating transaction volume and the design is to inspire a better ability to further develop on the Cardano Blockchain.

#### Feedback 5 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522#comment-6a1e047b038cf72ed1e64f26
- Summary (EN): Proposer (OSC) responds to the lack of concrete KPIs, acknowledging more detail on KPIs, milestones, and prior-cycle outcomes would help, stating some elements already exist operationally, that the Maintainer Retainer Program is underway with reports due within 90 days, and that draft milestones are posted in the full budget copy (5/6).
- Summary (JA): 提案者(OSC)は具体的なKPIの欠如に対応し、KPI・マイルストーン・前サイクルの成果に関する詳細があれば評価に役立つと認め、一部の要素はすでに運用上存在すること、Maintainer Retainer Programは進行中で90日以内に報告予定であること、ドラフトのマイルストーンが完全版予算に掲載されていることを述べている(5/6)。

Full text:

> \*\*4. Performance-based language without concrete KPIs\*\*

We (OSC) appreciate the feedback and agree that additional operational clarity can strengthen the proposal and improve DRep evaluation.

The intent of the Paid Open Source Model (POSM) was to establish a sustainable operational framework for critical open source infrastructure and ecosystem support across Cardano. While the proposal outlines the strategic operational areas, we recognize that additional detail around KPIs, milestone structures, program boundaries, and prior-cycle outcomes would improve transparency and evaluability.

Several of the requested elements already exist operationally within OSC/OSO processes, including milestone-based reporting, maintainer review processes, phased funding concepts, and work-package-level acceptance criteria. However, we acknowledge that these details are not yet presented in a sufficiently consolidated or explicit format within the proposal itself.

**- "Performance-based open-source sustainability" is stated.**

**- No specific metric ties (maintainer-week delivery? bug-fix throughput? tooling-uptime SLA? CI pass rates?).**

The Maintainer Retainer Program is actively underway, reports will follow within the next 90 days. Milestones are set by the Project/Repo being supported, a copy of these will be formatted and posted to the Open Source Committee GitBook as the projects achieves full\* enrollment.

**- 18-month duration with no milestone disbursement framework specified.**

Milestones are in draft and have been posted alongside the Full (non-character count limited) Copy of the OSC Budget submission. [https://opensourcecommittee.docs.intersectmbo.org/about/readme/open-source-committee-2025-proposals-1](https://opensourcecommittee.docs.intersectmbo.org/about/readme/open-source-committee-2025-proposals-1)

5/6

#### Feedback 6 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ea4790d73bae0eb2a99522#comment-6a1e05045141bb70a939dbb6
- Summary (EN): Proposer (OSC) addresses the lack of 2025 outcome data, explaining 2025 programs are still being delivered, that unused funds will be returned by September 2026, and requests 'provisional approval' with a promise to return unused funds, itemizing ~2.5M ADA of a 5.885M fund as potentially returnable (6/6).
- Summary (JA): 提案者(OSC)は2025年の成果データの欠如に対応し、2025年のプログラムはまだ実施中であること、未使用資金は2026年9月までに返還されることを説明し、未使用資金の返還を約束した上で「暫定承認」を求め、5.885M ADAの基金のうち約2.5M ADAが返還可能と項目別に示している(6/6)。

Full text:

> \*\*5. 2025 cycle outcomes are not enumerated\*\*

**- Proposal is "continued" — implying a 2025 cycle predecessor was funded.**

Programs from the 2025 Treasury Withdrawal are still being delivered. The revised 1 year delivery timeline has not yet reached completion. Additional funding is being requested to prove growth of these programs in a continuous nature. By the end of September 2026, unused/unallocated funds from the 2025 Treasury Withdrawal will be returned. The new batch of funding will run through the end of 2027.

**- The proposal does not enumerate: which maintainers got funded in 2025, what they delivered...**

Not all Community Maintainers have been assigned, those that have applied have Interview Summaries and repo assignments listed on the OSC GitBook. [https://opensourcecommittee.docs.intersectmbo.org/about/paid-open-source-model-posm/maintainer-retainer](https://opensourcecommittee.docs.intersectmbo.org/about/paid-open-source-model-posm/maintainer-retainer)

**- Without 2025 outcome data, a DRep cannot evaluate whether 2026 continuation is justified or what scope adjustments are appropriate.**

We (OSC) Thank DReps and are very appreciative of the detailed and speculative feedback.\*\* **We recognize** \*\*that our proposal(ask) presents risk. As we are bound by our Administrator and our presentation to the Cardano community, we ask for ‘provisional approval’ of continued funding with the promise of returning unused funds. **&#160;**
***Currently slated for Return:***

- Cardano (Google) Summer of Code - 400k ADA
- Code for Us Community Bounties - 250k ADA
- Accelerator Program (Return decision under active vote) - 100k ADA
- Tooling Sustainability (lack of applications) - 1M+ ADA eligible for return under unclaimed Milestones
- Maintainer Retainer (18-25 Maintainers instead of 45) - 720k+ ADA return

TOTAL: \~2.5M return to Treasury possible\* out of 5.885M original fund

6/6

---

## 16. Cardano Enterprise Adoption: Production Ticketing Platform

- Proposal ID: 69fa01a5e8a58900f4a05a09
- Requested: 4,372,865 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa01a5e8a58900f4a05a09
- Category: dApp - other
- Applicable criteria: C1, C3, C4, C9
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

I could not see why this business model needs blockchain. The features that genuinely require chain are a small subset, and they only have value if you do NOT trust Sellout — but if you don't trust Sellout, the custodial design means the service can't function at all.

Doesn't need chain (Web2 suffices):
* Anti-counterfeit → signatures suffice
* Resale restriction / price cap / KYC → centralised systems do this better
* Custodial wallet → effectively a Web2 account
* Organiser tools → just a web app
* Royalty 'enforcement' → can't block off-contract trades; effectively voluntary

Needs chain:
* Third-party verification by parties who don't trust the issuer (venue, artists)
* Asset / history survival after platform shutdown
* Royalty 'distribution' enforced independently of the operator (on-contract trades only)

### Voting reason (JA, as of 2026-05-28)

このビジネスモデルにおけるブロックチェーン利用の必要性・合理性を理解できませんでした。 ブロックチェーンが必要な項目はごく一部で、 かつそれらは「Sellout を信頼しない」場合にのみ効果が発揮されますが、 Sellout を信用しないのであればカストディアル設計などそもそもこのサービスが成立しません。

チェーン不要 (Web2 で足りる):
* 偽造防止 → 署名で足りる
* 転売制限・価格上限・本人確認 → 中央集権の方が得意
* ウォレット (カストディアル) → 実質 Web2 アカウント
* 主催者ツール → ただの Web アプリ
* ロイヤリティ「強制」→ コントラクト外取引を防げず実質任意

チェーン必要:
* 発行者を信じない第三者検証 (会場・アーティスト)
* プラットフォーム消滅後の資産・履歴の存続
* ロイヤリティ「分配」の運営者非依存な執行 (コントラクト経由分のみ)

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Let me confirm whether my understanding is correct.
I understand that the chain produces inherent value only for actors who (A) need not to trust Sellout, and (B) touch the chain independently, without going through Sellout's rails (custody, its own marketplace, its own scanner). From this perspective, the actors involved divide into three.

1. Neither A nor B applies: fans (custody), the organizer, the venue at entry, and resale sellers. Because they trust Sellout and everything is completed within the rails, there is almost no inherent meaning in using the chain.
2. A may apply, but B is not satisfied (they stay within the rails): in-app resale buyers and artists who receive allocations. The chain's independence is activated only at the time of off-platform trading, which is either a minority or a case that cannot be captured in the first place.
3. Both A and B are satisfied: independent resale marketplaces, third-party/white-label operation, integrators, protection from acquirers, and users after the operator disappears. There is genuine value here, but at present these are quite the edge cases, and I do not see any contracted entities.

On that basis, I would like to ask one thing. You hold that "the failure of fully decentralized ticketing was caused by UX, and the diagnosis itself was correct." However, if the above is correct, then because the actors who truly need the chain are limited to the edge, I feel that one cause of the failure may also have been that "the very situations where it is truly needed were small" (of course I think there are other factors too, such as UX and the presence of established incumbents).
If that is so, my point shifts from "whether the chain is needed or not" to "whether the Treasury should pay in advance to build production infrastructure serving edge cases, at a stage when Group 3 has not yet been contracted." I would appreciate it if you could tell me whether this understanding is significantly off.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。私の認識が合っているか確認させてください。
チェーンが固有の価値を生むのは、(A)Selloutを信頼しない必要があり、かつ(B)Selloutのレール(カストディ・自社マーケット・自社スキャナ)を介さず独立してチェーンに触れるアクターに限られる、と理解しました。この観点で関与するアクターは3つに分かれます。

1. AもBも当てはまらない:ファン(カストディ)・主催者・入場時の会場・転売の売り手。Selloutを信頼しレール内で完結するため、チェーンを使う固有の意味はほとんどありません。
2. Aは当てはまりうるが、Bは満たさない(レール内にとどまる):アプリ内の転売買い手・配分を受けるアーティスト。チェーンの独立性が起動するのは場外取引の時だけで、少数か、そもそも捕捉できないケースです。
3. AもBも満たす:独立した転売マーケット・他社/ホワイトラベル運営・統合者・買収者からの保護・運営消滅後のユーザー。ここには本物の価値がありますが、現時点ではかなりのエッジケースで、契約済みの実体も見当たりません。

その上で一点うかがえればと思います。皆さんは「完全分散型チケットの失敗はUXが原因で、診断自体は正しかった」とされています。ただ上記が正しいとすると、チェーンが本当に必要なアクターはエッジに限られるため、失敗の一因には「本当に必要な場面そのものが小さかった」可能性もあるのではないか、と感じています(もちろんUXや既存大手の存在など他の要因もあると思います)。
もしそうであれば、私の論点は「チェーンが要るか否か」ではなく、「エッジケースに資する本番インフラを、グループ3がまだ契約されていない段階で、Treasuryが先払いで建てるべきか」に移ります。この理解で大きくずれていないか、教えていただけると助かります。

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on Cardano Enterprise Adoption: Production Ticketing Platform (Sellout.io / Anvil, **4.37M ADA / NCL 1.25%**).

**Main reasons**

**1. Phase 1 already delivered with private capital — that part is concretely strong**
- Per proposal: Phase 1 (on-chain event creation + CIP-68 ticket minting + transfers + attendance verification) is **already live on Cardano mainnet, funded entirely by Sellout (over $130K invested)**.
- That is unusually strong trust evidence — the proposer used private capital to ship Phase 1 before asking Treasury.

**2. Phase 2 anchor is concrete but small relative to the ask**

| Anchor metric | Value |
|---|---|
| Yellowstone Club 2026 concert series | named anchor (Noah Kahan, Sting, Weezer, Black Crows, Mumford & Sons, Dierks Bentley, B52s) |
| 2025 historical revenue | $5.88M |
| 2026 projected on-chain value | $6M+ |
| Individual ticket price | $400 - $8,000 |
| Existing user base | 200,000+ (Sellout) |
| **Phase 2 ask** | **4.37M ADA ≈ $1.09M USD (at ADA $0.25)** |

Ask is 18% of the anchor's projected on-chain value. For a single-year single-club deployment, that ratio is high.

**3. Transaction contribution depends on event cadence**
- Concert ticketing pattern: per-ticket mint (1 tx) + secondary trade (~30% of tickets per industry data, 1 tx each) + claim/scan (1 tx).
- Yellowstone 7-concert series at ~5K tickets per concert = 35K mints + ~10K secondary trades + ~35K claims = ~80K tx for the anchor.
- 80K Year-1 tx / 800K Cardano monthly baseline = 1.2% one-month bump (10% if concentrated in a single month).
- Repeatable if other clubs adopt — but the Phase 2 ask is for one anchor + tooling.

**4. Phase 2 scope: ambitious — needs per-line budget breakdown**

| Phase 2 component | Reasonable cost band |
|---|---|
| Secondary marketplace with on-chain royalty enforcement | $100-300K |
| Anti-scalping controls per-event | $100-200K |
| Wallet onboarding for 200K Sellout users | $200-400K (heavy lift) |
| Organizer-facing tools | $100-200K |
| Independent third-party security audit | $50-150K |
| Professional marketing firm campaign | $100-500K |

Reasonable cost band: $650K-1.75M USD. The proposal asks ~$1.09M USD — inside the band, but per-line breakdown is not provided. The marketing line is the highest unbounded-cost risk.

**5. Treasury return mechanism**
- Ticketing platforms generate fee revenue (primary sale + secondary royalty + organizer subscription).
- The proposal does not specify Treasury revenue share — Sellout retains commercial value while Treasury funds public-good infrastructure.
- Phase 1 self-funded suggests commercial viability — Phase 2 should articulate ADA-holder economic upside (revenue share, equity, or fee rebate).

**6. Adoption beyond Yellowstone is the real test**
- Yellowstone is the anchor — but the platform's value depends on whether other venues adopt.
- No named pipeline of additional venue commitments. Single-anchor risk: if Yellowstone succeeds but no other venue follows, $1.09M produces a one-club system, not Cardano enterprise infrastructure.

**Recommend resubmission** with: (a) per-Phase-2-line budget breakdown, (b) Treasury revenue share or fee rebate mechanism (Sellout has private capital track record — they should be able to offer return terms), (c) named additional-venue pipeline post-Yellowstone, (d) milestone-gated disbursement instead of front-loaded.

*Phase 1 self-funded evidence earns NO-resubmit, not flat NO.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — Cardano Enterprise Adoption: 本番チケッティング基盤(Sellout.io / Anvil、**4.37M ADA / NCL 1.25%**)に NO(再提出推奨)。

**主な理由**

**1. フェーズ1は自費で本番投入済み。ここは明確に強い**
- 提案書より:フェーズ1(オンチェーン上のイベント作成 + CIP-68 チケット発行 + 譲渡 + 入場確認)は **Cardano メインネットで既に稼働中。Sellout が自費で $130K 超を投資**。
- 異例に強い信頼根拠。トレジャリーに頼む前に自費で本番に出した。

**2. フェーズ2のアンカーは具体的だが、要求額に対しては小さい**

| アンカー指標 | 値 |
|---|---|
| Yellowstone Club 2026 コンサートシリーズ | 名前付きアンカー(Noah Kahan、Sting、Weezer、Black Crows、Mumford & Sons、Dierks Bentley、B52s) |
| 2025 売上実績 | $5.88M |
| 2026 のオンチェーン化見込み | $6M+ |
| 単券価格 | $400 - $8,000 |
| 既存利用者基盤 | 200,000+(Sellout) |
| **フェーズ2 要求額** | **4.37M ADA ≒ $1.09M USD(ADA $0.25 換算)** |

要求額はアンカーの想定オンチェーン額の 18%。単年・単クラブのデプロイとしては比率が高い。

**3. 取引寄与はイベント頻度依存**
- コンサートチケッティングのパターン:1券発行(1件)+ 二次流通(業界データで券の 約 30%、各 1件)+ 入場 / スキャン(1件)。
- Yellowstone 7 公演 × 約 5K 券 = 35K 発行 + 約 10K 二次流通 + 約 35K 入場 = アンカーで 約 80K 件。
- 80K(Y1)/ 800K(Cardano 月次)= 1ヶ月分の 1.2%(単月集中なら 10%)。
- 他のクラブが採用すれば再現可能。ただし本フェーズ2 要求は1アンカー + ツーリング分。

**4. フェーズ2 範囲:意欲的、項目別予算が必要**

| フェーズ2 項目 | 妥当なレンジ |
|---|---|
| オンチェーンロイヤリティ強制付き二次市場 | $100-300K |
| 公演ごとの転売対策 | $100-200K |
| Sellout 既存 20 万ユーザーのウォレット導入 | $200-400K(重い) |
| 主催者向けツール | $100-200K |
| 独立第三者によるセキュリティ監査 | $50-150K |
| プロのマーケティング会社による施策 | $100-500K |

妥当なレンジ:$650K-1.75M USD。提案要求 約 $1.09M USD はレンジ内。だが項目別の内訳がない。マーケティング項目が上限のないコストリスク。

**5. トレジャリーへの還元機構**
- チケッティング事業は手数料収入を生む(一次販売 + 二次ロイヤリティ + 主催者サブスク)。
- 提案書はトレジャリーへの収益分配を指定していない。Sellout が商用価値を保ちつつ、トレジャリーが公共財基盤に資金提供する形。
- フェーズ1 自費は商用採算の示唆。フェーズ2 は ADA 保有者への経済的還元(収益分配、エクイティ、手数料リベートなど)を明示すべき。

**6. Yellowstone 以後の採用が真の試金石**
- Yellowstone はアンカー。基盤の価値は他会場が採用するかにかかる。
- 追加会場のパイプラインの名前出しがない。単一アンカーリスク:Yellowstone は成功しても、他会場が続かなければ $1.09M は1クラブ用システム止まりで、Cardano のエンタープライズ基盤にはならない。

**再提出推奨**:(a) フェーズ2 項目別予算、(b) トレジャリーへの収益分配 or 手数料リベート(Sellout には自費投入実績があるため還元条件は提示可能なはず)、(c) Yellowstone 後の追加会場パイプラインの名前出し、(d) 一括ではなくマイルストーン段階払い。

*フェーズ1 自費投入の実績があるため、NO そのものではなく NO 再提出推奨。*

### Proposer feedback (3)

#### Feedback 1 — source: twitter, author: CashAnvil
- Author note: CONFIRMED: bio "CEO of @AnvilDevAgency" (proposer of the ticketing platform)
- URL: https://twitter.com/CashAnvil/status/2059673270274691521
- Summary (EN): Anvil CEO ($cash, proposer) says he sent direct counterpoints on the proposal and rebuts the 'why blockchain' framing: Sellout chose Cardano for native assets, ledger, safety/reliability, eventual L2s and SPO. Also gave UX feedback (wants feedback filterable by proposal) and noted Catalyst historically never required KPIs.
- Summary (JA): Anvil CEO ($cash、 提案者) が提案への反論を直接送ったと述べ、「なぜブロックチェーンか」に反論: Sellout は Native Assets / Ledger / 安全性・信頼性 / 将来の L2・SPO のため Cardano を選択。 b69-share2 への UX 要望 (提案別フィルタ)、 Catalyst が従来 KPI を要求しなかった点も指摘。

Full text:

I sent Yuta a message on our proposal.

Out of respect for him I will give him some time to address our counterpoints on the proposal and my personal counterpoints to some other votes before sharing them in their entirety, publicly.

Just as a reminder though, Sellout chose Cardano for a multitude of reasons (Native Assets, Ledger, Safety and Reliability, eventual L2s, eventual SPO).

[Also: "Being able to filter this by proposal would be sweet!" / "Catalyst was a different beast with much more lax rules at first. They never required KPIs so no one included them." / "This is not vote shaming, I highly respect Yuta."]

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa01a5e8a58900f4a05a09#comment-6a1dd69dceb7fef00be0e4fd
- Summary (EN): Proposer (Anvil/Sellout) concedes anti-counterfeit alone does not need a blockchain and that custody requires trust, but argues the parties needing trustlessness (artists, venues, resale buyers) are not the custodial parties, while fans use custodial wallets by choice yet can self-custody native Cardano ticket assets at any time.
- Summary (JA): 提案者(Anvil/Sellout)は偽造防止だけならブロックチェーンは不要で、カストディは信頼を要すると認めつつ、トラストレス性を必要とする当事者(アーティスト、会場、リセール購入者)はカストディ対象ではなく、ファンは選択でカストディウォレットを使うがネイティブCardanoチケット資産をいつでも自己管理できると主張している。

Full text:

Yuta thank you from the Anvil and Sellout teams. This is a very useful critique we have received, and it improved how we explain the design. 

**Where you are right:** Anti-counterfeit alone does not need a blockchain because digital signatures are enough. Fully off-platform resale cannot be blocked by anyone. And a custodial wallet, at the moment it holds the asset, requires trust. We agree with all three points.

**Our main point: the parties who need trust-lessness are not the custodial parties.**

You wrote that the blockchain features only matter if a user does not trust Sellout but a custodial wallet requires trusting Sellout. The contradiction disappears when we separate two groups:

**Group 1: Fans(Consumers).** Fans use custodial wallets by choice, for convenience. But each ticket is a native Cardano asset. A fan can move it to a self-custody wallet at any time. The custodial wallet is only the starting point, not a lock-in. A normal Web2 account can never be exported this way.

**Group 2: Artists, venues, and resale buyers.** These parties are never custodied by Sellout. They do not trust Sellout's internal records, they read the blockchain directly. The three features you list as genuinely needing a blockchain (independent royalty distribution, third-party verification, and asset survival after a platform shutdown) serve exactly these parties.

So the trustless features serve the trustless relationships. The custodial convenience serves the fan who does not need them. One system serves both groups. A Web2 system cannot.

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa01a5e8a58900f4a05a09#comment-6a1dd823038cf72ed1e64f20
- Summary (EN): Proposer (Sellout) argues trust is divided rather than all-or-nothing (trusting Sellout to issue a real ticket vs. on-chain rules needing no trust), explains the business chose Cardano for long-term infrastructure reasons, and emphasizes real recurring mainnet volume from an established business with 200,000 users and a $6M+ anchor deployment.
- Summary (JA): 提案者(Sellout)は信頼は全か無かではなく分割されている(本物のチケット発行はSelloutを信頼するが、オンチェーンのルールは信頼不要)と主張し、同社が長期的なインフラ上の理由でCardanoを選んだと説明し、20万ユーザーと$6M超のアンカー展開を持つ既存事業からの実際の継続的なメインネット取引量を強調している。

Full text:

**Trust is divided, not all-or-nothing.** Two separate questions:

1️⃣ Do you trust Sellout to issue a real ticket? → Yes. Sellout is the official seller. No blockchain removes this.

2️⃣ Do you trust the rules after issuance - royalty splits, transfers, attendance, provenance, survival? → No trust is needed. These rules run on-chain, where any party can verify them.

This is more trust-minimization than Web2, where one operator controls the entire ticket lifecycle.

**Why a real business chose Cardano**. Sellout did not have to use a blockchain. Sellout chose Cardano for native assets, the ledger, safety and reliability, governance, future L2s, and running its own SPO. These are long-term infrastructure reasons, not a feature checklist. This was a decision made over 3-4 months, after several in-depth conversations on blockchain options and their pros/cons.

**Why this matters for adoption.** Every fully-decentralized ticketing project since 2017 has failed. The diagnosis was correct, but normal users will not adopt a fully trustless interface. The Cardano 2030 Vision asks builders to hide wallets and signing from users. Our design does this: trustless where money and ownership live, and Web2-smooth where humans onboard.

**The result for Cardano?** Every royalty distribution, transfer, resale, and check-in is a real mainnet transaction at the scale of an established business with 200,000 users and a contracted $6M+ anchor deployment. This is not projected testnet activity. It is real, recurring volume from day one.

We are happy to go deeper on any single point, and we are grateful for the rigor. Thank you for taking the time to understand the opportunity our proposal presents for Cardano.

---

## 17. Indigo Innovation Proposal: V2030RS, Tokenized RWA, BTC-Fi & Privacy

- Proposal ID: 69e63a4ed6a29288536b11fc
- Requested: 3,965,500 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e63a4ed6a29288536b11fc
- Category: dApp - DeFi
- Applicable criteria: C3, C4, C8, C9
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

The repayment projection (V2030RS Forecast Summary, ch.3 p11) contradicts the proposal body (§1.1 p1). §1.1 limits the 10% return scope to 'revenue from the products developed in this proposal (RWA / BTC-Fi / Midnight) only', but the Forecast Summary Low-scenario first-year figure 466,263 ADA equals 10% of the existing Indigo protocol's average annual revenue 4.66M ADA — implying the forecast is based on protocol-wide revenue. If only the new products are in scope, the forecast presumes products that have not even launched yet immediately generate revenue comparable to the existing protocol, which is unrealistic. Conversely, if the forecast genuinely covers the whole protocol, that contradicts the §1.1 limitation.

### Voting reason (JA, as of 2026-05-28)

回収予測 (V2030RS Forecast Summary、 3 章 p11) と提案本文 (1.1 節 p1) の記載が矛盾しています。 1.1 節では『この提案で開発されたプロダクト (RWA / BTC-Fi / Midnight) の収益のみ』を 10% 還元の対象としていますが、 Forecast Summary の Low シナリオ初年度 466,263 ADA は、 既存 Indigo プロトコル全体の年平均収益 4.66M ADA の 10% と一致しており、 予測がプロトコル全体の収益を母数にしていることが分かります。 新規プロダクトのみが対象なら、 まだローンチもしていないプロダクトが既存プロトコル並みの収益を即座に生む前提となり非現実的です。 逆に予測どおりプロトコル全体が対象なら、 1.1 節の限定と矛盾します。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; I would be glad to receive the data you proposed on the revenue projections for the new product. This is necessary in order to assess recoverability.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます、あなたが提案していただいた、新たなプロダクトの収益見込みに関するデータをいただければ嬉しいです。これは回収可能性を評価するために必要です。

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on Indigo Innovation Proposal: V2030RS, Tokenized RWA, BTC-Fi & Privacy (**3.97M ADA / NCL 1.13%**).

**Main reasons**

**1. The summary is very sparse for a 3.97M ADA / 4-pillar proposal**
- The proposal summary covers 4 ambitious scope pillars in 3 sentences:
  1. **iUSDt** — institutional-grade tokenised RWA solution.
  2. **BTC-Fi** — Bitcoin DeFi markets on Indigo.
  3. **Shielded iAssets** — privacy-preserving iAssets on partner-chain ecosystems.
  4. **V2030RS** — revenue-sharing model with Cardano Treasury.
- Each pillar individually is a multi-year project at Indigo's scale. Bundling 4 into a single proposal makes per-pillar scope evaluation impossible.

**2. Indigo's Cardano track record is strong, but this proposal extends to areas Indigo has not previously delivered**

| Pillar | Indigo's existing competence | Risk |
|---|---|---|
| iUSDt (RWA + institutional liquidity) | partial — Indigo Protocol is synthetics, not RWA | new domain |
| BTC-Fi (Bitcoin DeFi on Indigo) | none demonstrated — Bitcoin bridge architecture is distinct | new domain |
| Shielded iAssets on partner-chain | none demonstrated — partner-chain is research-stage on Cardano | research-stage |
| V2030RS revenue-sharing | new governance model — Treasury-Indigo coordination first-of-kind | structural unknown |

Indigo's primary Cardano track record (synthetic asset protocol, established TVL position) is in a different domain from 3 of these 4 pillars. The proposal asks Treasury to fund Indigo's expansion across these 4 directions without per-pillar scope-vs-budget breakdown.

**3. V2030RS revenue-sharing is potentially good, but undefined**
- "Landmark revenue-sharing model (V2030RS) with the Cardano Treasury" is mentioned.
- Mechanism unspecified: percentage of Indigo protocol revenue shared? trigger conditions? duration? cap?
- Compare with DeltaDeFi's "perpetual 15% revenue share" — that proposal at least gave a concrete percentage and duration.
- Without specification, the C4-positive framing cannot be evaluated.

**4. Scope overlap with parallel proposals**

| Pillar | Overlapping Budget #69 proposal |
|---|---|
| iUSDt (institutional RWA) | Wormhole Cross-Chain (institutional RWA pipeline) |
| Privacy on partner-chain | Tachýs Partner Chain Factory (research-stage partner chain) |
| BTC-Fi | (Bitcoin bridge proposals + sBTC pipeline) |

Each pillar competes with at least one separate Budget #69 proposal. Resource competition and duplication are unclear.

**5. Cost per pillar**
- 3.97M ADA / 4 pillars ≈ 992K ADA per pillar ≈ $248K USD per pillar at ADA $0.25.
- For ambitious multi-domain work (RWA + BTC-Fi + privacy + governance), $248K per pillar is small.
- This suggests either: each pillar is intentionally small-scope research-pilot, or the proposal is under-budgeted vs scope. Either interpretation makes per-pillar deliverable evaluation important.

**Recommend resubmission** with: (a) per-pillar scope + budget breakdown, (b) explicit V2030RS specification (%, duration, trigger conditions), (c) competence-extension argument for BTC-Fi, partner-chain, and RWA-institutional pillars (synthetics track record ≠ Bitcoin bridge or partner-chain privacy track record), (d) scope overlap delineation versus Wormhole, Tachýs, and Bitcoin-bridge proposals.

*Indigo is an established Cardano protocol — a flat NO would be too harsh. NO-resubmit reflects the per-pillar transparency and V2030RS specification gap. With clarifications, this could flip to YES on a pillar-by-pillar basis.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — Indigo Innovation Proposal: V2030RS、トークン化 RWA、BTC-Fi、プライバシー(**3.97M ADA / NCL 1.13%**)に NO(再提出推奨)。

**主な理由**

**1. 3.97M ADA / 4本柱の提案にしては、サマリーが非常に薄い**
- 提案サマリーは、4つの意欲的な柱を3文で記述:
  1. **iUSDt** — 機関グレードのトークン化 RWA。
  2. **BTC-Fi** — Indigo 上の Bitcoin DeFi 市場。
  3. **Shielded iAssets** — パートナーチェーン上のプライバシー保護 iAssets。
  4. **V2030RS** — Cardano トレジャリーとの収益分配モデル。
- Indigo の規模感では、各柱が単独で多年プロジェクト。4つを1提案に束ねると、柱ごとの範囲評価が不能になる。

**2. Indigo の Cardano 実績は強いが、本提案は実績の外に広がる**

| 柱 | Indigo 既存の専門性 | リスク |
|---|---|---|
| iUSDt(RWA + 機関流動性) | 部分的 — Indigo は合成資産で RWA ではない | 新領域 |
| BTC-Fi(Indigo 上 Bitcoin DeFi) | 実績なし — Bitcoin ブリッジ構造は別物 | 新領域 |
| パートナーチェーン上の Shielded iAssets | 実績なし — Cardano 上のパートナーチェーンは研究段階 | 研究段階 |
| V2030RS 収益分配 | 新ガバナンスモデル — トレジャリー × Indigo の調整は初物 | 構造未知数 |

Indigo の主な Cardano 実績(合成資産プロトコル、TVL のある立ち位置)は、4本柱のうち3つとは別領域。提案書は、柱ごとの範囲と予算の対応関係を示さずに、4方向への拡張にトレジャリー資金を求めている。

**3. V2030RS 収益分配は良い可能性があるが、定義がない**
- 「Cardano トレジャリーとの画期的な収益分配モデル(V2030RS)」と言及。
- 仕組みは未指定:Indigo の収益の何 %?発動条件?期間?上限?
- DeltaDeFi の「永続 15% 収益分配」と比較 — 少なくとも具体的な割合と期間を示していた。
- 仕様なしには、C4(還元)面の前向きな評価ができない。

**4. 並行提案との範囲重複**

| 柱 | 重複する Budget #69 提案 |
|---|---|
| iUSDt(機関 RWA) | Wormhole Cross-Chain(機関 RWA パイプライン) |
| パートナーチェーン上のプライバシー | Tachýs Partner Chain Factory(研究段階のパートナーチェーン) |
| BTC-Fi | (Bitcoin ブリッジ系提案 + sBTC パイプライン) |

各柱が少なくとも1件の別 Budget #69 提案と競合する。資源競合と重複が不明。

**5. 柱あたり単価**
- 3.97M ADA / 4 柱 ≒ 柱あたり 992K ADA ≒ ADA $0.25 換算で柱あたり $248K USD。
- RWA + BTC-Fi + プライバシー + ガバナンスの意欲的な領域横断作業に対し、柱あたり $248K は小さい。
- 解釈は2つ:各柱が意図的に小規模な研究パイロット、または範囲に対して予算不足。どちらでも柱ごとの納品物評価が重要になる。

**再提出推奨**:(a) 柱ごとの範囲 + 予算内訳、(b) V2030RS の明示的な仕様(%、期間、発動条件)、(c) BTC-Fi、パートナーチェーン、RWA 機関向け柱への能力拡張の論拠(合成資産の実績 ≠ Bitcoin ブリッジやパートナーチェーンプライバシーの実績)、(d) Wormhole、Tachýs、Bitcoin ブリッジ提案との範囲切り分け。

*Indigo は確立した Cardano プロトコルで、即 NO は過剰。NO 再提出は柱ごとの透明性と V2030RS 仕様の不足を反映。説明があれば柱単位で YES に転じうる。*

### Proposer feedback (1)

#### Feedback 1 — source: twitter, author: ecatxvc
- Author note: CONFIRMED: bio "Founder - Indigo Ecosystem @indigo_protocol"
- URL: https://twitter.com/ecatxvc/status/2060005402964631937
- Summary (EN): Indigo founder (EC) addresses the V2030RS contradiction concern: clarifies §1.1 limits revenue share to products developed through THIS proposal, and argues modeling the forecast off the existing protocol suite would misrepresent it since that wasn't built by this proposal. Offered DM/comment dialogue; feedback being incorporated.
- Summary (JA): Indigo 創業者 (EC) が V2030RS の矛盾懸念に回答: §1.1 は本提案で開発するプロダクトのみに収益分配を限定すると明確化。 既存プロトコル全体を母数に予測をモデル化するのは本提案の成果ではないため不適切と主張。 DM/コメントでの対話を申し出。

Full text:

Hello @yutazzz thanks for being patient on my follow up to provide more clarity on your concerns with the Indigo Innovation Proposal's V2030RS framework.

We're in the midst on launching Indigo V3 as I type this, so we have many irons in the fire at the moment, but positive!

Section 1.1 defines the actual V2030RS commitment: revenue share applies to products developed through this proposal.

[May 29 follow-up: As far as new product revenues, we would have to model V2030RS based off of a product suite we did not develop and/or manage. We can surely do that, but I'm afraid it wouldn't be a fair representation seeing as it wasn't Indigo's real production to begin with.]

---

## 18. Bringing Real-World Payments to Cardano with Wirex

- Proposal ID: 69f9d441f86410919eef6bd5
- Requested: 3,961,538 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f9d441f86410919eef6bd5
- Category: dApp - other
- Applicable criteria: C1, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

We need clarity on whether the projected 1M annual on-chain transactions are post-batch L1 Tx, pre-batch, or something else. The response to SIPO on this question is unclear, and this is important to me. What does "the chain itself needs to support near-instant tx confirmation to match the 200-300ms confirmation window required for card transactions" actually mean? Even with Peras, I don't believe Cardano will meet that latency requirement.

### Voting reason (JA, as of 2026-05-28)

年間 100 万件のオンチェーン取引について、 バッチ化された後の L1 で発生する Tx なのか、 バッチ化前の話か、 などについて明確な説明が必要です。 SIPO からの説明要求に対する回答はやや不明瞭に聞こえますが、 ここは私にとって重要です。 「the chain itself needs to support near instant tx confirmation to match the 200-300ms confirmation window required for card transactions」とはどういうことでしょうか。 Peras を前提にしても、 Cardano はそれに対応しないと思います。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Bringing Real-World Payments to Cardano with Wirex (**3.96M ADA / NCL 1.13%**).

**Main reasons**

**1. Wirex track record at scale**
- Per proposal: **7M users**, **$20B+ in processed volume**, **Visa Principal Member**.
- Visa Principal Member status is rare for crypto-fiat companies and implies multi-year regulatory and processing build-out.
- This is a payment-rail operator at scale, not a startup looking for its first payment partner.

**2. Real-world payment rails are a visible Cardano gap**
- Cardano DeFi TVL: ~$132M (DefiLlama, April 2026).
- Cardano daily-payment rails today: essentially none. No Visa-card-linked ADA spending at scale, no merchant acceptance integrations at scale, no fiat-rail bridge for ADA payroll or B2B.
- Per ADAtool db-sync: 99%+ of Cardano L1 transactions today are DeFi, NFT, governance, or staking. Payments-class transactions are <1% of monthly volume.
- Comparable chains (e.g., Visa-card-linked USDC on Solana via Crypto.com or Wirex) generate substantial recurring transactions. Cardano has no equivalent.

**3. Proposer's open-source commitment + self-custody integration**
- Per proposal: "full-stack, open-source payments infrastructure" + "native integration with self-custody wallets".
- That is structurally aligned with Cardano values (open source + non-custodial).
- A Visa card linked to on-chain balances is real economic activity, distinct from bridge-style speculative volume.

**4. C1: transaction contribution depends on actual conversion, which the proposer should commit to**
- Wirex has a real 7M user base. Whether those users convert to ADA-linked cards is the open question.
- Conversion rate, monthly transactions per active card, and ramp curve are not in the proposal as commitments. The DRep ask is to require these as milestones (see below).
- Cardano's monthly transaction baseline is ~700-800K (per ADAtool db-sync). Even small absolute conversion would be Cardano-material — but the proposer should be the one putting numbers on it, not the reviewer.

**Conditions for YES (DRep-side asks)**:
- (a) Cardano-specific user-conversion KPI tied to milestones (target number of Wirex users activating an ADA-linked card by M6 / M12, committed by the proposer).
- (b) Per-milestone transaction-volume reporting (visible KPI for DRep oversight, with halt rights if numbers don't materialise).
- (c) Open-source code commitment with specific repositories named.

Default YES on the basis of Wirex's $20B / 7M-user / Visa Principal Member track record, the visible Cardano payment-rails gap, and the structural alignment with self-custody. Conversion projections are intentionally left to milestone commitments rather than asserted here.

### Prior detailed analysis (JA)

**Vote: YES** — Wirex による実世界決済の Cardano 展開(**3.96M ADA / NCL 1.13%**)に YES。

**主な理由**

**1. Wirex の規模感のある実績**
- 提案書より:**利用者 700 万人**、**処理金額 累計 $20B+**、**Visa プリンシパルメンバー**。
- 暗号—法定通貨企業で Visa プリンシパルメンバーは稀。多年にわたる規制対応と決済処理の積み上げを示唆する。
- 既に規模感のある決済事業者で、最初の決済パートナーを探しているスタートアップではない。

**2. Cardano にとって、実世界決済は明らかな空白**
- Cardano DeFi TVL:約 $132M(DefiLlama 2026年4月)。
- 現在の Cardano の日常決済レール:実質ゼロ。規模のある ADA 連動 Visa カード支出はなく、規模のある加盟店受け入れ統合もなく、ADA 給与 / 法人向け決済の法定通貨ブリッジもない。
- ADAtool db-sync:Cardano L1 取引の 99%+ は DeFi、NFT、ガバナンス、ステーキング。決済型取引は月次ボリュームの 1% 未満。
- 比較対象チェーン(Crypto.com / Wirex 経由の Solana 上の Visa カード連動 USDC など)は持続的な取引を相当量生む。Cardano に同等のものはない。

**3. 提案者のオープンソース方針 + 自己保管統合**
- 提案書より:「フルスタックでオープンソースの決済基盤」+「自己保管ウォレットとのネイティブ統合」。
- Cardano の価値観(オープンソース + 非保管型)と構造的に一致。
- オンチェーン残高に紐付く Visa カード発行は実際の経済活動で、ブリッジ型の投機的な取引量とは別。

**4. C1:取引寄与は実際の転換率に依存。これは提案者がコミットすべき**
- Wirex の 700 万人は実在のユーザー基盤。それが ADA 連動カードに転換するかは未解明。
- 転換率、アクティブカード当たり月次取引数、立ち上がり曲線は、提案書にコミットとして記載されていない。マイルストーン化を DRep 側から要求すべき項目(下記)。
- Cardano の月次取引ベースラインは 約 700-800K 件(ADAtool db-sync)。絶対数で小さくても Cardano にとって意味のある寄与になり得るが、数字を出すのは評価者ではなく提案者の役割。

**YES の条件(DRep からの要求)**:
- (a) マイルストーンに紐付く Cardano 固有のユーザー転換 KPI(M6 / M12 までに ADA 連動カードを使い始める Wirex ユーザー数の目標。提案者がコミットする)。
- (b) マイルストーンごとの取引量レポート(DRep 監督用、未達なら停止できる構造)。
- (c) オープンソースコードのコミットメント。具体的なリポジトリ名の指定付き。

Wirex の $20B / 700 万人 / Visa プリンシパルメンバーの実績 + Cardano の決済レールの空白 + 自己保管との整合性で、YES。転換率の見込みはここで主張せず、マイルストーンのコミットメントに委ねる。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 19. Mithril Protocol

- Proposal ID: 69f3529e1e63d3708e0dadb6
- Requested: 3,810,423 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f3529e1e63d3708e0dadb6
- Category: Core protocol
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

The maintenance portion is essential, but I want stronger evidence of demand for the new-feature development portion.

### Voting reason (JA, as of 2026-05-28)

「メンテナンス」部分は必須だが、 「新規開発機能」部分の需要について、 より良い証拠を確認したい。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Mithril Protocol (**3.74M ADA / NCL 1.07%**).

**Main reasons**

**1. Mithril addresses a real infrastructure pain point with no competing alternative**
- Per proposal: "today full node synchronisation is slow and light clients rely on centralised trust".
- The specific problem: bootstrapping a Cardano node from genesis takes hours-to-days. Light clients without stake-based certification must trust a third-party API (Blockfrost / Koios / etc.).
- Mithril provides stake-based threshold multi-signatures to certify Cardano state, enabling rapid trustless verification.
- No other active Treasury Withdrawal funds a competing alternative.

**2. Mithril is the canonical Cardano stake-based certification protocol**
- Used by: Dolos (Mithril snapshot bootstrap), Cardano.nix (Mithril signer + snapshot integration per the MLabs Cardano.nix proposal), Oura (Mithril source).
- Pallas (the foundational Rust library Mithril uses) has 214,446 downloads on crates.io.
- Mithril signer operation is a real SPO workload — the Cardano.nix 2026 proposal explicitly cites a Mithril signer prototype as an SPO-tooling milestone.

**3. No competing stake-based certification protocol**
- Bitcoin's neutrino / compact-filter light-client model is not stake-based.
- Ethereum's beacon-chain sync committees serve a similar role but require Ethereum consensus participation — not portable to Cardano.
- Mithril is Cardano-native stake-weighted certification. Unique architectural position.

**4. Cost benchmark**
- 3.74M ADA ≈ $935K USD at ADA $0.25.
- For a protocol-layer infrastructure component covering Cardano sync + light-client trust minimisation, mid-range.
- Comparable foundational-infrastructure proposals this cycle: TxPipe Y2 bundle ~2.16M ADA total; MLabs Cardano.nix 1.14M ADA; Mithril 3.74M ADA — larger because the work is protocol-layer with cryptographic complexity.

**5. Strategic downstream value**

| Downstream use case | What it needs Mithril for |
|---|---|
| Fast wallet sync (Daedalus / Eternl / Nami / Lace) | Mithril snapshot fast-bootstrap |
| Light-client SDKs (mobile + browser) | Mithril stake-based certification = trustless light-client model |
| Cross-chain bridges (LayerZero / Wormhole / Bitcoin bridges) | Mithril provides verifiable Cardano-state proofs |
| Cardano archives + analytics | Mithril certified snapshot integrity |

Discontinuing Mithril would regress Cardano's trustless-light-client path.

**Concern (not a NO)**: The proposal summary is sparse. The DRep ask should be a milestone-level deliverable list + Year-1 delivery evidence (Mithril has been in development for years, so prior delivery cadence should be documentable). Default YES on canonical status + no alternative + strategic downstream value.

### Prior detailed analysis (JA)

**Vote: YES** — Mithril Protocol(**3.74M ADA / NCL 1.07%**)に YES。

**主な理由**

**1. Mithril は実在のインフラ課題に対処し、競合する代替案がない**
- 提案書より:「現状、フルノードの同期は遅く、ライトクライアントは集中型の信頼に依存している」。
- 具体的な問題:Cardano ノードをジェネシスからブートストラップすると数時間〜数日。ステーク証明のないライトクライアントは第三者 API(Blockfrost / Koios など)に依存せざるを得ない。
- Mithril はステーク加重しきい値マルチ署名で Cardano の状態を証明する。高速かつ信頼を最小化した検証を可能にする。
- 競合する代替を支援する他の Treasury Withdrawal はない。

**2. Mithril は Cardano のステーク証明の標準**
- 利用者:Dolos(Mithril スナップショットブート)、Cardano.nix(MLabs の Cardano.nix 提案より Mithril 署名者 + スナップショット統合)、Oura(Mithril ソース)。
- Mithril が使う基盤の Pallas は crates.io ダウンロード 214,446。
- Mithril 署名者の運用は実在の SPO 作業。Cardano.nix 2026 提案も SPO ツールマイルストーンに Mithril 署名者プロトタイプを明示している。

**3. 競合するステーク証明プロトコルはない**
- Bitcoin の neutrino / compact filter ライトクライアントはステーク方式ではない。
- Ethereum のビーコンチェーン同期委員会は似た役割だが Ethereum 合意への参加を要し、Cardano に移植できない。
- Mithril は Cardano ネイティブのステーク加重証明で、構造上独自の立ち位置。

**4. 単価**
- 3.74M ADA ≒ $935K USD(ADA $0.25 換算)。
- Cardano 同期 + ライトクライアント信頼最小化を担うプロトコル層インフラとして中位。
- 同サイクルの基盤インフラ提案:TxPipe Y2 バンドル 累計 約 2.16M ADA、MLabs Cardano.nix 1.14M ADA、Mithril 3.74M ADA。プロトコル層 + 暗号要素ありで、その分大きい。

**5. 下流の戦略的価値**

| 下流の用途 | Mithril への依存 |
|---|---|
| ウォレット高速同期(Daedalus / Eternl / Nami / Lace) | Mithril スナップショットの高速ブート |
| ライトクライアント SDK(モバイル + ブラウザ) | Mithril のステーク証明 = 信頼最小化型ライトクライアント |
| クロスチェーンブリッジ(LayerZero / Wormhole / Bitcoin ブリッジ) | Mithril が検証可能な Cardano 状態証明を提供 |
| Cardano アーカイブ + 分析 | Mithril 認証スナップショットの整合性 |

Mithril を打ち切ると、Cardano の信頼最小化ライトクライアント経路は後退する。

**懸念(NO ではない)**:提案書のサマリーが薄い。DRep からはマイルストーン単位の成果物リストと Y1 達成証拠(数年開発しているので過去ペースは文書化可能なはず)を要求すべき。標準的立ち位置 + 代替なし + 下流の戦略価値で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 20. DeFi Ecosystem Connectivity via Ledger Wallet with Clear Signing

- Proposal ID: 69fd6ef7f9ebc26d057f51d9
- Requested: 3,599,850 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd6ef7f9ebc26d057f51d9
- Category: Wallet / hardware
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Improving hardware-wallet UX and security is positive, but post-implementation maintenance cost etc. is unclear and needs further confirmation.

### Voting reason (JA, as of 2026-05-28)

ハードウェアウォレットのユーザー体験とセキュリティの改善は良いことですが、 実装後のメンテナンスコストなどが曖昧で、 より確認が必要です。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Full Integration of CIP-113 with Clear Signing across Ledger Products (**92.7K ADA / NCL 0.03%**).

**Main reasons**

**1. CIP-113 is the agreed token standard; this is the device-level layer**
- CIP-113 is the Programmable Tokens standard, launched by the Cardano Foundation in March 2026. It covers on-chain compliance and transfer logic.
- Without Ledger-device support for CIP-113, every token in this category (regulated stablecoins, RWA tokens, payroll tokens) can only be blind-signed on hardware wallets.
- Scope: Ledger Signer + Ledger Live + Ledger Enterprise — the full Ledger product line.
- **Budget = 92.7K ADA / NCL 0.03%** — small, complementary to the other two Ledger SAS proposals.

**2. The protocol-layer piece of the three-proposal stack**

| Layer | Proposal | Budget |
|---|---|---|
| **Protocol (this)** | CIP-113 across Ledger Products | **92.7K ADA** |
| dApp adoption | Top-5 dApps clear signing + Ledger Button | 3.46M ADA |
| Vendor maintenance | Cardano app on Ledger by Ledger SAS | 2.06M ADA |

Without device-level CIP-113 support, dApps can emit CIP-113 metadata but the device still shows opaque CBOR — the other two proposals' safety goal remains incomplete.

**3. Cost is at maintenance rates**
- 92.7K ADA across 3 products = ~30.9K ADA per product. Comparable to per-product Ledger app maintenance rates.

**4. No alternative is funded**
- Vendor-specific safe-signing formats exist historically but produce fragmented UX. CIP-113 is the agreed standard. No alternative Treasury Withdrawal or Catalyst funding covers Ledger-side CIP-113.

**Conclusion**: At 92.7K ADA, this is the smallest and most leveraged piece of the three-proposal Ledger stack — the highest-confidence YES in the bundle.

### Prior detailed analysis (JA)

**Vote: YES** — Ledger 全製品への CIP-113 統合(**92.7K ADA / NCL 0.03%**)に YES。

**主な理由**

**1. CIP-113 はエコシステムで合意された標準。これは機器側の実装層**
- CIP-113 はプログラム可能トークンの標準。2026年3月に Cardano Foundation が公開。コンプライアンスや転送ロジックをオンチェーンに持つ。
- Ledger 側で CIP-113 に対応しないと、規制対応のステーブルコイン、RWA トークン、給与トークンなど CIP-113 カテゴリ全部が、ハードウェアウォレットでは盲目署名のみになる。
- 対象:Ledger Signer + Ledger Live + Ledger Enterprise(Ledger の全製品ライン)。
- **予算 92.7K ADA / NCL 0.03%** — 小さく、他の2つの Ledger SAS 提案と補完関係にある。

**2. 3提案セットのうち、プロトコル層**

| 層 | 提案 | 予算 |
|---|---|---|
| **プロトコル(本提案)** | Ledger 全製品への CIP-113 統合 | **92.7K ADA** |
| dApp 採用層 | Top 5 dApp clear signing + Ledger Button | 3.46M ADA |
| ベンダー保守 | Ledger SAS による Cardano アプリ保守 | 2.06M ADA |

機器側で CIP-113 を実装しないと、dApp が CIP-113 メタデータを出しても機器側は依然として生 CBOR を表示する。他2提案の安全目標が成立しない。

**3. 単価は保守クラス**
- 92.7K ADA / 3 製品 = 製品当たり約 30.9K ADA。Ledger アプリの保守単価として相場。

**4. 代替の資金はない**
- ベンダー独自の安全署名スキームは過去にあるが、UX が分断する。CIP-113 は合意された標準で、Ledger 側 CIP-113 対応に対する他の Treasury Withdrawal や Catalyst 資金はない。

**結論**:92.7K ADA で、3提案 Ledger セット中もっとも小さく、もっとも効果が大きい。セット中、最も自信を持って YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 21. Eryx: Zero-Knowledge Capabilities

- Proposal ID: 69fd0b20b05ff80adc7d5c55
- Requested: 3,489,366 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd0b20b05ff80adc7d5c55
- Category: Research / ZK / FV
- Applicable criteria: C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. At minimum, demand still cannot be verified, and technical concerns raised by engineers have ultimately not been addressed.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 少なくとも依然として需要を検証できません。 また、 技術者からの懸念にも最終的にまだ対処されていません。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. I apologize for the confusion regarding the criteria. This was a configuration error on my part: research-type proposals should have C8 applied. If C9 is excluded, then the proposal's adoption capability would be judged by C8, but I think this would have automatically led to a somewhat difficult conclusion, so I do not think this works to your proposal's disadvantage. If one logically pushes "demand cannot be shown until supply is in place" to its conclusion, then any infrastructure or research proposal, including worthless ones, would be equally justified.

I thought a little about what this demand might be — for example, couldn't you present something like the ZK Bridge you are building as one example? In my rough understanding, the ZK Bridge is built with your own in-house tools, but had this proposal's common tooling existed, it would have cut costs by XX and sped up development by about XX, and so on.

In other words, could you provide something like the following?

1. A concrete adoption plan from your own pipeline — e.g., ZK Bridge, ZK Login, or Proof of Innocence committing to use WP1 (PLONK/SnarkJS verifier), WP2 (RISC Zero on BLS12-381), or the productionised aiken-zk.
2. Any named Cardano team that has requested these primitives or is blocked on their absence.
3. Adoption signals on the existing aiken-zk (the WP3 base): installs, integrations, external contributors, or projects building on it today.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。基準についての混乱をお詫びします。これは私の設定ミスで、研究系はC8を適用されるべきです。仮にC9を除外するとC8で提案書の採用能力を判定することになりますがこれは自動的に少し困難な結論が導かれていたと思いますのでこれはあなたの提案書に不利に作用しないと思います。「供給ができるまで需要は示せない」を論理的に突き詰めると、いかなるインフラや研究の提案も、無価値なものを含めて等しく正当化されてしまいます。

私は少しこの需要が何かについて考えてみましたが、例えば、あなたが作成しているZK Bridgeなどを1つの例として出すことはできないのでしょうか?私の雑な理解では、ZK Bridgeはあなたの自前のツールで構築していますが、この提案書の共通ツールがあれば、XXのコスト削減とXXほど開発が早まったなど。

つまり次のようなものを提供することはできますか?

1. A concrete adoption plan from your own pipeline — e.g., ZK Bridge, ZK Login, or Proof of Innocence committing to use WP1 (PLONK/SnarkJS verifier), WP2 (RISC Zero on BLS12-381), or the productionised aiken-zk.
2. Any named Cardano team that has requested these primitives or is blocked on their absence.
3. Adoption signals on the existing aiken-zk (the WP3 base): installs, integrations, external contributors, or projects building on it today.

### Prior detailed analysis (EN)

**Categorisation**: [Research / ZK]. Non-applicable: C1, C2 (Eryx team has Cardano track record per prior funded projects), C3, C4, C5 (PLONK/RISC Zero/Aiken ZK primitives don't necessarily duplicate active TWs), C6, C7, C10, C11.

**Applicable: C8, C9**. Applying:

• **C8 — Past funded projects' adoption unverifiable**: Per /tx-roi backend, Eryx (Cooperativa de Trabajo Eryx) has 1 prior Catalyst = 200K ADA. Separately, Eryx has a ZK Bridge TW (gov action id 38, ₳700,000 face, ratified epoch 575). Adoption metrics for the prior funded work (Cardano builder downloads, integration count, live mainnet usage) are not presented in the current proposal. 

  Per @perturbing's Ekklesia comment, multiple of the four proposed Year-1 contributions are problematic on their own terms (not just adoption): (i) PLONK verifier in Aiken — perturbing/plutus-plonk-example already exists (a port to Aiken is non-trivial but trivial-research-wise); (ii) RISC Zero zkVM → BLS12-381 — non-trivial scalar-field conversion risk (stark argument over wrong-sized scalar field); (iii) Aiken ZK extensions — existing aiken/crypto/bls12_381 stdlib raises sufficiency question; (iv) Semaphore — standard ZK primitive with no Cardano-specific demand signal in proposal.

• **C9 — Demand from any Cardano builder unverifiable**: PLONK verifier (tool), RISC Zero integration (infrastructure), Aiken ZK extensions (tool maintenance), Semaphore V4 (primitive) are all building blocks for builders to use, not direct tx/TVL generators on their own. Without identifying ≥1 named Cardano builder committing to use these, the scope-to-adoption gap is wide.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [Research / ZK]。 非適用: C1, C2 (Eryx team は prior funded project より Cardano track record あり), C3, C4, C5 (PLONK/RISC Zero/Aiken ZK primitive は active TW と必ずしも重複せず), C6, C7, C10, C11。

**適用: C8, C9**。 適用:

・**C8 — 過去 funded project の adoption 検証不能**: /tx-roi backend より、 Eryx (Cooperativa de Trabajo Eryx) は 1 prior Catalyst = 200K ADA。 別途 Eryx は ZK Bridge TW (gov action id 38, ₳700,000 face, epoch 575 ratified) を持つ。 過去 funded work の adoption metric (Cardano builder downloads, integration count, live mainnet usage) は現提案書に提示なし。

  @perturbing の Ekklesia コメントによれば、 提案される 4 つの Year-1 contribution 自体に問題点あり (adoption 不在だけではない): (i) PLONK verifier in Aiken — 既存の perturbing/plutus-plonk-example が存在 (Aiken への port は trivial-research-wise); (ii) RISC Zero zkVM → BLS12-381 — wrong-sized scalar field 上の stark argument 変換 risk が non-trivial; (iii) Aiken ZK extensions — 既存 aiken/crypto/bls12_381 stdlib に対し十分性質問; (iv) Semaphore — 標準 ZK primitive で Cardano-specific demand signal なし。

・**C9 — Cardano builder からの demand 検証不能**: PLONK verifier (tool), RISC Zero integration (infra), Aiken ZK extensions (tool maintenance), Semaphore V4 (primitive) は builder が使う building block で direct tx/TVL generator ではない。 これらを使う commit を持つ named Cardano builder ≥1 を identify しない限り、 scope-to-adoption gap が広い。

よって本提案はこれらを満たさない。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd0b20b05ff80adc7d5c55#comment-6a05f5fb038cf72ed1e64e79
- Summary (EN): On C9: notes internal inconsistency — the linked policy excludes C9 for 'Research/ZK/FV' kind, which is how the AI categorized them. On C8: defends track record (Proof of Innocence as PoC, Aiken-ZK new and self-tested, ZK Login just finished, ZK Bridge near-finished months ahead of schedule); says they are a newer Cardano team actively building the track record.
- Summary (JA): C9について: 内部整合性の問題を指摘 — 添付ポリシーは「Research/ZK/FV」分類ではC9除外とされており、AIも本提案をこのカテゴリに分類した。C8について: 過去実績を擁護 (Proof of InnocenceはPoC、Aiken-ZKは新しく内部検証中、ZK Loginは完了、ZK Bridgeはスケジュール前倒しでほぼ完了)、Cardano新参として実績を積み上げ中。

Full text:

Hi, Yuta! Thank you for the review, and thank you for making the rationale available.

On C9:
There might be an internal inconsistency in the applied rationale. The policy you linked explicitly excludes C9 from the "Research / ZK / FV" kind, which is also the category this proposal was flagged as by the AI you used. Since the proposal is categorized as "Research / ZK", C9 should not apply (under that framework). Is this right? Beyond the framework question, ZK infrastructure is something every major competing blockchain is actively investing in. The demand is well established by the industry, already.

On C8:
Let's start with our past projects' adoption. Proof of Innocence was openly meant to be a proof of concept, yes. However, our Aiken-ZK work is relatively new and we are testing it ourselves before further pushing it and putting more work into it (partly in this same proposal). ZK Login has just been finished, and the ZK Bridge is close to being finished, too (months ahead of schedule, even with the ADA decline). We have not yet had time to make further plans for these, or to see how they would be best applied. As a newer company in the Cardano developers community, we are actively building that track record, and this proposal is part of that.
We also think that what the rationale says about @perturbing's comment does not apply. Our arguments and rationale are all in that comment's reply. I would copy them here, but due to the character limit and the fact that the discussion might still evolve, I would prefer you to check the replies directly in that thread.

We hope this addresses your concerns and follows your AI's rationale. Please let us know what you think.
Thanks again for your comments!

#### Feedback 2 — source: twitter, author: eryxcoop
- Author note: CONFIRMED: Eryx team, tweet says "our proposal" in Japanese
- URL: https://twitter.com/eryxcoop/status/2059710373402403090
- Summary (EN): Eryx founder posts Japanese rebuttal: argues YUTA's pushback on C8 is misplaced — Proof of Innocence was deliberately a PoC, other ZK work shows active track-record building.
- Summary (JA): Eryx創業者が日本語で反論: C8への指摘は的外れ、Proof of InnocenceはあえてPoC、その他ZK作業で実績を積み上げ中。

Full text:

@yutazzz こんにちは、Yutaさん!レビューとその根拠をお送りいただきありがとうございます。 私たちは、私たちの提案に対するあなたの反論は的外れだと考えており、その理由を以下に説明します: — C8について:「過去の資金提供プロジェクトの採用状況が確認不可能」 私たちの過去のプロジェクトの採用状況について。Proof of Innocenceは概念実証として公式に位置づけられていたことは事実です。しかし、私たちのAiken-ZKの取り組みは比較的新しく、さらに推進し、より多くの作業を投入する前に(この提案の一部も含めて)自分たちでテストしているところです。ZK Loginは完成したばかりであり、ZK Bridgeも完成に近づいています(ADAの下落があったにもかかわらず、スケジュールより数ヶ月早く進んでいます)。これらについてはまだ今後の計画を立てたり、最適な活用方法を検討したりする時間がありませんでした。Cardano開発者コミュニティにおける新興企業として、私たちは積極的にその実績を積み上げており、この提案もその一環です。 RISC Zeroのワークパッケージについては、すべての実装リスクは事前調査で考慮済みであり、すべての不確実性をできるだけ早期に解決できるようマイルストーンを設定しました。実際、最初の2つのマイルストーンで対処します。 Semaphore(https://t.co/U03SOHOjJd)とRISC Zero(Wormhole、Blobstream Zero、Taiko、Steel、EZKL、Hibachi)の両方を基盤として構築されたプロジェクトがすでに存在しており、それらがCardanoに移行または導入される可能性があるため、その価値は明らかです。 PLONKについては、一部のプリミティブが不足しているため、Aikenへの移植に最適化が必要です。また、私たちの実装は独自に開発・レビューされます(移植ではありません)。 — C9について:「Cardanoビルダーからの需要が確認不可能」 適用された根拠に内部矛盾がある可能性があります。あなたがリンクしたポリシーは、C9を「Research / ZK / FV」種別から明示的に除外しており、これはあなたが使用したAIによってこの提案に付与されたカテゴリでもあります。提案が「Research / ZK」に分類されている以上、(そのフレームワークの下では)C9は適用されないはずです。この理解は正しいでしょうか?
フレームワークの問題を超えて、ZKインフラストラクチャは主要な競合ブロックチェーンエコシステムがすでに投資しているものです。プライバシー、スケーラブルな検証、および検証可能なオフチェーン計算はすでに業界で展開・活用されています。 Ethereumにはすでに成熟したZKエコシステムがあり、多くのプロジェクトがゼロ知識証明を活用して構築されています(zkSync、Starknet、Scroll、Polygon zkEVM、Aztec)。Solana(Light Protocol)やBitcoin(Citrea、Alpen Labs、ZKロールアップ研究)も参入しています。 現在、CardanoにはZKインフラストラクチャ層が欠如しています。Cardanoにおける観測可能なZK開発者活動が少ないのは、ZK技術に対する需要がないからではなく、ツールとインフラが不足しているからです。実際には、ZK開発者はそれらが揃っているエコシステムを選びます。 同時に、ZK自体に対する需要は業界全体ですでに確立されています。特にZK技術がスケーラビリティ、プライバシー、相互運用性、次世代ブロックチェーンアプリケーションにとって中心的な存在になりつつある今、Cardanoがこの分野で遅れを取らないことは戦略的に重要だと考えます。 — また、この提案はチームがAiken ZKやその他の進行中の暗号技術の取り組みを含め、Cardanoエコシステムにおいてすでに公開・検証可能なZK関連ツールとインフラの構築経験を持っているため、多くの研究志向のイニシアチブと比較して実行リスクを低減すると考えています。 現在の暗号業界における主要な論点は、プライバシーなしには採用はあり得ないというものです。ZcashがCardanoの時価総額を最近上回り、Ethereumがプライバシーインフラストラクチャと研究に数百万ドルを投資しているのはそのためです。また、CardanoにZKインフラがなければ、プライバシーを絶対条件とする機関や企業からの実質的な採用を達成することはできません。Cardanoは今日のように100%パブリックなブロックチェーンであり続けることも可能ですが、Layer 1でプライバシーとスケーラビリティを実現するために必要なZKインフラを構築することを選択した方が良いと私たちは考えます。ご懸念にお答えできたことを願い、投票の再考をお願いします。この件についてさらに議論できることを喜んでいます! 改めてコメントありがとうございます!

AIにより翻訳

---

## 22. Dano Finance: DeFi Kernel, American Options, and Orderbook SDK

- Proposal ID: 69fdc9b261c4f060e2fef6c9
- Requested: 3,399,000 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdc9b261c4f060e2fef6c9
- Category: dApp - DeFi
- Applicable criteria: C1, C3, C6, C7, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

I have changed Dano Finance from NO to Abstain based on feedback. This may contribute to a more efficient DeFi experience and increased transactions. However, I would like to re-examine the evidence for this demand, etc.

### Voting reason (JA, as of 2026-05-28)

Dano Finance はフィードバックを受けて NO → Abstain に変更しました。 これは効率的な DeFi 体験と Tx 増加に貢献する可能性がありますが、 需要などの根拠を再検証したいため。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: This proposal falls under [dApp-DeFi / orderbook]. Non-applicable: C2 (founders are established Cardano DeFi contributors), C4 (Treasury return considered secondary for this kind in my framework), C8 (no prior cycles to attribute), C10 (3.4M ADA ≈ 0.97% of NCL — below scrutiny band), C11 (not secondary-DAO).

**Applicable criteria: C1, C3, C5, C6, C7, C9**. Applying each:

• **C1 — Tx/TVL contribution materiality**: $10M aggregate TVL across 10 protocols ≈ $500K average each, achievable through temporary farming incentives. Proposal lacks: (a) increment vs current ~$132M Cardano DeFi TVL (per DefiLlama April 2026 = 7.6% increment, but achievable via farming dilution), (b) durability metrics beyond a 30-day trailing average, (c) Treasury ROI metrics such as protocol fee revenue or holder-diversity measures. The 30-day-ish farming-incentivized TVL pattern is well-documented across L1s as 'mercenary capital' that exits when farming ends.

• **C3 — KPI = outcome with causal attribution**: Headline TVL is achievable through farming campaigns; the proposal does not commit to retention metrics (TVL persistence after farming-incentives end) or holder-diversity measures or per-protocol volume targets. No causal attribution between Treasury investment and durable TVL retention.

• **C5 — Functional duplication with existing AMM ecosystem**: Cross-check existing Cardano DEXes (all Tier A — funded and live in production):
  - **Minswap** (per ADAtool db-sync tx_label.minswap = 31.4M tx all-time) — established AMM
  - **SundaeSwap** (7.5M tx all-time) — established AMM
  - **WingRiders** (4.7M tx all-time) — established AMM
  - **Splash / Splash Protocol** (combined 6.1M all-time) — orderbook-AMM hybrid
  - **Spectrum / VyFinance / Steelswap / MuesliSwap** — additional AMMs
  - **DexHunter** — aggregator (4.1M all-time, aggregating across all of the above)
  Functional substitution by AMM aggregator pattern (DexHunter routing) is empirically present at scale. Pure-orderbook differentiation positioning needs to demonstrate substitution-resistance.

• **C6 — L1 feasibility**: Cardano L1 has ~20-second block time (per Ouroboros Praos parameters) + per-tx fees on every order/cancel (~0.17 ADA ≈ $0.04 per ADAtool epoch data). Active market-making at typical professional-MM frequency requires sub-second order updates — economically impossible at L1 fees. **Empirical reference**: tx_label.muesliswap shows last_6m / all-time activity ratio of ~0.78% (per ADAtool db-sync) — MuesliSwap's pivot away from pure orderbook design produced empirical activity collapse, not just strategic re-positioning. The structural constraint is empirically demonstrable.

• **C7 — CoI safeguards**: Founding contributors (Dano Finance, Fallen Icarus per proposal) can plausibly become funding recipients through protocols they author or operate. The proposal commits to publishing CoI rules but does not specify exclusion thresholds, allocation caps for member-affiliated protocols, or independent review requirements. 'Will be published' is not a verifiable governance commitment, and capture resistance cannot be assessed from the document as written.

• **C9 — Thesis validation (decisive)**: Core thesis — that institutional, self-custodial, censorship-resistant settlement demand exists on Cardano specifically — is asserted but not evidenced. No pilot results, institutional letters of intent, or market sizing analysis are provided. Per 2026-05-10 X community search across Cardano DEX/institutional traffic discussion, no demand signal for institutional-grade self-custodial CLOB on Cardano was surfaced in 21-day window. Committing 3.4M ADA before small-scale validation inverts the normal order of risk.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: 本提案は [dApp-DeFi / orderbook] に該当。 非適用: C2 (founder は established Cardano DeFi contributor), C4 (本 kind で Treasury return は secondary), C8 (attribute する prior cycle なし), C10 (3.4M ADA ≈ NCL の 0.97% — scrutiny 帯以下), C11 (二次配布 DAO でない)。

**適用基準: C1, C3, C5, C6, C7, C9**。 各々あてはめ:

• **C1 — Tx/TVL 寄与度**: $10M を 10 protocol 横断で平均 $500K 各々、 farming incentive で達成可能。 提案書欠如点: (a) 現 Cardano DeFi TVL ~$132M (DefiLlama 2026年4月 = 7.6% 増分、 但し farming dilution で達成可能), (b) 30 日 trailing avg を超える durability metric なし, (c) protocol fee revenue や holder diversity 等 Treasury ROI metric なし。 30 日前後の farming-incentivized TVL pattern は L1 横断で 'mercenary capital' として well-documented (farming 終了で exit)。

• **C3 — KPI = outcome with causal attribution**: Headline TVL は farming campaign で達成可能; 提案書は farming incentive 終了後の retention metric, holder diversity, per-protocol volume target を commit せず。 Treasury 投資と durable TVL retention の causal attribution なし。

• **C5 — 既存 AMM ecosystem との機能重複**: 既存 Cardano DEX (全て Tier A — funded で live in production) と cross-check:
  - **Minswap** (ADAtool db-sync tx_label.minswap = 全期間 31.4M tx) — established AMM
  - **SundaeSwap** (全期間 7.5M tx) — established AMM
  - **WingRiders** (全期間 4.7M tx) — established AMM
  - **Splash / Splash Protocol** (合計全期間 6.1M) — orderbook-AMM hybrid
  - **Spectrum / VyFinance / Steelswap / MuesliSwap** — 追加 AMM
  - **DexHunter** — aggregator (全期間 4.1M、 上記全てを aggregate)
  AMM aggregator pattern (DexHunter routing) による functional substitution は scale で empirically 存在。 Pure-orderbook 差別化 positioning は substitution-resistance を demonstrate 必要。

• **C6 — L1 実現可能性**: Cardano L1 は block time ~20 秒 (Ouroboros Praos parameter より) + 注文/取消毎 fee (~0.17 ADA ≈ $0.04 per ADAtool epoch data)。 typical professional-MM 頻度の active market-making は sub-second order update を要求 — L1 fee で economically 不可能。 **Empirical reference**: tx_label.muesliswap の last_6m / 全期間 活動比率 ~0.78% (ADAtool db-sync より) — MuesliSwap の pure orderbook design からの pivot は empirical 活動崩壊を生んだ (単なる戦略再配置ではなく)。 Structural 制約は empirically demonstrable。

• **C7 — CoI safeguards**: 創設 contributor (Dano Finance, Fallen Icarus per proposal) が author/operate する protocol 経由で受益者になり得る。 提案書は CoI rules publish を commit するが exclusion threshold / member-affiliated protocol への allocation cap / independent review 要件を specify せず。 'Will be published' は検証可能な governance commitment ではなく、 capture resistance は記載通りでは評価不能。

• **C9 — Thesis 検証 (決定的)**: Core thesis — Cardano 特に institutional, self-custodial, censorship-resistant settlement demand 存在 — は assertion で evidence なし。 Pilot result, institutional LOI, market sizing analysis 提示なし。 2026-05-10 X community search で Cardano DEX/institutional traffic 議論を 21 日 window で横断した結果、 institutional-grade self-custodial CLOB demand signal は surface せず。 Small-scale validation 前に 3.4M ADA commit は通常の risk 順序を反転。

よって本提案はこれらを満たさない。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 23. GOV.EXE by TxPipe & gf Consulting Group: Public Project Execution Integrity, Pilot in Argentina

- Proposal ID: 69fd1b97e1ab5d003a0cab6f
- Requested: 3,006,828 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd1b97e1ab5d003a0cab6f
- Category: dApp - other
- Applicable criteria: C1, C4, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Strong team, but this investment is likely high-risk / low-return as currently structured.

The proposers acknowledge the proposal alone does not generate meaningful Tx, and hint that meaningful Tx might emerge IF the pilot succeeds AND various follow-on projects horizontally replicate.

Multiple high-risk dependencies must hold:

1. Even if the pilot succeeds, continued adoption is not guaranteed.
2. Even with continued adoption, Tx is minimal and horizontal replication is not guaranteed (and is out of scope).
3. Even with horizontal replication, no guarantee Tx volume reaches a level that recoups the 3M ADA investment.
4. The case for needing an L1 blockchain at all is weak. There are countless ways to produce tamper-resistant audit trails; using a public L1 specifically requires the demand 'this audit trail must be independently verifiable even against the Argentine government itself.' That demand is not evidenced in the proposal. The X-Road precedent the proposal cites is itself not a public blockchain — reinforcing the point.
5. Even granting that L1 is needed, the proposal does not explain why Cardano specifically. Any Ethereum-family L1 works. If the choice is funding-availability rather than technical necessity, Cardano could easily be replaced during horizontal replication.

### Voting reason (JA, as of 2026-05-28)

素晴らしいチームがいますが、 この投資は現状高リスク低リターンである可能性が高いと見込んでいます。

提案者は提案書単体で優位な Tx が生成されないことを認めており、 仮にこの提案書が成功した後に様々なプロジェクトが水平展開されたら、 優位な Tx を生成できる可能性があると示唆しています。

これは様々な高リスクの問題を対処する必要があります:

1. 仮にこのプロジェクトが成功しても、 継続的に採用される保証はない。
2. 継続的に採用されても Tx は僅かであり、 水平展開される保証はなく、 それは提案書のスコープ外。
3. 仮に水平展開されても、 300 万 ADA の投資を回収できるレベルで Tx が発生する保証はない。
4. そもそも L1 ブロックチェーンの必然性のロジックは弱い。 改竄不能な監査証跡を手にする手段は無数にあり、 特に L1 を使う意味は『この監査証跡は Argentina 政府自身からも独立して検証可能でなければならない』という需要が必要だが、 その需要を示す根拠は提案書から読み取れない。 提案書が挙げる X-Road の先例がパブリックブロックチェーンではないこともこれを補強する。
5. 百歩譲って L1 が必要だとしても、 なぜ Cardano なのか提案書は説明していない。 Ethereum 系の L1 はすべて対応可能。 技術的必然ではなく資金源が Cardano Treasury だからである場合、 水平展開の際に Cardano が削ぎ落とされる可能性も否定できない。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; weighing the returns such as Tx that this initiative would generate against the large empirical risks associated with this kind of initiative, it still appears to me to be relatively high-risk.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます、依然としてこの取り組みが生み出すTx等のリターンと、このような取り組みに関連する経験的な大きなリスクのバランスから見て、相対的にリスクが高いように思えています。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-other / government pilot]. Non-applicable: C2 (TxPipe has Cardano track record), C3, C5, C6, C7, C10, C11.

**Applicable: C1, C4, C8, C9**. Applying:

• **C1 — Tx contribution structurally negligible**: The Secretariat of Modernization of Entre Ríos processes an estimated 50-150 projects/year (based on public LatAm provincial-government scale). Per-project tx generation for traceability/verification is typically 5-20 events/lifecycle. Result: ~21-63 tx/month = **0.003-0.008% of Cardano's monthly 800K tx** baseline. Proposal contains no specific numerical commitment.

• **C4 — Treasury recovery on astronomical timescale**: Repayment is limited to the 19.4% contingency as ADA price hedge, with no commercial revenue share. Tx fee recovery calculation (at Cardano current ~0.17 ADA/tx ≈ $0.04 fee, net Treasury share ~50%):
  - Entre Ríos solo (~50 tx/month × $0.02 fee × 50% Treasury share = $0.50/month): recovery period ~13,000-55,000 years for 653K ADA grant
  - LatAm-wide deployment (assuming 100× scale-up): ~38 years
  Effectively a permanent grant structure.

• **C8 — TxPipe domain transfer concern**: Per /tx-roi, TxPipe has strong delivery track record on builder infrastructure (Pallas, Oura, UTxO RPC, Dolos — 26 Catalyst proposals + 663K TW = 4.53M ADA cumulative; per Intersect TW: 9/10 milestones delivered). However, GOV.EXE is gov-pilot domain — distinct from builder-tooling delivery. Domain transferability is uncertain; track record is not directly applicable.

• **C9 — Government blockchain pilot historical success rate**: Pilot completion ≠ production deployment ≠ replication. Government blockchain pilots historically have low conversion-to-production rates (e.g., Sweden Lantmäteriet land registry pilot 2017-2018 ended without production deployment; Estonia X-Road is exception, not norm). As Treasury investment, this falls into a high-failure-rate category.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-other / 政府 pilot]。 非適用: C2 (TxPipe Cardano track record あり), C3, C5, C6, C7, C10, C11。

**適用: C1, C4, C8, C9**。 適用:

・**C1 — Tx 寄与構造的 negligible**: Entre Ríos Secretariat は ~50-150 projects/年 処理 (LatAm 州政府 scale 公開情報より)。 Per-project tx 生成は traceability/verification で 5-20 events/lifecycle。 結果: ~21-63 tx/月 = **Cardano 月次 800K の 0.003-0.008%**。 提案書 specific 数値 commitment なし。

・**C4 — Treasury 回収 astronomical timescale**: Repayment は 19.4% contingency を ADA price hedge に限定、 commercial revenue share なし。 Tx fee 経由回収計算 (Cardano 現 ~0.17 ADA/tx ≈ $0.04 fee, net Treasury share ~50%):
  - Entre Ríos solo (~50 tx/月 × $0.02 fee × 50% Treasury share = $0.50/月): 653K ADA grant 回収期間 ~13,000-55,000 年
  - LatAm 全域 deployment (100× scale-up 仮定): ~38 年
  実質永久 grant 構造。

・**C8 — TxPipe 領域 transfer concern**: /tx-roi より TxPipe は builder infra で strong delivery track record (Pallas, Oura, UTxO RPC, Dolos — 26 Catalyst + 663K TW = 4.53M ADA 累積; Intersect TW より 9/10 milestones delivered)。 但し GOV.EXE は gov-pilot 領域 — builder-tooling delivery と distinct。 領域 transferability uncertain; track record は直接 applicable でない。

・**C9 — 政府 blockchain pilot 歴史的成功率**: Pilot 完了 ≠ production deployment ≠ replication。 政府 blockchain pilot は歴史的に conversion-to-production 率低 (例: Sweden Lantmäteriet 土地登記 pilot 2017-2018 は production deployment なしで終結; Estonia X-Road は exception で norm ではない)。 Treasury 投資として high-failure-rate category。

よって本提案はこれらを満たさない。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd1b97e1ab5d003a0cab6f#comment-6a05f84af4bf5dd313f5cef1
- Summary (EN): Proposer argues GOV.EXE's value lies not in a single Entre Rios pilot's transaction ROI but in validating a replicable institutional pattern for LATAM public-sector adoption, with each anchored administrative state transition generating recurring on-chain activity, and points to replicability metrics as the key area for scrutiny.
- Summary (JA): 提案者は、GOV.EXEの価値は単一のEntre Riosパイロットの取引ROIではなく、ラテンアメリカの公共部門採用の再現可能な制度パターンを検証する点にあり、アンカーされた各行政状態遷移が継続的なオンチェーン活動を生むと主張し、再現性の指標こそが精査の鍵だと指摘している。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C1, C4, C8, C9).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

**English**

Your analysis makes sense if GOV.EXE is measured only as an isolated pilot in Entre Ríos. However, in Latin America, the strategic value lies in validating a replicable institutional pattern.

Public auditability software for municipalities and provinces can scale through horizontal adoption: once the model is proven in one jurisdiction, others can adopt it with lower implementation costs. If each administrative state transition is anchored on Cardano, each additional institution would generate recurring on-chain activity.

In that sense, the real risk is not only technical execution, but replicability. That is where I would place the strongest scrutiny: post-pilot metrics, evidence of interest from additional jurisdictions, and whether the open-source framework is truly reusable by other Cardano builders.

So I understand the concern about direct transaction ROI from a single pilot, but I think the broader LATAM context matters. The value of this proposal should not be evaluated only by the first jurisdiction’s transaction volume, but also by its potential to create a reusable public-sector adoption model for Cardano.

#### Feedback 2 — source: hydra, author: diegomac
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd1b97e1ab5d003a0cab6f#comment-6a0b8dfd05e47100cbda5bd1
- Summary (EN): Proposer (diegomac) says the proposal was updated and addresses the domain-transferability concern by explaining the intentional division of labor between TxPipe (technical layer) and GF Consulting (government adoption layer), and cites TxPipe's 20-year track record including three years building/maintaining Buenos Aires' MiBA citizen-services app.
- Summary (JA): 提案者(diegomac)は提案を更新したと述べ、ドメイン転用可能性の懸念に対し、TxPipe(技術層)とGFコンサルティング(政府採用層)の意図的な役割分担を説明し、ブエノスアイレスの市民サービスアプリMiBAの3年間の構築・保守を含むTxPipeの20年の実績を引用している。

Full text:

Hi Yuta, thanks for the review and for taking the time to engage publicly.

We've updated the proposal since your initial vote to better reflect the value creation mechanisms and be transparent about the pilot's by-design limitations. Please let us know when you have some time to look at it again.

A few points we'd like to put on the record for your consideration:
**1- On domain transferability and TxPipe's role**
This is the most valid concern we've received, and we want to address it directly: TxPipe's track record is in builder infrastructure, and that's precisely why we structured this as a partnership with GF Consulting. The division of responsibility is intentional: TxPipe owns the technical layer (tooling, smart contracts, Cardano integration), and GF Consulting owns the government adoption layer; they bring the institutional relationships, the public-sector navigation experience, and the existing contacts with Entre Ríos's Secretariat of Modernization. Neither partner alone could deliver both sides of this proposal.

That said, TxPipe has been developing software for 20 years and has worked extensively with both the private and public sectors. In this regard, one notable project was the development and maintenance, over a period of three years, of the[ MiBA app](https://buenosaires.gob.ar/gcaba_historico/app-miba?utm_source=chatgpt.com), the application through which all citizen services for Argentina’s capital city are managed: [https://buenosaires.gob.ar/gcaba\_historico/app-miba](https://buenosaires.gob.ar/gcaba_historico/app-miba). 

(continue)

#### Feedback 3 — source: hydra, author: diegomac
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd1b97e1ab5d003a0cab6f#comment-6a0b8e1f0dcaa7f9767cd513
- Summary (EN): Proposer (diegomac) clarifies it is not claiming structural network-transaction contribution from the pilot itself, framing GOV.EXE as a vertical-opening investment whose value compounds through lasting outputs (open-source platform, endorsed case study, builder sessions, LATAM prospecting), with treasury repayment coming from the public-sector workstream it opens rather than the pilot.
- Summary (JA): 提案者(diegomac)はパイロット自体からネットワーク取引への構造的貢献を主張しているのではないと明確化し、GOV.EXEを垂直市場開拓投資と位置づけ、その価値は持続的な成果物(オープンソースプラットフォーム、承認されたケーススタディ、ビルダーセッション、ラテンアメリカの見込み開拓)を通じて複利的に増大し、トレジャリーへの返済はパイロットではなく開拓される公共部門のワークストリームから生じると説明している。

Full text:

**2- On what we are (and aren't) claiming**
We are not claiming structural contribution to network transactions through the pilot itself. GOV.EXE is a vertical-opening investment. The value compounds through the outputs that outlast the pilot: the open-source platform, the Secretariat-endorsed case study, builder working-group sessions, and LATAM prospecting briefings using real pilot results. These are the mechanisms that travel beyond Entre Ríos.
Repayment to the treasury, in any meaningful sense, would come not from this pilot's direct outputs but from the public-sector workstream it opens — if the vertical proves viable and additional builders or jurisdictions adopt the pattern.

---

## 24. DeFi Rails & Deployment Pilot Program

- Proposal ID: 69fb674589371182537b309c
- Requested: 2,950,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb674589371182537b309c
- Category: BD network
- Applicable criteria: C2, C3, C4, C7, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; if there is no experience in the Cardano space, I think you need either to add someone who has it to the team, or to narrow the scope as a first attempt. In addition, the treasury returns and on-chain outcome-target signals are still not clear.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます、Cardano分野の経験がない場合、それがある人物をチームに追加するか、あるいは初回としてはスコープを縮小する必要があると思えています。また、トレジャリーリターンやオンチェーンの成果目標シグナルなどが依然として明確ではありません。

### Prior detailed analysis (EN)

**Categorisation**: [BD network]. Non-applicable: C1, C5, C6, C9, C10, C11.

**Applicable: C2, C3, C4, C7, C8**. Applying:

• **C2 — Cardano-native track record 'N/A'**: Per /tx-roi backend, prior Cardano funding 'N/A'. Team experience cited: Polygon, ZKsync, Outlier Ventures, Polkadot — same template as Magenta Labs (Budget #69 NO).

• **C3 — Process KPIs only**: All milestone-tied KPIs are process metrics:
  - 50+ screened (intake count)
  - 20+ LOIs (commitment-letter count)
  - 10+ 'in deployment or activation' (loose definition)
  - 4 reports (deliverable count)
  Definition of 'opportunities in deployment' is loose: counts 'testnet preparation', 'funding review started', 'liquidity route preparation' — none of these are actual Tx/TVL contribution commitments.

• **C4 — No Treasury return**: Same BD-as-grant pattern. No revenue share, fee return, or repayment.

• **C7 — Counterparty opacity**: WP4 'two-layer evidence model' restricts named counterparty/LOI evidence to administrators and designated reviewers. DReps see only aggregated progress, making empirical KPI verification at DRep level impossible. Same pattern as Magenta proposal.

• **C8 — Combined with C2 absence**: 'N/A' Cardano funding history means C8 cannot be evidence-applied; combined with C2 lack of Cardano delivery record, the proposer is asking Cardano Treasury to fund Cardano-central BD work as their first Cardano engagement.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [BD ネットワーク]。 非適用: C1, C5, C6, C9, C10, C11。

**適用: C2, C3, C4, C7, C8**。 適用:

・**C2 — Cardano-native 実績 'N/A'**: /tx-roi backend より、 prior Cardano funding 'N/A'。 提案書 cited team experience: Polygon, ZKsync, Outlier Ventures, Polkadot — Magenta Labs (Budget #69 NO) と同 template。

・**C3 — Process KPI のみ**: 全 milestone-tied KPI は process metric:
  - 50+ screened (intake 数)
  - 20+ LOIs (commitment-letter 数)
  - 10+ 'in deployment or activation' (loose definition)
  - 4 reports (deliverable 数)
  'opportunities in deployment' 定義は loose: 'testnet preparation', 'funding review started', 'liquidity route preparation' を count — いずれも actual Tx/TVL contribution commitment ではない。

・**C4 — Treasury return なし**: 同 BD-as-grant pattern。 Revenue share / fee return / repayment なし。

・**C7 — Counterparty 不透明**: WP4 'two-layer evidence model' が named counterparty / LOI evidence を administrator + designated reviewer に制限。 DRep は aggregated progress のみで DRep level での empirical KPI 検証不能。 Magenta 同 pattern。

・**C8 — C2 欠如と combine**: 'N/A' Cardano funding history は C8 を evidence-apply できない; C2 の Cardano delivery record 欠如と combine し、 提案者は Cardano Treasury に Cardano 中核 BD work を first Cardano engagement として fund 要求。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb674589371182537b309c#comment-6a049b03f4bf5dd313f5ceea
- Summary (EN): Acknowledges concerns (Cardano-native delivery evidence, process vs outcome KPIs, counterparty verifiability, COI safeguards, treasury protection). Reframes as execution-oriented, not generic BD; added documented KPI targets, explicit RE2 continuation gates, sharper Treasury protection. Concedes Magenta Labs is a new Cardano delivery actor and proposes mitigations via milestone-gating and external validation.
- Summary (JA): 懸念 (Cardano-native納品実績/プロセスKPI vs 成果KPI/カウンターパーティ検証可能性/COI/トレジャリー保護)を認識。汎用BDではなく実行型と再定義し、KPI数値・RE2継続ゲート・トレジャリー保護を追加。Magenta LabsがCardano新参である点を明示し、マイルストーン段階交付と外部検証で緩和するとの方針。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C3, C4, C7, C8).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.


Thank you for your feedback, this is very useful and we appreciate the structured review. We understand the main concerns:
\* Cardano-native delivery evidence
\* Process KPIs vs outcome measurement
\* Counterparty verifiability
\* COI safeguards
\* Treasury protection

The intention behind the proposal is not generic BD activity, but execution-oriented work designed to help selected opportunities move toward real deployment, integration and measurable ecosystem usage.

We've already incorporated a first round of clarifications into the proposal, including documented KPI targets for counted opportunities, explicit RE2 continuation gates, and sharper Treasury protection mechanisms. 

We also want to acknowledge clearly that Magenta Labs is a new Cardano delivery actor. The mitigation is not to pretend otherwise, but to structure the program around milestone-gated delivery, evidence-based reporting and external validation wherever possible, while bringing execution experience and lessons learned from other ecosystems to contribute to the valuable work already happening across Cardano.

We're still working to capture additional feedback, refine how we communicate the execution standards and evidence requirements, and add supporting documents.

---

## 25. MLabs - TrueInventory: An accessible blockchain inventory for videogame developers

- Proposal ID: 69fc919e8a0de51b89857e19
- Requested: 2,922,885 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc919e8a0de51b89857e19
- Category: dApp - other
- Applicable criteria: C1, C3, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

GameFi Tx in the Cardano ecosystem is highly limited. Demand evidence must be supplied.

### Voting reason (JA, as of 2026-05-28)

Cardano エコシステムにおけるゲーム Fi の Tx は非常に限定されています。 需要の証拠を添付する必要があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. I can understand it to a certain extent, but the examples you raised are all cases of departure, and at the same time they appear to reinforce my argument. I think Paima Studio could also be added here. Wasn't it the case that GameFi departed not because tools were lacking, but because users were lacking? Of the Catalyst proposal tools you listed, one was not approved, one ended without being completed, and one has had no updates whatsoever for about five months — this too is suggestive about the market fit with GameFi. Ideally, would it be possible to submit this as an infrastructure proposal supporting a specific GameFi team, attached together with the details of that team's content?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。一定程度理解できますが、あなたがあげた例は、いずれも離脱例であり、同時に私の主張を補強しているように見えます。Paima Studioもここに加えても良いと思います。ツールが不足しているからGamefiが離脱した、のではなく、ユーザーが不足しているから離脱した、のではないでしょうか?挙げられたCatalyst提案書のツールも1つは承認されず、1つは完成せず終了し、1つは5ヶ月ほどアップデートが何もない状態で、これもGameFiとの市場適合性について示唆的です。理想的には、具体的なゲームFiチームを添えて、その内容とセットで、それを支えるインフラ提案として提出することは可能でしょうか?

### Prior detailed analysis (EN)

**Vote: NO** on MLabs - TrueInventory: blockchain inventory for videogame developers (**2.85M ADA / NCL 0.81%**).

**Main reasons**

**1. The proposal itself says no game studio has committed**
- Per proposal text: **"There is no specific game studio it is being built for."**
- Scope: 1.0 release with GameServer + GameClient + Claim HTTP APIs, audited smart contracts for tokenised items, and client libraries for Godot, Unity, and Unreal.
- Without a named studio, any projected transaction or TVL contribution is unverifiable.

**2. The Cardano gaming category has not generated sustained transactions**
- Per ADAtool db-sync archive (epochs 1-629), no Cardano-native game has produced substantial sustained transaction volume.
- Past Cardano gaming Catalyst funding has covered ~10+ proposals without producing a flagship game at scale.
- For comparison: Cardano DeFi (Minswap alone) = 31.4M transactions all-time; Cardano gaming = orders of magnitude smaller.

**3. Web3 gaming developers have settled on other chains**

| Chain | Gaming infrastructure | Status |
|---|---|---|
| **Solana** | SAGA mobile + multiple gaming studios | live, scaling |
| **Polygon** | Immutable, Ronin (Sky Mavis) | live, large historical volumes |
| **Avalanche** | gaming subnet (DFK Chain etc.) | live, dedicated subnet |
| **Cardano** | TrueInventory + a few legacy NFT-mint games | pre-traction |

Game developer mindshare has consolidated around chains with low fees and very fast UX. Cardano's eUTxO model is a legitimate technical differentiator but has not produced studio adoption in 3+ years of Cardano gaming Catalyst proposals.

**4. Cost per engine**
- 2.85M ADA across 3 engine targets (Godot + Unity + Unreal) = ~$237K USD per engine integration at ADA $0.25.
- Without a named studio, this is purely speculative infrastructure investment.

**5. Domain transfer risk for MLabs**
- MLabs's track record is strong in infrastructure and DSLs (Plutarch, Cardano.nix). Gaming is a different domain (engine integration, in-game economy design, player retention). Track-record transfer is unproven.

**Recommend resubmission** with: (a) at least one named gaming studio committing to TrueInventory with an explicit Cardano transaction / TVL projection, (b) cost breakdown per engine, (c) competitive analysis vs Immutable / Avalanche-subnet inventory standards that named studios already use.

### Prior detailed analysis (JA)

**Vote: NO** — MLabs - TrueInventory(**2.85M ADA / NCL 0.81%**)に NO。

**主な理由**

**1. 提案書自身が「特定のゲームスタジオは決まっていない」と明記**
- 提案書本文:**「特定のゲームスタジオ向けに作っているわけではない」**。
- 範囲:GameServer + GameClient + Claim 用 HTTP API、トークン化アイテムの監査済みスマートコントラクト、Godot / Unity / Unreal 用クライアントライブラリを含む 1.0 リリース。
- 採用スタジオの約束がない以上、見込みのトランザクション数や TVL 寄与は検証できない。

**2. Cardano のゲーム分野は持続的な取引を生んでいない**
- ADAtool db-sync(エポック 1-629):本番規模で持続的な取引量を持つ Cardano ネイティブのゲームはない。
- Cardano ゲーム関係の Catalyst 資金は過去 10件以上提供されているが、規模感のある旗艦ゲームは出ていない。
- 比較:Cardano DeFi(Minswap 単体)= 全期間 3,140万件。Cardano ゲーム全体はその数桁下。

**3. Web3 ゲーム開発者は他チェーンに集中している**

| チェーン | ゲーム基盤 | 状況 |
|---|---|---|
| **Solana** | SAGA モバイル + 複数スタジオ | 稼働中、拡大中 |
| **Polygon** | Immutable、Ronin(Sky Mavis) | 稼働中、歴史的に大きな出来高 |
| **Avalanche** | ゲーム用サブネット(DFK Chain など) | 稼働中、専用サブネット |
| **Cardano** | TrueInventory + 少数の旧 NFT 系ゲーム | 牽引前 |

ゲーム開発者の関心は、低手数料で UX が速いチェーンに集中している。Cardano の eUTxO モデルは技術的に正当な差別化要素だが、3年以上の Catalyst 投資でもスタジオ採用には至っていない。

**4. エンジン当たりの費用**
- 2.85M ADA / 3 エンジン(Godot + Unity + Unreal)= エンジン当たり 約 $237K USD(ADA $0.25 換算)。
- スタジオの約束がない以上、投機的な基盤投資。

**5. MLabs の領域転移リスク**
- MLabs の実績は基盤と DSL(Plutarch、Cardano.nix)に厚い。ゲームは別領域(エンジン統合、ゲーム内経済設計、プレイヤー継続率)。実績の移転は未検証。

**再提出推奨**:(a) TrueInventory 採用を約束する名前付きスタジオを1つ以上 + Cardano の取引 / TVL 寄与の見込み、(b) エンジンごとの費用内訳、(c) 採用済みスタジオがある Immutable や Avalanche サブネットのインベントリ標準との比較。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc919e8a0de51b89857e19#comment-6a1e0613038cf72ed1e64f27
- Summary (EN): Proposer (MLabs) argues low Cardano GameFi transaction volume is a symptom of a tooling gap rather than a counterargument, citing Necro League moving game-facing systems to Immutable and Cornucopias expanding to Base as evidence that Cardano-origin game projects route activity outward when game-facing infrastructure is stronger elsewhere.
- Summary (JA): 提案者(MLabs)は、CardanoのGameFi取引量が少ないのは反論ではなくツール不足の兆候だと主張し、Necro Leagueがゲーム向けシステムをImmutableに移行したことやCornucopiasがBaseに拡大したことを引用し、Cardano発のゲームプロジェクトはゲーム向けインフラが他で強いと活動を外部へ流すと論じている。

Full text:

Thanks, Yuta.

Low Cardano GameFi transaction volume is real and worth examining honestly. But we see it as a symptom of the tooling gap, not a counterargument to filling it. Game developers and players are generating this activity elsewhere, on chains with more mature game-specific infrastructure.

There are public examples of this dynamic.

Necro League, a Cardano-born game studio, announced that it was moving game-facing systems to Immutable while keeping its original NFT collection on Cardano. Their reasoning, posted directly on r/cardano, was practical. They need frictionless onboarding for non-crypto gamers, low-fee and high-throughput interactions, and "tooling designed specifically for games, not DeFi." Their Cardano NFTs remain part of the project, but future game-native systems are moving elsewhere.

[https://www.reddit.com/r/cardano/comments/1qawexr/from\_cardano\_to\_immutable\_why\_our\_cardanoborn/](https://www.reddit.com/r/cardano/comments/1qawexr/from_cardano_to_immutable_why_our_cardanoborn/)

Cornucopias, another major Cardano-rooted game project built on Unreal Engine 5, announced an expansion to Base in February 2024, with co-founder Josh Jones framing the move as part of a mission to be chain-agnostic. That is not the same as abandoning Cardano, but it does show the same pattern. Cardano-origin game projects are increasingly routing activity outward when game-facing infrastructure is stronger elsewhere.

[https://www.businesswire.com/news/home/20240208010745/en/Cornucopias-Increases-Interoperability-with-Expansion-to-Base](https://www.businesswire.com/news/home/20240208010745/en/Cornucopias-Increases-Interoperability-with-Expansion-to-Base)

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc919e8a0de51b89857e19#comment-6a1e06a15141bb70a939dbb7
- Summary (EN): Proposer (MLabs) cites years of Catalyst evidence of the gaming tooling gap (Fund 8 'Gamers On-Chained', repeated Unreal/Unity SDK proposals), MLabs' direct experience of game integrations failing at the architecture stage, and DappRadar rankings showing game activity on other ecosystems.
- Summary (JA): 提案者(MLabs)は、ゲームツール不足を示すCatalystの長年の証拠(Fund 8の「Gamers On-Chained」、繰り返されたUnreal/Unity SDK提案)、ゲーム統合がアーキテクチャ段階で失敗したMLabsの直接的経験、他のエコシステムでのゲーム活動を示すDappRadarのランキングを引用している。

Full text:

This gap has been visible in Catalyst for years. Fund 8 had a "Gamers On-Chained" challenge category. Later proposals repeatedly identified the lack of game-specific SDKs and integrations as a blocker, including Unreal Engine and Unity SDK proposals.

[https://projectcatalyst.io/funds/8/f8-gamers-on-chained](https://projectcatalyst.io/funds/8/f8-gamers-on-chained)

[https://projectcatalyst.io/funds/10/products-and-integrations/unreal-engine-cardano-api-sdk-development](https://projectcatalyst.io/funds/10/products-and-integrations/unreal-engine-cardano-api-sdk-development)

[https://projectcatalyst.io/funds/12/cardano-open-developers/cardano-game-development-sdk-for-unity](https://projectcatalyst.io/funds/12/cardano-open-developers/cardano-game-development-sdk-for-unity)

MLabs has also seen this problem directly through conversations and exploratory work with game teams considering Cardano integration. The recurring issue is not simply whether an NFT can be minted. It is whether a real game studio can integrate Cardano into a normal game architecture without rebuilding its inventory, authentication, backend, and player UX around blockchain primitives. We have seen promising use cases fail at that early architecture stage because the available path was too bespoke, too wallet-centric, or too chain-first for a production game.

Game activity is clearly happening in other ecosystems when the tooling and execution environment fit the needs of studios. Public DappRadar rankings show games such as Pixels on Ronin, Alien Worlds on WAX, and Gods Unchained on Immutable zkEVM and Immutable X generating meaningful market and activity signals outside Cardano.

https://dappradar.com/rankings/category/games

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc919e8a0de51b89857e19#comment-6a1e06e8f4bf5dd313f5cf84
- Summary (EN): Proposer (MLabs) argues low GameFi volume means uncaptured demand, and explains TrueInventory uses an off-chain inventory service for high-volume operations while bounding on-chain activity to claim/redeem flows, delivering smart contracts, backend, APIs, and Godot/Unity/Unreal integrations, concluding low volume is evidence for the proposal rather than against it.
- Summary (JA): 提案者(MLabs)はGameFi取引量の低さは未獲得の需要を意味すると主張し、TrueInventoryは大量の操作にはオフチェーンの在庫サービスを用い、オンチェーン活動はclaim/redeemフローに限定し、スマートコントラクト・バックエンド・API・Godot/Unity/Unreal統合を提供すると説明し、取引量の低さは提案に対する反証ではなく裏付けだと結論づけている。

Full text:

Low Cardano GameFi transaction volume does not mean there is no gaming demand. It means Cardano has not captured that demand.

That experience directly shaped TrueInventory. The proposal does not try to put all game state on-chain. That would not be realistic for games with normal performance and UX requirements. TrueInventory instead uses a robust off-chain inventory service for high-volume game operations, while bounding on-chain activity to claim and redeem flows where real player ownership is asserted. Players can hold tokenized items on Cardano, trade them, and redeem them back into game sessions, while studios keep a familiar game-server architecture.

So the demand signal is not high GameFi transaction volume on Cardano today. The signal is that Cardano-born or Cardano-adjacent game projects have repeatedly had to look elsewhere for game-facing infrastructure, Catalyst has repeatedly surfaced the tooling gap, external ecosystems are capturing real game activity, and MLabs has encountered the same issue directly in attempted game integrations.

TrueInventory targets that missing layer. It delivers smart contracts, a backend inventory service, APIs, and working Godot, Unity, and Unreal integrations with deployable demonstration projects.

The honest reading is that low Cardano GameFi transaction volume is evidence for this proposal, not against it, because GameFi teams will ignore Cardano until solutions for their use case are provided. If Cardano waits for high GameFi activity before funding game-native infrastructure, it risks waiting for activity that cannot realistically arrive because the infrastructure gap remains unfilled.

Here is a video explanation from our CTO:
[https://drive.google.com/file/d/1txY6RCVi7\_GsvDo6cqvA7gHrwVZvJUwa/view?usp=sharing](https://drive.google.com/file/d/1txY6RCVi7_GsvDo6cqvA7gHrwVZvJUwa/view?usp=sharing)

---

## 26. Governance Coalition: Governance Prototype and RFP Program

- Proposal ID: 69fdb7108a0de51b89857e22
- Requested: 2,664,095 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdb7108a0de51b89857e22
- Category: Governance coordination
- Applicable criteria: C5
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. I read the rebuttal and agree the disagreement is genuine. Generally speaking, more governance tooling and research isn't bad, but I do not agree with allocating this amount at the current priority level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 反論の記事を読み、 提案者と意見の不一致があることに私は同意します。 もちろん、 一般論としてツールや研究はもっとあっても悪くはないと思いますが、 現在の優先順位上この金額をそれに投下することに同意しません。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Indeed, "abundance" may have been an overstatement. However, my argument is not about whether there is value, but about priority. I am not saying the proposal is worthless, nor that tooling should be a substitute for negotiation. The two highest-leverage levers (delegation UX on the wallet side, and the painstaking consensus-building among DReps) are both outside the scope of this proposal, and the rebuttal more or less acknowledges that. The question to ask is not "is there value" but "with the actual levers left untouched, is allocating 2.66M ADA to an adjacent layer the right priority right now."

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。確かに「abundance(豊富に存在)」は言い過ぎだった可能性があります。ただ私の主張は価値の有無ではなく優先度です。提案が無価値とも、ツールが交渉の代わりになるべきとも言っていません。最もレバレッジの高い2つのレバー(ウォレット側の委任UX、DRep間の地道な合意形成)はどちらもこの提案の射程外であり、反論もそれをほぼ追認しています。問うべきは「価値があるか」ではなく「実際のレバーが手つかずのまま、隣接レイヤーに2.66M ADAを充てるのが今の優先度として正しいか」です。

### Prior detailed analysis (EN)

**Categorisation**: [Governance coordination]. Non-applicable: C1, C2 (proposer has Cardano track record), C3, C4, C6, C8, C9, C10, C11.

**Applicable: C5 — but the real concern is at a different layer, not duplication itself**. Applying:

• **C5 (light) — Some analytics-layer overlap with existing tools** (adatool, Cexplorer, Cardanoscan, Lido Nation, gov-health.intersectmbo.org, gov.tools, multiple individual DRep efforts). Noting this for completeness, but duplication is NOT the main argument here.

• **The real concern — this proposal isn't addressing the actual Cardano governance bottlenecks**. Tools, research artifacts, deliberation methodology, content, motivated community — all of these **already exist in abundance**. Adding more of them does not move the needle. The two actual bottlenecks are both **untouchable by this proposal**:

  **(a) End-user wallet UIUX for delegation**: The primary lever for improving delegation behavior (moving stake out of auto-abstain default, increasing active vote / re-delegation frequency) is the wallet UI/UX experience itself — how easily a wallet user discovers DRep options, reviews rationale, and switches delegation. **Only wallet providers (Eternl, Lace, Daedalus, Vespr, Begin, NuFi, Tokeo, Yoroi, etc.) can control this.** Neither a Governance Coalition nor an RFP program has authority over wallet front-ends. This bottleneck is structurally outside the proposal's reach.

  **(b) DRep-to-DRep consensus building — the dirty, exhausting negotiation work**: Cardano governance has many DReps holding **fundamentally different views and values** (on NCL ceilings, on which proposals to fund, on Treasury return mechanisms, on operator-capacity questions). Improving governance means finding compromise positions across those gaps — proposal by proposal, vote by vote. This is **slow, manual, relationship-based work** that happens through X DMs, Telegram, Discord side-channels, in-person events, and 1-on-1 calls. Research papers, analytics dashboards, structured deliberation protocols, and reward schemes **do not substitute** for the actual sit-down-and-negotiate effort. The proposal does not commit to performing this work directly — it commits to funding more research / RFPs / coordination layer artifacts.

  Both bottlenecks are outside the scope this proposal can credibly address. Adding another coordination layer — whether analytics, deliberation tooling, or research artifacts — does not change the wallet stack and does not perform the cross-DRep negotiation work.

Therefore this proposal does not satisfy this criterion as currently scoped.

### Prior detailed analysis (JA)

**分類**: [Governance 調整]。 非適用: C1, C2 (提案者 Cardano track record あり), C3, C4, C6, C8, C9, C10, C11。

**適用: C5 — 但し本質的な懸念は重複そのものではなく別の layer にある**。 適用:

・**C5 (軽く) — Analytics layer で既存ツールと一部重複** (adatool, Cexplorer, Cardanoscan, Lido Nation, gov-health.intersectmbo.org, gov.tools, 複数の個別 DRep 取組)。 一応指摘するが、 重複自体はここでの主張ではない。

・**本質的な懸念 — 本提案は真の Cardano governance bottleneck に対処していない**。 Tool、 research 成果物、 deliberation methodology、 content、 意欲的な community — これらは **既に潤沢に存在**。 これらを増やしても needle は動かない。 実際の bottleneck は 2 つあり、 **両方とも本提案では touch できない**:

  **(a) End-user wallet の UIUX (委任行動を変える唯一の lever)**: 委任行動を改善する (auto-abstain default からの stake 移動、 active vote / re-delegation 頻度の向上) の primary lever は wallet UI/UX そのもの — wallet user がどう簡単に DRep option を発見し、 rationale を review し、 委任を切り替えられるか。 **これを control できるのは wallet provider (Eternl, Lace, Daedalus, Vespr, Begin, NuFi, Tokeo, Yoroi 等) だけ**。 Governance Coalition も RFP program も wallet front-end への authority を持たない。 この bottleneck は構造的に提案 scope の外。

  **(b) DRep 間 consensus building — 泥臭い交渉作業**: Cardano governance には **根本的に異なる考え方と価値観** を持つ DRep が多数存在 (NCL ceiling 観、 どの提案を fund すべきか、 Treasury return mechanism、 operator capacity 観等)。 governance 改善とは、 提案毎・投票毎にそのギャップを跨ぐ compromise position を見つけていくこと。 これは **slow で manual で関係性ベースの作業** で、 X DM、 Telegram、 Discord side-channel、 オフライン event、 1-on-1 通話で行われる。 研究論文、 analytics dashboard、 structured deliberation protocol、 報酬 scheme は **この実際の sit-down-and-negotiate 作業を代替しない**。 提案書はこの作業を直接行う commit ではなく、 さらなる research / RFP / coordination layer 成果物への fund commit。

  両 bottleneck とも本提案が credibly address できる scope の外。 もう一つ coordination layer を加えても (analytics でも deliberation でも research artifact でも) wallet stack は変わらず、 cross-DRep 交渉作業も実行されない。

よって本提案は現状 scope ではこの criterion を満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: agora.cardano
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdb7108a0de51b89857e22#comment-6a05f18d5141bb70a939db02
- Summary (EN): Proposer (agora.cardano) states it published a detailed response focusing on the application of Criterion C5, the claim that the proposal does not address actual governance bottlenecks, scope misconceptions, and the distinction between governance prototyping and deployment, noting the proposal is grounded in the Beyond MVG process and was revised after DRep feedback.
- Summary (JA): 提案者(agora.cardano)は、基準C5の適用、提案が実際のガバナンスのボトルネックに対処していないという主張、スコープの誤解、ガバナンスのプロトタイピングと展開段階の区別に焦点を当てた詳細な回答を公開したと述べ、提案はBeyond MVGプロセスに基づき、DRepのフィードバックを受けて改訂されたと指摘している。

Full text:

I have published a detailed response addressing the concerns and rationale presented in YUTA’s evaluation framework regarding the **Governance Coalition: Governance Prototype and RFP Program** proposal.

The response focuses particularly on:

- the interpretation and application of Criterion C5;
- the assertion that the proposal allegedly does not address the “actual governance bottlenecks”;
- misconceptions regarding the proposal scope;
- and the distinction between governance experimentation, prototyping, and deployment-stage implementation.

The document also clarifies how the proposal is grounded in the Beyond MVG process, including:

- workshops,
- public surveys,
- governance problem-sensing,
- MoSCoW prioritization outputs,
- and governance research involving both IOG contributors and community participants.

Several conclusions in the original rationale appear, in my view, to rely on:

- subjective governance assumptions presented as definitive conclusions;
- incomplete contextualization of Beyond MVG findings;
- and interpretations that do not accurately reflect the actual proposal design or intended scope.

Importantly, this is not an attempt to dismiss community feedback.

The proposal has already gone through multiple major revisions after receiving feedback from active DReps, governance researchers, and ecosystem participants. In fact, some major design changes — including the removal of a much larger governance incentive allocation component — were made precisely because of governance feedback and political feasibility concerns raised during the review process.

At the same time, I believe it is important to publicly clarify misconceptions when criticism appears to evaluate a different proposal than the one actually being submitted.

The full response is available below:

[See Full Review](https://hackmd.io/@CEF-RDdySpK5AabybGaN7g/H1CCJLmyze) https://hackmd.io/@CEF-RDdySpK5AabybGaN7g/H1CCJLmyze

---

## 27. DeFi US App-Layer and Demand Activation and Capital Execution Pilot Program

- Proposal ID: 69fda8b1e1ab5d003a0cab75
- Requested: 2,500,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fda8b1e1ab5d003a0cab75
- Category: BD network
- Applicable criteria: C2, C3, C4, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; the reply ultimately does not demonstrate experience on Cardano, and it also takes the form of conceding the point that treasury returns and payment milestones are not tied to Cardano-attributable outcomes, so my concerns are basically not alleviated.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます、返答は、最終的にはCardanoでの経験者を示しておらず、トレジャリーへの還元や、支払いマイルストーンがCardano帰属成果に紐づかない点についてもそれを認めている形になっるなど、基本的には懸念は軽減されていません。

### Prior detailed analysis (EN)

**Categorisation**: [BD network / Magenta Labs]. Non-applicable: C1 (BD work doesn't directly generate Tx — measured via downstream effect), C5 (no specific duplication concern), C6 (no L1 use case), C9 (DeFi sector demand is generally validated; the issue is execution not thesis), C10 (₳2.5M ≈ 0.71% of NCL — well below scrutiny), C11 (not secondary-DAO).

**Applicable criteria: C2, C3, C4, C7, C8**. Applying each:

• **C2 — Cardano-native track record (decisive)**: Per /tx-roi backend, Magenta Labs has 'N/A' Cardano funding history (no prior Catalyst, no prior TW). Team experience cited in proposal: Polygon Labs, ZKsync, Outlier Ventures, Polkadot — none Cardano-native. The bidirectional trust signal evaluation: positive side (Cardano deliveries) is empty; negative side (operator history red flags) — none publicly surfaced, so neutral. Net: positive signal absent. Compared to two existing BD-style proposers with verifiable Cardano track record:
  - **STORM**: Implementation Partner, **9/11 Catalyst deliveries** on Cardano (per public Catalyst funding records via /tx-roi). Demonstrated capability to convert Cardano BD pipeline into deliverables.
  - **NMA**: Active Masumi engagement since Oct 2024 (per Masumi public docs + per Intersect TW where Masumi has 28.7K tx footprint).
  Magenta lacks the comparable Cardano-specific delivery record. The 'Polygon experience transfers' counter-argument requires Cardano-experienced staff/advisor disclosure — proposal does not name such structure.

• **C3 — KPI = outcome with causal attribution**: Proposal explicitly states 'ecosystem KPIs are not used as direct milestone triggers'. Payment milestones tie to process metrics: 60 sourced opportunities / 20 LOIs / 10 deployments. These measure Magenta's pipeline progression, not Cardano outcomes. **Causal attribution gap**: 'opportunities sourced' → 'Cardano-attributable Tx/TVL/wallet creation' is the unspecified middle step. Without UTM-tracked or cohort-attributable downstream metrics, milestone payments fund pipeline activity regardless of Cardano outcome.

• **C4 — Treasury return mechanism**: No revenue share, fee return, repayment, or success-based clawback specified. BD-as-grant structure with no return. The 'subsidy' framing means Treasury bears 100% of pipeline-development risk while downstream deployment commercial value (if any) accrues to deployed dApps and Magenta's commercial relationship with them — not Treasury.

• **C7 — CoI / counterparty verifiability**: WP4's two-layer evidence model restricts named counterparty / LOI evidence to administrators and designated reviewers. DReps cannot verify the targets of funded work — empirical KPI verification at DRep level impossible. **Counter-argument**: NDAs are industry standard in enterprise BD. **Refutation**: STORM operates similar confidentiality structure but with verifiable Cardano deliveries (9/11 Catalyst); the gap is delivery track record visibility (a ratio metric: deliverables/NDA-subjects), not full-disclosure-vs-no-disclosure binary.

• **C8 — Past funding outcome (combined with C2 'N/A')**: 'N/A' Cardano funding history means C8 cannot be evidence-applied to attribute past success or failure. Combined with C2's lack of Cardano delivery record, the proposer is asking Cardano Treasury to fund Cardano-central BD work as their **first** Cardano engagement at ₳2.5M scale. This inverts normal sequencing — typical pattern: small initial Catalyst proposal → demonstrate delivery → larger TW → Treasury-funded BD network.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [BD ネットワーク / Magenta Labs]。 非適用: C1 (BD work は直接 Tx 生成せず — downstream 効果で測定), C5 (specific duplication concern なし), C6 (L1 use case なし), C9 (DeFi sector demand は一般的に validated; issue は execution で thesis ではない), C10 (₳2.5M ≈ NCL の 0.71% — scrutiny 帯以下), C11 (二次配布 DAO でない)。

**適用基準: C2, C3, C4, C7, C8**。 各々あてはめ:

• **C2 — Cardano-native 実績 (決定的)**: /tx-roi backend より、 Magenta Labs は Cardano funding history 'N/A' (prior Catalyst なし、 prior TW なし)。 提案書 cited team experience: Polygon Labs, ZKsync, Outlier Ventures, Polkadot — Cardano-native なし。 Bidirectional trust signal: positive side (Cardano deliveries) は empty; negative side (operator history red flag) — public surface なしで neutral。 Net: positive signal absent。 比較として Cardano 実績ある 2 つの BD-style 提案者:
  - **STORM**: Implementation Partner、 Cardano で **9/11 Catalyst delivery** (公開 Catalyst funding records via /tx-roi)。 Cardano BD pipeline を deliverable に convert する capability demonstrated。
  - **NMA**: 2024-10 〜 active Masumi engagement (Masumi public docs + Masumi が 28.7K tx footprint を持つ Intersect TW より)。
  Magenta は comparable な Cardano-specific delivery record を欠く。 'Polygon experience transfers' counter-argument は Cardano-experienced staff/advisor disclosure 要求 — 提案書はそのような structure を name せず。

• **C3 — KPI = outcome with causal attribution**: 提案書は 'ecosystem KPIs are not used as direct milestone triggers' を明示。 Payment milestone は process metric に連動: 60 sourced opportunities / 20 LOIs / 10 deployments。 これらは Magenta pipeline 進捗で Cardano outcome ではない。 **Causal attribution gap**: 'opportunities sourced' → 'Cardano-attributable Tx/TVL/wallet creation' の中間 step が unspecified。 UTM-tracked や cohort-attributable downstream metric なしでは、 milestone payment は Cardano outcome に関わらず pipeline activity を fund。

• **C4 — Treasury 回収機構**: Revenue share / fee return / repayment / success-based clawback specify なし。 BD-as-grant 構造で return なし。 'Subsidy' framing は Treasury が pipeline-development risk の 100% を bear、 downstream deployment commercial value (あれば) は deployed dApp と Magenta の commercial relationship に accrue — Treasury には accrue せず。

• **C7 — CoI / counterparty 検証性**: WP4 two-layer evidence model が named counterparty / LOI evidence を administrator + designated reviewer に制限。 DRep は funded work target 検証不能 — DRep level での empirical KPI 検証不可。 **Counter-argument**: NDA は enterprise BD 業界標準。 **Refutation**: STORM は similar confidentiality structure で operate するが verifiable Cardano delivery (9/11 Catalyst) あり; gap は delivery track record visibility (ratio metric: deliverable/NDA-subject) で full-disclosure-vs-no-disclosure binary ではない。

• **C8 — 過去資金 outcome (C2 'N/A' と combine)**: 'N/A' Cardano funding history は C8 を evidence-apply (past success/failure attribution) できない。 C2 の Cardano delivery record 欠如と combine し、 提案者は Cardano Treasury に Cardano 中核 BD work を **first** Cardano engagement として ₳2.5M scale で fund 要求。 これは通常 sequencing を反転 — 典型 pattern: small initial Catalyst proposal → delivery demonstrate → larger TW → Treasury-funded BD network。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fda8b1e1ab5d003a0cab75#comment-6a073d195141bb70a939db16
- Summary (EN): Proposer acknowledges concerns and reframes scope: not generic BD but execution-focused work on US-linked app-layer/fintech/wallet integrations. Says first round of clarifications were added (KPI standards, RE2 continuation gate, COI/treasury safeguards, evidence layers).
- Summary (JA): 提案者は懸念を認め、汎用BDではなく米国系アプリ層/フィンテック/ウォレット統合に焦点を絞った実行型作業だと再定義。KPI基準、RE2 継続ゲート、COI・トレジャリー保護、エビデンス層など第1次の明確化を提案に反映済みとのこと。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C2, C3, C4, C8).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Thank you for your feedback. This is very useful and we appreciate the structured review.

We understand the main concerns.

The intention behind the **DeFi US App-Layer and Capital Execution Program** is not generic BD, marketing, ecosystem promotion or broad pipeline-building. The purpose is execution-oriented work focused on helping selected US-linked app-layer, fintech, wallet, treasury, stablecoin, allocator, fund and distribution opportunities move toward activation execution, integration, capital-flow pathways, user adoption and measurable Cardano usage.

We have already incorporated a first round of clarifications into the proposal, including clearer execution KPI standards, documented KPI impact rationales for counted opportunities, explicit counterparty evidence requirements, a hard RE2 continuation gate, public and confidential evidence layers and sharper Treasury protection mechanisms.

We are continuing to capture feedback, refine how we communicate the execution standards and evidence requirements, and strengthen the supporting appendices so the proposal can be evaluated on scope, evidence, additivity and Treasury protection rather than broad claims.

---

## 28. Cardano app on Ledger maintained by Ledger Technologies SAS

- Proposal ID: 69fd6321f9ebc26d057f51d7
- Requested: 2,218,620 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd6321f9ebc26d057f51d7
- Category: Wallet / hardware
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Please coordinate / de-duplicate scope with the VacuumLabs proposal first.

### Voting reason (JA, as of 2026-05-28)

VacuumLabs の提案書との重複を調整してください。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Cardano app on Ledger maintained by Ledger Technologies SAS (**2.06M ADA / NCL 0.59%**).

**Main reasons**

**1. First-party hardware vendor maintenance is the highest-quality tier**
- Ledger SAS is the hardware vendor itself, not a third-party integrator.
- Comparable arrangements (Ledger's BTC / ETH / SOL apps) are vendor-maintained for the same structural reason: the vendor controls firmware, the secure element, and the supply chain.
- Ledger is the dominant hardware wallet for ADA cold storage.

**2. The historical maintainer (VacuumLabs) → first-party transition is structurally correct**
- Per ADAtool /tx-roi: VacuumLabs Cardano HW work = 1 Catalyst (272,705 ADA) + active Intersect TW (2 milestones delivered, 120,800 ADA disbursed).
- VacuumLabs delivered the historical Cardano-on-Ledger app well, but direct maintenance by Ledger SAS removes the translator layer.

**3. Cost benchmark**
- 2.06M ADA ≈ $515K USD at ADA $0.25 = annual fee for first-party vendor maintenance of a major Ledger app — within market.
- Distinct from the 92.7K CIP-113 protocol line and the 3.46M Top-5 dApp clear-signing line — non-overlapping scopes within the three-proposal Ledger stack.

**4. Scope clarity**
- Yearly maintenance fee for the Cardano app on Ledger devices.
- Concrete milestones should include each hard-fork-readiness window.

Default YES — first-party hardware vendor maintenance, large ADA-on-Ledger population, no overlap with the other two Ledger SAS proposals.

### Prior detailed analysis (JA)

**Vote: YES** — Ledger SAS による Cardano アプリ保守(**2.06M ADA / NCL 0.59%**)に YES。

**主な理由**

**1. ハードウェアベンダー本家による保守が最上位**
- Ledger SAS は機器メーカー本体。第三者の統合業者ではない。
- Ledger の BTC / ETH / SOL アプリも同じ理由でベンダー保守になっている。ベンダーはファームウェアもセキュアエレメントもサプライチェーンも握っているため、第三者保守は常にベンダー内部の変更ペースから遅れる。
- ADA のコールドストレージでは Ledger が圧倒的に主流。

**2. 過去の保守者(VacuumLabs)から本家への移管は構造的に正しい**
- ADAtool /tx-roi より:VacuumLabs の Cardano HW 関連 = Catalyst 1件(272,705 ADA)+ Intersect TW(2 マイルストーン完了、120,800 ADA 受領)。
- VacuumLabs は過去にうまく届けてきたが、Ledger SAS が直接保守すれば翻訳層を1つ減らせる。

**3. 単価**
- 2.06M ADA ≒ $515K USD(ADA $0.25 換算)= 主要 Ledger アプリの本家保守料/年。市場相場の範囲内。
- 92.7K の CIP-113 プロトコル統合、3.46M の Top 5 dApp clear signing とは別物。3提案 Ledger セット内で重複しない。

**4. スコープの明確さ**
- Ledger 機器上の Cardano アプリの年次保守料。
- 各ハードフォーク対応の期限を、具体的なマイルストーンに含めるべき。

ベンダー本家による保守 + Ledger 上の ADA 利用層の大きさ + 他2提案との非重複で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 29. Libertum: Institution-Grade Participation Infrastructure for Cardano Real-World Assets

- Proposal ID: 69fb759cb05ff80adc7d5c47
- Requested: 2,193,900 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb759cb05ff80adc7d5c47
- Category: dApp - RWA
- Applicable criteria: C1, C4, C7
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; the C1 response is difficult to verify because there are no concrete figures. C2 also feels vague to me.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、C1の返答は具体的な数値がないために検証が難しいです。C2についても曖昧に感じます。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-RWA]. Non-applicable: C2 (Libertum has track record albeit not Cardano-native at significant scale), C3, C5, C6, C8, C9, C10, C11.

**Applicable: C1, C4, C7**. Applying:

• **C1 — Tx contribution structurally low**: RWA tokenized funds do not generate transactions at scale. Empirical reference: BlackRock BUIDL ~50 tx/month at $147M AUM (per BUIDL public Etherscan data). RWA tx generation is per-buy/sell/distribution-event basis, low frequency.

• **C4 — No Treasury return (decisive)**: Cardano Treasury pays $548K integration cost. Post-integration, platform fees flow to Libertum (5% to LBM token buyback per Libertum tokenomics docs). **No revenue share with Cardano Treasury** specified in proposal. Pure grant + private fee capture.

• **C7 — Structural CoI from tokenomics**: Libertum tokenomics allocates 5% of platform revenue to LBM token buyback & burn (per Libertum public tokenomics). This creates a structural CoI:
  - Cardano Treasury investment ($548K) → Libertum operates Cardano integration
  - Libertum captures Cardano-routed platform fees
  - 5% of those fees → LBM buyback & burn
  - LBM token holders (commercial entity stakeholders, not Cardano stakeholders) benefit

  LBM market scale (~$1.4M market cap per CoinGecko reference) makes the indirect financial impact non-trivial relative to grant size. 

  **Note**: Direct price impact via the integration → revenue → buyback → price chain is multi-step and uncertain in magnitude. The CoI exists at the structural level (Treasury investment → commercial-entity-token holder benefit) regardless of whether the price chain materialises significantly. The objection is the structural alignment, not the magnitude.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-RWA]。 非適用: C2 (Libertum は track record あり、 Cardano-native は significant scale でないが), C3, C5, C6, C8, C9, C10, C11。

**適用: C1, C4, C7**。 適用:

・**C1 — Tx 寄与構造的低**: RWA tokenized fund は scale で transaction 生成せず。 Empirical reference: BlackRock BUIDL ~50 tx/月 at $147M AUM (BUIDL 公開 Etherscan data より)。 RWA tx 生成は per-buy/sell/distribution-event で低頻度。

・**C4 — Treasury return なし (decisive)**: Cardano Treasury が integration cost $548K 支払。 Post-integration、 platform fees は Libertum に flow (5% は LBM token buyback per Libertum tokenomics docs)。 **Cardano Treasury への revenue share** を提案書 specify せず。 Pure grant + private fee capture。

・**C7 — Tokenomics による構造的 CoI**: Libertum tokenomics は platform revenue の 5% を LBM token buyback & burn に割当 (Libertum 公開 tokenomics より)。 これは構造的 CoI 形成:
  - Cardano Treasury 投資 ($548K) → Libertum が Cardano integration を operate
  - Libertum が Cardano-routed platform fees を capture
  - その fees の 5% → LBM buyback & burn
  - LBM token holder (commercial entity stakeholder、 Cardano stakeholder ではない) を benefit

  LBM market 規模 (~$1.4M market cap per CoinGecko reference) は grant size 比で間接 financial impact を non-trivial にする。

  **Note**: integration → revenue → buyback → price chain での direct price impact は multi-step で magnitude uncertain。 CoI は structural level (Treasury 投資 → commercial-entity-token holder benefit) で price chain が significantly materialise するか否かに関わらず存在。 反論は structural alignment で magnitude ではない。

よって本提案はこれらを満たさない。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb759cb05ff80adc7d5c47#comment-6a032ba3f4bf5dd313f5cedf
- Summary (EN): Reframes C1 as recurring operational activity (onboarding, compliance, permissions, settlements) rather than passive TVL. On C4 commits to updating with a Cardano Ecosystem Participation Mechanism. On C7 acknowledges wording problem in onboarding/deployment support section.
- Summary (JA): C1: 受動的TVLではなくオンボーディング・コンプライアンス・権限管理・決済等の継続的なオンチェーン活動だと再定義。C4: Cardanoエコシステム参加機構を提案に追加すると約束。C7: オンボーディング/展開支援セクションの表現に問題があったと認める。

Full text:

Thanks for taking the time to review the proposal and share a detailed rationale — it’s genuinely appreciated.

A few clarifications from our side may help better explain the intent behind the proposal, particularly around C1, C4, and C7.

On C1, the proposal is not focused on passive or “narrative-only” TVL growth. Libertum’s infrastructure is designed around recurring operational activity on Cardano — onboarding, compliance workflows, permissions management, governance actions, settlements, marketplace participation, and ongoing lifecycle transactions.

Because Libertum operates as reusable white-label infrastructure, every deployment introduces its own issuers, users, operational flows, and recurring transaction activity. Our view is that long-term ecosystem value comes from sustained Cardano-native participation rather than static TVL alone.

On C4, we understand and agree with the importance of ecosystem alignment when treasury funding supports commercial infrastructure. We are therefore updating the proposal to include a clearer Cardano Ecosystem Participation Mechanism tied directly to treasury-enabled infrastructure activity. The goal is to create stronger alignment between ecosystem growth, recurring on-chain participation, and long-term sustainability for Cardano.

Regarding C7, this is fair feedback and likely comes down to how the onboarding and deployment support section was originally written. The intention was never to create a discretionary grant structure or position Libertum as a treasury allocator.

To make this clearer, we are updating the proposal by:

- removing “grant” terminology entirely
- excluding Libertum-affiliated entities from eligibility
- ensuring any support remains milestone-based and operationally focused
- linking support only to measurable Cardano-native deployment outcomes
- adding transparency, reporting, and oversight requirements


Appreciate the time, structure, and effort put into reviewing the proposal.

#### Feedback 2 — source: twitter, author: Alucard575
- Author note: LIKELY: defends Libertum B-DEX with insider/roadmap knowledge; bio unconfirmed
- URL: https://twitter.com/Alucard575/status/2059832632750510368
- Summary (EN): Concedes current B-DEX volume/tokenization is modest BUT signals more is coming — RWA/Libertum context.
- Summary (JA): 現状のB-DEX量・トークン化は控えめだが今後拡大予定と返答 — RWA/Libertum文脈。

Full text:

@yutazzz Hi Yuta,
You make a very fair point, and it’s completely accurate that the current transaction volume through the live B-DEX and initial tokenizations is modest, BUT…..👇👇👇👇👇 https://t.co/BEycAMeL7l

---

## 30. Autonomous AI Finance on Cardano with ClawBank

- Proposal ID: 69fd539b85ddd26899aaf21c
- Requested: 1,874,600 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd539b85ddd26899aaf21c
- Category: Speculative finance
- Applicable criteria: C2, C3, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; is there data underpinning the Tx target? Also, is this Tx-target scale considered reasonable relative to the investment amount from the treasury?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、Tx目標の根拠となるデータはありますか?また、このTx目標規模は、トレジャリーからの投資額に対して妥当と考えられますか?

### Prior detailed analysis (EN)

**Categorisation**: [Speculative finance / AI agent]. Non-applicable: C5, C6 (AI agent finance generic, not L1-specific), C7, C10, C11.

**Applicable: C2, C3, C8, C9**. Applying:

• **C2 — Cardano-native track record (decisive)**: Per /tx-roi backend, Justice Conder (proposer) has Cardano funding history 'N/A'. Experience cited: Polygon Labs, Quadratic Accelerator. Same pattern as Magenta Labs (DeFi & OpenFi US, also Budget #69 NO) — building central Cardano financial infrastructure with no Cardano-native delivery record.

• **C3 — KPI = outcome (zero quantitative commitments)**: Across 4 work packages, the 'How will success be measured?' sections contain no specific tx, user, or TVL targets. Phrases like 'Number of active users', 'Volume of fiat to USDCx conversions', 'Monthly transaction activity generated' appear in milestone definitions without target values. Milestone triggers are process metrics, replicating the accountability gap of Magenta Labs proposal.

• **C8 — Past funding pattern**: 'N/A' Cardano track record means C8 cannot be applied with evidence — but combined with C2's lack of Cardano delivery history, the proposer is asking Cardano Treasury to fund ambitious Cardano-central infrastructure as their first Cardano work.

• **C9 — Speculative thesis (decisive)**: 'AI agents are becoming a new class of financial users' is not a validated market as of 2026:
  - x402 protocol: emerging, with sub-1K daily tx adoption across all chains as of 2026-Q1
  - MCP (Model Context Protocol): early-stage, no on-chain financial application at scale
  - Agent commerce: A16z-portfolio thesis with negligible production volume

  No empirical baseline for agent-driven tx within Cardano's monthly 800K. All expected Tx depends on this unvalidated thesis materialising.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [投機的金融 / AI agent]。 非適用: C5, C6 (AI agent finance は generic で L1-specific でない), C7, C10, C11。

**適用: C2, C3, C8, C9**。 適用:

・**C2 — Cardano-native 実績 (decisive)**: /tx-roi backend より、 Justice Conder (提案者) の Cardano funding history 'N/A'。 提案書 cited experience: Polygon Labs, Quadratic Accelerator。 Magenta Labs (Budget #69 NO) と同 pattern — Cardano-native delivery record なしで central Cardano 金融 infra を構築。

・**C3 — KPI = outcome (zero quantitative commitment)**: 4 WPs 全体で 'How will success be measured?' に specific tx / user / TVL target なし。 'Number of active users', 'Volume of fiat to USDCx conversions', 'Monthly transaction activity generated' は target value なしの description。 Milestone trigger は process metric で Magenta Labs の accountability gap を再生産。

・**C8 — 過去資金 pattern**: 'N/A' Cardano track record は C8 を evidence で apply できない — 但し C2 の Cardano delivery 履歴欠如と combine し、 提案者は Cardano Treasury に Cardano 中核 infra を first Cardano work として fund 要求。

・**C9 — 投機的 thesis (decisive)**: 'AI agents are becoming a new class of financial users' は 2026 時点 validated market ではない:
  - x402 protocol: emerging で 2026-Q1 時点 全 chain 横断で daily tx 1K 未満 adoption
  - MCP (Model Context Protocol): early-stage で scale での on-chain financial application なし
  - Agent commerce: A16z-portfolio thesis で production volume negligible

  Cardano 月次 800K 内での agent-driven tx の empirical baseline なし。 想定全 Tx は本 unvalidated thesis materialising に依存。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd539b85ddd26899aaf21c#comment-6a0fa0ab7d5f66c548766270
- Summary (EN): Reports a revision pass: stronger emphasis on measurable operational outcomes, Cardano-specific infrastructure rationale, milestone accountability and Treasury protection. Reduced 'AI finance' framing, repositioned around deployable Cardano infrastructure with concrete KPI targets per WP and continuation gates.
- Summary (JA): 改訂版を報告: 計測可能な運用成果、Cardano特化のインフラ根拠、マイルストーン責任、トレジャリー保護を強化。「AI finance」フレーミングを抑え、Cardano上のデプロイ可能インフラ路線へ再配置。WP毎の具体KPIとマイルストーン継続ゲートも追加。

Full text:

Thank you for the review and comment

We took another revision pass on the proposal based directly on this feedback. The updated version now places much stronger emphasis on measurable operational outcomes, Cardano-specific infrastructure rationale, milestone accountability, and Treasury protection.

We also reduced a lot of the broader “AI finance” framing and repositioned the proposal more explicitly around deployable infrastructure on Cardano

In addition, we added concrete KPI targets across all work packages, clearer continuation gates between milestones, and a stronger explanation of how this fits into the existing Cardano stack.

Appreciate the feedback again

---

## 31. Marlowe V2

- Proposal ID: 69fc8a71b05ff80adc7d5c4f
- Requested: 1,802,500 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8a71b05ff80adc7d5c4f
- Category: Research / ZK / FV
- Applicable criteria: C5, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: This proposal falls under [research / smart-contract DSL]. Of my 11-criterion voting policy, the following NON-applicable criteria are dismissed first to avoid mis-applied negatives:
• C1 (Tx/TVL materiality) — NOT applicable: a DSL doesn't directly generate Tx; it enables others. Tx is wrong metric.
• C3 (KPI = outcome) — NOT applicable: research deliverables (release, audit, integration) are output metrics by design.
• C4 (Treasury return) — NOT applicable: public-good DSL is intentionally non-revenue-generating.
• C6 (L1 feasibility) — NOT applicable: DSL design has no direct L1 fee/blocktime constraint.
• C7, C9, C10, C11 — NOT applicable to research/DSL.

**Applicable criteria: C5 (non-duplication), C8 (past funding outcome)**. Applying each:

• **C5 — Note on Aiken comparison (different target audience)**: Marlowe is designed for **financial-domain experts** (lawyers, financial professionals, non-programmers) — a DSL for non-coders to express financial contracts. Aiken is designed for **software engineers** writing on-chain code. These are different target audiences and 'accessibility' means different things in each context, so Aiken does NOT directly substitute Marlowe's intended user base. **However**, the empirical observation that every major Cardano DeFi protocol (Minswap, Liqwid, Indigo, SundaeSwap, WingRiders, Bodega, CSwap — verified via tx_label production usage) is built by software engineers using Aiken/Plutus suggests **the financial-DSL audience for Marlowe simply hasn't materialised on Cardano**. Proposal itself acknowledges: 'the vision ... was ahead of where Cardano adoption actually was'. The C5 substance is **audience non-materialisation**, not Aiken duplication.

• **C8 — Past funding outcome + community 'V2-of-failed-V1' critique**: The proposal does **not present its own adoption / usage data** to demonstrate the prior Marlowe investment has produced sustained Cardano DeFi adoption — and it does **not cite signed adoption commitments from any major Cardano DeFi protocol** for V2.

  *Supporting (but inconclusive) signal from our side*: ADAtool db-sync archive (epoch 1-629, 2017-09 to 2026-05-09) shows tx_label.marlowe (CIP metadata label 1564) trajectory — **2022: 84 tx; 2023: 5,901 tx (peak); 2024: 408 tx; 2025: 14 tx. Last 30 days = 0 tx**. *Caveat*: this label captures Marlowe transactions carrying the 1564 metadata; Marlowe activity sent without that metadata would be undercounted.

  *Independent community signal*: **@matiwinnetou (2026-05-08, ♥61)** — public budget critic — explicitly cites Marlowe as the cautionary 'V2 of a protocol with zero V1 adoption' example: 'caution dReps regarding some proposals … trying to create proposal for V2 of a protocol while V1 has zero adoption … assuming users will adopt the solution (like **we didn't have Marlowe as an example [used by nobody or almost nobody]**)'. The proposer concedes V1 adoption gap in proposal text ('the vision ... was ahead of where Cardano adoption actually was').

**The decisive gap is that the Marlowe side has not presented its own adoption data**, and the community-recognised 'V2-of-failed-V1' pattern applies.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: 本提案は [研究 / スマコン DSL] に該当。 11 基準のうち、 misapplied negative 防止のため非適用基準を先に dismissal:
・C1 (Tx/TVL 寄与度) — 非適用: DSL は直接 Tx 生成せず、 他者を enable。 Tx は wrong metric。
・C3 (KPI = outcome) — 非適用: 研究 deliverable (release / audit / integration) は output metric by design。
・C4 (Treasury return) — 非適用: public-good DSL は意図的に non-revenue-generating。
・C6 (L1 実現可能性) — 非適用: DSL design は直接の L1 fee/blocktime 制約なし。
・C7, C9, C10, C11 — research/DSL に非適用。

**適用基準: C5 (機能重複), C8 (過去資金 outcome)**。 各々あてはめ:

・**C5 — Aiken 比較の注 (target audience が異なる)**: Marlowe は **financial-domain expert** (lawyers, financial professional, non-programmer) 向け設計 — non-coder が financial contract を表現する DSL。 Aiken は **software engineer** が on-chain code を書く向け設計。 target audience は異なり、 'accessibility' は各 context で異なる意味、 よって Aiken は Marlowe の intended user base を直接 substitute しない。 **但し**、 主要 Cardano DeFi protocol (Minswap, Liqwid, Indigo, SundaeSwap, WingRiders, Bodega, CSwap — tx_label production usage で検証済) はすべて software engineer が Aiken/Plutus で構築している empirical 観察は、 **Marlowe の financial-DSL audience が Cardano で materialise していない** ことを示唆。 提案書自身が認知: 'the vision ... was ahead of where Cardano adoption actually was'。 C5 substance は **audience non-materialisation** で、 Aiken 重複ではない。

・**C8 — 過去資金 outcome + community の 'V2-of-failed-V1' critique**: 提案書は、 過去の Marlowe 投資が持続的 Cardano DeFi 採用を生んだことを示す **自身の採用 / 使用 data を提示していない**。 また V2 に対する **主要 Cardano DeFi protocol からの signed adoption commitment の引用もない**。

  *こちら側からの補強 (但し inconclusive) signal*: ADAtool db-sync archive (epoch 1-629, 2017-09 〜 2026-05-09) より tx_label.marlowe (CIP metadata label 1564) trajectory — **2022: 84 tx; 2023: 5,901 tx (peak); 2024: 408 tx; 2025: 14 tx。 直近 30 日 = 0 tx**。 *Caveat*: 本 label は 1564 metadata を持つ Marlowe tx を捕捉; 1564 metadata なしで送られた Marlowe activity は undercount 可能性。

  *独立 community signal*: **@matiwinnetou (2026-05-08, ♥61)** — 公開 budget 批判者 — が Marlowe を 'V1 zero-adoption の V2 提案' の cautionary 例として明示的に cite: 'caution dReps regarding some proposals … trying to create proposal for V2 of a protocol while V1 has zero adoption … assuming users will adopt the solution (**Marlowe を誰も or ほぼ誰も使っていない例として持っていなかったかのように**)'。 提案者は提案書 text で V1 adoption gap を認知 ('the vision ... was ahead of where Cardano adoption actually was')。

**決定的な gap は Marlowe 側が自身の adoption data を提示していないこと**、 そして community が認知する 'V2-of-failed-V1' pattern が適用。

よって本提案はこれらを満たさない。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 32. Tx3 by TxPipe: Open API Layer for Cardano's dApp Protocols

- Proposal ID: 69fc5a8785ddd26899aaf208
- Requested: 1,684,050 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc5a8785ddd26899aaf208
- Category: Infrastructure / SDK
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Latent demand is plausible, but I want stronger demand evidence.

### Voting reason (JA, as of 2026-05-28)

潜在的な需要を想定できるが、 より強い需要の証拠を確認したい。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback of a nature that would alter the vote.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback of a nature that would alter the vote.

### Prior detailed analysis (EN)

**Vote: YES** on Tx3 by TxPipe: Open API Layer for Cardano's dApp Protocols (**1.68M ADA / NCL 0.48%**).

**Main reasons**

**1. TxPipe Year-1 bundle delivered 9 of 10 milestones**
- Per ADAtool /tx-roi: TxPipe cumulative = **26 Catalyst proposals + 663K Treasury Withdrawal = 4.53M ADA**.
- Per Intersect TW (cardanotreasury.fi snapshot 2026-05-10): TxPipe Year-1 bundle (Pallas + UTxO RPC + Dolos + Oura) = **9 of 10 milestones delivered, 337K ADA disbursed, 1 pending (~53K ADA)**. Year-1 delivery ratio: 90%.
- Tx3 is new scope (separate from the Year-2 maintenance bundle). The delivery evidence applies to the team, not to this specific project.

**2. The problem statement is concrete**
- Today every integrator has to learn each Cardano dApp protocol from scratch — Minswap, SundaeSwap, Liqwid, Indigo all expose different interfaces.
- Tx3 standardises the intent-to-transaction layer for dApp protocol interactions.
- 12-month scope: 1,308,000 ADA + 327,000 ADA contingency = 1.685M ADA total.

**3. How Tx3 differs from Blockfrost / Koios / UTxO RPC**

| Layer | Service | Funding |
|---|---|---|
| Hosted API (third-party) | Blockfrost | active TW #104, 7.92M ADA |
| Hosted API (community) | Koios | community-run |
| Node interface standard | UTxO RPC | TxPipe Y2 ask 540K ADA |
| **dApp protocol API standard (Tx3)** | **TxPipe** | **1.68M ADA this proposal** |

Tx3 sits at the dApp-protocol layer (intent → transaction), separate from hosted APIs and node interfaces.

**Concern (not a NO)**: success depends on dApp protocols adopting Tx3 manifests. The proposal would be stronger with named Cardano dApps committing to publish Tx3 schemas before the Year-1 milestone closes. Default YES on the basis of TxPipe's delivery cadence and the gap Tx3 addresses.

### Prior detailed analysis (JA)

**Vote: YES** — Tx3 by TxPipe(**1.68M ADA / NCL 0.48%**)に YES。

**主な理由**

**1. TxPipe の1年目バンドルは10件中9件完了**
- ADAtool /tx-roi より:TxPipe 累積 = **Catalyst 26件 + TW 663K = 4.53M ADA**。
- Intersect TW(2026-05-10 時点)より:TxPipe Y1 バンドル(Pallas + UTxO RPC + Dolos + Oura)= **10件中9件完了、337K ADA 受領、1件保留(約 53K ADA)**。1年目達成率 90%。
- Tx3 は新規範囲(Y2 保守バンドルとは別)。実績はチームに対する評価で、本プロジェクト固有の実績ではない。

**2. 解決する問題が具体的**
- 現状、開発者は Minswap、SundaeSwap、Liqwid、Indigo といった各 Cardano dApp プロトコルを、毎回ゼロから学び直す必要がある。各プロトコルの操作面が違うため。
- Tx3 は「意図からトランザクションへ」の層を標準化する。
- 12か月:1,308,000 ADA + 327,000 ADA 予備 = 合計 1.685M ADA。

**3. Blockfrost / Koios / UTxO RPC との違い**

| 層 | サービス | 資金 |
|---|---|---|
| ホスト型 API(第三者) | Blockfrost | active TW #104、7.92M ADA |
| ホスト型 API(コミュニティ) | Koios | コミュニティ運営 |
| ノードインタフェース標準 | UTxO RPC | TxPipe Y2 540K ADA |
| **dApp プロトコル API 標準(Tx3)** | **TxPipe** | **1.68M ADA(本提案)** |

Tx3 は dApp プロトコル層(意図 → トランザクション)にあり、ホスト型 API やノードインタフェースとは別。

**懸念(NO ではない)**:成功は、dApp プロトコル側が Tx3 のマニフェストを採用するかにかかる。Y1 マイルストーン完了前に、Cardano の dApp が Tx3 スキーマ公開を約束していると、より強い提案になる。TxPipe の納品実績と、Tx3 が埋める空白を理由に YES。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: diegomac
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc5a8785ddd26899aaf208#comment-6a1dd8dc038cf72ed1e64f21
- Summary (EN): Proposer (diegomac) argues that although explicit demand for a newly released technology is hard to show, the same mechanism is well established elsewhere (OpenAPI in Web2, Solidity ABI in Ethereum), and lists current Tx3 users (Book.io, Ekklesia, SundaeSwap, Eryx/UBA) and interested teams as evidence of organic growth.
- Summary (JA): 提案者(diegomac)は、リリースされたばかりの技術への明示的な需要を示すのは難しいが、同じメカニズムは他所で十分に確立されている(Web2のOpenAPI、EthereumのSolidity ABI)と主張し、Tx3の現在の利用者(Book.io、Ekklesia、SundaeSwap、Eryx/ブエノスアイレス大学)と関心を示すチームを有機的成長の証拠として列挙している。

Full text:

Hey Yuta, as always, we appreciate your feedback.

It's hard to demonstrate explicit demand for a technology that was just released, but demand for this same mechanism is well established elsewhere.

- In Web2, it's shown by the widespread adoption of the OpenAPI standard;
- In Ethereum, by the use of the Solidity ABI as a core integration artifact.

Tx3 brings that same proven pattern to UTXO blockchains.

Despite being a very young technology, Tx3 is already seeing organic growth. It's currently used by:

- Book.io
- Ekklesia
- SundaeSwap
- Eryx and University of Buenos Aires

Several other teams have expressed interest, and we're actively helping them explore the tech:

- Indigo
- Strike
- Fluid Tokens
- snek.fun
- Bodega
- VyFi
- Hydra heads

On top of this, we're having meetings with more teams every week.

---

## 33. Hub-Network Liquidity: A Protocol for Revenue-based Finance at Network Scale

- Proposal ID: 69f0ed3a7822b26563397afa
- Requested: 1,596,500 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f0ed3a7822b26563397afa
- Category: Speculative finance
- Applicable criteria: C2, C3, C4, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; I have reviewed the reply, but none of it appears to alleviate my concerns at a substantive level.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、返答を確認しましたが、いずれも実質的なレベルで懸念が軽減されているものではないように見えます。

### Prior detailed analysis (EN)

**Categorisation**: [Speculative finance / revenue-based]. Non-applicable: C5, C6, C7, C10, C11.

**Applicable: C2, C3, C4, C8, C9**. Applying:

• **C2 — Cardano-native track record limited**: Per /tx-roi, proposer has cumulative ~$80K+ Catalyst grant history (Accra 100K, CATS $30K, Prisma DIDs 75K, Argentina 60K). Small base relative to proposed scale-up.

• **C4 — Treasury return zero (decisive)**: Proposal text quote: 'Will any portion of the requested funds be returned to the Cardano Treasury? No.' Pure grant for protocol development; protocol-generated surplus is captured by RPC holders (institutional investors); Treasury is neither protocol developer, issuer, nor holder.

• **C3 — KPI vagueness**: KPI-related statements are qualitative claims like 'exponential second and third order dynamics', with no specific Tx / TVL / user numerical commitments. Cardano network outcomes depend on dual hypothetical conditions: incubated project success + institutional capital inflow.

• **C8 — Past funded outcome attribution**: '110 teams incubated' and '45 hub deployments' are process metrics. No measurable Cardano network impact (participants on Cardano, teams launched on Cardano, Tx volume contribution, TVL impact) presented per grant. Three example projects cited (CarPool, MediSure, Safro Connect):
  - 'first delivery' (still building) status
  - 'building' (no live deployment) status
  - 'transactions accumulation' (early-stage, no scale)
  All early-stage; no closed deals or measurable Cardano on-chain outcomes presented.

• **C9 — Hypothetical institutional capital dependency**: Protocol value proposition centers on engagement with 'institutional capital sources (RBF providers, impact-first funds, mission-driven foundations)', but no committed partners, LOIs, or conditional commitments exist. Treasury funding is infrastructure investment ahead of demand validation; demand validation is a future event dependent on post-launch (9 months + alpha).

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [投機的金融 / revenue-based]。 非適用: C5, C6, C7, C10, C11。

**適用: C2, C3, C4, C8, C9**。 適用:

・**C2 — Cardano-native 実績 limited**: /tx-roi より、 提案者は累積 ~$80K+ Catalyst grant history (Accra 100K, CATS $30K, Prisma DIDs 75K, Argentina 60K)。 提案 scale-up に対し small base。

・**C4 — Treasury return zero (decisive)**: 提案書直接引用: 'Will any portion of the requested funds be returned to the Cardano Treasury? No.' Protocol 開発 pure grant; Protocol 生成 surplus は RPC holder (institutional investor) が capture; Treasury は protocol developer / issuer / holder のいずれでもない。

・**C3 — KPI vagueness**: KPI 関連 statement は 'exponential second and third order dynamics' 様の qualitative claim、 specific Tx / TVL / user 数値 commitment なし。 Cardano network outcome は dual hypothetical condition (incubated project 成功 + institutional capital inflow) に依存。

・**C8 — 過去 funded outcome attribution**: '110 teams incubated' と '45 hub deployments' は process metric。 Per grant の measurable Cardano network impact (Cardano 上の参加者数, Cardano launch team 数, Tx volume 寄与, TVL impact) 提示なし。 Cited 3 example project (CarPool, MediSure, Safro Connect):
  - 'first delivery' (still building) status
  - 'building' (no live deployment) status
  - 'transactions accumulation' (early-stage, no scale)
  全て early-stage; closed deal や measurable Cardano on-chain outcome 提示なし。

・**C9 — Hypothetical institutional capital 依存**: Protocol value proposition は 'institutional capital sources (RBF providers, impact-first funds, mission-driven foundations)' との engagement 中心、 committed partner / LOI / conditional commitment なし。 Treasury funding は demand validation 前の infrastructure investment; demand validation は post-launch (9 ヶ月 + alpha) 依存の future event。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f0ed3a7822b26563397afa#comment-6a11dadf05e47100cbda5c24
- Summary (EN): C2: $80K estimate reflects depreciated ADA; grants originated at $0.70–1.10. Argues this proposal is categorically distinct from prior event work (now protocol development). C4: updated to allocate funds for contract purchases with modeled 3× returns over 10y (11.6% CAGR) donated back to Treasury. C8: argues prior grants were process/capacity-building, not transactional. C9: events are the validation mechanism, partners can supply LOIs.
- Summary (JA): C2: 80K USD試算は下落後ADAでの計算 (元は$0.70–1.10時の助成)。今回はイベント運営ではなくプロトコル開発で過去と質的に別物。C4: 契約購入に資金を割り当て、10年で3倍 (CAGR 11.6%) を見込みトレジャリーへ寄付する仕組みを更新で追加。C8: 過去助成はシステム/能力構築でtx指標とは別軸。C9: イベント自体が検証機構、要請あればパートナーLOI提供可能。

Full text:

Thank you for your review Yuta. We welcome scrutiny and offer the following corrections:


C2 - Track record: The \~$80K estimate reflects significantly depreciated ADA. Our grants were initiated at $0.70–$1.10/ADA. More importantly, this proposal is categorically distinct from prior work. Previous funding supported event organisation; this funds protocol development - a deliberate organisational evolution. Applying event-delivery benchmarks to a protocol build mischaracterises both the proposal and our trajectory.


C4 - Treasury return: This has been addressed in the updated proposal. A portion of funds is allocated to purchase contracts on behalf of Cardano, with modelled 3x returns over 10 years (11.6% CAGR). Contract redemptions will be donated to the Treasury. Given we work with already-operational teams, redemptions are expected ahead of the modelled 3-year baseline.


C8 - Outcome attribution: Our prior grants funded systems and capacity-building, not transactional outputs. The cited projects illustrate systemic, process-oriented development - a deliberate methodology, not a gap. Applying narrow transactional metrics to organisational capacity work misreads our value proposition.


C9 - Institutional validation: Our events are the validation mechanism. They onboard capital partners, hub networks, and facilitators into a structured process. Existing partner relationships - paused during CATS delivery - can provide LOIs on request (the Regenesis Institute, referenced in the proposal). A significant event is planned with a different partner for November 2026, on the scale of CATS. We have done little to no marketing. These leads come from reputation built up over years within the ecological transition space, a field in which Cardano has significant untapped potential (which our work addresses).


C3 - KPI specificity: Noted. We are committed to developing upon this feedback, will discuss internally, and respond appropriately with another reply asap.

---

## 34. Cardano Content Creator Consortium (C4): Ecosystem Video Content Production, Marketing & Education

- Proposal ID: 69fac66e89371182537b3096
- Requested: 1,524,400 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fac66e89371182537b3096
- Category: Marketing / events
- Applicable criteria: C3
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. In particular, the most fundamental marketing question — 'who is the target audience' — is not clearly defined, and the proposal is not designed downstream of that. For me that is fatal. The design must start from the demand side, not the supply side.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 特に「ターゲットが誰か」というマーケティングを行う際に一番最初に考えるべき基本的な事項が明確に定義され、 そこから提案書が設計されていないのは私にとって致命的です。 供給側の事情から始めるのではなく、 需要側の事情から始める必要があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; in particular, the most fundamental marketing question — "who is the target audience" — is not clearly defined, and the proposal is not designed with that point in mind. For me this is fatal. The design should start not from the supply side, but from the demand side.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、特に、最も基本的なマーケティング上の疑問である「ターゲット層は誰か」が明確に定義されておらず、提案はその点を踏まえた設計になっていません。私にとってこれは致命的です。設計は供給側からではなく、需要側から始めるべきです。

### Prior detailed analysis (EN)

**Categorisation**: [Marketing/events / content]. Non-applicable: C1, C2, C4, C5, C6, C7, C8 (no prior C4 cycles to attribute fully), C9, C10, C11.

**Applicable: C3 (target audience + outcome — sole criterion)**. Applying:

• **C3 — Audience is undefined; even if defined, content abundance is not the constraint**: Proposal KPIs are output/process metrics (50M+ views, 850 content pieces, 100% creator retention) without specifying **which audience** is being acquired (developers? ADA holders? DeFi users? institutional outreach? general retail?). The proposal mentions 'wallet creation referrals' and 'DApp click-through' only as 'tracked where measurable' — explicitly not commitments. Effectiveness fundamentally depends on the audience definition, which isn't there.

  **But even with a clearly defined audience, this category isn't where Cardano's actual constraint lies**: Cardano-related video content + educational material already exists in abundance (long-running creator channels, dApp explainers, governance walkthroughs, AI-generated explainers, community-produced tutorials). The kind of content C4 proposes to produce — explainers, marketing videos, ecosystem education — is increasingly producible by AI tools at near-zero marginal cost. Subsidising more of the same volume rarely solves a real problem. Whatever the actual blocker for Cardano awareness/adoption is (audience targeting that nobody else is doing? a content type that AI/community can't replicate? a specific institutional channel?), it is **not** described in the proposal.

  Conditional path: if the proposer can identify (a) a specific audience that current content abundance fails to reach, (b) a content type that genuinely cannot be matched by AI/community supply, and (c) a per-segment outcome KPI tied to that audience's behaviour change, then the proposal becomes evaluable. As currently scoped, it adds volume to an oversupplied layer.

Therefore this proposal does not satisfy this criterion.

### Prior detailed analysis (JA)

**分類**: [Marketing/events / content]。 非適用: C1, C2, C4, C5, C6, C7, C8 (full attribute する prior C4 cycle なし), C9, C10, C11。

**適用: C3 (target audience + outcome — 単独)**。 適用:

・**C3 — audience が未定義; 仮に定義されても content 量は Cardano の真の制約ではない**: 提案書 KPI は output/process metric (50M+ views, 850 content pieces, 100% creator retention) で、 **どの audience** を獲得するか specify せず (developer? ADA holder? DeFi user? institutional outreach? 一般 retail?)。 'Wallet creation referrals' と 'DApp click-through' は 'tracked where measurable' でのみ言及 — 明示的に commitment ではない。 実効性は audience の定義に根本的に依存するが、 それが提案書にない。

  **但し audience が明確に定義されても、 このカテゴリは Cardano の真の制約がある場所ではない**: Cardano 関連の video content + 教育素材は既に潤沢に存在 (長年運営の creator channel、 dApp explainer、 governance walkthrough、 AI 生成 explainer、 コミュニティ作成 tutorial)。 C4 が生成しようとしている content type — explainer、 marketing video、 ecosystem 教育 — は AI tool で marginal cost ほぼゼロで生産可能になりつつある。 同種の量をさらに subsidize しても解決される問題はほとんどない。 Cardano awareness/adoption の真の blocker が何であれ (既存 content abundance が reach できていない特定 audience か? AI/コミュニティが replicate できない content type か? 特定の institutional channel か?)、 それは **提案書に記述されていない**。

  Conditional path: 提案者が (a) 現 content abundance が reach できていない specific audience、 (b) AI/コミュニティ supply で match できない genuinely な content type、 (c) その audience の behaviour change に紐付いた per-segment outcome KPI を identify すれば、 提案は評価可能になる。 現状 scope は oversupplied layer にさらに量を加えるだけ。

よって本提案はこの criterion を満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: Peter Bui
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fac66e89371182537b3096#comment-6a0328a95141bb70a939daf7
- Summary (EN): Proposer (Peter Bui) responds on the undefined-audience (C3) point that audience targets vary by creator strength, and argues that despite AI making generic content cheaper, the scarce and under-produced value is trusted specialist content (dev onboarding, governance walkthroughs, deep tutorials) that C4 is meant to fund.
- Summary (JA): 提案者(Peter Bui)は、対象視聴者が未定義(C3)という指摘に対し、対象は各クリエイターの強みによって異なると応じ、AIが汎用コンテンツを安価にしても、希少で生産不足なのは信頼される専門的コンテンツ(開発者オンボーディング、ガバナンス解説、深い技術チュートリアル)であり、C4はそれに資金提供することを意図していると主張している。

Full text:

Hey Yuta,

> • **C3 — Audience is undefined;&#32;**

Audience targets will vary based on what projects and the community need. Each creator has different strengths and reaches different audiences.

I’m strongest with walkthroughs and educational tutorials. People ask for dev onboarding content, but I don’t usually make it because it gets low views. Funding would let me focus on that work properly.

> **this category isn't where Cardano's actual constraint lies**: 

AI has made generic Cardano content cheaper. But that doesn’t mean specialist content has lost value. It means generic explainers have.

The scarce part isn’t production. It’s trust, distribution, context and accountability.

AI can help make a video. It can’t create the 30K subscribers who already trust a creator enough to listen.

That matters in crypto, where AI content often makes things worse: hallucinated CIPs, wrong governance, fake tokenomics and outdated dApps.

The ecosystem doesn’t need more low-effort AI explainers. It needs trusted people with reputations on the line to correct the noise and cover the hard stuff properly.

That’s why founders still DM creators asking for coverage. If content was truly saturated and interchangeable, that demand wouldn’t exist.

The real blocker is that the most valuable content is often the least rational to produce.

Developer onboarding, governance walkthroughs, long-form interviews and deep technical tutorials take time, but usually get fewer views than price talk or memecoins. Governance Matters is a good example.

That high-effort, high-signal work is under-produced because the market doesn’t reward it. I don’t do governance videos often because only a handful of DReps watch.

C4 is meant to fill that gap. Not to fund more generic content, but to support the specialist work the ecosystem keeps saying it needs.

AI is already part of the workflow. The point is funded specialists using AI as leverage, not replacing accountable creators with more noise.

---

## 35. Cardano Business Development Network: Accelerating Enterprise Adoption Through Coordinated BD Hubs

- Proposal ID: 69f4457693fdcc8059d4cc18
- Requested: 1,519,250 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f4457693fdcc8059d4cc18
- Category: BD network
- Applicable criteria: C3, C4, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

The people who will execute BD must be defined and submitted with CVs before proposal submission. The selection process is not described in the proposal, so I cannot trust the selection process and therefore cannot trust the eventual selection results.

### Voting reason (JA, as of 2026-05-28)

BD を実行する人々は提案書提出前に定義され、 経歴と共に提出される必要があります。 ここについて選定プロセスが提案書から分からないため、 選定プロセスを信頼できず、 従って選定結果も信頼できません。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO** on Cardano Business Development Network: Coordinated BD Hubs (**1.52M ADA / NCL 0.43%**).

**Main reasons**

**1. BD-network category is saturated in Budget #69**

| Budget #69 BD / enterprise-adoption proposal | Ask | Approach |
|---|---|---|
| Cardano Activation Program (CAP) | 6.2M ADA | x402 / agent commerce framing |
| Cardano Enterprise Activation Sandbox | 929K ADA | sandbox + intake metrics |
| Cardano DeFi Activation & Deployment Program | similar BD-network template |
| **Cardano BD Network (this)** | **1.52M ADA** | regional BD hub network |
| Magenta Labs (rejected pattern) | — | same BD-network template |
| Cardano BD Demand Engine (separate) | 20.87M ADA | marketing-funnel framing |

Multiple BD-network proposals competing for similar function = category saturation, not unique opportunity.

**2. KPIs are process metrics + loose "deals closed" definition**

| Target | Count | Process or outcome? |
|---|---|---|
| Regional BD teams | 5-8 | **process** |
| Cardano companies participating | 20+ | **process** |
| Deals closed | 7-10 | **outcome-shaped but undefined** |

"Deals closed" is not defined: signed LOI? signed commercial contract? deployed live on Cardano? generated transactions? Vision 2030 KPI alignment is claimed but there is no specific Cardano transaction or TVL contribution target per team.

**3. Cardano-specific track record is the gap**
- Budget #69 BD-network proposals predominantly come from non-Cardano-native operators (Polygon / ZKsync / Outlier Ventures alumni).
- The successful Cardano BD precedent (STORM Implementation Partner) shows the model can work — but requires a demonstrated Cardano-specific delivery track record.
- This proposal's regional-BD-team approach replicates the model without the predecessor track record.

**4. No Treasury return mechanism**
- BD-as-grant pattern: no revenue share, fee return, or repayment.
- "GTM alignment + reporting (10%)" is process. No commitment of fee revenue or transaction revenue to Treasury.

**5. The real bottleneck is deliverable-pipeline supply, not lead volume**
- Cardano's existing BD ecosystem (STORM, Cardano Foundation BD, Catalyst Pilots) has historically generated a named pilot pipeline larger than the number of pilots that actually convert to production deployment.
- The bottleneck is conversion, not lead volume. Adding 5-8 regional BD teams adds lead-volume capacity to a pipeline that is already constrained on deliverable supply.
- The "unable to qualify leads" problem stated in the proposal may be real, but adding BD hubs does not address the deliverable-supply side (Cardano builder capacity to take on enterprise pilots). Without addressing deliverable supply, BD-hub investment generates leads the ecosystem cannot convert.

**Recommend NO** because: (a) category saturation across multiple parallel BD-network proposals, (b) Cardano-native track record gap for the named consortium, (c) the diagnosis is wrong — the bottleneck is deliverable supply, not lead volume.

### Prior detailed analysis (JA)

**Vote: NO** — Cardano Business Development Network: 地域 BD ハブ網(**1.52M ADA / NCL 0.43%**)に NO。

**主な理由**

**1. Budget #69 内で BD ネットワーク系のカテゴリが飽和**

| Budget #69 の BD / エンタープライズ採用提案 | 要求 | アプローチ |
|---|---|---|
| Cardano Activation Program (CAP) | 6.2M ADA | x402 / エージェントコマース |
| Cardano Enterprise Activation Sandbox | 929K ADA | サンドボックス + 流入指標 |
| Cardano DeFi Activation & Deployment Program | 同系の BD ネットワーク型 | |
| **Cardano BD Network(本提案)** | **1.52M ADA** | 地域 BD ハブ網 |
| Magenta Labs(否決パターン) | — | 同じ BD ネットワーク型 |
| Cardano BD Demand Engine(別件) | 20.87M ADA | マーケティングファネル型 |

似た機能を狙う BD ネットワーク提案が複数 = カテゴリの飽和。独自の機会ではない。

**2. KPI はプロセス指標 + 「成約」の定義が曖昧**

| 目標 | 件数 | プロセス or 成果 |
|---|---|---|
| 地域 BD チーム | 5-8 | **プロセス** |
| 参加 Cardano 企業 | 20+ | **プロセス** |
| 成約 | 7-10 | **成果風だが定義なし** |

「成約」の定義がない:LOI 署名?商用契約署名?Cardano 上で本番稼働?取引発生?Vision 2030 KPI との整合は主張されているが、チーム当たりの Cardano の取引 / TVL 寄与目標はない。

**3. Cardano 固有の実績が欠けている**
- Budget #69 の BD ネットワーク系提案は、Cardano ネイティブではない事業者(Polygon / ZKsync / Outlier Ventures 出身)が中心。
- 成功した Cardano BD 先例(STORM Implementation Partner)は、モデルが機能することを示すが、Cardano 固有の納品実績が前提。
- 本提案の地域 BD チーム方式は、先行実績なしでモデルを模倣している。

**4. トレジャリーへの還元機構なし**
- BD = グラントのパターン:収益分配なし、手数料還元なし、返済なし。
- 「GTM 整合 + 報告(10%)」はプロセス。トレジャリーへの手数料収益 / 取引収益のコミットはない。

**5. 本当のボトルネックはリード量ではなく、納品側の供給**
- Cardano の既存 BD(STORM、Cardano Foundation BD、Catalyst Pilots)は歴史的に、本番デプロイに転換するパイロット数より多くの「名前付きパイロットパイプライン」を生み出してきた。
- ボトルネックは転換であって、リード量ではない。地域 BD チームを 5-8 追加してもリード量を増やすだけで、納品供給の制約は解消しない。
- 提案書の「リードを精査できない」問題はあり得る話だが、BD ハブの追加はそれを解消しない。Cardano ビルダー側がエンタープライズパイロットを引き受ける供給能力に届かない。供給側に手を入れないと、BD ハブへの投資はエコシステムが転換できないリードを生むだけになる。

**NO 推奨**:(a) 並行する BD ネットワーク提案によるカテゴリ飽和、(b) 名前付きコンソーシアムの Cardano 固有実績の欠如、(c) 診断の誤り — ボトルネックはリード量ではなく納品側の供給。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 36. MLabs - Covenant 2: Cross-Language Support and Developer Experience

- Proposal ID: 69fb2be989371182537b3099
- Requested: 1,484,333 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2be989371182537b3099
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Demand evidence in the Cardano ecosystem cannot be read from the proposal.

### Voting reason (JA, as of 2026-05-28)

Cardano エコシステムにおける需要の証拠が提案書から読み取れない。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. The evidence of demand relies almost entirely on "Konma / HaskLedger." Since this is 8 commits, 0 releases, 4 examples, 0 forks, and 1 star, I think it is weak as evidence.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。需要の証拠がほぼ「Konma / HaskLedger」に依拠しています。これは、コミット8・リリース0・サンプル4つ、フォーク0・スター1ですから、これは証拠としては弱いと思います。

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on MLabs - Covenant 2: Cross-Language Support and Developer Experience (**1.46M ADA / NCL 0.42%**).

**Main reasons**

**1. Covenant 1 just shipped — adoption is not yet visible**
- Covenant 1 was funded under Catalyst Fund 13 and is described as **"feature-complete and in stabilisation"**.
- No Cardano smart-contract language (Aiken / Plutarch / Plinth) has publicly committed to migrate its compilation backend to Covenant 1.
- Proposing Covenant 2 (cross-language + developer experience) before Covenant 1's Cardano-language adoption is validated inverts the sequencing.

**2. The Solana bytecode target is scope creep beyond a Cardano Treasury mandate**
- WP2 explicitly extends Covenant to Solana bytecode as a "first proof point" for a universal-glue framing.
- This raises three concrete questions:
  - Is Cardano Treasury the appropriate funder for Solana-bytecode work?
  - Would Solana ecosystem developers actually adopt a Cardano-incubated cross-compiler over native Solana toolchains?
  - Without any named Solana-side commitment, this is speculative.

**3. WP1 has real value but is bundled with WP2**

| WP | Scope | Risk shape |
|---|---|---|
| WP1 | Developer experience: error messages, interfaces, examples, tests, docs | Low risk, clear value to existing Aiken / Plutarch / Plinth users |
| WP2 | Solana bytecode target as universal-glue proof point | High risk, speculative |

Bundling makes WP1's straightforward case harder to evaluate. A per-WP budget split would let a DRep approve WP1 only.

**4. Scope check vs the rest of the Plutus toolchain stack**
- Aiken, Plutarch, and Plinth each have their own optimisation and analysis layers.
- Covenant 1 was meant to become the shared compiler-framework backend, but adoption is unconfirmed.
- TW #103 IO + VacuumLabs Plutus Enhancement (11.88M ADA) covers Plutus Core directly.
- Covenant's position between high-level languages and Plutus bytecode overlaps with what the Plutus Core team handles for Plutus and what TxPipe handles for Aiken's compilation.

**5. MLabs delivery context**
- Per /tx-roi: MLabs cumulative = 40 Catalyst + 393K TW = 12.26M ADA.
- Per Intersect TW: Core Tool Maintenance = 6 of 8 milestones delivered.
- Covenant 1 itself does not yet have public delivery metrics (no named language migrated to it). Proceeding to Covenant 2 is premature.

**Recommend resubmission** with: (a) Covenant 1 adoption evidence (at least one of Aiken / Plutarch / Plinth officially adopting the Covenant 1 backend), (b) WP1 and WP2 split into separate proposals — WP1 alone could plausibly pass on its own merit, (c) explicit Solana-side commitment if WP2 proceeds.

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — MLabs - Covenant 2(多言語対応 + DX、**1.46M ADA / NCL 0.42%**)に NO(再提出推奨)。

**主な理由**

**1. Covenant 1 がちょうど出荷されたばかり。採用がまだ見えない**
- Covenant 1 は Catalyst Fund 13 で資金提供を受け、**「機能完備、安定化中」** と説明されている。
- Aiken / Plutarch / Plinth のいずれも、コンパイル後段を Covenant 1 に切り替えるという公開コミットを出していない。
- Covenant 1 の Cardano 言語側採用が検証される前に Covenant 2(多言語化と DX)を出すのは、順序が逆。

**2. Solana バイトコード対応は Cardano トレジャリーの趣旨を超える**
- WP2 は明示的に、Covenant を Solana バイトコードに「最初の実証」として広げる、と書いている。
- 具体的な疑問が3つ:
  - Solana バイトコード対応の資金提供者として、Cardano トレジャリーは妥当か。
  - Solana のエコシステム開発者が、ネイティブ Solana ツールチェーンではなく Cardano 育ちのクロスコンパイラを採用するのか。
  - Solana 側の採用コミットが1つもない以上、これは投機的。

**3. WP1 は価値があるが、WP2 と束ねられている**

| WP | 範囲 | リスクの形 |
|---|---|---|
| WP1 | DX:エラーメッセージ、インタフェース、例、テスト、ドキュメント | 低リスク、既存の Aiken / Plutarch / Plinth 利用者に明確な価値 |
| WP2 | 「ユニバーサル接着剤」の実証としての Solana バイトコード対応 | 高リスク、投機的 |

抱き合わせのせいで、WP1 の堅い案件としての評価が難しくなっている。WP ごとに予算を分ければ、WP1 だけ承認することが可能。

**4. Plutus ツールチェーン全体との範囲確認**
- Aiken、Plutarch、Plinth はそれぞれ最適化と解析の層を持つ。
- Covenant 1 は共有のコンパイラフレームワーク後段になるはずだったが、採用は未確認。
- TW #103(IO + VacuumLabs Plutus Enhancement、11.88M ADA)は Plutus Core を直接対象にする。
- Covenant の「高水準言語と Plutus バイトコードの間」という立ち位置は、Plutus Core チームが Plutus 用に扱っている領域、および TxPipe が Aiken のコンパイル用に扱っている領域と重なる。

**5. MLabs の納品実績**
- /tx-roi:MLabs 累積 = Catalyst 40件 + TW 393K = 12.26M ADA。
- Intersect TW:コアツール保守 = 8件中6件完了。
- Covenant 1 自体は公開納品指標がまだなく(採用言語が出ていない)、Covenant 2 への前進は時期尚早。

**再提出推奨**:(a) Covenant 1 の採用証拠(Aiken / Plutarch / Plinth のいずれかが公式に Covenant 1 後段を採用)、(b) WP1 と WP2 を別提案に分離(WP1 単独なら通る可能性がある)、(c) WP2 を進めるなら Solana 側の採用コミット。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2be989371182537b3099#comment-6a1e07c2f4bf5dd313f5cf85
- Summary (EN): Proposer (MLabs) presents Konma's HaskLedger adoption of Covenant and c2uplc (with external contributor Vinit Inamke and Fund11 Catalyst history) as the Cardano demand signal, and clarifies Covenant is shared compiler infrastructure below the language layer aimed at consolidation rather than language fragmentation.
- Summary (JA): 提案者(MLabs)は、KonmaのHaskLedgerによるCovenantとc2uplcの採用(外部貢献者Vinit InamkeとFund11 Catalystの履歴を含む)をCardanoの需要シグナルとして提示し、Covenantは言語層の下にある共有コンパイラインフラであり、言語の断片化ではなく統合を目指すものだと明確化している。

Full text:

Thanks, Yuta.

The Cardano demand evidence for Covenant is visible through Konma's HaskLedger work.

Konma Org and the Konma DAO have adopted Covenant and c2uplc for HaskLedger, a Cardano EDSL that lets developers write smart contracts in Haskell's do notation and compile through Covenant. This is publicly visible through the HaskLedger repository, the Fund11 Catalyst milestone history, and issue activity on the Covenant and c2uplc repositories.

The demand signal is not just passive usage either. Vinit Inamke, external to MLabs, has opened issues on both Covenant and c2uplc, worked through integration problems, and maintained a HaskLedger-side fork or copied version. Konma is also the source of the cross-chain requirement in this proposal. Solana support was requested by an actual Cardano ecosystem adopter because HaskLedger's intended use case includes compiling to more than one target.

That is the current demand picture. One serious Cardano adopter, active external contributor engagement, and concrete feature requests coming from real integration work.

The important clarification is that Covenant is not another high-level Cardano smart contract language. It is shared compiler infrastructure below the language layer. The purpose is not to add more language fragmentation. It is to reduce duplicated compiler work across the ecosystem by giving language and framework teams a reusable layer for analysis, optimization, serialization, and code generation. Again, like CTL this proposal favors consolidation, not fragmentation.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2be989371182537b3099#comment-6a1e07dd038cf72ed1e64f28
- Summary (EN): Proposer (MLabs) argues consolidating the lower compiler pipeline avoids repeated infrastructure cost, ties the work to Cardano 2030 Pillar 2 A.3 (developer experience, lowering switching costs), and frames the Solana target not as funding Solana but as proving Covenant can be target-agnostic compiler infrastructure benefiting Cardano-native and cross-chain tools.
- Summary (JA): 提案者(MLabs)は、下位コンパイラパイプラインの統合が反復的なインフラコストを回避すると主張し、本作業をCardano 2030のPillar 2 A.3(開発者体験、移行コスト低減)に結びつけ、SolanaのターゲットはSolanaへの資金提供ではなくCovenantがターゲット非依存のコンパイラインフラになれることを実証するもので、Cardanoネイティブおよびクロスチェーンツールに利益をもたらすと位置づけている。

Full text:

If every language or framework team has to maintain its own lower compiler pipeline, Cardano keeps paying the same infrastructure cost repeatedly. Covenant is an attempt to consolidate that lower layer so teams can focus on developer-facing language design, examples, documentation, and application use cases.

This also speaks directly to Pillar 2 A.3 of the Cardano 2030 framework. A.3 names developer experience, education and migration, and compatibility with common multi-chain tooling as priorities, with the expected enhancement of lowering switching costs versus other L1s. Covenant 2 is one of the few proposals addressing that goal at the compiler-infrastructure level.

The Solana target should be understood in that context. This is not funding Solana for its own sake. It uses a concrete second target, requested by an actual Cardano adopter, to prove that Covenant can become target-agnostic compiler infrastructure. The Cardano benefit is that future Cardano-native and cross-chain tools can support Cardano through a shared backend rather than treating Cardano as a special case requiring a separate compiler pipeline.

Konma's HaskLedger is the first concrete proof point. Covenant 2 is the work required to make that pattern reusable for the next set of adopters.

Here is a video explanation from our CTO:

[https://drive.google.com/file/d/1gWaoRRiL2pGZUP02aUBcLwhfnCWDkBa-/view?usp=sharing](https://drive.google.com/file/d/1gWaoRRiL2pGZUP02aUBcLwhfnCWDkBa-/view?usp=sharing)

---

## 37. Evolution SDK 2026. Hardening to v1.0, Modern DevEx, and the Agent Economy

- Proposal ID: 69fd7ecef9ebc26d057f51da
- Requested: 1,441,996 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd7ecef9ebc26d057f51da
- Category: Infrastructure / SDK
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

As other reviewers have noted, a few items need fixing.
1) Off-chain transaction builders already proliferate (Mesh, Blaze, Buildoor, etc.).
2) The treasury-refund section contains a copy-paste error from a different proposal.

### Voting reason (JA, as of 2026-05-28)

他のレビュアーのコメントにもあるように、 いくつかの改良が必要です。
1) オフチェーン取引ビルダーはすでに乱立している (Mesh、 Blaze、 Buildoor など)。
2) トレジャリー返金セクションに別の提案書のコピペミスがある。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Evolution SDK 2026 - Hardening to v1.0 (**1.44M ADA / NCL 0.41%**).

**Main reasons**

**1. Intersect-incubated standard with delivery history**
- **First project incubated by Intersect's Open Source Committee + Technical Steering Committee** (per proposal).
- Currently ships **125+ modules across 4 packages**. Current release v0.5.7 — the architecture is in place; remaining work is hardening and developer experience.
- Per ADAtool /tx-roi: predecessor Lucid Evolution = 0 Catalyst + 130,903 ADA Treasury Withdrawal, 1 milestone delivered under Intersect TW.

**2. Scope is 4 quarterly milestones with concrete deliverables**

| Quarter | Deliverables |
|---|---|
| Q1 | Public benchmark dashboard + Effect v4 migration plan + v1.0 roadmap |
| Q2 | Effect v4 complete + hot-path optimization + v1.0-rc |
| Q3 | v1.0 GA + plugin SDK + Minswap and SundaeSwap plugins |
| Q4 | Strike + Dano + Fluid plugins + reference yield-route |

- Team: 2 senior engineers + 1 lead for 12 months. $360K-effective USD spread across 3 engineers = $120K USD per engineer — within market for senior TypeScript engineering.

**3. Position vs other Cardano TypeScript SDKs is defined**
- Mesh — broad, beginner-friendly.
- MLabs CTL — geared to Plutarch backends.
- HLabs Pebble — framework-style.
- **Evolution = Effect-based functional TypeScript** — distinct architecture, aimed at DeFi dApps that need composable transaction pipelines.
- Named adopters in the plugin pipeline (Minswap, SundaeSwap, Strike, Dano, Fluid) give a concrete demand signal.

Default YES — Intersect-incubated, named adopters, modest 3-engineer scope tied to dated quarterly milestones.

### Prior detailed analysis (JA)

**Vote: YES** — Evolution SDK 2026 - v1.0 化(**1.44M ADA / NCL 0.41%**)に YES。

**主な理由**

**1. Intersect が育てた標準。実績もある**
- **Intersect のオープンソース委員会と技術運営委員会が最初に育てたプロジェクト**(提案書より)。
- 現在 **4 パッケージで 125 個以上のモジュール** を公開。現バージョン v0.5.7 — 土台はできており、残りは安定化と使い勝手の改善。
- ADAtool /tx-roi より:前身の Lucid Evolution は Catalyst 0件 + Treasury Withdrawal 130,903 ADA、Intersect TW で 1 マイルストーン完了。

**2. 4 四半期ごとに具体的な成果物**

| 四半期 | 成果物 |
|---|---|
| Q1 | 公開ベンチマーク + Effect v4 移行計画 + v1.0 ロードマップ |
| Q2 | Effect v4 完了 + 高速化 + v1.0-rc |
| Q3 | v1.0 正式版 + プラグイン SDK + Minswap / SundaeSwap プラグイン |
| Q4 | Strike / Dano / Fluid プラグイン + 参考利回りルート |

- 体制:シニア2名 + リード1名 × 12か月。$360K を3人で割ると一人 $120K — シニア TypeScript の市場相場の範囲内。

**3. 他の Cardano 用 TypeScript SDK との位置づけが明確**
- Mesh — 幅広く、初心者向け。
- MLabs CTL — Plutarch バックエンド向け。
- HLabs Pebble — フレームワーク型。
- **Evolution** — Effect ベースの関数型。合成可能なトランザクションパイプラインを必要とする DeFi 向けで、設計上明確に差別化されている。
- Minswap、SundaeSwap、Strike、Dano、Fluid が採用予定として名前で挙がっている。

Intersect 育成の標準 + 名前付きの採用予定 + 3人体制 + 日付付きマイルストーン。維持予算として通すべき構造で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 38. MLabs: Better arrays for everyone

- Proposal ID: 69fb2e7485ddd26899aaf1fe
- Requested: 1,401,361 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2e7485ddd26899aaf1fe
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Need concrete evidence: which dApp teams are actually blocked by missing Plinth/Aiken array support, with linked feature requests / issues / waiting users.

### Voting reason (JA, as of 2026-05-28)

実際に Plinth / Aiken の配列サポートが足りなくて困っている dApp チームの具体的な声、 要望 issue、 待っている利用者の証拠を提示する必要があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; regarding the array effort, I would like to check whether there is any duplication or fragmentation.
1. Has the IOG Plutus Core team agreed to accept the `ArrayBuilder` primitive? If yes, please link the confirmation.
2. CIP-138 is still "Proposed." Does M2 depend on it being finalized first, and what happens if CIP-138's design or costing changes?
3. CIP-138 notes that higher-order builtins are coming. Could IOG solve array construction that way instead — and if so, is `ArrayBuilder` still needed?
4. Is any of this Plutus Core array work already funded elsewhere (e.g. the IO + VacuumLabs Plutus Enhancement)?
5. CIP-156 (multiIndexArray) was co-authored by the IOG Plutus Core team together with Anastasia Labs. That appears to be the established model for adding an array primitive — a non-IOG team working with IOG. Why is ArrayBuilder being proposed by MLabs alone, and has the same kind of coordination with the IOG Plutus Core team taken place?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます、アレイの試みについて、重複や断片化がないか確認したいと思っています。
1. Has the IOG Plutus Core team agreed to accept the `ArrayBuilder` primitive? If yes, please link the confirmation.
2. CIP-138 is still "Proposed." Does M2 depend on it being finalized first, and what happens if CIP-138's design or costing changes?
3. CIP-138 notes that higher-order builtins are coming. Could IOG solve array construction that way instead — and if so, is `ArrayBuilder` still needed?
4. Is any of this Plutus Core array work already funded elsewhere (e.g. the IO + VacuumLabs Plutus Enhancement)?
5. CIP-156 (multiIndexArray) was co-authored by the IOG Plutus Core team together with Anastasia Labs. That appears to be the established model for adding an array primitive — a non-IOG team working with IOG. Why is ArrayBuilder being proposed by MLabs alone, and has the same kind of coordination with the IOG Plutus Core team taken place?

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on MLabs: Better arrays for everyone (**1.38M ADA / NCL 0.39%**).

**Main reasons**

**1. The gap is real, but no named dApp has asked for the new primitives**
- Per proposal: CIP-138 added basic array support; Plutarch is most developed; Plinth and Aiken lag.
- The proposal closes the parity gap, adds new array primitives, and applies functional optimisation.
- The technical need is real — arrays are fundamental for financial calculations, batched transfers, table-based aggregation.
- But no named Cardano dApp commits to consume the new array primitives. The improvement is in the abstract, not anchored to a specific protocol bottleneck.

**2. Three-language scope with no consumer commitments**

| Scope item | Effort | Consumer commitment |
|---|---|---|
| Plinth array parity (catch up to Plutarch) | maintenance + feature | none named |
| Aiken array parity (catch up to Plutarch) | maintenance + feature | none named |
| New CIP introducing array primitives to Plutus Core | spec + implementation | none named |
| Functional optimisation | research | no benchmark target tied to a named dApp |

1.38M ADA / 3 languages ≈ $115K USD per language at ADA $0.25 — within market for the work. But absent consumer commitments, this is a "build it and hope" proposal.

**3. Sequencing: array performance is not the cited Plutus bottleneck**
- Cardano DeFi protocols (Minswap, Liqwid, Indigo) have not publicly cited array performance as their current Plutus bottleneck.
- More frequently cited bottlenecks: script size limits, execution-unit budget, validator deserialisation cost.
- Array work may pay off later, but it is not currently the highest-leverage Plutus performance work.

**4. Scope check versus IO TW #103**
- TW #103 IO + VacuumLabs Plutus Enhancement (11.88M ADA) likely covers core Plutus performance work.
- Whether arrays are part of #103 or a gap above it needs explicit delineation.

**5. MLabs delivery context + cross-team coordination**
- Per /tx-roi: MLabs cumulative = 40 Catalyst + 393K TW = 12.26M ADA.
- Per Intersect TW: Core Tool Maintenance = 6 of 8 milestones delivered.
- Plinth and Aiken parity extends MLabs maintenance to languages MLabs does not own — coordination with Plinth (IO) and Aiken (TxPipe / Pragma) teams is a real concern.

**Recommend resubmission** with: (a) at least one named Cardano DeFi / RWA protocol committing to consume new array primitives with a specific performance target, (b) explicit delineation against IO TW #103, (c) cross-team coordination commitments with the Plinth and Aiken teams.

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — MLabs: Better arrays for everyone(**1.38M ADA / NCL 0.39%**)に NO(再提出推奨)。

**主な理由**

**1. 空白は本物だが、新プリミティブを求めた名前付き dApp がない**
- 提案書:CIP-138 で基本的な配列対応が入った。Plutarch がもっとも進んでおり、Plinth と Aiken は遅れている。
- 本提案は格差を解消し、新しい配列プリミティブを追加、関数型最適化を適用する。
- 技術的な必要性はある。配列は金融計算、バッチ送金、表形式の集計に基本的に使うもの。
- しかし、新しい配列プリミティブを使うと約束した Cardano dApp が1つも挙がっていない。具体的なプロトコル側のボトルネックに紐付いていない。

**2. 3言語にまたがる範囲。採用側の約束がない**

| 範囲項目 | 工数 | 採用側の約束 |
|---|---|---|
| Plinth の配列を Plutarch に追いつかせる | 保守 + 機能 | なし |
| Aiken の配列を Plutarch に追いつかせる | 保守 + 機能 | なし |
| Plutus Core に配列プリミティブを入れる新 CIP | 仕様 + 実装 | なし |
| 関数型最適化 | 研究 | 名前付き dApp と紐付くベンチマークなし |

1.38M ADA / 3 言語 = 言語当たり 約 $115K USD(ADA $0.25)。作業に対する相場の範囲内。だが採用側の約束がない以上、「作れば誰か使うはず」型の提案になっている。

**3. 順序:配列性能は現状の Plutus ボトルネックとして語られていない**
- Cardano DeFi(Minswap、Liqwid、Indigo)は、配列性能を Plutus 上の現状ボトルネックとして公に挙げていない。
- よく挙がるボトルネック:スクリプトサイズ上限、実行ユニット予算、バリデータのデシリアライズコスト。
- 配列の改善は将来効くかもしれないが、今もっとも効く Plutus 性能改善ではない。

**4. IO TW #103 との範囲確認**
- TW #103(IO + VacuumLabs Plutus Enhancement、11.88M ADA)は、Plutus 中核の性能改善を含む可能性が高い。
- 配列が #103 の中か、#103 の外の空白か、明示が必要。

**5. MLabs の納品実績とチーム間調整**
- /tx-roi:MLabs 累積 = Catalyst 40件 + TW 393K = 12.26M ADA。
- Intersect TW:コアツール保守 = 8件中6件完了。
- Plinth と Aiken の整備は、MLabs が保守していない言語に保守範囲を広げる。Plinth(IO)と Aiken(TxPipe / Pragma)のチームとの調整が懸念点。

**再提出推奨**:(a) 新配列プリミティブの採用を約束する Cardano DeFi / RWA プロトコルを1つ以上、性能目標とともに、(b) IO TW #103 との切り分けを明示、(c) Plinth と Aiken のチームとの調整の約束。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2e7485ddd26899aaf1fe#comment-6a1e0862a7468bb49bf846ee
- Summary (EN): Proposer (MLabs) argues that for primitive-level smart contract infrastructure the demand signal is the writing, review, and acceptance of CIP-138 to add array support to UPLC, and that missing primitive performance shows up as avoided designs and workarounds rather than clean GitHub issues.
- Summary (JA): 提案者(MLabs)は、プリミティブ層のスマートコントラクトインフラでは、需要シグナルはUPLCに配列サポートを追加するCIP-138の起草・レビュー・受理であると主張し、プリミティブの性能不足は明確なGitHub issueではなく回避された設計や回避策として現れると論じている。

Full text:

Thanks, Yuta.

This is the right kind of question to ask, but for primitive-level smart contract infrastructure, the evidence has to be read differently than for an application feature request.

Arrays are not a niche feature for one dApp. They are a basic computational primitive. The demand signal already exists in the fact that CIP-138 was written, reviewed, and accepted to add array support to UPLC. This proposal is the next step on that same trajectory. It makes that primitive usable across Plinth, Plutarch, and Aiken, then adds the optimization work needed for array support to be practical rather than merely available.

The issue with asking only for named dApps blocked by missing Plinth or Aiken array support is that missing primitive-level performance often does not show up as a clean GitHub issue. It shows up as avoided designs, hand-optimized workarounds, developers choosing a different language, or developers choosing another chain before they ever file an issue in a Cardano repository.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2e7485ddd26899aaf1fe#comment-6a1e087b05e47100cbda5c54
- Summary (EN): Proposer (MLabs) notes an asymmetry where Plutarch has more developed array tooling than Plinth and Aiken, frames it as a developer-experience problem aligned with Cardano 2030 Pillar 2 A.3, and argues CIP-138 already established arrays as a needed primitive that this proposal completes across the major languages.
- Summary (JA): 提案者(MLabs)は、PlutarchがPlinthやAikenより配列ツールが発達しているという非対称性を指摘し、これをCardano 2030のPillar 2 A.3に沿った開発者体験の問題と位置づけ、CIP-138がすでに配列を必要なプリミティブとして確立しており、本提案がそれを主要言語全体で完成させると主張している。

Full text:

There is already an asymmetry inside Cardano. Plutarch has more developed array tooling, while Plinth and Aiken are behind. That is a developer-experience problem. A developer's access to efficient array patterns should not depend so heavily on which of Cardano's main smart contract languages they choose.

This is also directly aligned with Cardano 2030 Pillar 2 A.3. That section emphasizes developer experience, education and migration, compatibility with common tooling, and lowering switching costs versus other L1s. Better, more consistent array support across Cardano's main smart contract languages helps with exactly that. Developers coming from other ecosystems expect basic data structures to be available, performant, and documented.

So the demand case is not one waiting dApp. The demand case is that Cardano already accepted arrays as a needed primitive through CIP-138, but language-level support is still uneven and under-optimized. This proposal finishes that work across the major smart contract languages rather than leaving each language and each dApp team to solve it separately.

Here is a video explanation from our CTO: https://drive.google.com/file/d/18TTKqBdiDblWJtQaX\_xxSnPj8z\_PVnwE/view?usp=drive\_link

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb2e7485ddd26899aaf1fe#comment-6a1e136c7d5f66c5487662ad
- Summary (EN): Proposer (MLabs) posts a correction with the public video link.
- Summary (JA): 提案者(MLabs)は公開用の動画リンクの訂正を投稿している。

Full text:

Sorry, this is the public video link:

[https://drive.google.com/file/d/18TTKqBdiDblWJtQaX\_xxSnPj8z\_PVnwE/view](https://drive.google.com/file/d/18TTKqBdiDblWJtQaX_xxSnPj8z_PVnwE/view)

---

## 39. Ecosera: The End-to-End Clinical Research Ecosystem — From Trial Funding to Drug Approval on Cardano

- Proposal ID: 69fa093992f043aa2df1a283
- Requested: 1,390,508 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa093992f043aa2df1a283
- Category: dApp - RWA
- Applicable criteria: C1, C4, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. Could not find sufficient evidence that the revenue-share commitment is achievable within any meaningful time horizon.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 収益分配コミットメントが一定期間に達成しうるという十分な証拠を確認できなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; it still appears that the uncertainty of the return is high relative to the risk of this proposal. In cases where the Tx and the contribution to returns are not certain, could you define a quantitative definition of success in the Cardano ecosystem that this proposal would bring about? Also, in order to achieve that quantitative success, would it be possible to provide the proposer's own analysis of what the greatest barriers and risks to this proposal are, along with an analysis of why those are at a reasonably low level?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、依然としてこの提案書のリスクに対してリターンの不確実性が高いように見えています。Txやリターンの寄与は確実ではない場合、この提案書がもたらすCardanoエコシステムにおける成功の定量的な定義を定義できますでしょうか?また、その定量的な成功を達成するために、この提案書の最大の障壁とリスクは何かについて提案者自信の分析と、それらが合理的な水準に低い点についての分析を提供することは可能でしょうか?

### Prior detailed analysis (EN)

**Categorisation**: [dApp-RWA / clinical research]. Non-applicable: C2, C5, C6, C7, C8 (no prior cycles), C10, C11.

**Applicable: C1, C4, C9**. Applying:

• **C1 — Tx contribution structurally low**: Clinical trial / pharma supply chain has very low transaction frequency (per-batch / per-trial-event basis). Empirical references:
  - Pharma supply chain blockchain pilots (MediLedger, etc.) generate hundreds-to-thousands of tx/month at full scale
  - Clinical trial smart contracts: per-milestone events, low cadence (not real-time)
  Result: 0.001-0.01% of Cardano monthly 800K tx baseline ceiling, similar to Floriculture / GOV.EXE.

• **C4 — Public-funded private-capture risk**: If commercial fee structure is post-launch (typical for pharma platforms), Treasury investment captures public infrastructure value privately. Same Floriculture / Bridge Fund concern. Proposal must specify Treasury revenue share to satisfy C4.

• **C9 — Pharma blockchain pilot historical success rate**: Pilot completion ≠ production deployment ≠ replication. Pharma is heavily regulated, slow-moving. Treasury investment in domain-specific blockchain pilots (cross multiple verticals) historically have low conversion-to-production rates. Without named regulatory partnership commitment + signed LOIs, this falls into high-failure-rate category.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-RWA / 臨床研究]。 非適用: C2, C5, C6, C7, C8 (prior cycle なし), C10, C11。

**適用: C1, C4, C9**。 適用:

・**C1 — Tx 寄与構造的低**: 臨床 trial / pharma supply chain は非常に低 tx 頻度 (per-batch / per-trial-event basis)。 Empirical reference:
  - Pharma supply chain blockchain pilot (MediLedger 等) は full scale で月次数百〜数千 tx 生成
  - 臨床 trial smart contract: per-milestone event で低 cadence (real-time でない)
  結果: Cardano 月次 800K tx baseline の 0.001-0.01% ceiling、 Floriculture / GOV.EXE 同様。

・**C4 — Public-funded private-capture リスク**: Commercial fee structure が post-launch なら (pharma platform 典型) Treasury 投資が public infra value を privately capture。 Floriculture / Bridge Fund 同 concern。 提案書は Treasury revenue share を specify して C4 を satisfy 必要。

・**C9 — Pharma blockchain pilot 歴史的成功率**: Pilot 完了 ≠ production deployment ≠ replication。 Pharma は heavily regulated、 slow-moving。 Domain-specific blockchain pilot (複数 vertical 横断) の Treasury 投資は歴史的に conversion-to-production 率低。 Named regulatory partnership commitment + signed LOI なしでは high-failure-rate category。

よって本提案はこれらを満たさない。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa093992f043aa2df1a283#comment-6a0356d905e47100cbda5bb1
- Summary (EN): Resubmitted with amendments to all three flagged criteria: C1 concedes direct fee-recapture math doesn't carry the budget; C4 adds binding on-chain 10% net platform-fee revenue share to a public Treasury address until principal recovered (WP3 adapter); C9 replaces aspirational FDA contact with EOM Pharmaceuticals (IND #181300) as named commercial sponsor.
- Summary (JA): 3基準すべてに修正を加えて再提出。C1: 直接の手数料回収計算では予算を正当化しないと明示。C4: WP3アダプタでネット手数料の10%を公開トレジャリーアドレスへ毎月送る拘束的オンチェーン・レベニューシェアを追加 (元本回収まで)。C9: 観念的なFDA言及を削除しEOM Pharmaceuticals (IND #181300)を名指しのスポンサーとして提示。

Full text:

> Hi Yuta — thank you for the review and for the transparency on your framework.

We've read your full rationale at adatool.net/b69-share and are resubmitting the proposal with direct amendments addressing all three criteria:

C1 (transaction volume math): We've added a "Treasury Alignment, Direct Fee Math, and Value Capture" section to the KPIs field that explicitly concedes the direct L1 fee-recapture math doesn't carry the budget. We're not asking DReps to evaluate this on fee recapture — we're asking them to evaluate it on regulated-vertical activation and the revenue-share commitment below.

C4 (public-funded private-capture): The Repayment Circumstances field now specifies a binding, on-chain revenue-share commitment: 10% of net platform-fee revenue routed monthly to a public Treasury address via the WP3 settlement adapter, until the full 1,390,508 ADA grant principal is recovered. In parallel, every platform event generates L1 transaction fees to the network in perpetuity. The WP3 adapter implements this as on-chain logic, not a discretionary pledge.

C9 (regulatory pilot — missing named commitments): We've removed the aspirational FDA contact reference and replaced it with language grounded in what's actually documentable: EOM Pharmaceuticals (IND #181300, cancer cachexia indication) as the named commercial sponsor counterparty, and FDA-RTCT/RWE-aligned documentation as the deliverable.

We welcome any follow-up questions here. If the resubmission moves your vote, we'd appreciate knowing what, if anything, remains unresolved.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa093992f043aa2df1a283#comment-6a1d5669a7468bb49bf846e3
- Summary (EN): Proposer clarifies that the 10% platform-fee revenue share is not a guarantee of full grant recovery but a structural alignment mechanism addressing the public-funded/private-capture concern, and argues the proposal should be evaluated on the Cardano infrastructure delivered (WP1-WP3), the regulated-industry adoption pathway, and open-source artifacts rather than on treasury principal recovery.
- Summary (JA): 提案者は、10%のプラットフォーム手数料収益分配は助成金全額回収の保証ではなく、公的資金/私的取得の懸念に対処する構造的アライメント機構だと明確化し、本提案はトレジャリーの元本回収ではなく、提供されるCardanoインフラ(WP1〜WP3)、規制業界の採用経路、オープンソース成果物に基づいて評価されるべきだと主張している。

Full text:

> Hi Yuta — thank you for updating the rationale and summarizing the feedback received.

One clarification regarding the revenue-share mechanism, as we may not have communicated the intent clearly enough.

The purpose of the 10% platform-fee revenue share is not to suggest or guarantee that the Treasury will recover the full grant amount within a defined period. We agree that, at the current stage of commercialization, projecting a specific recovery timeline would be speculative and we have intentionally avoided making such claims.

Rather, the revenue share was introduced as a structural alignment mechanism intended to address the public-funded/private-capture concern. If Ecosera succeeds commercially, the Treasury participates directly in that success through a transparent and auditable on-chain mechanism. If Ecosera does not achieve meaningful commercial adoption, then the revenue share correspondingly has limited value.

We believe the proposal should therefore be evaluated primarily on the merits of the Cardano infrastructure being delivered (WP1–WP3), the regulated-industry adoption pathway being pursued, and the open-source artifacts being contributed to the ecosystem, rather than on an assumption that Treasury principal recovery is the primary source of ROI.

We appreciate the review and the opportunity to clarify this distinction.

---

## 40. MLabs: Encrypted Programmable Tokens with TFHE

- Proposal ID: 69fb450f8a0de51b89857e10
- Requested: 1,366,456 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb450f8a0de51b89857e10
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

As other commenters noted, technical feasibility must be examined first. Approving this work scope while feasibility is unclear is likely premature.

### Voting reason (JA, as of 2026-05-28)

他のコメントにもあるように、 技術的な実現可能性が最初に検討される必要がある。 また、 技術的な実現可能性が不明瞭な状況でこの作業範囲を承認することは困難な可能性がある。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. perturbing asked, because TFHE may not fit Plutus's execution limits, for an early go/no-go gate (with stop/refund if impractical) before Plutus Core integration. your Comment answers with the milestone order (M1→…→M5), but not the actual question: where is the decisive Plutus-fit check made, and can a hard stop/refund trigger before most of the budget is spent? This seems to talk past the request — could you clarify? 🙏

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。perturbing asked, because TFHE may not fit Plutus's execution limits, for an early go/no-go gate (with stop/refund if impractical) before Plutus Core integration. your Comment answers with the milestone order (M1→…→M5), but not the actual question: where is the decisive Plutus-fit check made, and can a hard stop/refund trigger before most of the budget is spent? This seems to talk past the request — could you clarify? 🙏

### Prior detailed analysis (EN)

**Vote: NO** on MLabs: Encrypted Programmable Tokens with TFHE (**1.34M ADA / NCL 0.38%**).

**Main reasons**

**1. Two recognised Cardano cryptography reviewers raised TFHE-specific concerns**
- **@0xdasha** flagged concerns about the TFHE choice for Cardano confidential tokens.
- **@perturbing** also signalled against TFHE here (independent of the PQ proposal, which @perturbing did approve).
- Two independent technical reviewers raising TFHE-specific concerns is a real signal, separate from any general "is privacy useful" debate.

**2. TFHE-specific technical concerns**
- **Patent landscape**: the proposal itself acknowledges that Zama's TFHE library is patent-restricted to non-commercial use. The Apache 2.0 reference TFHE library that would be used as a clean-room target is described in the proposal text as **"not production-grade"**.
- Building a production-grade clean-room TFHE in Haskell is significant cryptographic engineering risk.
- Alternative privacy primitives exist (MPC, zk-SNARKs for shielded transfers, FHE alternatives like CKKS / BFV / BGV) — TFHE is one branch of a contested design space.

**3. CIP-113 was launched in March 2026 — it is only 2 months old**
- CIP-113 (Programmable Tokens) launched March 2026 — only ~2 months of production at evaluation time.
- Adding a TFHE-encrypted extension on top of a brand-new standard inverts the normal sequencing.
- Even the plain CIP-113 named adopters (regulated stablecoins, RWA tokens, payroll) are themselves pre-launch on Cardano. Demand for a confidential extension is downstream of base adoption — which is itself unvalidated.

**4. Three stacked deliverables, each with high technical risk**

| Deliverable | Risk |
|---|---|
| 1. Clean-room Haskell TFHE library (Hackage-published) | Patent-clean + production-grade is non-trivial |
| 2. CIP extending CIP-113 with encryption primitives | Spec risk — CIP-113 itself is new |
| 3. Plutus Core primitive implementation | Plutus protocol-level change risk |

1.34M ADA across these — failure on (1) blocks (2) and (3). The risks stack.

**5. MLabs delivery context**
- Per /tx-roi: MLabs cumulative = 40 Catalyst + 393K TW = 12.26M ADA.
- Per Intersect TW: Core Tool Maintenance = 6 of 8 milestones delivered. That is maintenance evidence — not cryptographic-implementation evidence at TFHE complexity. Track-record transfer is uncertain.

**Recommend NO** (not resubmit) because: (a) two independent cryptographers raised TFHE-specific concerns, (b) CIP-113 itself is unvalidated for adoption — a confidential extension on top is premature, (c) the correct order is: validate CIP-113 demand → then propose a confidential extension with named regulated-finance / RWA adopters committing to a TFHE-encrypted variant.

### Prior detailed analysis (JA)

**Vote: NO** — MLabs: TFHE による暗号化プログラマブルトークン(**1.34M ADA / NCL 0.38%**)に NO。

**主な理由**

**1. 認知された Cardano 暗号レビュアー2名が TFHE 選択に懸念を表明**
- **@0xdasha**:Cardano 機密トークンに TFHE を採用することに懸念を表明。
- **@perturbing**:本件でも TFHE 選択に反対のシグナル(同氏は別件の PQ 提案には賛成)。
- 独立した技術レビュアー2名が TFHE 固有の懸念を表明している。これは「プライバシーは有用か」といった一般論とは別の、実在のシグナル。

**2. TFHE 固有の技術的懸念**
- **特許**:提案書自身、Zama の TFHE ライブラリは非商用に限定された特許制約があると認めている。クリーンルーム実装の目標とされる Apache 2.0 リファレンス TFHE ライブラリは、提案書本文で **「本番グレードではない」** と記載されている。
- 本番グレードのクリーンルーム TFHE を Haskell で作るのは、暗号工学として相応のリスク。
- 代替のプライバシー基本要素は他にもある(MPC、シールド送金用 zk-SNARK、CKKS / BFV / BGV などの他の FHE)。TFHE はまだ議論中の設計空間の一枝。

**3. CIP-113 は 2026年3月公開、まだ2か月**
- CIP-113(プログラマブルトークン標準)は 2026年3月公開。評価時点で本番運用は約2か月のみ。
- 出たばかりの標準の上に TFHE 暗号拡張を載せるのは、順序が逆。
- 素の CIP-113 を採用予定の主体(規制対応ステーブルコイン、RWA トークン、給与)も Cardano 上ではまだ立ち上げ前。機密拡張への需要は、CIP-113 そのものの採用の後に来る。

**4. 3つの成果物にリスクが積み重なっている**

| 成果物 | リスク |
|---|---|
| 1. Hackage 公開クリーンルーム Haskell TFHE | 特許回避と本番グレード両立は容易ではない |
| 2. CIP-113 を暗号で拡張する CIP | 仕様リスク。CIP-113 自体が新しい |
| 3. Plutus Core プリミティブ実装 | Plutus プロトコルレベルの変更リスク |

1.34M ADA をこれらに当てるが、(1) が失敗すれば (2) と (3) が止まる。リスクが直列。

**5. MLabs の納品実績**
- /tx-roi:MLabs 累積 = Catalyst 40件 + TW 393K = 12.26M ADA。
- Intersect TW:コアツール保守 = 8件中6件完了。これは保守の実績で、TFHE 規模の暗号実装の実績ではない。実績の移転は不確実。

**NO 推奨**(再提出推奨ではない):(a) 独立した暗号レビュアー2名が TFHE 固有の懸念を提起、(b) ベースの CIP-113 自体が採用未検証で、その上の機密拡張は時期尚早、(c) 正しい順序は「CIP-113 の需要を検証 → TFHE 暗号版を採用する名前付き規制対応金融 / RWA 主体と共に機密拡張提案」。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb450f8a0de51b89857e10#comment-6a1e08fa5141bb70a939dbb8
- Summary (EN): Proposer (MLabs) agrees TFHE technical feasibility must be examined carefully and not treated as settled, but argues that since confidential token functionality exists or is being developed elsewhere and Cardano is behind, encrypted balances and transfer amounts are worth evaluating seriously for CIP-113 programmable tokens serving institutional settlement, regulated stablecoins, payroll, and RWA use cases.
- Summary (JA): 提案者(MLabs)はTFHEの技術的実現可能性は慎重に検証すべきで既決事項として扱うべきではないと同意しつつ、機密トークン機能は他所で存在・開発中でCardanoは遅れているため、機関決済・規制ステーブルコイン・給与・RWAのユースケースに役立つCIP-113プログラマブルトークンにとって暗号化残高と送金額は真剣に評価する価値があると主張している。

Full text:

Thank you, Yuta.

We agree that technical feasibility needs to be examined carefully. TFHE is advanced cryptographic work, and it would not be responsible to treat implementation cost, performance, or protocol suitability as settled questions before doing the engineering analysis.

That said, this kind of feasibility work requires serious implementation effort. Confidential token functionality already exists or is being developed in other ecosystems, and Cardano is currently behind on that capability. If Cardano wants CIP-113 programmable tokens to serve institutional settlement, regulated stablecoins, payroll, and RWA use cases, then encrypted balances and encrypted transfer amounts are a capability worth evaluating seriously.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb450f8a0de51b89857e10#comment-6a1e0916ceb7fef00be0e50a
- Summary (EN): Proposer (MLabs) ties the work to Cardano 2030's Adoption & Utility focus and describes a staged milestone structure (clean-room Haskell TFHE library, CIP, tests/benchmarks, optimization, then Plutus Core implementation last) designed to test feasibility before final integration, committing to publish findings and return unused funds if a fundamental blocker is found.
- Summary (JA): 提案者(MLabs)は本作業をCardano 2030のAdoption & Utilityの焦点に結びつけ、段階的なマイルストーン構造(クリーンルームのHaskell TFHEライブラリ、CIP、テスト/ベンチマーク、最適化、最後にPlutus Core実装)を説明し、最終統合前に実現可能性を検証する設計で、根本的な障害が見つかれば結果を公開し未使用資金を返還すると約束している。

Full text:

This also aligns directly with Cardano 2030’s focus on Adoption & Utility, especially high-value verticals, enterprise security and compliance, and compatibility with capabilities emerging on other L1s.

The proposal is structured with that uncertainty in mind. It does not begin by adding primitives directly to Plutus Core. It begins with a clean-room Haskell TFHE library, then a CIP describing the required encrypted programmable token operations, then verification through tests and benchmarks, then optimization and a performance report. Plutus Core implementation comes only after those earlier stages provide the evidence needed to proceed.

If the implementation process reveals a fundamental feasibility blocker, we would not continue spending against the original scope. We would publish our findings, revise the affected work if possible, and return any material unused funds to the treasury if needed. We believe the work is feasible, but the milestone structure is designed to test that before final Plutus Core integration and to protect treasury value while pursuing an R&D proposal aligned with Cardano 2030 Pillar 2, Adoption & Utility.

Here is a video explanation from our CTO: [https://drive.google.com/file/d/1x1AcmrYgXboaFwc2MXaTWQkysNwEIfOF/view?usp=drive\_link](https://drive.google.com/file/d/1x1AcmrYgXboaFwc2MXaTWQkysNwEIfOF/view?usp=drive_link)

---

## 41. Enhance Swarm Treasury System with Open Social Governance

- Proposal ID: 69fc8c2285ddd26899aaf20d
- Requested: 1,350,330 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8c2285ddd26899aaf20d
- Category: dApp - other
- Applicable criteria: C1, C4, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Regarding Tx, it is acknowledged that it is low. As for TVL, I was unable to read off the past track record and target figures, so I cannot evaluate it. Since I still consider the verifiable impact relative to this funding amount to be limited, whether viewed from Tx or from TVL, I maintain my NO vote.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。Txに関してはそれが少ないことが認められています。TVLについても過去実績と目標数値を読み取ることができませんでしたので評価できません。依然としてこの資金調達額に対してこれらTxから見てもTVLから見ても検証可能なインパクトが限定的と考えられるためNOの投票を維持します。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-other / governance tooling]. Non-applicable: C2 (proposer has Cardano track record), C3, C5, C6, C7, C9 (governance tooling demand exists in principle), C10, C11.

**Applicable: C1, C4, C8**. Applying:

• **C1 — Tx contribution negligible**: Year 1 targets — 100 bundle tx + 200 wallets — represent 0.001% of Cardano's monthly 800K tx baseline. Even at 10× over-delivery, contribution would still be <0.01% of monthly tx.

• **C4 — Tx fee recovery on astronomical timescale**: 100 bundle tx Year 1 × $0.04 fee × 50% Treasury share = $2/year. Recovery period for any meaningful grant size = effectively permanent grant.

• **C8 — Past funded projects' attribution weak**: Per the proposal, the Swarm Treasury System has been operational 4+ years and has generated 350+ bundle tx total. That averages 85-100 tx/year — extremely small monthly/annual cadence. For other completed Catalyst projects by the same proposer:
  - Redis State Channels DRED
  - Universal Skills Authentication
  - cPoker Dred
  - Stellar Contracts
  None of these have public-information-verifiable production deployment, Cardano builder adoption, or Tx/TVL contribution. Completed project count is high (7+), but **empirical Cardano ecosystem contribution lacks sufficient evidence per project**.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-other / governance tooling]。 非適用: C2 (提案者 Cardano track record あり), C3, C5, C6, C7, C9 (governance tooling demand は原理的に存在), C10, C11。

**適用: C1, C4, C8**。 適用:

・**C1 — Tx 寄与 negligible**: Year 1 目標 — 100 bundle tx + 200 wallets — は Cardano 月次 800K tx baseline の 0.001%。 10× over-delivery でも月次 tx の <0.01%。

・**C4 — Tx fee 経由回収 astronomical timescale**: Year 1 100 bundle tx × $0.04 fee × 50% Treasury share = $2/年。 任意 meaningful grant size の回収期間 = 実質永久 grant。

・**C8 — 過去 funded project の attribution 弱い**: 提案書より Swarm Treasury System は 4+ 年稼働で 350+ bundle tx total 生成。 平均 85-100 tx/年 — 極めて小さい月次/年次 cadence。 同提案者の他 completed Catalyst project:
  - Redis State Channels DRED
  - Universal Skills Authentication
  - cPoker Dred
  - Stellar Contracts
  いずれも public-information で verifiable な production deployment / Cardano builder adoption / Tx/TVL 寄与なし。 完了 project 数は多い (7+) が、 **per-project の empirical Cardano ecosystem 寄与の evidence 不足**。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8c2285ddd26899aaf20d#comment-6a0c17e805e47100cbda5bd5
- Summary (EN): Direct pushback on AI-assisted rationale: disputes that TVL is 'narrative' (says it can be measured and is a Cardano KPI). Argues C4 'profit from treasury investment' misreads them — fees go to Cardano + SPOs, not operators. On C8, argues their team produces transactions and maintains tools/services years after prior funding.
- Summary (JA): AI援用のrationaleに直接反論: TVLが「ナラティブ」だという指摘に異議 (TVLは計測可能でCardanoのKPI)。C4の「トレジャリー投資からの利益」も誤読 (手数料はCardanoとSPOへ、運営者ではない)。C8については過去資金後も継続してtxを生み公開ツールやサービスを提供していると主張。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C1, C4, C8).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

C1 - Your AI says TVL is a narrative? I don't understand, we still going to produce TVL and can measure it and Cardano KPI's are expecting it. SO your AI dismissing the fact that TVL should not be measured is odd statement.

Your C4 reason is " *Public-good infrastructure / research / education are intentionally non-revenue-generating; demanding Treasury return is misaligned. For commercial dApps profiting from Treasury investment, however, return mechanism is critical."*

Your AI assumes we take profit from treasury transaction, its not true Cardano Treasury and SPO's earn the fees from those transactions, not us the operators.

And for the C8 you say "*Reason for exclusion:* *Core protocol is iterative work; outcome is the next protocol version. Wallet maintenance is continuous and outcome-attribution per cycle is artificial."*

but your criterion is this: "Repeat-funded proposers must demonstrate that prior cycles produced verifiable Cardano-specific outcomes. 'Completed' Catalyst status alone is insufficient — outcome must be Cardano builder adoption / production deployment / Tx contribution, not internal team activity. /tx-roi backend (https://adatool.net/tx-roi) provides the systematic prior-funding lookup."

We create transactions and we have public tools and provide services for years now after the proposal completion.

---

## 42. Open Sourced RWA Tokenization Framework with Revenue Share Model

- Proposal ID: 69ecf1ea93fdcc8059d4cc0a
- Requested: 1,339,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ecf1ea93fdcc8059d4cc0a
- Category: dApp - RWA
- Applicable criteria: C1
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: [dApp-RWA]. Non-applicable: C2, C3, C4, C5, C6, C7, C8, C9, C10, C11.

**Applicable: C1 (sole, decisive)**. Applying:

• **C1 — Tx/TVL contribution trivial (decisive)**: Proposal commits Min new RWA TVL = $100K. Quantitative analysis:
  - $100K / $132M Cardano DeFi TVL (April 2026 per DefiLlama) = **0.076%**
  - $335K Treasury invest → $100K TVL = **negative ROI: $3.35 invested per $1 of TVL created**

  Specific use case scale:
  - 250 heads of cattle: family-farm scale (commercial feedlots typically 1,000-50,000 heads per facility per USDA cattle-on-feed data)
  - Lifecycle tx low frequency: cattle 4-6 month finishing cycles + real estate ~1 year holding cycles
  - Total: hundreds of tx annually, ≪ Cardano monthly 800K tx baseline

  Per-ADA capital efficiency is structurally negative for this proposal.

Therefore this proposal does not satisfy this criterion.

### Prior detailed analysis (JA)

**分類**: [dApp-RWA]。 非適用: C2, C3, C4, C5, C6, C7, C8, C9, C10, C11。

**適用: C1 (単独 decisive)**。 適用:

・**C1 — Tx/TVL 寄与 trivial (decisive)**: 提案書 commit Min new RWA TVL = $100K。 数値分析:
  - $100K / $132M Cardano DeFi TVL (2026年4月 per DefiLlama) = **0.076%**
  - $335K Treasury 投資 → $100K TVL = **negative ROI: $3.35 invest per $1 TVL created**

  Specific use case scale:
  - 250 頭の牛: family-farm scale (commercial feedlot は典型 facility 当たり 1,000-50,000 頭 per USDA cattle-on-feed data)
  - Lifecycle tx 低頻度: 牛 4-6 ヶ月 finishing cycle + 不動産 ~1 年 holding cycle
  - 合計: 年数百 tx、 Cardano 月次 800K tx baseline ≪

  Per-ADA capital efficiency は本提案で構造的に negative。

よって本提案はこの criterion を満たさない。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 43. MLabs - Cardano Tx Library: JavaScript/TypeScript Interface, Koios Backend, Hard Fork Maintenance

- Proposal ID: 69fc8e0989371182537b30a3
- Requested: 1,337,763 ADA
- Vote (intention): Abstain
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8e0989371182537b30a3
- Category: Infrastructure / SDK
- Applicable criteria: C5, C8
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

1. Evidence of 'demand exists' is weak. The proposer cites 'we already have production users', but those users are people already on a different stack (PureScript version) — not a queue of JS/TS devs waiting for this new tool. It is unclear who would newly adopt it.
2. The transaction-building library space is already crowded. Rather than 'adding one more similar tool to an already-crowded category', the ecosystem needs to consolidate around one strong tool.

### Voting reason (JA, as of 2026-05-28)

1. 「需要がある」という証拠が弱い: 「すでに使ってくれている本番ユーザーがいる」と提案者は言うが、 よく見るとそれは既に別の仕組み (PureScript 版) を使っている人たちであって、 「この新しい道具を待ち望んでいる JS/TS の開発者の行列」ではない。 つまり、 作っても誰が新しく使うのか不明。
2. すでに似たトランザクション構築ライブラリが市場に溢れている。 同じようなツールが既にいくつもある。 「乱立している分野に、 また一つ似たものを増やす」のではなく、 強力な 1 つのツールに集中する必要がある。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. I would like to dig a little deeper into the evidence of demand.
1. Names of teams that will adopt it. I understand that "there are many JS/TS developers." The question is whether that demand will go through CTL. Can you name, or obtain endorsement comments from, teams that plan to use or migrate to this binding rather than a competing tool?
2. Advantage over competitors. The "robust typed core" you cited is a strength of the PureScript core itself, which is maintained separately under WP3/OSC. What I want to ask is how the JS/TS binding layer is superior to the likes of Lucid Evolution / Mesh. Can you compare them by name?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。需要の証拠について少し掘り下げたいと思います。
1.  採用するチーム名 「JS/TS開発者は多い」は理解しました。問題はその需要がCTL経由に向かうかです。競合ツールではなく本バインディングを使う・移行する予定のチームを、挙げるか、彼らから推薦のコメントをもらうことはできますか?
2.  競合に対する優位性 挙げられた「堅牢な型付きコア」はPureScriptコア自体の強みで、それはWP3/OSCで別途維持されます。問いたいのは、JS/TSバインディング層が Lucid Evolution / Mesh などに対してどう優れるか。名前をあげて比較できますか?

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on MLabs - Cardano Tx Library: JS/TS Interface, Koios Backend, Hard Fork Maintenance (**3.17M ADA / NCL 0.91%**).

**Main reasons**

**1. CTL has named production users, but its reach is PureScript-only today**
- Per proposal: **Indigo, Clarity, Genius Yield, Cardano Racers, Noble Steed Games, SingularityNet** (some maintaining their own forks).
- CTL is reachable only from PureScript today, which keeps it out of the JavaScript / TypeScript majority.
- Production use is real; the reach problem is real.

**2. The Cardano TS SDK space is already crowded — CTL's niche needs to be argued**

| SDK | Architecture | Niche | Funding |
|---|---|---|---|
| Mesh | TS | broad, beginner adoption | independent |
| Lucid Evolution | Effect-TS | functional pipeline | Budget #69 (1.44M ADA) |
| HLabs Pebble | TS | dApp framework | Budget #69 separate |
| **MLabs CTL (this)** | PureScript → TS | Plutarch backend integration | this proposal |
| Legacy Lucid | TS | deprecated | sunset |

CTL's plausible niche is dApp backends that use Plutarch and need tight on-chain ↔ off-chain integration. The proposal lists work packages but does not make this niche argument explicitly against Mesh or Lucid Evolution.

**3. Three work packages bundle new features with pure maintenance**

| WP | Scope | Type |
|---|---|---|
| 1. JS/TS Interface | Open CTL to JS/TS developers (remove the PureScript-only barrier) | new feature |
| 2. Koios Backend | Add Koios as a first-class query layer | new feature |
| 3. Quarterly Maintenance + Dijkstra Hard Fork Prep | Dependency bumps + Dijkstra readiness | maintenance |

3.17M ADA total is large, and without a per-WP budget split, a DRep cannot verify scope vs cost. Mesh and Lucid Evolution already serve JS/TS — WP1 specifically needs an argument for why it beats Lucid Evolution adoption for Plutarch-using dApps.

**4. MLabs delivery context**
- Per /tx-roi: MLabs cumulative = 40 Catalyst + 393K TW = 12.26M ADA.
- Per Intersect TW: Core Tool Maintenance = 6 of 8 milestones delivered + 2 pending. Maintenance delivery is solid.
- WP3 (Dijkstra hard-fork readiness) is maintenance-class and could be evaluated on the existing track.

**Recommend resubmission** with: (a) explicit niche differentiation versus Mesh and Lucid Evolution (the Plutarch-integration argument needs to be written out), (b) per-WP budget breakdown, (c) named CTL-using dApps committing to migrate to the JS/TS port once available.

*Vote position: NO-resubmit. MLabs delivery cadence and the Plutarch niche make a YES flip realistic with the items above.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — MLabs - Cardano Tx Library(JS/TS、Koios、ハードフォーク保守、**3.17M ADA / NCL 0.91%**)に NO(再提出推奨)。

**主な理由**

**1. CTL は本番採用者がいるが、現状 PureScript からしか触れない**
- 提案書より:**Indigo、Clarity、Genius Yield、Cardano Racers、Noble Steed Games、SingularityNet** など(自前フォークを抱える例もあり)。
- 現在は PureScript からのみ利用可能。JavaScript / TypeScript の主要層から外れている。
- 本番採用は事実。リーチの問題も事実。

**2. Cardano の TS SDK は既に混んでいる。CTL の立ち位置の説明が必要**

| SDK | アーキテクチャ | 立ち位置 | 資金 |
|---|---|---|---|
| Mesh | TS | 初心者向け、幅広い採用 | 独立 |
| Lucid Evolution | Effect-TS | 関数型パイプライン | Budget #69(1.44M ADA) |
| HLabs Pebble | TS | dApp フレームワーク | Budget #69 別件 |
| **MLabs CTL(本提案)** | PureScript → TS | Plutarch バックエンド統合 | 本提案 |
| Legacy Lucid | TS | 廃止 | 終了 |

CTL のあり得る立ち位置は、Plutarch を使う dApp バックエンドで、オンチェーン⇄オフチェーンを密結合したいケース。提案書は作業項目を並べるが、Mesh や Lucid Evolution に対するこの立ち位置の説明が書かれていない。

**3. 新機能と純粋な保守を1つにまとめている**

| WP | 範囲 | 種類 |
|---|---|---|
| 1. JS/TS インタフェース | JS/TS 開発者から触れるようにする(PureScript 縛りを解消) | 新機能 |
| 2. Koios バックエンド | Koios を一級のクエリ層として追加 | 新機能 |
| 3. 四半期保守 + Dijkstra HF 対応 | 依存更新 + Dijkstra 対応 | 保守 |

総額 3.17M ADA は大きい。WP ごとの予算分けがないと、DRep は範囲と費用が見合うか検証できない。Mesh と Lucid Evolution が既に JS/TS を提供している。WP1 については、「Plutarch を使う dApp にとって、Lucid Evolution 採用ではなくこの WP1 を選ぶべき理由」を、明示的に書き起こす必要がある。

**4. MLabs の納品実績**
- /tx-roi:MLabs 累積 = Catalyst 40件 + TW 393K = 12.26M ADA。
- Intersect TW:コアツール保守 = 8件中6件完了 + 2件保留。保守の達成は堅い。
- WP3(Dijkstra HF 対応)は保守クラス。既存の保守トラックで評価可能。

**再提出推奨**:(a) Mesh / Lucid Evolution に対する CTL の立ち位置を明示(Plutarch 連携の論点を書き起こす)、(b) WP ごとの予算分割、(c) JS/TS 版が出たら移行する CTL 利用 dApp の約束。

*MLabs の納品ペースと Plutarch ニッチの妥当性を踏まえれば、上記が揃えば YES への切り替えは現実的。*

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8e0989371182537b30a3#comment-6a1e04ac0dcaa7f9767cd59b
- Summary (EN): Proposer (MLabs) argues CTL is one of the most protocol-hardened transaction-building libraries (production users through Conway/Plomin, Van Rossum compatibility), that its PureScript typed core is a reliability feature for catching protocol mismatches and hard-fork readiness (relevant for Dijkstra/Plutus v4), and that WP1 exposes this core via JS/TS bindings.
- Summary (JA): 提案者(MLabs)は、CTLが最もプロトコル堅牢化された取引構築ライブラリの一つだ(Conway/Plominを通じた本番利用者、Van Rossum互換性)と主張し、そのPureScriptの型付きコアはプロトコルの不一致を捕捉しハードフォーク対応(Dijkstra/Plutus v4に関連)のための信頼性機能であり、WP1はこのコアをJS/TSバインディングで公開すると述べている。

Full text:

Thanks, Yuta.

Two points are worth making directly before responding to your specific points.

CTL is one of the most protocol-hardened transaction-building libraries in the Cardano ecosystem. It has shipped support across multiple protocol transitions since Alonzo, carried production users such as Indigo, Clarity, SingularityNet, and others through Conway and Plomin, and is currently delivering Van Rossum compatibility. When the question is which tooling the ecosystem should consolidate around, maintenance depth and hard fork discipline should be heavily weighted. On those axes, CTL is one of the strongest candidates in the ecosystem.

CTL's PureScript core is a feature, not a legacy quirk. Cardano transaction construction is complex, typed, and highly sensitive to ledger changes. A strongly typed functional core pushes more protocol mismatch detection into the library development cycle, where maintainers can catch problems through compilation, tests, and release validation before downstream dApps encounter them. In plain terms, when Cardano changes, CTL is designed so that many affected parts of the transaction-building layer must be updated deliberately before a release can be considered ready. That is a real reliability benefit for teams building on the network.

A concrete example is hard fork readiness. When a transition introduces new ledger types, new Plutus versions, new script behavior, or changes in transaction construction rules, each downstream dApp should not have to rediscover those changes independently. A maintained typed transaction-building layer absorbs much of that complexity once, then exposes a safer interface to application teams. This is especially relevant for Dijkstra, where Plutus v4 and ledger changes are expected to affect the tooling surface.

This is why WP1 does not compromise CTL's foundation. It exposes the same battle-tested functional core to a wider developer population through idiomatic JavaScript and TypeScript bindings.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8e0989371182537b30a3#comment-6a1e04c7ceb7fef00be0e509
- Summary (EN): Proposer (MLabs) argues the broad JS/TS transaction-building ecosystem is itself the demand signal, that WP1 lets those teams use CTL without adopting PureScript (supporting the consolidation goal), that this extends an existing production library rather than crowding the category, and that WP3 protects current CTL users through the Dijkstra transition.
- Summary (JA): 提案者(MLabs)は、広範なJS/TS取引構築エコシステム自体が需要シグナルだと主張し、WP1はそれらのチームがPureScriptを採用せずにCTLを使えるようにし(統合目標を支援)、これはカテゴリを混雑させるのではなく既存の本番ライブラリを拡張するものであり、WP3はDijkstra移行を通じて現在のCTL利用者を保護すると述べている。

Full text:

On demand, we agree that existing CTL production use is not the same as proving that a queue of JavaScript and TypeScript developers is waiting for the interface. But the existence of the broader JS and TS transaction-building ecosystem is itself the demand signal. The question is not whether Cardano developers want to build in JavaScript and TypeScript. They clearly do. The question is which transaction-building core should serve them.

Today those developers are often served by tools with less protocol history than CTL, or they must build workarounds around CTL by learning PureScript, running a separate PureScript service, or rebuilding transaction logic against lower-level libraries. WP1 gives those teams access to one of the most protocol-hardened libraries in the ecosystem without forcing PureScript adoption.

That directly supports the consolidation goal you raised.

On crowding, the framing matters. This proposal is not adding another unrelated transaction builder to an already crowded category. It is extending an existing production-used library into the language ecosystem where many dApp teams already work. Instead of separate wrappers, separate service boundaries, and separate lower-level implementations, teams can converge on a mature shared core with a JS and TS interface.

That is consolidation, not fragmentation. The ecosystem gets fewer effective transaction-building paths doing more work, not more tools doing the same work.

Finally, WP3 stands independently from the JavaScript and TypeScript question. It protects teams already relying on CTL today. Dijkstra is expected to land during or near the upcoming funding period, with Plutus v4, ledger changes, and consensus changes. This is exactly the kind of protocol boundary where undermaintained libraries can break and downstream dApps discover the issue too late.

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc8e0989371182537b30a3#comment-6a1e04da7d5f66c5487662ab
- Summary (EN): Proposer (MLabs) argues that making CTL Dijkstra-testnet-ready lets teams prepare dApps in parallel rather than scramble after the hard fork, summarizing that the proposal advances consolidation by protecting an existing production tool and making its functional core accessible to JS/TS developers.
- Summary (JA): 提案者(MLabs)は、CTLをDijkstraテストネット対応にすることでチームがハードフォーク後に慌てるのではなく並行してdAppを準備できると主張し、本提案は既存の本番ツールを保護しその関数型コアをJS/TS開発者に利用可能にすることで統合を前進させると総括している。

Full text:

As CTL becomes Dijkstra-testnet-ready, teams using CTL can prepare their own dApps in parallel rather than scrambling after the hard fork ships. That is the difference between a smoother ecosystem-wide transition and a scramble at the protocol boundary.

So our core response is that this proposal advances the kind of consolidation you are asking for. It protects an existing production-used tool, preserves a reliable functional-language-first transaction-building core, and makes that core accessible to the larger JavaScript and TypeScript developer base.

Here is a video explanation from our CTO:

https://drive.google.com/file/d/1qflKXVAyDeItoj-wzPV8eKQ5pINW0SRT/view?usp=sharing

---

## 44. Integration of Cardano into the Houdiniswap Aggregator

- Proposal ID: 69f08631d699758cde5d4a68
- Requested: 1,311,190 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f08631d699758cde5d4a68
- Category: dApp - DeFi
- Applicable criteria: C3, C4
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. While there are non-binding comments showing some give, they are basically non-binding. Also, the $1M target figure may be relatively small even from the standpoint of treasury returns relative to treasury expenditure.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。非拘束的な歩み寄りのコメントはありますものの、基本的には非拘束的なものです。また、$1Mという目標数値はトレジャリー支出から見たトレジャリー還元の観点から見ても、比較的小さい可能性があります。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-DeFi / aggregator integration]. Non-applicable: C1 (aggregator integration could plausibly bring Tx, but is downstream of C4 issue), C2, C5, C6, C7, C8, C9, C10, C11.

**Applicable: C3, C4 (decisive)**. Applying:

• **C4 — Treasury return explicitly zero (decisive)**: Proposal text quote: 'Will any portion of the requested funds be returned to the Cardano Treasury? No.' No repayment, no commercial revenue share, no fee return. Pure grant structure.

  Houdiniswap is profitable commercial entity with public revenue indicators:
  - $9.2M+ cumulative fees (per Token Terminal as of 2025)
  - Top 50 by revenue on Token Terminal ranking
  - Already organically integrated with 35+ chains (per Houdiniswap public docs)

  After Cardano Treasury funds integration cost ($315K), Houdiniswap captures 100% of Cardano-routed swap fees with no revenue share to the Treasury. A commercial entity with $9.2M+ revenue base has structural commercial incentive to integrate any chain it deems profitable — Treasury subsidy is unnecessary if integration is commercially worthwhile, and harmful (zero return) if it isn't.

• **C3 — KPI vagueness**: KPI commitments limited to '≥10 completed Cardano-involving swaps post-launch' and 'measurable volume within 90 days'. No concrete volume target specified. The proposal does not specify what % of Houdiniswap's existing $2.8B cumulative volume would be routed through Cardano.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-DeFi / aggregator integration]。 非適用: C1 (aggregator integration は plausibly Tx 持ち込みうるが C4 issue の downstream), C2, C5, C6, C7, C8, C9, C10, C11。

**適用: C3, C4 (decisive)**。 適用:

・**C4 — Treasury return 明示的に zero (decisive)**: 提案書直接引用: 'Will any portion of the requested funds be returned to the Cardano Treasury? No.' Repayment / commercial revenue share / fee return なし。 Pure grant 構造。

  Houdiniswap は public revenue indicator を持つ profitable commercial entity:
  - $9.2M+ 累積 fees (Token Terminal 2025 時点)
  - Token Terminal revenue ranking で Top 50
  - 既に 35+ chains に organically integrated (Houdiniswap public docs より)

  Cardano Treasury が integration cost ($315K) を fund した後、 Houdiniswap が Cardano-routed swap fees の 100% を capture、 Treasury への revenue share なし。 $9.2M+ revenue base を持つ commercial entity は profitable と判断する任意の chain への integration に structural commercial incentive あり — integration が commercially worthwhile なら Treasury subsidy 不要、 worthwhile でないなら harmful (zero return)。

・**C3 — KPI vagueness**: KPI commitment は '≥10 completed Cardano-involving swaps post-launch' と 'measurable volume within 90 days' に限定。 Concrete volume target specify なし。 提案書は Houdiniswap 既存 $2.8B 累積 volume の何 % が Cardano routing か specify せず。

よって本提案はこれらを満たさない。

### Proposer feedback (2)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f08631d699758cde5d4a68#comment-6a044a08a7468bb49bf84649
- Summary (EN): Asks for more concrete detail on YUTA's concerns and proposes a call to explore common ground, citing Houdini's cross-chain flexibility. Wants to find an effective working approach.
- Summary (JA): 懸念点について具体的詳細を求め、Houdiniのクロスチェーン柔軟性を活かして共通理解を探るためのコール (通話) を提案。双方にとって便利な作業方法を模索したいとのこと。

Full text:

> Hi — thanks for submitting this proposal.
> >
> My current vote: NO (applicable criteria: C3, C4).
> >
> Detailed per-criterion rationale + voting policy: https://adatool.net/b69-share
> >
> Disclosure: I'm using AI to keep pace with the review load this cycle, but I've read the proposal myself and the rationale was iteratively refined over many revisions. With 50+ more proposals plus GA still to review, replying here with counter-evidence is most useful — individual DMs/meetings may be hard to accommodate.
> >
> Thanks for your patience.

Hi Yuta,

Thank you for your feedback. Could you please share more details regarding your concerns? I understand that you are using AI to speed up the process; however, we would like to explore the most effective way to work with Cardano that is convenient for both parties.

It would be great to schedule a call to discuss this further and identify common ground. Houdini is quite flexible and multifunctional from a cross-chain perspective, and we see several ways to align our approach.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f08631d699758cde5d4a68#comment-6a1db0f0f4bf5dd313f5cf7f
- Summary (EN): Proposer offers treasury-protection measures (returning ADA price-appreciation difference, returning funds for unfinalized routes, milestone-based 1/3-2/3-3/3 payments, possible revenue sharing) and KPIs (expected $1M+ volume within 90 days post-launch, planned marketing partnerships with major Cardano projects).
- Summary (JA): 提案者はトレジャリー保護策(ADA値上がり分の差額返還、未完了ルートの資金返還、マイルストーン型の1/3・2/3・3/3払い、収益分配の可能性)とKPI(ローンチ後90日以内に$1M超の取引量見込み、主要Cardanoプロジェクトとのマーケティング提携計画)を提示している。

Full text:

> Hello, thank you as always 🙏
> >
> Regarding feedback on my vote on the Intersect Budget process proposal:
> >
> 1) I have listed my reasons for voting on the following page. Please review it. 🙏
> >
> 2) I have included the feedback received in the comments sections of X and the Hyda platform on the same page. Please check if this is comprehensive. (If any feedback is missing, please let me know in the Hyda platform comments.) 🙏
> >
> 3) To prevent any omissions in the aggregation of feedback, I would appreciate it if we could communicate via the Hyda platform if possible. 🙏
> >
> 4) I will re-count the feedback received here by June 2nd, 0:00 UTC, and will respond later or change my vote if necessary. If you have any comments, please leave them on the Hyda platform. 🙏
> >
> https://adatool.net/b69-share2

Hey, thanks for sharing your feedback again! I've added a few clarifications below:

**1. Treasury Protection:**

If the ADA price increases, we will return the difference in value to the Treasury.

If any route cannot be finalized, the related funding can be returned to the treasury.

To reduce risk for both sides, the grant can also be split into milestone-based payments: 1/3, 2/3 and 3/3 without requiring full upfront funding.

**Commercial Terms**

We can explore a revenue-sharing model, where Houdiniswap shares a portion of the fees generated after the integration.

**2. KPI:**

**Expected volume:** $1M+ within the first 90 days post-launch (based on our previous results)

**Growth potential:** We plan to partner with leading Cardano projects (WMTX, NIGHT, USDM, USDA, USDCx, IAG, SNEK) and other ecosystem projects to drive coordinated marketing efforts, which we expect will further increase transaction volume and user growth.

---

## 45. Hardware Wallet Maintenance 2026

- Proposal ID: 69e8b481b637aef81b4fadd7
- Requested: 1,310,960 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e8b481b637aef81b4fadd7
- Category: Wallet / hardware
- Applicable criteria: C5, C8
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Hardware wallet maintenance directly impacts end-user security.

### Voting reason (JA, as of 2026-05-28)

ハードウェアウォレットはエンドユーザーのセキュリティに直接影響します。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: [Wallet / hardware vendor maintenance — VacuumLabs covering Trezor + Keystone + Ledger compatibility per proposal text]. Non-applicable: C1, C2 (VacuumLabs is the established maintainer with multi-year track record), C3 (vendor-maintenance milestone metric), C4, C6, C7, C9, C10, C11.

**Applicable: C5 (scope overlap with parallel Ledger SAS proposals — decisive), C8**. Applying:

• **C5 — Direct scope overlap with parallel Ledger SAS proposals (decisive)**: Per VacuumLabs's own proposal text — '12 months of funding for production maintenance of Cardano hardware-wallet support: **Ledger AND Trezor compatibility updates**, maintenance of supporting interoperability libraries and cardano-hw-cli, developer support for ecosystem integrators'. This **explicitly includes Ledger compatibility work** alongside Trezor/Keystone.

  In parallel, Budget #69 contains **3 Ledger-side proposals from Ledger Technologies SAS itself**:
  - 'Cardano app on Ledger maintained by Ledger Technologies SAS' (₳2.06M) — Ledger SAS's own yearly maintenance fee for the Cardano app on Ledger devices
  - 'Full Integration of CIP-113 with Clear Signing across Ledger Products' (₳92.7K) — Ledger SAS implementing CIP-113 across Ledger Signer + Live + Enterprise
  - 'Clear signing of Cardano Top 5 dApps & Ledger Button integration' (₳3.46M) — Ledger SAS doing top-5 dApp Ledger integration

  **The overlap is direct**: both VacuumLabs (this proposal) and Ledger SAS (the 3 parallel proposals = ₳5.6M combined) are funding Cardano-app-on-Ledger maintenance work. Historically VacuumLabs maintained the Cardano app on Ledger; the Ledger SAS proposals signal a transition to Ledger SAS taking direct first-party responsibility. If that transition is happening, VacuumLabs's scope should be reduced to **Trezor + Keystone + cardano-hw-cli library** (the uncontested role), NOT include 'Ledger compatibility'. Currently the proposal claims both, which structurally duplicates Ledger SAS's parallel funding requests.

• **C8 — VacuumLabs delivery evidence (still valid for the uncontested scope)**: Per Intersect TW data, current-cycle Hardware Wallet Maintenance shows 2 milestones already delivered (120K ADA disbursed). VacuumLabs is the established Trezor+Keystone Cardano maintainer; the team-continuity argument holds for that scope.

**Recommend resubmission** with: (a) explicit scope-narrowing to remove Ledger work (or articulate the handoff arrangement with Ledger SAS), (b) clear delineation between VacuumLabs vs Ledger SAS work for the 2026-2027 cycle, (c) corresponding budget reduction reflecting the narrower scope. **Without this clarification, approving both VacuumLabs and Ledger SAS proposals double-funds Cardano-app-on-Ledger maintenance**.

Vote shifted YES → NO-recommend-resubmit on scope-overlap grounds.

### Prior detailed analysis (JA)

**分類**: [Wallet / hardware vendor maintenance — 提案 text より VacuumLabs が Trezor + Keystone + Ledger compatibility を cover]。 非適用: C1, C2 (VacuumLabs は multi-year track record を持つ established maintainer), C3 (vendor-maintenance milestone metric), C4, C6, C7, C9, C10, C11。

**適用: C5 (Ledger SAS 並行提案との scope overlap — decisive), C8**。 適用:

・**C5 — Ledger SAS 並行提案との直接 scope overlap (decisive)**: VacuumLabs 自身の提案 text より — '12 months of funding for production maintenance of Cardano hardware-wallet support: **Ledger AND Trezor compatibility updates**, maintenance of supporting interoperability libraries and cardano-hw-cli, developer support for ecosystem integrators'。 これは Trezor/Keystone と並んで **Ledger compatibility work を明示的に含む**。

  並行して、 Budget #69 には **Ledger Technologies SAS 自身** からの **3 つの Ledger-side 提案**が存在:
  - 'Cardano app on Ledger maintained by Ledger Technologies SAS' (₳2.06M) — Ledger SAS 自身の Cardano app on Ledger devices に対する年次 maintenance fee
  - 'Full Integration of CIP-113 with Clear Signing across Ledger Products' (₳92.7K) — Ledger SAS が Ledger Signer + Live + Enterprise 横断で CIP-113 を実装
  - 'Clear signing of Cardano Top 5 dApps & Ledger Button integration' (₳3.46M) — Ledger SAS が top-5 dApp の Ledger 統合を実施

  **Overlap は直接**: 本提案 (VacuumLabs) と 並行 3 提案 (Ledger SAS、 合計 ₳5.6M) の両方が Cardano-app-on-Ledger maintenance work を fund しようとしている。 歴史的に VacuumLabs が Ledger 上の Cardano app を維持していたが、 Ledger SAS 提案群は Ledger SAS が直接 first-party 責任を取る transition を signal。 その transition が起きているなら、 VacuumLabs の scope は **Trezor + Keystone + cardano-hw-cli library** (uncontested な役割) に縮小すべきで、 'Ledger compatibility' を含むべきでない。 現在は両方を claim しており、 Ledger SAS の並行 funding request と structurally duplicate。

・**C8 — VacuumLabs delivery evidence (uncontested scope で依然 valid)**: Intersect TW data より current-cycle Hardware Wallet Maintenance は 2 milestones delivered (120K ADA disbursed)。 VacuumLabs は established な Trezor+Keystone Cardano maintainer; team-continuity argument は該 scope で hold。

**再提出推奨**: (a) Ledger work を取り除く explicit scope-narrowing (or Ledger SAS との handoff arrangement の articulate)、 (b) 2026-2027 cycle での VacuumLabs vs Ledger SAS work の clear delineation、 (c) 縮小 scope を反映した budget 削減。 **この clarification なしに VacuumLabs と Ledger SAS 提案の両方を承認すると、 Cardano-app-on-Ledger maintenance を double-fund することになる**。

Scope-overlap grounds で Vote を YES → NO-recommend-resubmit に shift。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 46. zkFold Open Source Cardano Infrastructure 2026

- Proposal ID: 69fb54818a0de51b89857e11
- Requested: 1,256,600 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb54818a0de51b89857e11
- Category: Research / ZK / FV
- Applicable criteria: C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: [Research / ZK]. Non-applicable: C1 (research not direct Tx generator), C3 (research deliverables are output by design), C4 (public-good ZK infrastructure), C6, C7, C9, C10, C11.

**Applicable: C8 (past funding outcome)**. Applying:

• **C8 — Past funded projects' adoption empirically weak**: Per /tx-roi backend (https://adatool.net/tx-roi), **zkFold has received 9 Catalyst proposals + 1.16M ADA TW = 3.52M ADA cumulatively across multiple cycles**. Reviewing each:

  - **ENCOINS** (zkFold's flagship privacy product, launched November 2023): per LiveCoinWatch (https://www.livecoinwatch.com), market price has declined -99.7% from ATH; 24h volume has been $20-$2,663; last traded date 2025-03-18. ADAtool db-sync archive has no `encoins`/`encs` label in tx_label (production tx 0 verifiable). The ENCS governance token policy `9a9693a9...` has only 1 mint event (TGE).

  - **ZKFold Symbolic, UPLC Converter, ZK cross-border payment, Smart Contract Wallet**: claimed 'completed' but no verifiable Cardano builder adoption metric (downloads, integration count, GitHub usage by other Cardano projects) presented in proposal or accessible publicly.

  - **zkFold ZK Rollup TW** (active Treasury Withdrawal, separate funding stream): per cardanotreasury.fi as of 2026-05-10, **5/5 milestones delivered (681K ADA disbursed)**. However, milestone delivery is a process completion metric, not production adoption metric; no production tx consuming the ZK Rollup deliverable on Cardano mainnet is verifiable.

  - **Public questions raised** about deliverable-vs-scope alignment for prior funded items (e.g., Cardano integration of zkPass oracle feeds — actual production usage on Cardano cannot be verified at this time).

  - The proposal **explicitly refuses** Tx/MAU/TVL/revenue ecosystem commitments (proposal text quote: "zkFold does not commit to specific ecosystem-wide transaction, MAU, TVL, or revenue targets"). The 'controlled delivery metrics' offered (3 mainnet launches, 99% uptime) are output metrics. **Mainnet launch ≠ adoption.**

Given 3.52M ADA prior funding produced no empirically-verifiable Cardano ecosystem outcome at scale, additional 2026 funding for zkFold without an outcome commitment fails C8.

Therefore this proposal does not satisfy this criterion.

### Prior detailed analysis (JA)

**分類**: [Research / ZK]。 非適用: C1 (research は直接 Tx generator ではない), C3 (research deliverable は output by design), C4 (public-good ZK infra), C6, C7, C9, C10, C11。

**適用: C8 (過去資金 outcome)**。 適用:

・**C8 — 過去 funded projects の adoption empirically 弱**: /tx-roi backend (https://adatool.net/tx-roi) より、 **zkFold は累積 9 Catalyst proposals + 1.16M ADA TW = 3.52M ADA を multiple cycle 横断で受領**。 各 review:

  - **ENCOINS** (zkFold の flagship privacy 製品、 2023 年 11 月 launch): LiveCoinWatch (https://www.livecoinwatch.com) より market price は ATH から -99.7% 減; 24h volume は $20-$2,663; last traded 2025-03-18。 ADAtool db-sync archive に `encoins`/`encs` label なし (production tx 0 verifiable)。 ENCS governance token policy `9a9693a9...` は 1 mint event (TGE) のみ。

  - **ZKFold Symbolic, UPLC Converter, ZK cross-border payment, Smart Contract Wallet**: 'completed' 主張だが verifiable Cardano builder adoption metric (downloads, integration count, 他 Cardano projects による GitHub usage) は提案書または公開情報で提示なし。

  - **zkFold ZK Rollup TW** (active Treasury Withdrawal、 別 funding stream): cardanotreasury.fi 2026-05-10 時点で **5/5 milestones delivered (681K ADA disbursed)**。 但し milestone delivery は process completion metric で production adoption metric ではない; ZK Rollup deliverable を Cardano mainnet で consume する production tx は verifiable でない。

  - **過去 funded item の deliverable-vs-scope alignment** に関する public question あり (例: Cardano integration of zkPass oracle feeds — Cardano 上での actual production 使用は現時点 verify 不能)。 **C8 (delivery dispute) 追加 fail (2026-05-10 X)**: 'zkFold says you pocketed their 217k ADA milestone funds after they delivered. Midgard builders report the same on completed work. Multiple teams have called this out publicly.' との public allegation (@Avaxgator に representative tweet)。 Allegation の truth 値は別として、 unresolved-and-non-trivial public delivery dispute は Treasury commitment 前に scrutiny を warrant。

  - 提案書は **明示的に** Tx/MAU/TVL/revenue ecosystem commitment を拒否 (提案書引用: "zkFold does not commit to specific ecosystem-wide transaction, MAU, TVL, or revenue targets")。 提示される 'controlled delivery metrics' (3 mainnet launches, 99% uptime) は output metric。 **Mainnet launch ≠ adoption。**

3.52M ADA の過去資金が empirically-verifiable Cardano ecosystem outcome を scale で生まなかったため、 outcome commitment なしの 2026 追加資金は C8 不合格。

よって本提案はこの criterion を満たさない。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 47. 2027 Objectives, Research validation & Market Pilots - IntersectCPC

- Proposal ID: 69e7a2e8afb99100720f2795
- Requested: 1,240,000 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69e7a2e8afb99100720f2795
- Category: Governance coordination
- Applicable criteria: C3, C5, C8
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

For the W3 pilot support, success depends on who is on the Product Committee at that time. Given the current attack-prone Intersect election mechanism, I cannot trust future Product Committee composition. I would like W3 reconsidered later — after we see the W1-2 work outputs and the actual Product Committee composition at that time. Please resubmit on-chain governance action limited to W1-2 first; resubmit W3 later.

### Voting reason (JA, as of 2026-05-28)

W3 のパイロット支援について、 この成功はその時点のプロダクト委員会の構成メンバー次第ですが、 現在の攻撃を受けやすい Intersect 選挙の仕組みを考慮すると、 将来のプロダクト委員会メンバーを信頼することが困難です。 よって W3 は、 その時点のプロダクト委員会の構成と W1-2 までの作業結果をみて改めて考えたいため、 W1-2 に絞ったオンチェーンガバナンスアクションで再提出、 W3 を後日再提出いただきたいです。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on 2027 Objectives, Research validation & Market Pilots - IntersectCPC (**1.24M ADA / NCL 0.35%**).

**Main reasons**

**1. The pipeline framing is appropriate, but specific 2027 deliverables are not enumerated**
- Per proposal: "Vision & Strategy → Product Research → Market Pilots" pipeline.
- The pipeline is structurally appropriate for product strategy work.
- But specific 2027 deliverables are not enumerated:
  - Vision & Strategy: "workshops + community participation" — process metric.
  - Market Pilots: "high-potential pilots with strong product-market fit potential" — threshold undefined.
  - Strategy validation: "business engagement and market intelligence" — depth undefined.

**2. Past CPC cycle outcomes are not enumerated**
- Per proposal: CPC is operating an existing pipeline (Strategy → Research → Pilots).
- 2026 cycle outcome data is not presented: which pilots were operationalised? what were the conversion rates? what learnings inform the 2027 scope?
- Without 2026 outcome attribution, the 2027 ask is forward-looking only.

**3. Overlap with parallel Intersect / GMC / Marketing-Demand-Engine proposals**

| Function | Overlapping proposal | Funding ask |
|---|---|---|
| Vision 2030 strategy translation | Intersect MBO budget | 25.4M ADA |
| Market pilots | Cardano BD Network (regional hubs) | 1.52M ADA |
| Market pilots | Cardano Enterprise Activation Sandbox | 929K ADA |
| Marketing-driven pilots | Marketing Powered Demand Engine | 20.87M ADA |
| **Strategy / research / pilot bundle (this)** | — | **1.24M ADA** |

The "Strategy + Research + Pilots" framing overlaps with at least 3 other Budget #69 entries. The proposal does not explicitly delineate against them. The same DReps will be asked to fund overlapping pilot-pipeline work multiple times this cycle.

**4. KPIs are committee-side, not Cardano-outcome-side**
- "Define clear, measurable 2027 strategic goals through structured workshops" — process metric.
- "Convert research insights into a small number of high-potential pilots" — count undefined.
- No specific Cardano transaction / TVL / USD-revenue contribution target tied to milestones.
- Compare with Intersect TSC (1.19M ADA, similar size, but with 3 named specialist groups + a concrete review programme).

**5. Contingent on MBO approval — same pattern as TSC and the Budget Committee**
- Per proposal: execution is contingent on Intersect MBO budget approval.
- Clean failure mode (good).
- But the scope itself overlaps with MBO operations — contingency doesn't resolve why CPC is separate from MBO core scope.

**Recommend resubmission** with: (a) 2026 CPC cycle outcomes enumerated (pilots launched + conversion rates + learnings), (b) explicit scope delineation versus Cardano BD Network + Enterprise Sandbox + Marketing Demand Engine, (c) per-pilot Cardano-outcome KPI target, (d) tighter scope: "workshops + research + pilot funding" is 3 distinct functions — consider splitting and matching each to the appropriate Intersect sub-body.

*CPC scope is plausibly real but currently bundled with multiple parallel BD / pilot proposals without delineation. NO-resubmit to force scope clarity.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — 2027 Objectives, Research validation & Market Pilots - IntersectCPC(**1.24M ADA / NCL 0.35%**)に NO(再提出推奨)。

**主な理由**

**1. パイプラインの枠組みは妥当だが、2027 の具体的な成果物が列挙されていない**
- 提案書より:「Vision & Strategy → Product Research → Market Pilots」のパイプライン。
- プロダクト戦略業務として構造は妥当。
- ただし 2027 の具体的成果物が列挙されていない:
  - Vision & Strategy:「ワークショップ + コミュニティ参加」— プロセス指標。
  - Market Pilots:「高ポテンシャル + 高 PMF のパイロット」— 閾値未定義。
  - 戦略検証:「ビジネス対話と市場インテリジェンス」— 深さ未定義。

**2. 過去 CPC サイクルの結果が列挙されていない**
- 提案書:CPC は既存パイプライン(Strategy → Research → Pilots)を運営。
- 2026 サイクルの結果データなし:どのパイロットが実運用化された?転換率は?2027 範囲にどう反映する?
- 2026 結果の帰属がないと、2027 要求は前向きの主張のみになる。

**3. 並行する Intersect / GMC / Marketing Demand Engine 提案と重複**

| 機能 | 重複する提案 | 要求額 |
|---|---|---|
| Vision 2030 戦略の落とし込み | Intersect MBO 予算 | 25.4M ADA |
| 市場パイロット | Cardano BD Network(地域ハブ) | 1.52M ADA |
| 市場パイロット | Cardano Enterprise Activation Sandbox | 929K ADA |
| マーケ駆動パイロット | Marketing Powered Demand Engine | 20.87M ADA |
| **戦略 / 研究 / パイロット束(本提案)** | — | **1.24M ADA** |

「戦略 + 研究 + パイロット」の枠組みは、Budget #69 の他項目少なくとも3件と重複する。提案書はそれらとの切り分けを明示していない。同じ DRep が、本サイクル中に重複するパイロット系業務に何度も資金提供を求められる構造。

**4. KPI が委員会側で、Cardano の成果側ではない**
- 「構造化されたワークショップを通じて 2027 の明確で測定可能な戦略目標を定める」— プロセス指標。
- 「研究知見を少数の高ポテンシャルパイロットに転換する」— 件数未定義。
- マイルストーンに紐付く Cardano の取引 / TVL / USD 収益寄与目標がない。
- Intersect TSC(1.19M ADA、同規模だが3つの名前付き専門グループ + 具体的なレビュープログラム)と比較。

**5. MBO 承認連動 — TSC や Budget Committee と同パターン**
- 提案書:実行は Intersect MBO 予算承認に連動。
- 失敗モードは明快(良い)。
- ただし範囲自体が MBO 業務と重なる。連動条項は「なぜ CPC が MBO 中核範囲と別なのか」を解消しない。

**再提出推奨**:(a) 2026 CPC サイクルの結果列挙(開始したパイロット + 転換率 + 学び)、(b) Cardano BD Network + Enterprise Sandbox + Marketing Demand Engine との範囲の切り分けを明示、(c) パイロットごとの Cardano 成果 KPI、(d) より絞った範囲:「ワークショップ + 研究 + パイロット資金」は別個の3機能。分割して、それぞれ適切な Intersect サブ本体に紐付けることを検討。

*CPC 範囲は実在しうるが、複数の並行 BD / パイロット提案と切り分けなしに束ねられている。範囲の明確化を求めるため NO 再提出推奨。*

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 48. Intersect Technical Steering Committee Support

- Proposal ID: 69f38e85985067f4ae957a5e
- Requested: 1,193,000 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f38e85985067f4ae957a5e
- Category: Governance coordination
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

The bulk of scope (CIP editors, Hard Fork WG, parameter WG, etc.) is core ecosystem infrastructure.

### Voting reason (JA, as of 2026-05-28)

CIP や Hard Fork WG、 パラメータ WG など、 インフラ部分が大部分です。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Intersect Technical Steering Committee Support (**1.19M ADA / NCL 0.34%**).

**Main reasons**

**1. TSC operates real Cardano technical-governance infrastructure**
- Per proposal, TSC supports three specialist groups (WP2):
  - **Parameter Committee** — Cardano protocol parameter governance.
  - **CIP editors** — CIP review and merge governance (already managing cips.cardano.org).
  - **Hard Fork Working Group** — coordination for hard-fork releases (an active role given Dijkstra in Q1-Q2 2027 and the Leios / Peras roadmap).
- These are not "create a new committee" asks. They fund existing structural roles.

**2. Modest ask anchored to specific work packages**

| WP | Scope | Rough allocation |
|---|---|---|
| WP1 | Technical expert event attendance + commissioned technical reports | minor share |
| WP2 | Three specialist groups (Parameter / CIP / Hard Fork Working Group) | majority of budget |
| WP3 | Pilot independent technical review programme launching 2027 | additional incremental |

Total: $298,250 = 1,193,000 ADA at fixed conversion. Annualised cost for three specialist groups + technical events + a pilot review programme is at maintenance-class rate.

**3. The independent technical review programme (WP3) addresses a real gap**
- Cardano currently lacks an independent technical review programme distinct from IOG-internal review.
- A pilot launching in 2027 is a measured introduction (not an 18-month full commitment).
- This is the right way to introduce a new ecosystem capability — pilot + DRep oversight + scale if it works.

**4. No duplication: TSC is the only Cardano body of its kind**
- Intersect MBO (the parent body) is funded separately.
- The proposal text explicitly states three TSC-related activities are funded separately through the main Intersect budget: technical workshops, the Security Council, and the Bug Bounty Programme.
- This proposal's WP1 + WP2 + WP3 are not in the main Intersect budget.

**5. Contingent on Intersect MBO approval — clean failure mode**
- Per proposal: TSC execution is contingent on Intersect MBO budget approval. If MBO budget fails, TSC withdraws. DRep does not risk approving TSC without the MBO infrastructure.

**6. Accountability**
- Per proposal: "all expenditure will be fully accounted for and any unspent funds returned to the Cardano treasury".
- That is a strong commitment — most BD / marketing / research proposals do not include return-of-unspent terms.

**Conclusion**: real technical-governance role + clear scope + modest ask + explicit non-overlap with the main Intersect MBO budget. Default YES.

### Prior detailed analysis (JA)

**Vote: YES** — Intersect 技術運営委員会支援(**1.19M ADA / NCL 0.34%**)に YES。

**主な理由**

**1. TSC は実在の Cardano 技術ガバナンス基盤を運営**
- 提案書より、TSC は3つの専門グループ(WP2)を支える:
  - **パラメータ委員会** — Cardano プロトコルパラメータのガバナンス。
  - **CIP エディタ** — CIP レビューとマージ(既に cips.cardano.org を運用)。
  - **ハードフォーク作業部会** — ハードフォークの調整(2027 Q1-Q2 の Dijkstra や Leios / Peras を控え、現役の役割)。
- 「新しい委員会を作る」要求ではない。既存の構造的役割への資金。

**2. 具体的な作業項目に紐付いた控えめな要求額**

| WP | 範囲 | 配分の概観 |
|---|---|---|
| WP1 | 技術エキスパートのイベント参加 + 委託テクニカルレポート | 少額 |
| WP2 | 3つの専門グループ(Parameter / CIP / Hard Fork Working Group) | 予算の過半 |
| WP3 | 2027年開始の独立技術レビュー試行プログラム | 追加分 |

合計:$298,250 = 固定換算で 1,193,000 ADA。3 専門グループ + テクニカルイベント + 試行プログラムの年次費用としては保守クラスの単価。

**3. 独立技術レビュー試行(WP3)は実在の空白に対処**
- Cardano には現在、IOG の社内レビューと独立した技術レビュープログラムがない。
- 2027 年開始の試行は穏当な導入(18 か月コミットではない)。
- 新しいエコシステム能力の導入の正攻法:試行 + DRep 監督 + 機能すれば拡大。

**4. 重複なし:TSC は同種の唯一の本体**
- Intersect MBO(親本体)は別途資金。
- 提案書は明示している:TSC 関連の3活動(テクニカルワークショップ、セキュリティカウンシル、バグバウンティ)は主 Intersect 予算で別途資金。
- 本提案の WP1 + WP2 + WP3 は主 Intersect 予算には含まれない。

**5. Intersect MBO 承認に連動 — 明快な失敗モード**
- 提案書より:TSC 実行は Intersect MBO 予算承認に連動。MBO が落ちれば TSC は取り下げる。DRep が MBO 基盤なしで TSC を承認するリスクはない。

**6. 説明責任**
- 提案書より:「すべての支出を完全に説明し、未消化分は Cardano トレジャリーに返還する」。
- 強いコミット。多くの BD / マーケティング / 研究系提案には未消化返還の規定がない。

**結論**:実在する技術ガバナンスの役割 + 範囲の明確さ + 控えめな要求 + 主 Intersect MBO 予算との明示的な非重複で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 49. MLabs - Cardano.nix: 2026 Maintenance, Operator Tooling, and Dijkstra Readiness

- Proposal ID: 69fb669185ddd26899aaf203
- Requested: 1,171,903 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb669185ddd26899aaf203
- Category: Infrastructure / SDK
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Per developer feedback, demand is limited to a very narrow subset of developers. Demand evidence must be attached.

### Voting reason (JA, as of 2026-05-28)

開発者によれば、 これの需要は非常に限られた一部の開発者に限定されています。 需要の証拠を添付する必要があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Is my understanding correct that "being in trouble without this tool" boils down to — (a) a small number of teams that have already standardized on Nix, and (b) the time-bound risk that this layer would not make it in time for the Dijkstra HF — and that beyond these there are mature alternatives? Could you obtain and attach endorsement comments from this small number of teams, stating that they would be in trouble without NixOS and would not want to use alternative tools either?

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。「このツールがないと困る」のは——(a) Nix に標準化済みの少数のチーム と、(b) その層が Dijkstra HF に間に合わないという期限付きリスク——に集約され、それ以外には成熟した代替がある、という理解であっているでしょうか?この少数のチームからの、NixOSがないと困り代替ツールも使用したくないという、推薦コメントを入手し添付することはできますか?

### Prior detailed analysis (EN)

**Vote: YES** on MLabs - Cardano.nix: 2026 Maintenance, Operator Tooling, and Dijkstra Readiness (**1.14M ADA / NCL 0.33%**).

**Main reasons**

**1. Cardano.nix is the canonical Nix Cardano deployment toolkit**
- Founded under Catalyst Fund 10, continuously maintained by MLabs since.
- 2025 maintenance proposal: first 2 milestones already delivered (per proposal text).
- No competing Nix Cardano operator toolkit at this layer.
- Provides declarative deployment for: cardano-node + ogmios + kupo + cardano-db-sync + relay.

**2. Six-milestone scope tied to Dijkstra hard fork**

| Milestone | Scope |
|---|---|
| 1 | Foundational maintenance + source-build restoration |
| 2 | Service module completion (Demeter.run Kupo + Ogmios modules + Mithril snapshot bootstrap) |
| 3 | Dev-environment modules + AI-assistant readiness (Context7 integration for AI coding agents) |
| 4 | SPO operator tooling design |
| 5 | SPO operator tooling validation + Mithril signer prototype |
| 6 | Dijkstra readiness (Protocol Version 12, expected Q1-Q2 2027) |

- Dijkstra readiness is explicit and time-bounded.
- AI-assistant integration addresses a real developer-attrition surface: AI coding agents pulling accurate Cardano.nix context.

**3. MLabs delivery record on this specific project**
- Per ADAtool /tx-roi: MLabs cumulative = 40 Catalyst + 393K TW = 12.26M ADA.
- Per Intersect TW: Core Tool Maintenance bundle (Cardano.nix + Plutarch + ECC) = 6 of 8 milestones delivered (96,774 ADA disbursed) + 2 pending (41,294 ADA).
- Proposer notes the 2025 Cardano.nix maintenance had its first 2 milestones already delivered.

**4. What discontinuation would cost**
- SPOs and developers using Nix-based deployments would either: (a) self-maintain Nix expressions (rare combination of Cardano internals and Nix expertise required), or (b) abandon Nix for Docker / Ansible (more configuration drift).

**5. No competing Nix Cardano toolkit**
- Alternative deployment systems (Docker, Ansible) serve different operator workflows. No active Treasury Withdrawal funds a competing Nix maintainer.

Default YES — established sole-maintainer + concrete Dijkstra anchor + 75% Year-1 delivery + no alternative.

### Prior detailed analysis (JA)

**Vote: YES** — MLabs - Cardano.nix(保守 + 運用者ツール + Dijkstra 対応、**1.14M ADA / NCL 0.33%**)に YES。

**主な理由**

**1. Cardano.nix は Nix ベース Cardano デプロイの事実上の標準**
- Catalyst Fund 10 で誕生。以来 MLabs が継続保守。
- 2025 年保守提案:最初の2マイルストーンを既に納品済み(提案書本文より)。
- 同じ層に競合する Nix 系 Cardano 運用ツールはない。
- cardano-node + ogmios + kupo + cardano-db-sync + relay を宣言的にデプロイ可能。

**2. Dijkstra に紐付いた6マイルストーン**

| マイルストーン | 内容 |
|---|---|
| 1 | 基盤保守 + ソースビルドからの構築復活 |
| 2 | サービスモジュール完成(Demeter.run の Kupo / Ogmios モジュール + Mithril スナップショットブート) |
| 3 | 開発環境モジュール + AI コーディング支援対応(AI エージェント向け Context7 統合) |
| 4 | SPO 運用ツール設計 |
| 5 | SPO 運用ツール検証 + Mithril 署名者プロトタイプ |
| 6 | Dijkstra 対応(Protocol Version 12、2027 Q1-Q2 想定) |

- Dijkstra 対応は期限付きで明示。
- AI 支援対応は実在の課題(AI コーディングエージェントが正確な Cardano.nix の文脈を取得できるか)に対処。

**3. このプロジェクト固有の納品実績**
- ADAtool /tx-roi:MLabs 累積 = Catalyst 40件 + TW 393K = 12.26M ADA。
- Intersect TW:コアツール保守バンドル(Cardano.nix + Plutarch + ECC)= 8件中6件完了(96,774 ADA 受領)+ 2件保留(41,294 ADA)。
- 提案者は、2025 年 Cardano.nix 保守の最初の2マイルストーンを既に納品済みと記載。

**4. 保守をやめた場合の代替コスト**
- Nix ベースを使う SPO や開発者は、(a) Nix 表現を自前で保守する(Cardano 内部知識と Nix 知識の両方を持つ希少な組み合わせが必要)、または (b) Nix をやめて Docker / Ansible に移行する(設定の散らばりが拡大)、のいずれかになる。

**5. 競合する Nix Cardano ツールキットはない**
- Docker や Ansible は別の運用フローを担う。競合する Nix 系保守者に対する Treasury 資金はない。

確立した単独保守 + 期限付き Dijkstra 連携 + Y1 75% 達成 + 代替なしで、YES。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb669185ddd26899aaf203#comment-6a1e154e5141bb70a939dbba
- Summary (EN): Proposer (MLabs) acknowledges Cardano.nix serves a narrower operator audience but argues narrow is not absent, cites GitHub traffic (~40 unique cloners, 200+ clones in 14 days) as demand evidence, frames it as a continuation of a funded project with delivered milestones and a concrete 2026 scope, and aligns it with Cardano 2030 Pillars 1 and 5.
- Summary (JA): 提案者(MLabs)はCardano.nixが運用者という狭い層に向けたものだと認めつつ、狭いことは不在を意味しないと主張し、GitHubのトラフィック(14日間で約40の固有クローン者、200超のクローン)を需要の証拠として引用し、マイルストーンを達成した資金済みプロジェクトの継続で具体的な2026年スコープを持つと位置づけ、Cardano 2030のPillar 1と5に合致すると述べている。

Full text:

Thank you, Yuta.

We understand the concern that Cardano.nix serves a narrower developer and operator audience than a general-purpose wallet, SDK, or dApp framework. That is true. But “narrow” is not the same as absent or unimportant.

Cardano.nix is infrastructure for teams running Cardano services reproducibly, including cardano-node, Ogmios, Kupo, cardano-db-sync, Mithril-related workflows, and SPO/operator tooling. By nature, that audience is smaller than the general Cardano developer population, but it is also a high-leverage audience because these are the people operating production infrastructure.

On demand evidence, GitHub insights show approximately 40 unique cloners and 200+ total clones in the last 14 days. That indicates an active community of users and evaluators beyond MLabs. We can attach a screenshot of the GitHub traffic data as supporting evidence.

The proposal is therefore not based on theoretical demand. It is a continuation of an existing infrastructure project with current usage, prior funding, delivered milestones, and a concrete 2026 scope covering source-build restoration, service modules, Mithril bootstrap, developer environments, SPO tooling, testnet validation, and Dijkstra readiness.

This aligns directly with Cardano 2030 Pillar 1 and Pillar 5. Cardano.nix supports reproducible infrastructure, safer service deployment, operator resilience, and protocol-upgrade readiness. The user base may be specialized, but the value of reliable deployment infrastructure is ecosystem-wide.

Here is a video explanation by our CTO:

[https://drive.google.com/file/d/1xv568KnGpmeySgZFGh24gjDSw8E2006S/view?usp=sharing](https://drive.google.com/file/d/1xv568KnGpmeySgZFGh24gjDSw8E2006S/view?usp=sharing)

---

## 50. MLabs - Grumplestiltskin 2: Pasta Curve Builtins and Kimchi PLookup Proof-of-Concept

- Proposal ID: 69fcab8de1ab5d003a0cab66
- Requested: 1,167,325 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fcab8de1ab5d003a0cab66
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Multiple developers have indicated this may not be technically feasible on current Cardano.

### Voting reason (JA, as of 2026-05-28)

現在の Cardano において、 これが技術的に実現困難である可能性が複数の開発者により指摘されています。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. I understand that the Pasta builtins are implementable. However, (1) Cardano already has a more proof-efficient alternative path that achieves recursion on BLS12-381 via outer-field arithmetic (as pointed out by perturbing, and already implemented in Midnight), and (2) no real-demand builder that would consume the Pasta route's differentiator (IPA / no trusted setup) has yet been identified. Therefore, because the necessity is relatively weak and the demand has not been demonstrated, I consider the priority to be lower given the current market situation.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答をありがとうございます。Pastaビルトインは実装可能であることを理解しました。ただし、(1) Cardanoには外部体演算でBLS12-381上の再帰を実現する、より証明効率の良い代替経路が既に存在し(perturbing氏指摘・Midnight実装済み)、(2) Pastaルートの差別化要因(IPA/信頼設定不要)を消費する実需ビルダーはまだ特定されていません。よって必要性(necessity)が相対的に弱く需要(demand)が立証されていないために、現在のマーケットの状況から見て、優先順位は落ちると考えています。

### Prior detailed analysis (EN)

**Vote: NO** on MLabs - Grumplestiltskin 2: Pasta Curve Builtins and Kimchi PLookup PoC (**1.14M ADA / NCL 0.33%**).

**Main reasons**

**1. No Cardano builder has committed to use Pasta curves**
- Number of named Cardano ZK builders committing to consume Pasta-curve built-ins: **zero**.
- The proposal cites Mina's Kimchi proof system as inspiration, but Mina built its entire chain on Pasta. Cardano's ZK situation is different: BLS12-381 built-ins (CIP-381) are already in the protocol, and no major Cardano DeFi or RWA protocol currently uses ZK at production scale.

**2. Possible overlap with existing IO research Treasury Withdrawals**

| Active TW | Budget | Scope that may cover ZK primitives |
|---|---|---|
| TW #99 IO Consensus Initiative | 27.7M ADA (2026-2028) | Ouroboros + consensus research |
| TW #103 IO + VacuumLabs Plutus Enhancement | 11.88M ADA | Plutus Core built-ins + ZK |
| TW #113 Cardano Vision 2026 IO Research | 32.9M ADA | broad research |

Whether IO is already doing Pasta-curve work in #103 or #113 is not made explicit. Approving without delineation risks paying for the same layer twice.

**3. Sequencing: built-ins before demand**
- Proposed deliverables: a CIP for UPLC built-ins (Pallas + Vesta curves) + implementation in cardano-base + Plutus Core + a verifier proof of concept for Kimchi PLookup.
- These are all infrastructure that would enable future ZK use cases, but no funded Cardano ZK protocol has committed to consuming Pasta built-ins.
- Compare BLS12-381: CIP-381 was approved when Cardano ZK protocols (Hydra rollup design, ZK bridge designs) already had use cases in flight. Pasta curves lack that demand bridge today.

**4. MLabs delivery context**
- Per ADAtool /tx-roi: MLabs cumulative = 40 Catalyst + 393K TW = 12.26M ADA (largest historical recipient by proposal count).
- Per Intersect TW: MLabs Core Tool Maintenance = 6 of 8 milestones delivered (96,774 ADA disbursed) + 2 pending (41,294 ADA). Year-1 ratio 75%.
- Delivery cadence is solid for maintenance work; research proofs of concept carry a different risk shape.

**Recommend resubmission** with: (a) at least one named Cardano ZK builder committing to consume Pasta-curve built-ins, (b) explicit delineation versus IO TW #103 / #113 scope, (c) a problem-statement publication step before implementation begins, so the community can settle on Pasta versus alternative curve families.

*Note: per @perturbing's community feedback, Pasta curves are a recognised research direction, but the gap is demand validation.*

### Prior detailed analysis (JA)

**Vote: NO** — MLabs - Grumplestiltskin 2: Pasta 曲線ビルトイン + Kimchi PLookup PoC(**1.14M ADA / NCL 0.33%**)に NO。

**主な理由**

**1. Pasta 曲線を使うと宣言した Cardano 側ビルダーがいない**
- Pasta 曲線ビルトインを使うことを宣言した Cardano ZK ビルダー:**ゼロ**。
- 提案書は Mina の Kimchi 証明系を参照するが、Mina はチェーン全体を Pasta の上に構築している。Cardano は事情が違う。BLS12-381 のビルトイン(CIP-381)が既にプロトコル内にあり、本番規模で ZK を使う主要 Cardano DeFi / RWA プロトコルは今のところ存在しない。

**2. 既存 IO 研究系 Treasury Withdrawal との重なりの可能性**

| 進行中 TW | 予算 | ZK プリミティブと関係しうる範囲 |
|---|---|---|
| TW #99 IO Consensus Initiative | 27.7M ADA(2026-2028) | Ouroboros + 合意研究 |
| TW #103 IO + VacuumLabs Plutus Enhancement | 11.88M ADA | Plutus Core ビルトイン + ZK |
| TW #113 Cardano Vision 2026 IO Research | 32.9M ADA | 広い研究 |

IO 側が Pasta 曲線を #103 や #113 で扱うかどうかは明示されていない。切り分けなしで承認すると、同じ層を2度払う恐れがある。

**3. 順番の問題:需要より先にビルトイン**
- 提案の成果物:UPLC ビルトイン(Pallas + Vesta 曲線)の CIP + cardano-base / Plutus Core への実装 + YTxP を使った Kimchi PLookup の検証 PoC。
- いずれも「将来の ZK 用途を可能にする土台」だが、Pasta ビルトインを使うと約束した Cardano ZK プロトコルがない。
- BLS12-381 のときは、Cardano ZK プロトコル(Hydra ロールアップ設計、ZK ブリッジ設計)の用途が動いている状態で CIP-381 が承認された。Pasta はその橋がまだない。

**4. MLabs の納品実績**
- ADAtool /tx-roi:MLabs 累積 = Catalyst 40件 + TW 393K = 12.26M ADA(提案件数で歴代最大の受領者)。
- Intersect TW:MLabs コアツール保守 = 8件中6件完了(96,774 ADA 受領)+ 2件保留(41,294 ADA)。Y1 達成率 75%。
- 保守仕事の達成率は堅いが、研究 PoC は別のリスク形状を持つ。

**再提出推奨**:(a) Pasta 曲線ビルトインを使う Cardano ZK ビルダーを1つ以上明示、(b) IO TW #103 / #113 との範囲の切り分け、(c) 実装着手前に問題提起(CPS 形式)を公開し、Pasta と他の曲線群との比較をコミュニティで合意する。

*@perturbing のコメントによれば、Pasta 曲線は認知された研究方向だが、需要の検証が抜けている。*

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fcab8de1ab5d003a0cab66#comment-6a1e0fb55141bb70a939dbb9
- Summary (EN): Proposer (MLabs) engages perturbing's IPA-vs-KZG technical argument, conceding its accuracy but arguing Pasta curves and BLS12-381 are complementary rather than substitutes (IPA needs no trusted setup, Pasta is production-hardened on Zcash), so the case does not rest on Pasta being the only recursion path.
- Summary (JA): 提案者(MLabs)はperturbingのIPA対KZGの技術的議論に応じ、その正確さを認めつつ、Pasta曲線とBLS12-381は代替ではなく補完的だ(IPAはトラステッドセットアップ不要、PastaはZcashで本番堅牢化済み)と主張し、本提案の論拠はPastaが唯一の再帰経路であることに依存しないと述べている。

Full text:

Thanks, Yuta, for the substantive feedback. You mentioned the technical comments which in particular deserve direct engagement, and the proposal text has been updated since some of the earlier review. Point-by-point below.

1. perturbing's IPA-vs-KZG argument

perturbing is correct that Pasta curves use IPA-style commitments, which produce larger proofs than KZG; correct that Ethereum and the PSE Halo2 fork moved to pairing-based curves for exactly this reason; and correct that Midnight's 2025 foreign-field-arithmetic paper offers a viable BLS12-381 recursion path that doesn't require new curve builtins. None of that is wrong.

Where we'd push back: the existence of one good approach doesn't make a second approach unnecessary. The IPA-vs-KZG trade-off is real but not strictly directional — IPA requires no trusted setup, which matters for many privacy-first use cases; Halo2's accumulation scheme materially mitigates the proof-size gap; Pasta curves have been production-hardened on Zcash since Nu5 with multiple audits. Foreign-field PLONK on BLS12-381 is a genuinely interesting research direction, but it is also recent and not yet broadly adopted across the ZK ecosystem.

Our view: Cardano benefits from having both pathways available. BLS12-381 builtins (already in protocol) serve KZG-based use cases. Pasta builtins serve IPA-based, trusted-setup-free use cases. They are complements, not substitutes. We don't think the proposal's case rests on Pasta being the only path to recursion — it rests on Pasta being a different, well-tested path with different properties.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fcab8de1ab5d003a0cab66#comment-6a1e0fd00dcaa7f9767cd59d
- Summary (EN): Proposer (MLabs) commits to adding a public Problem Statement deliverable in M1 comparing Pasta builtins against alternatives before implementation, and to confirming with IO Research before M2 that the work does not duplicate Treasury Withdrawal #113 (or others), narrowing/withdrawing if overlap exists, and notes Grumplestiltskin 1 closeout precedes Grumplestiltskin 2.
- Summary (JA): 提案者(MLabs)は、実装前にPastaビルトインを代替案と比較する公開のProblem StatementをM1で追加し、M2前にIO Researchと作業がTreasury Withdrawal #113(他も含む)と重複しないことを確認し、重複があればスコープを縮小/撤回すると約束し、Grumplestiltskin 1のクローズアウトがGrumplestiltskin 2に先行すると述べている。

Full text:

2. Demand validation — adding a problem-statement step:

We agree that "primitives before demand" is a fair sequencing concern. We will add a public Problem Statement deliverable to M1 — a written analysis comparing Pasta builtins against the alternatives (BLS12-381 with foreign-field PLONK, Midnight's existing implementation, Eryx ZK work, zkFold), published before commencing implementation work in M2 onward. This gives the community a settled view of the curve-family trade-off before any code is contributed to cardano-base. If that analysis concludes Pasta is not the right next investment, we adjust scope accordingly.

3. IO Treasury Withdrawal overlap

We've reviewed the public scopes of TW #99 (Consensus Initiative / Leios), TW #103 (VacuumLabs Plutus Enhancement — performance/correctness/usability of Plutus), and TW #113 (Cardano Vision 2026 — broad research including ZK-enabled scaling and ZK rollups). None of the three publicly describes Pasta curve builtins or PLONK-family primitive contribution at the cardano-base / Plutus Core layer.

That said, the overlap concern is reasonable, particularly with TW #113. Commitment: before commencing M2 work, we will explicitly confirm with IO Research that this proposal does not duplicate planned TW #113 deliverables. If overlap exists, we narrow scope, refocus on complementary work, or withdraw. We are not asking the Treasury to pay for the same primitive twice.

4. Grumplestiltskin 1 closeout

Final milestone closeout for Grumplestiltskin 1 is expected this month as we conclude conversations with our auditors. Grumplestiltskin 2 work would not commence until Grumplestiltskin 1 is fully closed out.

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fcab8de1ab5d003a0cab66#comment-6a1e0fe8f4bf5dd313f5cf87
- Summary (EN): Proposer (MLabs) explains the Eryx audit scope covers cryptographic correctness, FFI safety, Plutus Core semantics, and the PLookup verifier, and details treasury protection (repayment Yes, surplus return above ~$0.30/ADA with a $5,000 materiality threshold, plus willingness to use a higher ADA reference rate if milestone payouts can convert to stablecoins).
- Summary (JA): 提案者(MLabs)は、Eryxの監査範囲が暗号学的正確性・FFIの安全性・Plutus Coreのセマンティクス・PLookup検証器を対象とすると説明し、トレジャリー保護(返済あり、約$0.30/ADA超で$5,000の重要性しきい値による余剰返還、加えてマイルストーン支払いをステーブルコインに変換できる場合はより高いADA参照レートを使う意向)を詳述している。

Full text:

5. Audit scope

Eryx audits cover cryptographic correctness of the curve implementations, FFI safety in the arkworks-rs integration, Plutus Core semantics of the new builtins, and the PLookup verifier implementation. Not just milestone evidence — the cryptographic content is what justified selecting a cryptography-specialist auditor over general software audit. Benchmarks are M2/M3 deliverables (we don't speculate on performance ahead of implementation) and will be public.

6. Treasury protection

The proposal text has been updated since the earlier review: repayment is now Yes, with surplus return triggered above \~$0.30/ADA, $5,000 USD materiality threshold, and surplus return for unused budget at close-out. Additional offer: if Intersect's administrative framework supports converting milestone payouts to stablecoins at the actualized conversion price upon milestone approval, we are willing to use a higher ADA reference rate — reducing the ADA requested and removing most appreciation-risk exposure.

We welcome reconsideration in light of these clarifications. Continued questions welcome.

Also, here is a video explanation from our CTO if that helps:

[https://drive.google.com/file/d/1\_wfXD94pbO0gRgCqynEe7E5NJyybzC0N/view?usp=sharing](https://drive.google.com/file/d/1_wfXD94pbO0gRgCqynEe7E5NJyybzC0N/view?usp=sharing)

---

## 51. MLabs Core Tool Maintenance & Enhancement: Plutarch and Ply

- Proposal ID: 69fae404f9ebc26d057f51bf
- Requested: 1,162,746 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fae404f9ebc26d057f51bf
- Category: Infrastructure / SDK
- Applicable criteria: C5, C8
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Already widely adopted.

### Voting reason (JA, as of 2026-05-28)

すでに幅広い採用があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback of a nature that would alter the vote.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback of a nature that would alter the vote.

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on MLabs Core Tool Maintenance & Enhancement: Plutarch and Ply (**1.14M ADA / NCL 0.33%**).

**Main reasons**

**1. 26 teams build with Plutarch and Ply — strongest demand evidence in the MLabs bundle**
- Per proposal text: "MLabs counted at least **26 teams building with Plutarch and Ply**" (recent internal audit).
- MLabs public cross-language benchmarks (mlabs-haskell.github.io/uplc-benchmark/comparison.html) show Plutarch ranks among smallest scripts with low on-chain compute and memory.
- This is the clearest demand-anchored MLabs proposal in the bundle.

**2. But Year-1 has 2 milestones still pending**
- Per Intersect TW (2026-05-10): Core Tool Maintenance bundle (Cardano.nix + Plutarch + ECC) = **6 of 8 milestones delivered (96,774 ADA disbursed) + 2 pending (41,294 ADA)**.
- Year-1 delivery ratio = 75%.
- Plutarch + Ply specific milestones within the bundle are not broken out, so Plutarch-specific delivery is unclear.
- A Year-2 ask without Year-1 closure visibility is a sequencing concern.

**3. Scope = quarterly maintenance with priority hierarchy**

| Priority | Scope |
|---|---|
| 1 | Critical breakages + serious vulnerabilities |
| 2 | Protocol-era + ledger updates (Dijkstra Q1-Q2 2027) |
| 3 | Routine maintenance (dependency bumps, CI, documentation) |
| 4 | Performance + DX enhancement |

The model is well-structured, but priority 4 is loosely defined and could absorb arbitrary scope. There are no specific Plutarch / Ply Year-2 deliverables tied to named dApp consumer needs.

**4. Cost benchmark versus Cardano.nix maintenance**
- This proposal: 1.14M ADA for Plutarch + Ply maintenance — the same amount as MLabs Cardano.nix 2026 (also 1.14M ADA).
- Cardano.nix has 6 concrete milestones; this proposal has a priority-hierarchy quarterly model.
- Plutarch's 26-team adoption is stronger than Cardano.nix's SPO adoption — Plutarch arguably warrants a separately structured evaluation.

**5. C5 cross-check**
- Plutarch is the Haskell eDSL for Cardano smart contracts; no competing Haskell eDSL exists at this layer.
- TW #103 IO + VacuumLabs Plutus Enhancement (11.88M ADA) is at the Plutus Core layer below Plutarch — orthogonal, not duplicative.
- Aiken (alternative smart-contract language) is separately maintained — different language, not a substitute for Plutarch users.

**Recommend resubmission** with: (a) explicit Year-1 closure status for the 2 pending Core Tool Maintenance milestones (which are Plutarch-specific?), (b) Year-2 deliverables broken out by Plutarch vs Ply with named dApp consumer commitments where applicable (Indigo, Liqwid, Genius Yield, etc.), (c) Year-2 cost-vs-26-team-adoption justification.

*Default-YES would be appropriate with Year-1 closure transparency. NO-resubmit reflects the visibility gap, not the underlying Plutarch value.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — MLabs コアツール保守強化:Plutarch と Ply(**1.14M ADA / NCL 0.33%**)に NO(再提出推奨)。

**主な理由**

**1. 26 チームが Plutarch / Ply で開発中 — MLabs バンドル中もっとも強い需要根拠**
- 提案書本文:「MLabs は **少なくとも 26 チームが Plutarch と Ply で開発している** ことを確認した」(最近の内部監査)。
- MLabs の公開クロス言語ベンチマーク(mlabs-haskell.github.io/uplc-benchmark/comparison.html)では、Plutarch はスクリプトサイズが小さく、オンチェーン計算とメモリが低い側に位置する。
- バンドルの中で需要根拠がもっとも明確な提案。

**2. ただし Year 1 にマイルストーンが2件未完**
- Intersect TW(2026-05-10):コアツール保守バンドル(Cardano.nix + Plutarch + ECC)= **8件中6件完了(96,774 ADA 受領)+ 2件保留(41,294 ADA)**。
- Y1 達成率 75%。
- バンドル内の Plutarch + Ply 固有マイルストーンは別途切り出されていないため、Plutarch 固有の達成状況は不明。
- Y1 の完了状況が見えないまま Y2 を承認することへの懸念。

**3. 範囲は優先度階層付きの四半期保守**

| 優先度 | 範囲 |
|---|---|
| 1 | 重大な破損 + 重大な脆弱性 |
| 2 | プロトコル時代 + 台帳更新(Dijkstra 2027 Q1-Q2) |
| 3 | 定型保守(依存更新、CI、ドキュメント) |
| 4 | 性能 + DX の改善 |

枠組み自体は整っているが、優先度4が緩く、任意の範囲を吸収しうる。Plutarch / Ply の Y2 で名前付き dApp ニーズに紐付いた具体的な成果物がない。

**4. Cardano.nix 保守との単価比較**
- 本提案:Plutarch + Ply 保守に 1.14M ADA — MLabs Cardano.nix 2026 と同額(同じく 1.14M ADA)。
- Cardano.nix は具体的な6マイルストーン構成。本提案は優先度階層型の四半期モデル。
- Plutarch の 26 チーム採用は Cardano.nix の SPO 採用より厚い。Plutarch の枠を別評価にする余地がある。

**5. 重複確認**
- Plutarch は Cardano スマートコントラクト用の Haskell eDSL。同層に競合する Haskell eDSL はない。
- TW #103(IO + VacuumLabs Plutus Enhancement、11.88M ADA)は Plutarch の下、Plutus Core 層。直交関係で重複ではない。
- Aiken(別言語)は別途保守。Plutarch 利用者の代替ではない。

**再提出推奨**:(a) コアツール保守の保留中2マイルストーンの Y1 完了状況(どれが Plutarch 固有か)、(b) Y2 の成果物を Plutarch と Ply で分解し、可能なら名前付き dApp(Indigo、Liqwid、Genius Yield など)の採用約束を添える、(c) Y2 費用を 26 チーム採用に対して正当化。

*Y1 完了状況の透明性があれば YES が妥当。NO 再提出推奨は可視性ギャップに対するもので、Plutarch の価値自体への否定ではない。*

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fae404f9ebc26d057f51bf#comment-6a1e12d9a7468bb49bf846ef
- Summary (EN): Proposer briefly thanks YUTA for the response and vote.
- Summary (JA): 提案者はYUTAの回答と投票に対し簡潔に謝意を述べている。

Full text:

Thank you for your response and vote.

---

## 52. Daedalus Wallet Maintenance and Improvements 2026-2027

- Proposal ID: 69fd0d5ef9ebc26d057f51d3
- Requested: 1,153,600 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd0d5ef9ebc26d057f51d3
- Category: Wallet / hardware
- Applicable criteria: C8
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Recommend resubmitting via on-chain governance action with scope reduced. Daedalus maintenance is a legitimate public-good ask, but the v7 proposal still fails the unit-economics and scope-discipline tests. $250k/yr (plus audit reserve) for ~4,000 opt-in MAU equals roughly $62/user/year — defensible only if scope were strictly hard-fork readiness, security patches, and node upgrades. Instead the proposal bundles CIP-30 dApp connector, Electron 41, Ledger Flex/Keystone support, and a self-architecture assessment — features whose demand from the actual full-node user cohort is undemonstrated. DeFi users structurally prefer browser wallets, so CIP-30 in Daedalus mostly duplicates Lace/Eternl rather than expanding addressable demand.

### Voting reason (JA, as of 2026-05-28)

スコープ縮小の上、 オンチェーンガバナンスアクションでの再提出を推奨します。 Daedalus maintenance は legitimate な public-good ask ですが、 v7 の提案書は依然として unit-economics と scope-discipline のテストに合格していません。 約 4,000 opt-in MAU に対して $250k/yr (+audit reserve) は ~$62/user/year で、 これが正当化できるのは scope が hard-fork readiness / security patches / node upgrades に厳密に絞られている場合のみです。 ところが提案は CIP-30 dApp connector、 Electron 41、 Ledger Flex / Keystone support、 self-architecture assessment を抱き合わせており、 これら機能の実際のフルノードユーザーコホートからの demand は実証されていません。 DeFi ユーザーは構造的にブラウザウォレットを選好するため、 Daedalus 内 CIP-30 は主に Lace / Eternl と重複し、 addressable demand の拡大ではなく重複作業となります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on Daedalus Wallet Maintenance 2026–2027 (**2.14M ADA / NCL 0.61%**).

**Main reasons**

**1. Proposer is the right team; the scope justification is the gap**
- Proposer: **Se7en Labs**, currently operating Daedalus under an IOG contract that closes **August 2026**.
- Daedalus is the only full-node desktop Cardano wallet. Its privacy-stance terms of service prevent collecting user telemetry, so asks for "show monthly active users" are not realistic for this product.
- The team is right; the issue is per-feature scope justification, not eligibility.

**2. Eight engineers for 12 months at $500K USD needs a role-by-role breakdown**

| Scope area | Listed deliverables |
|---|---|
| Governance | DRep dashboard + self-DRep registration + direct voting |
| Protocol Maintenance | Node upgrade + Leios + Peras + Nested Tx readiness |
| Ecosystem Expansion | Electron 41 + Ledger Flex + Keystone + CIP-30 dApp connector |
| Operations | Release cadence + QA + support |

The proposal lists feature areas but does not map the 8 engineers to these 4 buckets with role-quarters.

**3. Adding a dApp connector inside Daedalus is asserted, not argued**
- Daedalus users self-select for the "do not delegate trust" model.
- Those same users likely keep a browser wallet (Nami / Lace / Eternl) for dApp use, since browser context is where most dApp UX lives.
- The proposer needs to argue why a dApp connector inside Daedalus is the right surface, rather than deeper integration with the browser wallets these users already use.

**Recommend resubmission** with (a) the 8-engineer team mapped to the 4 scope areas, (b) per-feature scope justification with deferral options, (c) an explicit handoff plan from IOG, including code-ownership transfer milestones, since the IOG contract closes mid-cycle.

*Vote position: NO-resubmit holds. Se7en Labs is the right party. A flip to YES is realistic with the clarifications above.*

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — Daedalus Wallet Maintenance 2026–2027 (**2.14M ADA / NCL 0.61%**) に NO(再提出推奨)。

**主な理由**

**1. 提案者は正しい。足りないのは費用の根拠**
- 提案者は **Se7en Labs**。現在 IOG との契約のもとで Daedalus を運営しており、その契約は **2026年8月** に終了する。
- Daedalus は唯一のフルノード型デスクトップウォレットで、プライバシー方針上、ユーザーの利用統計を収集できない。よって「月間アクティブユーザー数を出せ」という要求は構造上、現実的でない。
- チームの適性は問題ない。問題は、機能ごとに費用が妥当かどうかの説明不足。

**2. 12か月で8人・$500K の内訳が役割ごとに示されていない**

| 領域 | 列挙されている成果物 |
|---|---|
| ガバナンス | DRep ダッシュボード、自分が DRep になる機能、直接投票 |
| プロトコル保守 | ノード更新、Leios、Peras、Nested Tx 対応 |
| エコシステム拡張 | Electron 41、Ledger Flex、Keystone、dApp 接続機能 |
| 運用 | リリース、QA、サポート |

提案書は領域を列挙するが、8人をこの4領域に何人ずつ配分するか(人月ベース)の説明がない。

**3. Daedalus 内に dApp 接続を作る判断は主張のみで根拠なし**
- Daedalus 利用者は「他者を信頼しない」モデルを選んだ人たち。
- その同じ利用者は dApp 操作にはブラウザウォレット(Nami / Lace / Eternl)を併用している可能性が高い。dApp の操作場所は基本ブラウザだから。
- 既存のブラウザウォレットと深く統合する方が良いのではないか、という比較がないまま、Daedalus 内に dApp 接続を作る必要性が主張されている。

**再提出推奨**:(a) 8人を4領域にどう配分するか、(b) 機能ごとの費用と「やらない場合」の選択肢、(c) IOG契約終了に伴うコード所有権の移転計画(マイルストーン付き)。

*Se7en Labs は正しいチーム。上記の補足があれば YES に転じうる。*

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 53. Catalyze Africa: Building Scalable Projects from CATS 2026

- Proposal ID: 69ef7bedd699758cde5d4a66
- Requested: 982,433 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ef7bedd699758cde5d4a66
- Category: Education
- Applicable criteria: C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Future measurability is not a substitute for past attribution. In effect, acknowledging that there is no past attribution and then promising to "measure it this time" is not a substitute for presenting a track record. Therefore, since I still cannot be confident in the feasibility of generating superior Tx, I maintain my NO vote.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。将来の計測可能性は、過去の帰属の代替になりません。 実質、過去の帰属が無いことを認めた上で「今度は測る」と約束したことは、実績の提示の代替にはなりません。よって優位なTxが生まれる実行可能性について依然として自信を持てないのでNOの投票を維持します。

### Prior detailed analysis (EN)

**Categorisation**: [Education / community building]. Non-applicable: C1, C3, C4 (education proposals not designed for Treasury return), C5, C6, C7, C9, C10, C11.

**Applicable: C2 (only as supporting context — Wada has Cardano track record, so C2 alone passes), C8 (past funding outcome attribution)**. Applying:

• **C8 — Past funded projects' outcome attribution (decisive)**: Per /tx-roi backend (https://adatool.net/tx-roi), **Wada has received 27 Catalyst proposals across multiple fund cycles since F4 = 1.81M ADA cumulative funding**. Examples of past Wada-funded Catalyst items (per public Catalyst funding records): West Africa onboarding programs, Planting Roots, Nurturing Roots, Cardano Hubs Directory, Expanding Cardano's Reach in Africa, etc.

  Production tx attributable to Wada-funded outcomes (per ADAtool db-sync `tx_label` aggregation): **0 verifiable**. The track record cited in the current proposal — '20+ hubs', '13 countries', '1,200 developers at CATS 2026' — consists of process metrics (event delivery, attendee count, country coverage). 

  Measurable Cardano network outcomes from the 27 prior funded projects, that could justify a 28th funding cycle, are absent from public information:
  - **Cardano DApp launches by program participants**: not enumerated
  - **Cardano Tx volume contribution**: not measurable in tx_label
  - **TVL impact**: not enumerated
  - **Long-term ecosystem retention** (alumni still active on Cardano N months post-program): not measured

  A public commenter on the proposal raised the same empirical concerns (paraphrased): 'How many developers does the initiative realistically expect to onboard into the Cardano ecosystem in terms of long-term impact?' and 'What measurable outcomes should realistically be expected a few months after the program concludes?' — these remain unaddressed in the proposal.

  Cumulative 1.81M ADA × 0 verifiable Cardano outcome ratio is a strong empirical signal that an additional funding cycle without outcome-attribution requirements should not be approved.

Therefore this proposal does not satisfy this criterion.

### Prior detailed analysis (JA)

**分類**: [教育 / community 構築]。 非適用: C1, C3, C4 (education 提案は Treasury return 設計でない), C5, C6, C7, C9, C10, C11。

**適用: C2 (supporting context として — Wada は Cardano track record あり、 C2 単独では pass), C8 (過去資金 outcome attribution)**。 適用:

・**C8 — 過去 funded projects の outcome attribution (決定的)**: /tx-roi backend (https://adatool.net/tx-roi) より、 **Wada は F4 以降複数 fund cycle 横断で 27 Catalyst proposals = 1.81M ADA 累積資金を受領**。 過去 Wada-funded Catalyst items の例 (公開 Catalyst funding records より): West Africa onboarding programs, Planting Roots, Nurturing Roots, Cardano Hubs Directory, Expanding Cardano's Reach in Africa 等。

  Wada-funded outcome に帰属可能 production tx (ADAtool db-sync `tx_label` 集計より): **0 verifiable**。 現提案書記載 track record — '20+ hubs', '13 countries', '1,200 developers at CATS 2026' — は process metric (event delivery, 参加者数, country coverage)。

  27 prior funded projects から、 28 回目の funding cycle を justify する measurable Cardano network outcome は公開情報に absent:
  - **Program 参加者による Cardano DApp launch 数**: enumerate なし
  - **Cardano Tx volume 寄与**: tx_label で measurable でない
  - **TVL impact**: enumerate なし
  - **長期 ecosystem retention** (program 後 N ヶ月 Cardano に active な alumni 数): 測定なし

  提案 commenter が同 empirical concern を提起 (要旨): 'How many developers does the initiative realistically expect to onboard into the Cardano ecosystem in terms of long-term impact?' と 'What measurable outcomes should realistically be expected a few months after the program concludes?' — 提案書で unaddressed のまま。

  累積 1.81M ADA × 0 verifiable Cardano outcome 比率は、 outcome-attribution requirement なしの追加 funding cycle を承認すべきでないという strong empirical signal。

よって本提案はこの criterion を満たさない。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ef7bedd699758cde5d4a66#comment-6a10957a0dcaa7f9767cd55e
- Summary (EN): Concedes that prior 27 Catalyst proposals (from F4) focused on human infrastructure/education and were not designed to leave on-chain tx_label footprints, explaining the /tx-roi absence. Plans cryptographic attribution methods including a standardized 'Catalyze Africa' metadata label across funded projects.
- Summary (JA): 過去27件のCatalyst提案 (F4以降)が人材インフラ・教育中心でtx_labelメタデータを残す設計ではなかったと認め、/tx-roiで不可視である理由を説明。今後は標準化された「Catalyze Africa」メタデータラベルなど暗号学的アトリビューション手法を導入予定。

Full text:

Hi Yuta, 

We appreciate you engaging with our proposal.

The application of the C8 criterion and the reference to the /tx-roi backend highlight an important concern regarding historical funding outcomes. Our 27 previous Catalyst proposals, beginning from Fund 4, were intentionally focused on human infrastructure, regional outreach, and foundational Web3 education. As a result, these initiatives were not designed to produce identifiable tx\_label metadata footprints on-chain. This explains the absence of visible signatures in standard db-sync aggregations for those funds, despite substantial on-chain activity emerging from the African region that was not systematically documented in a measurable attribution framework.

This Intersect proposal represents a clear transition from broad community building to targeted, measurable venture creation. It directly addresses the historical gap in on-chain attribution through a set of technical accountability mechanisms embedded within the 12-month framework.

First, we will explore cryptographic transaction attribution methods to make ecosystem impact auditable on-chain using defined metrics. One proposed approach is the introduction of a standardized transaction metadata label unique to the “Catalyze Africa” program, to be integrated across supported projects for smart contract interactions and native asset minting. This would allow transaction volume, wallet activity, and contract usage to be transparently tracked through db-sync tools such as ADAtool, effectively resolving future C8 attribution concerns.

Second, milestone approvals will no longer rely solely on attendance or event metrics. As reflected in the updated Milestones 3 and 4, payouts are tied to public GitHub repositories under open-source licenses containing compiled validator code, transaction schemas, and live testnet or mainnet contract addresses.

Due to char limit, kindly find the latter part of our response in the next reply...

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ef7bedd699758cde5d4a66#comment-6a1095b05141bb70a939db7c
- Summary (EN): Adds Alumni Portfolio Registry under WP2 to track project retention, live dApps, post-incubation funding outcomes — addressing the ecosystem impact measurement gap. Frames the proposal as converting Wada's human network into a verifiable deployment engine.
- Summary (JA): WP2に公開Alumni Portfolio Registryを設置し、プロジェクト継続率・稼働dApp・卒業後資金調達結果を追跡。Wadaの人材ネットワークを検証可能な展開エンジンへ転換するという位置づけで再考を要請。

Full text:

Continuation of our response to your enquiries:
Finally, Work Package 2 will establish a public Alumni Portfolio Registry to track project retention, live dApp deployments, and post-incubation funding outcomes, providing the measurable ecosystem impact metrics being requested.

We agree that ecosystem funding should move beyond process-based reporting. This proposal is intentionally designed to convert Wada’s established human network into a verifiable deployment engine for measurable Cardano utility, and we respectfully ask for reconsideration based on these milestone-driven accountability measures.

#### Feedback 3 — source: twitter, author: adamKDean
- Author note: LIKELY: CATS organizer (proposal is CATS-based); legal proposer is Wada Global
- URL: https://twitter.com/adamKDean/status/2060569388793966641
- Summary (EN): Adam Dean of CATS thanks YUTA for being open to feedback.
- Summary (JA): CATSのAdam DeanがYUTAのフィードバックへの開放性に感謝。

Full text:

@yutazzz @cats_summit Thank you for being open to feedback ♥️

---

## 54. Nula: Cardano's token streaming protocol

- Proposal ID: 69ef91a1985067f4ae957a56
- Requested: 952,750 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69ef91a1985067f4ae957a56
- Category: dApp - DeFi
- Applicable criteria: C1, C5, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Latent demand is plausible, but I want stronger demand evidence.

### Voting reason (JA, as of 2026-05-28)

潜在的な需要を想定できるが、 より強い需要の証拠を確認したい。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO** on Nula: Cardano's token streaming protocol (**952.75K ADA / NCL 0.27%**).

**Main reasons**

**1. Token streaming on other chains has not produced category-defining protocols**
- Token streaming primitives exist as Web3 building blocks: Sablier on Ethereum, Streamflow on Solana.
- **Sablier (Ethereum)**: about $200M historical cumulative TVL across all chains, but fewer than 10K active streams at most points (per Sablier public dashboards) — modest in absolute usage.
- **Streamflow (Solana)**: similar order of magnitude.
- These are useful primitives but not high-volume transaction drivers on any chain.
- Cardano's wallet UX (CIP-30) already allows off-chain payroll / vesting tools (Request, Toku, etc.) — on-chain streaming is not the only option.

**2. Transaction contribution math**
- Per-stream pattern: create (1 tx) + recipient withdrawals (N, typically <10 over the stream's lifetime) + close (1 tx) — order of 5-15 tx per stream lifecycle.
- If Nula reaches Sablier-comparable usage (~10K total streams in Year 1): ~50-150K tx/yr ≈ 4-12K tx/month = 0.5-1.5% of Cardano's ~800K monthly baseline.
- If usage is an order of magnitude lower (typical for a new chain entry): ~1K streams = ~10K tx/yr = ~0.1% of monthly baseline.
- Modest at best, marginal at worst.

**3. "No platform fee" = no Treasury return mechanism**
- Per proposal: "protocol charges no platform fee and captures no value — every transaction pays only the standard Cardano network fee, which flows back to stake pool operators and the treasury".
- Treasury revenue capture is limited to per-tx Cardano network fee (~0.17 ADA × ~50% Treasury share ≈ 0.085 ADA per tx).
- At Year-1 projected 50-150K tx, that is ~4,250-12,750 ADA/yr — versus a 952.75K ADA grant. Break-even ~75-225 years even on the optimistic Sablier-comparable assumption.

**4. Existing Cardano alternatives**
- Vesting and payroll workflows already happen on Cardano via:
  - Custom smart-contract vesting (Indigo, project-specific contracts).
  - Plutus escrow / time-lock contracts.
  - Off-chain payroll → on-chain settlement (current operator practice).
- Nula's unique angle is a standardised streaming primitive — but no named protocol (DEX, lending, DAO) commits to integrate Nula at the proposal stage.

**5. Open-source + patent-free is good but does not anchor demand**
- The proposal's "open-source, patent-free, non-extractive" framing is positive (Sablier had patent and commercial concerns).
- But that does not substitute for a named-adopter demand signal. No Cardano DAO, DEX, or lending protocol commits to Nula integration.

**Recommend NO** (not resubmit) because: (a) no named Cardano DAO / DEX / payroll-using-protocol commits to Nula, (b) transaction-contribution math does not justify 952.75K ADA, (c) the Treasury return mechanism is solely the Cardano network fee, which makes this a pure grant. A resubmission with named DAO / DEX integration commitments could be reconsidered.

### Prior detailed analysis (JA)

**Vote: NO** — Nula: Cardano のトークンストリーミングプロトコル(**952.75K ADA / NCL 0.27%**)に NO。

**主な理由**

**1. 他チェーンの類似プロトコルは「分野を定義するほどの規模」に至っていない**
- トークンストリーミングの基本要素は既に Web3 にある。Ethereum の Sablier、Solana の Streamflow。
- **Sablier(Ethereum)**:全チェーン累積 TVL 約 $200M。ただしアクティブなストリームは多くの時点で 10K 未満(Sablier 公開ダッシュボード)。絶対量は控えめ。
- **Streamflow(Solana)**:同じくらいの規模感。
- 有用な基本要素ではあるが、どのチェーンでも取引量を牽引するカテゴリにはなっていない。
- Cardano のウォレット UX(CIP-30)は、Request や Toku などのオフチェーン給与 / ベスティングツールを利用可能にする。オンチェーンストリーミング以外の選択肢がある。

**2. 取引寄与の試算**
- 1ストリームのパターン:作成(1件)+ 受取側の引き出し(N 件、通常は寿命中 <10 件)+ 終了(1件)。1ストリーム寿命当たり 約 5-15 件。
- Sablier 並み(Y1 で累積 10K ストリーム)なら:年 50-150K 件 ≒ 月 4-12K 件 = Cardano 月次 800K の 0.5-1.5%。
- 桁が1つ下(新チェーン参入の典型)なら:1K ストリーム = 年 10K 件 = 月次 約 0.1%。
- 良くて控えめ、悪ければ周辺的。

**3. 「プラットフォーム手数料なし」= トレジャリーへの還元機構がない**
- 提案書:「プロトコルはプラットフォーム手数料を取らず、価値を捕捉しない。すべての取引は標準の Cardano ネットワーク手数料のみで、それは SPO とトレジャリーに戻る」。
- トレジャリー収益取り込みは件当たりのネットワーク手数料のみ(約 0.17 ADA × トレジャリー分配 約 50% ≒ 件 0.085 ADA)。
- Y1 見込み 50-150K 件で 年 4,250-12,750 ADA。952.75K ADA のグラントに対し、Sablier 並みの楽観前提でも回収 約 75-225 年。

**4. Cardano 上の既存代替**
- ベスティング / 給与の業務は、Cardano 上で既に以下の形で行われている:
  - 独自スマートコントラクトベスティング(Indigo やプロジェクト固有)。
  - Plutus エスクロー / 時間ロック契約。
  - オフチェーン給与 → オンチェーン決済(現状の運用慣行)。
- Nula の独自性は「標準化されたストリーミング基本要素」。しかし提案時点で Nula を統合すると約束した名前付きプロトコル(DEX、レンディング、DAO)がない。

**5. オープンソース + 特許フリーは良いが、需要は固定されない**
- 「オープンソース、特許フリー、非搾取」の枠組みはプラス(Sablier には特許と商用の懸念があった)。
- しかし、それは名前付きの採用シグナルの代替にはならない。Nula 統合を約束した Cardano DAO / DEX / レンディングプロトコルがない。

**NO 推奨**(再提出推奨ではない):(a) Nula 統合を約束した名前付き Cardano DAO / DEX / 給与系プロトコルがない、(b) 取引寄与の試算が 952.75K ADA を正当化しない、(c) トレジャリー還元がネットワーク手数料のみで実質純グラント。名前付き DAO / DEX 統合の約束があれば再検討の余地はある。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 55. Cardano Enterprise Activation Sandbox

- Proposal ID: 69fdbd6381aade1f18481c2e
- Requested: 929,699 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fdbd6381aade1f18481c2e
- Category: BD network
- Applicable criteria: C3, C4, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: [BD network / enterprise sandbox]. Non-applicable: C1 (BD doesn't directly generate Tx), C2 (proposer has track record), C5, C6, C9, C10, C11.

**Applicable: C3, C4, C8**. Applying:

• **C3 — KPI = outcome (mixed)**: Process metrics (intake count, signed pilots, case studies, conversion rate) are valid intermediate BD KPIs by industry convention. The issue is not their inclusion, but the absence of outcome-anchored milestone triggers tied to Cardano Tx/TVL/USD-revenue contribution. The proposal does not specify the % of intake → measurable Cardano outcome.

• **C4 — Treasury return**: Proposal claims contribution to 'Monthly Transactions' but provides no projected tx/month figure, making expected protocol fee return on the 929,699 ADA investment unverifiable. No revenue share or repayment mechanism specified.

• **C8 — Past performance pattern**: In a separate STORM Catalyst proposal, the same proposer's KPI structure assigns 1 point per enterprise receiving a Cardano report — measuring engagement and awareness, not transactions or deployments. This is a weak mechanism for contributing to Cardano's 2030 transaction target.

### Prior detailed analysis (JA)

**分類**: [BD ネットワーク / enterprise sandbox]。 非適用: C1 (BD は直接 Tx 生成せず), C2 (提案者 track record あり), C5, C6, C9, C10, C11。

**適用: C3, C4, C8**。 適用:

・**C3 — KPI = outcome (mixed)**: Process metric (intake 数, signed pilot, case study, conversion rate) は業界慣習で valid な intermediate BD KPI。 含むこと自体ではなく、 Cardano Tx/TVL/USD revenue 寄与に連動した outcome-anchored milestone trigger の欠如が問題。 提案書は intake → measurable Cardano outcome の % を specify せず。

・**C4 — Treasury return**: 'Monthly Transactions' 寄与 claim だが projected tx/月 figure 提示なし、 929,699 ADA 投資への期待 protocol fee return が検証不能。 Revenue share / repayment mechanism specify なし。

・**C8 — 過去 performance pattern**: 同提案者の別 STORM Catalyst 提案では KPI 構造が enterprise が Cardano report 受領 = 1 point — engagement と awareness 測定で transaction や deployment ではない。 Cardano 2030 tx 目標への寄与 mechanism として弱い。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 56. MLabs: Post-quantum signature verification support

- Proposal ID: 69fb5faab05ff80adc7d5c46
- Requested: 758,762 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb5faab05ff80adc7d5c46
- Category: Research / ZK / FV
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Practical research and development for quantum resistance, with broadly positive developer reception.

### Voting reason (JA, as of 2026-05-28)

量子耐性のための実用的な研究と開発、 開発者からの評価も概ね悪くない。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback of a nature that would alter the vote.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback of a nature that would alter the vote.

### Prior detailed analysis (EN)

**Vote: YES** on MLabs: Post-quantum signature verification support (**4.00M ADA / NCL 1.14%**).

**Main reasons**

**1. Addresses CPS-0027 with 5 phased deliverables**

| Phase | Deliverable |
|---|---|
| 1 | Research + comparison report (ML-DSA vs SLH-DSA vs Falcon) with public recommendation |
| 2 | CIP authoring for the recommended scheme's UPLC built-in |
| 3 | Implementation in cardano-base + Plutus Core built-in |
| 4 | Wrappers for Plinth + Plutarch + Aiken (all 3 Cardano smart-contract languages) |
| 5 | Proof-of-concept smart-contract wallet using post-quantum signatures |

- CPS-0027 ("Approaches to Post-Quantum Signatures") is already in final review for merge.
- Phase 1 is explicitly a viability assessment — the right risk sequencing (research before implementation commitment).

**2. Community technical signal: @perturbing approves**
- @perturbing is a recognised Cardano cryptography reviewer. On Ekklesia: "Good proposal :)".
- That is an independent technical endorsement, separate from MLabs's own track record.

**3. Comparable chains have already shipped post-quantum signatures**

| Chain | Post-quantum signature status |
|---|---|
| **Algorand** | shipped |
| Ethereum | proposals in flight |
| Bitcoin | community discussion, no native support |
| **Cardano (this proposal)** | scripts cannot use PQ signatures today; this closes the gap |

"Harvest now, decrypt later" is a real concern for long-lived high-value Cardano assets (treasury holdings, multi-year vesting, RWA tokens). NIST has already standardised the first generation (ML-DSA + SLH-DSA + Falcon) — this is implementable, not research-stage.

**4. Cost benchmark**
- 4.00M ADA across 5 phases ≈ $1.0M USD at ADA $0.25.
- The Phase-1 viability milestone gives a DRep an off-ramp before the larger 4-language wrapper + Plutus Core spend.

**5. C5: scope check versus existing IO Treasury Withdrawals**
- TW #103 IO + VacuumLabs Plutus Enhancement (11.88M ADA) — Plutus Core built-ins generally; post-quantum-specific scope not explicit.
- TW #113 IO Vision 2026 Research (32.9M ADA) — broad research; PQ work could be in scope but is not explicit.
- The proposal should delineate against these — but @perturbing's approval suggests the technical community sees a real gap, not duplication.

**Conditions for YES**: (a) Phase 1 viability assessment must include explicit delineation against IO TW #103 and #113, (b) Phase 1 should be a hard go / no-go gate before Phase 2+ commitment.

Default YES with viability-gate condition — recognised CPS + technical community approval + concrete phased sequencing + comparable-chain precedent (Algorand).

### Prior detailed analysis (JA)

**Vote: YES** — MLabs: 耐量子署名検証サポート(**4.00M ADA / NCL 1.14%**)に YES。

**主な理由**

**1. CPS-0027 への対応 + 5段階の具体的な成果物**

| 段階 | 成果物 |
|---|---|
| 1 | 比較研究レポート(ML-DSA vs SLH-DSA vs Falcon)+ 公開推奨 |
| 2 | 推奨スキームの UPLC ビルトインの CIP 起案 |
| 3 | cardano-base + Plutus Core ビルトイン実装 |
| 4 | Plinth + Plutarch + Aiken 全部のラッパー(Cardano のスマートコントラクト言語3種) |
| 5 | 耐量子署名を使うスマートコントラクトウォレットの実証 |

- CPS-0027(耐量子署名のアプローチ)は既にマージ前最終レビュー段階。
- 段階1は明示的に「実現性評価」。実装着手前に研究、という正しいリスク順序。

**2. コミュニティ技術側のシグナル:@perturbing が支持**
- @perturbing は Cardano 暗号系の認知されたレビュアー。Ekklesia 上で「Good proposal :)」。
- MLabs 自身の実績主張とは独立した、技術側の支持。

**3. 比較対象のチェーンは既に耐量子署名を出荷している**

| チェーン | 耐量子署名の状況 |
|---|---|
| **Algorand** | 出荷済み |
| Ethereum | 複数提案進行中 |
| Bitcoin | 議論中、ネイティブ対応なし |
| **Cardano(本提案)** | スクリプトは現状 PQ 署名を使えない。これがその空白を埋める |

「今盗んで後で解読」は、長期保有の高額 Cardano 資産(トレジャリー、多年ベスティング、RWA トークン)にとって現実の懸念。NIST は第1世代(ML-DSA + SLH-DSA + Falcon)を既に標準化済み。実装可能であり、研究段階ではない。

**4. 単価**
- 5段階で 4.00M ADA ≒ $1.0M USD(ADA $0.25 換算)。
- 段階1の実現性評価は、4言語ラッパーと Plutus Core 実装にコミットする前の撤退点を DRep に与える。

**5. 既存 IO TW との範囲確認**
- TW #103 IO + VacuumLabs Plutus Enhancement(11.88M ADA):Plutus Core ビルトイン全般。PQ 固有は明示されず。
- TW #113 IO Vision 2026 Research(32.9M ADA):広い研究範囲。PQ も入り得るが明示なし。
- 提案者は IO 範囲との切り分けを明示すべき。だが @perturbing の支持は、技術コミュニティが本当に空白を見ていることを示唆する。

**YES の条件**:(a) 段階1の実現性評価で IO TW #103 / #113 との切り分けを明示、(b) 段階1を段階2以降への撤退点(go / no-go)として明確に運用。

認知された CPS + 技術コミュニティの支持 + 段階分け + Algorand などの先例で、撤退点付き YES。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fb5faab05ff80adc7d5c46#comment-6a1e0dde7d5f66c5487662ac
- Summary (EN): Proposer briefly thanks YUTA for the response and vote.
- Summary (JA): 提案者はYUTAの回答と投票に対し簡潔に謝意を述べている。

Full text:

Thank you for your response and vote.

---

## 57. MLabs: Open-Sourcing FeesaSwap as Live Fee Abstraction Infrastructure on Cardano

- Proposal ID: 69f8b983e8a58900f4a05a06
- Requested: 734,730 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8b983e8a58900f4a05a06
- Category: dApp - DeFi
- Applicable criteria: C1, C4, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Information on current usage is lacking; current usage is likely modest. Demand evidence must be supplied.

### Voting reason (JA, as of 2026-05-28)

現在どれほど使用されているのかの情報が不足しており、 おそらくそれほど多く使用されていない可能性がある。 需要の証拠を提示する必要があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; there was a comment that current usage on mainnet is limited, but the specific figures for that are not stated. It appears to suggest, by analogy with Solana and the like, that adoption will come with the passage of time, but I think you need to go one step further and explain why this is simply a "matter of timeframe" (I personally think the matter of timeframe is probably not the essential issue). It would probably be sounder to obtain a certain amount of evidence of adoption first, and then to charge the cost of open-sourcing via an on-chain governance action.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、メインネットでの現在の利用が限定的であるコメントがありましたが、具体的なその数値が記載されていません。Solanaなどとの類推で期間の経過で採用されることが示唆されているように見えますが、単にこれが「期間の長短問題」であるのはなぜか、(おそらくは期間の長短の問題は本質的ではないと思う)について一歩進んだ説明が必要だと思います。一定の採用の証拠を得てから、オンチェーンガバナンスアクションでオープンソース化のコストを請求するほうがおそらく筋が良い可能性があります。

### Prior detailed analysis (EN)

**Vote: NO** on MLabs: Open-Sourcing FeesaSwap as Live Fee Abstraction Infrastructure on Cardano (**687K ADA / NCL 0.20%**).

**Main reasons**

**1. FeesaSwap is currently MLabs's commercial mainnet product**
- Per proposal: FeesaSwap is **"MLabs's live Cardano mainnet fee-abstraction infrastructure (feesaswap.io)"**.
- It runs today as proprietary infrastructure. This proposal converts it to open source and hardens it for ecosystem adoption.
- Treasury is being asked to fund the IP-conversion of an existing commercial product, not greenfield development.

**2. Fee abstraction is a real Cardano gap, but pricing model is unclear**
- Paying Cardano transaction fees only in ADA is a real onboarding friction (stablecoin, bridged-asset, game-token, and RWA users have to acquire ADA first).
- Comparable fee abstraction has been built on Solana (Octane) and on Ethereum L2s via account abstraction.
- But: 687K ADA pays MLabs ~$172K USD at ADA $0.25 for code that already exists in production form.
- Pricing should be evaluated against: (a) net new development cost (small if mostly IP transfer), vs (b) commercial buy-out cost (substantial if Treasury is essentially compensating MLabs for forgone revenue).

**3. Treasury return mechanism is unclear after open-sourcing**
- Once open-sourced, FeesaSwap-derived fee revenue accrues to whoever runs the infrastructure — which may include MLabs and competitors.
- Treasury does not capture any revenue share from FeesaSwap-derived volume.
- The proposal's Treasury benefit claim is the indirect Cardano-tx-fee-in-ADA growth from removing the ADA-pre-acquisition barrier. That is diffuse and hard to attribute.

**4. Who maintains it after the one-shot grant?**
- Once open-sourced, FeesaSwap needs ongoing maintenance (smart-contract bug fixes, fee-quote pricing oracle, integration support).
- This proposal funds the open-source + hardening transition only.
- Year-2 maintenance is not specified. It could become a recurring ask, or MLabs could step away once commercial value is extracted.

**5. Usage metrics are not disclosed**
- FeesaSwap's current usage on Cardano mainnet is not disclosed in the proposal.
- If usage is low, open-sourcing may not change that. If usage is high, the commercial buy-out question becomes more pressing. The proposal does not say either way.

**Recommend NO** because: (a) the IP-conversion pricing model lacks transparency (commercial buy-out vs new public-good development), (b) no named long-term maintainer commitment after open-sourcing, (c) no usage metrics disclosed to anchor the demand claim. A resubmission addressing these could be reconsidered.

### Prior detailed analysis (JA)

**Vote: NO** — MLabs: FeesaSwap のオープンソース化(**687K ADA / NCL 0.20%**)に NO。

**主な理由**

**1. FeesaSwap は MLabs の商用本番製品**
- 提案書より:FeesaSwap は **「MLabs の本番稼働中の Cardano 手数料抽象基盤(feesaswap.io)」**。
- 現状はプロプライエタリ基盤として稼働。本提案はそれをオープンソース化し、エコシステム採用のために安定化する。
- トレジャリーは「既存の商用製品の IP 開放」を求められていて、グリーンフィールド開発ではない。

**2. 手数料抽象は実在の Cardano の空白だが、価格設定が不透明**
- Cardano の手数料が ADA のみは、実在のオンボーディング摩擦(ステーブルコイン、ブリッジ資産、ゲームトークン、RWA の利用者は先に ADA を取得する必要がある)。
- 比較対象は Solana の Octane や Ethereum L2 のアカウント抽象。
- ただし、本番稼働中のコードに対して 687K ADA = MLabs に 約 $172K USD(ADA $0.25 換算)。
- 価格評価軸:(a) 新規開発費(IP 移管が主なら小さい)、vs (b) 商用製品の買い取り(トレジャリーが MLabs に失われる売上を実質補償するなら大きい)、のどちらか。

**3. オープンソース化後のトレジャリーへの還元が不透明**
- オープンソース化後の手数料収入は、基盤を運用する者(MLabs 自身 + 競合を含み得る)に流れる。
- FeesaSwap 由来の取引量からトレジャリーは収益分配を受けない。
- 提案書のトレジャリー便益の主張は「ADA を先に取得する障壁を取り除くことで Cardano の取引手数料(ADA)が間接的に伸びる」というもの。拡散的で帰属が困難。

**4. ワンショットの後、誰が保守するのか**
- オープンソース化された FeesaSwap は継続保守を要する(スマートコントラクトのバグ修正、手数料見積もりオラクル、統合支援)。
- 本提案はオープンソース化と安定化の移行だけを対象。
- Y2 の保守体制は未定義。継続提案になる可能性も、商用価値を抜き取った後 MLabs が手を引く可能性もある。

**5. 利用指標が開示されていない**
- 本番上の FeesaSwap の現状利用指標は、提案書に開示なし。
- 利用が低ければオープンソース化しても変わらない。利用が高ければ商用買い取りの問題が顕在化する。どちらか不明。

**NO 推奨**:(a) IP 開放の価格設定が透明性に欠ける(商用買い取り vs 新規公共財開発)、(b) オープンソース化後の長期保守者の約束がない、(c) 需要主張を裏付ける利用指標が開示されていない。これらに対処する再提出は再検討の余地あり。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8b983e8a58900f4a05a06#comment-6a1e0c5705e47100cbda5c55
- Summary (EN): Proposer directs YUTA to its response posted in the top-level comments.
- Summary (JA): 提案者はトップレベルのコメントに投稿した回答を見るようYUTAに案内している。

Full text:

Hi Yuta, 

Please see our response in the top-level comments we posted.

---

## 58. Infrastructure for Quality Certification and Traceability in the Floriculture Industry

- Proposal ID: 69fc12c1f9ebc26d057f51c8
- Requested: 653,947 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc12c1f9ebc26d057f51c8
- Category: dApp - RWA
- Applicable criteria: C1, C3, C4, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. Of the several pieces of feedback, I think some have been partially addressed, but since I have not been able to confirm the rest, I maintain my NO vote.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。いくつかのフィードバックのうち、一部に部分的に対応されたと思いますが、残りは確認できていないため、NOの投票を維持します。

### Prior detailed analysis (EN)

**Categorisation**: [dApp-RWA / supply chain]. Non-applicable: C2, C5, C6, C7, C10, C11.

**Applicable: C1, C3, C4, C8, C9**. Applying:

• **C1 — Tx KPI claims structurally implausible**: Proposal claims **450K tx Year 1, 1M Year 2, 3-5M Year 3 (annual rates)**. Converting to monthly: Year 1 = 37.5K/month (~4.7% of Cardano 800K monthly baseline), Year 2 = ~83K/month (~10%), Year 3 = 250-417K/month (**31-52% of Cardano monthly baseline**). The Year-3 figure is the implausibility benchmark. Compared to BlackRock BUIDL (~50 tx/month at $147M AUM, per public Etherscan data), generating 37.5K/month from a single Plantec partnership starting month 1 already requires ~1,233 license-issuance operations/day — no evidence presented that single LatAm floriculture propagator's actual operational volume supports this, let alone the Year-3 escalation to 7-10× that rate.

• **C3 — KPI inconsistency**: WP4 sets 'additional 2 LOIs' as a KPI — suggesting the existing Plantec partnership may itself not be on formal commitment basis (i.e., LOI-stage rather than executed contract).

• **C4 — Public-to-private capture**: Treasury funds 653K ADA of development. After WP4 establishes 'commercial fee structure', commercial revenue accrues to proposer; explicit Treasury return = 'No'. Public capital builds infrastructure whose commercial value is privately captured — same asymmetry as Bridge Fund proposal.

• **C8 — Track record domain mismatch**: Proposer's delivered Catalyst track record is in government/electoral domains (blockchain voting system, Atala PRISM voter ID). Floriculture commercial enterprise ERP integration is a different domain. The ASP.NET / C# stack cited in proposal is also distinct from Cardano dApp development mainstream (TypeScript / Aiken). Domain transferability concerns.

• **C9 — Pilot-to-mass-adoption gap**: Multiple Cardano supply chain / traceability proposals have been funded historically via Cardano Foundation and Catalyst, none of which has generated mass adoption tx volume. No evidence presented that floriculture would produce different results.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [dApp-RWA / supply chain]。 非適用: C2, C5, C6, C7, C10, C11。

**適用: C1, C3, C4, C8, C9**。 適用:

・**C1 — Tx KPI 主張は構造的に implausible**: 提案書 claim **Year 1 450K tx、 Year 2 1M、 Year 3 3-5M (年間 rate)**。 月次換算: Year 1 = 37.5K/月 (Cardano 月次 800K baseline の ~4.7%)、 Year 2 = ~83K/月 (~10%)、 Year 3 = 250-417K/月 (**Cardano 月次 baseline の 31-52%**)。 Year-3 figure が implausibility benchmark。 BlackRock BUIDL (~50 tx/月 at $147M AUM, public Etherscan data) と比較し、 Plantec 単一 partnership から月 1 開始で 37.5K/月 生成は既に ~1,233 license-issuance ops/日 必要 — 単一 LatAm 花卉 propagator の実 operational volume がこれを support する evidence なし、 Year-3 で 7-10× へ escalate するなら尚更。

・**C3 — KPI 内部矛盾**: WP4 が 'additional 2 LOIs' を KPI 設定 — 既存 Plantec partnership 自体が formal commitment basis でない (executed contract ではなく LOI-stage) を示唆。

・**C4 — Public-to-private capture**: Treasury が 653K ADA 開発を fund。 WP4 で 'commercial fee structure' 確立後、 commercial revenue は提案者に accrue; 明示的 Treasury return = 'No'。 公的資本が infra build → commercial value privately capture — Bridge Fund 同 asymmetry。

・**C8 — track record 領域不一致**: 提案者の delivered Catalyst track record は government/electoral 領域 (blockchain voting system, Atala PRISM voter ID)。 花卉 commercial enterprise ERP integration は異なる領域。 提案書 cited ASP.NET / C# stack も Cardano dApp development mainstream (TypeScript / Aiken) と distinct。 領域 transferability concern。

・**C9 — pilot-to-mass-adoption gap**: 複数 Cardano supply chain / traceability 提案が歴史的に Cardano Foundation と Catalyst で funded、 いずれも mass adoption tx volume 生成せず。 花卉が異なる結果を生む evidence 提示なし。

よって本提案はこれらを満たさない。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc12c1f9ebc26d057f51c8#comment-6a0be435ceb7fef00be0e48b
- Summary (EN): Updated to distinguish certification/licensing layer from scalable export traceability layer. Clarifies that projected transaction growth is tied to recurring traceability events from real logistics operations, not certificate issuance alone.
- Summary (JA): 認証/ライセンス層とスケーラブルな輸出トレーサビリティ層を区別するよう改訂。txの伸びは証明書発行のみでなく実際の物流オペレーションから発生する継続的なトレーサビリティ・イベントに紐づくと明示。

Full text:

Hi Yuta,

Thanks for the review and detailed rationale.

After analyzing the feedback, I updated the proposal to clarify the distinction between the certification/licensing layer and the scalable export traceability layer. The updated version now explains more clearly that projected transaction growth is associated with recurring traceability events generated through real logistics operations, rather than certificate issuance alone.

Thanks again for the feedback.

---

## 59. Cardano Budget Committee: Budget Process Improvement and Treasury Transparency (2026-2027)

- Proposal ID: 69f22067d699758cde5d4a70
- Requested: 600,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f22067d699758cde5d4a70
- Category: Governance coordination
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Judging from the recent submission status of on-chain governance actions, submitting on-chain governance actions is no longer difficult for builders. Let's consolidate everything into on-chain governance actions and eliminate the Budget process.

### Voting reason (JA, as of 2026-05-28)

最近のオンチェーンガバナンスアクションの提出状況から判断すると、 オンチェーンガバナンスアクションの提出はもはやビルダーにとって難しいものではありません。 すべてをオンチェーンガバナンスアクションに統合し、 Budget process は廃止すべきです。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Cardano Budget Committee: Budget Process Improvement and Treasury Transparency 2026-2027 (**600K ADA / NCL 0.17%**).

**Main reasons**

**1. The Budget Committee operates real governance infrastructure**
- Per proposal: the 2026 budget cycle was "the first to run on a unified, end-to-end platform".
- The Budget Committee is the body that operationalises Treasury withdrawals through DRep governance. Without it, the budget cycle process either reverts to pre-Conway-era handling or moves under another sub-body.
- Cardano's Conway-era treasury governance is only ~12 months old; this is the first end-to-end cycle.

**2. Two concrete work packages**

| WP | Scope | Type |
|---|---|---|
| WP1 | Budget process + tooling improvement | iteration on existing platform |
| WP2 | Treasury transparency + analytics | data-side capability addition |

Iterative improvement of an existing platform is the right pattern (not a greenfield rewrite). Treasury transparency and analytics directly support a DRep's ability to vote informed.

**3. Small ask anchored to governance work**
- 600K ADA ≈ $150K USD at ADA $0.25.
- For 12 months of platform + analytics work, this is sub-maintenance-class rate.
- Smallest of the Intersect Budget #69 proposals.

**4. Explicit non-overlap with main Intersect MBO budget**
- Per proposal: execution is contingent on Intersect MBO budget approval; the proposer would withdraw this proposal if MBO fails.
- The Budget Committee is a sub-body within Intersect — funding here is incremental scope, not duplicative.

**5. The meta-governance role itself**
- The Budget Committee's existence enables DRep oversight of all other Treasury withdrawals.
- Refusing to fund the Budget Committee while continuing to ratify other Treasury withdrawals through it would be operationally inconsistent.

**6. Direct DRep-side data value**
- WP2 (Treasury transparency + analytics) directly serves DReps who must vote on Treasury withdrawals.
- Better budget tooling → better governance decisions. This proposal's return on investment is governance-infrastructure ROI, not direct-transaction ROI.

Default YES — small ask + meta-governance infrastructure + iterative improvement on existing platform + contingent on MBO approval.

### Prior detailed analysis (JA)

**Vote: YES** — Cardano Budget Committee: 予算プロセス改善とトレジャリー透明性 2026-2027(**600K ADA / NCL 0.17%**)に YES。

**主な理由**

**1. 予算委員会は実在のガバナンス基盤を運営**
- 提案書より:2026 年予算サイクルは「初めて統合されたエンドツーエンドのプラットフォームで運用された」。
- 予算委員会は、DRep ガバナンス経由のトレジャリー出金を実運用する本体。これがなければ予算サイクルは Conway 以前の方式に戻るか、別のサブ本体下に移ることになる。
- Cardano の Conway 期トレジャリーガバナンス自体がまだ約 12 か月で、本サイクルが最初のエンドツーエンド。

**2. 具体的な2つの作業項目**

| WP | 範囲 | 種類 |
|---|---|---|
| WP1 | 予算プロセス + ツールの改善 | 既存プラットフォームの反復改善 |
| WP2 | トレジャリー透明性 + 分析 | データ側機能の追加 |

既存プラットフォームの反復改善は正攻法(ゼロから作り直しではない)。透明性と分析は、DRep が情報に基づいて投票する能力を直接支える。

**3. ガバナンス作業に紐付いた小さい要求**
- 600K ADA ≒ $150K USD(ADA $0.25 換算)。
- 12 か月のプラットフォーム + 分析の作業に対し、保守クラス未満の単価。
- Intersect Budget #69 提案中もっとも小さい。

**4. 主 Intersect MBO 予算との非重複が明示**
- 提案書より:実行は Intersect MBO 予算の承認に連動。MBO が落ちれば本提案は取り下げ。
- 予算委員会は Intersect 内のサブ本体。ここでの資金は追加範囲であり、重複ではない。

**5. メタガバナンスとしての役割**
- 予算委員会の存在自体が、他のトレジャリー出金への DRep 監督を可能にする。
- 予算委員会を介してトレジャリー出金を批准し続けながら、予算委員会への資金を拒むのは運用上一貫しない。

**6. DRep 側へのデータ価値**
- WP2(透明性 + 分析)は、トレジャリー出金を投票する DRep を直接支える。
- 予算ツールの改善 → ガバナンス決定の質向上。本提案の ROI はガバナンス基盤 ROI で、直接の取引 ROI ではない。

小さい要求 + メタガバナンス基盤 + 既存プラットフォームの反復改善 + MBO 承認に連動で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 60. Full Integration of CIP-113 with Clear Signing across Ledger Products

- Proposal ID: 69fd6b34f9ebc26d057f51d8
- Requested: 556,200 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd6b34f9ebc26d057f51d8
- Category: Wallet / hardware
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

CIP-113 demand has not yet been demonstrated at the mainnet level. Device-level development support may be premature.

### Voting reason (JA, as of 2026-05-28)

CIP-113 の需要はメインネットレベルでまだ実証されていません。 デバイスレベルの開発対応は早すぎる可能性があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Full Integration of CIP-113 with Clear Signing across Ledger Products (**92.7K ADA / NCL 0.03%**).

**Main reasons**

**1. CIP-113 is the agreed token standard; this is the device-level layer**
- CIP-113 is the Programmable Tokens standard, launched by the Cardano Foundation in March 2026. It covers on-chain compliance and transfer logic.
- Without Ledger-device support for CIP-113, every token in this category (regulated stablecoins, RWA tokens, payroll tokens) can only be blind-signed on hardware wallets.
- Scope: Ledger Signer + Ledger Live + Ledger Enterprise — the full Ledger product line.
- **Budget = 92.7K ADA / NCL 0.03%** — small, complementary to the other two Ledger SAS proposals.

**2. The protocol-layer piece of the three-proposal stack**

| Layer | Proposal | Budget |
|---|---|---|
| **Protocol (this)** | CIP-113 across Ledger Products | **92.7K ADA** |
| dApp adoption | Top-5 dApps clear signing + Ledger Button | 3.46M ADA |
| Vendor maintenance | Cardano app on Ledger by Ledger SAS | 2.06M ADA |

Without device-level CIP-113 support, dApps can emit CIP-113 metadata but the device still shows opaque CBOR — the other two proposals' safety goal remains incomplete.

**3. Cost is at maintenance rates**
- 92.7K ADA across 3 products = ~30.9K ADA per product. Comparable to per-product Ledger app maintenance rates.

**4. No alternative is funded**
- Vendor-specific safe-signing formats exist historically but produce fragmented UX. CIP-113 is the agreed standard. No alternative Treasury Withdrawal or Catalyst funding covers Ledger-side CIP-113.

**Conclusion**: At 92.7K ADA, this is the smallest and most leveraged piece of the three-proposal Ledger stack — the highest-confidence YES in the bundle.

### Prior detailed analysis (JA)

**Vote: YES** — Ledger 全製品への CIP-113 統合(**92.7K ADA / NCL 0.03%**)に YES。

**主な理由**

**1. CIP-113 はエコシステムで合意された標準。これは機器側の実装層**
- CIP-113 はプログラム可能トークンの標準。2026年3月に Cardano Foundation が公開。コンプライアンスや転送ロジックをオンチェーンに持つ。
- Ledger 側で CIP-113 に対応しないと、規制対応のステーブルコイン、RWA トークン、給与トークンなど CIP-113 カテゴリ全部が、ハードウェアウォレットでは盲目署名のみになる。
- 対象:Ledger Signer + Ledger Live + Ledger Enterprise(Ledger の全製品ライン)。
- **予算 92.7K ADA / NCL 0.03%** — 小さく、他の2つの Ledger SAS 提案と補完関係にある。

**2. 3提案セットのうち、プロトコル層**

| 層 | 提案 | 予算 |
|---|---|---|
| **プロトコル(本提案)** | Ledger 全製品への CIP-113 統合 | **92.7K ADA** |
| dApp 採用層 | Top 5 dApp clear signing + Ledger Button | 3.46M ADA |
| ベンダー保守 | Ledger SAS による Cardano アプリ保守 | 2.06M ADA |

機器側で CIP-113 を実装しないと、dApp が CIP-113 メタデータを出しても機器側は依然として生 CBOR を表示する。他2提案の安全目標が成立しない。

**3. 単価は保守クラス**
- 92.7K ADA / 3 製品 = 製品当たり約 30.9K ADA。Ledger アプリの保守単価として相場。

**4. 代替の資金はない**
- ベンダー独自の安全署名スキームは過去にあるが、UX が分断する。CIP-113 は合意された標準で、Ledger 側 CIP-113 対応に対する他の Treasury Withdrawal や Catalyst 資金はない。

**結論**:92.7K ADA で、3提案 Ledger セット中もっとも小さく、もっとも効果が大きい。セット中、最も自信を持って YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 61. Oura by TxPipe: Maintaining Cardano's Event Pipeline

- Proposal ID: 69f9dabb92f043aa2df1a282
- Requested: 540,750 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f9dabb92f043aa2df1a282
- Category: Infrastructure / SDK
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Broad demand and adoption are verifiable.

### Voting reason (JA, as of 2026-05-28)

広い需要と採用を確認できる。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Oura by TxPipe: Maintaining Cardano's Event Pipeline (**540.75K ADA / NCL 0.15%**).

**Main reasons**

**1. Part-time maintainer at $105K USD/yr — market-grade rate**
- 420,000 ADA + 105,000 ADA contingency = 525K ADA.
- At ADA ~$0.25, 420K ADA ≈ $105K USD = the stated annual part-time rate. The contingency covers ADA price risk.
- That rate is materially below the full-time market for senior Rust + Cardano protocol expertise.

**2. Oura adoption is publicly verifiable**
- Per proposal: github.com/txpipe/oura has **654 commits, 288 stars, 79 forks, 58 contributors** — the most-starred TxPipe project.
- Funded twice through Catalyst (Funds 9 and 13) for feature development. This proposal moves the project into a maintenance cycle.
- Built on Pallas. Supports many sources (N2C, N2N, S3, Mithril, UTxO RPC) and many sinks (Kafka, Elasticsearch, AWS Lambda/S3/SQS, RabbitMQ, Redis, SQL, webhooks).

**3. TxPipe team-level delivery record**
- Per ADAtool /tx-roi: TxPipe cumulative = 26 Catalyst + 663K TW = 4.53M ADA.
- Per Intersect TW: TxPipe Year-1 bundle = 9 of 10 milestones delivered, 337K ADA disbursed.

**4. Not a duplicate of cardano-db-sync**
- cardano-db-sync produces a relational PostgreSQL snapshot.
- Oura produces real-time typed event streams (Kafka / NATS / Webhook / STDOUT).
- Different products for different needs. No active Treasury Withdrawal funds a competing event-streaming maintainer.

**5. Compared to letting it fork**
- 525K ADA centralised vs. 58 contributors independently maintaining CBOR parsing, sink throughput, and hard-fork compatibility for their own forks. Centralised maintenance is cheaper.

Default YES — part-time maintainer model + verifiable adoption (288 stars / 58 contributors) + 90% Year-1 delivery.

### Prior detailed analysis (JA)

**Vote: YES** — Oura by TxPipe(**540.75K ADA / NCL 0.15%**)に YES。

**主な理由**

**1. パートタイム保守体制で $105K USD/年 — 相場以下**
- 420,000 ADA + 105,000 ADA の予備 = 525K ADA。
- ADA $0.25 換算で 420K ADA ≒ $105K USD。提案通りのパートタイム年俸と一致する。予備分は ADA 価格変動の備え。
- シニア Rust + Cardano プロトコル知識のフルタイム相場より明確に安い。

**2. Oura の採用は公開数値で確認できる**
- 提案書より:github.com/txpipe/oura に **コミット 654、Star 288、Fork 79、貢献者 58**。TxPipe ポートフォリオ中で最も Star が多い。
- 過去 Catalyst(Fund 9 と 13)で2回機能開発に資金。本提案で保守サイクルに移行。
- Pallas の上に構築。複数の入力(N2C、N2N、S3、Mithril、UTxO RPC)と複数の出力(Kafka、Elasticsearch、AWS Lambda/S3/SQS、RabbitMQ、Redis、SQL、Webhook)に対応。

**3. TxPipe の納品実績(チーム単位)**
- ADAtool /tx-roi:TxPipe 累積 = Catalyst 26件 + TW 663K = 4.53M ADA。
- Intersect TW:TxPipe Y1 バンドル = 10件中9件完了、337K ADA 受領。

**4. cardano-db-sync の重複ではない**
- cardano-db-sync は PostgreSQL のスナップショット型出力。
- Oura は型付きリアルタイムイベントストリーム(Kafka / NATS / Webhook / STDOUT)。
- 用途が違う別物。競合するイベントストリーミング保守者に対する Treasury 資金はない。

**5. もし保守をやめてフォークさせると**
- 525K ADA で集中保守する代わりに、58人の貢献者が各自で CBOR 解析、出力スループット、ハードフォーク対応を担うことになる。集中保守の方が安い。

パートタイム体制 + 公開数値で確認できる採用 + Y1 90% 達成で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 62. UTxO RPC by TxPipe: Maintaining Cardano's Integration Standard, Year 2

- Proposal ID: 69f9d3db0a4abf2b3c1da737
- Requested: 540,750 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f9d3db0a4abf2b3c1da737
- Category: Infrastructure / SDK
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Broad demand and adoption are verifiable.

### Voting reason (JA, as of 2026-05-28)

広い需要と採用を確認できる。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on UTxO RPC by TxPipe: Maintaining Cardano's Integration Standard, Year 2 (**540.75K ADA / NCL 0.15%**).

**Main reasons**

**1. UTxO RPC is the integration standard used by multiple Cardano node implementations**
- Per proposal: adopted by **Amaru, Dingo, and the Haskell Cardano node** — three independent node implementations use UTxO RPC as the canonical gRPC interface.
- Maintains **10+ repositories** covering the core spec + SDKs in Rust, Go, Node.js, .NET, Haskell, and Python.
- Apache 2.0 licensed.
- Pallas (the underlying Rust library) has **214,446 downloads on crates.io** — a concrete adoption metric.

**2. Year-1 delivery already disbursed under Intersect TW**
- Per Intersect TW (2026-05-10): TxPipe Year-1 bundle = 9 of 10 milestones delivered, 337K ADA disbursed.
- This Year-2 ask is the direct continuation. Proposer states the new grant period begins after the existing contract closes.

**3. Cost structure: part-time maintainer at $105K USD/yr**
- 420K ADA + 105K ADA contingency = 525K ADA.
- Cost across the 10+ repos and 6 SDK languages = $15-17K USD per supported language-binding per year — well below the cost of rebuilding from scratch.

**4. Compared to letting each consumer maintain its own copy**

| Scenario | Rough cost |
|---|---|
| Continue central maintenance (this proposal) | 525K ADA / yr |
| Amaru self-maintains its UTxO RPC binding | ~$30K / yr |
| Dingo self-maintains its UTxO RPC binding | ~$30K / yr |
| Haskell node self-maintains | ~$30K / yr |
| Spec drift across 3 forks | hard to quantify, large |
| 6 SDK language matrix splits across consumers | $50-100K duplication |

Central maintenance at 525K ADA/yr is cheaper than the abandonment alternative.

**5. No competing Cardano integration standard**
- UTxO RPC is the canonical spec. Blockfrost (TW #104, 7.92M ADA) is a hosted API service, not a protocol specification — different layer.

Default YES — established standard + 3 named adopters + 90% Year-1 delivery + part-time rate.

### Prior detailed analysis (JA)

**Vote: YES** — UTxO RPC by TxPipe(Year 2、**540.75K ADA / NCL 0.15%**)に YES。

**主な理由**

**1. 複数の Cardano ノード実装が採用する統合標準**
- 提案書より:**Amaru、Dingo、Haskell 版 Cardano ノード** が UTxO RPC を gRPC インタフェースとして採用。3つの独立した実装に使われている。
- 中核仕様 + Rust、Go、Node.js、.NET、Haskell、Python の SDK で **10以上のリポジトリ** を維持。
- Apache 2.0 ライセンス。
- 基盤の Pallas ライブラリは crates.io で **214,446 ダウンロード** — 採用の具体的な指標。

**2. Year 1 は Intersect TW のもとで既に納品済み**
- Intersect TW(2026-05-10):TxPipe Y1 バンドル = 10件中9件完了、337K ADA 受領。
- 本 Y2 は直接の継続。既存契約終了後に新グラント期間を開始する旨を明記。

**3. 単価:パートタイム保守 $105K USD/年**
- 420K ADA + 105K ADA 予備 = 525K ADA。
- 10以上のリポジトリと6言語の SDK に対して、対応言語当たり年 $15-17K USD。ゼロから作り直す費用よりはるかに安い。

**4. 各利用者が自前で持つ場合との比較**

| 想定 | 概算 |
|---|---|
| 集中保守を継続(本提案) | 年 525K ADA |
| Amaru が UTxO RPC バインディングを自前保守 | 年 約 $30K |
| Dingo が自前保守 | 年 約 $30K |
| Haskell ノードが自前保守 | 年 約 $30K |
| 3 フォーク間の仕様ずれ | 定量化困難、大きい |
| 6 言語の SDK が利用者ごとに分裂 | 重複費用 $50-100K |

集中保守の方が、放棄した場合より安い。

**5. 競合する Cardano 統合標準はない**
- UTxO RPC が事実上の標準。Blockfrost(TW #104、7.92M ADA)はホスト型 API サービスで、プロトコル仕様ではない。層が違う。

確立した標準 + 名前付きの3採用者 + Y1 90% 達成 + パートタイム単価で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 63. Dolos by TxPipe: Maintaining Cardano's Lightweight Data Node, Year 2

- Proposal ID: 69f9ca0e4b815ecdc8d91a17
- Requested: 540,750 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f9ca0e4b815ecdc8d91a17
- Category: Infrastructure / SDK
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Broad demand and adoption are verifiable.

### Voting reason (JA, as of 2026-05-28)

広い需要と採用を確認できる。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Dolos by TxPipe: Maintaining Cardano's Lightweight Data Node, Year 2 (**540.75K ADA / NCL 0.15%**).

**Main reasons**

**1. Dolos provides 5 query interfaces in one lightweight Rust node**
- **Mini-Blockfrost** (HTTP REST)
- **UTxO-RPC** (gRPC)
- **Mini-Kupo** (pattern-matching UTxO queries)
- **Ouroboros N2C unix socket** (cardano-cli + Ogmios compatible)
- Plus base UTxO and ledger primitives
- All at a fraction of full-node resource usage.
- Project metrics: 939 commits, 80 releases, 129 stars, 51 forks, 27 contributors.

**2. Multi-client Cardano resilience**
- Cardano's resilience plan calls for multiple node implementations.
- This is similar in spirit to Ethereum client diversity (geth / besu / erigon / nethermind / lighthouse).
- Dolos sits at the lightweight tier — an alternative to running a full cardano-node for read-heavy, indexer, or developer workflows.

**3. Part-time maintainer cost vs the alternatives**
- 420K ADA + 105K contingency = 525K ADA / yr ($105K USD/yr part-time).
- Replacing Dolos's 5-interface surface with individual operators would mean 5+ teams each running their own indexer pipeline. Duplication cost is high.

**4. Year-1 delivery (TxPipe bundle 90%)**
- Per Intersect TW: TxPipe Year-1 bundle = 9 of 10 milestones delivered, 337K ADA disbursed.
- Dolos's Year-1 maintenance milestones are part of that delivered cohort. Year-2 is a direct continuation.

**5. Alternative implementations are not duplication**
- Multi-client Cardano explicitly wants alternative node implementations.
- Dolos differs from full cardano-node on resource footprint and from Pallas (raw library) by providing an operational query surface. No active Treasury Withdrawal funds a competing lightweight indexer-node.

**Conclusion**: 939-commit / 80-release project + 5 query interfaces + part-time rate + 90% Year-1 delivery → default YES.

### Prior detailed analysis (JA)

**Vote: YES** — Dolos by TxPipe(Year 2、**540.75K ADA / NCL 0.15%**)に YES。

**主な理由**

**1. 軽量 Rust ノードに5つの問い合わせインタフェース**
- **Mini-Blockfrost**(HTTP REST)
- **UTxO-RPC**(gRPC)
- **Mini-Kupo**(パターンマッチング UTxO 問い合わせ)
- **Ouroboros N2C unix ソケット**(cardano-cli + Ogmios 互換)
- そのほか UTxO / 台帳の基本機能
- フルノードに比べリソース消費はごく一部。
- プロジェクト指標:コミット 939、リリース 80、Star 129、Fork 51、貢献者 27。

**2. マルチクライアント Cardano の冗長性**
- Cardano の冗長化方針は複数のノード実装を求めている。
- 思想は Ethereum のクライアント多様性(geth / besu / erigon / nethermind / lighthouse)に近い。
- Dolos は軽量層を担う。読み取り中心、インデクサー、開発用途で、フルノードの代替になる。

**3. パートタイム保守単価と、代替の比較**
- 420K ADA + 105K 予備 = 年 525K ADA(パートタイム $105K USD/年)。
- 5つのインタフェースを個別運用者で代替すると、5+ チームが各自のインデクサーパイプラインを保守する必要がある。重複費用が大きい。

**4. Year 1 の納品実績(TxPipe バンドル 90%)**
- Intersect TW:TxPipe Y1 バンドル = 10件中9件完了、337K ADA 受領。
- Dolos の Y1 保守マイルストーンはこの完了群に含まれる。Y2 はその直接の継続。

**5. 別実装は重複ではない**
- マルチクライアント Cardano は別実装を望んでいる(戦略目標)。
- Dolos はフル cardano-node とリソース消費で差別化、Pallas(生ライブラリ)と「運用可能な問い合わせ面を提供する」点で差別化。競合する軽量インデクサーノードに対する Treasury 資金はない。

**結論**:939コミット・80リリースの実績 + 5インタフェース + パートタイム単価 + Y1 90% 達成で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 64. Pallas by TxPipe: Maintaining Cardano's Core Rust Libraries, Year 2

- Proposal ID: 69f8c6dec9c351b28aa8d7b8
- Requested: 540,750 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f8c6dec9c351b28aa8d7b8
- Category: Infrastructure / SDK
- Applicable criteria: C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Already widely adopted.

### Voting reason (JA, as of 2026-05-28)

すでに幅広い採用があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on Pallas by TxPipe: Maintaining Cardano's Core Rust Libraries, Year 2 (**540.75K ADA / NCL 0.15%**).

**Main reasons**

**1. Pallas is the foundation under the entire Rust Cardano stack — adoption is measurable**
- Per proposal: **649 pull requests, 199 stars, 91 forks, 60 contributors, 214,446 downloads on crates.io**.
- Named downstream projects cited: **Aiken, Dolos, Lucid, Oura, Mithril, Amaru**.

**2. What discontinuing Pallas would cost**

| Project | What it depends on Pallas for |
|---|---|
| **Aiken** (smart-contract language) | CBOR + ledger primitives |
| **Amaru** (Rust Cardano node) | full primitive stack |
| **Mithril** (stake-based certification) | cryptographic + ledger primitives |
| **Dolos** (lightweight node) | full primitive stack |
| **Oura** (event pipeline) | CBOR parsing + mini-protocol |
| **Lucid** (TypeScript SDK off-chain) | shared primitives |

Discontinuing would force each of these to either maintain its own copy of CBOR / cryptography / mini-protocol code (large duplication), or coordinate a community fork with overhead larger than 525K ADA per year.

**3. Cost per downstream consumer**
- 525K ADA / 6 named downstreams = ~87.5K ADA each. At ADA $0.25 that's ~$22K USD per downstream per year — far below the cost of self-maintaining the same code.

**4. Year-1 delivery evidence**
- Per ADAtool /tx-roi: TxPipe cumulative = 4.53M ADA across 26 Catalyst + 663K TW.
- Per Intersect TW: TxPipe Year-1 bundle = 9 of 10 milestones delivered, 337K ADA disbursed. Year-1 delivery ratio 90%.

**5. The only canonical Rust Cardano library at this layer**
- No competing Rust Cardano foundational library exists at this layer. Any "competitor" would be a fork of Pallas itself.

**Conclusion**: Foundational + measurable adoption (214,446 crates.io downloads) + 6 named downstreams + 90% Year-1 delivery → highest-confidence YES in the TxPipe Year-2 bundle.

### Prior detailed analysis (JA)

**Vote: YES** — Pallas by TxPipe(Year 2、**540.75K ADA / NCL 0.15%**)に YES。

**主な理由**

**1. Rust Cardano スタック全体の土台。採用は数値で確認できる**
- 提案書より:**プルリクエスト 649、Star 199、Fork 91、貢献者 60、crates.io ダウンロード 214,446**。
- 提案書で名前を挙げた下流プロジェクト:**Aiken、Dolos、Lucid、Oura、Mithril、Amaru**。

**2. もし保守をやめた場合の費用**

| プロジェクト | Pallas に依存している部分 |
|---|---|
| **Aiken**(スマートコントラクト言語) | CBOR + 台帳プリミティブ |
| **Amaru**(Rust 版 Cardano ノード) | プリミティブ群全体 |
| **Mithril**(ステーク証明) | 暗号 + 台帳プリミティブ |
| **Dolos**(軽量ノード) | プリミティブ群全体 |
| **Oura**(イベントパイプ) | CBOR 解析 + mini-protocol |
| **Lucid**(TypeScript SDK) | 共有プリミティブ |

保守をやめると、各プロジェクトは (a) CBOR・暗号・mini-protocol コードを自前で複製して維持する(重複費用が大きい)、または (b) コミュニティのフォークを調整する(年 525K ADA を上回る調整費用がかかる)、のいずれかになる。

**3. 下流プロジェクト当たりの費用**
- 525K ADA / 6 下流 = 各 約 87.5K ADA。ADA $0.25 換算で年 約 $22K USD/下流。自前保守のコストよりはるかに安い。

**4. Year 1 実績**
- ADAtool /tx-roi:TxPipe 累積 = Catalyst 26件 + TW 663K = 4.53M ADA。
- Intersect TW:TxPipe Y1 バンドル = 10件中9件完了、337K ADA 受領。Y1 達成率 90%。

**5. この層では唯一の Rust Cardano ライブラリ**
- 同じ層に競合する Rust Cardano 基盤ライブラリは存在しない。「競合」は Pallas 自身のフォークしかない。

**結論**:基盤 + 数値で確認できる採用(crates.io ダウンロード 214,446)+ 名前付きの下流6つ + Y1 90% 達成。TxPipe Y2 バンドル中もっとも自信を持って YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 65. Civics Committee Governance Expert Led, Sustainable Education Program

- Proposal ID: 69fa68b4b05ff80adc7d5c41
- Requested: 442,900 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa68b4b05ff80adc7d5c41
- Category: Education
- Applicable criteria: C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response. I can understand the logic that this should be judged by whether the proposal is cost-efficient, rather than by comparing it with what I consider to be other priorities; but even so, I still do not think it is cost-efficient at this point. Hardly any past governance workshop has had a good reputation, and I myself do not have a good impression of them. This is not limited to those hosted by Intersect; it also includes ones hosted by other entities and cases where I myself have been involved in hosting. I have this impression including the series of constitution workshops. I think producing meaningful outcomes in a governance workshop requires a high level of skill. The Civics Committee is a fluid organization. I think it is necessary to fix and appoint a responsible person whom one can believe capable of efficiently managing the execution of this.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます。その他の優先事項と私が考えるものと比較するのではなく、この提案書がコスト効率に優れているかどうかで判定すべきというロジックは理解できますが、同時に、その上でもやはりコスト効率が良いとは今のところ思えていません。過去のいかなるガバナンスワークショップもほとんど良い評判はなく、私自身も良い印象はありません。これはInetersectが主催のものに限らず、他のエンティティ主催のものや、私自身が主催に関与しているケースも含みます。一連の憲法ワークショップを含めてその印象があります。ガバナンスワークショップで意味のある成果を出すには、高いスキルが要求されると思います。シビック委員会は流動的な組織です。これの効率的な実行管理をしうると信じられる責任者を固定して任命する必要があると思います。

### Prior detailed analysis (EN)

**Categorisation**: [Education / governance]. Non-applicable: C1, C2 (Civics Committee has track record), C3 (education milestones legitimately are workshop count), C4, C5, C6, C7, C9, C10, C11.

**Applicable: C8 (sole)**. Applying:

• **C8 — Adding governance education does not address the actual governance bottlenecks**: Cardano's governance work has been heavily funded already — Cardano Foundation, Intersect, EMURGO continuous outreach; multiple Catalyst-funded DRep education proposals across F4-F12; Civics Committee's own Constitutional Workshop Series. Tools, research, content, motivated community are all abundantly supplied. Yet the headline governance metrics haven't moved — registered DReps are a minimal fraction of ADA holders, active voting DReps are an even smaller subset, and >50% of staking ADA remains in default auto-abstain. Adding more of the same supply doesn't fix this because **the actual bottlenecks are elsewhere**, and both are outside this proposal's scope:

  **(a) End-user wallet UIUX for delegation** — Moving stake out of auto-abstain default requires improving how wallet users discover DRep options, review DRep rationale, and switch delegation. **Only wallet providers (Eternl, Lace, Daedalus, Vespr, Begin, NuFi, Tokeo, Yoroi, etc.) control this layer**. An education program has no authority over wallet front-ends — workshop attendees, no matter how well-trained, still hit the same UIUX friction when they try to delegate.

  **(b) DRep-to-DRep consensus building** — Cardano governance has many DReps holding fundamentally different views and values. Improving governance means finding compromise positions across those gaps — proposal by proposal, vote by vote. This is **slow, manual, relationship-based negotiation work** that happens via X DMs, Telegram, Discord side-channels, in-person events, 1-on-1 calls. Adding more educated DReps doesn't substitute for the actual sit-down-and-negotiate effort — and there's no shortage of motivated participants today; the gap is in the consensus-finding process itself.

  The proposal's expected outcomes ('25+ new DReps, 60%+ delegation intent') therefore lack a credible causal pathway to actual governance improvement. Even if the workshop produces engaged graduates, they hit (a) wallet UIUX friction when delegating and (b) the DRep-consensus negotiation gap as they participate. More workshop cohorts do not change either.

Therefore this proposal does not satisfy this criterion.

### Prior detailed analysis (JA)

**分類**: [教育 / governance]。 非適用: C1, C2 (Civics Committee track record あり), C3 (教育 milestone は workshop 数で正当), C4, C5, C6, C7, C9, C10, C11。

**適用: C8 (単独)**。 適用:

・**C8 — Governance 教育の追加は真の governance bottleneck に対処していない**: Cardano の governance work は既に heavily funded — Cardano Foundation, Intersect, EMURGO の継続的 outreach; F4-F12 横断の Catalyst-funded DRep 教育提案複数; Civics Committee 自身の Constitutional Workshop Series。 Tool、 research、 content、 意欲的 community は全て潤沢に供給済。 ところが headline governance metric は動いていない — registered DRep は ADA holder の少数、 active voting DRep はさらに少数、 staking ADA の >50% は default auto-abstain のまま。 同種の supply を追加してもこれは fix されない。 **真の bottleneck は別の場所にあり、 両方とも本提案の scope 外**:

  **(a) End-user wallet の UIUX (delegation flow)**: Auto-abstain default から stake を移動させるには、 wallet user がどう簡単に DRep option を発見し、 DRep rationale を review し、 委任を切り替えられるかという wallet UI/UX を改善する必要。 **これを control できる layer は wallet provider のみ (Eternl, Lace, Daedalus, Vespr, Begin, NuFi, Tokeo, Yoroi 等)**。 教育 program は wallet front-end への authority を持たない — workshop 参加者がどれだけよく訓練されても、 委任しようとした時に同じ UIUX friction に当たる。

  **(b) DRep 間 consensus building**: Cardano governance は根本的に異なる考え方と価値観を持つ DRep が多数。 governance 改善とは、 提案毎・投票毎にそのギャップを跨ぐ compromise position を見つけていくこと。 これは **slow で manual で関係性ベースの交渉作業** で、 X DM、 Telegram、 Discord side-channel、 オフライン event、 1-on-1 通話で行われる。 教育を受けた DRep を増やすことは実際の sit-down-and-negotiate 作業を代替しない — そして今日 motivated participant が不足しているわけではない; gap は consensus-finding process そのもの。

  提案書の期待 outcome ('25+ new DRep, 60%+ delegation intent') は、 実際の governance 改善への credible な causal pathway を欠く。 仮に workshop が engaged な卒業生を生んでも、 彼らは委任時に (a) wallet UIUX friction に当たり、 参加すれば (b) DRep-consensus 交渉 gap に当たる。 workshop cohort を増やしてもどちらも変わらない。

よって本提案はこの criterion を満たさない。

### Proposer feedback (3)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa68b4b05ff80adc7d5c41#comment-6a18581205e47100cbda5c45
- Summary (EN): Concedes wallet UX and DRep negotiation are real bottlenecks but argues education is a necessary input even if not sufficient — both delegators and DReps need shared baseline knowledge (constitution, CIP-1694) to navigate the experience and consensus work.
- Summary (JA): ウォレットUXとDRep間交渉が真のボトルネックである点は同意。ただし教育は十分条件ではなくとも必要条件であり、委任者もDRepも憲法・CIP-1694等の共通知識基盤がなければ体験や合意形成に到達できないと反論。

Full text:

@yuta.zzz

1

Thank you for engaging with the proposal in detail. Having read your rationale for our specific proposal on adatool.net/b69-share, we want to respond directly to your core argument, as we think you have identified something important.

We will break the responses down over a number of posts due to CHAR limit restrictions.

Your central claim, as we read it, is that Cardano's governance bottlenecks are (a) wallet UI/UX for delegation and (b) DRep-to-DRep consensus building, and that neither is addressable by an education program. You conclude that more educated DReps still hit the same friction points.

You are substantially right on both bottlenecks. We do not dispute that wallet UI/UX shapes delegation behaviour, or that consensus-building is relationship work that no workshop can substitute for. Where we would push back is on the implication that education therefore has no causal pathway to governance improvement.

Three points for your consideration:

**1. The bottleneck framing is incomplete.** Wallet UI/UX and DRep negotiation matter, but they are not the only constraints. Even a perfect wallet UI does not help an Ada holder who does not understand what they are delegating or to whom. Even ideal DRep negotiation does not help if DReps lack shared baseline knowledge of the constitution, CIP-1694, or other relevant context to negotiate over. Education is not sufficient for governance improvement, but it is a necessary input for both the wallet user experience and the DRep negotiation process to produce informed outcomes. The question is not whether education alone fixes governance, it is whether the marginal ADA spent on this proposal produces enough informed participation to be worth the cost relative to alternatives.

#### Feedback 2 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa68b4b05ff80adc7d5c41#comment-6a18584b038cf72ed1e64f09
- Summary (EN): Empirical pushback: prior constitutional convention workshops generated ~230 new DRep registrations per 12-epoch period — non-trivial against small base. The proposed program adds pre/post assessments, behaviour-intent surveys and opt-in wallet linking so causal claims can be tested. 45% of budget builds a reusable Governance Workshop Portal + open-source curriculum.
- Summary (JA): 実証的反論: 過去の憲法制定ワークショップは12エポックあたり約230名のDRep新規登録を生み、小さなDRep母集団に対しては有意。本提案ではpre/post評価・行動意向調査・任意ウォレット連携で因果を検証可能に。予算の45%は再利用可能なGovernance Workshop Portal+OSSカリキュラム構築。

Full text:

> 2 

**2. The constitutional convention workshops produced measurable on-chain output.** You note that headline governance metrics have not moved, but the prior civics committee workshop series generated approximately 230 new DRep registrations per 12-epoch period during active delivery. That is not a trivial number against a small DRep base. The current proposal is structured to replicate and improve on that outcome with explicit measurement (pre/post assessments, behaviour-intent surveys, opt-in wallet linking, aggregate ecosystem indicators) so the causal claim can be tested rather than asserted.

**3. The program's lasting deliverable is infrastructure, not just workshops.** 45% of the budget funds the Governance Workshop Portal, curated open-source curriculum, and measurement system, assets that survive the funding period. After 12 months, anyone (including DReps you talk to, including community members in regions the committee cannot reach, including the next civics committee) can host a workshop using these materials without further funding. This is closer to building shared infrastructure than running a one-off program. The relevant comparison is not "another education program competing with existing supply" but "is this the infrastructure layer the ecosystem has been missing."

On the dashboard/tooling abundance argument you raise elsewhere in your rationales: agreed that tools exist. The curriculum effort here is curation, not creation, we are explicitly assembling existing ecosystem materials (Cardano Foundation governance course, CIP-1694 docs, GovTool guides, community DRep guides) into one authoritative, accuracy-reviewed, version-controlled collection. The gap we are filling is fragmentation, not absence.

#### Feedback 3 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fa68b4b05ff80adc7d5c41#comment-6a18588ea7468bb49bf846d2
- Summary (EN): Closes with respect for the voting policy and openness to specific structural changes (measurement methodology, milestone tied to governance outcomes). Invites direct engagement.
- Summary (JA): 投票方針を尊重し、具体的な構造変更 (測定方法論の公開、ガバナンス成果に紐付くマイルストーン構造など) があれば歓迎すると締める。直接連絡も歓迎。

Full text:

3

We respect your voting policy and your time. If your position remains NO after considering these points, we understand. If specific changes to the proposal would address your concerns, for example a clearer commitment to publishing measurement methodology, or a different milestone structure tied to specific governance outcomes, we would genuinely like to hear them. The Civics Committee is reachable through the contact details on the proposal page.

Thanks again for engaging publicly with the rationale rather than just voting silently. This visible reasoning is what makes this process work.

Civics Committee

---

## 66. BloxBean Java/JVM Toolchain for Cardano: 2026 Maintenance & New Initiatives

- Proposal ID: 69f857aed73bae0eb2a99543
- Requested: 432,600 ADA
- Vote (intention): YES
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69f857aed73bae0eb2a99543
- Category: Infrastructure / SDK
- Applicable criteria: C5, C8
- Prior snapshot vote: YES

### Voting reason (EN, as of 2026-05-28)

Already widely adopted.

### Voting reason (JA, as of 2026-05-28)

すでに幅広い採用があります。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: YES** on BloxBean Java/JVM Toolchain for Cardano: 2026 Maintenance & New Initiatives (**432.6K ADA / NCL 0.12%**).

**Main reasons**

**1. Named production consumers, including the official Cardano exchange integration**
- Per proposal, BloxBean tools (CCL + Yaci + Yaci Store + Yaci DevKit) power:
  - **Cardano Rosetta-Java** — the official Cardano exchange integration
  - **uVerify**
  - **Aquarium from Fluid Tokens**
  - **USDM**
  - **Easy1 Stake Pool**
  - **Gero Wallet**
  - and other community apps
- Rosetta-Java is the canonical surface used by exchanges to integrate Cardano — substantial downstream criticality.

**2. Funding split between Cardano Foundation and Treasury**

| Funding source | Funded engineers (FTE) |
|---|---|
| **Cardano Foundation** | 2.5 (including lead maintainer Satya as a CF employee) |
| **Treasury (current 2025 cycle)** | 1.0 (40 hr/week) |
| **Treasury (this 2026 proposal)** | 1.5 (60 hr/week) — **incremental ask of 0.5** |
| **Total team** | 3.5 → 4.0 |

This is not "fund the whole project from Treasury" — Cardano Foundation carries the majority. The incremental 2026 ask is small and justified by the 2026 roadmap.

**3. Concrete 2026 deliverables**

| Project | 2026 deliverable |
|---|---|
| CCL 0.8.0 | TxFlow workflow primitives + TxPlan (YAML) + verifiable data structures (MPF) |
| Yaci Store | Hard-fork support + Analytics Store (Parquet via DuckLake) + ~95% Blockfrost API compatibility |
| Yano + JuLC | new initiative maturation |
| All | hard-fork readiness, dependency updates, CI |

Hard-fork readiness is mandatory; the new initiatives are incremental scope. The Blockfrost API compatibility target (~95%) is concrete and auditable.

**4. JVM is structurally separate from the TypeScript and Rust ecosystems**
- Cardano Rust toolchain (Pallas + Oura + Dolos): TxPipe maintains.
- Cardano TypeScript toolchain (Lucid Evolution + Mesh + CTL): multiple maintainers.
- **Cardano JVM toolchain: BloxBean is the canonical maintainer.** No competing Java / Kotlin / Scala Cardano toolchain at production scale.
- JVM is one of the largest developer communities globally, especially in enterprise and financial systems.

**5. Cost benchmark**
- 432.6K ADA for 0.5 FTE incremental + 1 FTE continuation over 12 months.
- At ADA $0.25, ~$108K USD for 1.5 FTE per year ≈ $72K USD per FTE — below market rate for senior Java + Cardano protocol expertise.
- Lead maintainer's salary covered by Cardano Foundation = the lowest Treasury cost per deliverable in the bundle.

Default YES — named institutional consumer (Rosetta-Java) + concrete 2026 roadmap + appropriate CF/Treasury cost-sharing + canonical JVM-toolchain position.

### Prior detailed analysis (JA)

**Vote: YES** — BloxBean Java/JVM Toolchain for Cardano(2026 保守 + 新規施策、**432.6K ADA / NCL 0.12%**)に YES。

**主な理由**

**1. 名前付きの本番採用者あり。公式の Cardano 取引所統合も含む**
- 提案書より、BloxBean のツール(CCL + Yaci + Yaci Store + Yaci DevKit)が以下を支えている:
  - **Cardano Rosetta-Java**(公式の Cardano 取引所統合)
  - **uVerify**
  - **Aquarium from Fluid Tokens**
  - **USDM**
  - **Easy1 Stake Pool**
  - **Gero Wallet**
  - その他コミュニティアプリ
- Rosetta-Java は取引所が Cardano を統合する際の標準窓口。下流の重要度が高い。

**2. Cardano Foundation とトレジャリーの分担**

| 資金源 | 担当エンジニア(FTE) |
|---|---|
| **Cardano Foundation** | 2.5(CF 雇用のリード保守者 Satya を含む) |
| **トレジャリー(2025 サイクル)** | 1.0(週 40 時間) |
| **トレジャリー(本 2026 提案)** | 1.5(週 60 時間)— **追加分は 0.5 FTE** |
| **チーム合計** | 3.5 → 4.0 |

「全部トレジャリー資金」ではない。CF が過半を負担。2026 の追加分は小さく、ロードマップ拡張で正当化される。

**3. 2026 の具体的な成果物**

| プロジェクト | 2026 の成果物 |
|---|---|
| CCL 0.8.0 | TxFlow ワークフロー + TxPlan(YAML)+ 検証可能データ構造(MPF) |
| Yaci Store | ハードフォーク対応 + 分析ストア(DuckLake 経由の Parquet)+ Blockfrost API 約 95% 互換 |
| Yano + JuLC | 新規施策の成熟 |
| 全プロジェクト | ハードフォーク対応、依存更新、CI |

ハードフォーク対応は必須。新規施策は追加範囲。Blockfrost API 互換目標(約 95%)は具体的で検証可能。

**4. JVM は TypeScript / Rust エコシステムと構造上別**
- Cardano Rust ツール(Pallas + Oura + Dolos):TxPipe が保守。
- Cardano TypeScript ツール(Lucid Evolution + Mesh + CTL):複数の保守者。
- **Cardano JVM ツール:BloxBean が標準の保守者。** 本番規模で競合する Java / Kotlin / Scala Cardano ツールはない。
- JVM 開発者層は世界的にも大規模で、エンタープライズと金融系で特に厚い。

**5. 単価**
- 0.5 FTE 追加 + 1 FTE 継続を 12 か月で 432.6K ADA。
- ADA $0.25 換算で、1.5 FTE/年 約 $108K USD ≒ FTE 当たり 約 $72K USD/年。シニア Java + Cardano 知識の市場相場より低い。
- リード保守者の給与は CF が負担。バンドル中もっとも納品当たりトレジャリー費用が低い構造。

名前付きの公式採用先 + 具体的な 2026 ロードマップ + 適切な CF / トレジャリー分担 + 標準の JVM ツール位置で、YES。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 67. Formal Verification in Lean 4 and Blaster — Cardano Auditor Training Program 2026

- Proposal ID: 69fd84b3b05ff80adc7d5c58
- Requested: 412,000 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fd84b3b05ff80adc7d5c58
- Category: Research / ZK / FV
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Concerns raised in the prior analysis (expand 📚 below) were not mitigated to an acceptable level. Also, developer-training spend is not reusable. I consider funding training programs that don't yield reusable artefacts to be low priority.

### Voting reason (JA, as of 2026-05-28)

事前分析 (下記📚詳細を展開) で述べた懸念が許容可能な水準まで軽減されなかった。 また、 開発者をトレーニングする費用は再利用できません。 再利用可能な成果のないトレーニングプログラムへの資金提供の優先度は低いと考えています。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Categorisation**: [Research / FV training]. Non-applicable: C1, C2, C3 (research output metrics by design), C4, C6, C7, C10, C11.

**Applicable: C5, C8, C9**. Applying:

• **C5 — Functional overlap with IO Budget 2026 proposal**: IO Global has separately submitted active TW #102 'IO: Cardano High Assurance Technical Collaboration' (13.1M ADA) covering FV tooling accessibility. **Tier B comparison (active TW pending ratification, not yet funded)** — overlap concern is conditional on #102's vote outcome. If #102 ratifies, Lean 4 Auditor Training is duplicative. If #102 fails, Lean 4 Auditor Training has scope but should still satisfy C9 (thesis validation) independently.

• **C9 — Demand thesis unsupported**: The proposal's central claim that 'Cardano cannot scale TVS faster than auditor capacity' is asserted without empirical support:
  - No survey data identifying which Cardano protocols are waiting for audits
  - No data on audit firm backlogs or wait times

  Empirical counter-evidence: at least 8-10 firms actively serve Cardano audit/security work — MLabs, Anastasia Labs, CertiK, Quantstamp, Hacken, Tweag, Runtime Verification, No Witness Labs (the proposer itself). Per EMURGO official statement, Cardano TVL $1.1B+ with zero major Cardano hacks — current capacity functions at least at the catastrophic-failure-prevention level.

• **C8 — Conflation of niche scarcity with Cardano scarcity**: 'Lean 4 + Blaster auditor scarcity' is genuinely globally rare (Lean 4 is a niche proof assistant; Blaster is the proposer's own tool). 'Cardano auditor scarcity' is not. The proposal frames the former as if it were the latter — this conflation is the central evidence gap.

Therefore this proposal does not satisfy these criteria.

### Prior detailed analysis (JA)

**分類**: [Research / FV training]。 非適用: C1, C2, C3 (研究 output metric は by design), C4, C6, C7, C10, C11。

**適用: C5, C8, C9**。 適用:

・**C5 — IO Budget 2026 提案との機能重複**: IO Global は別途 active TW #102 'IO: Cardano High Assurance Technical Collaboration' (13.1M ADA) を FV tooling accessibility に対し submit。 **Tier B 比較 (active TW で ratify 前、 funded 確定でない)** — overlap concern は #102 投票結果に conditional。 #102 ratify されれば Lean 4 Auditor Training は重複。 #102 失敗なら Lean 4 Auditor Training は scope ありだが C9 (thesis validation) を independently に satisfy 必要。

・**C9 — demand thesis unsupported**: 提案書の中核主張 'Cardano cannot scale TVS faster than auditor capacity' は empirical support なしで assertion:
  - audit 待ち Cardano protocol の identifying survey data なし
  - audit firm backlog や wait time の data なし

  Empirical counter-evidence: 少なくとも 8-10 firms が Cardano audit/security work を active に serve — MLabs, Anastasia Labs, CertiK, Quantstamp, Hacken, Tweag, Runtime Verification, No Witness Labs (提案者自身)。 EMURGO 公式声明より Cardano TVL $1.1B+ で zero major Cardano hacks — current capacity は少なくとも catastrophic-failure-prevention level で機能。

・**C8 — niche scarcity と Cardano scarcity の混同**: 'Lean 4 + Blaster auditor scarcity' は globally に真に rare (Lean 4 は niche proof assistant; Blaster は提案者自身の tool)。 'Cardano auditor scarcity' は rare ではない。 提案書は前者を後者かのように framing — この混同が central evidence gap。

よって本提案はこれらを満たさない。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---

## 68. High-performance Rust Ogmios Client

- Proposal ID: 69fc770b8a0de51b89857e17
- Requested: 343,814 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc770b8a0de51b89857e17
- Category: Infrastructure / SDK
- Applicable criteria: C4, C5, C8
- Prior snapshot vote: NO

### Voting reason (EN, as of 2026-05-28)

Demand evidence in the Cardano ecosystem cannot be read from the proposal. Ogmios already exists; the data on how many developers actually want a Rust rewrite is not visible from the proposal.

### Voting reason (JA, as of 2026-05-28)

Cardano エコシステムにおける需要の証拠が提案書から読み取れない。 すでに Ogmios が存在しており、 Rust への書き直しをどれほどの開発者が求めているのかのデータが読み取れない。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

Thank you for the response; I apologize for seeming to move the goalposts, but in addition, you need to prove demand for this tool.

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

返答ありがとうございます、ゴールポストを動かしているようで申し訳ありませんが、さらに、当ツールへの需要を証明する必要があります。

### Prior detailed analysis (EN)

**Categorisation**: [Infrastructure / Ogmios Rust client]. Non-applicable: C1, C2, C3, C6, C7, C9, C10, C11.

**Applicable: C4, C5, C8** (revised after 2026-05-10 X community findings). Applying:

• **C5 — Existing Rust Ogmios client exists (decisive new evidence)**: Per @ItsDave_ADA (2026-05-10 X), an existing Rust client for Ogmios is publicly available: **https://github.com/vietanhrs/ogmios.rs**. Confirmed scope coverage of vietanhrs/ogmios.rs (MIT licensed, Rust 1.70+, Ogmios v6.x compatible): chain synchronization (block follow + rollback notifications), transaction submission + evaluation, mempool monitoring, ledger state queries (UTXOs, pools, parameters, governance), server health checking — i.e., the full Ogmios protocol surface. Status: minimal activity (0 stars, 11 commits, no releases) — likely early-stage / not actively maintained, BUT the codebase exists and can be forked / extended at a fraction of new-build cost. The earlier C5 dismissal ('Rust client complements existing TS/JS clients; not duplicative') was incomplete — it didn't engage with this specific existing Rust implementation.

• **C4 — Pricing concern (community signals)**: Per X community (2026-05-10): @matiwinnetou ('545K is insane, can be vibe-coded in 2 weeks, 50K max'), @ItsDave_ADA ('I'll do it for 125'). Proposal asks **545,694 ADA**. At ADA ≈ $0.24, that's ~$130K, and at higher ADA prices it scales up. Community price expectations for greenfield Rust Ogmios client = $50K-$125K range. Even allowing for higher quality / better maintenance commitment than vibe-coded baseline, 545K ADA represents 4-10× the community's stated reasonable range.

• **C8 — Builder demand still plausible**: Rust ecosystem demand for a Cardano-Ogmios client is real (Amaru, Dingo, Pallas-using projects, dApp Rust backends). The question is whether a NEW build is justified vs forking/maintaining vietanhrs/ogmios.rs at much lower cost.

**Vote shifted from YES → NO (community signal decisive)** based on:
1. Existing OSS Rust client (vietanhrs/ogmios.rs) wasn't engaged with in proposal
2. Pricing significantly above community expectations
3. Resubmission path: (a) explain why vietanhrs/ogmios.rs cannot be forked / extended, OR (b) reframe as maintenance/extension of existing OSS at sub-100K ADA cost, OR (c) demonstrate concrete technical superiority (benchmarks vs vietanhrs/ogmios.rs) justifying greenfield build at 5×+ cost.

### Prior detailed analysis (JA)

**分類**: [Infra / Ogmios Rust client]。 非適用: C1, C2, C3, C6, C7, C9, C10, C11。

**適用: C4, C5, C8** (2026-05-10 X community findings 後 revised)。 適用:

・**C5 — 既存 Rust Ogmios client が存在 (decisive な新 evidence)**: @ItsDave_ADA (2026-05-10 X) より、 Ogmios の既存 Rust client が公開済: **https://github.com/vietanhrs/ogmios.rs**。 vietanhrs/ogmios.rs の scope coverage 確認 (MIT licensed, Rust 1.70+, Ogmios v6.x 互換): chain synchronization (block follow + rollback notification), transaction submission + evaluation, mempool monitoring, ledger state query (UTXOs, pools, parameters, governance), server health check — つまり Ogmios protocol surface 全体。 Status: 活動 minimal (0 star, 11 commit, release なし) — likely early-stage / 非 active 維持、 但し codebase は存在し new-build cost の一部分で fork / 拡張可能。 以前の C5 dismissal ('Rust client は既存 TS/JS client を complement; 重複ではない') は不完全 — 本特定の既存 Rust 実装に engage していなかった。

・**C4 — 価格設定の懸念 (community signal)**: X community (2026-05-10) より: @matiwinnetou ('545K は insane、 2 週間で vibe-code 可能、 max 50K')、 @ItsDave_ADA ('125 でやる')。 提案は **545,694 ADA** 要求。 ADA ≈ $0.24 で ~$130K、 ADA 価格上昇でさらに scale。 Community の greenfield Rust Ogmios client 価格期待 = $50K-$125K 帯。 vibe-coded baseline より高品質 / 良好な maintenance commitment を allow しても、 545K ADA は community の reasonable range の 4-10×。

・**C8 — Builder demand 自体は plausible**: Cardano-Ogmios client への Rust ecosystem demand は real (Amaru, Dingo, Pallas-using project, dApp Rust backend)。 問題は新規 build が vietanhrs/ogmios.rs を fork/maintain する低 cost option に対し正当化されるか。

**Vote を YES → NO に shift (community signal が決定的)**、 理由:
1. 既存 OSS Rust client (vietanhrs/ogmios.rs) に提案書が engage していない
2. Pricing が community 期待を大幅に上回る
3. Resubmit path: (a) vietanhrs/ogmios.rs を fork / 拡張できない理由を説明、 又は (b) sub-100K ADA cost で既存 OSS の maintenance/拡張として reframe、 又は (c) concrete な技術的優位性 (vietanhrs/ogmios.rs との benchmark) を demonstrate して 5×+ cost greenfield build を正当化。

### Proposer feedback (1)

#### Feedback 1 — source: hydra, author: (anonymous)
- URL: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fc770b8a0de51b89857e17#comment-6a0d9a977d5f66c548766251
- Summary (EN): C5: aware of existing Rust Ogmios but argues their target is production-grade (benchmarks, async perf, preprod/mainnet validation, operational tooling) vs feasibility prototypes that mirror TS client API. C4: positioned as open-source infrastructure; will explicitly commit unused/appreciated ADA returns to treasury. C8: cites WingRiders' completed Catalyst milestones and ongoing production operation.
- Summary (JA): C5: 既存Rust Ogmiosは認識しているが、TSクライアントAPIを模した実現性検証レベルに対し、本提案は本番品質 (ベンチ、async性能、preprod/mainnet検証、運用ツール) を狙うと差別化。C4: OSSインフラとして残額/ADA上昇分のトレジャリー返却を明文化予定。C8: WingRidersはCatalystマイルストーン完了+本番運用実績ありと提示。

Full text:

Thanks for reviewing the proposal.

C5 (duplication):
We are aware of the existing Rust Ogmios, however, our proposal targets production-grade infrastructure rather than basic protocol feasibility. Existing Rust implementations largely mirror the TypeScript client API and functionality. While useful as early experiments, they do not provide performance-oriented, idiomatic Rust implementations with published benchmarks, reliability guarantees, extensive testing, preprod/mainnet validation, operational tooling, and long-term maintainability.

Our focus is production readiness: benchmarking, profiling, async performance optimization, testing coverage, live-network validation, operational reliability, developer experience, and sustainable maintenance by an experienced team already operating Cardano infrastructure in production.

C4 (treasury return):
This proposal is positioned as open-source infrastructure / SDK work rather than a commercial dApp feature. The deliverables are intended to become reusable public infrastructure assets for the broader Cardano ecosystem, including tooling, documentation, testing infrastructure, and backend integrations usable by other teams.

We will also update the proposal to explicitly state that any unused ADA, or excess value caused by ADA appreciation beyond delivery requirements, will be returned to the treasury or remain unclaimed.

C8 (past outcomes):
WingRiders has already delivered multiple Catalyst-funded milestones with publicly verifiable outcomes, including production deployments, open-source repositories, infrastructure tooling, and live applications supporting WingRiders DEX, Rapid DEX, Multi DEX Launchpad, and related backend systems. This proposal builds on practical operational experience running production Cardano infrastructure, not experimental-only development.

---

## 69. Cardano MCP by Lido Nation & 2 Lovelaces

- Proposal ID: 69fbc8dd85ddd26899aaf207
- Requested: 339,900 ADA
- Vote (intention): NO
- Hydra page: https://hydra-voting.intersectmbo.org/votes/cardano-budget-2026/69fbc8dd85ddd26899aaf207
- Category: Infrastructure / SDK
- Applicable criteria: C5, C8, C9
- Prior snapshot vote: NO-recommend-resubmit

### Voting reason (EN, as of 2026-05-28)

Scope appears to overlap with IO's DevEx proposal. It's also hard to tell how functional the actual prototype is.

### Voting reason (JA, as of 2026-05-28)

IO の提案書と作業範囲が重複しているように見える。 実態がどこまで動くプロトタイプなのかわかりづらい。

### Response to proposer feedback (EN, up to 2026-06-02 00:00 UTC)

No feedback

### Response to proposer feedback (JA, up to 2026-06-02 00:00 UTC)

No feedback

### Prior detailed analysis (EN)

**Vote: NO-recommend-resubmit** on Cardano MCP by Lido Nation & 2 Lovelaces (**339.9K ADA / NCL 0.10%**).

(MCP = Model Context Protocol, a way for AI coding agents to query domain-specific tools and data.)

**Main reasons**

**1. Cardano MCPs already exist — the proposal's "first / only" framing is wrong**
- Proposal framing: "Cardano is the only major blockchain without a production AI developer MCP. Solana has 40+. Ethereum has 30+."
- Actual situation: at least 2 production Cardano MCPs already deployed by Cardano builders:
  - **Indigo MCP** — Indigo Protocol-specific MCP, 1,700+ downloads.
  - **VESPR MCP** — wallet-side Cardano MCP for AI integration.
  - Plus this proposal's prototype — github.com/lidonation/Cardano-mcp is already live.
- The "first / only" framing is empirically incorrect.

**2. The proposal misdiagnoses the bottleneck**
- Proposal claim: "developer attrition driven by AI giving wrong Cardano answers."
- More empirically supported drivers of developer attrition:
  - AI training data lag (frontier models trained before recent Cardano protocol updates).
  - Cardano docs are fragmented (Plutus vs Aiken vs Plinth vs cardano-cli).
  - eUTxO conceptual barrier (different from EVM).
- An MCP helps marginally but does not address the training-data-lag or docs-fragmentation root causes.
- Solana / Ethereum's high MCP counts are real but their developer attraction is driven by liquidity, TVL, and user activity — not by MCP count.

**3. Scope: 54 tools across 6 modules — granular but unfocused**

| Module | Tool count | How it differs from existing Indigo / VESPR MCPs |
|---|---|---|
| Query | unspecified | likely overlaps Indigo MCP |
| Transaction building | unspecified | likely overlaps VESPR MCP + dApp-specific MCPs |
| Tokens and NFTs | unspecified | likely covered by existing wallet MCPs |
| Smart contracts | unspecified | gap may exist; could be useful |
| Indexing | unspecified | overlaps with Blockfrost API surface |
| **Governance / DRep workbench** | **26 tools** | **claimed unique — this is the proposal's defining value** |

26 of 54 tools (about half) is the governance / DRep workbench. The other 28 mostly duplicate existing Cardano MCP surfaces.

**4. The real gap is the governance workbench**
- No existing Cardano MCP focuses on governance work specifically.
- A 26-tool DRep workbench (reading proposals, sentiment analysis, ratification forecast, expiry tracking, CIP-100 rationale drafting) addresses a real DRep workload.
- Budget for governance-only scope would be much smaller than the full 54-tool 339.9K ADA ask.

**5. Cost and alternatives**
- 339.9K ADA ≈ $85K USD at ADA $0.25.
- For governance-only 26 tools, $85K is high; for all 54 tools (mostly redundant), $85K underprices the duplication.
- An alternative path: the governance workbench could be merged with VESPR or built as an Indigo MCP extension.

**Recommend resubmission** with: (a) scope narrowed to the governance workbench only (the unique value), (b) explicit cross-reference to existing Indigo MCP and VESPR MCP with documented non-overlap, (c) integration plan with at least one existing Cardano MCP (avoid yet-another fragment), (d) revised budget scaled to the narrower scope (likely 50-100K ADA).

### Prior detailed analysis (JA)

**Vote: NO-recommend-resubmit** — Cardano MCP by Lido Nation & 2 Lovelaces(**339.9K ADA / NCL 0.10%**)に NO(再提出推奨)。

(MCP は Model Context Protocol。AI コーディングエージェントが領域固有のツールやデータを参照するための仕組み。)

**主な理由**

**1. Cardano MCP は既に存在する。「最初 / 唯一」という前提が事実と異なる**
- 提案書の枠組み:「Cardano は本番運用の AI 開発者向け MCP を持たない唯一の主要チェーン。Solana は 40+、Ethereum は 30+」。
- 実際:少なくとも本番稼働中の Cardano MCP が既に存在する:
  - **Indigo MCP** — Indigo Protocol 固有 MCP、ダウンロード 1,700+。
  - **VESPR MCP** — AI 統合用のウォレット側 Cardano MCP。
  - 本提案のプロトタイプ(github.com/lidonation/Cardano-mcp)も既に公開済み。
- 「最初 / 唯一」の前提は事実と異なる。

**2. ボトルネックの診断が誤っている**
- 提案書の主張:「AI が Cardano について誤答するため開発者が離脱する」。
- 経験的により支持される離脱要因:
  - AI 学習データの遅延(最新の Cardano プロトコル更新前に学習が終わったモデル)。
  - Cardano のドキュメントが分散(Plutus / Aiken / Plinth / cardano-cli で別々)。
  - eUTxO モデルの概念的なハードル(EVM とは違う)。
- MCP は補助的には効くが、学習データ遅延やドキュメント分散の根本要因には届かない。
- Solana / Ethereum の MCP 数が多いのは事実だが、これらのエコシステムが開発者を引きつけている要因は流動性、TVL、利用者活動であって、MCP の数ではない。

**3. 範囲:6 モジュールで 54 ツール — 細かいが焦点不明**

| モジュール | ツール数 | 既存 Indigo / VESPR との違い |
|---|---|---|
| 問い合わせ | 未指定 | Indigo MCP と重複の見込み |
| トランザクション構築 | 未指定 | VESPR MCP + dApp 固有 MCP と重複の見込み |
| トークン / NFT | 未指定 | 既存ウォレット MCP がほぼカバー |
| スマートコントラクト | 未指定 | 空白がありそう。価値の可能性 |
| インデックス | 未指定 | Blockfrost API 領域と重複 |
| **ガバナンス / DRep ワークベンチ** | **26 ツール** | **独自と主張。提案の核となる価値** |

54 中 26 ツール(約半分)がガバナンス / DRep ワークベンチ。残り 28 ツールはほぼ既存 MCP の重複。

**4. 本当の空白はガバナンスワークベンチ**
- ガバナンス業務に特化した Cardano MCP は他に存在しない。
- 26 ツールの DRep ワークベンチ(提案を読む、感情分析、批准予測、期限管理、CIP-100 根拠ドラフト)は現実の DRep 作業に対応する。
- ガバナンス特化の範囲なら、54 ツール用の 339.9K ADA より大幅に小さい予算で済む。

**5. 単価と代替**
- 339.9K ADA ≒ $85K USD(ADA $0.25 換算)。
- ガバナンス 26 ツール限定なら $85K は高め。54 ツール(大半重複)には $85K では重複の代償を過小評価している。
- 代替経路:ガバナンスワークベンチは VESPR と統合、または Indigo MCP の拡張として作る選択肢がある。

**再提出推奨**:(a) 範囲をガバナンスワークベンチに絞る(独自価値の部分)、(b) 既存 Indigo MCP / VESPR MCP との重複しない範囲を明示、(c) 既存 Cardano MCP の少なくとも1つとの統合計画(断片の追加を避ける)、(d) 絞った範囲に合わせた予算(おそらく 50-100K ADA)。

### Proposer feedback (0)

_No proposer feedback collected for this proposal._

---