> ## Documentation Index > Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt > Use this file to discover all available pages before exploring further. # Trust and Guarantees > Why a cross-chain message can be trusted, which source-network assumptions it inherits, and what can prevent delivery An application that releases funds in response to a cross-chain message needs assurance that the source chain finalized the instruction. Metal's [interoperability mechanism](https://docs.metalntwx.com/learn/interop/overview.md) lets the destination verify that evidence directly, without relying on the relayer's account of what happened. Its guarantees depend on the source network's security and on the verifier that the receiving application accepts. ## Finalized source history On Metal, a canonical block is one finalized through [Simplex consensus](https://docs.metalntwx.com/learn/architecture.md). 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. | Source chain | Evidence the receiving chain verifies | | - | - | | Metal | A finality certificate signed by the configured validator quorum | | Ethereum | Signatures from a sync committee, a rotating group of validators that signs headers for light clients, together with proofs identifying finalized execution state | | Tempo | A threshold signature checked against the configured validator group public key | | Arc | Validator signatures representing more than two-thirds of the configured voting power | 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. > [card] [Light Clients and Messages](https://docs.metalntwx.com/learn/interop/overview.md) > > How light clients and inboxes verify source evidence before a contract call. > [card] [Light-client checkpoints](https://docs.metalntwx.com/reference/interop/light-clients.md) > > Configuration, supported network changes, and verifier replacement for each chain. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.