Pebble & Ecosystem maintenance: TypeScript core of Cardano
157 DReps voted · 57 with a rationale
Open a row to read the rationale.
- Yes 592.3M ₳ Rationale
Summary
Yoroi DRep votes YES on “Pebble & Ecosystem Maintenance: TypeScript Core of Cardano”, recognising this resubmission as a materially improved proposal that addresses the concerns raised in our prior ABSTAIN position.
Rationale
A focused resubmission that addresses prior concerns.
The combined HLabs proposal that Yoroi abstained on bundled Gerolamo, Pebble, and tooling maintenance into a single 8 million ADA request. This proposal separates those tracks, removes the node implementation entirely, and reduces the ask to 4,600,000 ADA. The concerns Yoroi raised about scope and proportionality have been directly addressed by the resubmission structure HLabs has chosen.Pebble’s performance case is now independently verified.
At the time of our prior vote, the case for Pebble rested largely on the team’s own claims. The UPLC-CAPE benchmark results, produced through IOG’s independent evaluation framework, now show that Pebble outperforms Aiken on CPU and memory budget and is competitive with Plutarch. Combined with a TypeScript-shaped syntax that serves the largest developer community on Cardano, this positions Pebble as a complementary on-ramp rather than a redundant one.Tooling maintenance is load-bearing infrastructure.
The HLabs TypeScript stack is a dependency of Mesh, Lucid Evolution, Midgard, and numerous production dApps. Keeping it synchronised with protocol upgrades is not discretionary work; it is the foundational maintenance that keeps the TypeScript ecosystem coherent through hard forks. Funding it here avoids pushing that cost onto dozens of downstream teams who would otherwise have to absorb it independently.Conclusion
Yoroi votes YES on this proposal as a well-scoped, appropriately priced successor to the prior HLabs submission, and one that reflects the kind of focused, evidence-based resubmission we encouraged. - Yes 428.5M ₳ Rationale
I vote YES for "Pebble & Ecosystem maintenance: TypeScript core of Cardano".
I vote YES for the same reasons as in the previous vote.
—
私は「Pebble & Ecosystem maintenance: TypeScript core of Cardano」にYESを投票します。
前回の投票と同様の理由で、YESを投票します。
- Abstain 328.3M ₳ No rationale
- Yes 297.4M ₳ Rationale
Summary
EMURGO as a DRep votes YES on the treasury withdrawal titled “Pebble & Ecosystem Maintenance: TypeScript Core of Cardano”, with rationale outlined below.
Rationale
EMURGO previously abstained on the combined HLabs proposal that bundled Gerolamo, Pebble, and tooling maintenance into a single request of over 8 million ADA. Our reservations at that time centered on the scale of the ask, questions around TypeScript as a foundation for a production node, and uncertainty about the necessity of a new smart contract language alongside Aiken. This proposal addresses the first and second concerns directly: Gerolamo is now a separate governance action voted on independently, and this proposal focuses exclusively on Pebble and TypeScript ecosystem maintenance at a materially reduced cost of 4,600,000 ADA.On Pebble specifically, our view has evolved on the basis of the evidence now available. The UPLC-CAPE benchmark results, produced through IOG’s independent framework, show that Pebble produces on-chain code that outperforms Aiken in both CPU and memory budget and is competitive with Plutarch, while offering an imperative, TypeScript-shaped syntax that addresses a genuinely different developer audience. This is not a redundant addition alongside Aiken; it is a complementary on-ramp for the TypeScript and Solidity developer populations that Aiken’s functional-first design does not serve. The case for Pebble is now grounded in verifiable performance data rather than assertion.
The tooling maintenance component is straightforward. The HLabs TypeScript stack underpins Mesh, Lucid Evolution, Midgard, and a long tail of production dApps. When a hard fork lands, those projects depend on HLabs updating the foundational libraries. Funding that maintenance through this proposal is more efficient than leaving the cost to be absorbed inconsistently across dozens of downstream teams. The governance structure, with an independent oversight board, milestone-based disbursements, and automatic return of unused funds, is well-designed. EMURGO votes YES.
- Yes 240.8M ₳ No rationale
- Yes 221.8M ₳ Rationale
YES on Pebble & Ecosystem maintenance: TypeScript core of Cardano;
In line with our previous vote, we support HLabs' proposals.
- No 174.4M ₳ Rationale
See my previous rationale (I don't think Aiken is the main bottleneck for Cardano adoption)
- Yes 160.5M ₳ No rationale
- Yes 135.1M ₳ Rationale
The Cardano Foundation votes YES. We support Pebble and important TypeScript library maintenance, however we urge the team to increase the length of this proposal and use these funds for at least 24 months, rather than the 12 months originally foreseen.
A PDF version of this rationale is also made available.
We appreciate Harmonic Laboratories responding to our previous feedback by separating this valuable developer tooling from the ambitious browser node initiative. We are voting YES based on the following strategic alignments, guided by important financial parameters:
1. Strategic Developer Onboarding: The Cardano ecosystem currently lacks a production-ready imperative smart contract language. Pebble’s TypeScript-inspired syntax serves as a bridge for the global pool of Web2 (JS/TS) and EVM (Solidity) developers. While functional programming (like Aiken) is excellent for specific developer profiles, Pebble lowers the barrier to entry for the broader market without sacrificing UPLC performance.
2. Important Infrastructure Maintenance: Funding the maintenance of the HLabs TypeScript stack (
cardano-ledger-ts,plutus-machine, etc.) is important public good infrastructure. Major ecosystem tools, including Mesh and Lucid Evolution, depend on these libraries being updated for upcoming intra-era hard forks. Ensuring this stack remains stable is vital for ecosystem continuity.3. Budget Reframe: The 24–36 Month Runway Caveat: Our primary concern involves the financial proportionality of the request. A $1.15M (₳4.6M) request for 5 FTEs plus contingency over a 12-month period is substantial, especially given historical contribution patterns that reflect a very lean core team. Our Subject Matter Experts noted that a $500,000 ask from Pebble would align more closely with standard 12-month costs.
Therefore, our YES vote is cast with the recommendation that this $1.15M budget be stretched to cover a 24-month (at least) maintenance horizon. We wish to make this clear now so that future maintenance funding requests will be informed by this viewpoint and can provide an explanation should additional funds be needed within 24 months. By viewing this as a multi-year runway, it factors in the long-term, ongoing maintenance of Pebble and the important TS libraries.
4. Transparency and Oversight: While we commend the use of the SundaeLabs treasury contract and the independent oversight committee, we note that the specific budgetary breakdown and justification for the 5 FTEs could benefit from additional clarity. We also strongly encourage the team to provide increasingly granular and transparent financial reporting for any future funding requests.
The Cardano Foundation votes YES. We support the expansion of Cardano's smart contract paradigms and the maintenance of important TypeScript libraries.
NOTE on 'Internal Voting':
The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well. - Yes 93.3M ₳ Rationale
This is the last-minute vote. I'm changing my vote to YES.
For reference, please check my previous rationale.
My conditions for accepting the proposal have been largely met.
- Catalyst proposal is done. The Catalyst platform displayed data incorrectly.
- The difference between Pebble and Catalyst-funded projects has been clarified.
- I have evidence that there is demand for Pebble from devs.
- I have decided not to insist on unbundling.
If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.
MANDA Pool ID:
pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8My DRep ID:
drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp - Yes 92.1M ₳ No rationale
- Yes 89.8M ₳ Rationale
SIPO DRep votes YES on Pebble & Ecosystem maintenance: TypeScript core of Cardano.
Governance Action ID: gov_action1ggr2uz7prwn5l84cdn2krwngfez0p7wluy4u3u3ez9pz5ls2whesqnsjly8
DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
Date: 2026-05-13Context: This is the resubmission of the TypeScript / smart-contract-language half of HLabs's original 2026 Budget, on which SIPO voted YES (with binding expectations) on 2026-04-10. The original ₳8.0M single proposal narrowly missed DRep ratification at 66.78%. HLabs split the work into two independently-votable proposals and reduced the combined ask by approximately 30% in USD terms. SIPO has reviewed both resubmissions and votes YES on each individually.
Why SIPO votes YES
- The five SIPO expectations from the 2026-04-10 vote are structurally addressed.
- Monthly velocity transparency: Monthly Lightweight Updates, Quarterly Detailed Reports, and a Public Transaction Journal committed in the HarmonicLabs/2026-treasury-proposal repository, matching the standard SIPO asked of Amaru and Dingo.
- Q2 hard-fork (Plutus V4) gate: M1.B is an independently-payable sub-milestone (₳210k), with CI-green Plutus V4 testnet snapshot for all four maintained libraries as the acceptance criterion. M1.A (Pebble) and M1.B (HF maintenance) can be co-signed and paid independently, so HLabs has no incentive to bundle or delay HF work.
- Past delivery accountability: the 2025 Retrospective (IPFS QmZVw...e9c) documents EC-0014-25 Gerolamo as 11/13 fully shipped and 2/13 in progress, despite ADA/USD dropping from ~0.7 to under 0.3 (effective funding cut by more than half). HLabs still delivered.
- Aiken complementarity: an explicit "Why Pebble and Aiken can coexist" section, a complementarity table mapping each to different developer profiles, and Lucas Rosa (Aiken / Midnight) on the Independent Oversight Board.
- 25% contingency discipline: reduced to 15% (10pp absolute reduction), structured as a refundable reserve with contract-enforced failsafe sweep back to the Cardano treasury at expiration.
Pebble expands the developer funnel without fragmenting it. Cardano Foundation surveys show TypeScript / JavaScript is the most-used language among Cardano developers. Pebble is TypeScript-shaped, imperative-first, targets UPLC, and its UPLC-CAPE benchmarks show strict improvement over Aiken at smaller script sizes. Aiken remains the FP-fluent option; Pebble opens the EVM / Web2 onramp. This directly supports Cardano 2030 Pillar 2 (A.3 Developer Experience — Education & migration).
Tooling maintenance is load-bearing public-good infrastructure. cardano-ledger-ts, ouroboros-miniprotocols-ts, plutus-machine, and uplc are direct or transitive dependencies of Mesh, Lucid Evolution, Midgard, and the long tail of TypeScript dApps and wallets. Skipping this funding does not save money; it pushes the cost to dozens of downstream teams who absorb it independently and inconsistently.
Governance and budget discipline match SIPO's approved standard. SundaeLabs treasury-contracts framework (independently audited by TxPipe and MLabs), Independent Oversight Board (Carmuega / TxPipe, Rosa / Aiken, Gianelloni / BlinkLabs), auto-abstain DRep delegation on escrow, no SPO delegation, single-board-member pause, contract-enforced failsafe sweep — identical to Amaru, Dingo, and the IO 9-proposal round of 2026-05-09. The $0.25 ADA/USD conversion rate is conservative versus the 0.35 used in the original April 10 submission, materially reducing ADA-denominated risk.
Binding operational expectations SIPO attaches to this YES
- M1.B HF readiness must produce CI-green Plutus V4 testnet snapshot evidence for all four maintained libraries within Q2 2026, published as tagged releases. Failure to ship this gate must pause M1.B until evidence is supplied; M1.A may continue independently.
- Pebble adoption indicators (≥20 developers, ≥3 tutorials, 100% documentation coverage) reported quarterly with primary evidence (npm downloads, GitHub stars, Discord counts, published tutorial URLs), not as a year-end claim.
- Aiken interoperability demonstrated through at least one concrete deliverable: shared Plutus blueprints, shared conformance tests, or a UPLC-CAPE category co-defined with the Aiken team.
- UPLC-CAPE participation extended to at least one new category beyond naive-recursion Fibonacci / Factorial by M2.
- Contingency drawdown publicly justified in each quarterly report and the public transaction journal; unused contingency swept back to the Cardano treasury via the SundaeLabs failsafe.
- Plutus V4 codegen (M2, Q3 2026) must enable end-to-end execution of a Pebble contract on a Plutus V4 preview / preprod node, with a committed log or tx link as acceptance evidence.
- Independent Oversight Committee reviews published in a stable, quarter-over-quarter comparable format covering milestone progress, KPI trends, delays with reasons, and the next quarter's critical path.
- Scope containment: any pivot outside Pebble language + the four named libraries should come back as a separate governance action with its own audit plan, not be absorbed into this ask.
Closing
This is a coherent and structurally improved resubmission. Every binding expectation SIPO attached to the original YES is addressed in the resubmitted text and milestone structure. The underlying public-good case — expanding Cardano's developer funnel through an imperative UPLC-targeted language and sustaining the TypeScript libraries the ecosystem already depends on — has not weakened. SIPO's YES is conditional on the expectations above being treated as binding operational commitments and verified by the Independent Oversight Committee before each disbursement.
For these reasons, SIPO DRep votes YES.
SIPO DRepとして、本提案「Pebble & Ecosystem maintenance: TypeScript core of Cardano」に賛成（YES）を投じます。
Governance Action ID: gov_action1ggr2uz7prwn5l84cdn2krwngfez0p7wluy4u3u3ez9pz5ls2whesqnsjly8
DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
Date: 2026-05-13背景：本提案は、2026-04-10にSIPOが期待事項付きでYESを投じた当初HLabs 2026 BudgetのTypeScript / スマートコントラクト言語部分の再提出です。当初₳8.0Mの単一提案はDRep批准66.78%で67%閾値に僅差で届きませんでした。HLabsはコミュニティフィードバックを反映し、作業を2つの独立投票可能な提案に分割、合計請求額をUSD換算で約30%削減しました。SIPOは両再提出を精読し、それぞれに個別YESを投じます。
SIPOがYESと判断する理由
- 2026-04-10投票時の5つの期待事項が構造的に対応されている。
- 月次ベロシティ透明性：Monthly Lightweight Updates、四半期詳細レポート、公開トランザクションジャーナルをHarmonicLabs/2026-treasury-proposal repoにコミット。SIPOがAmaru・Dingoに求めてきた標準と一致。
- Q2ハードフォーク（Plutus V4）ゲート：M1.Bが独立支払可能サブマイルストーン（₳210k）として分離。Acceptance Criterionは4ライブラリすべてについてPlutus V4テストネットスナップショットへのCIグリーン。M1.A（Pebble）とM1.B（HFメンテナンス）が独立して共同署名・支払可能で、HLabsにHF対応をPebbleとバンドル・遅延させるインセンティブなし。
- 過去デリバリー説明責任：2025 Retrospective（IPFS QmZVw...e9c）でEC-0014-25 Gerolamoが13項目中11項目完納、2項目進行中と記録。ADA/USDが約0.7から0.3以下に下落し実効ファンディングが半分以下になったにもかかわらず履行。
- Aiken補完関係：『Why Pebble and Aiken can coexist』セクションを明示、補完性テーブルで両者を異なる開発者プロファイル向けに位置づけ、Independent Oversight BoardにLucas Rosa氏（Aiken / Midnight）を配置。
- 25%コンティンジェンシー規律：15%へ削減（絶対値10ppダウン）、返還可能リザーブとして構造化、契約満了時の未使用分は契約レベル強制でCardanoトレジャリーへfailsafe sweep。
Pebbleは開発者ファネルを拡大するが分断はしない。Cardano Foundation調査ではTypeScript / JavaScriptがCardano開発者の最多使用言語。PebbleはTypeScript的、命令型優先、UPLCターゲットで、UPLC-CAPEベンチマークはAikenを上回るスクリプトサイズ縮小を示す。AikenはFP堪能組の選択肢を維持し、PebbleはEVM / Web2 onrampを開く。Cardano 2030 Pillar 2（A.3 Developer Experience — Education & migration）に直接対応。
ツーリングメンテナンスは負荷を担う公共財インフラ。cardano-ledger-ts、ouroboros-miniprotocols-ts、plutus-machine、uplc は Mesh、Lucid Evolution、Midgard、および多数のTypeScript dApp・ウォレットの直接または間接依存。ファンディングをスキップしてもコストは消えず、下流の数十チームに分散・吸収される。
ガバナンス・予算規律はSIPO承認標準と一致。SundaeLabs treasury-contractsフレームワーク（TxPipe + MLabs独立監査済み）、Independent Oversight Board（Carmuega / TxPipe、Rosa / Aiken、Gianelloni / BlinkLabs）、エスクローのAuto-abstain DRep委任、SPO委任不可、単一ボードメンバー一時停止可、契約強制failsafe sweep — Amaru・Dingo・IO 9提案ラウンド（2026-05-09）と同一。$0.25 ADA/USDレートは当初4月10日提出時の0.35に対して保守的で、ADA建てリスクを大幅に削減。
SIPOが本YESに付す拘束力ある運用上の期待事項
- M1.B HF対応：Q2 2026中に4ライブラリすべてについてPlutus V4テストネットスナップショットへのCIグリーン証跡をタグ付きリリースとして公開。本ゲート達成失敗時は証跡提供までM1.Bを一時停止すべきであり、M1.Aは独立して支払継続可。
- Pebble採用指標（≥20開発者、≥3チュートリアル、100%文書化）を四半期ごとに一次証跡（npm DL、GitHub star、Discordメンバー、公開チュートリアルURL）で報告。年末単一クレームは不可。
- Aiken相互運用性：共有Plutus blueprint、共有conformanceテスト、またはAikenチームと共同定義のUPLC-CAPEカテゴリのいずれかで具体デリバラブルを実証。
- UPLC-CAPE参加をM2までにnaive-recursion Fibonacci / Factorial以外の少なくとも1カテゴリへ拡張。
- コンティンジェンシー使用は各四半期レポートおよび公開トランザクションジャーナルで公開正当化、未使用分はSundaeLabs failsafeでCardanoトレジャリーへ返却。
- Plutus V4 codegen（M2、Q3 2026）はPlutus V4 preview / preprodノード上でのPebbleコントラクトのエンドツーエンド実行を実現、コミットログまたはtxリンクをAcceptance Evidenceとする。
- Independent Oversight Committeeレビューを、マイルストーン進捗・KPI推移・遅延理由・次四半期クリティカルパスを四半期間で比較可能な安定フォーマットで公開。
- スコープ封じ込め：Pebble言語+4ライブラリ外への方向転換は、独自の監査計画と予算をもつ別個のガバナンスアクションとして戻すこと。
結び
本提案は首尾一貫した構造的に改善された再提出。SIPOが当初YESに付した拘束力ある期待事項のすべてが、再提出されたテキストとマイルストーン構造で対応されている。基礎にある公共財ケース — 命令型UPLCターゲット言語を通じたCardano開発者ファネル拡大、およびエコシステムが既に依存しているTypeScriptライブラリの継続維持 — は弱まっていない。SIPOのYESは、上記期待事項が拘束力ある運用上のコミットメントとして扱われ、各支払前にIndependent Oversight Committeeによって検証されることを条件とする。
以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。
- Yes 89.3M ₳ Rationale
Given Cardano's relative lack of success over the years in attracting developers vs. its peers, I believe it is worth taking a gamble on a typescript-shaped imperative language. There is a valid argument that functional programming is no longer as steep a challenge with the rise of vibe coding. But, Cardano's historic record of NOT overly attracting developers has not so far been disrupted by AI. So, the case for taking a gamble at this price on adopting an imperative smart contract programming language still seems persuasive enough. It only requires a modicum of first principles thinking to conclude that something akin to the world's most popular programming language has a good chance of seeing more adoption than something more akin to languages that are far less adopted. Additionally, this is not an "OR" situation where we replace one arrow with another. This would be an "AND" situation where we hope to add another arrow in the quiver.
- Yes 89.2M ₳ Rationale
Improving developer experience is essential for Cardano's development. The ability to create smart contracts using syntax familiar to Web2 engineers is a key factor in attracting developers to Cardano.
- Yes 77.3M ₳ No rationale
- Yes 74.7M ₳ No rationale
- Yes 71.3M ₳ Rationale
I vote YES. I credit the team for splitting this from their prior proposal. Bringing strongly typed languages like TypeScript to Cardano is essential for growth. Crucially, the value ask entirely justifies the value output. I look forward to seeing this progress if funded.
A PDF version of this rationale is also made available.
I am formally registering a YES vote on the Pebble and Ecosystem maintenance Treasury Withdrawal. First and foremost, I must credit Harmonic Laboratories for their persistence, their passion, and their undeniable commitment to Cardano. I deeply appreciate that this specific initiative has been split out from their original, broader proposal on which I previously voted NO. This demonstrates a highly mature responsiveness to community governance and feedback.
From a technical standpoint, I am voting to specifically support and credit the development of Pebble. Having the ability to build smart contracts using widely recognised paradigms like TypeScript is absolutely essential for Cardano. It dramatically lowers the barrier to entry for millions of global developers and has the potential to drive massive ecosystem growth. Furthermore, because of the strongly typed nature of TypeScript, Pebble serves as a perfectly placed blueprint for how we can successfully adopt and integrate other mainstream programming languages into our ecosystem in the future.
Crucially, having reviewed the financials, I firmly believe that the value ask of this proposal entirely justifies the value output. I consider this to be a highly strategic and accountable investment in our core infrastructure and developer onboarding pipeline. I am proud to support it today, and I look forward to seeing this progress if funded.
- Yes 70.8M ₳ No rationale
- No 68M ₳ Rationale
I understand the importance of strengthening onboarding pathways for TypeScript and Solidity developers, as well as the value of maintaining critical tooling infrastructure within the Cardano ecosystem. I also recognize that HLabs currently plays an important role in supporting widely used TypeScript libraries and dependencies across projects such as Mesh, Lucid Evolution, and Midgard.
I can also appreciate the broader vision behind Pebble and the attempt to lower the barrier for imperative-style developers who may currently find Cardano difficult to approach. Additionally, the proposal demonstrates a relatively strong level of transparency and milestone-based accountability compared to many treasury proposals.
However, I believe Cardano’s highest-priority challenge at this stage is not the creation of additional smart contract languages, but rather increasing real adoption, users, liquidity, demand, and market connectivity. From my perspective, Cardano’s current limitations are less about lacking development tooling and more about the ecosystem’s ability to translate existing technical strengths into meaningful market growth and user adoption.
I am also cautious about the potential fragmentation that may result from introducing another smart contract language into an ecosystem where Aiken has already established a meaningful position. It remains uncertain whether TypeScript-like syntax alone will meaningfully drive large-scale developer migration into Cardano.
Given the current treasury environment, I believe the ecosystem should prioritize initiatives that directly strengthen adoption, liquidity, user growth, and competitive positioning before expanding the number of developer languages and paradigms available within the ecosystem.
For these reasons, I vote against this proposal.
本提案が目指している「TypeScript / Solidity開発者の導線強化」や、tooling maintenanceの重要性については理解しています。特に、HLabsが現在のCardano TypeScript ecosystemにおいて重要な役割を担っていることや、Mesh、Lucid Evolution、Midgardなどの基盤ライブラリ維持がエコシステムにとって一定の価値を持つことには異論はありません。
また、Pebbleによって、これまでCardanoへ入りづらかったimperative系開発者への間口を広げようとしている方向性自体も理解できます。proposal全体としても、milestone管理や透明性への配慮が比較的丁寧に設計されている点は評価しています。
一方で、現在のCardanoが直面している最優先課題は、「新しい開発言語を増やすこと」よりも、「実際の採用・ユーザー・需要・流動性・市場接続をどう増やすか」にあると考えています。現状のCardanoは、技術や開発基盤そのものが不足しているというより、既存技術を活かしきれるだけの市場側の拡大や実需形成の方が大きな課題に見えています。
また、Aikenが既に一定の地位を築いている中で、新たなスマートコントラクト言語を追加することによる開発者分散やエコシステム複雑化のリスクについても慎重に考える必要があると感じています。TypeScriptライクな構文だけで大規模な開発者流入が実現するかについても、現時点では不確実性が大きいと考えています。
現在のトレジャリー状況を踏まえると、今はまず「開発者数を増やすこと」よりも、「ユーザー・流動性・採用・市場競争力」を強化する施策を優先すべき段階だと判断しています。
そのため、今回は反対とします。
- Yes 62.7M ₳ No rationale
- No 53.8M ₳ Rationale
I am voting No on the Pebble & Ecosystem maintenance: TypeScript core of Cardano proposal.
This proposal bundles two tracks of work: maintenance of the TypeScript tooling stack, and accelerated development of a new smart contract language, Pebble. My positions on these two are clearly different. Because the proposal does not allow them to be evaluated separately, and because the Pebble portion does not meet the bar in my view, I am voting No on the bundled package.
I strongly agree with funding the TypeScript tooling maintenance. Many widely-used libraries in the Cardano TypeScript ecosystem, including Mesh, Lucid Evolution, and Midgard L2, depend on this tooling stack directly or transitively. If this maintenance lags during a hard fork, the entire downstream ecosystem stalls along with it. This is public-goods infrastructure, and I believe the Treasury should fund it.
However, I am skeptical about the case for funding Pebble.
There is no empirical evidence of demand. The proposal argues that since TS/JS is the largest developer pool in the world, an imperative-syntax language will draw them to Cardano. But there is no concrete signal showing that TypeScript developers who chose not to come to Cardano point to "Aiken's functional paradigm" as the blocker. If anything, in an era where AI has sharply lowered the cost of learning a new language, I think the real barrier is not the language itself but the structural difference between the market-standard EVM and the eUTxO model. Pebble does not address this fundamental barrier.
HLabs' own adoption target is very modest. Despite a potential target pool of millions of TS/Solidity developers, the 12-month goal is only 20 developers. Spending around ₳3.2M to onboard developers at that scale is difficult to justify.
Aiken is already working well. Aiken became the default quickly after mainnet release, and Cardano developer activity has remained steady. There is no observable signal supporting the hypothesis that "the functional paradigm is the bottleneck blocking developer inflow."
I think Cardano's real bottleneck for developer onboarding lies elsewhere. TVL and commercial opportunity, network effects, the learning curve of the eUTxO model itself, and gaps in documentation and tutorials are the larger problems, and Pebble does not solve any of them.
I recognize the value of the tooling maintenance while remaining skeptical about the funding case for Pebble. Because the bundled structure forces a single decision on both, I am voting No.
- No 50.5M ₳ No rationale
- No 49.7M ₳ Rationale
I am voting No on this proposal. As a DRep, I evaluate all treasury withdrawal governance actions against my published voting framework, with a focus on the healthy development and long-term sustainability of the ecosystem. This proposal does not meet the framework's requirements, and I am voting No on that basis. Reference: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem/ [Japanese version follows] 本提案に反対票を投じます。私はすべてのトレジャリー出金ガバナンスアクションを、公開済みの投票フレームワークに基づいて、エコシステムの健全な発展と持続可能性を重視して評価しています。本提案はフレームワークの要件を満たさないため、反対票を投じます。参照: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/
- Yes 40M ₳ Rationale
I am thankful to Michele & the Hlabs team for splitting this proposal into two. I will be upvoting Pebble, because I believe it has a big chance of helping developer adoption of Cardano and will be downvoting Geralomo because I think its currently not necessary to fund another node after Amaru, Haskell Node, Dingo, C# Node, even if it is Typescript & can run in the browser. I would like the Hlabs team to focus their efforts on Pebble & other projects such as Gravity DEX which I believe could bring substantial traffic to Cardano and help in positioning it as a true DeFi chain.
- Yes 38.1M ₳ No rationale
- Yes 36.8M ₳ No rationale
- Yes 34.4M ₳ Rationale
予算が限られていて、どちらか一方が今すぐ必要か？と問われれば、HLabsのツールメンテナンスが最も緊急性が高いと言えます。これは、次のアップグレード時に既存のアプリが動かなくなるのを防ぐためです。
- Yes 34.3M ₳ Rationale
We are voting YES. This withdrawal funds open-source public goods at two layers Cardano structurally depends on: better smart-contract developer ergonomics (Pebble) and ongoing maintenance of the TypeScript core that a large share of the ecosystem builds and runs on.
A PDF version of this rationale is also made available.
We are voting YES. This withdrawal funds open-source public goods at two layers Cardano structurally depends on: better smart-contract developer ergonomics (Pebble) and ongoing maintenance of the TypeScript core that a large share of the ecosystem builds and runs on (libraries, tooling, and the TypeScript node). These are exactly the kind of infrastructure the treasury exists to fund, because no single commercial actor has a direct incentive to pay for them. We weighed the concerns raised in earlier deliberation on the related work — packaging, FTE accounting, and the Constitutional Committee's posture — and concluded they argue for tighter reporting and milestone-gated disbursement, not for defunding the work.
What this funds
Pebble — a strongly-typed smart-contract DSL (a first-class language with its own syntax and compiler) that compiles to UPLC (Untyped Plutus Core) and exposes onchain/offchain type ecosystems for contract and dApp integration. It lowers the barrier to writing correct on-chain code on Cardano.
TypeScript core / ecosystem maintenance — continued upkeep of the TypeScript libraries, tooling, and node work (including the Gerolamo TypeScript node) that a large part of the builder community relies on. This is the unglamorous, high-leverage maintenance layer that keeps the application ecosystem healthy.
Why we support itMaintenance of shared infrastructure is a treasury-shaped cost. The TypeScript stack is a commons: many teams depend on it, but its upkeep is under-provided by markets because no one team captures the full benefit of maintaining it. Funding it from the treasury is precisely the gap community funding is meant to fill.
Client and tooling diversity is a resilience requirement. A maintained TypeScript node and toolchain reduces the network's dependence on a single canonical implementation and a single language community. Diversity at the node and tooling layer lowers correlated-failure risk — one bug or supply-chain issue affecting every node at once.
Developer ergonomics drive the application layer. Cardano's EUTXO model is powerful but has a steeper on-ramp than account-based chains. A type-safe DSL that compiles to UPLC (Pebble) eliminates a class of on-chain bugs and widens the funnel of developers who can ship safely. Tooling that makes the platform easier to build on compounds over years.
Meets the world's largest developer population where it is. TypeScript is one of the most widely used languages globally. Lowering the language barrier to building and running Cardano infrastructure is among the higher-leverage uses of ecosystem funding.
Accountable, known builder. The work continues existing, inspectable open-source output from a named team (Harmonic Labs / Michele Nuzzi) rather than a speculative proposal from an unproven group. Treasury money is lower-risk when it extends work that already lives in public.
Concerns we weighed
An honest YES has to address the issues raised in deliberation on the related action:Packaging / scope clarity. The earlier bundled version (Pebble + Gerolamo — HLabs 2026 Budget, GA95) drew valid criticism for combining distinct workstreams under one budget, which blurs accountability. We support funding each deliverable against its own milestones and budget line, and read the "TypeScript core maintenance" framing as a step toward clearer scoping — provided the line items are itemized.
FTE accounting / potential double-counting. Reviewers flagged possible double-counting of full-time-equivalents across workstreams. This is a reporting-quality problem that warrants a transparent staffing breakdown and milestone-tied disbursement — it does not establish that the work lacks value.
Constitutional Committee posture. A CC body previously raised an unconstitutionality finding on the related action, and HLabs published a public response. We read this as a governance-process dispute about scope and documentation standards rather than a judgment that the deliverables are without merit. We weight the substance heavily while backing the CC's push for tighter proposal hygiene.
Conditions we'd attach (and watch)
Itemized budget: Pebble and the TypeScript-core maintenance lines scoped and costed separately.
Milestone-gated disbursement rather than a single up-front withdrawal.
A transparent staffing/FTE table that resolves the double-counting question.
Public, inspectable deliverables (repos, releases) tied to each milestone.
Bottom line
Cardano needs maintained core tooling and more than one language community building on it — and both are hard to fund through normal market incentives, which is exactly why the treasury should. The objections to this work are about how the spend is packaged and reported, not whether it is worth doing. We vote YES on the substance and back the call for itemized, milestone-gated funding. - Yes 32.3M ₳ Rationale
Yes. ₳4.6M over 12 months for HLabs to build Pebble (TypeScript-syntax smart-contract language) and maintain the TS stack behind Mesh, Lucid Evolution, and Midgard. Milestone-gated SundaeSwap escrow, independent oversight, public UPLC-CAPE benchmarks, quarterly financial audit.
A PDF version of this rationale is also made available.
Voting Yes. ₳4,600,000 over 12 months for Harmonic Laboratories across two tracks: Pebble, an imperative smart-contract language compiling to UPLC, and ongoing maintenance of the TypeScript stack that production projects already depend on. Gerolamo is funded under a separate action and voted independently. Strong fit across the Cardano First framework:
- Adoption: Lead pillar. Pebble gives the TypeScript and Web2 developer pool a familiar imperative syntax that compiles to on-chain code, the highest-leverage onboarding lever Cardano has. The maintenance half matters as much: the HLabs stack (cardano-ledger-ts, ouroboros-miniprotocols-ts, plutus-machine, uplc) already sits under Mesh, Lucid Evolution, and Midgard, so this is infrastructure the existing builder base ships on today, kept synchronized with each hard fork.
- Decentralization: HLabs is an independent, Cardano-native R&D firm, not an incumbent. Funding a second serious tooling lineage outside the IO, CF, and Intersect orbit reduces single-vendor concentration in the parts of the stack developers touch daily. Same logic as my Yes on Amaru, Dingo, and Pebble + Gerolamo.
- Scalability: Pebble compiles to optimized UPLC that, per HLabs' published benchmarks, outperforms Aiken and stays competitive with Plutarch. Smaller, cheaper scripts are a direct execution-efficiency gain. The proposal commits Pebble to public UPLC-CAPE benchmark submissions, so the performance claim is verifiable against Intersect's suite rather than self-reported.
- Economic Sustainability: Contested. ₳4.6M is a grant, not a loan, so no capital returns directly. What makes it acceptable: the ask follows the Amaru FTE-valuation standard (5 FTE at $200k, 0.25 ADA/USD, 15% contingency), every quarter is gated on accepted deliverables, and non-delivery sweeps funds back rather than spending them anyway.
- Governance Transparency: Funds sit in the audited SundaeSwap treasury.ak / vendor.ak escrow and release only as an independent oversight committee co-signs each milestone, against public artifacts (tagged npm release, UPLC-CAPE submission, green CI log) rather than self-reported progress. Milestone 0 draws only ₳400,000 at kickoff, contingency is held back across the engineering quarters, and an independent third-party financial audit runs quarterly plus a final assessment.
Splitting Gerolamo into a separate action means this ask funds a tighter scope than the earlier combined HLabs budget did.
Risks I'm accepting with this Yes:
- Greenfield language adoption. Pebble is pre-production, and the thesis that TypeScript-shaped syntax pulls new builders onto Cardano is unproven on-chain. Aiken already holds the functional-programming segment. If Pebble fails to attract developers, the language half underdelivers.
- Single-vendor dependency. Funding HLabs deepens reliance on one firm for critical TypeScript infrastructure; if HLabs stalls, Mesh, Lucid Evolution, and Midgard inherit the exposure. Milestone gating protects the money, not the concentration in the dependency graph.
- Grant with no repayment. Recovery depends on the non-delivery sweep, not revenue or repayment. I accept that the public-good nature of core tooling justifies a grant structure, the same way prior core-infrastructure withdrawals have been treated.
Critical TypeScript infrastructure the ecosystem already runs on, a new on-ramp for the largest developer pool on earth, milestone-gated escrow with independent oversight. Yes.
- Abstain 31.3M ₳ No rationale
- Yes 31M ₳ Rationale
I am voting YES.
This proposal delivers high‑value public goods for Cardano, including the TypeScript ecosystem and the Pebble compiler.
The funding structure is transparent, with escrow, third‑party oversight, and clear refund conditions, which significantly reduces risk.
All outputs are open‑source and directly strengthen Cardano’s developer experience and long‑term competitiveness. - Yes 28.2M ₳ Rationale
Typescript is arguably the most popular programming language in use today and is the native language of the internet. Having a native Cardano smart contract language based on TypeScript will unlock a huge portion of the developer market and make building on Cardano exponentially easier than it is today. Pebble is an easy YES for me.
- Yes 27.9M ₳ No rationale
- No 27.4M ₳ No rationale
- Yes 26.1M ₳ No rationale
- Yes 22.7M ₳ Rationale
🙂
- Yes 22M ₳ No rationale
- Abstain 21.3M ₳ No rationale
- Yes 21.2M ₳ No rationale
- Yes 21.1M ₳ No rationale
- Yes 21.1M ₳ No rationale
- Yes 20.3M ₳ No rationale
- Yes 19.9M ₳ Rationale
With Midnight using Typescript, I see great value in Cardano also supporting Typescript as a smart contract language option, so developers can tackle both chains with one programming language. This is YES for me.
- Yes 17.1M ₳ Rationale
Pebble & Ecosystem maintenance: TypeScript core of Cardano
- Yes 14.1M ₳ No rationale
- Yes 13.3M ₳ Rationale
RCADA supports this treasury withdrawal proposal from Harmonic Laboratories (HLabs) for Pebble and TypeScript ecosystem maintenance as a strategically important investment in Cardano’s long-term developer accessibility, tooling resilience, and ecosystem continuity.
This proposal funds two tightly related workstreams: the continued development of Pebble, an imperative, TypeScript-shaped smart contract language targeting UPLC, and the ongoing maintenance of critical TypeScript infrastructure libraries that underpin a significant portion of Cardano’s developer ecosystem. These include dependencies relied upon directly or transitively by projects such as Mesh, Lucid Evolution, Midgard, wallet integrations, indexers, and other production systems. Ensuring these libraries remain synchronized with protocol upgrades and future hard forks represents meaningful ecosystem maintenance rather than optional experimentation.
RCADA previously voted YES on the broader HLabs 2026 infrastructure proposal, which included Gerolamo, Pebble, and TypeScript tooling maintenance as a tightly integrated stack spanning infrastructure, developer onboarding, and ecosystem resilience. This proposal represents a more modular and independently reviewable version of that vision, separating Gerolamo into its own governance action. We view this increased granularity positively and consistent with our long-standing preference for more focused treasury proposals.
From a governance perspective, this proposal demonstrates a strong degree of maturity and accountability. Funds are managed through audited SundaeSwap treasury escrow contracts with milestone-based disbursement, independent oversight, pause mechanisms, refund protections, and automatic treasury return of unused funds at expiry. Importantly, milestone acceptance criteria are tied to objective, publicly inspectable artifacts such as tagged releases, npm packages, benchmark submissions, test logs, and observable execution on preview or pre-production networks. RCADA places considerable weight on verifiable delivery mechanisms, and this proposal compares favorably to many prior treasury requests in that regard.
We also acknowledge the strategic case for expanding Cardano’s developer funnel. Cardano has historically faced onboarding friction, particularly for developers accustomed to imperative and TypeScript-based environments. Pebble attempts to lower this barrier by offering a familiar development model while targeting the same underlying UPLC runtime as existing languages. We do not view this as a replacement for Aiken, but rather as a complementary pathway that may broaden participation among Web2 and Solidity developers who might otherwise find Cardano’s smart contract stack less accessible.
That said, our support comes with several caveats.
First, while we appreciate the proposal’s detailed governance structure, we continue to hold reservations around the use of upfront contingency reserves within treasury asks. Although the 15% contingency is refundable, milestone-gated, and substantially smaller than structures seen elsewhere, RCADA remains cautious about the precedent that pre-allocated contingency buffers can establish for treasury discipline. Future proposals should continue exploring more conditional or milestone-triggered approaches wherever feasible rather than normalizing larger embedded reserves.
Second, while we recognize Pebble’s potential to improve onboarding, developer adoption ultimately remains the key measure of success. A new language ecosystem introduces some risk of fragmentation, duplicated effort, or ecosystem complexity if adoption fails to materialize meaningfully. For this reason, we strongly encourage transparent reporting not only on technical delivery, but also on measurable ecosystem usage — including developer onboarding, tooling adoption, educational uptake, and downstream integration into real applications.
Third, RCADA continues to emphasize the importance of maintaining multiple complementary developer pathways without creating unnecessary competition for scarce ecosystem attention or treasury resources. Pebble’s success should be evaluated on whether it expands Cardano’s total addressable developer base rather than merely redistributing existing developers across another toolset.
In summary, RCADA believes this proposal meets the standard for responsible treasury funding. It addresses genuine ecosystem needs, demonstrates mature governance and accountability mechanisms, and aligns with long-term goals around decentralization, developer accessibility, and infrastructure resilience. Our support should be interpreted as endorsement of this specific implementation, governance structure, and reporting model — while signaling continued scrutiny around contingency design, measurable adoption outcomes, and ecosystem fragmentation risk.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- Abstain 11M ₳ No rationale
- Abstain 10.5M ₳ Rationale
This is not because I am against the proposal, nor because I believe it lacks value. My abstain is based on something much simpler:
I am not a technical expert and I do not feel confident enough to make a strong judgment on the technical merits of Pebble versus alternatives.
Pebble may very well be useful. The tooling maintenance portion may also be important. But unlike Gerolamo, where the value proposition is easier to understand at a strategic and product level, this proposal depends much more on technical assessment
So my abstain is an honest one. I am not rejecting the proposal. I am simply acknowledging that I do not have the technical depth required to judge it with conviction.
I do think separating this proposal from Gerolamo was the right decision. These are very different asks and they should not have been bundled together in a way that forced voters into one combined position.
- Yes 8.8M ₳ Rationale
私はこの提案に賛成します。Pebbleの開発およびTypeScriptエコシステムの保守は、特定の企業やアプリケーションではなく、Cardanoエコシステム全体の開発基盤を強化する取り組みだと考えています。特に、TypeScriptは多くの開発者にとって身近な言語であり、新たな開発者の参入障壁を下げる可能性がある点を評価しています。また、既存のTypeScriptライブラリやツール群は、既に複数のプロジェクトで利用されており、今後のハードフォークやプロトコルアップグレードへ継続的に対応していくことにも価値があると考えています。Pebbleの普及や成果については今後も確認していく必要がありますが、本提案はオープンソースの公共財としてCardanoエコシステム全体へ利益を還元する性質が強いと考えています。そのため、私は本提案に賛成します。\n\nI vote Yes on this proposal. I believe the development of Pebble and the maintenance of the TypeScript ecosystem strengthen the development foundations of the broader Cardano ecosystem rather than serving a specific company or application. In particular, I value the potential for TypeScript, a language familiar to many developers, to lower the barrier to entry for new builders. I also believe there is significant value in maintaining the existing TypeScript libraries and tooling that are already used by multiple projects and ensuring they remain compatible with future hard forks and protocol upgrades. While the adoption and long-term impact of Pebble should continue to be evaluated, I view this proposal as a strong public-good investment that can benefit the wider Cardano ecosystem through open-source development. Therefore, I vote Yes on this proposal.
- Yes 8.1M ₳ No rationale