はじめに
2026年3月29日にエポック621で提出されたガバナンスアクション「Pebble + Gerolamo – HLabs 2026 Budget」について、SIPO DRepとしての分析と判断をお伝えします。
本提案は、Harmonic Laboratories（以下HLabs）が提出したTreasury Withdrawal（トレジャリー出金）提案であり、申請額は₳8,035,714（約$2.8125M、0.35 ADA/USD換算）です。12ヶ月の期間で、GerolamoというTypeScript実装のCardanoノード、Pebbleというスマートコントラクト言語、そしてHLabsが既にメンテナンスしている基盤TypeScriptライブラリ群のハードフォーク対応、この3領域に対する資金提供を求めています。
SIPOは本提案に賛成（YES）を投じます。以下、その判断に至った構造的な理由と、SIPOが期待する運用上の留意点を整理してお伝えします。
提案の全体像
| 項目 | 内容 |
|---|---|
| 提案名 | Pebble + Gerolamo – HLabs 2026 Budget |
| タイプ | Treasury Withdrawal |
| 申請額 | ₳8,035,714（$2.25M + 25%コンティンジェンシー） |
| 期間 | 12ヶ月（Q2 2026 – Q1 2027） |
| 提案者 | Harmonic Laboratories (HLabs) |
| 失効 | 2026年4月30日（Epoch 628） |
提案結果：https://adastat.net/governances/b11527fbcdc9d41e8f497de64a029a18673a5eefc413718459046f0b7a1a665600
配分内訳：
| スコープ | FTE | 金額 |
|---|---|---|
| Gerolamo（TypeScript Cardanoノード） | 5.0 | $1,125,000 |
| Pebble（スマートコントラクト言語＋開発ツール） | 3.5 | $787,500 |
| ハードフォークメンテナンス（TSライブラリ群） | 1.5 | $337,500 |
| 合計 | 10.0 | $2,250,000 |
これに25%のコンティンジェンシーバッファ（$562,500）を加え、$2,812,500、0.35 ADA/USDで₳8,035,714となります。
3つのスコープを個別に評価する
1. Gerolamo ― ブラウザネイティブな軽量ノードという新しい価値
Gerolamoは、TypeScriptで実装されたCardanoノードです。ただし、ここで注意深く読み取る必要があるのは、Gerolamoがブロック生成ノードとして設計されていないという点です。
提案書は明確に、Gerolamoの主な用途をブラウザ、dApp、ウォレット向けの軽量ノードとして位置づけており、ブロック生成をサポートするにはさらに約$500kの監査費用と最低1 FTEの追加が必要だと明記しています。この判断は、現在のコスト環境を考慮すると妥当です。
では、Gerolamoは何を解決するのでしょうか。
現在のCardano dAppエコシステムは、チェーン状態のクエリを中央集権的なインデクサや第三者APIに依存するケースが多く存在します。これは、分散化が本来排除すべきはずの信頼前提を、アプリケーション層で再導入してしまうことを意味します。ユーザーが「トラストレス」であると期待しているdAppが、実は特定のインフラ事業者への信頼を前提に動作しているわけです。
Gerolamoがブラウザ内で動作する本格的な軽量ノードを提供できれば、この構造が変わります。dAppは自身のUTxO状態検証やトランザクション検証を外部サービスに頼ることなく実行でき、ライトウォレットはDaedalus級の検証性を維持しながらも軽量なユーザー体験を提供できます。さらにSPOは、既存のHaskellノード構成と並列にGerolamoをリレーとして展開することで、リレー層におけるコードベースの多様性を追加することも可能です。
SIPOは既にAmaru（Rust実装）とDingo（Go実装）にYESを投じてきました。この2実装はいずれもブロック生成ノードを志向しています。Gerolamoはそれらとはカテゴリが異なる価値提案であり、資金の重複ではありません。ブラウザネイティブなノード実装は、現在のCardanoエコシステムに構造的に欠けているピースです。
2. Pebble ― 開発者ファネルの拡張
Cardanoのスマートコントラクト開発には長らく、関数型プログラミングの学習曲線という障壁が存在してきました。Aikenはこの障壁を大きく下げ、Rustや関数型言語に慣れた開発者にとって親しみやすい環境を提供することに成功し、現在では多数の本番dAppで使用されています。SIPOはAikenをCardanoスマコンツーリングの中心的成功事例と考えています。
Pebbleはこれとは異なる開発者層をターゲットにしています。TypeScript、JavaScript、Solidityといった命令型構文に慣れたエンジニアです。これは世界最大の開発者コミュニティであり、Aikenとは異なるメンタルモデルを持っています。
ここで重要なのは、Pebble対Aikenという競合構図ではなく、Cardanoが複数の正統な入口を持つという考え方です。両言語は最終的に最適化されたUPLC（Untyped Plutus Core）にコンパイルされ、オンチェーンでは同じ効率性を発揮します。選択は開発者の好みと背景に委ねられ、エコシステム全体としては開発者ファネルが拡大します。
Pebbleの設計は、LSP（Language Server Protocol）、CLI、watchモード、ソースマップを通じたデバッグ統合といった、成熟したエコシステムに匹敵する開発者体験を提供することを目指しています。これはCardano 2030戦略フレームワークのPillar 2（A.3 Developer Experience — Education & migration）と直接整合します。同項目は、EVM系およびアカウントベースの開発者がCardano/UTxOへ移行するための資料と経路を明示的に求めています。
3. ハードフォークメンテナンス ― 見落とされがちな公共財
この項目は、3つの中で最も「地味」ですが、おそらく最も高レバレッジな投資です。
HLabsは cardano-ledger-ts、ouroboros-miniprotocols-ts、plutus-machine、uplc といったTypeScriptライブラリをメンテナンスしています。これらはCardano TypeScript開発者エコシステムの相当な部分にとって、直接依存または下流ライブラリを介した間接依存の形で、基盤となっているライブラリ群です。
ハードフォークがプロトコルパラメータやPlutusバージョン、台帳ルールを変更するたびに、これらのライブラリは速やかに更新される必要があります。更新が遅れれば、下流プロジェクトはビルド破壊、緊急書き直し、あるいは静かな正しさのバグに直面することになります。
オープンソースでよく見られるパターンとして、重要なライブラリが資金不足のままメンテナ疲弊によって放棄され、各プロジェクトがフォークして個別にメンテナンスを引き継ぐことで、エコシステム全体のリソースが重複消費されていく現象があります。あるいはフラグメンテーションが起き、開発者コミュニティが分断されていきます。1.5 FTEでこのリスクを回避できるのであれば、それは極めて費用対効果の高い投資です。
ガバナンス構造の評価
本提案は、資金をSundaeLabsの treasury-contracts フレームワークに保持します。これはSIPOが既にAmaruおよびDingoに対してYESを投じた際と同じ監査済みエスクロー契約であり、バリデータはTxPipeとMLabsによって独立監査されています。
独立監視ボードは以下の3名で構成されています：
- Santiago Carmuega（TxPipe, Dolos）
- Lucas Rosa（Aiken, Starstream, Midnight）
- Chris Gianelloni（BlinkLabs, Dingo）
いずれもHLabsに持分を持たず、Cardanoインフラに直接的な技術的信頼性を持つ運用者です。注目すべきは、ボードメンバーにAikenとDingoの中心人物が含まれている点です。これは、異なる言語実装・異なる開発哲学を持つプロジェクト間で、競合ではなく協力関係が築かれていることを示す強いシグナルです。
権限スキームは以下の通りです：
| アクション | 権限 |
|---|---|
| 定期支払（Disburse） | HLabs + ボードメンバー1名 |
| 早期返却（Sweep） | HLabs + ボードメンバー1名 |
| マイルストーン調整（Reorganize） | HLabs単独 |
| 初期設定（Fund） | ボード過半数 |
| マイルストーン停止（Pause） | ボードメンバー1名 |
| マイルストーン再開（Resume） | ボード過半数 |
| プロジェクト変更（Modify） | HLabs + ボード過半数 |
単一ボードメンバーが異常を感知した場合に一時停止できる構造になっており、日常運用は軽量、構造的変更は重い承認プロセスが求められる、妥当な設計です。
さらに、エスクロー中のTreasury資金はDRepレベルでAuto-abstainに強制され、SPO委任は契約レベルで禁止されています。これは、トレジャリー資金がガバナンス投票やステーキングに影響を与えないことを保証します。契約満了時の未使用資金は、Cardanoトレジャリーへ自動的に返却されます（Failsafe Sweep）。
これはSIPOが既に二度承認した標準と同一であり、この規模のトレジャリー出金として適切と引き続き考えます。
Cardano 2030との整合
本提案は、Cardano 2030戦略フレームワークに対して具体的にマッピングされています。
| KPI / 戦略的優先度 | 2030目標 | HLabsの貢献 |
|---|---|---|
| 代替フルノードクライアント | 仕様準拠の実装 ≥2 | Gerolamoが2番目の仕様準拠実装として直接貢献 |
| 月次稼働率 | 99.98% | ハードフォークメンテナンスがプロトコルアップグレード時のエコシステム安定性を確保 |
| 開発者移行経路（A.3） | より多くの開発者オンボーディング | PebbleがEVM/TS系開発者にCardanoスマコンに親しみやすい構文を提供 |
さらに、提案は以下の測定可能な採用指標を12ヶ月以内の目標として公開でコミットしています。
Gerolamo採用目標（12ヶ月）：
- リレーとしてGerolamoを運用するSPO：10プール以上
- ブラウザベースのノード統合：ウォレット/dApp 3以上
Pebble採用目標（12ヶ月）：
- 開発者オンボーディング：20人以上（npmダウンロード、GitHubスター、Discordメンバー）
- 文書化完全性：全言語機能の100%カバレッジ
- チュートリアル完成：3以上のエンドツーエンドガイド
これらの指標は、HLabs自身の自己報告とは独立に、コミュニティが客観的にデリバリー評価を行うための基準を提供します。この点は重要です。
予算規律の検討
FTE単価 $225k/年は、SIPOが既にAmaruの前例においてCardanoコアインフラ業務の合理的ベンチマークとして承認した水準と整合しています。10 FTE × $225k = $2,250,000 に25%のコンティンジェンシーバッファを加え、$2,812,500。これを0.35 ADA/USDで換算すると₳8,035,714となります。
25%のコンティンジェンシーは、提案書自身が「過去の過少見積もりと楽観バイアスに対する学習」として位置づけており、裁量的な拡張予算ではないとされています。SIPOはこの位置づけが実務上も厳格に守られることを期待します。
スタンスの一貫性
SIPOのこれまでの投票履歴と照らし合わせてみます。
- Amaru Treasury Withdrawal 2026 → YES（ノード多様性、Rust実装）
- Dingo: Production-Grade Block Producer in Go → YES（ノード多様性、Go実装、Ethereum Prysm事例）
- HLabs: Pebble + Gerolamo 2026 Budget → 本投票
論理的な帰結として、SIPOがHLabs提案にNOを投じるには、以下のいずれかを主張する必要があります：
- 「ブラウザ軽量ノードはCardanoに不要である」
- 「TypeScript系開発者のオンボーディング経路は不要である」
- 「TypeScriptライブラリ群の保守は公共財ではない」
いずれもSIPOの過去スタンスと矛盾しますし、いずれも実際のCardanoエコシステムの状況を踏まえると妥当な主張にはなり得ません。
重要なのは、Gerolamoがブロック生成ノードではない点です。Amaru・Dingoと「4つ目のブロック生成実装は必要か」という論点ではなく、「dApp・ウォレット層にトラストレスな基盤を提供する実装は必要か」という全く別の論点です。この違いを明確に認識することで、3提案すべてへのYESが論理的に首尾一貫します。
SIPOの期待事項
SIPOのYESは、デリバリーとTreasury運用が厳格に説明責任を伴い続けることを前提としています。具体的には、以下の項目を明示的な運用上のコミットメントとして扱うことを期待します。
1. 月次ベロシティの透明性
HLabsは同規模のTreasury申請を受けた他チームと比較して小規模であり、本提案で資金提供される作業範囲は10 FTE相当に対応します。Gerolamo、Pebble、ツーリングメンテナンスの各リポジトリにおけるコミットベロシティおよびマイルストーン進捗について、月次レベルで公開可視性を維持することを期待します。各マイルストーン審査の前に、コミュニティがデリバリーの軌道を評価できる必要があります。
2. Q2ハードフォーク対応を最初のハードゲートとして
HLabsがメンテナンスする全TypeScriptライブラリは、Q2中に来たるべきintra-eraハードフォークに対応して更新される必要があります。SIPOはこれを本提案全体の中で最も荷重を担うデリバリーと位置づけます。ここでの失敗は、TypeScriptベースの全下流Cardanoプロジェクトに伝播するためです。証跡としてはリリースノート、PR参照、プロトコル変更との互換性確認を期待します。
3. Gerolamoプロダクションレディネス基準の達成
提案書はブラウザ軽量ノードについて5つの明示的な基準を掲げています：
- メインネットでのgenesisからtipまでの同期
- コモディティハードウェア（4 CPU、16GB RAM）上での初期同期48時間以内
- 15以上のピアとの24時間以上の安定接続
- Haskellノードベースラインの2倍以内のブロック伝播レイテンシ
- k=2160ブロックまでのロールバック復旧成功
SIPOはこれらが、デリバリー時に緩和されるのではなく、再現可能な証跡をもって達成された上でプロダクションレディ宣言がなされることを期待します。
4. Pebble採用指標の証跡ベース報告
20人の開発者オンボーディング、100%文書化、3つのチュートリアルといった目標は、自己評価の主張ではなく証跡（npmダウンロード数、GitHubスター数、Discordメンバー数、公開チュートリアルURL）とともに四半期ごとに報告されることを期待します。
5. Aikenとの補完関係の維持
SIPOがPebbleを支持するのは、Aikenとは異なる開発者層をターゲットにしているからです。Aikenと競合するからではありません。HLabsがPebbleをAikenと対立させるトーンやマーケティングを避け、妥当な範囲で相互運用性（共有Plutusブループリント、コンフォーマンステストの共有等）に協力することを期待します。Cardanoスマコン開発者コミュニティの分断は、Pebble自体が成功したとしても望ましくない帰結です。
6. 25%コンティンジェンシーの規律
コンティンジェンシーはリスクポリシーであり、裁量的拡張予算ではありません。コンティンジェンシー使用があった場合には明確な正当化を伴って公開で会計されること、および契約満了時に未使用分がSundaeLabs契約のfailsafe sweepを通じてCardanoトレジャリーへ返却されることを期待します。
7. Gerolamoブロック生成へのスコープ封じ込め
本提案はGerolamoをブラウザ軽量ノードおよびリレーとして明示的にスコープしています。将来、ブロック生成への方向転換を行う場合は、独自の監査計画と予算をもって別個のガバナンスアクションとして提案されるべきです。現在の申請に吸収される形で実施されるべきではありません。
8. 四半期報告の一貫性
SIPOはHLabsに対し、Amaru・Dingoに求めてきたのと同じ報告規律を期待します。マイルストーン進捗、KPI推移、遅延理由、次四半期のクリティカルパスを、四半期間で比較可能なフォーマットで一貫して報告することです。
9. 過去デリバリーの説明責任
SIPOはHLabsが、本提案の四半期報告と並行して、過去のCatalyst資金案件のステータスを公開で総括することを期待します。エコシステムが資金ラウンドごとの離散的評価ではなく、デリバリー実績を継続的に評価できるようにするためです。
結び
SIPOは本提案を、ノード多様性および公共財インフラに関するドクトリンの論理的な延長として評価します。
- Gerolamoは、Haskell Node、Amaru、Dingoのいずれも埋められない位置にある、dAppとウォレットアーキテクチャの構造的ギャップに対応します
- Pebbleは世界最大の開発者コミュニティに向けた追加の入口を開き、Aikenを置き換えるのではなく補完します
- ハードフォークツーリングメンテナンスは、既に大量に使用されており、衰退を許せば高コストかつ不安定化を招くエコシステム層を保護します
ガバナンス構造はSIPOがAmaruとDingoに対して既に承認したものと同一であり、予算規律もSIPOが既に妥当と受け入れた標準の範囲内です。
SIPOのYESは、デリバリーから切り離されたHLabsという組織への信認票ではありません。本提案の特定の作業スコープを、特定の予算水準で、特定のガバナンス構造のもとで資金提供する価値があるとの判断票です。ただし、上記の期待事項が拘束力のある運用上のコミットメントとして扱われることを条件とします。
以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。
SIPO DRep: How We View the “Pebble + Gerolamo – HLabs 2026 Budget” Proposal ― Analysis, YES Vote, and Stance
Introduction
We share SIPO DRep’s analysis and decision on the Governance Action “Pebble + Gerolamo – HLabs 2026 Budget,” submitted on March 29, 2026 in Epoch 621.
This is a Treasury Withdrawal proposal submitted by Harmonic Laboratories (HLabs) requesting ₳8,035,714 (approximately $2.8125M at 0.35 ADA/USD) over a 12-month period. The proposal funds three distinct scopes of work: Gerolamo, a TypeScript implementation of a Cardano node; Pebble, an imperative smart-contract programming language; and ongoing hard-fork maintenance of the foundational TypeScript libraries that HLabs already maintains for a substantial portion of the Cardano developer ecosystem.
SIPO votes YES on this proposal. Below we set out the structural reasoning behind that decision, along with the operational expectations SIPO attaches to its YES.
Proposal Overview
| Item | Details |
|---|---|
| Title | Pebble + Gerolamo – HLabs 2026 Budget |
| Type | Treasury Withdrawal |
| Requested | ₳8,035,714 ($2.25M + 25% contingency) |
| Duration | 12 months (Q2 2026 – Q1 2027) |
| Proposer | Harmonic Laboratories (HLabs) |
| Expires | April 30, 2026 (Epoch 628) |
Budget breakdown:
| Scope | FTE | Amount |
|---|---|---|
| Gerolamo (TypeScript Cardano node) | 5.0 | $1,125,000 |
| Pebble (language + dApp development tools) | 3.5 | $787,500 |
| Hard-fork maintenance (TS libraries) | 1.5 | $337,500 |
| Total | 10.0 | $2,250,000 |
A 25% contingency buffer ($562,500) brings the total to $2,812,500, denominated at 0.35 ADA/USD as ₳8,035,714.
Evaluating the Three Scopes
1. Gerolamo — A Browser-Native Light Node as a Distinct Value Proposition
Gerolamo is a TypeScript implementation of a Cardano node. The critical point to read carefully, however, is that Gerolamo is not designed as a block-producing node.
The proposal explicitly scopes Gerolamo as a light node for browsers, dApps, and wallets, and notes that enabling block production would require an additional ~$500k for a security audit plus at least one additional FTE. Given the current environment, SIPO considers this scoping decision correct.
What does Gerolamo actually solve?
Most dApps in the Cardano ecosystem today rely on centralized indexers or third-party APIs to query chain state. This reintroduces the trust assumptions that decentralization is supposed to eliminate. Users who believe they are interacting with “trustless” dApps are in fact relying on specific infrastructure operators at the application layer.
A production-ready browser-native light node changes that structure. dApps can verify UTxO states and validate transactions without relying on external services. Light wallets can offer Daedalus-level verification while retaining a light-wallet user experience. SPOs can additionally deploy Gerolamo as a relay alongside their existing Haskell-node setup, adding codebase diversity at the relay layer.
SIPO has already voted YES on Amaru (Rust) and Dingo (Go). Both of those implementations target block production. Gerolamo is a different category of value — not a duplication of funding. A browser-native node implementation is the structurally missing piece of today’s Cardano ecosystem.
2. Pebble — Expanding the Developer Funnel
Cardano smart-contract development has long carried the overhead of functional-programming literacy. Aiken meaningfully reduced that barrier for developers with Rust or FP backgrounds and is now used in a wide range of production dApps. SIPO considers Aiken a central success of Cardano’s smart-contract tooling.
Pebble targets a different developer population: engineers fluent in TypeScript, JavaScript, and Solidity-style imperative syntax. This is the largest developer community in the world, and it operates with a different mental model than functional programming.
The question is not Pebble versus Aiken. The question is whether Cardano should have multiple legitimate on-ramps for developers with different backgrounds. Both Pebble and Aiken compile to optimized UPLC; on-chain, their output is equivalent in efficiency. The choice is about developer preference and background, not runtime performance. From an ecosystem perspective, the result is an expanded developer funnel.
Pebble’s design includes full LSP (Language Server Protocol) implementation, a CLI with watch mode, and integrated debugging via sourcemaps — the kind of professional developer experience developers from mature ecosystems expect. This directly supports the Cardano 2030 Strategic Framework Pillar 2 (A.3 Developer Experience — Education & migration), which explicitly calls for materials and pathways to help EVM and account-based developers migrate to Cardano/UTxO.
3. Hard-Fork Tooling Maintenance — The Undervalued Public Good
This is the least glamorous of the three scopes but arguably the highest-leverage line item.
HLabs maintains cardano-ledger-ts, ouroboros-miniprotocols-ts, plutus-machine, and uplc. These libraries are load-bearing for a substantial portion of the Cardano TypeScript developer ecosystem, either as direct dependencies or transitively through downstream libraries.
Every time a hard fork changes protocol parameters, Plutus versions, or ledger rules, these libraries must be updated promptly. When they are not, downstream projects face broken builds, emergency rewrites, or — worse — silent correctness bugs.
A common pattern in open-source ecosystems is that critical libraries, starved of funding, fall into maintainer burnout and abandonment. Downstream projects then either fork and re-maintain the code themselves (duplicating effort across the ecosystem) or migrate to alternatives (fragmenting the developer community). Both outcomes are costly and destabilizing. If 1.5 FTE can prevent this, it is one of the most cost-effective investments in the proposal.
Governance Structure
Funds are held in SundaeLabs’ treasury-contracts framework — the same audited escrow structure that SIPO has already approved for Amaru and Dingo. The contracts have been independently audited by TxPipe and MLabs.
The independent oversight board is composed of:
- Santiago Carmuega (TxPipe, Dolos)
- Lucas Rosa (Aiken, Starstream, Midnight)
- Chris Gianelloni (BlinkLabs, Dingo)
None of the board members hold a stake in HLabs, and all three have direct technical credibility in Cardano infrastructure. Notably, the board includes central figures from Aiken and Dingo — a strong signal that projects with different language implementations and different design philosophies are operating in cooperation rather than competition.
The permission scheme is as follows:
| Action | Authorization |
|---|---|
| Disburse (periodic release) | HLabs + any one board member |
| Sweep early (return unused funds) | HLabs + any one board member |
| Reorganize (milestone schedule) | HLabs alone |
| Fund (initial vendor setup) | Board majority |
| Pause milestone | Any one board member |
| Resume milestone | Board majority |
| Modify project | HLabs + board majority |
Day-to-day operations require a single board co-signature, structural changes require the full board, and any single member can pause a milestone if something looks off. This is a reasonable design.
Funds in escrow are enforced to auto-abstain at the DRep level and cannot be delegated to SPOs — treasury funds do not influence governance votes or staking. Any unused funds at contract expiration automatically sweep back to the Cardano treasury.
This is the same standard SIPO has already approved twice and continues to consider appropriate for treasury withdrawals at this scale.
Cardano 2030 Alignment
The proposal maps concretely to the Cardano 2030 Strategic Framework.
| KPI / Strategic Priority | 2030 Target | HLabs Contribution |
|---|---|---|
| Alternative full-node clients | ≥2 spec-conformant | Gerolamo contributes as a second spec-conformant client |
| Monthly uptime | 99.98% | Hard-fork maintenance ensures stability across protocol upgrades |
| Developer migration pathways (A.3) | More developers onboarded | Pebble provides EVM/TS developers familiar syntax for Cardano |
The proposal also commits to publishing measurable adoption indicators within 12 months:
Gerolamo targets:
- SPOs running Gerolamo as a relay: ≥10 pools
- Browser-based node integrations: ≥3 wallets/dApps
Pebble targets:
- Developer onboarding: ≥20 developers
- Documentation completeness: 100% coverage
- Tutorial completion: ≥3 end-to-end tutorials
These metrics give the community objective criteria to evaluate delivery, independent of HLabs’s own self-reporting. That point matters.
Budget Discipline
The $225k annual FTE rate is consistent with the Amaru precedent that SIPO has already endorsed as a reasonable benchmark for Cardano core infrastructure work. Ten FTEs at that rate produce $2,250,000, plus a 25% contingency of $562,500, for a total of $2,812,500 — ₳8,035,714 at 0.35 ADA/USD.
The 25% contingency is framed in the proposal as a learned response to past underestimation and optimism bias, not as a discretionary expansion budget. SIPO expects this framing to be enforced in practice.
Consistency with Past Votes
SIPO’s voting history on related proposals:
- Amaru Treasury Withdrawal 2026 → YES (node diversity, Rust implementation)
- Dingo: Production-Grade Block Producer in Go → YES (node diversity, Go implementation, Ethereum Prysm precedent)
- HLabs: Pebble + Gerolamo 2026 Budget → this vote
For SIPO to vote NO on the HLabs proposal, it would have to argue one of the following:
- Cardano does not need a browser-native light node
- Cardano does not need onboarding pathways for TypeScript developers
- The TypeScript tooling layer is not a public good worth maintaining
None of these are consistent with SIPO’s past stances, and none hold up against the actual state of the Cardano ecosystem.
The critical distinction is that Gerolamo is not a block-producing node. The question here is not “does Cardano need a fourth block-producing implementation” but “does Cardano need a trust-minimized foundation for its dApp and wallet layer.” These are different questions, and recognizing that difference makes YES votes on all three proposals logically coherent.
SIPO’s Expectations
SIPO’s YES vote is conditional on delivery and treasury usage remaining strictly accountable. The following are expected to be treated as explicit operational commitments:
1. Monthly velocity transparency
HLabs is smaller than some peer recipients of similar treasury asks, and the funded scope here corresponds to 10 FTE-equivalents of work. SIPO expects month-level visibility into commit velocity and milestone progress across Gerolamo, Pebble, and the tooling-maintenance repositories. The community should be able to evaluate whether delivery is on track before each milestone gate.
2. Q2 hard-fork readiness as the first hard gate
All HLabs-maintained TypeScript libraries must be updated to support the upcoming intra-era hard fork within Q2. SIPO considers this the most load-bearing deliverable in the entire proposal, because failure would propagate to every downstream TypeScript-based Cardano project. Evidence should include release notes, PR references, and confirmation of compatibility with protocol changes.
3. Gerolamo production-readiness criteria must be met
The proposal commits to five explicit criteria for the browser light node:
- Sync from genesis to tip on mainnet
- Initial sync ≤48 hours on commodity hardware (4 CPU, 16GB RAM)
- Stable connections with ≥15 peers for ≥24 hours
- Block propagation latency within 2x of the Haskell node baseline
- Successful rollback recovery up to k=2160 blocks
SIPO expects these criteria to be met with reproducible evidence before Gerolamo is declared production-ready, not softened at delivery time.
4. Pebble adoption indicators tracked with evidence
The ≥20 onboarded developers, 100% documentation coverage, and ≥3 tutorials targets should be reported at each quarterly milestone with evidence (npm downloads, GitHub stars, Discord members, published tutorial URLs) rather than as self-assessed claims.
5. Complementarity with Aiken maintained in practice
SIPO supports Pebble specifically because it targets a different developer population than Aiken, not because it competes with Aiken. SIPO expects HLabs to avoid tone or marketing that pits Pebble against Aiken, and to actively collaborate on interoperability where reasonable (shared Plutus blueprints, conformance test sharing). Fragmentation of the Cardano smart-contract developer community would be a poor outcome even if Pebble itself succeeds.
6. 25% contingency buffer discipline
The contingency is a risk policy, not a discretionary expansion budget. SIPO expects any contingency drawdown to be publicly accounted for with clear justification, and any unused contingency at contract expiration to return to the Cardano treasury via the SundaeLabs contract’s failsafe sweep.
7. Scope containment on Gerolamo block production
The proposal explicitly scopes Gerolamo as a browser light node and relay. Any future pivot toward block production should come back as a separate governance action with its own audit plan and budget, not be absorbed into the current ask.
8. Quarterly reporting in a stable format
SIPO expects HLabs to adopt the same reporting discipline that SIPO has asked of Amaru and Dingo: consistent quarterly reports covering milestone progress, KPI trends, delays with reasons, and the next quarter’s critical path, in a format that remains comparable across quarters.
9. Past delivery accountability
SIPO expects HLabs to publicly close out the status of past Catalyst-funded work alongside this proposal’s quarterly reporting, so that the ecosystem can evaluate delivery track record continuously rather than discretely per funding round.
Closing
SIPO views this proposal as a coherent extension of its node-diversity and public-good infrastructure doctrine.
- Gerolamo addresses a structural gap in Cardano’s dApp and wallet architecture that neither Haskell Node, Amaru, nor Dingo is positioned to fill
- Pebble opens an additional on-ramp for the largest developer community in the world, complementing rather than replacing Aiken
- Hard-fork tooling maintenance protects a layer of the ecosystem that is already heavily used and would be expensive and destabilizing to let atrophy
The governance structure is the same SIPO has already endorsed for Amaru and Dingo, and the budget discipline is within the standard SIPO has already accepted as reasonable.
SIPO’s YES is not a vote of confidence in HLabs as an organization abstracted from deliverables. It is a vote that this specific scope of work, at this specific budget level, under this specific governance structure, is worth funding — subject to the expectations above being treated as binding operational commitments.
For these reasons, SIPO DRep votes YES.
References
- Governance Action: gov.tools
- Adastat: adastat.net
- Gerolamo Repository: github.com/HarmonicLabs/gerolamo
- Pebble Repository: github.com/HarmonicLabs/pebble
- Cardano 2030 Strategic Framework: product.cardano.intersectmbo.org
- SundaeSwap Treasury Contracts: github.com/SundaeSwap-finance/treasury-contracts
