Skip to content
Financial Context Wiki

Cross-chain relayer liveness risk

Relayer liveness risk is the risk that an authenticated cross-chain message is not delivered or executed on time; diagnosis must separate source finality, proof availability, delivery, destination execution and asset accounting.

Updated

For educational purposes only; not investment advice. Cross-chain delays can strand assets, consume fees or become permanent loss when proof, expiry, contract or recovery assumptions fail.

Direct answer

Cross-chain relayer liveness risk is the risk that a valid, authenticated message is not submitted or executed on its destination in time. A relayer usually transports a message and proof or metadata; it does not make the source event final or authorize the payload. Source consensus, proof or attestation production, destination verification and receiver execution are separate dependencies.

A delayed delivery is initially an availability problem, not proof that assets were stolen. It can nevertheless create financing cost, missed deadlines, expired tickets, unusable liquidity or permanent loss under a product’s rules. Conversely, a source receipt and a front-end Pending label do not prove that the problem is the relayer: the source may not be final, the proof may not exist, the destination may be paused, gas may be underfunded or the receiver may revert.

Permissionless delivery is protocol-specific. Hyperlane and Wormhole describe paths in which third parties can deliver authenticated messages, while other deployments restrict executors, destination callers or recovery functions. Open submission does not let a relayer alter an authenticated payload, and allowlisting a relayer does not replace destination verification or replay protection.

How it works

A useful lifecycle separates source submitted, source finalized, proof pending, ready, destination submitted, failed/retryable, executed, and expired/cancelled. Those labels are analytical; each protocol has its own on-chain fields. An OP Stack withdrawal, a CCTP burn-and-mint message, a Wormhole VAA and a Hyperlane message have different proof, timing, fee and retry rules.

First establish whether the source action actually locked, burned or dispatched value and whether it reached the required finality. Next establish whether the expected root, validator signatures, guardian VAA or attestation is available and current. Only then ask whether a relayer observed the message, accepted its fee policy, built correct metadata, and submitted it to the exact destination contract.

Destination execution has independent failure modes: chain or sequencer outage, stale RPC, contract pause, wrong receiver version, insufficient gas, ordered-nonce blockage, expiry, or application revert. A transaction hash is only a submission reference. Completion requires a successful receipt, protocol processed state, receiver event or state change, correct token identity and the expected balance effect under the required destination finality.

Manual relay is not a universal rescue button. It is possible only when the deployed protocol exposes an eligible entry point, the exact original message and proof are obtainable, the caller is permitted, the message remains unconsumed and unexpired, and the caller can fund destination gas and value. Simulate the official destination call. Never create a new source lock or burn merely to repair an unexplained first message.

Retry and replay are different. A documented retry resubmits the same canonical message after a failed destination effect; correct consumed or nonce state permits at most one successful effect. Multiple relayers can race and waste gas even when replay protection preserves safety. Cancellation of a local task cannot recall a destination transaction already broadcast or included.

Use this workflow:

  1. Pin the protocol, lane and deployed version, source and destination domains and contracts, source transaction and log, message ID or nonce, asset action, raw amount, receiver and expiry.
  2. Verify the source receipt and event, then apply that chain and protocol’s required confirmation or finality rule; inspect block identity and reorganization status instead of trusting the interface.
  3. Locate the protocol-defined proof, VAA, attestation, checkpoint or root; verify its source state, version, signer set, availability and invalidation or expiry status.
  4. Inspect destination chain health, messenger and receiver versions, pause state, nonce or processed state, predecessor requirements, deadline and required native gas.
  5. Determine whether delivery is permissionless, allowlisted or caller-restricted; for an eligible manual path, reconstruct and simulate the exact original payload, proof and official destination call.
  6. Refresh the gas limit, price, exchange-rate markup, fee cap, refund and expiry quote; submit or retry the same message, handle duplicate and replacement races, and retain the destination receipt.
  7. Reconcile source escrow or burn, in-flight liability, destination mint, unlock or call, protocol and gas fees, refunds and final state; escalate through documented channels without sharing a seed phrase or private key.

Examples

  • Attribute delay by stage. Source finality takes 12 minutes, proof or attestation production 8 minutes, the relayer queue 35 minutes, and destination inclusion 5 minutes. End-to-end time is 12 + 8 + 35 + 5 = 60 minutes. Only the 35-minute queue belongs to delivery liveness; the first 20 minutes and final 5 minutes have different owners.
  • A destination gas quote becomes insufficient. Gas limit is 300,000. At 25 gwei, the quote is 300,000 * 25 * 10^-9 = 0.0075 ETH. At execution, 60 gwei requires 0.018 ETH, leaving a 0.018 - 0.0075 = 0.0105 ETH shortfall. Paying more source-chain gas does not necessarily fund destination execution.
  • Duplicate relayers spend gas, not principal. Three relayers submit the same 100,000 USDC message. The winner uses 180,000 gas * 30 gwei = 0.0054 ETH; two losing transactions each revert after 70,000 gas * 30 gwei = 0.0021 ETH. Total relay gas is 0.0054 + 0.0021 + 0.0021 = 0.0096 ETH, while correct replay state allows one 100,000 USDC effect, not 300,000 USDC.
  • Track the in-flight liability. A lock-and-mint route locks 25 ETH, but the destination call fails: escrow is +25 ETH, wrapped supply is +0 ETH, and in-flight liability is 25 ETH. A successful retry of the same message leaves escrow at 25 ETH, raises wrapped supply to 25 ETH, and reduces in-flight liability to 0 ETH. A new 25 ETH source deposit would instead create 50 ETH of escrow and two obligations.

Risks

  • A source transaction remains pending or reverts while the interface reports sent.
  • A source event is acted on before sufficient finality.
  • A source reorganization removes or changes the event.
  • Proof, attestation, checkpoint or signature data is unavailable.
  • A stale, wrong or invalidated root or signer set is used.
  • An allowlisted relayer key or service becomes unavailable.
  • Permissionless delivery is mistaken for guaranteed prompt delivery.
  • A caller-restricted entry point is mistaken for a public manual path.
  • The destination chain, sequencer, RPC or indexer is unavailable or stale.
  • The destination messenger or receiver is paused.
  • A receiver upgrade or address mismatch makes the call revert.
  • The destination gas limit is too low.
  • The gas quote, exchange rate, fee cap or refund assumption becomes stale.
  • The wallet lacks the correct destination native gas asset.
  • A message, ticket, proof or execution deadline expires.
  • An ordered nonce gap blocks later messages.
  • Retry or consumed-state logic permits duplication or prevents recovery.
  • Duplicate submission, cancellation or replacement races waste gas.
  • A fake support path supplies malicious contracts, proofs or calldata.
  • Source lock or burn, in-flight claims, destination effects, fees and refunds are misreconciled.

Common misconceptions

  • The relayer authenticates the message. Delivery carries evidence; the destination verifier and application enforce source, sender, payload and replay rules.
  • A relayer outage means assets are already lost or automatically refunded. The first result is delay; expiry, recovery, solvency and refund consequences are product-specific.
  • Permissionless relay means anyone can change the payload or guarantees immediate execution. Authentication prevents mutation, while proof, gas, chain and receiver availability still control liveness.
  • Any retry causes a double mint. A correct retry reuses one message and permits only one successful effect; a new source transfer creates a new obligation instead.
  • A destination transaction hash or completed interface label proves receipt. Confirm receipt success, processed state, receiver events, balances, token identity and required finality.

Sources

Navigation

Search the wiki...