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.
- Yes1.2M ₳No rationale
- Abstain1.1M ₳No rationale
- No1.1M ₳Rationale
Again - too small a window of time to justify my spending any time evaluating this proposal.
- No1.1M ₳Rationale
The pitch is undeniably seductive: “a fully validating Cardano node in the browser” sounds like the sort of category-defining differentiator that makes conference stages purr. And yes, Cardano’s eUTxO architecture gives this idea more technical plausibility than most chains can honestly claim. I give the proposal that much. But plausibility is not yet treasury-worthiness, and Cardano governance should not confuse an elegant narrative with a proven necessity.
**
Treasury should fund indispensable commons, not merely fascinating engineering. This proposal may indeed produce useful code, research spillovers, and a compelling demo. But “could become foundational” is not the same as “must be treasury-funded now.” If the primary value is strategic optionality, ecosystem signaling, and future bridge/L2 relevance, then I want stronger evidence of demand pull, integration commitments, and why the private sector, partner co-funding, or a narrower scoped ask would not be the more prudent route.** - Yes966.3K ₳No rationale
- No927.7K ₳No rationale
- Yes920.9K ₳No rationale
- No884.5K ₳No rationale
- No866.3K ₳No rationale
- Yes829.9K ₳Rationale
Impact Assessment (Pros/Cons)
Pros
True Trust-Minimized Ecosystem: Currently, the vast majority of decentralized applications (dApps) and light wallets on Cardano rely on centralized indexers and backend APIs to query ledger states. Gerolamo eliminates these single points of failure by letting client applications verify transactions and UTxO sets directly within a web worker.Cardano-Only Structural Advantage: Cardano's unique eUTxO architecture allows local state verification. A browser node doesn’t need to hold the entire global ledger state to validate the exact transaction path it interacts with, providing a massive scalability and user experience advantage over account-based L1 platforms.
Client & Node Tier Diversity: Relying entirely on a single node implementation poses systemic risk. Adding a production-grade TypeScript/Wasm client client provides structural resilience to the tier handling user interactions.
Strong Strategic Alignment: The proposal natively meets the core benchmarks outlined in the Cardano 2030 Strategic Framework, specifically advancing "Ecosystem Growth & Real-world Adoption" by significantly lowering hurdles for light wallet providers.
Cons
Substantial Treasury Allocation: The request of ₳4,600,000 represents a major capital deployment from the global treasury.Technical and Maintenance Risks: Maintaining cross-era hard-fork compatibility inside a browser environment over a long period introduces complex up-keep requirements, placing high reliance on the sustained commitment of HLabs.
Final Recommendation
Vote: YES
Rationale
The implementation of a true browser-based node is a fundamental paradigm shift for client-side decentralization. While the capital layout is substantial, the milestone-driven framework, clear 5-FTE resource management, and alignment with the open-source ethos justify the investment. Crucially, this action builds upon previous governance feedback, bringing refined structural parameters and clear delivery indicators.Historical Coherence Check
Our previous stance regarding early technical architectures or tooling frameworks from HLabs leaned cautious (e.g., voting "No" on the Pebble + Gerolamo HLabs framework earlier in April 2026 due to budgetary/packaging parameters). However, this resubmitted, focused proposal presents distinct clarity, isolation of scope, and a strong risk-mitigated milestone schedule. Evolving technical alignment and structured accountability parameters warrant this transition to a YES vote.Latin American Ecosystem Impact
For Latin America, local web infrastructure and mobile-first limitations often restrict user interaction with fully sovereign full nodes due to high hardware overhead. By facilitating a secure, ultra-lightweight node that operates right inside consumer web browsers and web workers, Gerolamo vastly lowers the entry barrier for LatAm developers and everyday users. It enables localized dApps and light wallets to function securely without high-bandwidth infrastructure dependencies, amplifying true financial sovereignty and trustless web3 access across the region. - Yes796.1K ₳Rationale
I like the team and what they are trying to do here. I get there is some execution risk, and that even without this the node diversity roadmap has multiple avenues in progress. But this is also unique and compelling in terms of a competitive advantage that would make some noise.
- Abstain792.3K ₳No rationale
- No742.6K ₳Rationale
No!
- Yes636.4K ₳No rationale
- Yes604.7K ₳Rationale
Ask: ₳4,600,000 FTE cost: $200K/year Duration: Q2 2026 – Q1 2027 (12 months) Oversight board: Santiago Carmuega, Lucas Rosa, Chris Gianelloni Gerolamo is genuinely differentiated infrastructure. Cardano's eUTxO design
A PDF version of this rationale is also made available.
I'm voting yes on Gerolamo for the same reason I voted yes on the combined proposal it was originally part of: a fully-validating browser node is something only Cardano can build without redesigning its base layer, and shipping it turns a latent architectural advantage into a competitive moat. Most Cardano wallets and dApps currently depend on centralized API providers to interact with the blockchain. That dependency reintroduces trust assumptions that decentralization is supposed to eliminate and it makes browser-based governance participation fragile in ways that matter to me directly. Gerolamo's browser extension, backed by its own validating node and exposing a CIP-30-style messaging API, removes that dependency at the application layer. A DRep with Gerolamo installed can verify chain state locally. A wallet can query UTxOs without asking Blockfrost. That's not a convenience feature; it's what "trustless" is supposed to mean in practice.
HLabs builds on its own production infrastructure here. The ouroboros-miniprotocols-ts library, the TypeScript implementation of Cardano's networking stack that Gerolamo's peer connectivity layer runs on is maintained by HLabs and in production use across the ecosystem. This team isn't learning how to implement mini-protocols in TypeScript; they wrote the library everyone else depends on. The browser-specific engineering challenges are real (IndexedDB performance, WebSocket proxy architecture, stable peer management across browser sessions) but these are solvable engineering problems, not open research questions. The M4 requirement of ≥15 stable peers maintained for ≥24 hours across ≥3 independent browser sessions with a non-Chromium screencast committed to the repo is a strong production-readiness bar.
At ₳4,600,000 (~$1.15M at $0.25), five FTEs at $200K annually with the best kickoff ratio in this batch (10% upfront, 90% against quarterly deliverables), the ask is appropriately scoped. The governance structure is the same dual-audited SundaeLabs escrow and same three-person oversight board with unilateral pause rights as the Pebble + tooling proposal. The public transaction journal and monthly status updates add a layer of transparency that exceeds anything else in this budget cycle. Separating Gerolamo from the combined proposal is better governance and it lets DReps evaluate each deliverable on its own merits and prevents a single component concern from blocking unrelated work. The merits here are clear. - Yes591.1K ₳Rationale
I support this proposal because it develops a genuinely unique capability that few, if any, other blockchain ecosystems can realistically deliver: a fully validating Cardano node running directly in the browser, providing both meaningful decentralisation benefits and a powerful marketing differentiator that showcases Cardano’s architectural strengths in a tangible, user-facing way.
- No579.1K ₳Rationale
Voting: NO ❌
Harmonic Labs is asking for 4.6 million ADA from the Cardano treasury for the Gerolamo project — a browser-based light node for dApps and wallets.
The idea sounds attractive:
run a validating Cardano node directly inside the browser and reduce dependence on centralized RPC servers and APIs.But in reality, this looks like another expensive R&D experiment wrapped in decentralization marketing.
📌 My position is simple:
I vote NO.Cardano does not need another multi-million ADA research proposal with endless milestones, audits, reports, and FTE calculations.
The ecosystem needs:
— real adoption
— real users
— real liquidity
— real growth4.6 million ADA is a massive amount of treasury funds.
And what does the average ADA holder get right now?
Almost nothing.
No direct impact on adoption.
No major increase in network activity.
No meaningful benefit for the majority of users.Again:
roadmaps, committees, reports, oversight boards, milestones.A lot of presentations.
Very little real-world impact.The Cardano treasury should not become an endless ATM for teams constantly asking for millions before delivering meaningful ecosystem-wide results.
First results.
Then more funding.My vote: NO ❌
I registered as a DRep and I am ready to help shape the future of the ecosystem.
Optimistic about building the largest digital community in the world. 🖤My DRep ID:
➡️ drep1y269ehxj3...2fg2jrMore details: https://t.me/PROCENT666/338
#Cardano #ADA #DRep #CardanoGovernance #Web3 #Crypto #Blockchain #DeFi
- Yes573.2K ₳No rationale
- No568K ₳Rationale
No node needed in the browser ATM.
- No550.1K ₳No rationale
- No501.3K ₳Rationale
- Yes488.9K ₳No rationale
- Yes479.2K ₳No rationale
- Yes466.2K ₳No rationale
- Yes438.6K ₳No rationale
- No393.6K ₳No rationale
- Yes379.5K ₳No rationale
- NoRevoted366.6K ₳History
Earlier votes
No3mo agoSuperseded
No3mo agoSuperseded
No4mo agoSuperseded
- Yes356.1K ₳Rationale
Sticking to my initial vote decision for this, and it's an even easier decision now that Pebble was separated: Three new nodes on the treasury payroll at once may seem like too many, however a browser-capable node is incredibly valuable. So for that alone, this has my support.
- No342.8K ₳No rationale
- No338.2K ₳No rationale
- No330.6K ₳No rationale
- Abstain318.1K ₳Rationale
Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
Reading proposals and staying updated, just like you.
Thanks to all fellow DReps who are also doing the hard work.
Follow and DM me on X: @kenerik if you have any questions. - Yes314.4K ₳Rationale
In line with my past vote, I'm voting YES for Gerolamo. This in-browser light node gives Cardano trustless on-device validation for dApps/wallets.
A PDF version of this rationale is also made available.
In line with my previous vote, I am voting YES for Gerolamo. Cardano uniquely benefits from an in-browser, fully-validating light node that allows wallets and dApps to verify data directly on-device without trusting centralized servers. While this phase focuses on client-side validation to contain costs, I strongly entertain the idea of this project evolving into a full block-producing client node during a secondary funding phase in 2027.
- No313.8K ₳No rationale
- Abstain301.3K ₳Rationale
Please, I need you to include in future proposals the same in PDF format. With so many proposals being uploaded per week, it is almost impossible for one person to read all of this. We need PDFs to use them in AI tools and analyze the information faster regarding what I look for in a proposal. For that reason, I vote No.
- Yes297K ₳Rationale
Voting YES on The first node in the browser; a Cardano USP
May 22nd 2026
Summary
The request comes from Harmonic Laboratories. In this proposal they are asking for a total of 4,600,000 ADA to develop Gerolamo which is a Cardano node running in the web browser.
Quote: This proposal funds Gerolamo, the first production-ready Cardano node that runs in the browser, at 5 FTE.
Conclusion
I think this is a great proposal. I voted for the previous hlabs budget and felt it a shame it did not pass (see that vote context here). I'm glad they've resubmitted and I hope we can get it across the line this time.
Signed,
William DoyleYour friendly neighbourhood DRep!
$computerman
drep1yfpgzfymq...pzw3nt
@william00000010 on 𝕏
contact@williamdoyle.ca - No285.2K ₳No rationale
- Yes275.2K ₳Rationale
I am voting YES on “The first node in the browser; a Cardano USP.”
This proposal funds Gerolamo, a TypeScript implementation of a Cardano node scoped to a production‑ready browser‑extension light node that dApps and wallets can use for local, trust‑minimized validation instead of relying entirely on centralized RPC/indexer infrastructure. It directly advances the Cardano 2030 KPI for alternative full node clients and the “Security & Resilience → Client Diversity” objective by adding an independently developed client in a different runtime and footprint (browser/TypeScript) than the existing Haskell and Rust implementations.
The scope and budget are focused and reasonable for core infrastructure. The ask is 4,600,000 ADA (~USD 1.15M at 0.25), representing 5 FTE at USD 200k/year plus a 15% contingency. The rate is clearly defined as a company‑level rate that includes taxes, non‑developer staff, compliance, legal, and an independent financial audit, not just salaries. The work is strictly limited to the browser light‑node use case: full block production, SPO infrastructure, and server‑side relay roles are explicitly out of scope for this funding period, which keeps the mandate narrow and avoids overlapping with Amaru and other server‑side clients.
Deliverables and milestones are objective and user‑relevant. Over 12 months (Q2 2026–Q1 2027), the plan is to:
Implement full ledger rules and Praos chain selection in a browser‑compatible way, with state stored in IndexedDB and correct rollback handling.
Release a public browser extension (e.g., via Chrome Web Store) exposing a messaging API for basic and indexed queries (tip, UTxO by output reference, UTxOs by address/asset, plus transaction submission), along with a demo dApp that demonstrates these flows against a public testnet without any backend.
Achieve stability criteria: syncing from genesis to tip, maintaining ≥15 peers for extended periods, correct behaviour across rollbacks, and working in at least one non‑Chromium browser (e.g., Firefox or Safari).
Acceptance criteria are tied to tagged releases, sync logs, store listings, tests, screencasts, and public documentation, not self‑reported status, and production‑readiness is defined in terms of sync reliability, performance, peer connectivity, and rollback safety.
Governance, custody, and oversight are strong. Funds are held in SundaeLabs’ treasury.ak/vendor.ak contracts, audited and in production, with milestone‑based disbursement gated by an independent oversight board (TxPipe, Aiken/Midnight, BlinkLabs/Dingo) that can co‑sign releases, pause milestones, and help sweep unused funds back to the Treasury. The proposal includes an independent financial audit of fund flows (quarterly plus final), monthly public updates, quarterly detailed reports (technical and financial), and a transaction journal logging every on‑chain action tied to this GA. All escrowed ADA is delegated to the always‑abstain DRep and cannot be staked with SPOs; any remaining funds after expiry are automatically swept back to the Treasury at the contract level. The proposers also reference a 2025 retrospective on prior funding and delivery, which is important for continuity and accountability.
I acknowledge the concerns raised by some DReps about execution risk, demand visibility, and the number of concurrent node efforts. A fully validating browser node is technically challenging, and adoption by wallets and dApps will need to be earned over time. However, this proposal is one‑year, tightly scoped, and heavily milestone‑gated, with independent technical and financial oversight. It does not seek to fund another general‑purpose full node; it targets a unique niche that Cardano’s eUTxO design makes realistic: on‑device, browser‑based validation for dApps and light wallets. In my view, that is the kind of foundational, decentralization‑oriented infrastructure the treasury should support, especially when the ask is moderate and the accountability structure is strong.
For these reasons, I am comfortable voting YES on this proposal. - NoChanged272.2K ₳History
Earlier votes
Yes4mo agoSuperseded
- No268.9K ₳No rationale
- Yes260.8K ₳No rationale
- Yes232.8K ₳No rationale
- Yes216.4K ₳No rationale
- Abstain202.8K ₳No rationale
- Abstain191.9K ₳Rationale
not a techie, but this seems cool. we have a lot of node client teams, which is fantastic for the ecosystem. i can't make an expert assessment on whether we need this one too, so i'll abstain
- No189.8K ₳No rationale
- YesChanged185K ₳History
Earlier votes
No3mo agoSuperseded
- Yes182.7K ₳No rationale
- Abstain161.1K ₳No rationale