SIPO DRep：『The First Node in the Browser; a Cardano USP（Gerolamo）』再提出をどう考えるか ― SIPO DRepの分析と「YES」評価、そしてスタンス

はじめに

2026年5月5日にエポック629で提出されたガバナンスアクション「The first node in the browser; a Cardano USP」について、SIPO DRepとしての分析と判断をお伝えします。

本提案は、Harmonic Laboratories（以下HLabs）が提出したTreasury Withdrawal（トレジャリー出金）提案であり、申請額は₳4,600,000（約$1.15M、$0.25 ADA/USD換算）です。12ヶ月の期間で、Gerolamoというブラウザ拡張機能としてパッケージされる完全検証Cardano軽量ノードの開発に対する資金提供を求めています。

本提案は単独の新規提案ではありません。2026年4月10日にSIPOが「期待事項付きYES」を投じた当初のHLabs 2026 Budget提案（₳8,035,714の単一提案）が、DRep批准において66.78%となり67%閾値に僅差で届かなかったことを受け、HLabsがコミュニティフィードバックを反映して2つの独立投票可能な提案に分割再提出した片方です。もう片方の「Pebble & Ecosystem Maintenance: TypeScript Core of Cardano」については別記事で扱います。

Gerolamo側は、当初4月10日投票時には存在していなかったEC-0014-25回顧録の公開により、実質的に強化された再提出となっています。

SIPOは本提案に賛成（YES）を投じます。以下、なぜGerolamoがCardano固有の構造的USPなのか、当初5期待事項にどう応答されているか、そして今回新たに付す8つの拘束力ある運用上の期待事項を整理してお伝えします。

提案の全体像

項目	内容
提案名	The first node in the browser; a Cardano USP
タイプ	Treasury Withdrawal
申請額	₳4,600,000（$1M + 15%コンティンジェンシー、$0.25/ADA換算）
期間	12ヶ月（Q2 2026 – Q1 2027）
提案者	Harmonic Laboratories (HLabs)
提出エポック	629（2026年5月5日）
失効エポック	635（2026年6月9日）
Governance Action ID	gov_action1guz68e8zkwphcdc8wnp40cclkv92qgnel7xnffmsmp2ljp09qtwqq596k4c

配分内訳：

スコープ	FTE	金額
Gerolamo（TypeScript Cardanoノード）	5.0	$1,000,000
15%コンティンジェンシー	–	$150,000
合計	5.0	$1,150,000

$0.25 ADA/USDで換算し、₳4,600,000となります。

合算で見ると、もう片方のPebble提案（同₳4,600,000）と合わせて₳9,200,000、約$2.3Mとなり、当初の₳8,035,714（$2.8125M @ $0.35/ADA）と比較してUSD換算で約30%の削減になっています。

GerolamoがCardano固有のUSPである構造的理由

「ブロックチェーンのノードがブラウザで動く」という話は、業界でしばしば語られてきました。しかし、実際に完全検証を行うノードをブラウザで稼働させた主要チェーンは存在しません。理由はベースレイヤー設計にあります。

CardanoのeUTxO設計には、他の主要チェーンが模倣できない構造的特性があります：

eUTxO状態はトランザクションにローカル：ブラウザノードは台帳全体のグローバルな可変状態を維持する必要がなく、自分が関心を持つスライスのインプットとアウトプットだけを検証できます
ブロックサイズと帯域要求は限定的：高TPS L1と比較して控えめで、一般的な家庭用回線でブラウザが持続的に処理可能な範囲内です
コンセンサス（Praos）は軽量リソースで検証可能
Plutusスクリプトは決定的なCEKマシン上の純粋関数：JavaScript / WebAssemblyランタイムでホストし、Web Worker内でメインスレッドをブロックせずに実行することが容易です

これらの組み合わせが、Cardanoを ブラウザ内検証ノードが技術的に現実的な唯一の主要チェーン にしています。Ethereum、Solana、その他のアカウントベースまたは高TPSチェーンは、検証を骨抜きにする（実質的にSPV / trusted-RPCに退化させる）か、コンセンサスと状態モデルを根本的に再設計するかしない限り、これを再現できません。

