> ## 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.

# Light Clients and Messages

> How Metal verifies finalized outcomes across blockchains and uses them to authorize contract calls

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](https://docs.metalntwx.com/learn/architecture.md).

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.

![Transactions, execution receipts, resulting state, and cumulative outbox messages have corresponding commitments in a Metal block header. Hashing the complete header produces the block hash.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/interop/block-header.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=398623dedd467787c7cb5d59126569f0)

*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.

![A light client hashes the supplied Metal header and verifies the finality certificate's signatures and quorum against trusted validator keys. Successful verification produces an accepted checkpoint.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/interop/light-client-verification.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=2c00da9dbfad3f9a9d30c76b1f2c174e)

*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](https://docs.metalntwx.com/learn/interop/guarantees.md) 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.

![A relayer supplies Metal finality evidence to the destination light client and a message proof to the inbox. The inbox uses the accepted checkpoint to verify inclusion, then calls the receiving contract, which authorizes the source sender.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/interop/message-execution.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=49ef1930bd602bf37f25552c3d592d21)

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](https://docs.metalntwx.com/reference/interop/light-clients.md) 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](https://docs.metalntwx.com/learn/interop/guarantees.md) explains what the
receiving application can rely on, how replay protection works, and which
delivery and recovery behaviors applications must provide.

> [card] [Trust and Guarantees](https://docs.metalntwx.com/learn/interop/guarantees.md)
>
> Source authenticity, message integrity, replay protection, and delivery limits.

> [card] [Finality certificates](https://docs.metalntwx.com/reference/interop/finality-certificates.md)
>
> The evidence that authenticates a finalized Metal block.

> [card] [Send messages from Metal](https://docs.metalntwx.com/build/interop/send-messages-from-metal.md)
>
> Queue a message, build its proof, and execute the destination call.

> [card] [Receive messages on Metal](https://docs.metalntwx.com/build/interop/receive-messages-on-metal.md)
>
> Prove a source outbox commitment and deliver its call on Metal.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.