TL;DR — The 5 Things That Will Get Your Bridge Hacked

1. Weak validator security — Small multisigs, poor key management, no slashing (Ronin: $625M)
2. Missing message validation — Signatures not properly verified, allowing forged mints (Wormhole: $320M)
3. Broken initialization — Faulty contract setup letting anyone pass validation (Nomad: $190M)
4. No circuit breakers — No way to pause when exploits are in progress
5. Insufficient finality checks — Minting before source chain reaches finality

🔐 Interactive Checklist Available

We've created an interactive version of this checklist with expandable details, code examples, and audit checkboxes. Perfect for auditors and dev teams.

→ View the EVM Cross-Chain Bridge Security Checklist

Introduction: Why Bridge Security Is Non-Negotiable

• $625M — Ronin Bridge (March 2022)
• $320M — Wormhole (February 2022)
• $190M — Nomad Bridge (August 2022)
• $100M — Harmony Horizon (June 2022)
• $80M — Orbit Chain (January 2024)

How to Use This Checklist

1. Architecture & Trust Model
2. Message Passing Security
3. Asset Transfer Mechanisms
4. Oracle & Validation Security
5. Economic Security
6. Emergency Mechanisms & Operations
7. Chain-Specific Considerations

• Why it matters — Context and real-world exploit examples
• Security checks — Specific items to verify
• Red flags — Warning signs that indicate vulnerabilities

1. Architecture & Trust Model

Why It Matters

Security Checks

Validator Set Security

• Multi-signature threshold is appropriate — A 2-of-3 multisig is not sufficient for a bridge holding $100M+. Consider threshold signatures (TSS) or higher ratios (e.g., 5-of-9 minimum, with 7-of-11 or higher for large TVL).
• Validator selection is decentralized — Validators should be geographically distributed, organizationally independent, and selected through transparent criteria.
• Key management is hardened — Hardware Security Modules (HSMs), air-gapped signing, and multi-party computation (MPC) for key generation.
• Rotation mechanisms exist — Compromised or inactive validators can be removed and replaced without halting the bridge.
• Slashing conditions are defined — Validators face economic penalties for signing invalid messages or double-signing.

Consensus & Finality

• Finality requirements are chain-appropriate — Ethereum needs ~15 minutes for economic finality; Solana achieves it in seconds. Your bridge must respect each chain's finality guarantees.
• Fork handling is explicit — What happens if a source chain reorganizes after a message is relayed? The bridge must handle this gracefully.
• Byzantine fault tolerance (BFT) assumptions are documented — How many validators can be malicious before the system fails? This should be explicit, not implicit.

Red Flags

• Validator keys stored in cloud environments without HSM protection
• Single organization controlling majority of validator keys
• No slashing mechanism for malicious behavior
• Finality assumptions not documented or tested

2. Message Passing Security

Why It Matters

Security Checks

Message Authentication

• Source chain is cryptographically verified — Messages must be provably from the claimed source chain. This typically requires validator signatures over the message hash, including chain ID.
• Message integrity is guaranteed — Any modification to the message payload must invalidate the message. Use cryptographic hashes and signatures, not just sequence numbers.
• Sender authorization is verified — On the destination chain, verify that the message was sent by an authorized contract on the source chain (trusted remote pattern).

Replay Attack Prevention

• Nonces are implemented per-sender — Each message should have a unique nonce that cannot be reused.
• Cross-chain replay protection exists — A message valid on Chain A should not be replayable on Chain B. Include chain IDs in signed payloads.
• Historical message replay is prevented — An attacker with an old valid message should not be able to re-execute it. Track processed message hashes.

Message Ordering

• Ordering guarantees are defined — Does your bridge guarantee in-order delivery? If yes, enforce it. If no, ensure your application logic handles out-of-order messages.
• Timeout mechanisms exist — Messages should expire after a reasonable period. Stale messages are a security risk.
• Retry logic is safe — Failed messages that are retried should not create double-execution vulnerabilities.

Red Flags

• Message validation relies on msg.sender checks alone (can be spoofed via intermediary contracts)
• No chain ID in signed message payloads
• Nonces that can be predicted or manipulated
• No expiration on cross-chain messages

3. Asset Transfer Mechanisms

Why It Matters

Security Checks

Lock-and-Mint Bridges

• Supply conservation is enforced — The total supply of wrapped tokens across all chains must never exceed the locked collateral on the source chain.
• Mint authority is strictly controlled — Only the bridge contract (verified message receiver) should be able to mint wrapped tokens. No admin mint functions.
• Burn verification is complete — Before unlocking collateral, cryptographically verify that wrapped tokens were burned on the destination chain.
• Accounting is atomic — Lock and mint (or burn and unlock) should be atomic operations that cannot be partially executed.

Liquidity Pool Bridges

