Relayer Failure

A relayer can fail by refusing to process or forward specific transactions, effectively censoring users. This can be due to compliance policies, malicious intent, or economic disincentives (e.g., low fees).

• Example: A centralized sequencer in a rollup refusing to include transactions from a sanctioned address.
• Impact: Breaks the core blockchain property of permissionlessness and availability.

This is a complete operational halt where the relayer stops submitting any data to the destination chain. Causes include server downtime, network partitions, or a coordinated attack on the relayer infrastructure.

• Example: A bridge's validator set goes offline, freezing all cross-chain withdrawals.
• Result: Creates a single point of failure, stranding assets or halting application state updates.

A subtle failure mode where a relayer receives transaction data but deliberately withholds it from being published. This is a key attack vector in optimistic rollups during the challenge period.

• Mechanism: A malicious sequencer could withhold a fraud proof transaction to make an invalid state root appear valid.
• Mitigation: Relies on watchtowers or a decentralized, permissionless set of relayers to force publication.

Relayers often require gas fees to operate. Failure occurs when it becomes economically irrational for any relayer to submit a transaction, creating a liveness trap.

• Scenario: Network congestion on the destination chain causes gas costs to exceed the relayer's fee or the transaction's value.
• Common in: User-operated gas relay services and certain cross-chain messaging protocols during extreme volatility.

The relayer acts maliciously by submitting incorrect or fraudulent data. This is distinct from liveness failure and represents an active attack on system integrity.

• Examples: Submitting a fake Merkle proof for a bridge withdrawal, or relaying an outdated state root from a rollup.
• Defense: Requires cryptographic fraud proofs or zero-knowledge validity proofs to detect and slash the malicious relayer.

Not a failure event itself, but the primary root cause. A system dependent on a single, centralized relayer inherits all its operational and trust risks.

• Key Vulnerabilities: Private key compromise, regulatory takedown, or insider risk.
• Architectural Solution: Decentralizing the relayer role through permissionless networks, threshold signatures, or fault-tolerant consensus among many relayers.

A relayer is a network participant that submits user-signed transactions to the blockchain, covering the gas fees on the user's behalf. This enables gasless transactions, a key feature of meta-transaction systems and account abstraction. Relayer failure occurs when this service is unavailable or compromised, breaking the fundamental promise of seamless user interaction.

A malicious or compromised relayer can selectively censor transactions. This attack vector involves the relayer refusing to submit specific transactions based on sender, recipient, or contract address.

• Impact: Users are denied service, which can be used for front-running, market manipulation, or enforcing blacklists.
• Mitigation: Systems like ERC-4337 (Account Abstraction) support a decentralized relayer network, allowing users to switch providers if one is censoring.

This is a non-malicious failure where the relayer service goes offline due to technical issues like server outages, software bugs, or misconfigured gas parameters.

• Impact: All dependent user transactions stall. In systems with time-sensitive operations (e.g., liquidation protection in DeFi), this can lead to direct financial loss.
• Example: A DApp's dedicated relayer goes down, rendering its front-end unusable for all users who rely on gasless transactions.

Attackers can exploit relayers through economic means.

• Gas Price Griefing: Spamming the relayer with computationally expensive transactions to drain its gas fund.
• Stale Nonce Blocking: Submitting a transaction with a high gas fee for a user's future nonce, blocking all subsequent transactions until it is mined or replaced.
• Mitigation: Relayers implement gas limits per transaction, whitelists, and economic reputability checks to filter spam.

Using a single relayer introduces a central point of failure and trust assumption. The relayer must be trusted to:

1. Correctly simulate transaction validity.
2. Not front-run or manipulate user transactions.
3. Maintain reliable infrastructure. This centralization risk contradicts blockchain's decentralized ethos. The security of the entire application layer becomes dependent on the relayer's integrity and uptime.

Modern architectures are designed to reduce relayer risk:

• Decentralized Relayer Networks: Protocols like ERC-4337 allow multiple bundlers (relayers) to compete, preventing censorship.
• User-Operated Nodes: In systems like EIP-3074, users can authorize a one-time transaction to a friend's node, acting as a temporary, trust-minimized relayer.
• Fallback Mechanisms: DApps should allow users to self-submit transactions by paying gas directly if the primary relayer fails.

