Pebble + Gerolamo - HLabs 2026 Budget

{
  "_meta": {
    "schema_version": "1.2.0",
    "ingested_at": "2026-06-02",
    "source": "Koios TreasuryWithdrawal",
    "proposal_id": "gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv",
    "title": "Pebble + Gerolamo - HLabs 2026 Budget",
    "proposer": "Unknown",
    "requested_budget_ada": 8035714,
    "summary": "\nHarmonic Laboratories (HLabs for short) is an R&D firm born and focused solely on the Cardano ecosystem.\n\nHarmonic Laboratories supports and maintains a considerable portion of the TypeScript tooling for the Cardano ecosystem, which the majority of Cardano developers use, either directly, or indirectly via other libraries that depend on code written and maintained by HLabs.\n\nThe mission of HLabs is for true decentralization to become the baseline of application development, not only a nice-to-have feature.\n\n### Duration & Milestones\n\nThis proposal spans over **12 months**, throughout which there will be several deliveries and demos. Amongst the key deliveries, we note:\n\n- maintenance for an upcoming hard fork;\n- a production-ready light node ([Gerolamo](https://github.com/HarmonicLabs/gerolamo));\n- a production-ready, imperative and efficient, programming language for smart contracts ([pebble](https://github.com/HarmonicLabs/pebble)).\n\n### Total Budget Ask\n\nThe estimated USD budget is of **`$2,250,000`** (or **`₳6,428,571`**) + 25% in refundable contingency (**`₳1,607,143`**); for a total ask of **`8,035,714 ADA`**."
  },
  "id": "onchain-pebble-gerolamo-hlabs-2026-budget",
  "identity": {
    "title": "Pebble + Gerolamo - HLabs 2026 Budget",
    "proposer_name": "Unknown"
  },
  "source": {
    "channels": [
      "onchain"
    ],
    "hydra_id": "gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv",
    "onchain_action_id": "gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv",
    "onchain_tx_hash": "b11527fbcdc9d41e8f497de64a029a18673a5eefc413718459046f0b7a1a6656"
  },
  "classification": {
    "official_pillar_primary": [],
    "official_pillar_secondary": [],
    "working_category_suggestion": null,
    "tags": []
  },
  "ask": {
    "ada_amount": 8035714,
    "currency_basis": "ada_flat",
    "raw_ask_text": "8,035,714 ADA TreasuryWithdrawal on-chain."
  },
  "lifecycle": {
    "pipeline_state": "rejected",
    "proposed_epoch": 621,
    "expiration_epoch": 628,
    "ratified_epoch": null,
    "enacted_epoch": null,
    "dropped_epoch": 629,
    "expired_epoch": 628
  },
  "links": {
    "adastat_url": "https://adastat.net/governances/gov_action1ky2j077de82par6f0hny5q56rpnn5hh0csfhrpzeq3hsk7s6vetqquz3scv",
    "meta_url": "ipfs://QmNuDfoojLyBNqk7qEXjd4UvZUKRX5aALjRUydrrr1pxWb",
    "other": [
      "https://github.com/HarmonicLabs/gerolamo",
      "https://github.com/HarmonicLabs/pebble",
      "https://product.cardano.intersectmbo.org/vision/strategy-2030/",
      "https://github.com/SundaeSwap-finance/treasury-contracts",
      "https://gateway.pinata.cloud/ipfs/QmZVw82XNXNsgGmBj39R26Mx7jgzWaNjSw4A7JM9Erye9c"
    ]
  },
  "content": {
    "abstract": "\nHarmonic Laboratories (HLabs for short) is an R&D firm born and focused solely on the Cardano ecosystem.\n\nHarmonic Laboratories supports and maintains a considerable portion of the TypeScript tooling for the Cardano ecosystem, which the majority of Cardano developers use, either directly, or indirectly via other libraries that depend on code written and maintained by HLabs.\n\nThe mission of HLabs is for true decentralization to become the baseline of application development, not only a nice-to-have feature.\n\n### Duration & Milestones\n\nThis proposal spans over **12 months**, throughout which there will be several deliveries and demos. Amongst the key deliveries, we note:\n\n- maintenance for an upcoming hard fork;\n- a production-ready light node ([Gerolamo](https://github.com/HarmonicLabs/gerolamo));\n- a production-ready, imperative and efficient, programming language for smart contracts ([pebble](https://github.com/HarmonicLabs/pebble)).\n\n### Total Budget Ask\n\nThe estimated USD budget is of **`$2,250,000`** (or **`₳6,428,571`**) + 25% in refundable contingency (**`₳1,607,143`**); for a total ask of **`8,035,714 ADA`**.",
    "rationale": "\n### Budget Breakdown\n\nThe full budget breakdown is given below.\n\nFor a fair valuation of the proposal, we will follow a similar process to what is used in the Amaru proposal, which we believe is setting a good standard in terms of Treasury budget proposals, and we will estimate the scopes of this proposal in _FTE_ (Full-Time Equivalent), which we will consider to equal a figure of `$225k` yearly rate.\n\nWe use a conversion rate of `0.35` ADA [`₳`] per USD [`$`].\n\n#### Complete View\n\n| Scope                                                     | Estimated (FTEs) | Project Total ($)  |\n| :---                                                      | ---:             | ---:               |\n| Gerolamo (TypeScript Cardano node)                        | 5                | `$1,125,000`       |\n| Pebble (programming language + dApp development tools)    | 3.5              | `$787,500`         |\n| Hard-fork maintenance                                     | 1.5              | `$337,500`         |\n|                                                           |                  |                    |\n| **Total**                                                 | **10 FTEs**      | `$2,250,000`       |\n\n#### Cost Rationale\n\nThe total ask for the project is `10 FTEs`.\n\nFTEs are being valued at an annual rate of `$225k`.\n\nFurthermore, we are aware of our assumption/optimism bias (our forecast is subject to underestimating complexity, overlooking challenges, and undervaluing the time and cost required to deliver, as well as our biased expectation of market movements). We therefore add an extra 25% contingency buffer, learning by our past mistakes.\n\nThis leaves us with the following total: `(10 x $225k) x 1.25 = $2,812,500`\n\nFinally, using a conversion rate of `0.35` ADA per USD, we formulate a budget ask of **`₳8,035,714`**. A [complete breakdown of this budget](#budget-detailed-view) is available below.\n\n### Milestones\n\nThis proposal spans Q2 2026 through Q1 2027, with milestones organized by quarter.\n\n#### Q2 2026 (Apr–Jun): Hard Fork Readiness & Foundations\n\n- Hard-fork maintenance: all TypeScript libraries updated for the upcoming hard fork\n- Gerolamo: improve storage and networking for browser environments;\n- Pebble: complete the type system; support for upcoming hard fork changes\n\n**Completion evidence:**\n\n- All relevant libraries maintained by HLabs support the Hardfork\n- Gerolamo syncs to tip on public test network\n- Multiple (≥3) pebble contracts of various complexity compiled end-to-end to valid on-chain code\n\n#### Q3 2026 (Jul–Sep): Core Delivery\n\n- Gerolamo: initial server-side relay capable release\n- Pebble: additional key language features, such as namespaces, tests and more comprehensive standard library\n\n**Completion evidence:**\n\n- Gerolamo server-side relay syncs and follows chain tip on public test network\n- Gerolamo relay published as installable release\n- New language features implemented (e.g. namespaces, tests, standard library)\n\n#### Q4 2026 (Oct–Nov): Integration & Browser Support\n\n- Gerolamo: browser light node capable of syncing and serving chain data; compatibility with existing Cardano tooling\n- Pebble: complete IDE integration & CLI + push for developers onboarding\n\n**Completion evidence:**\n\n- Browser demo syncing and querying chain data without a backend server\n- Standard Cardano tool (cardano-cli or cardano-db-sync) successfully connects to Gerolamo\n- Pebble IDE extension published with syntax highlighting and inline errors\n- Pebble CLI `build` command working on multiple projects\n\n#### Q1 2027 (Dec–Mar): Production Readiness, Documentation & Adoption\n\n- Gerolamo: production-ready browser light node; performance validation\n- Pebble: interactive console, documentation, tutorials\n\n**Completion evidence:**\n\n- Major browsers where Gerolamo runs as a light node (Chromium etc.)\n- Gerolamo browser node reaches a \"trustless\" tip, eventually over multiple sessions\n- Gerolamo maintains stable peer connections for ≥24 hours\n- Pebble language features documented with examples\n- End-to-end tutorials published\n\n### Budget Administration and Governance Oversight\n\n#### Smart Contract Escrow\n\nFunds are held and released through the SundaeLabs treasury-contracts (https://github.com/SundaeSwap-finance/treasury-contracts), a proven framework with two validators:\n\ntreasury.ak: Holds all ADA withdrawn from the Cardano treasury. Everything gets locked here when the governance action is enacted.\nvendor.ak: Manages milestone-based vesting for HLabs. Payment schedule, payout dates, release conditions.\nBoth contracts have been independently audited by TxPipe and MLabs and are in production use on mainnet.\n\n#### Independent Oversight Board\n\nAn independent oversight board provides third-party governance:\n\nSantiago Carmuega (TxPipe, Dolos)\nLucas Rosa (Aiken, Starstream, Midnight)\nChris Gianelloni (BlinkLabs, Dingo)\n\nBoard members don't have a stake in HLabs. They co-sign disbursements, review milestones, and can halt funding if we're not delivering.\n\n#### Permission Scheme\n\nThe actions allowed by the escrow contract are as follows:\n\nDisburse (periodic release): HLabs initiates + any 1 board member co-signs\n\nSweep early (return unused funds): HLabs + any 1 board member\n\nReorganize (adjust milestone schedule): HLabs only\n\nFund (initial vendor setup): Board majority\n\nPause milestone: Any 1 board member\n\nResume milestone: Board majority\n\nModify project: HLabs + board majority\n\nDay-to-day operations need one board signature. Structural changes need the full board. And any single member can hit pause if something looks off.\n\n#### Delegation Policy\n\nThe treasury contract enforces auto-abstain DRep delegation and no SPO delegation for all funds in escrow. Treasury funds don't influence governance votes or staking.\n\n#### Failsafe Sweep\n\nFunds left in the contract after expiration automatically sweep back to the Cardano treasury. Enforced at the contract level. Can't be overridden.\n\n### Constitutionality Checklist\n\nIn an effort to convince ourselves of the proposal's constitutionality, we thought relevant to include a checklist of the points we cover and for each, our interpretation of the Cardano Constitution.\n\n#### Purpose\n\n- [x] This proposal is for work intended to enhance the security, decentralization and long-term sustainability of Cardano.\n\n#### Article II, Section 6: Governance Action Standards\n\n- [x] We have submitted this proposal in a standardized, legible format, which includes a URL and hash of all documented off-chain content. We believe our rationale to be detailed and sufficient. The proposal contains a title, abstract, justification, and relevant supporting materials.\n\n#### Article II, Section 7: \"Treasury Withdrawals\" Action Standards\n\n- [x] **Section 7.1** — This proposal specifies the purpose of the withdrawal, the 12-month delivery period, the relevant costs and expenses, and the circumstances under which the withdrawal might be refunded to the Cardano Treasury.\n\n- [x] **Section 7.2** — A full retrospective of past funding and deliverables is available in the [2025 retrospective](https://gateway.pinata.cloud/ipfs/QmZVw82XNXNsgGmBj39R26Mx7jgzWaNjSw4A7JM9Erye9c) document.\n\n- [x] **Section 7.5** — This proposal designates administrators (the oversight board) responsible for monitoring fund usage and ensuring deliverables are achieved.\n\n- [x] **Section 7.6** — Treasury funds held by the administrator prior to disbursement will be kept in separate auditable accounts, delegated to the predefined `always_abstain` voting option.\n\n#### Treasury Withdrawal Guardrails\n\n- [x] **TREASURY-02a** — This withdrawal shall not exceed the Net Change Limit for the relevant period.\n\n- [x] **TREASURY-03a** — This withdrawal is denominated in ada.\n\n- [x] **TREASURY-04a** — We acknowledge this action requires greater than 50% of DRep active voting stake to be ratified.\n#### Cardano 2030 Strategic Alignment\n\n- [x] This proposal directly supports the Cardano 2030 Strategic Framework, contributing to the \"Alternative full node clients\" KPI (Pillar 1: Security & Resilience) and Developer Experience priorities (Pillar 2: Adoption & Utility).\n\n- [x] Measurable adoption indicators have been defined to provide visibility into ecosystem-level KPI contributions (TVL, monthly transactions, MAU).\n\n### Budget Detailed View\n\n#### Gerolamo (Typescript cardano node)\n\n[repo](https://github.com/HarmonicLabs/gerolamo)\n\n| Main Objective                                  |\n| ---                                             |\n| production-ready light node for dApps & wallets |\n\nGerolamo is a TypeScript implementation of the Cardano node designed for:\n- **Browser compatibility**: Serving as a base for nodes running in browsers\n- **Extensibility**: Being the base for purpose-specific nodes (light nodes, UTxO-only nodes, chain indexers)\n\n##### Full Ledger Rules Coverage\n\n###### Goal\n\nImplement complete ledger validation rules to enable Gerolamo to fully validate blocks and transactions according to the Cardano protocol specifications.\n\n###### Key Results\n\n- Full ledger state management using LMDB (or IndexedDB for browsers) for performance improvements.\n- Consensus implementation (Praos) with chain selection and rollback handling\n- Volatile DB for managing chain forks\n- Block and transaction validation covering all eras\n\n###### Estimated Effort\n\n2.5 FTEs\n\n##### Node APIs\n\n###### Goal\n\nProvide comprehensive APIs for dApp developers and infrastructure operators to interact with the Cardano network through Gerolamo.\n\n###### Key Results\n\n- UTxO RPC endpoints for efficient UTxO queries\n- Local socket support for node-to-client protocols (cardano-db-sync, cardano-cli compatibility)\n- Browser API for dApps to use\n\n###### Estimated Effort\n\n2 FTEs\n\n##### Plutus Machine Improvements\n\n###### Goal\n\nContinuously improve the [plutus-machine](https://github.com/HarmonicLabs/plutus-machine) CEK interpreter for better performance and full conformance with the Plutus specification.\n\n###### Key Results\n\n- Performance optimizations for script evaluation\n- Budget tracking and cost model accuracy improvements\n- Sourcemap support for debugging\n\n###### Estimated Effort\n\n0.5 FTEs\n\n##### Gerolamo Summary\n\n- total resources estimated: `5 FTEs`\n\n##### Production Readiness Criteria\n\nGerolamo will be considered production-ready as a browser light node when it meets the following objective criteria:\n\n| Criterion              | Requirement                                                    | Verification Method     |\n| :--------------------- | :------------------------------------------------------------- | :---------------------- |\n| **Sync reliability**   | Successful sync from genesis to tip on mainnet                 | Continuous integration  |\n| **Sync performance**   | Initial sync ≤48 hours on commodity hardware (4 CPU, 16GB RAM) | Benchmark suite         |\n| **Peer connectivity**  | Stable connections with ≥15 peers for ≥24 hours                | Network validation      |\n| **Block propagation**  | Block relay latency within 2x of Haskell node baseline         | Comparative benchmarks  |\n| **Rollback handling**  | Successful recovery from rollbacks up to k=2160 blocks         | Adversarial scenarios   |\n\n##### Value Proposition vs. Other Node Implementations\n\n| Dimension            | Haskell Node               | Amaru                                    | Gerolamo                       | Gerolamo Benefit                                  |\n| :------------------- | :------------------------- | :--------------------------------------- | :----------------------------- | :------------------------------------------------ |\n| **Runtime**          | GHC runtime                | Native (Rust)                            | Bun/Node.js/Browser            | Runs anywhere JavaScript runs, including browsers |\n| **Browser support**  | No                         | Limited support planned (WASM, EOY 2026) | Yes (IndexedDB + WebWorkers)   | Production-ready browser support sooner           |\n| **Developer access** | Haskell expertise required | Rust expertise required                  | TypeScript/JavaScript          | Largest contributor pool (17M+ JS/TS developers)  |\n| **Extensibility**    | Cardano-specific           | Rust crates ecosystem                    | npm ecosystem integration      | Seamless integration with web/dApp tooling        |\n| **Use cases**        | Full block production      | Full block production                    | Browser light node, data node, relay | Complementary; JS/TS native browser capability    |\n\n> [!NOTE]\n>  Gerolamo is designed as a **complementary implementation** focused on browser light node and data-node use cases, not a replacement for block-producing nodes yet. Block production so far remains on the Haskell node.\n>\n> Getting to a point where the node can be considered seriously as a production-ready light node, functionality wise, should get us pretty close to a point where it can also be used for block production.\n>\n> however, enabling block production in a mainnet environment, would incur in a serious increase in the funds we would need to ask\n>\n> for the security audit alone, the amaru and blinklabs teams are asking an additional 500k USD, which we believe to be appropriate.\n>\n> additionally, if we were to include block production between the goal of this year, we'd also need to increase the estimated effort by *at least* 1 more FTE.\n>\n> should the condition allow the next year, block production will be strongly considered.\n>\n> given the current environment we decided it would be best to cut those efforts in order to contain the costs.\n\n#### Pebble (smart contract programming language)\n\n[repo](https://github.com/HarmonicLabs/pebble)\n\n| Main Objective                    |\n| ---                               |\n| production-ready language & tools |\n\nPebble is a simple, yet rock solid, functional language with an imperative bias, targeting UPLC (Untyped Plutus Core). It provides developers with an intuitive syntax while compiling to highly optimized on-chain code.\n\n##### Compiler Stability\n\n###### Goal\n\nAchieve production-grade compiler stability with optimized code generation.\n\n###### Key Results\n\n- Comprehensive type system with full type inference\n- Optimized UPLC code generation with minimal script sizes\n- Complete error reporting with actionable messages\n- Support for Plutus V4\n- Key language features: namespaces, built-in test support, comprehensive standard library\n- Documentation and tutorials for onboarding new developers\n\n###### Estimated Effort\n\n2 FTEs\n\n##### Developer Tooling\n\n###### Goal\n\nProvide a complete development experience for Pebble developers with IDE integration, debugging tools, and build system support.\n\n###### Key Results\n\n- **Language Server Protocol (LSP)** implementation:\n- Syntax highlighting\n- Auto-completion\n- Go-to-definition\n- Find references\n- Inline error reporting\n- Hover documentation\n- **Stable and reliable sourcemaps** for debugging compiled contracts\n- **CLI improvements**:\n- Build and watch modes\n- REPL for interactive development\n- **Blueprint generation** for contract metadata\n\n###### Estimated Effort\n\n1.5 FTEs\n\n##### Pebble Summary\n\n- total resources estimated: `3.5 FTEs`\n\n##### Differentiation from Aiken\n\nPebble and Aiken serve different developer profiles and are **complementary** within the Cardano ecosystem, not competitive.\n\n| Dimension              | Aiken                            | Pebble                                 | Implication                                           |\n| :--------------------- | :------------------------------- | :------------------------------------- | :---------------------------------------------------- |\n| **Paradigm**           | Functional-first (Rust-inspired) | Imperative-first (TypeScript-inspired) | Different mental models for different developers      |\n| **Target audience**    | Developers comfortable with FP   | Web2/EVM developers                    | Expands total addressable developer pool              |\n| **Syntax familiarity** | Rust, Gleam                      | TypeScript, JavaScript, Solidity       | Lower barrier for the 17M+ JS/TS developers globally  |\n| **Learning curve**     | Requires FP fundamentals         | Familiar imperative patterns           | Faster onboarding for majority of developers          |\n\n###### Why both matter\n\nCardano needs multiple on-ramps for developers:\n- Developers with Rust/Haskell/FP experience gravitate toward Aiken\n- Developers with JS/TS/Solidity experience will find Pebble more accessible\n- Both compile to optimized UPLC; the choice is about developer preference, not runtime performance\n\nBy funding Pebble, the Treasury expands Cardano's developer funnel without fragmenting it.\n\n#### Hard-fork maintenance\n\n| Main Objective                |\n| ---                           |\n| guarantee ecosystem stability |\n\n##### Upcoming Intra-Era Hard Fork\n\n###### Goal\n\nEnsure all HLabs TypeScript libraries are updated and fully compatible with the upcoming hard fork, including Plutus V4 changes and new protocol parameters.\n\n###### Key Results\n\nMaintenance of the affected repositories to support new protocol features:\n\n- **[cardano-ledger-ts](https://github.com/HarmonicLabs/cardano-ledger-ts)**: Collection of functions and classes defining the Cardano ledger data structures\n- **[ouroboros-miniprotocols-ts](https://github.com/HarmonicLabs/ouroboros-miniprotocols-ts)**: TypeScript implementation of the Ouroboros networking protocol\n- **[plutus-machine](https://github.com/HarmonicLabs/plutus-machine)**: CEK machine implementation for UPLC evaluation\n- **[uplc](https://github.com/HarmonicLabs/uplc)**: TypeScript/JavaScript representation of UPLC\n\n###### Estimated Effort\n\n1.5 FTE\n\n##### Hard-Fork Maintenance Summary\n\n- total resources estimated: `1.5 FTE`"
  },
  "metadata": {
    "open_source": "unknown",
    "has_prior_delivery": null,
    "duplicate_of_existing_solution": "unknown"
  },
  "treasury_return": {
    "has_return_clause": false,
    "mechanisms": [],
    "treasury_favourability": "unknown",
    "treasury_favourability_confidence": "low",
    "treasury_favourability_set_by": "ai"
  },
  "ecosystem_demand": {
    "evidence_level": "unknown",
    "evidence_level_confidence": "low",
    "evidence_level_set_by": "ai"
  },
  "incumbents": {
    "has_existing_solution": "unknown",
    "has_existing_solution_confidence": "low",
    "has_existing_solution_set_by": "ai"
  },
  "relationships": {
    "bundle_with": [],
    "supersedes": null,
    "competes_with": [],
    "depends_on": [],
    "notes": ""
  }
}