Pebble + Gerolamo - HLabs 2026 Budget
199 DReps voted · 87 with a rationale · 21 changed their vote
Open a row to read the rationale.
- Abstain584.2M ₳Rationale
Summary
Yoroi DRep votes ABSTAIN on the Harmonic Laboratories treasury withdrawal. This position is not a judgment on the team, but a considered view on necessity, sequencing, and responsible use of treasury resources.
Rationale
On the node implementation
Yoroi engaged directly with developers and engineers on the Gerolamo proposal, and the conversations we had surfaced genuine questions about whether TypeScript is the right foundation for a production-grade node. We hold this view with humility - we are open to hearing from others in the technical community who see it differently, and we do not consider the matter closed. What we can say is that, on the basis of those conversations, and with Amaru and Dingo already funded and progressing, we are not yet persuaded that a third alternative node represents the best use of treasury resources in this cycle.
On the smart contract language
Pebble is an ambitious undertaking, and we do not question the intent behind it. That said, our view is that the ecosystem does not require a new smart contract language at this point in time. Aiken has matured considerably and continues to gain adoption. At this point, we would rather see that momentum built upon than dispersed across parallel efforts.
A question of proportionality
At over 8 million ADA, the scale of this request warrants reconsideration. The Cardano 2030 roadmap targets two live alternative node clients, a benchmark already being worked toward. Committing this level of funding to efforts that are both experimental and largely covered by existing initiatives is difficult to support in the current cycle. We would encourage HLabs to revisit the scope and return with a revised cost that better reflects what is genuinely needed at this point in the roadmap.
Conclusion
Yoroi has considerable respect for HLabs and the work they have contributed to the Cardano ecosystem. Our decision to abstain is not a rejection of the team, instead it is a considered view on timing, scope, and proportionate use of treasury resources. We would welcome a resubmission with a revised cost, and we hope to be in a position to support a more targeted proposal from them in a future cycle.
- Yes435.8M ₳Rationale
I vote YES for "Pebble + Gerolamo - HLabs 2026 Budget".
I attempted to create a simple demo on the following site, and I can confirm that Pebble and Gerolamo offer a different value and development experience compared to existing nodes and languages. Through this work, I felt there is significant potential demand for these two products, so I decided to vote YES.
https://adatool.net/gerolamo
https://adatool.net/pebblePebble certainly has the potential to facilitate developer onboarding. With the increasing use of AI, the ability for humans to easily review the AI-generated artifacts seems valuable. Please check the Same Contract on the demo page.
Gerolamo certainly can function as a small node that runs within a browser, which could potentially reduce API dependencies that can be a single hurdle for wallets and DApps. The sense of security that comes from being a full node has led some ADA holders to continue buying more expensive PCs specifically for Daedalus and to reject all light wallets (even though many developers say this is an overreaction). Therefore, having a wallet that can be used with peace of mind is one of the most basic needs of ADA holders. There may also be a potential effect of expanding the use of DApps through onboarding Deadalue users to light wallets.
私は、「Pebble + Gerolamo - HLabs 2026 Budget」へYESを投票します。
次のサイトで簡易的なデモの作成を試みましたが、確かに、PebbleとGerolamoは既存のノードや言語とは異なる価値や開発体験をもたらすことが確認できます。私はこれらの作業を通じて、この2つのプロダクトには潜在的に大きな需要があるように感じられましたのでYESを投票することにしました。
https://adatool.net/gerolamo
https://adatool.net/pebblePebbleは確かに、開発者のオンボーディングを容易にする可能性があります。私自身も、管理している小さなadatoolサイトでこれを何かに活用することに興味を持ち始めています。AIの使用が高まる中で、そのAIの生成成果物を人間が簡単に確認しやすいことは価値があるように思えます。Same Contractをご確認ください。
Gerolamoは確かに、ブラウザ内で実行可能な小さなノードとして機能させることができ、これによりウォレット、DAppsの単一障害となり得るAPI依存を軽減することができる可能性があります。フルノードである安心感から、Daedalusのためにより高額なPCを買い換え続け、一切のライトウォレットを拒否するADAホルダーもある程度存在するように(それは心配しすぎただという開発者も多いにも関わらずです)、安心して利用できるウォレットであることはADAホルダーの最も基本的な需要の1つです。Deadalueユーザーのライトウォレットへのオンボーディングを通じたDAppsの利用拡大の潜在的な効果もあるかもしれません。
- YesRevoted332.2M ₳History
Earlier votes
Yes3mo agoSuperseded
- Abstain293M ₳Rationale
Summary
EMURGO as a DRep votes ABSTAIN on the treasury withdrawal titled "Pebble + Gerolamo - HLabs 2026 Budget", with rationale outlined below.
Rationale
EMURGO recognizes the technical strength of Harmonic Laboratories and appreciates their ongoing contributions to the Cardano TypeScript ecosystem. This position should not be interpreted as a reflection on the quality of their work or their role within the community.
From a technical perspective, while we recognise the merits of additional node implementations, both discussions with external technologists in the ecosystem and the internal technical team at EMURGO suggest there are reservations around the use of TypeScript as the foundation for a production node environment.
We remain open to hearing from experts who hold different views, and we do not consider this question settled. In the meantime, with Amaru and Dingo already funded and progressing, the case for committing treasury resources to a third alternative node at this stage is not yet clearly established.
On the matter of Pebble, we do not believe further development of a new smart contract language is critical to the ecosystem at this point. Aiken continues to serve developers well, and we see no clearly defined gap that would justify the additional investment in the current cycle.
Beyond the technical considerations, the scale of the funding request remains a concern. We would warmly welcome the team to resubmit with a revised cost that better reflects the scope of work proposed. For these reasons, EMURGO votes Abstain.
- Yes254.7M ₳No rationale
- Yes222.9M ₳Rationale
TL;DR: EDC votes YES on gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv;
We revised our vote on Dingo from NO to YES. Going forward, for node diversity, we will support the Haskell, Rust, Go, and TypeScript implementations.
Reasoning: If we introduce more than one node implementation, we need to add more than one additional implementation. Think of different node implementations as a multi-signature wallet controlled by two parties that do not trust each other. If one of the nodes introduces bugs or changes the ledger rules, whether intentionally or not, we do not want a 50/50 chain split. We want at least two honest and correct node implementations to prevent a situation similar to the one we had in November 2025.
We expect the maintenance cost to be significantly lower than the cost of implementing the different nodes now. Spend responsibly.
TL;DR: If you support node diversity, you need to choose at least two additional node implementations in addition to the Haskell one.
- No174.6M ₳Rationale
Keep in mind this review is in the context of the 2.25m ask
Pebble
I don't believe an alternative to Aiken that's 50% better will be difference maker in getting Cardano more adoption. Definitely any improvement to Plutus usability is nice and I've heard many good things about Pebble, I would rather fund somebody to try building a totally different approach to UTXO smart contracts that has some solid idea behind it. Especially because although Starstream development is going well and we haven't hit any issues, there's never a sure thing in software engineering so there's always a chance something goes wrong with Starstream (proof generation too slow, transactions too big, people don't like the devx, etc.). Instead of putting all the eggs in the Starstream basket, I'd be more comfortable if there was another alternative plan (even if multiple ways to achieve some end goal getting funded always leads to issues).
Realistically Plutus hasn't really gotten much adoption in the world, and I don't think an iterative improvement will be what gets a new wave of developers to come build on Cardano. It's not a new narrative. It's not a 10x unlock in new capabilities. It's meaningful work and true improvement, but I think Cardano needs some big new ideas. If you ask a lot of the large projects that tried to build on Cardano (either internally or externally), it's not that they weren't able to build because the language was too complicated or they were missing one feature or two. It's often times because they were missing big-ticket features that are fundamentally incompatible with the way Cardano is architectured today. yeah but it doesn't solve the fact events are missing (and basically impossible to properly add), the fact that ABIs are missing (and basically impossible to properly add), that data-heavy use-cases like L2s are infeasible, that privacy / crypto-heavy use-cases are basically blocked, that compute-heavy use-cases can't be atomic, that state channels are missing features to really deliver, that composition is so limited at the protocol level that most dApps live in isolation, etc. etc. etc.. These are the problems almost everybody runs into, and Pebble can make some iterative improvements on these, but almost all of them are fundamental problems at the ledger/plutus core level that Pebble cannot easily address.
For example, if the author is passionate about composability, I'd rather have a proposal where they go deep into what the UTXO could look like in relation to MPC/coSNARKs/FHE/related concepts and try and come up with what the UTXO model could look like in that lens. I think for sure there has got to be multiple ways you could rig the UTXO model to connect to these that gives you orders of magnitude more expressiveness in composability compared to what we have now. It can grow into an alternative to Starstream, or orthogonal to it. it's entirely possible the result of the investigation (just like was the case for Starstream) is that it requires a lot of new cryptography, a lot of hard work, and multiple ledger-level changes to make happen, but I think that's the kind of rethinking and new narrative that Cardano needs
Gerolamo
Although the project is meaningful and unique, for these kinds of these I always feel like we would end up with a better result (both for our ecosystem and the world) if you instead just put $1m into funding wasm development in general and leveraged the result of that (Wasm makes progress every year and I think a lot of people are sleeping on how much progress has been made, but there are still many areas that I think could make a big difference if improved where standards committees have already agreed and it's just missing an implementer).
For example, this is the kind of thing I'm talking about though
for example, if you need to model code that accesses the file system (often the case in typical nodes), the Wasm Component model allows for this through wasi-filesystem (https://github.com/WebAssembly/WASI/tree/main/proposals)
for threading (another common ask), the new Wasm Component 0.3 supports async and streams, which makes it very easy to implement a lot of concurrency systems (and compile many new kinds of languages into Wasm components). Additionally, with new standards like wasi-gfx, you can outsource certain computations to the user's GPU directly from Wasm which lowers a lot of cases people historically needed threads in Wasm (rendering UI or doing expensive computation)
There's a lot of work being done on Wasm components, but there are still a lot of specification blockers for big projects (ex: how does the Wasm GC proposal compose with the Wasm component system?), as well as implementation blocks (ex: Firefox said they want to implement Wasm Components in the browser natively, but no clear when they'll finish this work), but although there are a lot of work to be done on Wasm components, I think a lot of things are now within reach and could be accelerated over giving up and doing stuff in the JS layer (which historically was the go-to solution). By spending the money to instead make a node like Dingo is compatible with Wasm Components, we probably take on less engineering debt (no need to update Gerolamo every hardfork), and any work we need to do (probably not that much work) is beneficial to any project in the web that is built using wasm components (and increasing number of projects, including other Cardano efforts)
- Yes165.7M ₳No rationale
- No120.2M ₳Rationale
We highly value the Harmonic Laboratories team and believe the proposal makes a strong case for Pebble & tooling, but the combined proposal's costs and uncertain practical value of the Gerolamo browser node prevent our approval. We highly encourage a leaner withdrawal specifically for Pebble.
A PDF version of this rationale is also made available.
The Cardano Foundation recognizes Harmonic Laboratories (HLabs) as a dedicated and highly skilled team that has consistently delivered value to the Cardano ecosystem. However, after extensive review by our Governance Advisory Team and internal Subject Matter Experts, we are unable to support the entirety of this proposal.
Our decision is driven by the following factors:
Strong Support for Pebble & Maintenance: We see strategic value in Pebble. The roadmap for this workstream is plausible, realistic, and contains explicit features and targets. An imperative, TypeScript-inspired language that compiles to highly optimized UPLC is an ideal "gateway" to attract the millions of global Web2 developers to Cardano. We also view the ongoing hard-fork maintenance of critical TS libraries (
cardano-ledger-ts,plutus-machine) as essential public good infrastructure.Concerns Regarding Gerolamo (Browser Node): While the concept of a browser-based node is technically interesting, there is significant skepticism regarding its practical utility and user adoption. Furthermore, our technical reviewers found the milestones somewhat vague, with subtle, unclear differences among phases (e.g., "syncs to tip" vs. "server-side relay syncs" vs. "reaches a 'trustless' tip"). Most critically, the defined "production-readiness" criteria focus almost exclusively on syncing and connectivity. Syncing with public networks is simply not sufficient to constitute a production node; the criteria completely miss rigorous testing for correctness and strict conformance with other nodes.
Budget Efficiency & Retrospective Contradictions: The total ask of 10 FTEs (valued at $225,000 per FTE annually) appears high for the proposed scope. Our review of the team's 2025 retrospective indicates that much of Gerolamo is already "mostly done" and Pebble is essentially presented as a working product. Requesting a 10 FTE budget for what appears to be finishing touches and maintenance, while pricing the workstreams entirely separately despite likely being covered by the same small team, is something we believe merits further optimization or explanation, if the cost is otherwise justified.
Contingency Buffer: Adding a flat 25% contingency buffer on top of an already significant 10-FTE baseline effectively locks up an additional ~1.6 million ADA. We believe this buffer is larger than necessary for the proposed scope.
Recommendation for a Revised Proposal
We do not want to see the momentum behind Pebble stall. We strongly encourage HLabs to unbundle this proposal and submit a separate, highly focused Treasury Withdrawal exclusively for Pebble and the ongoing TypeScript tooling maintenance.
We commend HLabs for their ongoing commitment to the ecosystem, but we urge them to return with a leaner, unbundled proposal focused on the high-value developer onboarding tools.
NOTE on 'Internal Voting':
The fields constitutional and unconstitutional below reflect the CF governance teams' individual opinions whether they are for or against the proposal. Reason for this inconsistency is, that CIP-136 is at the moment only applicable to CC rationales, but we want to record the internal opinions of our DRep assessment transparently as well. - Yes92.2M ₳No rationale
- Yes91.5M ₳Rationale
As a DRep I decided to vote YES for the proposal: Pebble + Gerolamo - HLabs 2026 Budget
The proposal concerns the tooling, Gerolamo node and programming language for smart contracts named Pebble.
Gerolamo is a lightweight node that is designed with the goal of running in the browser and one day potentially also on mobile devices. This would allow developers to build light wallets that move towards more trust-minimized, on-chain security models.
Applications using a Gerolamo node could benefit from higher responsiveness and improved reliability, as they may become more independent of data from external servers.
If full ledger validation is implemented, such applications could theoretically reach a security level comparable to running a full node like Daedalus, allowing users to move closer to full sovereignty over their funds.
Although most users are probably not explicitly looking for maximum sovereignty, they can still benefit from improved responsiveness and reduced reliance on centralized infrastructure.
Gerolamo is primarily positioned as an alternative relay and data node implementation, contributing to client diversity and reducing reliance on a single codebase at the networking layer. It is not currently intended for block production, although future extensions could expand its capabilities.
The alternative programming language Pebble is a strong argument in support of the proposal.
Haskell (Plutus) and Aiken are primarily functional programming languages, while Pebble is designed to be more imperative and low-level in style, closer to paradigms commonly used in Web2 development.
Pebble code is compiled into Untyped Plutus Core, ensuring compatibility with the existing execution model.
Aiken is currently one of the most widely used programming languages in the ecosystem. However, it can still be relatively complex for developers who only have experience with imperative languages.
Building alternative programming languages is desirable for the ecosystem, as it can broaden developer participation and diversify the tooling landscape.
The tooling maintained by HLabs is another strong reason to support the proposal.
TypeScript libraries such as cardano-ledger-ts, ouroboros-miniprotocols-ts, and uplc form part of the foundational infrastructure used by a range of Cardano developer tools and applications, often as transitive dependencies.
While not always visible at the application layer, these libraries underpin SDKs, off-chain code, and experimentation in the TypeScript ecosystem.
Continued support for this tooling helps maintain continuity for developers and reduces the operational burden of adapting to protocol changes.
The proposal is also aligned with the Cardano Vision 2030, particularly in terms of its focus on measurable outcomes and ecosystem KPIs.
By supporting core infrastructure, developer tooling, and alternative implementations, it contributes to key metrics such as developer growth, network resilience, and client diversity. These are critical indicators of long-term ecosystem health and decentralization.
I would appreciate it if the proposal were split into three separate proposals, corresponding to the main work streams (Pebble, Gerolamo, and tooling). This would allow for more granular evaluation and clearer accountability for each component.
That said, I do not consider this a reason to reject the proposal. I understand that the team intends to continue working across all three areas in parallel, and bundling them may reflect practical considerations around coordination and delivery.
- Yes88.6M ₳Rationale
It plays an important role in building decentralized applications, and lightweight nodes are needed.
- Yes86M ₳Rationale
SIPO DRep votes YES on Pebble + Gerolamo - HLabs 2026 Budget.
SIPO supports this proposal as a coherent extension of its node-diversity doctrine and as a targeted public-good investment in Cardano's TypeScript layer. Having voted YES on Amaru (Rust) and Dingo (Go) on the basis that multi-client architecture is infrastructure insurance, SIPO now votes YES on HLabs — not because this funds a fourth block-producing implementation, but because it addresses three complementary needs that neither Amaru nor Dingo cover: (1) a browser-native light node that lets dApps and wallets escape centralized indexer dependency, (2) an imperative smart-contract language that opens Cardano to the 17M+ TypeScript/JavaScript developer pool, and (3) sustained maintenance of foundational TypeScript tooling that a significant portion of Cardano's developer ecosystem already depends on.
Why SIPO votes YES
Gerolamo is complementary, not redundant, to Amaru and Dingo. It is explicitly designed as a TypeScript light node for browsers, dApps, and wallets — not a block-producing node. This is structurally missing from Cardano today. Most dApps currently rely on centralized indexers or third-party APIs, reintroducing the trust assumptions decentralization is meant to eliminate. A production-ready browser node lets dApps verify UTxO states without external services, and lets light wallets offer Daedalus-level verification with light-wallet UX. SPOs can deploy Gerolamo as a relay alongside Haskell, adding codebase diversity at the relay layer. This is a different category of value from Amaru/Dingo's block-producing ambitions.
Pebble expands the developer funnel without fragmenting it. Aiken materially improved the Cardano smart-contract experience for developers with FP familiarity, and SIPO considers Aiken a central success. Pebble targets a different profile: engineers fluent in TypeScript/JavaScript/Solidity-style imperative syntax — the largest developer community in the world. The choice is not Aiken vs Pebble; it is Cardano having multiple legitimate on-ramps, all compiling to optimized UPLC. This directly supports Cardano 2030 Pillar 2 (A.3 Developer Experience — Education & migration).
Hard-fork tooling maintenance is non-optional public-good infrastructure. cardano-ledger-ts, ouroboros-miniprotocols-ts, plutus-machine, and uplc are load-bearing for a substantial share of Cardano's TypeScript ecosystem. When a hard fork changes protocol parameters, these libraries must be updated promptly, or downstream projects face breaking changes or silent correctness bugs. Funding 1.5 FTE for sustained maintenance is one of the highest-leverage line items in this proposal.
Governance structure matches the standard SIPO has already endorsed. Funds are held in SundaeLabs treasury-contracts — the same audited escrow Amaru and Dingo use, 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 direct technical credibility in Cardano infrastructure. Auto-abstain DRep delegation, no SPO delegation, failsafe sweep at contract expiration. Same standard SIPO has already approved twice.
Cardano 2030 alignment is concrete, not rhetorical. Maps directly to two formal 2030 KPIs (alternative full-node clients, monthly uptime via hard-fork maintenance) and Pillar 2 A.3. Measurable adoption indicators committed: Gerolamo (≥10 SPOs as relay, ≥3 browser-based wallet/dApp integrations in 12 months); Pebble (≥20 developers onboarded, 100% documentation, ≥3 e2e tutorials).
Expectations (YES with clear conditions)
SIPO's YES is conditional on delivery and treasury usage remaining strictly accountable:
- Monthly velocity transparency across Gerolamo, Pebble, and tooling-maintenance repositories
- Q2 hard-fork readiness as the first hard gate: all HLabs-maintained TypeScript libraries updated for the upcoming intra-era hard fork
- Gerolamo production-readiness criteria met with reproducible evidence (sync from genesis to tip on mainnet, initial sync ≤48h on commodity hardware, stable connections with ≥15 peers for ≥24h, block propagation within 2x of Haskell baseline, rollback recovery up to k=2160)
- Pebble adoption indicators reported with evidence (npm downloads, GitHub stars, Discord members, published tutorial URLs), not self-assessed claims
- Complementarity with Aiken maintained in practice: no adversarial tone or marketing, active interoperability collaboration where reasonable
- 25% contingency buffer as risk policy, not discretionary expansion: transparent accounting for any drawdown, unused funds swept to treasury at contract expiration
- Scope containment on Gerolamo block production: any future pivot must come as a separate governance action with its own audit plan and budget
- Quarterly reporting in a stable format with KPI continuity, comparable across quarters — same discipline SIPO asked of Amaru and Dingo
- Past delivery accountability: public closeout of past Catalyst-funded work alongside quarterly reporting
SIPO views this proposal as a logical extension of its node-diversity and public-good infrastructure doctrine. Gerolamo addresses a structural gap in Cardano's dApp and wallet architecture that neither Haskell Node, Amaru, nor Dingo is positioned to fill. Pebble opens an additional on-ramp complementing rather than replacing Aiken. Hard-fork tooling maintenance protects a layer already heavily used. SIPO's YES is not a vote of confidence in HLabs abstracted from deliverables — it is a vote that this specific scope, at this specific budget level, under this specific governance structure, is worth funding, subject to the expectations above being treated as binding operational commitments.
SIPO DRepとして、本提案「Pebble + Gerolamo - HLabs 2026 Budget」に賛成（YES）を投じます。
SIPOは本提案を、既に支持してきたノード多様性ドクトリンの自然な延長、およびCardano TypeScript層への公共財投資として支持します。Amaru（Rust）とDingo（Go）にYESを投じた論理の延長でHLabs提案にもYESを投じますが、これは「4つ目のブロック生成ノード」を資金提供するからではありません。AmaruもDingoもカバーしていない3つの相補的領域に投資するものだからです：(1) dApp/ウォレットが中央集権インデクサ依存から脱却できるブラウザネイティブ軽量ノード、(2) 1700万人超のTS/JS開発者プールをCardanoに開く命令型スマコン言語、(3) 既に大量に使われているCardano TypeScript基盤ライブラリ群の継続メンテナンス。
SIPOがYESと判断する理由
GerolamoはAmaru・Dingoと競合ではなく補完関係。明示的にブラウザ・dApp・ウォレット向けTypeScript軽量ノードとして設計され、ブロック生成ノードではありません。現状の大半のdAppは中央集権インデクサに依存し、分散化が排除すべきはずの信頼前提を再導入しています。プロダクション品質のブラウザノードがあれば、dAppは外部サービスに依存せずUTxO検証を行え、ライトウォレットは軽量UXのままDaedalus級の検証性を提供できます。SPOは既存Haskell構成と並列にリレーとして展開でき、リレー層のコードベース多様性にも寄与します。Amaru/Dingoのブロック生成志向とは異なるカテゴリの価値です。
Pebbleは開発者ファネルを拡大するが分断しない。AikenはRust/関数型慣れした開発者にとっての障壁を大きく下げた中心的成功事例です。Pebbleは異なる層、すなわちTS/JS/Solidity系の命令型構文に慣れたエンジニア（世界最大の開発者コミュニティ）を狙います。Aiken対Pebbleではなく、異なるバックグラウンドを持つ開発者への複数の正統な入口を持つことが本質です。両者とも最適化されたUPLCへコンパイルされます。Cardano 2030 Pillar 2（A.3 Developer Experience — Education & migration）と直接整合します。
ハードフォーク維持は選択可能ではない公共財。cardano-ledger-ts、ouroboros-miniprotocols-ts、plutus-machine、uplc は、Cardano TypeScript開発者エコシステムの相当部分にとって基盤となるライブラリ群です。ハードフォーク時に速やかに更新されなければ、下流プロジェクトはビルド破壊や静かな正しさのバグに直面します。1.5 FTEでこのリスクを回避できることは、本提案中最も高レバレッジな投資の一つです。
ガバナンス構造はSIPOが既に承認した標準と一致。資金はSundaeLabs treasury-contracts（Amaru/Dingoと同じ監査済みエスクロー、TxPipe/MLabs監査）に保持されます。独立監視ボード（Santiago Carmuega/TxPipe、Lucas Rosa/Aiken-Midnight、Chris Gianelloni/BlinkLabs-Dingo）はHLabsに持分を持たず、Cardanoインフラへの直接的な技術的信頼性があります。Auto-abstain DRep委任、SPO委任禁止、契約満了時failsafe sweep。SIPOが既に二度承認した標準と同一です。
Cardano 2030との整合は具体的。形式化された2つの2030 KPI（代替フルノードクライアント、ハードフォークメンテナンス経由の月次稼働率）およびPillar 2 A.3に直接マッピング。Gerolamo採用目標（12ヶ月で10以上のSPOリレー、3以上のブラウザ統合）とPebble目標（20以上の開発者、100%文書化、3以上のチュートリアル）が公開指標として提示されており、HLabs自己報告とは独立した評価基準が存在します。
SIPOの期待事項（YESには明確な条件が伴う）
SIPOのYESはデリバリーとTreasury運用が厳格に説明責任を伴うことを前提とし、以下を明示的な運用コミットメントとして期待します：
- 月次ベロシティの公開（Gerolamo・Pebble・ツーリング全リポジトリ）
- Q2ハードフォーク対応を最初のハードゲートとして。HLabs維持全TSライブラリがintra-era HFに対応
- Gerolamoプロダクションレディネス5基準の達成（mainnet同期、初期同期48h以内、15ピア24h、Haskellの2倍以内レイテンシ、k=2160ロールバック復旧）を再現可能な証跡とともに
- Pebble採用指標を証跡ベース（npmダウンロード、GitHubスター、Discord、公開URL）で四半期報告
- Aikenとの補完関係を実務で維持。対立的トーンを避け、相互運用性に協力
- 25%コンティンジェンシーはリスクポリシーであり裁量拡張予算ではない。使用時は透明会計、未使用分はfailsafe sweepでTreasury返却
- Gerolamoブロック生成へのスコープ封じ込め。将来のブロック生成は別個のガバナンスアクションとして提出
- 四半期報告の安定フォーマットとKPI連続性。Amaru・Dingoに求めたのと同じ規律
- 過去Catalyst資金案件の公開総括を本提案四半期報告と並行して実施
SIPOは本提案をノード多様性と公共財インフラに関するドクトリンの論理的延長として評価します。Gerolamoは、Haskell Node・Amaru・Dingoのいずれも埋められないdApp/ウォレットアーキテクチャの構造的ギャップに対応します。Pebbleは世界最大の開発者コミュニティに向けた追加入口を開き、Aikenを置き換えるのではなく補完します。ハードフォーク維持は既に大量に使われているエコシステム層を保護します。SIPOのYESは、HLabsという組織への抽象的信認票ではなく、本特定スコープ・特定予算・特定ガバナンス構造での資金提供の価値を認める判断票です。ただし上記期待事項が拘束力のある運用コミットメントとして扱われることを条件とします。
以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。
- No84.3M ₳Rationale
While acknowledging that this proposal is related to both Gerolamo and Pebble, I will echo the vote rationale I provided in connection with my vote on the Dingo proposal:
Node diversity is extremely important for the ecosystem. However, there are several different initiatives seeking funding this year for node development and this proposal should be compared alongside the others once we see them during the Intersect budget process. So, this is a "no" vote as to timing. This proposal should be considered alongside the others during the budget process when the entirety of the budget can be considered. This applies to the funding for Pebble as well.
- Yes76.8M ₳Rationale
An full-node in the browser is the dream of all cypherpunks, connecting every single user directly to the blockchain, no middleman, no APIs, no trusting your wallet provider, just direct participation in the network.
A PDF version of this rationale is also made available.
An full-node in the browser is the dream of all cypherpunks, connecting every single user directly to the blockchain, no middleman, no APIs, no trusting your wallet provider, just direct participation in the network. \n\nMost full-node wallets are desktop applications, which means you cannot use them to interact with decentralized (or centralized) applications on Cardano because the applications are all webapps.
- Yes75.2M ₳No rationale
- No74.5M ₳Rationale
I acknowledge the technical merit and long-term importance of this proposal. Enhancing node diversity through Gerolamo and expanding the developer funnel via Pebble are both aligned with Cardano’s future growth.
However, I question whether allocating approximately 8M ADA to this area is the right priority at this stage.
At present, the ecosystem would benefit more from initiatives that directly drive real-world usage—such as increasing DApp adoption, attracting users, and creating tangible demand—rather than further expanding the development infrastructure.
While I recognize this as a valuable long-term investment, I believe the timing is not appropriate. Given limited Treasury resources, priority should be placed on initiatives that more directly contribute to ecosystem usage and growth.
For these reasons, I vote NO.
本提案の技術的価値および長期的な必要性については理解しています。Gerolamoによるノード多様性の強化や、Pebbleによる開発者導線の拡張は、Cardanoの将来的な発展にとって重要な要素であると考えます。
しかしながら、現時点で約800万ADA規模の資金をこの領域に配分する優先順位には疑問があります。現在のエコシステムにおいては、開発基盤の拡充よりも、実際にDAppを利用するユーザーの増加や、実需の創出に直結する取り組みの方が優先度が高いと判断しています。
長期的には必要な投資であることは認めつつも、現段階ではタイミングが適切ではないと考え、本提案には反対票を投じます。
- Abstain73.1M ₳Rationale
I am voting ABSTAIN on the Harmonic Laboratories Treasury Withdrawal. I want to explicitly commend the HLabs team for their ongoing contributions to Cardano. I am a tremendous advocate for their passion, their undeniable technical talent, and their proven track record of executing for our ecosystem.
A PDF version of this rationale is also made available.
I am voting ABSTAIN on the Harmonic Laboratories Treasury Withdrawal. I want to explicitly commend the HLabs team for their ongoing contributions to Cardano. I am a tremendous advocate for their passion, their undeniable technical talent, and their proven track record of executing for our ecosystem.
While I see immense strategic value in this proposal, particularly the Pebble programming language which I would have strongly considered supporting in isolation at an appropriate valuation, the bundled nature of this request presents an insurmountable hurdle. In our current financial climate, I cannot justify a combined expenditure exceeding eight million ADA for this specific functionality. Furthermore, funding these expansive and parallel infrastructure projects today inevitably guarantees ongoing Treasury obligations for future maintenance costs. If this proposal were to fail, I would strongly encourage the team to consider unbundling this initiative in the future, as a standalone proposal focused purely on bringing Pebble to market would find a highly receptive audience.
Despite these strict fiscal reservations, my profound respect for this team dictates that I will not use my voting weight to actively block their initiative. I firmly believe HLabs brings exceptional value to our blockchain, and as a mark of that respect, I am formally stepping aside to allow the broader community to determine the ultimate fate of this governance action.
- Yes69.4M ₳No rationale
- Yes66M ₳Rationale
yes
- YesChanged62.7M ₳Rationale
Been pressured to vote yes.
Earlier votes
Abstain3mo agoSuperseded
- No53.8M ₳Rationale
Rationale:
Gerolamo: No Clear Demand for a Browser Light Node Today
A trust-minimized browser light node is conceptually appealing, but there is no evidence of meaningful demand for backend-free dApp architectures in the current Cardano ecosystem. Most dApps today rely on centralized APIs such as Blockfrost and Koios, and this setup is functioning without significant friction. Cardano's primary bottleneck is not infrastructure decentralization, it is the lack of users and dApps themselves.Gerolamo and Amaru: Redundant Scope
Node diversity is important for long-term resilience, and having multiple implementations is a valid goal. However, the Treasury is already funding Amaru, a Rust-based alternative node. While Gerolamo and Amaru differ in runtime and target use cases, the functional overlap around chain sync, ledger validation, and peer connectivity is substantial. Given the current state of the ecosystem, investing heavily in parallel node implementations is not the highest priority. Limited Treasury resources should be directed toward areas with more immediate impact.Pebble: Unvalidated Demand for a Second Smart Contract Language
Aiken already serves as Cardano's primary smart contract language and is still in its early stages of adoption. The argument that Pebble will attract 17M+ JS/TS developers is a supply-side narrative with no demand-side validation. The claim that developers cannot onboard to Cardano because Aiken's learning curve is too steep does not hold up. Today, developers can rapidly learn new languages and frameworks through AI-assisted tools, making language familiarity a much smaller barrier than it used to be. The real barrier to developer adoption is not the language itself, it is whether building on Cardano leads to users and traction. The priority should be growing the ecosystem and demonstrating that Cardano is worth building on, not introducing a second smart contract language before the first has achieved meaningful penetration.
The ecosystem's highest priority today is creating an environment that attracts more liquidity and users. Node diversity matters, but Treasury resources are finite and must be allocated according to what the ecosystem needs most urgently. For these reasons, I vote against this proposal.
- Abstain50.5M ₳Rationale
With the treasury depleting quickly due to proposals being repriced around $0.25 ADA, I believe we need to be more cautious with spending. I’ve been vocal about the importance of building Cardano nodes and have already approved two other budget requests related to this area. I also think the amount requested per full-time equivalent (FTE), at $225k per year plus a 25% contingency, is too high. Therefore, I am abstaining from this vote.
- No50.4M ₳Rationale
I am voting No on this proposal. As a DRep, I evaluate all treasury withdrawal governance actions against my published voting framework, with a focus on the healthy development and long-term sustainability of the ecosystem.
This proposal bundles three distinct deliverables, each of which fails the framework's requirements. Gerolamo is a third node implementation. With Amaru and Dingo already funded, Gerolamo represents a third entry in the same category. My framework permits treasury funding for a second implementation on client diversity grounds, but the third and beyond belong in Tier 3, where market funding is appropriate. Furthermore, competing implementations should be selected through a competitive RFP process with a defined budget, not approved one by one without systematic comparison.
Pebble is a language-specific smart contract tool targeting TypeScript and JavaScript developers. Useful as it may be, this falls squarely into Tier 3. The market is the appropriate funding source for language-specific developer tooling. Hard-fork maintenance for TypeScript libraries does not meet the Tier 2 requirement of being language-agnostic and ecosystem-wide. It benefits only the TypeScript developer community, not the broader ecosystem.
Voting No to protect treasury discipline and market mechanisms for Tier 3 and beyond.
Reference: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem/
[Japanese version follows] 本提案に反対票を投じます。私はすべてのトレジャリー出金ガバナンスアクションを、公開済みの投票フレームワークに基づいて、エコシステムの健全な発展と持続可能性を重視して評価しています。本提案は3つの異なる成果物を束ねていますが、いずれもフレームワークの要件を満たしません。
GerolamoはAmaruとDingoがすでに予算確保済みである以上、3番目のノード実装です。私のフレームワークはクライアント多様性の観点から2番目の実装までトレジャリー資金を認めていますが、3番目以降はTier 3であり、市場資金が適切です。また、競合する実装は定められた予算のもとで競争的なRFPプロセスを通じて選定されるべきであり、体系的な比較なしに個別承認を積み重ねるべきではありません。 PebbleはTypeScript・JavaScript開発者を対象としたlanguage-specificなスマートコントラクトツールです。有用性はあるとしても、Tier 3に明確に該当します。language-specificな開発者ツールの資金調達は市場が担うべき領域です。 TypeScriptライブラリのハードフォーク対応メンテナンスは、Tier 2の要件である「language-agnosticかつエコシステム全体への貢献」を満たしません。恩恵を受けるのはTypeScript開発者コミュニティのみであり、エコシステム全体ではありません。トレジャリーの規律とTier 3以降における市場メカニズムを守るため、反対票を投じます。
参照: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/ - Yes50M ₳Rationale
Definitely Yes. Having multiple, diverse nodes from different teams is critically important for any decentralized system, including Cardano.
- No49.5M ₳No rationale
- Yes48.6M ₳No rationale
- Yes40.1M ₳Rationale
I believe this is good for Node Diversity even though I am wondering what will happen now that the ADA price is way below the conversion rate in the proposal.
- Yes38.1M ₳Rationale
Gerolamo and Pebble could significantly improve decentralization and onboarding if executed well. The direction is solid, with accountability built into the funding structure. I vote yes.
- YesChanged37.8M ₳History
Earlier votes
Abstain2mo agoSuperseded
- Yes34.6M ₳No rationale
- Yes34.3M ₳Rationale
Socious DRep votes YES on the HLabs 2026 budget proposal. This is a high-leverage infrastructure investment that directly advances three Cardano 2030 priorities the ecosystem has already endorsed: client diversity (Gerolamo as a TypeScript node), developer onboarding from Web2/EVM communities (Pebble as an imperative smart-contract language), and continuity of critical TypeScript tooling that a large share of Cardano dApps already depend on, directly or transitively. The proposal is well-scoped, transparently costed against an industry-comparable FTE benchmark already accepted by the community (the Amaru precedent), and constrained by best-in-class on-chain escrow and oversight controls.
- Yes33.5M ₳Rationale
Yes. Gerolamo (TypeScript alt node) advances client diversity KPI; Pebble lowers smart-contract barrier for TS/Web2 devs. Milestone-gated escrow with independent oversight board. Consistent with Amaru and Dingo Yes votes.
A PDF version of this rationale is also made available.
Voting Yes. This proposal scores strongly across the Cardano First framework:
- Decentralization: Gerolamo is a TypeScript alternative node implementation. Direct contribution to the Cardano 2030 client-diversity KPI. Same logic that drove my Yes on Amaru and (separately) Dingo.
- Adoption: Pebble lowers the smart-contract barrier for the massive TypeScript / Web2 developer pool. Onboarding new builders is the highest-leverage adoption lever we have.
- Economic Sustainability: SundaeSwap treasury-contracts escrow with milestone-gated disbursement, plus an independent oversight board (Santiago Carmuega, Lucas Rosa, Chris Gianelloni). Funds delegated to auto-abstain.
- Governance Transparency: Constitutionally compliant, public deliverables, monthly reporting cadence.
Strong on Decentralization and Adoption pillars with credible execution structure. Yes.
- No31.4M ₳Rationale
I am voting NO.
While I acknowledge that both Gerolamo and Pebble may provide value to the Cardano ecosystem, the highest‑priority needs are already being addressed. Amaru, as a Rust-based node implementation, meaningfully contributes to client diversity, and Aiken is already widely adopted as a practical and mature smart contract language. Given this existing foundation, the urgency and priority of this proposal appear lower.
I do not consider this work unnecessary; however, with limited Treasury resources, I believe funding should prioritize practical dApps and initiatives that drive real-world adoption and user-facing utility. - Yes30.7M ₳No rationale
- YesRevoted27.9M ₳Rationale
Gerolamo offers a unique value proposition over the existing Haskell node and the other alternate nodes in development (Dingo, Amaru, etc.). In my mind, the other nodes are geared toward SPOs, but Gerolamo will be a major benefit toward dApp and light wallet developers. As a native TypeScript node, along with the Pebble language, Gerolamo will be catering toward one of the most highly-adopted languages on the planet. With the capability to run a node in the browser, this opens up a lot of new use cases for developers that we simply don't have with other nodes or tooling. Coming together as a package deal with Pebble makes this even more attractive as a way to attract new developers, products, and use cases to the Cardano ecosystem. For these reasons I am enthusiastically voting YES on the Pebble + Gerolamo proposal.
Earlier votes
Yes3mo agoSuperseded
Gerolamo offers a unique value proposition over the existing Haskell node and the other alternate nodes in development (Dingo, Amaru, etc.). In my mind, the other nodes are geared toward SPOs, but Gerolamo will be a major benefit toward dApp and light wallet developers. As a native TypeScript node, along with the Pebble language, Gerolamo will be catering toward one of the most highly-adopted languages on the planet. With the capability to run a node in the browser, this opens up a lot of new use cases for developers that we simply don't have with other nodes or tooling. Coming together as a package deal with Pebble makes this even more attractive as a way to attract new developers, products, and use cases to the Cardano ecosystem. For these reasons I am enthusiastically voting YES on the Pebble + Gerolamo proposal.
- No27.9M ₳No rationale
- Yes27.5M ₳No rationale
- Yes26.1M ₳Rationale
In my mind this is a Enterprise Infrastructure Investment
Reduces platform risk → introduces node diversity and removes reliance on single infrastructure paths
Improves data integrity → enables direct, verifiable access to chain state without third-party dependencies
Accelerates development velocity → lowers onboarding friction with familiar tooling (TypeScript-style environment)
Protects integrations → ensures core libraries stay maintained through protocol upgrades
Prevents ecosystem fragmentation → avoids duplicated effort and incompatible tooling stacks
Supports scalable operations → enables more resilient, production-ready application architectures
Strengthens long-term ROI of treasury spend → funds foundational infrastructure rather than short-lived initiativesIn short-This proposal invests in core infrastructure that reduces operational risk, improves developer throughput, and makes Cardano a more reliable platform for building and scaling real-world applications.
- Yes25.3M ₳Rationale
I am voting YES to support the Pebble + Gerolamo - HLabs 2026 Budget proposal. While node diversity is important (see previous rationales), this node variation will equip the ecosystem with valuable latitude to serve a new range of user experiences.
- Yes23.5M ₳Rationale
Validation in the browser plus a focused contract language. Yes, please. I'm listed as a member of the oversight committee for this project, but will receive zero funds. I wouldn't do this if I didn't want to see Gerolamo successful.
- No22M ₳No rationale
- Yes21.5M ₳No rationale
- Yes21.5M ₳Rationale
I vote YES on the Treasury Withdrawal action titled “Pebble + Gerolamo - HLabs 2026 Budget” (b11527fbcdc9d41e8f497de64a029a18673a5eefc413718459046f0b7a1a6656#0).
I have taken my time with voting on this proposal in an attempt to understand its place among other recent alternative node proposals and the community sentiment for or against it. It is clear that there is currently strong community support for this proposal and it is now close to passing with just a few hours left until the end of the epoch.
While the Amaru and Dingo proposals position themselves as fully functional (block producer capable) alternate nodes to the current Haskell node, this proposal offers a different target market at this stage of its development. Instead, it positions itself as “a complementary implementation focused on browser light node and data-node use cases, not a replacement for block-producing nodes yet”. Providing access to the Cardano blockchain through another programming language, Typescript, in addition to the Rust and Go implementations offered by Amaru and Dingo respectively. Widening developer access to the Cardano blockchain and its data is vital to onboarding more developers to build a greater array of applications on top of Cardano.
No, we probably shouldn’t fund every single alternate programming language proposal that comes around but a Rust, Go and Typescript set forms quite a big trident to land a new wave of developers interested in Cardano, across web3 and web2 ecosystems. It’s time to finally put to bed the old “nobody uses Haskell” narrative. It gave us the secure base, now it’s time to build on it with a variety of toolkits and see what’s possible.
- Yes21.4M ₳No rationale
- Yes21.1M ₳No rationale
- Yes20.4M ₳No rationale
- Yes20.3M ₳No rationale
- Yes19.9M ₳Rationale
This is not yet another alternative client operating like all the other but both Pebble and Gerolamo do offer unique developer and user experiences which will help our ecosystem.
- Yes17.3M ₳Rationale
Pebble + Gerolamo - HLabs 2026 Budget