The first node in the browser; a Cardano USP
182 DReps voted · 73 with a rationale · 12 changed their vote
Open a row to read the rationale.
- YesChanged10.9M ₳History
Earlier votes
Abstain2mo agoSuperseded
- Yes10.8M ₳No rationale
- Yes10.4M ₳Rationale
My view is consistent with the position I took previously when these were bundled together. Now that the proposals have been separated, I can reflect my actual view more accurately
The reason is straightforward - even as a non-technical voter, I can clearly understand the strategic value of this proposal.
A production ready Cardano light node that runs in the browser is a unique and differentiated product. It improves onboarding, lowers access barriers and strengthens the decentralization story in a way that is easy to grasp even without deep technical expertise. It stands out as something that could be genuinely useful for wallets, dApps and end users, while also giving Cardano a clear point of differentiation. aka USP
I'm always a big fan of onboarding the 'regular joe'
- YesRevoted9.2M ₳History
Earlier votes
Yes2mo agoSuperseded
- Yes8.8M ₳Rationale
私はこの提案に賛成します。本提案は、ブラウザ内で動作する完全検証型のCardanoライトノードであるGerolamoの開発を目的としており、Cardanoが持つeUTxOモデルや軽量なプロトコル設計といった特性を活かした、独自性の高い取り組みだと考えています。特に、ライトウォレットやdAppsが外部サービスへの依存を減らし、ユーザー自身の環境で検証を行えるようになる可能性を高く評価しています。こうした仕組みは、Cardanoの強みを実際のアプリケーションへ活かすことにつながると考えています。採用や統合が今後の課題であることは認識していますが、Cardanoの技術的な強みを実用的な形でユーザーや開発者、そしてエコシステム全体へ届ける価値のある挑戦だと考えます。以上の理由から、本提案を支持します。\n\nI support this proposal. This proposal aims to develop Gerolamo, a fully validating Cardano light node that runs in the browser, and I believe it is a distinctive initiative that leverages Cardano’s unique characteristics, including its eUTxO model and lightweight protocol design. In particular, I highly value the potential for light wallets and dApps to reduce their dependence on external services while enabling users to verify chain state within their own environment. I believe this approach helps bring Cardano’s strengths into practical applications. While I recognize that adoption and integration remain important challenges, I see this as a valuable effort to deliver Cardano’s technical strengths in a practical way to developers, users, and the broader ecosystem. For these reasons, I support this proposal.
- YesChanged8.1M ₳History
Earlier votes
Abstain2mo agoSuperseded
- Yes7.6M ₳Rationale
Voting YES
I support both HLabs proposals - part of as public infrastructure, not just private product work. But I do appreciate their original approach too.
The Pebble and TypeScript maintenance proposal funds tools and libraries that Cardano builders already use, and it helps keep that stack working through protocol upgrades. Pebble also gives Cardano a more familiar path for TypeScript, JavaScript and Solidity-style developers, which matters if we want more people building here.
Gerolamo may be "riskier", but I think this is the kind of technical risk the Treasury should sometimes take. In my view a real Cardano node in the browser would be a strong differentiator. It could reduce dependence on centralised providers and give wallets and dApps a more trust-minimised way to interact with the chain. Not just a nice feature if it clicks properly.
The new split is also better than the original bundled proposal. I would not support risk for every proposal, but if Cardano wants to stand out, we need some carefully scoped bets like this. Here, one proposal supports infrastructure builders use today, while the other tries to create a real future-facing Cardano advantage. I like a bold attempt from time to time - if it clicks with me as a Cardano user. This is a joint review for both proposals.
- Abstain7.2M ₳No rationale
- Yes5.9M ₳Rationale
Voting yes - this is consistent with my prior vote which was for the combined proposal.
- Yes5.8M ₳Rationale
- 노드의 언어다양성의 우선순위는 후순위라고 판단하지만
재무부 자금 투입양 대비 성과가 기대되기에 지지함
- 노드의 언어다양성의 우선순위는 후순위라고 판단하지만
- Yes5.4M ₳No rationale
- Yes5.3M ₳Rationale
Yes, well written and milestone driven treasury submission.
- Abstain5.3M ₳Rationale
STORM Partners abstains on the Gerolamo browser node proposal.
We respect Harmonic Labs and recognize the technical ambition behind a browser-based Cardano node. If successful, it could become a distinctive Cardano capability. That said, we are not fully convinced this should be a priority under the current NCL. Cardano already has several alternative node initiatives in motion, and we do not have enough confidence that this specific node path should rank above more immediate infrastructure, scaling, and adoption needs.
Given our limited technical certainty here, we abstain rather than vote NO. - No4.8M ₳No rationale
- No4.7M ₳Rationale
This would have my vote if the ADA market price was higher, but at the moment I don't think the Treasury can afford it.
- Yes4.6M ₳No rationale
- Abstain4.4M ₳Rationale
After careful consideration, although I supported the previous bundled proposal, I have decided to abstain from both the Pebble and Gerolamo proposals. While both initiatives are valuable additions, they are not critical at this stage, especially given the high volume of treasury proposals and the urgent need to identify and focus on our top priorities. Although I respect the team, these projects do not rank among our highest priorities right now. At the same time, I do not wish to obstruct other DReps, particularly those with greater technical expertise, if they believe the proposals should move forward.
For this reason, I will abstain from the voting process.==============================
PS (for all future governance actions): I will not respond to any direct messages attempting to persuade me to change my vote. Please respect my decision, as none of these choices are made lightly.
- Yes4.2M ₳No rationale
- Yes4.1M ₳No rationale
- Yes4.1M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "The first node in the browser; a Cardano USP" (gov_action1guz68e8zkwphcdc8wnp40cclkv92qgnel7xnffmsmp2ljp09qtwqq596k4c), pois o Gerolamo transforma uma vantagem técnica específica da Cardano em um produto concreto: um nó leve, validador e executável diretamente no navegador. Essa iniciativa fortalece a proposta de valor da rede ao permitir que dApps e carteiras acessem e validem dados da blockchain com menor dependência de RPCs, indexadores ou outras infraestruturas centralizadas. Também consideramos positivo o foco em descentralização prática, diversidade de clientes e melhoria da experiência dos desenvolvedores que utilizam TypeScript/JavaScript, um dos maiores ecossistemas de desenvolvimento do mundo. A disponibilização de um nó executável em extensão de navegador pode ampliar o acesso à verificação local de dados, beneficiando carteiras leves, aplicações descentralizadas e futuras soluções de interoperabilidade, como bridges e camadas de escalabilidade (L2s). Por fim, a proposta apresenta um escopo bem delimitado, com marcos trimestrais verificáveis, utilização de mecanismos de escrow, supervisão por comitê independente, contingência reembolsável e relatórios públicos. Esses elementos reduzem o risco para a tesouraria, aumentam a transparência da execução e tornam o financiamento mais responsável, auditável e alinhado aos objetivos estratégicos de longo prazo da Cardano.
[English]
We chose to vote "YES" on this governance action "The first node in the browser; a Cardano USP" (gov_action1guz68e8zkwphcdc8wnp40cclkv92qgnel7xnffmsmp2ljp09qtwqq596k4c), because Gerolamo turns a unique technical advantage of Cardano into a tangible product: a lightweight validating node that can run directly in a web browser. This initiative strengthens Cardano’s value proposition by enabling dApps and wallets to access and verify blockchain data with reduced reliance on RPC providers, indexers, or other centralized infrastructure. We also view positively the proposal’s focus on practical decentralization, client diversity, and improving the developer experience for the TypeScript/JavaScript ecosystem, one of the largest developer communities in the world. Delivering a browser-based node can expand access to local verification capabilities, benefiting lightweight wallets, decentralized applications, and future interoperability solutions such as bridges and Layer 2 protocols. Finally, the proposal presents a clearly defined scope, with verifiable quarterly milestones, escrow mechanisms, independent oversight, refundable contingency funds, and public reporting. These elements reduce treasury risk, improve execution transparency, and make the funding more responsible, auditable, and aligned with Cardano’s long-term strategic objectives. - Yes4M ₳No rationale
- No3.8M ₳Rationale
I do not see this as significantly changing the main problems Cardano faces, and doesn't cross my line for value, or why this is needed now.
A PDF version of this rationale is also made available.
While a technically sophisticated and strategically interesting proposal, I am less convinced about its urgency relative to some other treasury priorities.
The core thesis is legitimate: Cardano’s eUTXO architecture and relatively lightweight validation model create the possibility for a fully-validating in-browser node in ways that are structurally difficult for most other major chains. If successfully delivered, that would represent an architectural differentiator. But, how valuable would that be to the market?
I also believe the proposal’s broader research spillover effects are likely more important than the browser extension itself. Work around lightweight verification, succinct proofs, browser-hosted validation, and portable verifier infrastructure likely compounds into future bridge, L2, and decentralized application architectures across the ecosystem.
I appreciate that HLabs responded to community feedback by decomposing the original bundled proposal into independently votable components, improving governance precision and accountability. The milestone structure, escrow framework, oversight board, and refund mechanisms are also directionally healthier than the average treasury proposal.
That said, I don't support the proposal’s prioritization relative to more immediate ecosystem bottlenecks.
Cardano’s current constraints are still more heavily concentrated around liquidity, adoption, interoperability, developer ecosystem growth, and application density than browser-native validation capabilities specifically. While I believe the proposal has meaningful long-term option value, I am less convinced it represents urgent ecosystem infrastructure today.
More broadly, Cardano governance should remain careful not to systematically over-prioritize technically elegant infrastructure simply because it is architecturally impressive. Treasury capital is finite, and strategic prioritization matters.
- Yes3.1M ₳Rationale
Very happy to vote YES for this proposal.
It has become recently very clear that node diversity and development away from IOG maintained products is essential for the longevity of Cardano. Without node and developer diversity for core Cardano tooling, IOG can hold the treasury hostage every year, and they have already shown that this is their current and future intent. Apart from this, a lightweight browser-based node like Gerolamo is an essential step for Cardano to facilitate future mainstream adoption and support of the blockchain with ease-of-use access.
I sincerely hope that the rest of the Cardano Community votes yes for this proposal so that we can all see the benefits of Gerolamo come to fruition.
- No3M ₳No rationale
- Abstain2.8M ₳No rationale
- Yes2.6M ₳Rationale
私は本提案に賛成します。ただし、マイルストーン達成と実装状況の公開検証を重視します。Gerolamoは、2025年Gerolamo提案の大型化・実用化フェーズと位置づけられるものであり、CardanoのeUTxO設計と比較的軽量な検証構造を活かし、ブラウザ内で動作するCardano light nodeを実用化しようとする提案です。これが実現すれば、dAppsやlight walletsが中央集権的なAPIや外部サーバーに過度に依存せず、ユーザー端末側で検証可能なアクセス経路を持てるようになります。これは、Web3が中央集権APIに依存している問題への直接回答であり、Cardanoの分散性、client diversity、そして2030年に向けたインフラ戦略と整合しています。
一方で、「fully-validating」「production-ready」の到達基準は、今後の公開マイルストーンに基づいて厳密に確認されるべきです。また、BlockfrostやCayleyのようなAPI/Indexing基盤とは競合というより補完関係にあり、API/Indexing層がデータアクセスを支え、Gerolamoがユーザー端末側の検証層を担う構造として評価できます。
マイルストーン、独立監督、escrow、返還可能contingencyが設計されている点は評価します。これらが実効的に運用されることを前提に、本提案はCardanoの「ユーザーが自分で検証できるWeb3」という独自性を強化する公共財投資として支持します。
I support this proposal, while emphasizing the importance of milestone-based delivery and public verification of implementation progress. Gerolamo can be viewed as the expanded and practical implementation phase of the 2025 Gerolamo proposal. It aims to turn Cardano’s eUTxO design and relatively lightweight validation model into a browser-based Cardano light node. If delivered, it would allow dApps and light wallets to reduce reliance on centralized APIs and remote servers, giving users a more trust-minimized way to access Cardano from their own devices. In this sense, it is a direct response to the problem of Web3 depending on centralized API layers, and it aligns well with Cardano’s decentralization, client diversity, and 2030 infrastructure strategy.
However, the terms “fully-validating” and “production-ready” should be verified strictly against future public milestones. I also see Gerolamo as complementary, rather than competitive, with API/indexing infrastructure such as Blockfrost or Cayley: those systems support data access, while Gerolamo strengthens user-side verification.
I value the milestone structure, independent oversight, escrow design, and refundable contingency. Provided these controls are enforced, I see this as a worthwhile public-goods investment that strengthens Cardano’s unique claim: a Web3 ecosystem where users can verify more from their own devices.
- Abstain2.5M ₳No rationale
- Abstain2.5M ₳No rationale
- Yes2.4M ₳No rationale
- No2.3M ₳No rationale
- Yes2.3M ₳No rationale
- No2.3M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳No rationale
- Yes2.1M ₳Rationale
I am voting YES because Gerolamo has the potential to materially strengthen Cardano’s decentralisation, client diversity, and developer infrastructure by enabling a browser-capable Cardano node. This aligns with Cardano’s long-term strategy and with my DRep principles of supporting open-source public-good infrastructure that improves resilience and reduces reliance on centralised service providers.
I recognise the delivery risk: Gerolamo is not yet a production-ready validating browser node, and the project must demonstrate real progress through its milestones. I would also like continued clarity around independent audit and oversight costs, milestone acceptance, and adoption pathways for wallets and dApps.
However, I believe this is the type of ambitious infrastructure work the treasury should support when paired with transparent delivery controls, refundable contingency, and independent oversight. For that reason, I support this proposal.
- Abstain2M ₳No rationale
- No1.9M ₳No rationale
- Yes1.8M ₳Rationale
We fully support this proposal!
This is a technology investment that delivers enormous public value (Public Goods) and creates a truly exclusive competitive advantage for Cardano. Thanks to its eUTxO design and unique consensus mechanism, Cardano is the only large blockchain that can operate a fully validating light node directly in the user's web browser through the Gerolamo project. This helps dApps and e-wallets minimize reliance on central API/RPC services (like Blockfrost), thereby ensuring absolute decentralization and information security in the true spirit of Web3.
Furthermore, the Harmonic Labs team has a history of excellent product delivery, incorporating community feedback to break down the proposal and reduce the budget by 30%. The clear milestone structure, independent oversight board, and delay recovery mechanism minimize risks for the treasury. We believe this proposal not only enriches the diversity of network nodes (alongside Haskell, Amaru, and Dingo) but also serves as a crucial foundation for optimizing Midnight infrastructure and future Layer 2 solutions.
- Yes1.8M ₳No rationale
- No1.8M ₳Rationale
With Amaru and Dingo already further along in development, together with the Haskell node, I do not currently see the need to fund a fourth node implementation. Three nodes provides sufficient resiliency without creating too much fragmentation, and spreading resources too thinly.
The project is interesting but at this time non-essential. If the developers wish to continue it as a community project, I would welcome this, but of course I understand if it is shelved.
- No1.8M ₳Rationale
Again - too small a window of time to justify my spending any time evaluating this proposal.
- No1.7M ₳Rationale
Niche, overpriced light client with a weak adoption target. Putting consensus-critical validation into a browser extension is a security downgrade
- Yes1.7M ₳No rationale
- Yes1.7M ₳No rationale
- Abstain1.6M ₳No rationale
- Yes1.6M ₳Rationale
In my rationale for the first treasury withdrawal for these items, which I approved, I stated that I believe this node implementation will play an important role in Cardano’s decentralization, as it enables dApps and light wallets to directly verify data instead of relying on APIs. I also stated that I believe the Pebble smart contract language can become a valuable alternative to existing ones.
However, I am generally reluctant to approve proposals that include a contingency buffer while the current NCL concept is in place, as this limits the funding available to other proposals, even if unused funds would later be returned.
That said, I also believe the current threshold for approving treasury withdrawals is too high, especially since only a few larger DReps can block a proposal. As the first proposal only narrowly failed, I consider it as good as approved. Combined with the fact that the contingency buffer is not excessive, I will approve these proposals as well.
- Yes1.6M ₳Rationale
good proposal, would recommend
good proposal, would recommend
- No1.6M ₳No rationale
- Yes1.5M ₳Rationale
Vote: YES on "The first node in the browser; a Cardano USP" (Gerolamo) — HLabs
Rationale:
Gerolamo targets a capability that no other major L1 can replicate without redesigning its base layer. Cardano's eUTxO model, bounded block sizes, and deterministic Plutus execution make an in-browser fully-validating node technically viable here in a way it is not on Ethereum, Solana, or any account-based chain. If shipped, this becomes a concrete, demonstrable competitive advantage — not a whitepaper claim.
The engineering work required (succinct validation, compact checkpointing, embeddable verifiers) directly feeds into components Cardano needs anyway for trustless bridges and L2 infrastructure. Funding Gerolamo is funding that foundation.
I voted No on the previous bundled HLabs proposal (Pebble + Gerolamo). This proposal addresses that concern: the scope has been deliberately separated, and Gerolamo stands on its own merit with a focused 5-FTE, $1M budget that excludes block production and non-essential overhead.
The governance structure is among the strongest I have seen in any treasury proposal:
- Smart contract escrow (SundaeSwap treasury contracts, audited by TxPipe and MLabs)
- Independent oversight board (Carmuega, Rosa, Gianelloni) with pause authority
- Milestone-based disbursement with objective, publicly verifiable acceptance criteria
- Independent quarterly financial audit
- Automatic failsafe sweep of unused funds back to treasury
At ₳4,600,000 for 12 months and 5 FTEs, the cost is contained and the contingency buffer (15%, refundable) reflects lessons learned from prior proposals affected by ADA price volatility.
This is infrastructure that compounds: every wallet and dApp that integrates Gerolamo inherits trustless chain access. That is the kind of investment the treasury should be making.
- Yes1.4M ₳No rationale