The first node in the browser; a Cardano USP
182 DReps voted · 73 with a rationale · 9 changed their vote · 3 re-voted unchanged
Open a row to read the rationale.
Changed votes: 6 to yes, 1 to no, 2 to abstain, together voting with 730.2M ₳ of voting power.
Voting concentration
8 of 182 DReps cast half of the voted power.
Largest voter 15.1%, top 5 combined 42.6% of 4.5B ₳ voted.
The 13 largest voters together held as much voting power as the 67.0% threshold required in yes votes.
- Yes8.9M ₳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/."
- 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.
- YesChanged7.3M ₳History
Earlier votes
Abstain3mo agoSuperseded
- Abstain6.8M ₳No rationale
- YesChanged6.7M ₳History
Earlier votes
Abstain4mo agoSuperseded
- Yes5.7M ₳Rationale
- 노드의 언어다양성의 우선순위는 후순위라고 판단하지만
재무부 자금 투입양 대비 성과가 기대되기에 지지함
- 노드의 언어다양성의 우선순위는 후순위라고 판단하지만
- Yes5.7M ₳No rationale
- Abstain5.5M ₳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.
- Yes5.5M ₳No rationale
- 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. - Yes5.2M ₳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.
- Yes5.1M ₳No rationale
- Yes5.1M ₳Rationale
Yes, well written and milestone driven treasury submission.
- Yes4.9M ₳Rationale
Voting YES. A fully validating Cardano node running directly in the browser is a genuinely differentiated infrastructure play that aligns strongly with Cardano’s architecture and decentralization goals. Beyond the UX narrative, the underlying work on lightweight validation and client diversity has meaningful long-term value for wallets, dApps, bridges, and L2 infrastructure.
- No4.8M ₳No rationale
- No4.5M ₳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.2M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "The first node in the browser; a Cardano USP" (gov_action1guz...596k4c), 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_action1guz...596k4c), 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. - Yes4.2M ₳No rationale
- No4M ₳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.
- Yes4M ₳No rationale
- Yes3.5M ₳No rationale
- Yes3.1M ₳No rationale
- Yes3M ₳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.
- Yes2.8M ₳No rationale
- No2.7M ₳No rationale
- Abstain2.7M ₳No rationale
- Yes2.7M ₳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
- Abstain2.2M ₳No rationale
- Yes2.2M ₳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.
- Yes2M ₳Rationale
good proposal, would recommend
good proposal, would recommend
- No1.9M ₳No rationale
- Yes1.8M ₳No rationale
- No1.8M ₳Rationale
The proposal frames an in-browser validating node as a critical decentralization investment. But Cardano already operates one of the most decentralized networks in the industry by meaningful measures: a large, globally distributed SPO set, multiple node client implementations in active development, and a governance model that is live and participatory. The marginal decentralization gain from a browser light node — whose own success metric is just 3 integrations — does not constitute an urgent need that justifies 4.6M ADA from a treasury under active spending constraint.
- No1.7M ₳Rationale
Niche, overpriced light client with a weak adoption target. Putting consensus-critical validation into a browser extension is a security downgrade
- Abstain1.6M ₳No rationale
- Yes1.6M ₳No rationale
- No1.6M ₳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.
- 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.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
- No1.4M ₳No rationale
- No1.3M ₳No rationale
- No1.2M ₳No rationale
- Abstain1.2M ₳No rationale