Bridging assets
Treat bridge contracts, finality, liquidity, and emergency controls as a separate security boundary.
A bridge is the user-facing boundary between a rollup and another chain. It is not only a UI flow. Its security depends on contract correctness, finality assumptions, message relaying, asset custody, and the authority allowed to upgrade or pause it. The OP Stack fault-proof documentation illustrates why a withdrawal requires both inclusion evidence and the relevant proof or dispute conditions.
Design questions
- Which finality condition must be met before a deposit or withdrawal is accepted?
- Who can pause, upgrade, or recover the bridge contracts, and how is that authority protected?
- Is liquidity required for fast exits, and what happens when it is exhausted?
- How are failed, delayed, or replayed cross-chain messages detected and reconciled?
Monitor bridge contract events, message queue age, relay failures, contract balance changes, and withdrawal completion time. Document a user-facing incident path before launch; a bridge outage is often perceived as loss of funds even when assets remain recoverable.
Asset and message lifecycle
A bridge operation should be observable across its whole lifecycle: source transaction accepted, source finality reached, message emitted, relay submitted, destination verification completed, and asset minted, released, or made claimable. Give each operation a stable message identifier that support and engineering teams can use across explorers, logs, and dashboards.
For fast bridges or liquidity networks, distinguish canonical settlement from a liquidity-provider promise. A fast exit can complete before the canonical withdrawal path, but its risk, fees, and fallback path must be clear to users.
Administrative controls
| Control | Purpose | Minimum guardrail |
|---|---|---|
| Upgrade authority | Correct defects or add compatible functionality. | Timelock, multisig, audited change process, and published contract addresses. |
| Pause authority | Stop an active exploit or unsafe relay. | Narrow scope, incident owner, and a documented unpause condition. |
| Rate or liquidity limits | Limit loss and congestion exposure. | Alert on utilization and a documented emergency adjustment process. |
| Message recovery | Resolve a failed but valid message. | Evidence requirements, dual review, and an immutable audit trail. |
Exercise a bridge incident drill that pauses a non-production route, verifies user messaging, traces pending messages, and restores service without double-processing an operation.