- HLabs는 대다수의 에이다 개발자가 직접 또는 간접적으로 사용하는 TypeScript 도구의 상당 부분을 지원하고 유지 관리함 .

- HLabs의 사명은 진정한 탈중앙화가 애플리케이션 개발의 선택 사항이 아닌 기본 원칙이 되도록 하는 것임 .

- 본 제안은 12개월 동안 진행되며 여러 결과물과 시연을 포함함 .

- 주요 결과물에는 다가오는 하드포크 유지 관리, 프로덕션 준비가 완료된 라이트 노드인 Gerolamo, 효율적인 스마트 계약 프로그래밍 언어인 Pebble이 포함됨 .

- 총 예산 요구액은 2.25M 달러(6.4M ₳)에 25%의 환불 가능한 예비비(1.6M ₳)를 더한 총 8.0M ₳임 .

- ■ 주석 *TypeScript: 자바스크립트 기반의 프로그래밍 언어 **Hard Fork: 블록체인 네트워크의 근본적인 프로토콜 업그레이드 ***Light Node: 전체 블록체인 데이터를 저장하지 않고 필수 정보만 확인하는 노드 ****Smart Contract: 블록체인에서 조건 충족 시 자동 실행되는 계약 프로그램

- Gerolamo는 dApp이 브라우저에서 직접 경량 노드를 실행하여 에이다 원장에 신뢰 최소화 방식으로 직접 접근하도록 지원했음 .

- 라이트 월렛 개발자는 Gerolamo를 통합하여 사용자에게 Daedalus 수준의 보안을 제공하면서도 낮은 오버헤드를 유지했음 .

- SPO는 Gerolamo를 추가 릴레이 노드로 활용하여 네트워크의 다양성을 확보하고 단일 구현체 버그로 인한 위험을 줄였음 .

- Pebble은 TypeScript 및 JavaScript 개발자에게 익숙한 구문을 제공하여 수 M 명의 개발자에게 에이다 개발의 문을 열어주었음 .

- Pebble은 명령형 구문을 사용함에도 불구하고 고도로 최적화된 UPLC로 컴파일되어 효율적인 온체인 코드를 생성했음 .

- HLabs의 툴링 유지보수는 Hard Fork 시 생태계 전반의 안정성을 보장하고 라이브러리 파편화 및 중단 위험을 제거했음 .

- 본 제안은 대안적 풀 노드 클라이언트 구현 및 개발자 이주 경로 확보 등 에이다 2030 전략 프레임워크의 핵심 KPI와 일치임 .

- Gerolamo는 12개월 내 10개 이상의 SPO 릴레이 운영과 3개 이상의 브라우저 기반 노드 통합을 목표로 설정했음 .

- Pebble은 20명 이상의 개발자 온보딩과 모든 언어 기능에 대한 문서화 및 튜토리얼 완성을 목표로 했음 .

- ■ 주석 *dApp: 탈중앙화 애플리케이션 **SPO: 스테이크 풀 운영자 ***UTxO: 미사용 트랜잭션 출력값 ****UPLC: Untyped Plutus Core *****LSP: Language Server Protocol ******Hard Fork: 블록체인 프로토콜의 대규모 업그레이드 *******SDK: 소프트웨어 개발 키트 ********KPI: 핵심 성과 지표 *********TypeScript: 자바스크립트의 상위 집합 프로그래밍 언어 **********EVM: 이더리움 가상 머신

- 총 예산은 10 FTE를 기준으로 산정되었으며, 인력당 연간 요율은 $225k로 설정했음 .

- 개발의 복잡성과 시장 변동성을 고려하여 25%의 예비비를 추가한 총 예산 규모는 $2.81M임 .

- 에이다 환율 0.35를 적용하여 최종적으로 ₳8.04M의 예산을 요청했음 .

- 주요 프로젝트인 Gerolamo는 브라우저 호환성을 갖춘 TypeScript 기반의 에이다 노드 구현체임 .

- Pebble은 JavaScript 및 TypeScript 개발자들에게 친숙한 문법을 제공하는 스마트 컨트랙트 프로그래밍 언어임 .

- 2026년 2분기부터 2027년 1분기까지 하드포크 준비, 핵심 기능 인도, 브라우저 지원, 상용화 준비의 마일스톤을 수행함 .

- 자금은 SundaeLabs의 스마트 컨트랙트 에스크로를 통해 관리되며, 독립적인 감독 위원회의 승인을 거쳐 지급됨 .

