Relayer

What Is a Relayer?

A relayer is a node or service that forwards transactions, messages, or cryptographic proofs between blockchain networks or between users and on-chain protocols. Rather than requiring every participant to interact directly with every chain, relayers act as intermediaries that monitor events on one system and submit corresponding data to another.

The term "relayer" covers several distinct roles depending on context. In cross-chain bridges, relayers transport messages and proofs between connected blockchains. In gasless transaction systems, relayers submit signed messages on behalf of users who lack native tokens to pay for gas. In decentralized exchange protocols, relayers host off-chain order books and facilitate trade discovery. Each model carries different trust assumptions, economics, and security properties.

How It Works

Despite their different applications, all relayers follow a common pattern:

1. Monitor a source system for specific events (contract emissions, signed messages, or order submissions)
2. Package the relevant data, often including cryptographic proofs or signatures
3. Submit that data to a destination system (another blockchain, a smart contract, or a settlement layer)
4. The destination system verifies the data independently and executes the corresponding action

The critical design question is where verification happens. In well-designed systems, the destination chain or contract performs all verification on-chain, meaning the relayer cannot forge or alter messages. The relayer's role is purely transport: it can delay or withhold messages (a liveness concern) but cannot fabricate them (a safety guarantee).

Cross-Chain Message Relayers

Cross-chain relayers transport messages and proofs between separate blockchain networks. This is the most common use of the term today, and several major protocols implement it differently:

IBC (Inter-Blockchain Communication) relayers in the Cosmos ecosystem are the gold standard for trustless relaying. An IBC relayer watches for packet commitments on a source chain and submits them along with Merkle proofs to the receiving chain. The receiving chain maintains a light client of the source chain and verifies every proof independently. No trust in the relayer is required: anyone can run an IBC relayer, and the protocol's safety properties hold even if every relayer is Byzantine (malicious). Only liveness depends on at least one honest relayer being operational. The IBC Eureka upgrade (IBC v2), launched in April 2025, extended this model beyond Cosmos by using zero-knowledge proof verification to connect directly to Ethereum.

Wormhole uses a permissioned set of 19 Guardian nodes operated by established validators such as Figment, Staked, and Everstake. Each Guardian runs full nodes for every supported blockchain. When a cross-chain message is emitted, Guardians independently verify the event and sign an attestation. Once 13 of 19 Guardians sign, they produce a Verifiable Action Approval (VAA). Separate relayer services (called Executors) then transport the signed VAA to the destination chain, where a smart contract verifies the multisig before executing. The relayer role here is permissionless and purely transport: anyone can deliver a VAA, and the trust assumption rests on the Guardian set, not the relayer.

LayerZero V2 introduced Decentralized Verifier Networks (DVNs), a modular security framework that separates verification from execution. Applications choose their own security configuration through an X-of-Y-of-N model, specifying exactly how many DVNs must verify a message before it is considered valid. As of 2026, over 50 DVN operators run on the network, including Google Cloud, Polyhedra Network, and Nethermind. Separate Executor services handle message delivery, and this role is fully permissionless.

Meta-Transaction Relayers

Meta-transaction relayers solve a chicken-and-egg problem in blockchain UX: users need native tokens to pay gas fees, but acquiring those tokens requires an existing wallet and an on-ramp. Meta-transaction relayers let users sign messages off-chain and have a relayer submit the actual on-chain transaction, paying the gas on their behalf.

The ERC-2771 standard defines how this works on Ethereum. The flow involves three participants: a user (signer), a relayer (forwarder), and a recipient contract:

1. The user signs a message authorizing a specific action, using their private key. This costs no gas.
2. The relayer wraps this signed message into an on-chain transaction, pays the gas fee, and submits it to the recipient contract through a trusted forwarder.
3. The recipient contract verifies the original signer's signature via the trusted forwarder and executes the action as if the user had submitted it directly.

// ERC-2771 recipient contract pattern
// Instead of using msg.sender directly,
// the contract calls _msgSender() to extract
// the original signer from the forwarded call

function _msgSender() internal view returns (address) {
    if (msg.sender == trustedForwarder) {
        // Extract original sender appended by forwarder
        return address(bytes20(msg.data[msg.data.length - 20:]));
    }
    return msg.sender;
}