Gerolamoは、この潜在的アーキテクチャ優位性を 実際に出荷可能なプロダクト に変換するプロジェクトです。研究デモやSPVクライアントの簡略版ではなく、コンセンサスを実行し、ヘッダーとブロックを検証し、Plutusスクリプトを評価する、本物のノードがユーザーマシン上のブラウザ拡張機能内で動作します。

これは「いつかブラウザで動くかもしれない」という願望ではなく、Cardanoが具体的に他チェーンに対して提示できる差別化要因になります。

ノード多様性ドクトリンの第4軸としてのGerolamo

SIPOはAmaru（Rust）とDingo（Go）に対してYESを投じてきました。論理は Haskell単一実装リスクは実在する というもので、その典型例として2026年3月のEthereum Prysmインシデントがあります。マルチクライアントアーキテクチャはインフラ保険です。

GerolamoはこのドクトリンをTypeScript / WebAssemblyという第4軸に拡張します。ただし重要なのは、これが構造的に異なる役割であることです。

本提案は明示的に、Gerolamoを dAppとウォレット向けの軽量検証ノード としてスコープしており、ブロック生成ノードではありません。提案書本文には次のように記載されています：

Gerolamoは本提案下において、ブラウザ軽量ノード用途に専属する補完的実装として設計されています。サーバーサイドリレー役割、ブロック生成、その他のフルノード用途は本ファンディング期間中、本スコープから明示的に除外され、HaskellノードおよびAmaru等の他実装に残ります。

加えて、ブロック生成を追加するには「約$500kの追加監査と少なくとも追加1 FTEが必要」であると明記され、現在のコスト環境下ではブロック生成範囲を削減することが妥当な判断であるとしています。

これはSIPOがノード多様性懸念に対して期待する「最強の構造的回答」です。Amaru・Dingo（ブロック生成）とGerolamo（軽量ノード）は競合ではなく、異なる役割で同じドクトリンを支える 関係にあります。

なぜGerolamoが必要か ― 構造的に欠けているピース

現在のCardano dAppエコシステムは、チェーン状態のクエリを 中央集権的インデクサや第三者API に依存するケースが多く存在します。これは、分散化が本来排除すべきはずの信頼前提を、アプリケーション層で再導入してしまうことを意味します。ユーザーが「トラストレス」であると期待しているdAppが、実は特定のインフラ事業者への信頼を前提に動作しているわけです。

Gerolamoがブラウザ拡張機能として提供する完全検証軽量ノードは、この構造を変えます：

dApp側

dAppは、ユーザーが一度インストールしたブラウザ拡張機能経由で完全検証軽量ノードに問い合わせることで、バックエンド依存なしに信頼性最小化されたチェーンアクセス を得られます。UTxO状態の検証、トランザクション検証、チェーンデータクエリを、外部サービスに依存せず実行できます。

ライトウォレット側

ライトウォレット開発者は、Gerolamoをアプリケーションに統合することで、ユーザーに Daedalus級のセキュリティ保証 を、フルノードのオーバーヘッドなしに提供できます。ユーザーは自身のUTxOを検証し、受信トランザクションを検証し、軽量ウォレットのUXを享受しながら資金に対する完全な主権を維持できます。

軽量ノード層でのクライアント多様性

Cardanoのレジリエンスは、複数の独立して開発されたクライアント実装を持つことから恩恵を受けます。Gerolamoは TypeScriptネイティブのブラウザターゲット軽量ノード をその風景に追加し、単一クライアントのバグや前提が依存するウォレットおよびdAppに波及するリスクを削減します。

研究配当 ― ブラウザノード開発が産むエコシステム全体への波及効果

ブラウザで動くほど小さなノードを構築することは、単なるパッケージング作業ではありません。Cardanoエコシステム全体がいずれ必要とする一連の問題への実進歩を強制します：

コンパクト / 簡潔検証

Gerolamoの構築は、何が 必ず再検証されるべきか と何が要約・証跡化・チェックポイント化可能かを厳密に区別することを要求します。Mithril様の証明書、partial state proof、暗号アンカー付きヘッダーチェーン検証といった同じテクニックが、Trustless BridgeとRollupの構築ブロックそのもの です。

将来コンセンサス作業（Leios等）への強制制約

本物のブラウザ内検証ノードを維持することで、将来のいかなるコンセンサスプロトコルアップグレード（最も差し迫った例はLeios）も軽量リソースで検証可能であり続けなければならない という厳しい制約が生まれます。Gerolamoのようなアーティファクトがテーブル上に存在しなければ「これはまだライトクライアントで扱いやすいか？」という問いを後回しにできてしまいますが、存在すればこの問いが事前に強制されます。

