cETH Whitepaper

Moving assets between different chains is a complex task, which often requires usage of centralized exchanges. This complicates user onboarding to the new chains, leads to fragmented liquidity, limits possible cross-chain farming strategies, and leads to less accurate pricing of on-chain assets due to smaller arbitrage options.

The protocol bridges ERC-20 between Ethereum and Canton, for example ETH on Ethereum to cETH on Canton. It is centralized by design, with a trusted relayer enforcing limits and correctness, with future plans of making it decentralized.

Bridges traditionally use lock/mint and burn/release patterns with a trusted attestation layer. The presented design follows this paradigm while focusing on deterministic backend processing, explicit checkpoints, and reorg recovery. It also borrows operational patterns from centralized settlement systems: strict state transitions, idempotency, and audit‑friendly logs.

Each transfer is identified by a unique messageId (bytes32). The relayer stores and checks this ID to prevent replay and to allow safe restarts. The messageId is carried end‑to‑end and is the primary correlation key in logs and the database.

The bridge treats a “message” as an immutable intent with an execution lifecycle. The relayer records: source chain identifier and transaction hash, destination chain identifier and transaction hash (once executed), amounts and addresses/parties, and timestamps for observability.

Users trust that the relayer will not mint unbacked assets and will not release funds without a valid Canton withdrawal. Operational controls, audit logs, and DB state transitions provide accountability.

In practice this implies: the relayer's key management and operational procedures are part of the security boundary. The bridge is only as reliable as its RPC/data sources unless the relayer cross‑checks providers.

The relayer uses a small set of statuses in processed_messages to drive idempotent processing. The state machine is intentionally simple — it can be extended later with finer granularity if operational requirements demand it.

The relayer processes external events at-least-once (events can be re-observed after restart or rollback), but the combined design aims for exactly-once effects by enforcing idempotency at the message level: source observation can repeat; destination execution is guarded by messageId uniqueness and DB state.

chain_checkpoints stores the last fully scanned block and its block hash. On restart, the watcher resumes from this checkpoint. Checkpoints are namespaced by chain ID, router address, and destination chain to prevent collisions across networks.

The watcher compares the stored checkpoint hash with the current chain hash at the same height. A mismatch triggers rollback by a safety buffer, deletes affected rows, and rescans the range.

The rollback strategy is conservative: roll back before the divergence by a fixed buffer; delete any processed_messages above the rollback height; rescan deterministically from the rollback height to the safe head.

processed_messages ensures each messageId is processed once, supporting safe retries and relayer restarts. The DB is the source of truth for operational state and auditing.

The relayer always queries/updates by messageId and treats duplicates as no‑ops.

The relayer separates inclusion (tx mined, has receipt) from finality (tx reached a configured confirmation depth).

For EVM deposits, the watcher only scans up to latest − confirmations. For EVM withdrawals, the signer waits for the receipt and then waits until the receipt's block has enough confirmations.

This system should be analyzed as a centralized custody/settlement component: a compromised relayer key can steal funds; a compromised RPC provider can cause incorrect observations or delayed processing; a compromised database can hide or distort operational history.