Exchange and Custodian Incident Response Playbook

When the Linea sequencer stops producing blocks, all L2 transaction inclusion ceases immediately. Operational Impact: User deposits from L1 to L2 will not be processed by the bridge relayer. Withdrawals initiated before the halt will remain in the pending queue. Procedure: Immediately halt crediting of all Linea L2 deposits. Display a clear warning in your UI that the network is not processing transactions. Do not broadcast new withdrawal initiations on L2, as they will not be included in a batch. Monitor the official Linea status page and block explorer for the first new block. After the sequencer restarts, wait for 10 confirmed L2 blocks before resuming normal deposit crediting to mitigate any chain reorganization risk.

A bridge pause, typically enacted by the Security Council, freezes the canonical message relay between L1 and L2. Operational Impact: L1-to-L2 deposits are stuck in the bridge contract. L2-to-L1 withdrawal proofs cannot be submitted to the L1 bridge for finalization. Procedure: Immediately suspend all deposit and withdrawal processing. Reconcile your internal ledger against the last finalized L1 state. For pending withdrawals, do not credit users until the bridge is unpaused and the Merkle proof has been successfully submitted and confirmed on L1. For pending deposits, inform users their funds are safe in the bridge contract and will be processed upon resumption. Monitor the Security Council's multisig for the unpause transaction.

A chain reorganization on Linea, while rare, can invalidate previously confirmed L2 blocks. Operational Impact: Deposits credited based on a now-orphaned block may be reversed. Withdrawals initiated in an orphaned block will not be finalizable on L1. Procedure: Your system must detect a reorg by monitoring for a drop in the block_number from your connected RPC node. Upon detection, immediately freeze all Linea operations. Re-index the canonical chain from the last known-good block before the reorg depth. Re-process all deposit and withdrawal events against the new canonical history. Reverse any internal credits for deposits that are no longer in the canonical chain. Wait for a number of confirmations equal to your risk tolerance plus the maximum observed reorg depth before unfreezing operations.

If the prover stalls, L2 batches will not be proven on L1, halting all finality. Operational Impact: L2-to-L1 withdrawals will remain in a 'pending' state indefinitely, as their Merkle proof cannot be verified against a proven state root on L1. L2 transactions are confirmed on L2 but not finalized on L1. Procedure: Do not treat L2 confirmation as final for high-value withdrawals. Extend your withdrawal SLA timelines and communicate the delay proactively. Your system should track the provenBatchId on the L1 LineaRollup contract. If it stops incrementing for a predefined threshold (e.g., 1 hour), trigger an alert and switch withdrawal processing to a 'delayed' mode. Do not credit users for withdrawals until the corresponding batch is proven and the Merkle proof is verified on L1.

After normal operations resume, a rigorous reconciliation process is mandatory to ensure ledger integrity. Procedure: Run a full audit comparing your internal deposit and withdrawal records against on-chain events from the canonical bridge contracts and L2 block history. Identify any discrepancies caused by reorgs, failed message relays, or manual interventions. Generate a report detailing the incident timeline, the total value and number of affected transactions, and the final resolved state for each. For any transaction that could not be automatically reconciled, create a manual remediation ticket. This report serves as an immutable record for compliance, customer support, and post-mortem analysis with Chainscore Labs to harden your integration against future events.

Use the official Linea status page as the first external signal for degraded network service, RPC availability, bridge disruption, or other acknowledged operational incidents. Exchanges and custodians should map status-page component changes to internal severity levels: for example, degraded block production may trigger deposit confirmation delays, while bridge disruption may trigger withdrawal queuing or temporary suspension. Do not rely on the status page alone for crediting decisions; pair it with independent RPC, explorer, and L1 settlement checks before reopening flows.

Keep the Linea documentation bookmarked in the exchange runbook for finality assumptions, bridge behavior, network configuration, and developer-facing integration details. During a bridge pause, prover delay, or message relay anomaly, operations teams should verify whether the issue affects L1-to-L2 deposits, L2-to-L1 withdrawals, or both directions. Custody teams should also confirm whether their asset support depends on the canonical bridge, a third-party bridge, or an application-specific contract path before issuing broad customer notices.

Monitor the Linea GitHub repository for protocol implementation changes, release notes, operational fixes, and security-relevant commits that may explain incident behavior or recovery requirements. Infrastructure teams should not auto-upgrade production nodes during an incident without change-control approval, but they should track repository activity to identify whether a client, prover, contract, or configuration update is part of the remediation path. Archive links to relevant issues, pull requests, or releases in the internal incident record for postmortem traceability.

Use Linea explorers and independent RPC providers to confirm whether blocks are advancing, transaction receipts are consistent, deposits are visible, and withdrawal messages are progressing. A single RPC endpoint can return stale or inconsistent data during provider outages, so exchange systems should compare block height, latest block timestamp, transaction status, and receipt logs across at least two sources. For customer support, explorer links should be treated as evidence of inclusion, not proof of final settlement, until the exchange’s Linea finality policy is satisfied.

Follow Linea’s official public communications for incident acknowledgements, recovery updates, and ecosystem advisories that may not immediately appear in documentation. Incident commanders should separate official protocol communications from market commentary, community rumors, and third-party bridge announcements. When drafting customer notices, reference only confirmed facts: affected services, whether deposits or withdrawals are paused, what users should avoid doing, and when the next update will be provided. Avoid promising recovery times unless Linea has provided a clear remediation timeline.

Because Linea settlement, bridge finality, and proof publication depend on Ethereum L1, exchanges should monitor Ethereum finality, gas conditions, and L1 transaction inclusion during Linea incidents. A Linea bridge delay may originate from prover backlog, relayer behavior, L1 congestion, or Ethereum finality instability. Treasury and custody teams should tag incidents by dependency layer so that customer communications do not misclassify an Ethereum-side settlement delay as a Linea-only outage. Reopening withdrawals should require both Linea-side recovery and successful L1 confirmation of the relevant bridge or settlement transactions.