Trustless Bridge

チェーンBのブリッジコントラクトがCardanoの状態を検証する必要がある場合、ブラウザノードが必要とするのと同じプリミティブが必要となります：Cardanoのチェーン履歴を安価、簡潔、非対話的に確認する方法です。Gerolamoの検証パスへの投資は、ブリッジ実装がさもなくばゼロから再導出するコンポーネントを生成し、battle-testします。

Layer 2システム

楽観的およびValidity Rollup様のL2がCardano上で必要とする 効率的で埋め込み可能なL1状態のVerifier は、構造的にブラウザノードと同じアーティファクトです。最小信頼、最小フットプリント、他のランタイム内に埋め込むよう設計された軽量ノード。Gerolamoへの投資はL2エコシステム全体に償却されます。

dApp側検証

チェーン上に移動する価値が増えるにつれ、dAppは自身のバックエンドを信頼するのではなく、チェーン状態を自ら検証する必要が増します。Gerolamoは各チームが自前で実装する代わりに、ドロップイン可能な監査済みJavaScriptネイティブVerifier を提供します。

「ブラウザ内ノード」のマーケティング価値を脇に置いたとしても、Gerolamoの構築に必要なエンジニアリングは、Cardanoエコシステムがブリッジ・L2ロードマップを実現するために必要な 基礎研究 です。Gerolamoへの資金提供は、その基礎への資金提供です。

EC-0014-25回顧録 ― 4月10日投票からの実質的変化

これが当初提案からの最も重要な追加情報です。

HLabsの初トレジャリーファンディング作業 EC-0014-25 Gerolamoトレジャリー契約（₳578,571、2025年8月12日〜2026年3月30日実行）に関する2025 Retrospectiveが、IPFS（QmZVw82XNXNsgGmBj39R26Mx7jgzWaNjSw4A7JM9Erye9c）で公開されました。

回顧録は計画13項目のうち以下を記録しています：

ステータス	項目
✅ 完納 (11/13)	Ouroboros mini-protocols / multi-era chain sync (Shelley〜Conway) / block & header parsing / VRF検証付きheader validation / transaction submission / block validation with ledger state update / rollback handling / full storage (volatile + immutable chunks + WAL concurrency) / HTTP Block API / mempool management / terminal UI & structured logging
🟡 進行中 (2/13)	P2P peer management（複数ピア対応自体は実装済み、動的ピア選択が次フェーズ）／ Mithril integration（初期サポート実装済み、改善継続中）

加えて、Browser compatibilityはEC-0014-25下で進行中として明示的にスコープされ、次フェーズを促進するための設計決定がなされていました ― これがまさに本再提出のスコープそのもの です。

特筆すべきは、回顧録が次の事実も記録していることです：

ADA/USDレートが提出時の約0.7から現在0.3以下に下落したことで、プロジェクトの評価額はUSD換算で著しくアンダーペイメントとなった。Harmonic Laboratoriesは、極めて厳しい条件下でも約束通り出荷し続けたことを誇りに思う。

つまり、HLabsは 資金が実効的に半分以下になっても履行した実績 を有しています。これは「資金提供を受けても市場環境次第で履行しない」リスクへの、過去実績ベースの強い反証です。

SIPOはこの回顧録を、当初4月10日投票時には存在していなかった有意義なトラックレコードシグナルとして、再提出案件の評価を実質的に強化するものと位置づけます。

当初提案との差分 ― 何が構造的に変わったか

SIPOは当初提案に対し「期待事項付きYES」を投じる際に、7つの拘束力ある運用上のコミットメントを期待事項として示しました。そのうち本Gerolamo提案に該当する5項目について、再提出版での応答を確認します：

① 月次ベロシティの透明性

Pebbleと同標準（Monthly Lightweight Updates、四半期詳細レポート、公開トランザクションジャーナル）がHarmonicLabs/2026-treasury-proposalリポジトリで運用されます。

② 軽量ノード文脈でのハードフォーク対応