The Gas Station Network (GSN) built a decentralized network of relayers around this standard. OpenGSN connects users, relay servers, and paymasters (contracts that define who pays for gas and under what conditions) through a central RelayHub contract. This architecture has largely been superseded by account abstraction (ERC-4337), which replaces relayers with bundlers and paymasters as first-class protocol participants.

DEX Order Relayers

In the context of decentralized exchanges, a relayer is a service that maintains an off-chain order book and facilitates trade discovery. The 0x protocol pioneered this model: makers sign orders off-chain, relayers aggregate and display these orders, and takers fill them by submitting both signatures to on-chain settlement contracts.

DEX relayers do not custody funds or execute trades. They serve a pure matchmaking function: hosting orders, presenting them to traders, and earning fees for facilitation. Because 0x provides a shared protocol layer, orders listed on one relayer can be filled through another, creating a network effect where liquidity grows as more applications adopt the standard.

This model has largely given way to on-chain AMMs and more recently to intent-based architectures, where solvers compete to fill user intents rather than relayers hosting static order books.

Trust Assumptions by Relayer Type

The key distinction is between safety and liveness. Most relayer designs ensure that a malicious relayer cannot steal funds or forge messages (no safety trust required). However, all relayer designs depend on at least one relayer being operational to deliver messages (liveness trust). This is why permissionless relaying matters: when anyone can run a relayer, liveness depends on economic incentives rather than trusting specific operators.

Relayer Economics

Running a relayer requires covering infrastructure costs (running full nodes, monitoring events) and transaction costs (gas fees on destination chains). Different protocols handle relayer compensation differently:

• Cross-chain relayers typically earn fees from the protocol or from users who pay a premium for message delivery. IBC relayers often operate at thin margins or as a public good, with some relayer operators subsidizing costs to support ecosystem connectivity.
• Meta-transaction relayers are compensated by paymasters or application-level fee structures. The GSN uses a staking and reputation system where relayers compete on price and reliability.
• DEX relayers earn trading fees from order fills, typically a small percentage of trade volume.

MEV Opportunities

Relayers that see transactions before they reach the chain occupy a privileged position similar to block builders. In cross-chain contexts, relayers can potentially extract MEV by reordering messages, front-running cross-chain arbitrage, or selectively delaying certain messages. This is an active area of research, with protocols exploring encrypted mempools, commit-reveal schemes, and fair ordering to mitigate relayer-extractable value. For a deeper analysis of extraction risks in cross-chain systems, see the research on cross-chain bridging risks.

Use Cases

• Cross-chain token transfers: relayers deliver proofs that enable users to move assets between networks via bridges without interacting with both chains directly
• Gasless onboarding: new users can interact with dApps immediately without first acquiring native tokens, with relayers paying gas through paymaster contracts
• Cross-chain governance: DAO votes on one chain can trigger execution on another through relayed messages
• Multi-chain stablecoin transfers: protocols like Circle's CCTP use relayers (called attesters) to verify burn-and-mint operations across chains, enabling native stablecoin movement without wrapped assets
• Intent-based bridging: modern protocols like Across and Relay use relayers (called fillers) to front liquidity for users and settle later via optimistic verification

Risks and Considerations

Liveness Dependence

Every relayer-based system depends on at least one relayer being operational. If all relayers go offline, messages cannot be delivered even though the underlying protocol remains secure. This is why permissionless relaying is a critical design property: it ensures that anyone can step in to relay messages when existing operators fail. In systems like Spark, which uses a different approach to off-chain scaling, the trust model avoids relayer dependence entirely by using cooperative signing with the operator network.

Centralization Risk

Even when relaying is technically permissionless, economics may concentrate relaying among a few well-funded operators. Running full nodes across dozens of chains is expensive, and relayer revenue often does not cover costs. This can create fragile points of failure where a small number of operators handle the majority of cross-chain traffic.

Censorship

Relayers that see messages before delivery can selectively censor specific transactions or users. While this cannot compromise funds in well-designed systems (users can always find another relayer or relay themselves), it can delay time-sensitive operations like liquidations or arbitrage. Encrypted messaging and redundant relayer sets mitigate this risk.

Gas Cost Exposure

Cross-chain relayers must pay destination-chain gas fees to deliver messages. During periods of network congestion, gas costs can spike unpredictably, potentially making relaying unprofitable or causing delivery delays. Some protocols pre-charge users for estimated gas, while others use fee markets where relayers bid on message delivery. For an overview of how different layer-2 solutions handle transaction costs, see the L2 trust model comparison.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.