What relayers actually do in bridge transfers

Relayers in bridge transfers are off-chain message passers, not funds movers: they watch for a deposit event on the source chain and submit a matching execution transaction on the destination chain. Once that transaction lands, the relayer’s job ends. The bridge contract — not the relayer — decides whether the transfer is valid, and that separation drives almost every operational choice you make when sizing up a bridge.

The mechanism, end to end

Start on the source chain. You call the bridge contract’s lock or burn function with the recipient, token, amount, destination chain, and any optional data. The contract emits an event: BridgeSent(transferId, recipient, token, amount, destinationChain). That event is the entire instruction set. The bridge contract does not care yet whether any relayer is listening.

A relayer picks up that event off-chain, formats calldata for the destination bridge’s execute(transferId, recipient, token, amount) function, and submits the transaction on the destination chain, paying destination gas. Often it batches several messages into one transaction to split that gas cost. The destination contract checks that the transfer ID has not been executed, confirms that its trusted source root actually contains that event, then mints or releases the corresponding tokens to the recipient. No token travels across a wire; it is a lock-and-mint pairing.

Because each leg is an Ethereum Virtual Machine execution — whether the destination is Polygon Network or an L2 — a relayer does not need to understand the asset, only the event. Think of it as the messenger for an emitted log, whether that log comes from a bridge locker or a Uniswap Protocol pool; it cannot see balances, only logs. A cross-chain swap assembled by an aggregator like Paraswap is still this same sequence underneath: relayers are carrying the messages between lock/mint calls. If you want to trace that fee through a quoted transfer, follow it on note.com.

What relayers are not

Three roles usually get blurred into “relayers”. The distinction matters because it changes the security model:

• Custodian. A relayer never holds the tokens. The source contract locks them, and the destination contract releases them. Your counterparty is the bridge contract, not a relayer.
• Validator or updater. The relayer does not attest source state. It submits an event only after a bridge’s own updater or committee has already rooted that state on the destination chain. If that root is wrong, the relayer is not where funds get lost; the bridge’s attestation set is.
• Oracle. It does not price the transfer or decide terms. The payload is fixed by the source call; a relayer can only choose whether to carry it.

When to use a relayer

For a standard EVM-to-EVM token transfer, relayers are the sane default. They keep destination gas low, bring latency down to a few blocks, and anyone can race to submit the message in the common permissionless design. The trust assumption remains whatever the bridge uses to update roots; relayers only add a liveness risk, not a theft risk.

Relayers are the wrong tool for arbitrary cross-chain state sync with large payloads. There you want a light-client or zk-verified bridge, even if it costs more gas. And if the destination call can fail — for example, the mint is paused — a relayer cannot undo the source lock. A bridge without an explicit refund or recover path for that case will leave your asset stranded, no matter how many relayers are watching.

Self-relay is the edge case

Most bridge contracts allow any address to call execute if the event exists. That means when destination gas is cheap and relayers are asking for a high fee, you can submit the transaction yourself and pay only raw gas. The relayer fee is a market price, not a toll. In an aggregator context, that self-relay path is the pressure valve that keeps bridge fees honest.