Bridge Relayer

Overview

A bridge relayer watches source-chain events, constructs the required message or proof, and submits it to the destination contract. Depending on the bridge, relayers may be permissionless executors, selected operators, or services that also pay destination gas. A relayer should not be able to forge a valid message when verification is sound, but it can affect liveness by delaying or withholding delivery. Incorrect fee estimation, nonce handling, duplicate submissions, or destination contract failures can leave messages pending. Integrators should distinguish message approval from relayer execution and provide a safe way to retry permissionless delivery when supported. Monitoring should track relayer transaction hashes, gas funding, errors, and destination status. A bridge should define whether another relayer can complete the same message without duplicating effects.

Bridge Relayer should be modeled as a multi-stage operation: source authorization, source inclusion and finality, message or proof production, relay, destination verification, destination execution, and destination finality. When evaluating Bridge Relayer, completion of an early stage does not prove that value or instructions reached the destination. Security depends on the exact verification route. Relevant assumptions include the validator or signer set, multisignature policy, light-client or proof design, relayers, upgrade authority, rate limits, and liquidity providers. Being described as official does not eliminate the underlying trust and control assumptions. Asset controls must bind the source asset, destination representation, contract addresses, decimals, mint or custody model, and redemption path. Two assets can share a symbol while having different issuers, contracts, or backing; symbol matching alone is therefore unsafe for crediting.