Hedera’s HIP-1535 Proposes Bridge-Free Cross-Ledger Proofs

On September 1, Hedera presented HIP-1535 as a plan—not a production launch—for cross-ledger messaging that replaces bridge-validator attestations with direct verification of ledger state proofs. For a fund or trading desk, that could remove one committee-based trust layer from transfers and settlement instructions, but it does not yet provide a live route, asset liquidity or measurable execution costs.

What did Hedera actually launch with HIP-1535?

Hedera released a draft specification for CLPR, the Cross-Ledger Protocol, rather than activating the service on mainnet. The HIP-1535 draft, created August 18, describes a native Hiero service and says separate verifier specifications exist for Hiero, Ethereum, QBFT and Sei. It does not document production deployments, completed audits or active channels.

CLPR is also a messaging layer, not an asset bridge by itself. Applications could use authenticated messages to coordinate token transfers, swaps or collateral movements, but they must supply the asset contracts, liquidity and business logic.

How would CLPR verify and settle a message?

CLPR would have the receiving ledger authenticate a proof of the sending ledger’s committed state through a verifier contract fixed to a specific channel. Permissionless endpoints relay ordered message bundles, but they do not decide whether the messages are valid; the destination service verifies the proof, replay protection, sequence numbers and a cumulative SHA-256 running hash before execution.

• An application selects a channel, connector and destination application.
• The connector authorizes the message, which enters an ordered outbound queue.
• An endpoint relays a bundle and state proof to the destination ledger.
• The destination verifies, executes and later returns an ordered response.

This removes a separate validator federation, not all trust. Each application still relies on both ledgers, both CLPR implementations and the channel’s verifier contract. If both ledgers provide asynchronous Byzantine fault-tolerant finality, the proposal says the route inherits that property. A channel accepting an Ethereum “latest” or “safe” commitment instead carries more reorganization risk than one restricted to finalized state.

What changes for a fund or trading desk?

The practical gain would be a cleaner verification boundary: a desk could assess the two ledgers and an immutable channel verifier instead of underwriting an additional bridge committee and its signing keys. Different channels could serve different risk tolerances, allowing a high-value workflow to require finalized proofs while a latency-sensitive application chooses a weaker commitment level.

Settlement economics remain external to the proof system. Connectors must maintain balances and slashable stake on each ledger, front destination execution costs and reimburse bundle submitters plus a margin. CLPR specifies no new token and no extra protocol fee on message enqueue, but it does not eliminate native transaction fees or connector capital requirements.

What is the main constraint on HIP-1535?

The verifier is the decisive constraint because CLPR does not certify its correctness. A defective verifier can invalidate the promised security model; it cannot be replaced within an existing channel, so applications must migrate to a new channel while an administrator closes the old one. Endpoints also remain necessary for liveness, and queued messages can reach configurable backpressure limits during an outage.

The design is a meaningful attempt to reduce bridge trust, but “validator-free” should not be mistaken for risk-free or live. The draft gives no fixed message fee, stake minimum, bundle capacity, delivery time or deployment date, so those operating metrics—and production readiness—could not be verified.