An LF Decentralized Trust Lab
CLPR (“Clipper”) is an open protocol for reliable, in-order messaging between independent ledger networks. The destination ledger verifies the source ledger’s state proofs, so trust comes from the ledgers, not from bridges, pooled liquidity or intermediary validators.
Contributed by Hashgraph, with a native Hiero service specified in HIP-1535, and hosted as an LF Decentralized Trust lab.
Many bridges ask two ledgers to trust a third party. CLPR lets each ledger check the other’s proofs instead.
01 / 03
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
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
The destination’s Verifier Contract checks the source ledger’s state proof itself. No bridge, no pooled liquidity, no intermediary validators.
Why bridgeless
Interledger solutions often add an intermediary consensus layer or a federated bridge: a party in the middle that has to be trusted. CLPR has no such party. Each ledger verifies the other’s state with proofs it checks itself, and the Endpoints that carry those proofs cannot forge them.
A third party sits between the chains: a federated bridge, a validator set or a custodian.
Each ledger checks the other’s state proofs itself. Endpoints build and relay them but cannot forge them.
A Channel is only as trustworthy as its Verifier Contract, and anyone can register a Channel, so applications should check which verifier it uses.
Why a party in the middle is the weak pointUse cases
A CLPR message is bytes with an address, and every Data Message gets exactly one response. The design outlines four patterns built on that primitive. They are applications, not part of the protocol, and none is specified yet.
A contract on one ledger calls a contract on another through a proxy on each side. The result comes back as the response, later rather than within the same call.
Assets are locked on the source ledger and minted on the destination. If minting succeeds, the locked assets may be burned; if it fails, they are released.
Several ledgers change state together through two-phase commit, carried as ordinary messages. If any one of them fails, all of them roll back.
Hiero tokens, fungible and non-fungible, handled across Hiero networks by the messaging layer itself, with no smart-contract proxies. The design gives this one sentence so far.
Architecture
CLPR is chain-agnostic. Supporting a new ledger type means building three components. The destination CLPR Service needs no change to its implementation, because each Verifier Contract translates the source ledger’s format into the local one.
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.
Read local ledger state, build state-proven bundles in the source ledger’s format, sync them with peer Endpoints, and keep the trust anchor on each remote Channel current as the ledger’s signing authority changes.
Each checks one ledger type’s proofs, and a Channel is bound to one for its whole lifetime. They verify incoming state proofs against the Channel’s trust anchor and decode bundles into the local data format.
Hiero has a native CLPR Service, specified by the approved HIP-1535, and builds its Endpoints into every consensus node, so that side needs no separate relay infrastructure.
How a new ledger is addedOpen source
The specification is normative and language-neutral: wire formats, state and algorithms that any language can implement on any ledger. The reference implementations show one way to do it.
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.gitclpr-smart-contracts
Reference implementationCLPR Service and Verifier Contracts for EVM ledgers.
LFDT-CLPR/clpr-smart-contracts
(Open repository)clpr-endpoint
A CLPR Endpoint that reads EVM chain state and submits bundles to EVM ledgers. It supports QBFT and CometBFT proof types.
LFDT-CLPR/clpr-endpoint
(Open repository)hiero-consensus-node #27029
HIP-1535 approvedThe native CLPR service inside the Hiero consensus node, specified by the approved HIP-1535. An opt-in service: networks that do not enable it are unaffected.
hiero-ledger/hiero-consensus-node/pull/27029
(Open repository)Get involved
CLPR is a lab of LF Decentralized Trust, run in the open by its maintainers under LFDT’s technical oversight. Its maintainers and committers are listed in the governance repository, and the lab is open to anyone who wants to help.
Review the spec and its decision records, raise issues and propose changes. The Labs charter calls for specification work under the Community Specification License 1.0.
Open clpr-specImprove the Solidity contracts or the Java Endpoint. Code is Apache-2.0 licensed and every commit needs a DCO sign-off.
Browse the repositoriesMaintain a network that can produce or verify state proofs? Help build its Service, Endpoints and Verifier Contracts, or a native integration.
See how a ledger is addedContributed by Hashgraph under its agreement with the Hedera Governing Council. The ideas build on Dr. Leemon Baird’s proposals for cross-ledger communication. The first native implementation is part of Hiero.