• Pool solvency is guaranteed — The bridge should never promise more liquidity than exists. Implement checks before transfers.
• Slippage protection is enforced — Large transfers should not drain pools or cause excessive slippage. Implement per-transaction and per-epoch limits.
• Rebalancing is secure — If the bridge rebalances liquidity across chains, ensure this mechanism cannot be exploited for arbitrage at the protocol's expense.

Token Handling

• Fee-on-transfer tokens are handled — Tokens that take a fee on transfer will cause accounting mismatches. Either block them or measure actual received amounts.
• Rebasing tokens are handled — Tokens that change balance automatically (like stETH) require special accounting logic.
• Token decimals are normalized — Different chains may represent the same token with different decimal places. Ensure conversions are correct.
• Native token (ETH/MATIC/etc.) handling is explicit — Wrapping and unwrapping logic must be bulletproof.

Red Flags

• Mint functions callable by anyone (even with checks, this is high-risk)
• No supply cap enforcement on wrapped tokens
• Manual rebalancing by admin keys
• Token transfers using transfer() instead of safeTransfer() patterns

4. Oracle & Validation Security

Why It Matters

Security Checks

Oracle Integration

• Oracle manipulation resistance is verified — If using price oracles, ensure they're resistant to flash loan manipulation. Use TWAPs or multiple oracle sources.
• Oracle liveness is monitored — Stale oracle data is dangerous. Implement heartbeat checks and fallback mechanisms.
• Cross-chain price consistency is verified — Asset prices should be consistent across chains. Large discrepancies may indicate manipulation.

Light Client Security

• Block header verification is complete — If using light clients, verify entire header validity, not just selected fields.
• State proofs are validated — Merkle proofs must be fully validated against verified block headers.
• Client updates are secure — Light client update mechanisms should require sufficient validator signatures and not be susceptible to eclipse attacks.

Relayer Network

• Relayer censorship resistance exists — Multiple independent relayers should be able to relay messages. No single relayer should be able to censor.
• Relayer incentives are aligned — Relayers should be economically motivated to deliver messages promptly and honestly.
• Failed relay handling is defined — What happens if no relayer picks up a message? Users should have recourse.

Red Flags

• Single oracle source for critical price data
• Light client that can be updated by a small number of keys
• Single relayer with no fallback mechanism
• No monitoring for oracle/relayer liveness

5. Economic Security

Why It Matters

Security Checks

Attack Cost Analysis

• Cost to corrupt validators > TVL — The economic cost to compromise enough validators to steal funds should exceed the funds at risk.
• Slashing exceeds potential profit — Malicious validators should lose more than they could gain from an attack.
• Time-locked withdrawals for large amounts — Large withdrawals should have a delay period, giving time to detect and respond to attacks.

Fee Mechanisms

• Fees cover operational costs — Relayer gas, validator infrastructure, and security monitoring all cost money. Fees should be sustainable.
• Fee calculation is manipulation-resistant — Attackers should not be able to manipulate fee calculations to drain funds or grief users.
• Fee tokens are validated — If fees can be paid in multiple tokens, ensure all are properly validated and valued.

MEV Protection

• Front-running resistance exists — Cross-chain arbitrage opportunities created by the bridge should not be extractable by front-runners at user expense.
• Sandwich attack protection — Large transfers should be protected from sandwich attacks on either chain.
• Sequencer/validator MEV is considered — On L2s or chains with centralized sequencers, consider how sequencer MEV affects bridge users.

Red Flags

• TVL significantly exceeds validator stake at risk
• No withdrawal delays for large amounts
• Fees paid in unvalidated or easily manipulated tokens
• No consideration of MEV in bridge design

6. Emergency Mechanisms & Operations

Why It Matters

Security Checks

Circuit Breakers

• Pause functionality exists — The bridge can be paused quickly in an emergency. This should require minimal signers (e.g., 1-of-N guardians).
• Per-chain pause is possible — If one chain is compromised, you should be able to pause just that chain without affecting others.
• Volume-based limits exist — Automatic rate limiting when unusual volumes are detected. Slow down potential exploits.
• Velocity controls exist — Limit the speed at which funds can leave the bridge, even for legitimate transactions.

Recovery Mechanisms

• Asset recovery procedures are documented — How do you recover funds stuck in the bridge due to bugs or failed transactions?
• State synchronization after incidents — If the bridge pauses mid-operation, how do you reconcile state across chains?
• User compensation mechanisms exist — If users lose funds due to bridge issues, how are they compensated?

Operational Security

• Key management follows best practices — Multi-party computation, hardware security modules, geographic distribution.
• Access control is principle of least privilege — Each role should have only the permissions it needs.
• Monitoring and alerting is comprehensive — Real-time monitoring for unusual activity, with automated alerts.
• Incident response plan exists — Documented procedures for common incident types, with clear roles and communication channels.

