Pebble + Gerolamo - HLabs 2026 Budget
199 DReps voted · 89 with a rationale · 11 changed their vote · 9 re-voted unchanged
Open a row to read the rationale.
Changed votes: 8 to yes, 3 to no, together voting with 225.1M ₳ of voting power.
- Abstain11.9M ₳No rationale
- No10.9M ₳No rationale
- AbstainChanged10.3M ₳Rationale
I wanted to add a rational. Wasn't able to do this without changing my vote from Abstain to No. I will change to Abstain again
I can the advantage Gerolamo for non-tech people, easy onboarding for a light node. Different from other proposals. I would vote Yes if it was only for Gerolamo.
I cannot say (as I'm not a developer) Pebble, is advantageous or not. This is why I would prefer that the proposals be separated. I would vote Abstain on Pebble and Yes for Gerolamo.
Earlier votes
No5mo agoSuperseded
I wanted to add a rational. Wasn't able to do this without changing my vote from Abstain to No. I will change to Abstain again
I can the advantage Gerolamo for non-tech people, easy onboarding for a light node. Different from other proposals. I would vote Yes if it was only for Gerolamo.
I cannot say (as I'm not a developer) Pebble, is advantageous or not. This is why I would prefer that the proposals be separated. I would vote Abstain on Pebble and Yes for Gerolamo.
Abstain5mo agoSuperseded
- YesRevoted9.8M ₳History
Earlier votes
Yes4mo agoSuperseded
- YesChanged9.5M ₳Rationale
My initial hesitation was around whether this directly drives near-term adoption and user growth. I still believe that’s the primary gap Cardano needs to solve, and that we need to be intentional about building stronger demand-side pipelines across the ecosystem.
That said, I also recognize that this proposal contributes to foundational capabilities that align with where we want the ecosystem to go—particularly around trustless access and developer experience.
This isn’t a shift away from my broader view that we need to prioritize adoption, but rather an acknowledgment that we can—and should—do both. Strengthening the foundation while building better pathways to users doesn’t have to be mutually exclusive.
Earlier votes
Abstain5mo agoSuperseded
I am voting Abstain.
This proposal is technically sound and budget-wise manageable. I do not view it as irresponsible from a treasury perspective. My hesitation is more strategic: I do not yet see how it changes anything meaningfully urgent for Cardano right now (the needed outcomes aren't aligned in my opinion).
Gerolamo, Pebble, and tooling maintenance may all be useful, but they read to me more as infrastructure and developer-capability expansions than as proposals that materially move users, growth, economic activity, or near-term developer demand. The key results are laid out fairly well, but they still feel more like technical outputs than ecosystem outcomes.
I have supported node diversity proposals such as Dingo and Amaru because those more directly advance client diversity and reduce single-client risk. This proposal is different. It may contribute to relay/light-node diversity and better tooling, but that is not the same strategic category to me - the outcome for the ecosystem (to me) just isn't there. "Nice to have, but not a need."
So this is not a No. I do not want to stand in the way if the broader ecosystem sees value here, especially given the manageable cost. But I cannot directly support it because I am not convinced it addresses Cardano’s most urgent priorities at this time. I think if we can address some other outcomes first - drive the user/economic growth - it'll help generate the demand for infrastructure that aids to more trust-less apps. Let's focus on generating demand to "pull" this type of infrastructure forward.
- Yes8.9M ₳Rationale
RCADA supports this treasury withdrawal proposal from Harmonic Laboratories (HLabs) as a high-impact infrastructure investment aligned with Cardano’s long-term decentralization, developer accessibility, and ecosystem resilience.
The proposal presents a coherent and well-structured funding request across three interrelated workstreams: Gerolamo (a TypeScript-based node implementation), Pebble (a developer-friendly smart contract language and tooling suite), and ongoing maintenance of critical TypeScript ecosystem libraries. While these components are bundled, we find that they form a vertically integrated and mutually reinforcing stack spanning infrastructure, developer experience, and ecosystem continuity. This distinguishes the proposal from broader multi-project bundles and supports its evaluation as a unified initiative.
From a governance and treasury perspective, the proposal demonstrates a mature and robust design. Funds are held in audited smart contract escrow, disbursements are milestone-based, and an independent oversight board with credible ecosystem representation has meaningful enforcement powers, including the ability to pause funding and co-sign releases. Importantly, unused funds are automatically returned to the treasury at contract expiry. These mechanisms provide strong safeguards against misuse and materially reduce execution risk.
We also recognize the strategic importance of the proposed deliverables. Gerolamo contributes directly to client diversity and decentralization, particularly through its light-node and browser-based capabilities. Pebble lowers the barrier to entry for a large pool of Web2 and EVM developers, expanding Cardano’s potential developer base without displacing existing tooling. Continued maintenance of foundational TypeScript libraries ensures ecosystem stability across protocol upgrades and reduces fragmentation risk. Collectively, these contributions align with the Cardano 2030 vision and represent meaningful public goods for the network.
That said, this proposal is not without concerns.
First, the inclusion of a 25% contingency buffer within the upfront funding ask raises important governance considerations. While the justification—accounting for uncertainty and optimism bias in complex R&D work—is reasonable, and while the escrow model ensures that these funds are not automatically disbursed, we remain cautious about the precedent this sets. Large pre-allocated contingencies, even when refundable, risk inflating treasury requests and reducing funding discipline over time. We strongly encourage future proposals to explore more conditional or milestone-triggered contingency mechanisms rather than incorporating significant buffers into the initial ask.
Second, although we find the bundling in this case to be justified due to the tight coupling of the three workstreams, we reiterate our general preference for modular governance actions wherever feasible. Bundling inherently limits DRep granularity in decision-making and should be applied carefully. This proposal sits at the acceptable boundary of that practice, but broader or less cohesive bundling approaches would likely not receive the same level of support.
In summary, RCADA views this proposal as meeting the bar for responsible treasury allocation: it is strategically aligned, technically credible, and supported by strong governance and oversight mechanisms. Our support should be interpreted as endorsement of this specific implementation and structure—not as blanket approval of bundled proposals or large upfront contingencies as a general standard.
We therefore vote YES, while signaling clearly that future proposals adopting similar patterns—particularly around contingency design—may face increased scrutiny and could result in an Abstain or No vote if not sufficiently justified or refined.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/
- YesRevoted7.6M ₳Rationale
A handful of things we get here that are of strategic importance in a tough market year for crypto. We get a new node implementation - production-ready light node Gerolamo that will allow DApps to run their own lightweight nodes. If Cardano light wallets are able to offer Daedalus-like security (I think it is a massive win), we might wake up thousands upon thousands of risk-averse Cardano holders from their long sleep and even bring over new risk averse crypto users.
We get a new programming language for smart contracts - pebble. With Cardano smart contracts being unique, lowering the hurdle brings competition and choice.
Third, we keep a competent infrastructure team actively working on key components of Cardano. Thus we gain more resilience and reduce dependency on one core provider. This directly helps ADA holders and the Treasury become less dependent one one core player. Competition and choice will lower costs and lower treasury outflows in the years ahead.
To quote a US president: In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing. We need to take action in times of difficulty. This is likely to be no ordinary year.Earlier votes
Yes5mo agoSuperseded
- Yes7.3M ₳No rationale
- Yes6.7M ₳No rationale
- Yes6.5M ₳No rationale
- No5.7M ₳No rationale
- Yes5.7M ₳No rationale
- Yes5.5M ₳Rationale
Node diversity, light wallet infrastructure and an easy & efficient smart contract programming language. It's a YES from me!
- Yes5.5M ₳No rationale
- No5.3M ₳No rationale
- Yes5.3M ₳Rationale
We vote YES. Harmonic Labs has been building Cardano-native infrastructure for years, and their TypeScript-first stack covering smart contract tooling, protocol libraries, and a lightweight node client addresses a real gap in the developer experience. Most alternative node efforts are oriented toward SPOs and validator infrastructure. Gerolamo and Pebble target the DApp and light client layer, where the quality of tooling directly shapes what builders can ship and how quickly the ecosystem can attract new developers.
- No5.2M ₳Rationale
We don’t think the priority right now is to explore entirely new approaches beyond Plutus or to chase another alternative that is marginally better than Aiken.
From our perspective, the current bottleneck of Cardano is not developer tooling or the lack of new technical directions. The real issue is the lack of users. When there are not enough users, there is not enough incentive for developers to come and build.
We see this as a sequencing problem. The ecosystem needs to reach a certain level of adoption before expanding into new smart contract paradigms. At this stage, even a significantly better developer experience will not drive meaningful adoption if user demand is still weak.
It is also important to point out that the limited adoption of Plutus is not mainly due to its complexity. Developers are willing to learn difficult systems when the opportunity is large enough. What is missing today is that opportunity, because the number of active users is still too small.
We recognize that there are architectural limitations such as missing event systems, lack of standard ABI patterns, limited composability, and difficulties with data heavy or compute heavy use cases. These are real issues, but they are not the primary constraint holding back growth right now. They only become critical when the ecosystem reaches a scale where those limitations start to block real demand.
Our position is simple. We should focus on growing the user base and creating real demand first. Once that foundation is strong, developers will naturally follow, and more advanced technical approaches beyond Plutus will become both necessary and impactful.
- Yes5.1M ₳No rationale
- Yes5.1M ₳Rationale
Great for node diversity. Pebble and Gerolamo also bring some really unique developer and user experiences that’ll help strengthen our ecosystem
- Yes4.9M ₳No rationale
- Yes4.8M ₳No rationale
- Yes4.5M ₳No rationale
- Yes4.4M ₳No rationale
- Yes4.2M ₳Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "Pebble + Gerolamo - HLabs 2026 Budget" (gov_action1ky2...uz3scv), pois ela apresenta potencial para fortalecer a infraestrutura do ecossistema Cardano, ao investir em ferramentas desenvolvidas em linguagens amplamente utilizadas, como TypeScript/JavaScript. Essa abordagem contribui para reduzir dependências centralizadas e ampliar o acesso de desenvolvedores, ao utilizar tecnologias mais familiares e acessíveis. A combinação entre manutenção contínua, desenvolvimento de novas soluções — como um light node — e melhorias na experiência de desenvolvimento tende a impulsionar a resiliência, a descentralização e o crescimento sustentável da rede, estando alinhada às metas estratégicas de longo prazo da Cardano. Além disso, consideramos a proposta bem estruturada sob a ótica de governança e responsabilidade no uso dos recursos do tesouro. O texto apresenta mecanismos claros de transparência e controle, incluindo administração via contrato inteligente, prestação de contas pública, auditoria financeira, devolução de saldos remanescentes ao tesouro e uso restrito da contingência exclusivamente para mitigação de volatilidade de mercado.
[English]
We chose to vote "YES" on this governance action "Pebble + Gerolamo - HLabs 2026 Budget" (gov_action1ky2...uz3scv), as it has the potential to strengthen the Cardano ecosystem infrastructure by investing in tools built with widely adopted programming languages such as TypeScript/JavaScript. This approach helps reduce centralized dependencies and broadens developer accessibility by leveraging more familiar technologies. The combination of ongoing maintenance, new solutions — such as a light node — and improvements to the developer experience can enhance the network’s resilience, decentralization, and sustainable growth, while aligning with Cardano’s long-term strategic goals. Furthermore, we consider the proposal well grounded from a governance and treasury responsibility perspective. It outlines clear mechanisms for transparency and accountability, including smart contract-based fund management, public reporting, financial auditing, the return of unused funds to the treasury, and restricted use of contingency funds solely for mitigating market volatility. - Yes4.2M ₳No rationale
- Abstain4M ₳Rationale
This proposal is well-structured from a technical execution and financial control perspective, but it fails to establish a credible, evaluable return on investment (ROI) thesis.
As a result, the proposal cannot be properly valued. I will Abstain.
⸻
- Strength: Technical and Operational Clarity
The proposal demonstrates competence in two areas:
a. Technical Definition
• Clear articulation of what is being built (Pebble, Gerolamo)
• Defined responsibilities and delivery structure
• Consideration of service-level expectationsb. Financial Controls
• Mechanisms to manage disbursement
• Attention to fraud mitigation and accountabilityThese are necessary conditions for funding—but not sufficient.
⸻
- Core Deficiency: Absence of ROI Framework
The proposal emphasizes what will be built and how funds will be controlled, but does not adequately address:
What measurable value will be created for the ecosystem, and how that value justifies the cost.
Key gaps:
• No quantified or even directional estimate of ecosystem impact
• No clear articulation of who the end users are
• No evidence of demand (committed builders, partners, or adopters)
• No framework to measure success post-deploymentThe result is that:
• The investment (“I”) is explicit
• The return (“R”) is undefined⸻
- Public Goods vs. Utility Validation
The proposal implicitly positions these tools as public-utility infrastructure.
That raises specific evaluation requirements:
• Are these tools actually needed?
• What friction do they remove in the developer or user workflow?
• How many projects are currently blocked or constrained by the absence of these tools?
• Are there credible teams prepared to build on top of them?None of these questions are answered in a way that allows independent validation.
Without this, the “public good” framing becomes non-falsifiable—it cannot be tested, challenged, or benchmarked.
⸻
- Pricing Without Value Anchoring
The proposal includes a substantial funding request.
However:
• There is no benchmark against comparable tooling efforts
• No linkage between cost and expected ecosystem impact
• No scenario analysis (e.g., low / base / high adoption cases)This makes it impossible to determine whether the price is:
• Efficient
• Reasonable
• ExcessiveValuation requires both sides of the equation. Here, only cost is specified.
⸻
- Decision Logic
I am not voting “No” because:
• The proposal does not demonstrate that the investment is negative EV
• The technical work may have meritHowever, I cannot vote “Yes” because:
• The proposal does not demonstrate that the investment is positive EV
• The return cannot be independently assessedTherefore, the only logically consistent position is:
Abstain due to insufficient information to evaluate ROI.
⸻
- What Would Be Required for a “Yes”
A revised proposal would need to include:
• A clear ROI thesis (even if probabilistic)
• Defined target users and use cases
• Evidence of demand or committed adoption
• Measurable success metrics tied to ecosystem impact
• At least a directional value model (e.g., developer growth, transaction volume, TVL impact)⸻
Conclusion
This proposal meets baseline standards for execution and control, but fails at the level that matters most for Treasury allocation: value creation clarity.
Until the return case is made explicit and testable, capital allocation cannot be justified.
- No4M ₳No rationale
- Yes3.5M ₳Rationale
yes
- Yes3.5M ₳No rationale
- Yes3.1M ₳No rationale
- YesChanged3M ₳Rationale
I originally voted no on this proposal only due to the low cost of ADA and the need to prioritize spending, however as it is now clear that IOG intends to raid the treasury every year for funding, alternative nodes are a top priority.
Without node diversity and a seriously reduced dependence on IOG, IOG will continue to hold the network and treasury hostage.
I therefore see this spending as excellent value and I hope that Pebble + Gerolamo get funded!
Earlier votes
No5mo agoSuperseded
While alternative nodes are important, given current market conditions for Cardano, I have to say no at this time. Spending needs to be on essentials only right now, and we already have two alternate nodes that are now being funded (and I only said yes to one of them myself).
When the value of ADA is higher ($1 or more), I'd be happy to vote yes for this proposal.
- NoChanged2.8M ₳History
Earlier votes
Yes5mo agoSuperseded
- Yes2.8M ₳No rationale
- Yes2.7M ₳No rationale
- No2.7M ₳No rationale
- YesChanged2.7M ₳Rationale
After careful consideration, I will be voting YES for this proposal.
There are many things I would of liked to see changed but ultimately the need to fund community led initiatives outweighs my concerns.
Earlier votes
Abstain5mo agoSuperseded
- Yes2.7M ₳Rationale
本提案は約10FTE（フルタイム換算人員）による中規模開発であり、Gerolamo（軽量ノード）、Pebble（新言語）、および既存ツール保守の3本柱から構成されています。中でもGerolamoは「誰でもノードになれる」環境を実現し、dAppやウォレットの中央依存を低減する重要な基盤技術です。これによりネットワークの分散性と耐障害性が向上し、Cardanoの理念に直接貢献します。また、この変化はSPOの役割を奪うものではなく、「ブロック生成という本質への純化」を促すものであり、長期的には信頼性と運用力に基づく健全な競争を生むと評価します。Pebbleについては採用不確実性はあるものの、TypeScript系開発者の参入を促す可能性があり、言語の適切な分散と開発者基盤拡大に寄与する点を評価します。以上より、本提案はリスクを伴いつつも中長期的価値が高く、強く支持します。
This proposal represents a mid-sized effort (~10 FTE) covering Gerolamo (light node), Pebble (new language), and tooling maintenance. Gerolamo is particularly important, as it enables a “node-for-everyone” model, reducing reliance on centralized infrastructure and strengthening decentralization and resilience. This does not weaken SPOs, but rather refines their role toward reliable block production and professional operation.
Pebble carries adoption uncertainty, but it has potential to attract TypeScript developers and support a healthy diversification of programming languages in the ecosystem.
Overall, while there are risks, the long-term strategic value is significant. I strongly support this proposal.
- Yes2.5M ₳No rationale
- Yes2.5M ₳Rationale
This helps realize our previous vision for light nodes - the browser is the easiest entry point. I think this is a valuable add.
- Yes2.2M ₳No rationale
- Yes2.2M ₳Rationale
I support node diversity. The reward is the mitigation of risk and benefits the ecosystem
- Yes2.1M ₳No rationale
- No2.1M ₳Rationale
NO — I support the strategic value of HLabs’ work on Gerolamo, Pebble and TypeScript ecosystem maintenance, and I believe these workstreams could materially improve Cardano’s decentralization, developer experience and infrastructure resilience. However, this Treasury Withdrawal does not clearly satisfy Article II, Section 7(4) of the current Cardano Constitution, which requires an allocation of ADA for periodic independent audits and oversight metrics. The proposed escrow and oversight board are strong safeguards, but they do not clearly replace the need for an explicit audit/oversight allocation in the funding request itself. Given the size of the request and the importance of maintaining clean Treasury standards, I am voting NO on this version while encouraging HLabs to resubmit with the constitutional gap addressed and clearer budget separation.
- Yes2M ₳Rationale
Don't mind me, I'm just collecting my voting reward at https://voting-rewards.harmoniclabs.tech/
- Yes1.9M ₳No rationale
- Abstain1.8M ₳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.
- Abstain1.6M ₳No rationale
- Yes1.6M ₳No rationale
- 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.