本提案はGerolamoを明示的にdAppおよびウォレット向けの軽量ノードであり、ブロック生成ノードではないとスコープしています。本スコープのHF対応は、ブロックプロデューサー（V4 codegenと改訂コストモデルをオンチェーンに出荷する必要がある）より構造的に軽量ですが、ゼロではありません：ブラウザ軽量ノードはPlutus V4メインネットに対して同期、Praosヘッダー検証、Plutusスクリプト評価、UTxOクエリ提供を継続できる必要があります。Milestone 1（Q2 2026）はブラウザストレージ層（IndexedDB）、ネットワーキング層（Ouroboros mini-protocols over Web Workers / WebSockets + proxy）、およびブラウザコンテキストからpublic preprodのtipまでの同期を配送します。

SIPOは、本作業が来たるべきintra-eraハードフォークを通じて整合的であり続けることを、下記の拘束力ある期待事項で明示的に求めます。

③ 過去Catalyst / トレジャリー案件の説明責任

上記EC-0014-25回顧録により対応されています。SIPOは公開された回顧録を期待事項への実質的回答と評価し、特にそれがGerolamoが拡張するまさにその作業をカバーしている点を重視します。

④ Aiken補完関係

Gerolamoはスマートコントラクト言語ではなく軽量ノードのため、Aiken補完性は直接適用されません。ただしOversight BoardにLucas Rosa氏（Aiken、Midnight）が含まれており、Cardanoエコシステム横断的なガバナンスはPebble提案と同様に確保されています。

⑤ 25%コンティンジェンシー規律

Pebbleと同様、コンティンジェンシーを25%から15%へ削減（絶対値10ppダウン）、返還可能リザーブとして構造化、契約満了時の未使用分は契約レベル強制でCardanoトレジャリーへfailsafe sweep。

ガバナンス構造の評価

Pebble提案と同一のガバナンス構造です：

資金は SundaeLabs treasury-contracts フレームワーク（TxPipeとMLabsにより独立監査済み）に保持
Independent Oversight Board：Santiago Carmuega（TxPipe、Dolos）、Lucas Rosa（Aiken、Starstream、Midnight）、Chris Gianelloni（BlinkLabs、Dingo）の3名構成、いずれもHLabsに持分なし
権限スキーム：定期支払にHLabs + ボードメンバー1名、構造変更にHLabs + ボード過半数、任意の単一ボードメンバーがマイルストーン一時停止可能
エスクロー中のトレジャリー資金は DRepレベルでAuto-abstain強制 かつ SPO委任不可
契約満了時の未使用資金は契約強制 failsafe sweep でCardanoトレジャリーへ自動返却

SIPOがAmaru、Dingo、IOG 9提案ラウンド、Blockfrost、Pogunに対して承認したのと同じガバナンス標準です。

マイルストーン構造 ― 検証可能な配送計画

マイルストーン	期間	配送内容	配分（base + contingency）
M0	起動時	プロジェクト初期化・ガバナンス設定	₳400,000（10%、コンティンジェンシーなし）
M1	Q2 2026	ブラウザストレージ + ネットワーキング + preprod sync	₳900k + ₳150k = ₳1,050,000
M2	Q3 2026	公開拡張機能ストアリリース + 簡易クエリAPI（非インデックス）	₳900k + ₳150k = ₳1,050,000
M3	Q4 2026	インデックスクエリAPI（UTxO by Address & Asset）	₳900k + ₳150k = ₳1,050,000
M4	Q1 2027	安定性ハードニング + ブラウザリーチ拡大 + ドキュメンテーション	₳900k + ₳150k = ₳1,050,000

各マイルストーンは、コミットされたGitHubリリース、コミット済み同期ログ、公開デモURL、preprodでの成功txといった公開アーティファクトから客観的に検証可能なAcceptance Criterionが定義されています。

M4のプロダクションレディネス基準は特に明確で、≥15ピアとの≥24時間安定接続、≥3別個ブラウザセッションでのtipまでの同期、少なくとも1つの非Chromiumエンジン（Firefoxまたは Safari）での検証（screencastリポジトリコミット必須）、および統合・APIドキュメントのリポジトリ公開が求められます。

SIPOが新たに付す拘束力ある運用上の期待事項

SIPOのYESは、以下が拘束力ある運用コミットメントとして扱われ、Independent Oversight Committeeの公開レビューに基づき、コミュニティが四半期ごとに評価することを条件とします：

