Skip to content
CLPR

Cross-ledger messaging with nothing in between.

CLPR (“Clipper”) is an open Cross Ledger PRotocol for reliable, asynchronous, in-order message passing between independent ledger networks. Trust comes from each ledger’s own state proofs, not from bridges, pooled liquidity or intermediary validator networks.

Read the specificationExplore the code

Contributed by Hashgraph, built natively into Hiero and stewarded by LF Decentralized Trust.

  • Hashgraph
  • Hedera
  • Hiero
  • LF Decentralized Trust

CLPR in three steps

Bridges ask two ledgers to trust a third party. CLPR lets each ledger trust only what it can prove.

01 / 03

Two independent networks.

Each ledger keeps its own consensus, its own rules and its own validators. Neither one has to hand control to anyone to talk to the other.

02 / 03

A direct, ordered Channel.

Messages queue in order on the source ledger, linked by a running-hash chain, and cross in bundles. Every Data Message gets exactly one response.

03 / 03

Proofs, not promises.

The destination’s Verifier Contract checks the source ledger’s state proof itself. No bridge, no pooled liquidity, no intermediary validators.

Protocol properties

Guarantees enforced by the ledgers themselves.

CLPR does not add a party that has to be trusted. What it promises follows from consensus, state proofs and an ordered queue on each side of the Channel.

  • In order, tamper-evident

    Messages on a Channel arrive in the order they were sent. A running-hash chain fixes that order and makes any change visible.

  • Exactly one response

    Every Data Message produces exactly one Response Message, with a status and reply bytes, on the same Channel.

  • Zero custody

    Endpoints never hold assets. There is no pooled liquidity sitting in the middle, waiting to become a target.

  • Permissionless delivery

    If an Endpoint goes offline, anyone, including the sender, can submit the proof and the Channel moves on.

  • Any payload

    Arbitrary bytes: data, oracle feeds and contract calls. Asset transfers are application logic built on top.

  • Speed of consensus

    No extra confirmation rounds from a bridge. Latency is bounded by how fast the two networks reach consensus.

How it works

Follow one message across a Channel.

Seven steps from one ledger to the other and back. Let it play, or step through at your own pace.

Step 1 of 7

An application hands over a payload

An application on Ledger A sends an arbitrary byte payload to its CLPR Service and names the Connector that will pay for execution on Ledger B.

Step 1 of 7: An application hands over a payload. An application on Ledger A sends an arbitrary byte payload to its CLPR Service and names the Connector that will pay for execution on Ledger B.

Why bridgeless

Trust lives in the ledgers, not in a bridge.

Bridges and relayers were built as workarounds for isolated chains, and they add a party in the middle that has to be trusted. CLPR removes that party: each ledger verifies the other’s state directly, using proofs it can check itself.

Compare by

Typical bridge

A third party sits between the chains and holds the keys and the assets.

Where trust lives

In a separate validator set, multisig or relayer network

CLPR

Each ledger checks the other’s state proofs itself. Nothing sits in between.

Where trust lives

In the two ledgers, through state proofs checked by Verifier Contracts

Architecture

Four layers, one minimal API.

Applications only see a small interface for sending and receiving payloads. How ledgers prove and verify each other’s state stays below it, which is what lets CLPR span very different networks.

  1. L4

    Application

    A minimal API for sending and receiving message payloads. Asset transfers and cross-ledger contract calls are application logic on top of it.

    CLPR Application API

  2. L3

    Payment & routing

    Connectors pay for message execution on the destination ledger and can be slashed for misbehavior. The CLPR Service routes each message to its application.

  3. L2

    Messaging

    An ordered, state-proven queue per Channel. Messages travel in bundles linked by a running-hash chain, so one proof extends trust to every message inside.

  4. L1

    Network

    Permissionless Channel registration with commit-reveal against ID squatting, the bundle sync protocol between Endpoints, and the pluggable Verifier Contract interface.

Chain-agnostic

Bring any ledger that can prove its state.

CLPR is chain-agnostic. Supporting a new ledger type means building three components. The destination CLPR Service never changes, because each Verifier Contract translates the source ledger’s format into the local one.

  • CLPR Service

    Native to the ledger or deployed as a smart contract. Curates CLPR state, manages Channels, routes messages and coordinates payment between Connectors, applications and Endpoints.

  • CLPR Endpoints

    Read local ledger state, build state-proven bundles in the source ledger’s format, sync them with peer Endpoints, and rotate the ledger’s trust anchor in remote Verifier Contracts.

  • Verifier Contracts

    Immutable contracts, one per target ledger type. They verify incoming state proofs against an updatable trust anchor and decode bundles into the local data format.

Connecting a new ledger to Hiero

Hiero already speaks CLPR natively. Step through what the new ledger needs, and watch it come together.

Step 1 of 8: Implement a CLPR Service and CLPR Endpoints for the new ledger type.

Once both ledgers implement CLPR natively, their validators become the Endpoints and no separate infrastructure is needed.

Open source

Open specification, open implementations.

The specification is normative and has no software dependencies, so it can be implemented in any language for any chain. The reference implementations show one way to do it.

Start hereSpecification
clpr-spec(Open repository)

The CLPR specification: component behavior, common data structures and formats, plus architecture decision records tracing how the design evolved.

Clone the specification

$ git clone https://github.com/LFDT-CLPR/clpr-spec.git
How the project is rungovernanceHow the lab is run: maintainers, processes and decision-making, following LF Decentralized Trust practices.(Open repository)
Code license
Apache-2.0 with DCO sign-off
Specification license
Community Specification License 1.0

Shared vocabulary

Terminology

The terms used throughout the CLPR specification. Pick one on the map, or search for it below.

  • Network

    Term 1 of 14

    The other ledger that a network communicates with over CLPR.

    See it in How it works

    Related terms

Get involved

Build CLPR in the open.

CLPR is stewarded under the neutral, vendor-independent governance of LF Decentralized Trust. Hashgraph and Hedera are the initial maintainers, and the lab is open to anyone who wants to help.

Contributed by Hashgraph on behalf of the Hedera Governing Council, building on Dr. Leemon Baird’s approach to cross-ledger communication. Hiero is building the first native implementation.

Start with the specification.

It is the shortest path to understanding how two ledgers can trust each other directly.

Read the specificationFollow LFDT-CLPR on GitHub