Many cross-chain bridges rely on a relayer network to submit proof of a deposit on the source chain to the destination chain. A failure in this relay process, whether due to technical faults, censorship, or malicious collusion, can freeze user funds. For example, a bridge's off-chain relayer going offline could prevent the minting of wrapped assets, stranding value between chains.

Protocols like Gas Station Network (GSN) and ERC-4337 Account Abstraction depend on paymasters or bundlers to relay and pay for user transactions. If these relayers fail—due to insufficient funds, misconfiguration, or being outbid on gas—user operations will not be included in a block. This breaks the user experience for "gasless" dApps that abstract away gas fees.

Decentralized oracles like Chainlink use a network of nodes to relay off-chain data on-chain. While designed for redundancy, a critical failure in the node operator set or their external data sources can delay or halt price feed updates. This can cause DeFi protocols relying on accurate data for liquidations or settlements to malfunction, leading to insolvency or frozen states.

Optimistic Rollups (e.g., Optimism, Arbitrum) post state roots to Ethereum L1 via a designated Sequencer. If the sequencer fails to relay these commitments, the L2 chain cannot finalize its state on the secure base layer, preventing withdrawals. While users can force transactions via L1, this creates a withdrawal delay and degrades the user experience.

To combat single points of failure, protocols implement decentralized relayer networks. Key designs include:

• Permissionless Relaying: Anyone can submit proofs or transactions for a reward (e.g., Across Protocol's relay auction).
• Staked Operator Sets: Relay operators post a bond (stake) that can be slashed for malfeasance or downtime.
• Fallback Mechanisms: Systems like EigenLayer allow for the creation of decentralized AVS (Actively Validated Services) for critical tasks like bridging.

Aligning relayer operator incentives with network liveness through cryptographic economics.

• Service-Level Agreements (SLAs) with Bonds: Operators lock capital that is forfeited if they fail to meet uptime guarantees.
• Protocol-Owned Relays: Networks like Cosmos and Polygon often run canonical, protocol-funded relayers for critical cross-chain bridges.
• Reward Distribution: Relayers earn fees (e.g., priority fees, MEV) for successful service, creating a competitive market for reliability.

Reducing exclusive dependence on any single transaction submission path.

• Public Mempool Submission: As a last resort, broadcasting a transaction directly to the public mempool via a standard RPC node, accepting the risk of frontrunning.
• Multi-Relay Broadcasting: Sending the same transaction to several relayers simultaneously; the first successful inclusion wins.
• Hybrid Architectures: Using specialized relayers (e.g., for MEV protection) alongside standard RPC endpoints for non-critical transactions.

A core property of decentralized networks, ensuring transactions cannot be unjustly excluded. Relayer failure can become a vector for censorship if the relay is malicious or compromised and selectively withholds blocks containing certain transactions. This contrasts with liveness failures, where transactions are delayed unintentionally due to technical faults.

A critical redundancy system for mitigating relayer failure. In systems like MEV-Boost, validators configure a bid deadline and a fallback URL. If the primary relay fails to deliver a block by the deadline, the validator's client will fall back to:

• Using a secondary, backup relay.
• Proposing a block built locally by its own execution client. This ensures the validator can still propose a valid block and avoid an inactivity leak.

A system design where users rely on a third-party relayer to submit and potentially pay for their transactions, as seen in meta-transactions or gasless systems. Failure in this model means user transactions are not broadcast. This introduces a liveness assumption and centralization risk, contrasting with permissionless peer-to-peer (p2p) gossip where users broadcast directly to the network.

An entity that constructs execution payloads by ordering transactions and extracting MEV. Builders send their blocks to relays. A relay failure severs the communication channel between the builder and the validator, causing the builder's work to be lost. This makes relay reliability a direct economic concern for builders, who invest computational resources in block construction.

The underlying peer-to-peer (p2p) propagation layer of a blockchain (e.g., Ethereum's eth network). It is the default, decentralized method for broadcasting transactions and blocks. Relayer-based systems often exist as an overlay atop this network. A full gossip network failure is a more severe, network-wide event, whereas a relayer failure is typically an isolated service outage affecting a specific pipeline like MEV-Boost.