ブラウザ軽量ノードのHF整合性をM2（Q3 2026）までに実証：Gerolamoはブラウザコンテキストから公開Plutus V4テストネットをtipまで同期し、runをログ記録してリポジトリにコミット。SIPOはGerolamoがV4 codegenを出荷することを要求しない（それはPebbleのスコープ）が、intra-eraハードフォークを通じて軽量ノードが有効なPlutus V4 verifierであり続けることを要求する。実証失敗時はM2支払を一時停止すべき。
プロダクションレディネス基準は再現可能・第三者検証可能な証跡で達成：M4の4基準（≥15ピアとの≥24時間安定peer-set、≥3別個ブラウザセッションでの同期、少なくとも1つの非Chromiumエンジンでの検証、リポジトリでのintegration & APIドキュメント公開）はゲートであり、願望ではない。SIPOはOversight Committeeがコミットされたrunログ、peer-list snapshot、screencastに対してこれらを検証し、M4支払共同署名前に簡潔な検証ノートを公開することを期待。
スコープ封じ込めは拘束力：本ファンディング期間中、ブロック生成、サーバーサイドリレー役割、フルノード用途への方向転換は、独自監査計画（提案自体がブロック生成追加には約$500k追加監査と少なくとも追加1 FTEが必要と注記）をもつ別個ガバナンスアクションとして戻されるべきであり、現在の申請に吸収されるべきではない。
採用指標は名前付き統合で報告：本提案は12ヶ月以内に≥3のwallet / dApp統合にコミット。SIPOはこれらが四半期ごとに、統合プロジェクト名、統合コミットまたは公開リリースノートへのリンク、および統合プロジェクト側からの同意確認をもって報告されることを期待する。匿名統合カウントは不可。
Mithril統合の完了：EC-0014-25回顧録はMithril統合を初期サポート実装済みで進行中と記録。SIPOはMithril統合が本ファンディング期間中に文書化された完了状態に到達することを期待し、ブラウザコンテキストからのMithrilアンカーbootstrapを実証するタグ付きリリースと、初期同期時間削減に関する公開ベンチマークを伴うべきである。
Trustless Bridgeプリミティブ波及は引き継ぎ時に文書化：M4 hand-off / ‘what’s next’レポートは、Gerolamo向けに開発された検証プリミティブ（succinct certificates、cheap header validation、embeddable verifiers、partial state proofs）のうち、trustless bridge、L2 verifier、dApp側検証に再利用可能なものを明示的に識別すべきである。これはGerolamoのエンジニアリング投資を、より広範なエコシステムが構築できる公共財資産に変換する文書化ステップ。
コンティンジェンシー使用は公開会計：マイルストーンベースライン分を超える₳600,000コンティンジェンシーリザーブの支払はすべて、四半期レポートおよびトランザクションジャーナルに公開正当化エントリを伴うものとし、原因と引き出し額を識別する。契約満了時の未使用コンティンジェンシーはSundaeLabs failsafeを通じてCardanoトレジャリーへ返却されること。
Independent Oversight Committeeレビューの安定フォーマット公開：マイルストーン進捗、KPI推移、遅延理由、次四半期のクリティカルパスを、四半期間で比較可能な形で公開すること。SIPOがAmaru・Dingoに求めてきたのと同じ報告規律を期待。

過去投票スタンスとの整合性

ノード多様性ドクトリン

Amaru（Rust）→ YES、Dingo（Go）→ YES、原 HLabs Pebble + Gerolamo Budget → YES（期待事項付き）、本Gerolamo再提出 → YES。Haskell単一実装リスク軽減（Ethereum Prysmインシデント2026-03が証明）の論理を、ブロックプロデューサー軸からブラウザターゲット軽量ノード軸へと 構造的に拡張 するもの。

EUTXO×Browser Node = Cardano-only USPドクトリン

SIPOは内部ドクトリンとして、L2＋ wrapped bridge設計が頭打ちになりつつあり、Cardanoの構造的優位性は競合がベースレイヤーを書き換えない限り模倣できないUTxOネイティブ設計にあると保持してきました。Gerolamoはこの潜在的優位性を実際に出荷可能なプロダクトに変換するプロジェクトであり、本ドクトリンと完全に整合します。

Cardano 2030戦略整合