- 에스크로 계약은 투표권 행사나 SPO 스테이킹에 영향을 미치지 않도록 설계되었으며, 미사용 자금은 에이다 재무고로 자동 반환됨 .

- 본 제안은 에이다 헌법의 거버넌스 표준과 2030 전략적 프레임워크의 핵심 지표를 엄격히 준수함 .

- ■ 주석 *FTE: 전일종량제 (Full-Time Equivalent) **UPLC: Untyped Plutus Core (비정형 플루투스 코어) ***Hard Fork: 블록체인 프로토콜의 중대한 변경 사항 ****Escrow: 조건부 자금 보관 및 인출 시스템 *****DRep: 에이다 거버넌스의 위임 대표 ******SPO: 스테이크 풀 운영자 (Stake Pool Operator) *******LSP: 개발 도구 간 통신을 위한 언어 서버 프로토콜 ********CEK: 스크립트 실행을 위한 가상 머신 인터프리터 모델 *********IDE: 통합 개발 환경 (Integrated Development Environment) **********CLI: 명령 줄 인터페이스 (Command Line Interface)

Harmonic 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.

The mission of HLabs is for true decentralization to become the baseline of application development, not only a nice-to-have feature.

### Duration & Milestones

This proposal spans over **12 months**, throughout which there will be several deliveries and demos. Amongst the key deliveries, we note:

