Pebble + Gerolamo - HLabs 2026 Budget
199 DReps voted · 87 with a rationale · 21 changed their vote
Open a row to read the rationale.
- Yes1.7M ₳Rationale
I support node diversity. The reward is the mitigation of risk and benefits the ecosystem
- Abstain1.6M ₳No rationale
- Yes1.6M ₳Rationale
I believe this node implementation will play an important role in the decentralization of Cardano, because it enables dApps and light wallets to directly verify stuff instead of relying on APIs. It adds to the diverse node landscape (I previously stated that I think 3–5 different node implementations would be ideal, so this would be the 4th I support).
I think the Pebble smart contract language will also be a good alternative to existing ones. - Yes1.6M ₳Rationale
Don't mind me, I'm just collecting my voting reward at https://voting-rewards.harmoniclabs.tech/
- No1.5M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳No rationale
- Yes1.4M ₳Rationale
Vote: YES — Harmonic Laboratories (HLabs) Proposal
This proposal is a strong infrastructure investment that advances decentralization, developer accessibility, and ecosystem resilience through Gerolamo (light node), Pebble (smart contract language), and ongoing TypeScript tooling maintenance.
It aligns well with Cardano 2030 priorities. Gerolamo supports client diversity and reduces reliance on centralized infrastructure, while Pebble lowers the barrier for mainstream developers. Continued tooling maintenance ensures stability across hard forks and avoids fragmentation risks.
The value proposition is clear: enabling trust-minimized dApps and wallets, expanding the developer funnel, and maintaining critical ecosystem dependencies. The budget is substantial but justified, with transparent FTE-based costing and a reasonable contingency.
Governance safeguards are robust, including milestone-based escrow, independent oversight, and treasury protections, significantly reducing execution risk.
There are execution and adoption risks, particularly around scope and Pebble uptake, but these are acknowledged and mitigated through milestones and measurable targets.
Overall, this is a credible, well-structured proposal addressing key ecosystem bottlenecks.
Final Position: YES
- No1.4M ₳No rationale
- Yes1.3M ₳No rationale
- Yes1.1M ₳No rationale
- No1.1M ₳Rationale
I will not support the withdrawal of a hefty 8M ADA for a package that bundles one clearly defensible need with two much less proven expansion bets. The proposal splits the work into 5 FTEs for Gerolamo, 3.5 FTEs for Pebble, and 1.5 FTEs for hard-fork maintenance, using 10 FTEs at $225k (quite hefty for 1 FTE!!) each plus a 25% contingency. That immediately tells me where the weight of the ask really sits: not in essential ecosystem maintenance, but in building out a browser-capable TypeScript node and pushing a new smart-contract language.
I can see the strategic argument for Gerolamo. A production-ready light node that runs in JavaScript environments and even browsers could improve accessibility, reduce dependency concentration, and broaden integration options. That is serious work, no doubt, but not worth $225k per FTE on average! Seriousness alone does not justify the full price. I have to ask whether the treasury should pay this much, in one motion, for infrastructure that is still proving itself, especially when the proposal itself positions Gerolamo relative to other node implementations rather than as the only viable path.
Pebble is even less convincing to me. It's framed complementary to Aiken, aimed at developers more comfortable with TypeScript, JavaScript, and Solidity-style thinking. I understand the logic. I still do not find it strong enough though. Cardano benefits from better tooling, but it does not automatically benefit from every additional language surface! I said this earlier: New languages create fragmentation risk, documentation burden, maintenance overhead, and long-tail support expectations. The proposal says this expands the developer funnel; I say that claim remains aspirational unless adoption is demonstrated beyond a “more familiar syntax” narrative. Familiarity is not, by itself, a treasury-grade investment thesis.
What makes me most cautious is the packaging. If the real priority is hard-fork readiness for widely used TypeScript libraries, then that should have been presented with much sharper focus. If Gerolamo is the flagship, then it should stand on its own economic and technical merits. If Pebble is the growth bet, then it should compete for funding as a distinct initiative with a much higher burden of proof on adoption. Bundling all three together feels strategically convenient for the proposer, but not disciplined enough for treasury stewardship!
I do not see a convincing case for approving the full ₳8.04M bundle as presented.** I vote No because I refuse to let necessary maintenance be used as the vehicle for funding a much broader and far more speculative expansion agenda.**
- Yes971.5K ₳Rationale
🟢 Rationale – YES on Pebble + Gerolamo (HLabs 2026 Budget)
We vote YES on this proposal.
Harmonic Laboratories (HLabs) has established itself as a trusted and highly relevant contributor within the Cardano ecosystem, particularly through its ongoing work on TypeScript tooling that already underpins a large part of current development activity.
A key strength of this proposal is its contribution to node diversity. Multiple independent node implementations are critical for the long-term resilience of the network. Beyond pure redundancy, different implementations bring different perspectives and architectural approaches, which improves overall system robustness. Additionally, more diverse, open-source implementations expand the available dataset for emerging tooling (including AI-driven development workflows), enabling better understanding of the protocol and ultimately making it easier for developers to build on Cardano.
We also see strong value in the TypeScript-first approach. TypeScript is one of the most widely used programming languages globally, and lowering the barrier to entry for this developer base is a major lever for ecosystem growth. By enabling developers to interact with Cardano using familiar tools and paradigms, this proposal significantly improves onboarding and reduces friction.
In particular, Pebble creates a bridge for Web2 and EVM developers, while Gerolamo expands infrastructure accessibility through lightweight node implementations, including browser-based use cases. Together, these components make it easier to build, test, and deploy real-world applications on Cardano.
Overall, this proposal strengthens infrastructure, developer experience, and ecosystem accessibility in a coherent and well-aligned way.
- Yes964.1K ₳No rationale
- Abstain931.8K ₳No rationale
- Yes861.5K ₳No rationale
- No825.2K ₳Rationale
In line with our previous voting, we undescore the relevance of prioritizing the community's effort and treasury in growth, adoption and real world use cases.
We recognize the value of the continued development of technical tooling but we believe this is not the right time for this. - Abstain798.6K ₳Rationale
As early-stage dApp builders, we're abstaining and deferring to more experienced ecosystem developers who are better positioned to evaluate the technical merit of this proposal.
- Yes798.4K ₳No rationale
- No794.5K ₳Rationale
I'd like to see node diversity options rolled up and evaluated under a more strategic and focused Intersect initiative. Prefer to see the major initiatives in this proposal not bundled. And, given our depressed market, I'm not fully convinced that that the demand side of the equation justifies the extent of this investment.
- Yes776.8K ₳Rationale
Light nodes are crucial infrastructure for on-chain interactions and integrations, which can reduce friction and cost for new application to emerge.
As previously stated in past rationale, node diversity is not something that should be the responsibility of founding entities, as this centralizes the codebase (including exploits and vulnerabilities) and the maintenance thereof.
- No763.4K ₳No rationale
- Abstain763.4K ₳No rationale
- NoChanged759K ₳Rationale
Voting No as written. It could be good for Cardano, but the ask is quite large at current ADA prices.
Earlier votes
Yes3mo agoSuperseded
- Yes717.5K ₳No rationale
- Yes705.1K ₳Rationale
I'm voting yes in the hopes that this team delivers all that is promised for our ecosystem, Abstract Harmonic Laboratories (HLabs for short) is an R&D firm born and focused solely on the Cardano ecosystem. This proposal delivers critical infrastructure: Gerolamo enables browser-based light nodes for trustless dApps, Pebble lowers the barrier for TypeScript developers to build smart contracts, and ongoing tooling maintenance ensures ecosystem stability across hard forks. With strong governance through audited escrow and independent oversight, ₳8M for 10 FTEs over 12 months is a reasonable investment in Cardano's long-term decentralization and developer adoption. Pebble = TypeScript devs (17M+) can build Cardano smart contracts without learning functional programming Gerolamo = dApps run their own nodes instead of trusting centralized servers Tooling maintenance = devs don't get screwed by protocol upgrades Lower barriers = more devs = more dApps = better ecosystem. Simple math.
- No705.1K ₳No rationale
- Yes652.3K ₳No rationale
- Yes625.9K ₳Rationale
I'm voting yes on the HLabs Pebble + Gerolamo proposal because it addresses complementary infrastructure gaps that neither Amaru nor Dingo cover: a browser-native light node enabling dApps and wallets to escape centralized indexer dependency, an imperative smart contract language targeting the 17 million+ TypeScript/JavaScript developer pool, and sustained maintenance of foundational TypeScript tooling the ecosystem already depends on. While the proposal has legitimate administrative and cost-justification weaknesses, the strategic value of expanding Cardano's developer funnel and enabling trustless browser-based chain verification outweighs those concerns.
Gerolamo is not redundant to existing alternative node efforts, it's explicitly designed as a TypeScript light node for browsers, not a block-producing node. Most Cardano dApps currently rely on centralized indexers or third-party APIs, reintroducing trust assumptions that decentralization is meant to eliminate. A production-ready browser node lets dApps verify UTxO states locally without external services and enables light wallets to offer Daedalus-level security with light wallet UX. This is a full-node in the browser connecting users directly to the blockchain with no middleman, no APIs, no trusting wallet providers, truly needed for P2P DeFi. SPOs can also deploy Gerolamo as a relay alongside Haskell nodes, adding codebase diversity at the networking layer. This creates a different category of value from Amaru/Dingo's block-producing ambitions and directly addresses the platform's missing layer for browser-native chain access.
Pebble expands the developer funnel without fragmenting it. Pebble targets engineers fluent in TypeScript/JavaScript/Solidity-style imperative syntax which is the largest developer community globally. Haskell (Plutus) and Aiken are primarily functional languages, which can be complex for developers with only imperative language experience. Pebble uses an imperative-first paradigm with familiar syntax patterns, compiling to optimized UPLC like Aiken while lowering the barrier for Web2 and EVM developers. Cardano having multiple legitimate on-ramps that serve different mental models and experience backgrounds is essential This directly supports Cardano 2030 Pillar 2 (Adoption & Utility) by expanding the total addressable developer pool.
The hard-fork tooling maintenance component, 1.5 FTE for cardano-ledger-ts, ouroboros-miniprotocols-ts, plutus-machine, and uplc, is non-optional public good infrastructure. These TypeScript libraries are load-bearing for a substantial share of Cardano's developer ecosystem, often as transitive dependencies in SDKs, off-chain code, and tooling. When hard forks change protocol parameters, these libraries must be updated promptly or downstream projects face breaking changes and silent correctness bugs. Funding sustained maintenance is one of the highest-leverage line items in this proposal, ensuring continuity through protocol upgrades and reducing operational burden for developers building on this stack.
The governance structure matches the standard I've already endorsed for Amaru and Dingo. Funds are held in SundaeLabs treasury-contracts, the same audited escrow framework used by other alternative node implementations, audited by TxPipe and MLabs. The independent oversight board (Santiago Carmuega/TxPipe, Lucas Rosa/Aiken-Midnight, Chris Gianelloni/BlinkLabs-Dingo) has no stake in HLabs and carries direct technical credibility in Cardano infrastructure. Auto-abstain DRep delegation, no SPO delegation, failsafe sweep at contract expiration, same accountability mechanisms I've approved twice before.
That said, this proposal has structural weaknesses that institutional-grade treasury management should flag. The administrative and cost-justification layers lack the rigid structure expected for $2.25 million in expenditures over 12 months. The budget treats administrative operations as invisible overhead bundled into a flat $225,000 per FTE rate, hiding actual engineer costs versus company operating expenses. There's no dedicated project management role for a 12-month project with 10 FTEs, no breakdown of general and administrative costs (rent, legal, HR, accounting), and no explicit basis of estimate showing how much of that $225,000 is base salary versus fringe benefits versus overhead versus fee/profit.
The proposal also lacks clarity on human capital and hiring risk. The budget assumes 10 FTEs but doesn't specify if those people are currently on staff or need to be hired. There are no staffing milestones, no key personnel clauses protecting against critical team member departures, and no defined non-delivery recourse beyond the board's ability to pause funding. The 25% refundable contingency is a red flag—it's labeled as a buffer for "optimism bias" rather than allocated against specific identified risks with management reserve protocols. Standard contracts require monthly status reports and financial reporting; this proposal only commits to quarterly milestone demos.
I would prefer to see labor categories explicitly defined (2 senior systems architects, 6 software engineers, 2 QA/DevOps leads) rather than treating FTEs as interchangeable units, a formal basis of estimate with salary/benefits/overhead breakdown, staffing milestones with hiring timelines, monthly financial and progress reporting rather than quarterly demos, and risk-allocated contingency with management reserve protocols rather than a blanket 25% buffer. These administrative gaps create execution risk and make oversight harder for the board and the community.
Despite these concerns, I'm voting yes because the strategic value is clear and the technical deliverables are measurable. Quarterly completion evidence is publicly demonstrable: all HLabs libraries supporting the hard fork, Gerolamo syncing to tip on public testnet, multiple Pebble contracts compiled end-to-end to valid on-chain code, browser demo querying chain data without backend servers, IDE extension published with syntax highlighting and inline errors.
The administrative weaknesses are real, but they don't justify blocking foundational infrastructure that reduces operational risk, improves developer throughput, and makes Cardano more reliable for building real-world applications. HLabs has demonstrated execution through existing TypeScript tooling maintenance, they're not unproven builders asking for speculative funding. The oversight board can enforce milestone discipline, and the failsafe sweep returns unused funds. In tough market conditions where treasury resources are constrained, investing in core infrastructure that expands the developer base and enables browser-native trustless verification is higher leverage than waiting for perfect administrative polish. - No605.7K ₳Rationale
📌 AS A DREP — I AM AGAINST THIS PROPOSAL
This is not a small, targeted funding request.
This is a large withdrawal from the Cardano treasury based on future promises.The proposal asks for 8,035,714 ADA.
And it is not only for a node.
It includes:
• Gerolamo
• Pebble
• TypeScript infrastructure maintenance
• hard fork readiness
• IDE tooling
• documentation
• extra contingency on top👉 In simple terms: they want the money now, while the results are promised later.
🔥 What I do not like
• The node is not ready yet
• Block production is not even part of the current goal
• The project is stretched over 12 months
• The budget looks like full team funding from the treasury
• They also added 25% contingency, meaning extra funds for miscalculations and delaysThis no longer looks like a modest infrastructure request.
It looks like an attempt to pull a large amount from the treasury under a broad package of promises.📉 What the real issue is
A node can be launched with much less funding.
Especially when this is not a full production block-producing node, but a light node, relay, or developer tool stack.Here, under the banner of “decentralization” and “ecosystem growth,” several separate directions were bundled together and charged to the treasury as one large package.
🧩 My view is simple
Cardano needs network resilience.
Cardano needs developers.
Cardano needs tools.But that does not mean every polished proposal with big words should be paid from treasury funds.
If the product is not ready, if the result is still just a plan, and the amount is already huge — that is a bad signal for me.
⚠️ So my position is clear
As a DRep, I am against it.
I do not support withdrawing this level of funds from the treasury for unfinished promises, stretched timelines, and an oversized scope.The Cardano treasury is not a funding pool for polished presentations.
It should be used for real, measurable, proportional results.🚀 КУРС «LEDGER ХОЛОДНЫЙ КРИПТОКОШЕЛЕК» | METAMASK
https://edgarbagdasarian.justclick.ru/order/LEDGERMETAMASK🔥 ЗАКРЫТЫЙ VIP ЧАТ ПЛАТНАЯ ПОДПИСКА
https://t.me/MREDGARCROSS_BOT🌐 ВСЕ КУРСЫ И ССЫЛКИ
https://mredgarcross.com/📌 Note: This post is for informational and analytical purposes only. It does not contain calls for action, protests, or violation of any law. Everything stated here reflects the author’s personal analysis and reflections.
- Yes589.7K ₳Rationale
Approving this proposal as it invests in infrastructure, developer tooling, and smarter contract capabilities that collectively lower barriers to building on Cardano, strengthen decentralisation, and enable sustainable long-term ecosystem growth.
- No535.2K ₳Rationale
The least capable team building a full node for Cardano, already took massive amounts of funds with little to show for it.
- Yes533.9K ₳Rationale
Now is the time to implement and take the lead while the other chains and industry struggle. Push forward now and grow the treasury revenue streams through infrastructure that will lead to more future use. Fiscal responsibility is critical at the moment as well and future endeavors will continue to become more scrutinized until treasury revenue picks up
- Yes501K ₳Rationale
I support this. Because Cardano does not need more decorative optimism. It needs infrastructure, maintenance, and fewer single points of failure. This proposal is funding real work with measurable outcomes and actual accountability. Pebble should absolutely be watched closely for adoption, but overall this is the kind of treasury spending that strengthens the ecosystem instead of just producing another conference panel about potential.
- No499K ₳Rationale
- YesRevoted479.9K ₳History
Earlier votes
Yes3mo agoSuperseded
- Yes478.3K ₳No rationale
- Yes466.2K ₳Rationale
I fully support this initiative !
- Yes442.9K ₳No rationale
- Abstain414.2K ₳No rationale
- No409.7K ₳Rationale
The amount is too large. Despite the large sum demanded, there's no clear promise of a rigorous accounting report to match.
- Yes383K ₳No rationale
- Yes381.1K ₳No rationale
- Yes365.7K ₳No rationale
- No360.3K ₳No rationale
- YesRevoted325.4K ₳Rationale
I support this proposal primarily because Pebble and the node are being developed in TypeScript, which significantly lowers the barrier to entry for new developers. With TypeScript becoming the most used language on GitHub as of August 2025, surpassing both Python and JavaScript, it offers a large and growing talent pool. This increases the likelihood of broader contribution, faster iteration, and long-term maintainability. For these reasons, I vote YES.
Earlier votes
Yes3mo agoSuperseded
Yes3mo agoSuperseded
- Abstain320.4K ₳No rationale
- YesChanged314.4K ₳Rationale
I’m voting YES on HLabs. Despite initial budget concerns, Gerolamo’s browser-native resilience and Pebble’s imperative syntax offer unique strategic value. These tools enable true decentralization and lower entry barriers for devs, justifying this vital treasury investment.
A PDF version of this rationale is also made available.
Summary
After deep reflection and additional research, I have decided to vote YES on the Harmonic Laboratories proposal. While I initially had reservations regarding the budget, my further research into the unique "serverless" resilience of the Gerolamo node and the onboarding potential of the Pebble language has convinced me of its strategic value for Cardano.
Transparency & Due Diligence Disclosure
I want to be as transparent as possible with my delegators: I am not a technical expert. Recognizing this, I have spent additional time researching this proposal and weighing the rationales of respected DReps whose technical judgment I value. Specifically, the views of Input Endorsers, Cardano Yoda, Cerkoryn, Varavas, Yuta, Dave, and Chris Cata were instrumental in helping me navigate the complexities of this action.
Furthermore, I was approached by the Harmonic Labs team to discuss my initial concerns. Our dialogue was productive and allowed me to gain a much deeper understanding of the project’s scope.Rationale
- True "Don’t Trust, Verify" for Users: Gerolamo is a different "beast" because it is a TypeScript implementation capable of running directly in a browser. This allows users and dApp developers to verify the ledger on their own devices rather than relying on 3rd-party APIs. This provides a level of censorship resistance and "serverless" resilience that is currently a missing piece in our ecosystem and more aligned with my self-sovereignty / “power to the edges” philosophy.
- Lowering the Developer Barrier: I am now convinced that Pebble is a vital "on-ramp”. By offering an imperative programming style familiar to the 17 million JS/TS and Solidity developers, we can onboard talent more effectively than through functional programming alone.
- Clarification on Costs: My main concern was the high cost of FTEs. The team successfully explained that these figures represent the total revenue distribution required to support a high-level operation - including taxes, benefits, and overhead - rather than just base salaries. To attract and retain the tier of engineering talent required for a node implementation, these rates are a necessary investment.
Conclusion
Cardano needs more than just core infrastructure; it needs tools that make it easy for users to be self-sovereign and for developers to build. This proposal delivers both. While the budget remains a significant ask, I believe the long-term benefits to our decentralization and adoption metrics justify the investment.
Earlier votes
No3mo agoSuperseded
I am voting NO on this proposal. While I remain a strong advocate for technical diversity and highly respect the HLabs team, I believe that at this moment, the treasury must prioritize the maturation of existing node projects and exercise greater fiscal conservatism.
A PDF version of this rationale is also made available.
My decision is based on a strategic assessment of our current infrastructure landscape and treasury health:
Diminishing Returns on Node Diversity: I have been a vocal supporter of multi-language client diversity, as evidenced by my previous "YES" votes for Amaru (Rust) and Dingo (Go). However, we must ask: how many concurrent node implementations are enough for the current stage of the ecosystem? I believe we are approaching a point of diminishing returns. We should allow our current alternative nodes to materialize and reach production readiness before committing significant funds to a fourth implementation.
Budgetary Concerns & Treasury Impact: An ask of 8,035,714 ADA is a substantial withdrawal. Furthermore, I find the valuation of $225,000 per FTE to be very expensive. As a DRep committed to "justifiable spending", I cannot support such high premium rates at a time when we should be maximizing the "bang for buck" for our delegators.
Strategic Timing: I would be open to reconsidering this request in the future (perhaps in a year’s time). A later date would allow us to evaluate the progress of ongoing node projects and potentially benefit from a more favorable ADA price, which would reduce the total ADA burden on the treasury.
Note on the Team and Technology
I want to clarify that this vote is not a reflection on Harmonic Laboratories. I consider the selection of TypeScript for the Gerolamo node and the Pebble language to be a brilliant strategic choice that would undoubtedly lower the barrier for millions of developers. My "No" is strictly a matter of timing and budget, not a lack of faith in the tech or the team’s capabilities.
- Yes313.4K ₳No rationale
- YesChanged300.6K ₳History
Earlier votes
No2mo agoSuperseded
I like the proposal, however at this times with $ADA at 0.25, this is not a priority.