本提案はCardano 2030戦略フレームワークの Pillar 1（Infrastructure & Research Excellence）I.2 Security & Resilience → Client Diversity と直接整合し、形式的2030 KPI「Alternative full-node clients ≥2 spec-conformant」に対する直接貢献を測定可能な採用指標（≥3 wallet / dApp統合）とともに公開しています。

Treasury Fitドクトリンv2.0照合

8シグナル中0件hit：HLabsは自己資金不可能なR&D企業、Oversight Board構造は三重利益相反パターンを防止、本提案は公共財インフラ（完全検証ブラウザターゲット軽量ノード + ブリッジ・L2 verifierに波及する検証プリミティブ）であってブランドマーケティングではなく、IOG presenceは構造的に必要ではなく、具体的でニュース価値のある技術的デリバラブル（Cardano上初のプロダクションレディなin-browser検証ノード、公開拡張機能ストア掲載、indexed UTxOクエリAPI）を含み、イベント提案ではない。Treasury Fitはポジティブ。

結び

SIPOは本提案を、当初HLabs 2026 askのブラウザ軽量ノード半分の、首尾一貫した構造的に改善された再提出として評価し、EC-0014-25回顧録により実質的に強化されたものと位置づけます。SIPOが当初YESに付した拘束力ある期待事項のすべてが、再提出されたテキストとマイルストーン構造で対応されています。基礎にある公共財ケース — CardanoのeUTxOネイティブなアーキテクチャ特性を、dAppとウォレットが信頼バックエンドなしに依拠できる出荷可能で完全検証なブラウザノードに変換し、同時にブリッジ・L2ロードマップ全体に複合する検証プリミティブを生み出すこと — は弱まっていません。

ノード多様性の第4軸（Haskell / Rust / Go / TypeScript-WASM）は、SIPOが既に二度承認したドクトリンを拡張します。

SIPOのYESは、デリバリーから切り離されたHLabsという組織への信認票ではありません。本提案の特定の作業スコープを、特定の予算水準で、特定のガバナンス構造のもとで資金提供する価値があるとの判断票です。ただし、上記の8つの期待事項が拘束力ある運用上のコミットメントとして扱われ、各支払前にIndependent Oversight Committeeによって検証されることを条件とします。

以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。

SIPO DRep: How We View the Resubmitted “The First Node in the Browser; a Cardano USP (Gerolamo)” Proposal ― Analysis, YES Vote, and Stance

Introduction

This article presents SIPO DRep’s analysis and decision on the governance action “The first node in the browser; a Cardano USP,” submitted in Epoch 629 on 2026-05-05.

This is a Treasury Withdrawal proposal submitted by Harmonic Laboratories (HLabs), requesting ₳4,600,000 (approximately $1.15M at $0.25 ADA/USD). Over a 12-month period, it funds the development of Gerolamo, a fully-validating Cardano light node packaged as a browser extension.

This is not a standalone new proposal. The original HLabs 2026 Budget proposal (a single ₳8,035,714 ask), on which SIPO voted YES with expectations on 2026-04-10, narrowly missed DRep ratification at 66.78%, just below the 67% threshold. HLabs responded to community feedback by splitting the work into two independently-votable proposals. This is one half. The other half (“Pebble & Ecosystem Maintenance: TypeScript Core of Cardano”) is covered in a separate article.

The Gerolamo half is materially strengthened by the published EC-0014-25 retrospective, which did not exist at the time of the original April 10 vote.

SIPO votes YES on this proposal. Below we lay out why Gerolamo is a Cardano-only structural USP, how the original five expectations are addressed, and the eight new binding operational expectations SIPO attaches to this YES.

Why Gerolamo Is a Cardano-Only Structural USP

“A node that runs in the browser” has been talked about across the L1 landscape for years. Yet no major chain has shipped a fully-validating browser node. The reason lies in base-layer design.

Cardano’s eUTxO design has architectural properties no other major chain can match: eUTxO state stays local to the transaction; block sizes and bandwidth requirements are bounded and modest; consensus (Praos) is verifiable on light resources; Plutus scripts are pure functions over a deterministic CEK machine, straightforward to host in a JavaScript / WebAssembly runtime. Together, these properties make Cardano the only major chain where a fully-validating in-browser node is technically realistic today.