Red Flags

• No pause functionality or pause requires too many signers
• No rate limiting or volume caps
• All admin keys held by same entity/location
• No documented incident response plan

7. Chain-Specific Considerations

EVM Chains

• Gas limit differences are handled — Transaction gas limits vary by chain. Ensure cross-chain calls won't fail due to gas limits.
• Block time differences are accounted for — Confirmation requirements should be based on finality, not block count.
• Precompile availability is verified — Some EVM chains lack certain precompiles. Verify cryptographic operations work on all target chains.
• EIP compatibility is confirmed — Different EVM chains support different EIPs. Verify your contracts work on all targets.

Non-EVM Chains (Solana, Cosmos, etc.)

• Account model differences are handled — UTXO vs. account-based models require different security considerations.
• Signature schemes are compatible — Ed25519 vs. secp256k1 — ensure signature verification works across chains.
• Finality models are understood — Probabilistic vs. deterministic finality requires different confirmation strategies.
• Program/contract upgrade patterns differ — Understand how upgrades work on each chain and secure accordingly.

L2 Specific

• Sequencer trust assumptions are documented — Centralized sequencers can censor or reorder transactions.
• Withdrawal delays are accounted for — Optimistic rollups have 7-day withdrawal windows. Your bridge UX must account for this.
• L1 fallback exists — If the L2 sequencer goes down, users should be able to exit via L1.

LayerZero Integration Checklist

Endpoint Configuration

• Trusted remotes are correctly configured — Each chain's contract must explicitly trust the correct contract addresses on other chains.
• Pathway configuration is minimal — Only enable the pathways (chain pairs) you actually need.
• Library versions are pinned — Don't auto-upgrade to new LayerZero libraries without auditing changes.

Message Handling

• lzReceive cannot be called directly — Only the LayerZero endpoint should be able to call your receive function.
• Gas forwarding is bounded — Don't forward unlimited gas to destination calls. Implement caps.
• Failed messages are handled — Implement nonblockingLzReceive pattern to prevent one failed message from blocking all subsequent messages.
• Adapter parameters are validated — Custom adapter parameters should be validated to prevent gas manipulation attacks.

OFT (Omnichain Fungible Token) Specific

• Shared decimals are consistent — OFT uses shared decimals for cross-chain accounting. Ensure consistency.
• Rate limiting is implemented — Large transfers should trigger rate limits to prevent rapid drainage.
• Credit system is understood — Understand how LayerZero's credit system works and its implications for your token.

Chainlink CCIP Integration Checklist

Router Configuration

• Supported chains are validated — CCIP only supports specific chain pairs. Verify your chains are supported.
• Fee token is approved — LINK or native token must be approved for fee payment.
• Gas limits are appropriately set — Destination gas limits must be sufficient for your callback logic.

Message Processing

• ccipReceive is properly protected — Only the CCIP Router should be able to call this function.
• Message validation is complete — Verify source chain, sender address, and message contents.
• Rate limits are configured — CCIP supports rate limiting — configure appropriate limits for your use case.
• Out-of-order execution is handled — CCIP does not guarantee message ordering. Your logic must handle this.

Testing Your Bridge

Unit Tests

• Message encoding/decoding edge cases
• Fee calculation with various token types
• Access control for all privileged functions
• Pause and unpause functionality

Integration Tests

• Full round-trip transfers (source → destination → source)
• Failed message handling and retry logic
• Multi-chain state consistency
• Upgrade procedures on all chains

Adversarial Tests

• Replay attack attempts
• Message forgery attempts
• Validator collusion scenarios
• Economic attacks (e.g., draining liquidity pools)

Chaos Testing

• Network partitions between validators
• Chain reorganizations during pending transfers
• Validator node failures
• High-latency network conditions

Before You Launch: Final Checklist

• Multiple independent audits completed — At least two audits from reputable firms, with all findings addressed.
• Bug bounty program launched — Incentivize white-hat hackers to find vulnerabilities before black-hats do.
• Monitoring and alerting operational — Real-time visibility into bridge operations with automated alerts.
• Incident response team identified — Named individuals with clear responsibilities and communication channels.
• Graduated rollout planned — Start with low TVL caps and increase gradually as confidence builds.
• Insurance or user protection fund considered — How will affected users be made whole if something goes wrong?

Conclusion: Build Bridges That Last

Get in Touch

Additional Resources

• Rekt News - Bridge Hacks — Post-mortems of major bridge exploits
• LayerZero Documentation — Official LayerZero integration guides
• Chainlink CCIP Documentation — Official CCIP documentation
• L2Beat - Bridge Risk Analysis — Risk assessments for major bridges
• Zealynx DeFi Upskill Repository — Extended security checklists and audit resources

FAQ: Cross-Chain Bridge Security

Glossary