Finalized source history
On Metal, a canonical block is one finalized through Simplex consensus. Validators execute the block before voting, and a finality certificate records the required quorum’s agreement. The Metal light client verifies that agreement without repeating transaction execution, so it relies on the validators to enforce Metal’s execution rules. Once the header is authenticated, its message root allows the inbox to check whether a particular instruction belongs to that history. A message proof supplies the hashes and message count needed to verify the instruction’s message commitment against this root. For messages arriving on Metal, account and storage proofs establish that the source outbox recorded the commitment under the accepted block’s state root. The evidence used to authenticate the source block differs by network.
These checks depend on the security of the source consensus and the signers
used by its light-client protocol. An attacker who controls enough of the
relevant signing keys could make false history pass verification. The
receiving chain’s signature checks cannot distinguish that history from one
authenticated by honest signers.
Trust in the verifier
Signature verification also depends on knowing whose keys to accept. The party deploying a Metal, Tempo, or Arc client supplies its trusted signing keys, and the receiving application relies on that choice when it accepts calls through the associated inbox. For Metal, the signed statement also includes the chain ID and genesis block hash, binding the signatures to the intended Metal network. These client contracts have no administration interface for replacing their keys. This prevents an administrator from changing the signing authority within an existing deployment, but it also limits which source-network changes that deployment can follow. A new signing key or an unsupported consensus change can require a replacement verifier. Until a supported verifier accepts the affected blocks, their messages remain pending. Ethereum verification starts from a trusted consensus block selected in Metal’s network configuration. Its light-client protocol follows verified changes to the sync committee, allowing verification to continue as committee membership changes. Changing the trusted starting configuration requires a Metal network upgrade.The relayer’s influence
Once the source block is authenticated, the inbox checks that the supplied call matches the message commitment. That commitment includes both chain IDs, the nonce, source sender, receiving contract, and call data. Changing an encoded amount or substituting another receiving contract changes the commitment, causing the original proof to fail. The receiving contract can also use the authenticated sender to apply its own authorization rules. For example, a contract releasing funds can restrict instructions to its approved payment contract on Metal, even though any account can deliver them. After a successful call, the inbox records the message’s nonce and rejects further attempts to execute it. A different relayer or a proof against a later checkpoint does not reset that record. This gives each message at most one successful execution through the same inbox. The record belongs to that inbox and does not carry over to a replacement.Delivery and completion
A relayer can delay a message or choose the order in which it submits valid messages. Another relayer can deliver the same evidence, provided it can obtain the required data and the destination chain can execute the call. There is no guaranteed delivery time, and a valid message can remain unexecuted if nobody submits it. The destination call executes in a separate transaction with its own execution result and finality. If it reverts, the inbox leaves the message available for another attempt, while the finalized source transaction stays in place. If a payment locks funds on Metal and requests their release on another chain, those funds can remain locked while the destination call is pending. Completion requires the intended destination call to succeed and its block to finalize. Any expiry or refund depends on the application’s contracts because the message protocol does not automatically reverse the source transaction when delivery fails.Light Clients and Messages
How light clients and inboxes verify source evidence before a contract call.
Light-client checkpoints
Configuration, supported network changes, and verifier replacement for each chain.