Gerolamo turns this latent architectural advantage into a shipped product. Not a research demo, not a stripped-down SPV client — a real node running consensus, validating headers and blocks, and evaluating Plutus scripts, all inside a browser extension on the user’s machine. This is a concrete differentiator Cardano can put in front of developers, wallet teams, enterprises, and regulators.

Gerolamo as the Fourth Axis of Node Diversity

SIPO voted YES on Amaru (Rust) and Dingo (Go) on the basis that Haskell single-implementation risk is real (the Ethereum Prysm incident of 2026-03 is the canonical reference). Gerolamo extends this doctrine to a fourth axis: TypeScript / WebAssembly, but in a structurally different role — a light validating node for dApps and wallets, not a block producer.

The proposal explicitly scopes server-side relay roles, block production, and other full-node use cases as out-of-scope, noting that adding block production would require an additional ~$500k audit plus at least one additional FTE. This is the strongest possible structural answer to a node-diversity concern: Amaru / Dingo (block producers) and Gerolamo (light node) support the same doctrine in different roles.

Why Gerolamo Is Needed ― The Structurally Missing Piece

Most Cardano dApps today rely on centralized indexers or third-party APIs to query chain state. A production-ready browser node lets dApps query a fully-validating light node hosted by a browser extension the user installs once, providing direct, trustless access to the Cardano ledger without any backend dependency. Light wallet developers can integrate Gerolamo to offer Daedalus-grade security guarantees without the overhead of running a full node. And Gerolamo contributes a TypeScript-native, browser-targeted light node to client diversity, reducing the risk that a bug in any single client cascades through the wallets and dApps that depend on it.

Research Dividend ― Ecosystem-Wide Spillover

Engineering a node small enough to run in a browser is not a packaging exercise. It forces real progress on a class of problems the broader Cardano ecosystem will need anyway: compact / succinct validation (Mithril-style certificates, partial state proofs, header-chain verification — the same building blocks of trustless bridges and rollups); a forcing function for future consensus protocols (Leios and beyond must remain verifiable on light resources); trustless bridge primitives (a bridge contract on chain B needs the same succinct verification primitive as a browser node); Layer 2 verifiers (structurally the same artifact as a browser light node); and dApp-side verification (a drop-in, audited, JavaScript-native verifier replaces every team rolling its own).

Even setting aside the marketing value of “node in the browser,” the engineering required to ship Gerolamo is foundational research the Cardano ecosystem needs in order to deliver on its bridges-and-L2 roadmap.

The EC-0014-25 Retrospective ― Material Change from April 10

This is the most important new information added since the original proposal. The HLabs 2025 Retrospective covering HLabs’s first treasury-funded work, the EC-0014-25 Gerolamo Treasury Contract (₳578,571, executed 2025-08-12 to 2026-03-30), has been published at IPFS QmZVw82XNXNsgGmBj39R26Mx7jgzWaNjSw4A7JM9Erye9c.

The retrospective documents 11 of 13 planned items as fully shipped (Ouroboros mini-protocols, multi-era chain sync, block/header parsing, header validation with VRF, transaction submission, block validation with ledger state updates, rollback handling, full storage with WAL concurrency, HTTP block API, mempool management, terminal UI / structured logging) and 2 of 13 as in progress with foundations in place (P2P peer management — multi-peer handling implemented, dynamic peer selection is next; Mithril integration — initial support integrated, ongoing).

Notably, browser compatibility was explicitly scoped as in-progress under EC-0014-25, with design decisions made to facilitate the next phase — precisely the scope of this resubmission. And HLabs delivered on all commitments despite the project being effectively underfunded by more than half in USD terms (ADA/USD dropped from ~0.7 at submission to under 0.3 today).

SIPO treats this retrospective as a meaningful track-record signal that did not exist at the time of the original 2026-04-10 vote.

What Changed Structurally from the Original

SIPO’s original YES vote was conditional on seven binding operational commitments. The five that apply to this scope are addressed as follows in the resubmission:

Monthly velocity transparency: same standard as Pebble (Monthly Lightweight Updates, Quarterly Reports, Public Transaction Journal).
HF readiness in light-node context: M1 (Q2 2026) delivers browser storage (IndexedDB), networking (Ouroboros mini-protocols over Web Workers / WebSockets), and a preprod sync from a browser context. HF coherence required by M2 — added as a binding expectation below.
Past Catalyst accountability: addressed by the EC-0014-25 retrospective above, particularly relevant because it covers the very work Gerolamo extends.
Aiken complementarity: Gerolamo is not a language, but Lucas Rosa (Aiken, Midnight) on the Oversight Board ensures cross-ecosystem governance perspective as in Pebble.
25% contingency discipline: reduced to 15%, structured as a refundable reserve with contract-enforced failsafe sweep.