- maintenance for an upcoming hard fork;
- a production-ready light node ([Gerolamo](https://github.com/HarmonicLabs/gerolamo));
- a production-ready, imperative and efficient, programming language for smart contracts ([pebble](https://github.com/HarmonicLabs/pebble)).

### Total Budget Ask

The 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`**.

Gerolamo, Pebble, and ongoing tooling maintenance each serve distinct stakeholders while collectively strengthening Cardano's infrastructure, developer and user experience, and long-term sustainability.

#### Who will benefit from Gerolamo?

##### TL;DR

- dApps for trust-minimized applications
- wallets for daedalus-like security
- SPOs for relay nodes

##### dApps

Decentralized applications benefit immensely from trust-minimized access to blockchain data. Currently, most dApps rely on centralized indexers or third-party APIs to query the chain state, introducing points of failure and trust assumptions that undermine the decentralization ethos.

Gerolamo enables dApps to run their own lightweight nodes; even directly in the browser; providing direct, trustless access to the Cardano ledger.

This means dApps can verify UTxO states, validate transactions, and query chain data without relying on external services. The result is a more resilient, censorship-resistant application architecture that aligns with the core principles of decentralization.

##### Light wallets

Light wallets today must trust external servers to provide accurate chain data. This creates a security trade-off: users gain convenience but sacrifice the ability to independently verify their balances and transaction history.

With Gerolamo, wallet developers can integrate a lightweight node directly into their applications, offering users Daedalus-like security guarantees without the overhead of running a full node. Users can verify their own UTxOs, validate incoming transactions, and maintain full sovereignty over their funds, all while enjoying the user experience of a light wallet.

##### SPOs

Stake Pool Operators can use Gerolamo as an additional relay node alongside their existing infrastructure. Block production continues on their current setup, while Gerolamo relays add diversity and resilience to their pool.

A diverse node implementation landscape strengthens the network's resilience. By providing an alternative codebase for relays, Gerolamo reduces the risk of network-wide issues stemming from bugs in a single implementation; a critical factor for long-term network health and decentralization.

#### Who will benefit from Pebble?

##### TL;DR

Developers who seek an alternative to functional programming without sacrificing efficiency.

The language aims to be as similar as possible to TypeScript, which is a widely adopted language used in Web2, as well as similar to languages used in other, more mature ecosystems, such as Solidity on EVM chains.

##### Onboarding Web2 developers

One of Cardano's greatest challenges is the steep learning curve for smart contract development. Aiken, the most widely adopted smart contract language on Cardano, while a great improvement compared to haskell, still requires familiarity with functional programming paradigms, concepts unfamiliar to the vast majority of developers worldwide. This barrier significantly limits the pool of talent that can contribute to Cardano's dApp ecosystem.

Pebble bridges this gap by offering a syntax and development experience familiar to TypeScript and JavaScript developers, the largest programming communities in the world. By lowering the barrier to entry, Pebble opens Cardano development to millions of developers who would otherwise be deterred by the functional programming learning curve.

##### Efficient on-chain code

Despite its imperative syntax, Pebble compiles to highly optimized UPLC (Untyped Plutus Core). Developers don't have to choose between familiarity and efficiency: Pebble delivers both. The compiler performs aggressive optimizations to minimize execution costs, ensuring that contracts written in Pebble are competitive with hand-optimized Plutus code, making them a viable choice for production applications.

##### Professional development experience

Pebble's tooling, including a full Language Server Protocol (LSP) implementation, CLI with watch mode, and integrated debugging via sourcemaps, provides a development experience on par with mature ecosystems. Developers can enjoy auto-completion, inline error reporting, go-to-definition, and all the conveniences they expect from modern IDEs. This professional-grade tooling accelerates development cycles and reduces bugs, ultimately leading to higher-quality dApps on Cardano.

#### Who will benefit from the tooling maintenance?

##### TL;DR

The entire ecosystem can have the guarantee that there will always be up-to-date, easy to use, tools for them to use, without the fear of having to redesign entire applications because of missing support.

##### Ecosystem-wide stability

The TypeScript tooling maintained by HLabs underpins a significant portion of Cardano's developer ecosystem. Libraries like `cardano-ledger-ts`, `ouroboros-miniprotocols-ts`, and `uplc` are dependencies for numerous projects—both directly and transitively through other libraries. When a hard fork introduces protocol changes, these foundational libraries must be updated promptly, or downstream projects face breaking changes and potential security vulnerabilities.

By funding ongoing maintenance, the Treasury ensures that the TypeScript ecosystem remains synchronized with protocol upgrades. Developers can trust that their applications will continue to function across hard forks without emergency rewrites or extended downtime.

##### Reducing fragmentation risk

Without dedicated maintenance, critical libraries risk abandonment, a common fate in open-source ecosystems.

Abandoned dependencies force teams to either fork and maintain code themselves (duplicating effort across the ecosystem) or migrate to alternative solutions (fragmenting the developer community). Both outcomes are costly and destabilizing.

Sustained funding for HLabs tooling maintenance eliminates this risk, providing the ecosystem with a reliable foundation upon which developers can confidently build long-term projects.

### Cardano 2030 Alignment

This proposal directly supports the [Cardano 2030 Strategic Framework](https://product.cardano.intersectmbo.org/vision/strategy-2030/), contributing to core KPIs and strategic pillars as outlined below.

#### Alignment with Core KPIs

| KPI / Strategic Priority | 2030 Target / Goal | HLabs Contribution |
| :----------------------------------------- | :----------------------------- | :------------------------------------------------------------------------------ |
| **Alternative full node clients** | ≥2 spec-conformant | Gerolamo directly contributes as a second spec-conformant client implementation |
| **Monthly Uptime** | 99.98% | Hard-fork maintenance ensures ecosystem stability across protocol upgrades |
| **Developer migration pathways** (A.3) | "More developers can onboard" | Pebble provides EVM/TS developers a familiar syntax for Cardano smart contracts |

> **Note**: The first two rows are formal Cardano 2030 KPIs. The third row corresponds to Strategic Pillar A.3 (Developer Experience → Education & migration), which is an explicit 2030 priority but not yet a numeric KPI. TVL, monthly transactions, and MAU are ecosystem-level outcomes enabled by infrastructure investments like this proposal; we track adoption indicators (below) as leading metrics that contribute to these outcomes.

#### Alignment with Strategic Pillars

**Pillar 1: Infrastructure & Research Excellence**

- **I.2 Security & Resilience → Client Diversity**: Gerolamo is explicitly aligned with the 2030 goal of "supporting additional full-node and light-client implementations" to achieve "better decentralization" and "reduce single-client risk."

**Pillar 2: Adoption & Utility**

- **A.3 Developer Experience → Open-source incentives**: This proposal directly addresses the strategic priority to "incentivize the maintenance of core Cardano SDKs, frameworks, and infrastructure in line with open-source best practices" for a "sustainable builder ecosystem."
- **A.3 Developer Experience → Education & migration**: Pebble addresses the goal to "provide materials for EVM/account-based devs moving to Cardano/UTxO" by offering familiar imperative syntax, enabling "more developers to onboard."

#### Measurable Adoption Indicators

To provide visibility into how this proposal contributes to ecosystem-level outcomes, we commit to tracking and reporting the following adoption metrics:

##### Gerolamo Adoption Targets

| Metric | 12-Month Target | Measurement Method |
| :------------------------------- | :---------------- | :------------------------------------- |
| SPOs running Gerolamo as relay | ≥10 pools | Public registry + self-reporting |
| Browser-based node integrations | ≥3 wallets/dApps | dApps/wallets integrations |

##### Pebble Adoption Targets

| Metric | 12-Month Target | Measurement Method |
| :------------------------- | :---------------------- | :--------------------------------------------- |
| Developer onboarding | ≥20 developers | npm downloads, GitHub stars, Discord members |
| Documentation completeness | 100% coverage | All language features documented with examples |
| Tutorial completion | ≥3 e2e tutorials | Published guides covering common patterns |

The full budget breakdown is given below.

For 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.

We use a conversion rate of `0.35` ADA [`₳`] per USD [`$`].

#### Complete View

| Scope | Estimated (FTEs) | Project Total ($) |
| :--- | ---: | ---: |
| Gerolamo (TypeScript Cardano node) | 5 | `$1,125,000` |
| Pebble (programming language + dApp development tools) | 3.5 | `$787,500` |
| Hard-fork maintenance | 1.5 | `$337,500` |
| | | |
| **Total** | **10 FTEs** | `$2,250,000` |

#### Cost Rationale

The total ask for the project is `10 FTEs`.

FTEs are being valued at an annual rate of `$225k`.

Furthermore, 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.

This leaves us with the following total: `(10 x $225k) x 1.25 = $2,812,500`

Finally, 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.

### Milestones

This proposal spans Q2 2026 through Q1 2027, with milestones organized by quarter.

#### Q2 2026 (Apr–Jun): Hard Fork Readiness & Foundations

- Hard-fork maintenance: all TypeScript libraries updated for the upcoming hard fork
- Gerolamo: improve storage and networking for browser environments;
- Pebble: complete the type system; support for upcoming hard fork changes

**Completion evidence:**

- All relevant libraries maintained by HLabs support the Hardfork
- Gerolamo syncs to tip on public test network
- Multiple (≥3) pebble contracts of various complexity compiled end-to-end to valid on-chain code

#### Q3 2026 (Jul–Sep): Core Delivery

- Gerolamo: initial server-side relay capable release
- Pebble: additional key language features, such as namespaces, tests and more comprehensive standard library

**Completion evidence:**

- Gerolamo server-side relay syncs and follows chain tip on public test network
- Gerolamo relay published as installable release
- New language features implemented (e.g. namespaces, tests, standard library)

#### Q4 2026 (Oct–Nov): Integration & Browser Support

- Gerolamo: browser light node capable of syncing and serving chain data; compatibility with existing Cardano tooling
- Pebble: complete IDE integration & CLI + push for developers onboarding

**Completion evidence:**

- Browser demo syncing and querying chain data without a backend server
- Standard Cardano tool (cardano-cli or cardano-db-sync) successfully connects to Gerolamo
- Pebble IDE extension published with syntax highlighting and inline errors
- Pebble CLI `build` command working on multiple projects

#### Q1 2027 (Dec–Mar): Production Readiness, Documentation & Adoption

- Gerolamo: production-ready browser light node; performance validation
- Pebble: interactive console, documentation, tutorials

**Completion evidence:**

- Major browsers where Gerolamo runs as a light node (Chromium etc.)
- Gerolamo browser node reaches a "trustless" tip, eventually over multiple sessions
- Gerolamo maintains stable peer connections for ≥24 hours
- Pebble language features documented with examples
- End-to-end tutorials published

### Budget Administration and Governance Oversight

#### Smart Contract Escrow

Funds are held and released through the SundaeLabs treasury-contracts (https://github.com/SundaeSwap-finance/treasury-contracts), a proven framework with two validators:

treasury.ak: Holds all ADA withdrawn from the Cardano treasury. Everything gets locked here when the governance action is enacted.
vendor.ak: Manages milestone-based vesting for HLabs. Payment schedule, payout dates, release conditions.
Both contracts have been independently audited by TxPipe and MLabs and are in production use on mainnet.

#### Independent Oversight Board

An independent oversight board provides third-party governance:

Santiago Carmuega (TxPipe, Dolos)
Lucas Rosa (Aiken, Starstream, Midnight)
Chris Gianelloni (BlinkLabs, Dingo)

Board members don't have a stake in HLabs. They co-sign disbursements, review milestones, and can halt funding if we're not delivering.

#### Permission Scheme

The actions allowed by the escrow contract are as follows:

Disburse (periodic release): HLabs initiates + any 1 board member co-signs

Sweep early (return unused funds): HLabs + any 1 board member

Reorganize (adjust milestone schedule): HLabs only

Fund (initial vendor setup): Board majority

Pause milestone: Any 1 board member

Resume milestone: Board majority

Modify project: HLabs + board majority

Day-to-day operations need one board signature. Structural changes need the full board. And any single member can hit pause if something looks off.

#### Delegation Policy

The 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.

#### Failsafe Sweep

Funds left in the contract after expiration automatically sweep back to the Cardano treasury. Enforced at the contract level. Can't be overridden.

### Constitutionality Checklist

In 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.

#### Purpose

- [x] This proposal is for work intended to enhance the security, decentralization and long-term sustainability of Cardano.

#### Article II, Section 6: Governance Action Standards

- [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.

#### Article II, Section 7: "Treasury Withdrawals" Action Standards

- [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.

- [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.

- [x] **Section 7.5** — This proposal designates administrators (the oversight board) responsible for monitoring fund usage and ensuring deliverables are achieved.

- [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.

#### Treasury Withdrawal Guardrails

- [x] **TREASURY-02a** — This withdrawal shall not exceed the Net Change Limit for the relevant period.

- [x] **TREASURY-03a** — This withdrawal is denominated in ada.

- [x] **TREASURY-04a** — We acknowledge this action requires greater than 50% of DRep active voting stake to be ratified.
#### Cardano 2030 Strategic Alignment

- [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).

- [x] Measurable adoption indicators have been defined to provide visibility into ecosystem-level KPI contributions (TVL, monthly transactions, MAU).

### Budget Detailed View

#### Gerolamo (Typescript cardano node)

[repo](https://github.com/HarmonicLabs/gerolamo)

| Main Objective |
| --- |
| production-ready light node for dApps & wallets |

Gerolamo is a TypeScript implementation of the Cardano node designed for:
- **Browser compatibility**: Serving as a base for nodes running in browsers
- **Extensibility**: Being the base for purpose-specific nodes (light nodes, UTxO-only nodes, chain indexers)

##### Full Ledger Rules Coverage

###### Goal

Implement complete ledger validation rules to enable Gerolamo to fully validate blocks and transactions according to the Cardano protocol specifications.

###### Key Results

- Full ledger state management using LMDB (or IndexedDB for browsers) for performance improvements.
- Consensus implementation (Praos) with chain selection and rollback handling
- Volatile DB for managing chain forks
- Block and transaction validation covering all eras

###### Estimated Effort

2.5 FTEs

##### Node APIs

###### Goal

Provide comprehensive APIs for dApp developers and infrastructure operators to interact with the Cardano network through Gerolamo.

###### Key Results

- UTxO RPC endpoints for efficient UTxO queries
- Local socket support for node-to-client protocols (cardano-db-sync, cardano-cli compatibility)
- Browser API for dApps to use

###### Estimated Effort

2 FTEs

##### Plutus Machine Improvements

###### Goal

Continuously improve the [plutus-machine](https://github.com/HarmonicLabs/plutus-machine) CEK interpreter for better performance and full conformance with the Plutus specification.

###### Key Results

- Performance optimizations for script evaluation
- Budget tracking and cost model accuracy improvements
- Sourcemap support for debugging

###### Estimated Effort

0.5 FTEs

##### Gerolamo Summary

- total resources estimated: `5 FTEs`

##### Production Readiness Criteria

Gerolamo will be considered production-ready as a browser light node when it meets the following objective criteria:

| Criterion | Requirement | Verification Method |
| :--------------------- | :------------------------------------------------------------- | :---------------------- |
| **Sync reliability** | Successful sync from genesis to tip on mainnet | Continuous integration |
| **Sync performance** | Initial sync ≤48 hours on commodity hardware (4 CPU, 16GB RAM) | Benchmark suite |
| **Peer connectivity** | Stable connections with ≥15 peers for ≥24 hours | Network validation |
| **Block propagation** | Block relay latency within 2x of Haskell node baseline | Comparative benchmarks |
| **Rollback handling** | Successful recovery from rollbacks up to k=2160 blocks | Adversarial scenarios |

##### Value Proposition vs. Other Node Implementations

| Dimension | Haskell Node | Amaru | Gerolamo | Gerolamo Benefit |
| :------------------- | :------------------------- | :--------------------------------------- | :----------------------------- | :------------------------------------------------ |
| **Runtime** | GHC runtime | Native (Rust) | Bun/Node.js/Browser | Runs anywhere JavaScript runs, including browsers |
| **Browser support** | No | Limited support planned (WASM, EOY 2026) | Yes (IndexedDB + WebWorkers) | Production-ready browser support sooner |
| **Developer access** | Haskell expertise required | Rust expertise required | TypeScript/JavaScript | Largest contributor pool (17M+ JS/TS developers) |
| **Extensibility** | Cardano-specific | Rust crates ecosystem | npm ecosystem integration | Seamless integration with web/dApp tooling |
| **Use cases** | Full block production | Full block production | Browser light node, data node, relay | Complementary; JS/TS native browser capability |

> [!NOTE]
> 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.
>
> 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.
>
> however, enabling block production in a mainnet environment, would incur in a serious increase in the funds we would need to ask
>
> for the security audit alone, the amaru and blinklabs teams are asking an additional 500k USD, which we believe to be appropriate.
>
> 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.
>
> should the condition allow the next year, block production will be strongly considered.
>
> given the current environment we decided it would be best to cut those efforts in order to contain the costs.

#### Pebble (smart contract programming language)

[repo](https://github.com/HarmonicLabs/pebble)

| Main Objective |
| --- |
| production-ready language & tools |

Pebble 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.

##### Compiler Stability

###### Goal

Achieve production-grade compiler stability with optimized code generation.

###### Key Results

- Comprehensive type system with full type inference
- Optimized UPLC code generation with minimal script sizes
- Complete error reporting with actionable messages
- Support for Plutus V4
- Key language features: namespaces, built-in test support, comprehensive standard library
- Documentation and tutorials for onboarding new developers

###### Estimated Effort

2 FTEs

##### Developer Tooling

###### Goal

Provide a complete development experience for Pebble developers with IDE integration, debugging tools, and build system support.

###### Key Results

- **Language Server Protocol (LSP)** implementation:
- Syntax highlighting
- Auto-completion
- Go-to-definition
- Find references
- Inline error reporting
- Hover documentation
- **Stable and reliable sourcemaps** for debugging compiled contracts
- **CLI improvements**:
- Build and watch modes
- REPL for interactive development
- **Blueprint generation** for contract metadata

###### Estimated Effort

1.5 FTEs

##### Pebble Summary

- total resources estimated: `3.5 FTEs`

##### Differentiation from Aiken

Pebble and Aiken serve different developer profiles and are **complementary** within the Cardano ecosystem, not competitive.

| Dimension | Aiken | Pebble | Implication |
| :--------------------- | :------------------------------- | :------------------------------------- | :---------------------------------------------------- |
| **Paradigm** | Functional-first (Rust-inspired) | Imperative-first (TypeScript-inspired) | Different mental models for different developers |
| **Target audience** | Developers comfortable with FP | Web2/EVM developers | Expands total addressable developer pool |
| **Syntax familiarity** | Rust, Gleam | TypeScript, JavaScript, Solidity | Lower barrier for the 17M+ JS/TS developers globally |
| **Learning curve** | Requires FP fundamentals | Familiar imperative patterns | Faster onboarding for majority of developers |

###### Why both matter

Cardano needs multiple on-ramps for developers:
- Developers with Rust/Haskell/FP experience gravitate toward Aiken
- Developers with JS/TS/Solidity experience will find Pebble more accessible
- Both compile to optimized UPLC; the choice is about developer preference, not runtime performance

By funding Pebble, the Treasury expands Cardano's developer funnel without fragmenting it.

#### Hard-fork maintenance

| Main Objective |
| --- |
| guarantee ecosystem stability |

##### Upcoming Intra-Era Hard Fork

###### Goal

Ensure all HLabs TypeScript libraries are updated and fully compatible with the upcoming hard fork, including Plutus V4 changes and new protocol parameters.

###### Key Results

Maintenance of the affected repositories to support new protocol features:

- **[cardano-ledger-ts](https://github.com/HarmonicLabs/cardano-ledger-ts)**: Collection of functions and classes defining the Cardano ledger data structures
- **[ouroboros-miniprotocols-ts](https://github.com/HarmonicLabs/ouroboros-miniprotocols-ts)**: TypeScript implementation of the Ouroboros networking protocol
- **[plutus-machine](https://github.com/HarmonicLabs/plutus-machine)**: CEK machine implementation for UPLC evaluation
- **[uplc](https://github.com/HarmonicLabs/uplc)**: TypeScript/JavaScript representation of UPLC

###### Estimated Effort

1.5 FTE

##### Hard-Fork Maintenance Summary

- total resources estimated: `1.5 FTE`