DRepTalk
Sign in
Enter as DRepEnter as SPOEnter as CC memberEnter as proposerRegister as DRep
Governance ActionsDiscussionsDRepsTreasury
Sign in
More ways to sign in
Enter as SPOEnter as CC memberEnter as proposerRegister as DRep

The first node in the browser; a Cardano USP

System2mo ago1 post
DReps 182SPOs 0

182 DReps voted · 73 with a rationale · 12 changed their vote

Open a row to read the rationale.

  • Yoroi W₳llet
    Abstain584.2M ₳Rationale

    Summary
    Yoroi DRep votes ABSTAIN on "The first node in the browser; a Cardano USP." This position reflects a continuation of our view on node diversity sequencing and is not a judgment on HLabs or the quality of their work.
    Rationale
    Yoroi acknowledges the effort to resubmit with a narrower scope.
    HLabs has responded to community feedback by separating this proposal from the broader combined request and reducing the budget significantly. That responsiveness is appreciated, and the browser-node concept remains technically compelling for the reasons the proposal articulates well.

    Our reservations about TypeScript as a node foundation remain open.
    Conversations with developers and engineers in the ecosystem continue to surface questions about whether TypeScript is the right choice for production-grade node infrastructure. We do not hold this view with certainty and remain open to hearing from those who see it differently, but it continues to factor into our position.

    The sequencing question has not materially changed.
    With Amaru and Dingo already funded and working toward alternative node readiness, the case for a third implementation in the same cycle remains difficult to establish, even accounting for the distinct browser-focused scope of this proposal. Yoroi would find it easier to support Gerolamo in a future cycle once the existing funded efforts have progressed further toward their delivery targets.

    Conclusion
    Yoroi has genuine respect for HLabs and the contributions they continue to make to the Cardano TypeScript ecosystem. Our decision to abstain reflects a considered view on timing and sequencing rather than any objection to the team or the concept. We would welcome a future proposal once the broader node diversity landscape has had time to mature and would hope to be in a position to support it at that point.

  • YUTA
    YesChanged435.8M ₳Rationale

    Voting YES on "The first node in the browser; a Cardano USP."

    • Given the high maintenance costs of the Haskell node, further competition is needed.
    • I have confirmed that current DApp developers who generate transactions on mainnet intend to actively use this after Geronimo's development, provided it is properly developed. If properly developed, this will reduce the burden on developers. If properly developed, other DApp developers may also take interest.

    「The first node in the browser; a Cardano USP」にYESを投票します。

    ・Haskellノードの高額な保守費用を考えると、さらなる競争が必要です。
    ・現在メインネットでTxを生むDApps開発者から、ジョロラモの開発後は、これが適切に開発された場合、積極的にこれを使用したい意向を確認しました。適切に開発された場合は、これは開発者の負担を軽減します。適切に開発されれば、その他のDApps開発者も興味を持つ可能性があります。

    Earlier votes

    No2mo agoSuperseded

    I vote NO to "The first node in the browser; a Cardano USP".

    I have asked many developers about this, but I have not been able to find any developers who would want to use it. While it is difficult to foresee this demand beforehand, as the proposer claims, I may be requesting the same criteria from other proposals, so I need to maintain consistency. However, I may change this vote if I can find more evidence of demand for Goloramo.

    —

    私は「The first node in the browser; a Cardano USP」にNOを投票します。

    私は多くの開発者にこれについて聞きましたが、これを使用したい開発者を見つけることができませんでした。提案者が主張しているようにこの需要を事前に把握することは困難な作業ですが、しかしながら、私は他の提案書にも同じ基準を要求している場合がありますので、それと一貫性を保つ必要があります。ただし、Goloramoの需要についての裏付けが取れたらこの投票を変更する可能性があります。

  • EMURGO
    Abstain293M ₳Rationale

    Summary
    EMURGO as a DRep votes ABSTAIN on the treasury withdrawal titled "The first node in the browser; a Cardano USP", with rationale outlined below.
    Rationale
    EMURGO recognises the technical effort behind this resubmission and acknowledges that HLabs has responded constructively to community feedback by separating proposals and narrowing the scope of this request. A browser-native validating node is a genuinely differentiated capability, and Cardano's eUTxO architecture does create meaningful conditions for it that other chains cannot easily replicate.

    Our position carries over from our view on the earlier combined proposal. Questions raised through conversations with external technologists about TypeScript as the foundation for a production-grade node environment remain open. We hold that view with humility and do not consider it settled, but it continues to inform our assessment. Additionally, with Amaru and Dingo already funded and progressing, the case for committing treasury resources to a third node implementation in the same cycle, even one scoped to a distinct browser use case, is not yet clearly established to our satisfaction. The Cardano 2030 framework targets two live alternative node clients, a benchmark that existing funded efforts are already working toward.

    We appreciate HLabs's continued engagement with the ecosystem and the deliberate effort to right-size this request. Our abstain reflects a continuation of our considered position on node diversity sequencing rather than any new concern about the team or the concept itself.

  • CryptoCrow
    Yes254.7M ₳No rationale
  • Eternl DRep Committee
    Yes222.9M ₳Rationale

    YES on Pebble & Ecosystem maintenance: TypeScript core of Cardano;

    In line with our previous vote, we support HLabs' proposals.

  • Sebastien Guillemot セバ
    Abstain174.6M ₳Rationale

    See my previous rationale for why I'm skeptical of this proposal. However, with the fact this proposal now is separate from Pebble, and the fact the amount was lowered a bit, I think this is sufficient for me to change from a "no" to an "abstain"

  • Everstake
    Yes165.7M ₳No rationale
  • Cardano Foundation
    NoRevoted120.2M ₳Rationale

    While we appreciate Harmonic Laboratories and the unbundling of this initiative, the $1.15M ask for a browser-based node currently lacks broad market validation, faces significant technical constraints, requires more rigorous acceptance criteria, and is missing key architectural design decisions.

    A PDF version of this rationale is also made available.

    Our assessment team and internal Subject Matter Experts (SMEs) have thoroughly reviewed this proposal. While the concept of a trustless browser node is innovative and conceptually intriguing, we are unable to support this treasury withdrawal due to the combination of the following considerations:

    1. Lack of Market Validation: We are concerned about the potential traction for Gerolamo. While it is a fascinating tool, it currently appears tailored to a relatively niche audience, which does not yet justify a treasury expenditure of this scale. We respectfully suggest that an idea like this might be better suited for initial bootstrapping. If the broader market and user base demonstrate strong demand, it could certainly be reconsidered in the future.
    2. Significant Technical Constraints: The technical feasibility of running a fully validating node within a browser presents notable challenges. Managing the Cardano Ledger State via IndexedDB is highly ambitious given that modern browsers restrict local storage, which introduces risks of performance degradation or data eviction over time. Furthermore, an independent review of the current public repositories suggests the codebase currently defers intricate calculations to centralized infrastructure (like Blockfrost) rather than executing true local ledger management. This draws into question the core premise of a fully trustless node.
    3. Refining Acceptance Criteria: The current milestones define "production readiness" primarily through connectivity metrics (e.g., syncing to tip). While important, we believe a production-ready validating node requires more comprehensive benchmarks. We strongly encourage the inclusion of rigorous, property-based conformance testing or differential testing against the core node to mathematically guarantee the correctness of ledger validation.
    4. Missing Architectural Design Decisions: The proposal would greatly benefit from a more robust and detailed architectural blueprint. Given the well-documented limitations of browser environments, we would need a clearer technical explanation of exactly how Gerolamo will sustainably navigate these resource constraints during extended use to ensure long-term stability and reliability.
    5. Budget Transparency and Efficiency: The proposal requests 5 Full-Time Equivalents (FTEs) structured as a lumped sum of $200k/FTE, plus a 15% contingency, totaling $1.15M. For a project that is “mostly done” as written in the proposal, with only limited API integration work and packaging remaining, we struggle to justify the requested amount. We also note that Harmonic Laboratories was already funded in 2025 through the Intersect budget administration process to deliver a “fully functional light node that can run in the browser.” An additional treasury request of $1.15M for what seems to be a continuation of that workstream at substantially higher FTE rates is not something we can support.

    The Cardano Foundation votes NO for this proposal. We respect the HLabs team and their ongoing contributions to the ecosystem. However, due to the need for initial market validation, significant technical constraints, questions around budgeting, and the need for more defined acceptance criteria, we cannot support this treasury funding commitment.

    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.

    Earlier votes

    No2mo agoSuperseded

    While we appreciate Harmonic Laboratories and the unbundling of this initiative, the $1.15M ask for a browser-based node currently lacks broad market validation, faces significant technical constraints, requires more rigorous acceptance criteria, and is missing key architectural design decisions.

    A PDF version of this rationale is also made available.

    Our assessment team and internal Subject Matter Experts (SMEs) have thoroughly reviewed this proposal. While the concept of a trustless browser node is innovative and conceptually intriguing, we are unable to support this treasury withdrawal due to the combination of the following considerations:

    1. Lack of Market Validation: We are concerned about the potential traction for Gerolamo. While it is a fascinating tool, it currently appears tailored to a relatively niche audience, which does not yet justify a treasury expenditure of this scale. We respectfully suggest that an idea like this might be better suited for initial bootstrapping. If the broader market and user base demonstrate strong demand, it could certainly be reconsidered in the future.
    2. Significant Technical Constraints: The technical feasibility of running a fully validating node within a browser presents notable challenges. Managing the Cardano Ledger State via IndexedDB is highly ambitious given that modern browsers restrict local storage, which introduces risks of performance degradation or data eviction over time. Furthermore, an independent review of the current public repositories suggests the codebase currently defers intricate calculations to centralized infrastructure (like Blockfrost) rather than executing true local ledger management. This draws into question the core premise of a fully trustless node.
    3. Refining Acceptance Criteria: The current milestones define "production readiness" primarily through connectivity metrics (e.g., syncing to tip). While important, we believe a production-ready validating node requires more comprehensive benchmarks. We strongly encourage the inclusion of rigorous, property-based conformance testing or differential testing against the core node to mathematically guarantee the correctness of ledger validation.
    4. Missing Architectural Design Decisions: The proposal would greatly benefit from a more robust and detailed architectural blueprint. Given the well-documented limitations of browser environments, we would need a clearer technical explanation of exactly how Gerolamo will sustainably navigate these resource constraints during extended use to ensure long-term stability and reliability.
    5. Budget Transparency and Efficiency: The proposal requests 5 Full-Time Equivalents (FTEs) structured as a lumped sum of $200k/FTE, plus a 15% contingency, totaling $1.15M. For a project that is “mostly done” as written in the proposal, with only limited API integration work and packaging remaining, we struggle to justify the requested amount. We also note that Harmonic Laboratories was already funded in 2025 through the Intersect budget administration process to deliver a “fully functional light node that can run in the browser.” An additional treasury request of $1.15M for what seems to be a continuation of that workstream at substantially higher FTE rates is not something we can support.

    The Cardano Foundation votes NO for this proposal. We respect the HLabs team and their ongoing contributions to the ecosystem. However, due to the need for initial market validation, significant technical constraints, questions around budgeting, and the need for more defined acceptance criteria, we cannot support this treasury funding commitment.

    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.

  • JAZZ
    YesChanged92.2M ₳History

    Earlier votes

    Abstain2mo agoSuperseded

  • CardanoYoda (MANDA Pool)
    Yes91.5M ₳Rationale

    As a DRep, I decided to vote YES for the proposal: The first node in the browser; a Cardano USP.

    This proposal concerns Gerolamo, a TypeScript implementation of a Cardano node, scoped specifically to the browser-extension light-node use case. The goal is to deliver a production-ready Cardano light node that can run in the browser and expose a messaging API to dApps and wallets. This would allow applications to obtain locally verified chain data instead of relying entirely on trusted external servers.

    The main reason I support this proposal is that Gerolamo could help move Cardano wallets and dApps toward a more trust-minimized model. Today, many applications depend heavily on backend providers, indexers, APIs, or other server-side infrastructure. This is convenient, but it also creates dependency on external services. A browser-based validating node could allow users and developers to interact with Cardano with stronger local verification guarantees.

    This does not only matter for users who explicitly demand maximum sovereignty. Most users probably do not think in terms of “full validation” or “trust minimization.” However, they can still benefit from applications that are more reliable, more responsive, and less dependent on centralized infrastructure. If delivered successfully, Gerolamo could make stronger security assumptions available through ordinary browser-based applications.

    I also see value in Gerolamo from the perspective of client diversity. Cardano should not rely forever on a single dominant node implementation or one main codebase at the networking and validation layer. Gerolamo is not funded here as a block-producing node, and server-side relay roles are explicitly out of scope under this proposal. However, a successful TypeScript implementation of ledger validation, networking, and browser-based node architecture could become an important foundation for future alternative node work.

    That said, my YES vote is not without concerns.

    I also note that Gerolamo has received previous funding, and based on the public project status, the final milestone from that earlier funding appears to remain paused or unfinished. I do not consider this, by itself, a reason to reject the current proposal, especially because the new proposal has a clearer scope and a stronger milestone-based structure. However, I would still like HLabs to provide a clear retrospective on the previous funding.

    Second, the proposal still carries high execution risk. A browser-based Cardano node is technically plausible, but difficult. The hardest part is not simply making something sync in a browser. The hard part is the correct and robust implementation of ledger rules, chain selection, rollback handling, Plutus validation, protocol parameter changes, storage behavior, and conformance with the reference implementation.

    The author's clarification was useful, especially regarding the proxy architecture, Mithril, browser runtime assumptions, and the distinction between technical feasibility and production readiness. However, it also confirms that conformance is not currently a milestone-gated requirement, even though a significant part of the Haskell node conformance tests has reportedly been ported, and more work is ongoing.

    Third, I recognize that demand for this kind of infrastructure is not always easy to prove in advance. Users do not usually ask directly for client diversity, local validation, or reduced RPC dependency, but they can benefit from these properties indirectly through more resilient and trust-minimized applications.

    For this reason, I do not consider the absence of a fully proven demand to be a reason to reject the proposal. However, adoption remains an important factor to watch. I would welcome clear communication from HLabs during delivery about potential wallet or dApp integrations, proxy operator interest, and usage indicators that show whether Gerolamo is moving from technical capability toward practical ecosystem adoption.

    In conclusion, I am voting YES because I believe Gerolamo addresses an important long-term infrastructure need for Cardano: more trust-minimized dApps and wallets, reduced dependency on centralized backend services, stronger client diversity, and a potentially distinctive browser-based validation model.

    At the same time, I recognize that this is an ambitious infrastructure proposal with meaningful technical and adoption risks. My YES vote reflects support for the direction, the potential ecosystem benefits, and the team’s continued work, while also recognizing that delivery should be followed closely by the community. In particular, I will be looking for transparent reporting on progress, conformance work, benchmarks, adoption signals, and how the team builds on lessons from the previous Gerolamo funding.

    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:
    pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

    My DRep ID:
    drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

  • BTBF_XSP
    No88.6M ₳Rationale

    While this may become necessary in the future, with multiple diversity node proposals recently approved, I shall vote against this time.

  • SIPO
    Yes86M ₳Rationale

    SIPO DRep votes YES on The first node in the browser; a Cardano USP (Gerolamo).

    Governance Action ID: gov_action1guz68e8zkwphcdc8wnp40cclkv92qgnel7xnffmsmp2ljp09qtwqq596k4c
    DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
    Date: 2026-05-13

    Context: This is the resubmission of the browser-light-node 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. The Gerolamo half is now materially strengthened by the published EC-0014-25 retrospective, which did not exist at the time of the original April 10 vote.

    Why SIPO votes YES

    1. Gerolamo is a Cardano-only structural USP. eUTxO state stays local to the transaction, block sizes are bounded, Praos is verifiable on light resources, and Plutus scripts are pure functions over a deterministic CEK machine — together making Cardano the only major chain where a fully-validating in-browser node is technically realistic. Ethereum, Solana, and account-based chains would have to cripple validation (revert to SPV / trusted-RPC) or redesign their base layer. Gerolamo is the artifact that turns this latent advantage into a shipped product.

    2. Gerolamo extends SIPO's node-diversity doctrine to a fourth axis. SIPO voted YES on Amaru (Rust) and Dingo (Go) on Haskell single-implementation-risk grounds (Ethereum Prysm 2026-03 is the canonical reference). Gerolamo adds TypeScript / WebAssembly — but explicitly as a complementary light-node implementation for dApps and wallets, not a block producer. The proposal scopes block production and server-side relay roles as out-of-scope and notes that adding them would require an additional ~$500k audit plus at least one additional FTE. This is the strongest possible structural answer to a node-diversity concern.

    3. Documented prior-funding track record (material change from April 10). HLabs's first treasury-funded work EC-0014-25 Gerolamo (₳578,571) is now retrospectively documented at IPFS QmZVw...e9c: 11 of 13 planned items fully shipped, 2 in progress. The project was effectively underfunded by more than half in USD terms (ADA/USD 0.7 → under 0.3) — HLabs still delivered. Browser compatibility was scoped as in-progress under EC-0014-25; that is precisely the scope of this resubmission.

    4. Five SIPO expectations from 2026-04-10 are addressed.

    • 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 layer (IndexedDB), networking layer (Ouroboros mini-protocols over Web Workers / WebSockets), and a public preprod sync from a browser context. HF coherence by M2 is added as a binding expectation below.
    • Past Catalyst accountability: covered by the EC-0014-25 retrospective above.
    • Contingency 25% → 15%, refundable, contract-enforced failsafe sweep.
    • Production-readiness criteria committed (≥15 peers / ≥24 hours stable peer-set at M4, sync across ≥3 separate browser sessions, verification on at least one non-Chromium engine with screencast).
    1. Governance and budget discipline identical to SIPO's approved standard. SundaeLabs treasury-contracts (TxPipe + MLabs audited), Independent Oversight Board (Carmuega / TxPipe, Rosa / Aiken, Gianelloni / BlinkLabs), auto-abstain DRep delegation on escrow, no SPO delegation, single-board-member pause, failsafe sweep. $0.25 ADA/USD conservative versus the original 0.35.

    Binding operational expectations SIPO attaches to this YES

    • 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, run logged and committed. Failure to demonstrate this should pause M2 disbursement until evidence is supplied.
    • Production-readiness criteria met with reproducible, third-party-verifiable evidence: ≥24-hour stable peer-set with ≥15 peers, sync across ≥3 separate browser sessions, verification on a non-Chromium engine with screencast committed to the repo, integration / API documentation published.
    • Scope containment binding: any pivot toward block production, server-side relay roles, or full-node use cases returns as a separate governance action with its own audit plan, not be absorbed into this ask.
    • Adoption indicator reported with named integrations: the ≥3 wallet / dApp integrations should be reported quarterly with project names, integration commit / release links, and consenting projects' confirmation. Anonymous counts are not sufficient.
    • Mithril integration reaches a documented completion state during this funding period (tagged release demonstrating Mithril-anchored bootstrap from a browser context, plus a public benchmark on initial-sync time savings). This is the natural completion of work begun under EC-0014-25.
    • Trustless bridge primitives spillover documented at the M4 hand-off: which verification primitives developed for Gerolamo (succinct certificates, cheap header validation, embeddable verifiers, partial state proofs) are reusable for trustless bridges, L2 verifiers, and dApp-side verification.
    • Contingency drawdown publicly justified in quarterly reports and the public transaction journal; unused contingency swept back to the Cardano treasury via the SundaeLabs failsafe.
    • 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.

    Closing

    This resubmission is a coherent and structurally improved version of the browser-light-node half of the original 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. 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として、本提案「The first node in the browser; a Cardano USP (Gerolamo)」に賛成（YES）を投じます。

    Governance Action ID: gov_action1guz68e8zkwphcdc8wnp40cclkv92qgnel7xnffmsmp2ljp09qtwqq596k4c
    DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
    Date: 2026-05-13

    背景：本提案は、2026-04-10にSIPOが期待事項付きでYESを投じた当初HLabs 2026 Budgetのブラウザ軽量ノード部分の再提出です。当初₳8.0Mの単一提案はDRep批准66.78%で67%閾値に僅差で届きませんでした。HLabsはコミュニティフィードバックを反映し、2つの独立投票可能な提案に分割、合計請求額をUSD換算で約30%削減しました。Gerolamo側は加えて、当初4月10日投票時には存在していなかったEC-0014-25回顧録の公開により実質的に強化されています。

    SIPOがYESと判断する理由

    1. GerolamoはCardano固有の構造的USP。eUTxOステートはトランザクションにローカル、ブロックサイズは限定的、Praosは軽量リソースで検証可能、PlutusスクリプトはCEKマシン上の純粋関数 — これらにより、Cardanoは完全検証ブラウザノードが技術的に現実的な唯一の主要チェーン。Ethereum・Solana・アカウントベースチェーンは検証を骨抜き（SPV / trusted-RPCに退化）にするかベースレイヤーを再設計するしかない。Gerolamoはこの潜在的優位性を出荷可能なプロダクトに変換するアーティファクト。

    2. GerolamoはSIPOのノード多様性ドクトリンを第4軸へ拡張。SIPOはAmaru（Rust）とDingo（Go）にHaskell単一実装リスク（2026-03 Ethereum Prysmインシデントが典型）の論理でYES投票。GerolamoはTypeScript / WebAssemblyを追加するが、明示的にdApp / ウォレット用補完軽量ノードとして、ブロックプロデューサーではなくスコープ。提案はブロック生成・サーバーサイドリレー役割を本スコープから明示的に除外し、追加には約$500k監査と少なくとも追加1 FTEが必要と注記。これはノード多様性懸念に対する最強の構造的回答。

    3. 文書化された過去ファンディング・トラックレコード（4月10日投票からの実質的変化）。HLabsの初トレジャリーファンディング作業EC-0014-25 Gerolamo（₳578,571）の回顧録（IPFS QmZVw...e9c）：計画13項目中11項目完納、2項目進行中。ADA/USDが0.7から0.3以下に下落し実効ファンディングが半分以下になったにもかかわらず履行。Browser compatibilityはEC-0014-25下で進行中スコープされており、これが本再提出のスコープそのもの。

    4. 2026-04-10投票時の5期待事項が対応：

    • 月次ベロシティ透明性：Pebbleと同標準（Monthly Lightweight Updates、四半期レポート、公開トランザクションジャーナル）。
    • 軽量ノード文脈でのHF対応：M1（Q2 2026）でブラウザストレージ層（IndexedDB）、ネットワーキング層（Ouroboros mini-protocols over Web Workers / WebSockets）、ブラウザコンテキストからのpreprod sync配送。M2までのHF整合性は下記の拘束力ある期待事項として追加。
    • 過去Catalyst説明責任：上記EC-0014-25回顧録でカバー。
    • コンティンジェンシー25%→15%、返還可能、契約強制failsafe sweep。
    • プロダクションレディネス基準コミット（M4時点で≥15ピア・≥24時間安定peer-set、≥3別個ブラウザセッションでの同期、screencast付き非Chromiumエンジン検証）。
    1. ガバナンス・予算規律はSIPO承認標準と一致。SundaeLabs treasury-contracts（TxPipe + MLabs監査済み）、Independent Oversight Board（Carmuega / TxPipe、Rosa / Aiken、Gianelloni / BlinkLabs）、エスクローAuto-abstain DRep委任、SPO委任不可、単一ボードメンバー一時停止可、failsafe sweep。$0.25 ADA/USDは当初0.35に対して保守的。

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

    • ブラウザ軽量ノードのHF整合性をM2（Q3 2026）までに実証：Gerolamoはブラウザコンテキストから公開Plutus V4テストネットをtipまで同期、runをログ記録・コミット。本実証失敗時は証跡提供までM2支払を一時停止。
    • プロダクションレディネス基準は再現可能・第三者検証可能な証跡で達成：≥15ピアとの≥24時間安定peer-set、≥3別個ブラウザセッションでのtipまでの同期、非Chromiumエンジンでの検証＋screencastリポジトリコミット、integration / APIドキュメント公開。
    • スコープ封じ込めは拘束力：ブロック生成・サーバーサイドリレー・フルノード用途への方向転換は独自監査計画をもつ別個ガバナンスアクションとして戻すこと。
    • 採用指標は名前付き統合で報告：≥3 wallet / dApp統合をプロジェクト名、統合コミット / リリースリンク、統合プロジェクト側からの同意確認とともに四半期ごとに報告。匿名カウント不可。
    • Mithril統合は本期間中に文書化された完了状態（ブラウザコンテキストからのMithrilアンカーbootstrapを実証するタグ付きリリース＋初期同期時間削減の公開ベンチマーク）。EC-0014-25下で開始された作業の自然な完了。
    • Trustless Bridgeプリミティブ波及をM4 hand-offで文書化：Gerolamo向け検証プリミティブ（succinct certificates、cheap header validation、embeddable verifiers、partial state proofs）のうちbridge、L2 verifier、dApp側検証に再利用可能なものを明示。
    • コンティンジェンシー使用は四半期レポートおよびトランザクションジャーナルで公開正当化、未使用分はSundaeLabs failsafeでCardanoトレジャリーへ返却。
    • Independent Oversight Committeeレビューを、マイルストーン進捗・KPI推移・遅延理由・次四半期クリティカルパスを四半期間で比較可能な安定フォーマットで公開。

    結び

    本再提出は、当初askのブラウザ軽量ノード部分の首尾一貫した構造的改善版であり、EC-0014-25回顧録により強化されている。公共財ケース — CardanoのeUTxO特性を、信頼バックエンドなしの出荷可能な完全検証ブラウザノードに変換し、bridge・L2ロードマップに複合する検証プリミティブを生み出すこと — は弱まっていない。ノード多様性の第4軸（Haskell / Rust / Go / TypeScript-WASM）はSIPO既承認ドクトリンを拡張する。SIPOのYESは、上記期待事項が拘束力ある運用上のコミットメントとして扱われ、各支払前にIndependent Oversight Committeeによって検証されることを条件とする。

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

  • Army of Spies
    Yes84.3M ₳Rationale

    Voting yes for node diversity here. As discussed in-depth many, many times on the Army of Spies YouTube channel, node diversity is a minimum infrastructure requirement of modern blockchains and we must meet a certain threshold in that regard.

  • ranket
    AbstainChanged75.2M ₳History

    Earlier votes

    No2mo agoSuperseded

  • SASA_nagamaru_ながまる
    No74.5M ₳Rationale

    I have decided to vote NO on this proposal.

    First, I want to acknowledge that I find the technical direction of Gerolamo and the broader vision of a fully-validating Cardano light node running directly in the browser to be both interesting and uniquely aligned with Cardano’s architecture.

    In particular, I recognize the effort to leverage eUTXO and Cardano’s design principles to enable trustless on-device validation, which could potentially become a meaningful differentiator compared to other ecosystems. I also appreciate the proposal’s attempt to reduce scope and contain costs given the current Treasury environment.

    However, at this stage, I do not feel a strong sense of urgency or priority for this initiative.

    While the technology itself is innovative, I believe the Cardano ecosystem’s most immediate challenges currently relate to liquidity, user growth, external capital inflows, real-world demand, and broader adoption.

    In that context, it remains unclear how much impact a browser-based validating node would realistically have on the ecosystem as a whole, or how widely such a solution would actually be adopted in practice.

    This should not be interpreted as opposition to the overall direction of the proposal. I believe it could contribute to Cardano’s long-term decentralization and lightweight verification capabilities. However, considering the limited Treasury resources available, I believe funding should currently prioritize areas that more directly contribute to real-world demand and ecosystem growth, and for that reason I have decided to vote NO.

    僕は本提案に対してNOを投じます。

    まず前提として、Gerolamoの技術的な方向性や、「ブラウザ上で完全検証可能なCardano light nodeを実現する」という思想そのものについては、非常に興味深く、Cardanoらしい挑戦だと感じています。

    特に、eUTXOやCardanoの設計思想を活かし、「trustless on-device validation」を実現しようとしている点については、他チェーンとの差別化要素として一定の可能性があると考えています。また、現在のTreasury環境を踏まえて、scopeを絞り、コストを抑えようとしている姿勢についても評価しています。

    一方で、現時点では、この提案に対して強い必要性や優先順位の高さを感じることができませんでした。

    技術的には非常に面白い取り組みではあるものの、現在のCardano ecosystemが直面している最重要課題は、流動性、ユーザー流入、外部資本、実需、adoptionなどであると考えています。

    その中で、browser-based validating nodeが、現時点でecosystem全体へどれほど大きな影響を与えるのか、また実際にどれほど広く利用されるのかについては、まだ不透明だと感じています。

    僕は、本提案の方向性そのものを否定しているわけではありません。長期的には、Cardanoの分散性や軽量検証技術の発展に貢献する可能性があると考えています。しかし、限られたTreasury資金をどこへ優先的に配分するべきかという観点から、現時点ではより直接的に実需やecosystem成長へ繋がる領域を優先すべきだと考え、今回はNOを選択しました。

  • Dave
    Abstain73.1M ₳Rationale

    I am voting ABSTAIN on this standalone proposal. I previously voted abstain and stand by this position in the current market. Whilst I recognise its advantages and value to our blockchain, I cannot allocate funds for this as a priority right now given the market and my planned focus.

    A PDF version of this rationale is also made available.

    I am formally registering an ABSTAIN vote on the standalone Gerolamo treasury request.

    I commend the HLabs team for taking prior feedback on board by unbundling their initiatives. I previously voted abstain, additionally I have since supported their Pebble proposal with a yes vote. I am standing by this position in the current market. Whilst I recognise the unique technical advantages of this proposal and the value it brings to our blockchain, I cannot allocate treasury funds for this as a priority at this moment in time in the current market and with my current planned focus.

    However, out of profound respect for the team's exceptional track record, I will not use my voting weight to actively block it. I will not stand by if the community were to decide this is required, and I am stepping aside to let the collective voice of the ecosystem determine the outcome.

  • Martin Lang
    Yes69.4M ₳No rationale
  • Hermes Stakepool Germany (HRMS)
    Yes66M ₳No rationale
  • Peter Bui
    Abstain62.7M ₳No rationale
  • Dori
    No53.8M ₳Rationale

    I'm voting No on the "The first node in the browser; a Cardano USP" proposal.

    To use a constrained treasury efficiently, the budget should be allocated by priority against actual ecosystem development needs. If this proposal passes and a new TypeScript-based browser node gets added as another client implementation, that's a positive in itself, but I don't see it as solving a fundamental problem that's blocking ecosystem development.

    In other words, it would be nice to have, but it's not essential at the priority level of this cycle.

    1. The proposal doesn't demonstrate a problem the Cardano ecosystem actually needs to solve.

    The Cardano dApp and wallet ecosystem currently runs stably on infrastructure like Mesh, Lucid Evolution, Blockfrost, Maestro, and Koios. The absence of a fully-validating in-browser node isn't creating real problems for dApp builders or users. On top of that, IOG already provides a light verification option through Mithril. The 12-month adoption target of "≥3 wallet/dApp integrations" also reads as the proposal itself acknowledging that market demand isn't large.

    1. The case for treasury priority is weak.

    In the current NCL-constrained environment, ₳4.6M is not a small amount. The goal of client diversity is already being addressed through multiple projects, and the differentiated value of a "browser-based TypeScript node" on top of that is not clearly articulated.

    HLabs is also requesting a separate ₳4.6M for Pebble and TypeScript tooling in the same cycle, which means a single team would receive roughly ₳9.2M from this cycle if both proposals pass. I think the more responsible treasury allocation for this cycle is to direct those funds toward protocol-layer infrastructure, maintenance of core tools with proven track records, and builder work where actual demand has been demonstrated.

  • hix_coffeepool
    No50.4M ₳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/

  • AdaStat
    Yes50M ₳Rationale

    Having multiple, diverse nodes from different teams is critically important for any decentralized system, including Cardano.

  • Chris-O
    No49.5M ₳No rationale
  • PoolTool
    No47.6M ₳No rationale
  • HISAI
    Abstain42.9M ₳No rationale
  • Patrick_Tobler
    AbstainChanged40.1M ₳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.

    Earlier votes

    No2mo agoSuperseded

    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.

  • drep1yffcjs0njfe...
    Abstain38.1M ₳Rationale

    I voted ABSTAIN on this proposal.

    I appreciate the technical value and decentralization vision behind browser-based light nodes, and I respect the work HLabs has done for the ecosystem.

    However, I am still uncertain whether this is a high-priority Treasury focus in the current environment compared to other core ecosystem needs.

  • Linda - Cryptofly
    No37.8M ₳No rationale
  • Liqwid DAO
    Abstain36.9M ₳No rationale
  • MUEN
    Yes34.6M ₳Rationale

    ブラウザでフル機能が動くのはCardanoだけという実績は、投資家や開発者に対し、Cardanoの設計（EUTXO）が正しいことを証明する最強の武器になります。価格が低い今こそ、こうした圧倒的な差別化が必要だと考えます。

  • Aichi/Tokai_DRep
    No31.4M ₳Rationale

    I am voting NO.

    While I recognize the technical value of this proposal, my current priority is to support projects that drive real‑world adoption and create practical, socially impactful use cases on Cardano.
    With that focus in mind, I will not support this proposal at this time.

  • NEDSCAVE.IO
    Abstain30.7M ₳No rationale
  • Cerkoryn
    Yes27.9M ₳Rationale

    Gerolamo offers a unique value proposition over the existing Haskell node and the other alternate nodes in development (Dingo, Amaru, etc.). In my mind, the other nodes are geared toward SPOs, but Gerolamo will be a major benefit toward dApp and light wallet developers. As a native TypeScript node, Gerolamo will be catering toward one of the most highly-adopted languages on the planet. With the capability to run a node in the browser, this opens up a lot of new use cases for developers that we simply don't have with other nodes or tooling. For these reasons I am enthusiastically voting YES on the Gerolamo proposal.

  • TERA DRep
    No27.9M ₳No rationale
  • Drep One
    Yes27.5M ₳No rationale
  • Florian Volery
    No26.3M ₳No rationale
  • wolf31o2 (Chris Gianelloni)
    Yes23.5M ₳Rationale

    Excited for Gerolamo

  • DINO
    YesChanged21.5M ₳History

    Earlier votes

    No2mo agoSuperseded

  • Hephaestus Stake Pool [HEPHY]
    Abstain21.5M ₳No rationale
  • Ha-Nguyen
    Abstain21.4M ₳No rationale
  • Moonstake
    Yes20.4M ₳No rationale
  • CTEC-Stake-Pool
    No20.3M ₳No rationale
  • Chris [STR8] - Straightpool
    No19.9M ₳Rationale

    Whilst interesting, I believe the demand and use case for an in-browser node is unclear at this time.
    Plus with Amaru and Dingo we already have 2 alternative nodes to the core Haskell node for client diversity and given the moving parts in Cardano with Leios and Peras, I don't believe we should onboard a fourth at this time.
    Maybe we can revisit this at a later time when the Cardano codebase has stabilized more. Overall, at this time, I vote "NO" on this.

  • Rodrigo-[CHIL]
    Yes17.3M ₳Rationale

    The first node in the browser; a Cardano USP

  • Cardanians
    Yes16.7M ₳Rationale

    Our previous position on the broader Pebble + Gerolamo – HLabs 2026 Budget was ABSTAIN, mainly because it bundled several important streams together and we preferred a broader RFP/tender-style approach for alternative nodes and core tooling. The core concern remains: node and client diversity should eventually be funded through a more strategic ecosystem-wide process, because every new implementation can create long-term maintenance obligations.

    However, this new proposal is materially cleaner and easier to evaluate. It is focused specifically on Gerolamo, asks for 4,600,000 ADA, discloses 5 FTE over 12 months, and narrows the scope to a browser-based validating node and dApp/wallet API surface. This is a clearer and more accountable structure than the previous bundled proposal.

    We also see a strong public-good argument. Reducing wallet and dApp dependence on centralized API providers is directly aligned with Cardano’s decentralization goals, and a browser-based validating node could become a unique Cardano advantage if adopted. The proposal still carries adoption risk, but given the improved scope clarity, explicit FTE model, milestone structure, and strategic value for trust-minimized dApps and wallets, we are willing to support it.

  • DraculaDAO
    No16.4M ₳No rationale
  • drep1ytaunswwpyt...
    Yes14.2M ₳No rationale
  • 忠実
    Yes14.1M ₳No rationale
  • RCADA
    Yes13.3M ₳Rationale

    RCADA supports this treasury withdrawal as a strategically meaningful investment in Cardano’s decentralisation, developer accessibility, and long-term ecosystem resilience.

    This proposal introduces Gerolamo — a production-ready, browser-based validating Cardano light node — and seeks to transform what is arguably one of Cardano’s unique architectural strengths into a tangible and demonstrable ecosystem advantage. Cardano’s eUTxO model, deterministic execution, and comparatively lightweight validation requirements make this type of implementation realistically achievable in a way that is difficult or impractical for most competing blockchain architectures. We believe there is merit in pursuing innovations that strengthen Cardano’s unique positioning while simultaneously improving decentralisation in practical, user-facing ways.

    RCADA has historically supported infrastructure proposals that strengthen network resilience, reduce systemic dependency, and expand the diversity of tooling available across the ecosystem. In our previous support for alternative node development, we recognised that independent implementations reduce single-client risk and improve the robustness of the network over time. Gerolamo extends this principle into the light-node tier by enabling trust-minimised, browser-native validation for wallets, dApps, and users who would otherwise rely on centralised infrastructure providers. We view this as directionally aligned with Cardano’s long-term decentralisation goals and consistent with prior RCADA voting positions.

    We also recognise the broader strategic value of expanding developer accessibility. By building within the TypeScript ecosystem, this proposal lowers barriers to participation for a significantly larger pool of developers and improves integration pathways for wallets, browser applications, and dApps. As with prior infrastructure proposals, we consider wider contributor accessibility to be an important ecosystem benefit, particularly when balanced against long-term resilience and maintainability.

    Importantly, the governance structure presented in this proposal materially strengthens confidence in treasury stewardship. The use of milestone-based escrow contracts, independent oversight, public reporting, transaction journaling, auditable financial controls, and objective delivery criteria represents a strong governance framework and reflects an encouraging maturation in Treasury Withdrawal proposal standards. RCADA has consistently emphasised the importance of accountability, measurable deliverables, and transparent administration in treasury-funded initiatives, and we view this proposal favourably in that regard.

    At the same time, our support comes with caveats.

    First, execution risk remains meaningful. Delivering a fully-validating browser-based node capable of reliable synchronization, consensus validation, rollback handling, and wallet/dApp integration is an ambitious technical undertaking. While the proposal is thoughtfully scoped and milestone-driven, success will ultimately depend on execution quality and adoption by downstream ecosystem participants.

    Second, ecosystem demand remains an area we will monitor closely. The proposal’s value proposition becomes substantially stronger if wallets, dApps, and governance tooling meaningfully integrate Gerolamo after delivery. We therefore view real-world adoption as an important indicator of success and would expect future funding requests, if any, to demonstrate measurable ecosystem traction.

    Third, while we appreciate the flexibility required in complex engineering efforts, we note that the ability for milestone schedules to be reorganised by HLabs introduces a governance consideration that should be exercised conservatively and transparently to preserve confidence in treasury accountability.

    On balance, RCADA finds that this proposal meets the threshold for treasury funding. It combines a compelling strategic vision, meaningful decentralisation benefits, strong developer-accessibility potential, and one of the more mature treasury governance structures currently presented to the ecosystem.

    Our YES vote reflects support for this specific proposal and its merits. It should not be interpreted as a blanket endorsement of all future infrastructure implementations or continued funding without demonstrated delivery, adoption, and accountability. Future requests should continue to meet the same standard of scrutiny, measurable progress, and ecosystem value.

    RCADA remains committed to supporting initiatives that strengthen decentralisation, improve governance standards, and contribute meaningful long-term value to the Cardano ecosystem.

    RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."

  • Wada DRep
    No12.1M ₳Rationale

    We are voting no on this governance action due to concerns regarding execution and adoption risk relative to the requested treasury funding.

    While we recognize the technical ambition of a browser-based Cardano node and acknowledge its potential contribution to decentralization, the proposal does not sufficiently demonstrate ecosystem demand or a clear path to widespread adoption. The projected benefits remain largely speculative, while the requested budget is substantial.

    The proposal's success depends not only on technical delivery but also on meaningful integration by wallets, dApps, and end users. At present, there is insufficient evidence that these stakeholders will adopt the solution at a scale that justifies the investment. Given the combination of technical complexity, browser environment constraints, uncertain user demand, and integration dependencies, we believe the risk-adjusted value proposition is not strong enough to warrant treasury funding at this time.

    We encourage the team to further validate demand, demonstrate adoption commitments, and de-risk the implementation before seeking funding of this magnitude.