Governance Structure

Identical to the Pebble proposal: SundaeLabs treasury-contracts framework (TxPipe + MLabs audited); Independent Oversight Board of Santiago Carmuega (TxPipe, Dolos), Lucas Rosa (Aiken, Starstream, Midnight), Chris Gianelloni (BlinkLabs, Dingo); auto-abstain DRep delegation on escrow; failsafe sweep at contract expiration. The same governance standard SIPO has approved for Amaru, Dingo, the IOG 9-proposal round, Blockfrost, and Pogun.

SIPO’s New Binding Operational Expectations

Hard-fork coherence for the browser light node demonstrated by M2 (Q3 2026): Gerolamo must sync a public Plutus V4 testnet to tip from a browser context, with the run logged and committed to the repo. SIPO does not require Gerolamo to ship V4 codegen (that is Pebble’s scope), but does require the light node to remain a valid Plutus V4 verifier across the intra-era hard fork.
Production-readiness criteria met with reproducible, third-party-verifiable evidence: the four M4 criteria (≥15 peers / ≥24-hour stable peer-set, sync across ≥3 separate browser sessions, verification on a non-Chromium engine with screencast committed, integration / API documentation published) are gates, not aspirations.
Scope containment binding: any pivot toward block production, server-side relay roles, or full-node use cases during this funding period should come back as a separate governance action with its own audit plan.
Adoption indicator reported with named integrations: the ≥3 wallet / dApp integrations should be reported quarterly with project names, integration commit or release links, and consenting projects’ confirmation. Anonymous integration counts are not sufficient.
Mithril integration completion: a documented completion state during this funding period, with a tagged release demonstrating Mithril-anchored bootstrap from a browser context and a public benchmark on initial-sync time savings.
Trustless bridge primitives spillover documented at the M4 hand-off: the “what’s next” report must explicitly identify which verification primitives developed for Gerolamo are reusable for trustless bridges, L2 verifiers, and dApp-side verification.
Contingency drawdown publicly accounted for: any disbursement of the ₳600,000 contingency reserve beyond the milestone-baseline portions must be accompanied by a public justification entry. Unused contingency at contract expiration must sweep back to the Cardano treasury via the SundaeLabs failsafe.
Independent Oversight Committee reviews published in a stable, quarter-over-quarter comparable format.

Closing

SIPO views this proposal as a coherent and structurally improved resubmission of the browser-light-node half of the original HLabs 2026 ask, materially strengthened by the EC-0014-25 retrospective. The underlying public-good case — turning Cardano’s eUTxO-native architectural property into a shippable, fully-validating browser node that dApps and wallets can rely on without trusted backends, while producing verification primitives that compound across the bridges and L2 roadmap — has not weakened. The fourth axis of node diversity (Haskell / Rust / Go / TypeScript-WASM) extends a doctrine SIPO has already endorsed twice. For these reasons, SIPO DRep votes YES.

References

Proposal IPFS metadata: ipfs://QmbQPrRhUUtvqNitu9mgC8esM3kXmR5iHGhEkLX1UZaLDy
HLabs proposal repo: https://github.com/HarmonicLabs/2026-treasury-proposal
Gerolamo repo: https://github.com/HarmonicLabs/gerolamo
Pebble repo: https://github.com/HarmonicLabs/pebble
2025 Retrospective (EC-0014-25): https://gateway.pinata.cloud/ipfs/QmZVw82XNXNsgGmBj39R26Mx7jgzWaNjSw4A7JM9Erye9c
EC-0014-25 Treasury Contract: https://treasury.sundae.fi/instances/9e65e4ed7d6fd86fc4827d2b45da6d2c601fb920e8bfd794b8ecc619/project/EC-0014-25
SundaeLabs treasury-contracts: https://github.com/SundaeSwap-finance/treasury-contracts
Cardano 2030 Strategic Framework: https://product.cardano.intersectmbo.org/vision/strategy-2030/

DRep, ニュース, ...