Smart contract audits are incomplete. They validate on-chain logic but ignore the off-chain relayer infrastructure that powers 90% of user transactions. This creates a systemic risk where the validated code is secure, but the execution path is not.
The Cost of Ignoring Relayer Centralization in Your Audit Scope
Audits focus on smart contract logic but ignore the centralized relayers that can censor or reorder transactions. This is a systemic failure in cross-chain security.
Introduction
Audits that ignore relayer infrastructure create a false sense of security, leaving critical transaction execution and value flow vulnerable.
Relayers are the new attack surface. Protocols like Across and Stargate depend on centralized, permissioned relayers for cross-chain messaging and intent settlement. A compromised relayer can censor, front-run, or reorder transactions, bypassing all on-chain safeguards.
The failure is architectural. The industry treats relayers as trusted third parties, not as part of the security perimeter. This is a design flaw that audits, focused solely on bytecode, systematically miss, leaving billions in TVL exposed to a single point of failure.
The Core Argument
Auditing smart contracts while ignoring the relayer layer is a critical architectural oversight that introduces systemic risk.
Relayers are execution oracles. Your smart contract logic depends on their honest, timely, and correct execution of off-chain logic. Ignoring this dependency creates a single point of failure that invalidates on-chain security guarantees.
Your audit scope is incomplete. A contract secured by OpenZeppelin libraries and audited by Trail of Bits remains vulnerable if its intent fulfillment relies on a centralized relayer run by the protocol team. The attack surface shifts from code to infrastructure.
Centralized relayers create liveness risk. Protocols like Across and Socket rely on a permissioned set of relayers for fast, cheap transactions. If these operators are compromised or go offline, the entire cross-chain system halts, regardless of on-chain safety.
Evidence: The Wormhole bridge exploit in 2022 was not a smart contract bug; it was a relayer signature verification failure. The attacker forged VAA signatures because the guardian set's off-chain process was compromised, resulting in a $325M loss.
The Centralization Spectrum: Where Major Bridges Stand
Relayer centralization is the single most common and catastrophic failure vector in cross-chain security, yet remains a footnote in most audits.
The Problem: The Single-Point-of-Failure Relayer
Most bridges rely on a centralized, off-chain relayer to submit transactions. This creates a single signer for billions in TVL. Audits often focus on on-chain contracts, ignoring this off-chain component.\n- Failure Mode: Relayer downtime halts all transfers.\n- Attack Vector: Compromised relayer keys can drain liquidity pools.\n- Reality: This is how the Wormhole and Ronin Bridge hacks ($650M+ combined) occurred.
The Solution: Decentralized Verifier Networks (LayerZero)
Replace the single relayer with a permissionless network of independent Oracles and Relayers. Security derives from the economic security of the underlying chains (e.g., Ethereum) via Proof-of-Delivery.\n- Key Benefit: No single entity can censor or forge messages.\n- Trade-off: Introduces latency and complexity in consensus.\n- Entity Context: This is the core innovation of LayerZero, separating message attestation (Oracle) from delivery (Relayer).
The Hybrid: Optimistic Security (Across, Socket)
Use a centralized relayer for speed, but back it with a fraud-proof window and a decentralized fallback. Users are made whole from a bonded liquidity pool if fraud is proven.\n- Key Benefit: Near-instant UX with decentralized security guarantees.\n- Mechanism: Inspired by Optimistic Rollups; a Watcher network can slash the relayer's bond.\n- Entity Context: Across Protocol uses this model with UMA's Optimistic Oracle, while Socket employs a guard network.
The Illusion: Multi-Sig Upgrades
A bridge with a decentralized relayer but a centralized upgrade mechanism is still centralized. A 5/9 multi-sig controlling the contract is the ultimate backdoor.\n- Key Risk: Governance capture or signer collusion can change bridge logic instantly.\n- Audit Gap: Teams check the current code, not the upgradeability admin.\n- Reality Check: This was the critical failure in the Poly Network hack ($611M).
Attack Vectors Enabled by a Centralized Relayer
A comparison of critical vulnerabilities introduced when a bridge, cross-chain messaging protocol, or intent-based system relies on a single, trusted relayer. This matrix quantifies the failure modes that audits often miss.
| Attack Vector | Single Centralized Relayer | Decentralized Validator Set (e.g., LayerZero) | Fully Permissionless Auction (e.g., Across) |
|---|---|---|---|
Censorship Attack | |||
Transaction Reordering / MEV Extraction | Limited by OApp config | ||
Funds Theft via Malicious Execution | Requires >1/3 stake corruption | Requires solver collusion | |
Protocol Upgrade Unilateral Control | |||
Liveness Failure (Downtime SLA) | Defined by operator |
| Always live via economic incentive |
Data Availability Withholding | |||
Cost of Attack (Theoretical) | Compromise 1 entity | Acquire >1/3 of staked capital | Outbid all solvers + fulfill order |
Recovery Time from Compromise | Indefinite | Governance slashing & replacement (~7 days) | Next block (new solver wins) |
Why Audits Consistently Miss This
Audit scopes are myopically focused on smart contract logic, ignoring the critical off-chain infrastructure that powers user interactions.
Audits define scope narrowly, focusing on on-chain smart contract code like the bridge validator signatures or liquidity pool math. This creates a false sense of security because the live system includes off-chain components.
Relayer logic is off-chain black boxes. The sequencing, batching, and fee logic for protocols like Across and Stargate runs on centralized servers. Auditors never see this code, missing single points of failure.
The threat model is incomplete. A smart contract is secure, but a malicious or compromised relayer can censor, front-run, or extract maximal value from users. This is a systemic risk, not a contract bug.
Evidence: The $325M Wormhole bridge hack originated from a signature validation flaw, but subsequent incidents like LayerZero's paused relayer demonstrate operational risks audits don't cover.
Case Studies: Centralization in Action
Real-world failures where a single point of control in the relayer layer became the protocol's single point of failure.
The Nomad Bridge Hack: A Single Signer's Mistake
A $190M exploit triggered by a routine upgrade where a single, centralized relayer (the 'upgrade proposer') initialized a new bridge contract with a zero-byte trusted root. This wasn't a cryptographic break; it was an operational failure in a centralized control mechanism.
- Root Cause: Centralized upgrade authority with insufficient multi-sig safeguards.
- Impact: Instant, total loss of funds due to a single incorrect parameter.
- Lesson: Relayer governance is as critical as smart contract logic.
PolyNetwork: The Admin Key Compromise
A $611M cross-chain heist made possible because the protocol's multi-sig relayer/keeper system was controlled by a single entity's private keys. The attacker exploited a vulnerability in the contract logic, but the centralized key management allowed them to bypass all security layers.
- Root Cause: Over-centralized key custody for critical relayer functions.
- Impact: Full control over asset movement across Polygon, BSC, and Ethereum.
- Lesson: Key management for relayers must be as decentralized as the chain consensus itself.
Wormhole & LayerZero: The Guardian/Oracle Risk
High-value bridges like Wormhole (19/20 Guardian multisig) and LayerZero (Oracle/Relayer set) rely on a small, permissioned set of entities. While not yet exploited, this creates a systemic risk corridor. A state-level adversary or a collusion event could censor or forge messages for $1B+ in bridged assets.
- Root Cause: Intentional centralization for speed, creating a trusted federation.
- Impact: Creates a censorship and liveness risk for the entire cross-chain ecosystem.
- Lesson: The security budget of a bridge is the collective security of its relayer set.
The Solution: Intent-Based Architectures (UniswapX, Across)
Frameworks like UniswapX and Across Protocol shift risk from centralized relayers to a competitive solver network. Users submit intent-based orders, and a decentralized set of solvers compete to fulfill them, posting bonds.
- Mechanism: Solvers bear the execution risk and capital cost; users get guaranteed outcomes.
- Benefit: Eliminates the single, trusted relayer. Failure is isolated and slashed.
- Trade-off: Introduces MEV and latency competition instead of liveness risk.
The Builder's Defense (And Why It's Wrong)
Protocol architects systematically exclude relayer infrastructure from security audits, creating a critical blind spot.
Audit scope is incomplete. Builders argue their smart contract logic is the only relevant attack surface. This ignores the oracle-relayer dependency that executes cross-chain messages for protocols like LayerZero and Wormhole.
The trusted compute layer. Your protocol's security collapses to the relayer's key management. If a sequencer like Espresso or AltLayer is compromised, your validated state transitions are irrelevant.
Evidence from exploits. The Poly Network and Nomad bridge hacks were not contract bugs but oracle/relayer failures. The industry audits the lockbox but not the armored car service transporting its contents.
FAQ: For Architects and Auditors
Common questions about the systemic risks and audit blind spots created by ignoring relayer centralization.
The primary risks are systemic liveness failure and censorship, not just smart contract bugs. Audits focused solely on code miss the operational risk of a single relayer (e.g., in many rollups or bridges like Wormhole) going offline or censoring transactions, which can freeze billions in assets.
TL;DR: The Auditor's & Builder's Checklist
Relayers are the new single point of failure. Auditing the smart contract is table stakes; ignoring the off-chain execution layer is professional malpractice.
The Oracle Problem, Reborn
Relayers are state oracles. A centralized relayer can censor, reorder, or lie about cross-chain states, breaking the security model of protocols like Chainlink CCIP or Wormhole.\n- Attack Vector: Malicious state attestation can drain bridges securing $10B+ TVL.\n- Audit Gap: Most audits stop at the on-chain verifier, not the off-chain attestation committee.
Sequencer Risk is Now Cross-Chain
Just as Arbitrum or Optimism sequencers can censor L2 txns, a dominant intent solver or bridge relayer (e.g., Across, LayerZero) controls cross-chain flow.\n- Metric to Audit: Relayer market share > 33% is a critical centralization threshold.\n- Builder Mandate: Enforce solver competition via mechanisms like CowSwap's batch auctions or UniswapX's fill competition.
The Economic Abstraction Trap
Users think in terms of 'gasless' UX, but builders must account for the relayer's profit motive. A relayer can frontrun, extract MEV, or fail to subsidize fees during congestion.\n- Checklist Item: Audit the fee model and subsidy backstop.\n- Red Flag: Relayer profitability depends solely on token inflation or unsustainable grants.
Solution: Demand Verifiable Execution
Move beyond trust. Builders must integrate systems that make relayer actions provably correct and punishable.\n- Adopt: Succinct or Herodotus for on-chain proof of off-chain state.\n- Enforce: Slashing conditions for verifiable malfeasance, not just multisig signatures.
Solution: Architect for Relayer Rotation
Design the system so no single relayer is indispensable. This is a core protocol architecture flaw if not addressed.\n- Implement: Permissionless relayership with bond requirements.\n- Benchmark: Latency should not degrade with N>5 active relayers.
The Auditor's New Test Suite
Expand the scope. The final report must include a dedicated Relayer & Operational Security chapter.\n- Quantify: Centralization metrics (HHI, Nakamoto Coefficient) for the relayer set.\n- Simulate: Relayer failure and adversarial scenarios (griefing, censorship) in your threat model.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.