Light Clients and Messages

An application may use a payment completed on Metal to authorize the release of funds on another blockchain. Before releasing those funds, the destination chain needs evidence that the transaction authorizing their release finalized on Metal. Metal’s interoperability design makes that evidence verifiable on the destination chain, where an application can check it before acting.

​

From transactions to finalized state

On a blockchain, transactions execute within blocks and update the chain’s state. Full nodes check those transactions and their results against the chain’s rules, while consensus establishes which blocks become final. On Metal, validators execute proposed blocks and vote to finalize them through Simplex consensus. The block header contains cryptographic commitments to the block’s contents and resulting state. These commitments let a verifier check whether particular data belongs to that block. Selected header fields are shown. The block hash covers the complete header. Metal’s validators sign a finalization statement containing the block hash, producing a finality certificate that authenticates the header. A smart contract on another blockchain can verify this certificate and then use the header’s commitments to check a claim about Metal’s finalized history.

​

Light-client verification

A light client authenticates source-chain headers using signatures and proofs from that chain’s consensus. It is light because it can check those headers without re-executing every transaction. It starts from trusted information about the source network, such as its validator public keys. Once it accepts a finalized header, the block hash and its commitments form a checkpoint against which other data can be verified. Metal checkpoint verification uses the validator keys configured in the light client. This separates two checks. Consensus evidence establishes that the source chain finalized the block, and an inclusion proof establishes that the claimed message belongs to the authenticated data. A relayer carries this evidence between networks. Because the destination chain checks the evidence itself, anyone can perform that delivery without being trusted to decide what happened.

​

Verifying Metal on another chain

Metal implements its light-client verifier as a smart contract, MetalLightClient, on the destination EVM chain. A relayer supplies a Metal block header and its finality certificate. The contract checks the validator signatures and required quorum against its trusted validator set, then stores the accepted checkpoint. A certificate authenticates a selected finalized block, so the contract can advance between checkpoints without replaying the intervening blocks. The receiving application can use the stored commitments to verify a message from Metal. The guarantees of this verification depend on the source network’s configuration and consensus security.

​

From verified messages to contract calls

An application requests a remote action by recording a message in the outbox, MetalOutbox. The message specifies the destination chain, receiving contract, and call data, and binds them to the source sender and a unique message number, or nonce. A payment contract can record its payment and enqueue the corresponding message atomically in the same Metal transaction. The outbox adds each message commitment to an append-only Merkle tree. Its message root commits to both the tree’s contents and the number of messages recorded so far. Every Metal block header carries this root, which validators check against the executed state. Finalizing that header therefore authenticates the outgoing messages it covers. On the destination chain, the inbox, MetalInbox, checks the message proof against a checkpoint accepted by the light client. If the proof matches, the inbox calls the receiving contract with the committed call data. The relayer supplies both the consensus evidence and the message proof for these checks. When the inbox calls the receiving contract, it exposes the Metal account or contract that sent the message. A contract that releases funds can use this information to accept instructions only from its approved payment contract on Metal. Before releasing funds, it checks both that the call came through its designated inbox and that the original sender is that payment contract.

​

Verifying other chains on Metal

The reverse direction uses the same verification model. Metal verifies a finalized source block and records an accepted checkpoint, then checks the message against that checkpoint before executing the requested call. The current verification paths cover Ethereum, Tempo, and Arc. On these source chains, an Outbox contract records each message commitment in a storage slot that is written once. Metal’s ForeignInbox checks an account proof for that outbox and a storage proof for the message under the accepted state root. This lets an incoming route use ordinary contract storage without adding Metal’s dedicated message-root field to the source chain’s block format. Each ForeignInbox is bound to a source chain, source outbox, and light client. During the call to the receiving contract it exposes the authenticated source sender, so the receiving application on Metal can apply the same authorization model as an application receiving a message from Metal. Tempo and Arc checkpoints are verified by smart contracts on Metal. Ethereum uses a different execution path. Metal validators verify Ethereum light-client updates as part of block execution and record accepted checkpoints in a protocol contract. The inbox reads those checkpoints when it verifies an incoming message. The light-client reference covers the configuration and verification details for each chain.

​

Asynchronous execution

Executing the destination call requires a separate transaction on the destination chain. Source finality makes a message eligible for delivery, but the destination still needs an accepted checkpoint, the required proofs, and a successful call to the receiving contract. The destination outcome becomes final under that chain’s own consensus. This separation lets the two chains finalize independently. It also means a source transaction can be final while its destination call is still pending. Trust and Guarantees explains what the receiving application can rely on, how replay protection works, and which delivery and recovery behaviors applications must provide.