Specify a cross-chain bridge with message passing, asset transfer mechanics, security models, and fallback procedures for safe interoperability between blockchains.
## ROLE You are a cross-chain infrastructure architect who designs bridge protocols connecting different blockchains. You understand the security tradeoffs between different bridge architectures, the history of bridge exploits (Wormhole, Ronin, Nomad), and how to design systems that prioritize security over convenience. ## OBJECTIVE Specify a cross-chain bridge connecting [CHAIN A: e.g., Ethereum] and [CHAIN B: e.g., Arbitrum/Solana/Cosmos] for [USE CASE: e.g., token transfers, general message passing, liquidity unification] with a security model of [MODEL: e.g., optimistic, ZK-proven, validator set, canonical rollup bridge]. ## TASK ### Bridge Architecture - Lock and mint: lock tokens on source chain, mint synthetic on destination - Burn and unlock: burn synthetic on destination, unlock original on source - Liquidity network: liquidity pools on both chains, no synthetic tokens needed - Message passing: arbitrary data relay between chains for cross-chain contract calls - ZK bridge: zero-knowledge proof of source chain state verified on destination - Architecture selection rationale based on security requirements and use case ### Security Model #### Trust Assumptions - Validator set: who validates cross-chain messages and how are they selected - Threshold: how many validators must agree (e.g., 2/3, 3/5, 5/8) - Economic security: total value staked by validators as deterrent against misbehavior - Slashing: penalties for validators who sign invalid messages - Key management: how validator keys are generated, stored, and rotated #### Verification Methods - Optimistic: messages assumed valid, challenged during dispute window (7-14 days) - Multisig: N-of-M validator signatures required for message validity - ZK proof: cryptographic proof of source chain consensus verified on destination - Light client: destination chain runs light client of source chain, verifying headers - Canonical: rollup-native bridge using the rollup's own security guarantees ### Asset Transfer Flow 1. User initiates transfer on source chain: specify amount, destination address, target chain 2. Source contract: locks or burns tokens, emits cross-chain message event 3. Relayer/validator: observes source chain event, signs attestation 4. Destination contract: verifies attestation(s), mints or releases tokens to user 5. Confirmation: user receives tokens on destination chain - Include timing estimates for each step - Define retry and fallback procedures for each failure point ### Message Passing Protocol - Message format: standardized structure for cross-chain messages (nonce, source, destination, payload, fee) - Message ordering: guaranteed ordered delivery or best-effort with nonce-based replay protection - Message size limits: maximum payload size and gas limits for destination execution - Fee structure: how cross-chain messaging fees are calculated and paid - Callback support: destination chain can send response back to source chain ### Failure Handling - Relayer failure: what happens if no relayer picks up a message within the timeout - Validator failure: protocol behavior when validators go offline - Destination revert: how to handle failed execution on the destination chain - Chain reorganization: handling reorgs that invalidate already-relayed messages - Stuck transactions: user-initiated recovery process for failed transfers - Emergency pause: circuit breaker to halt all bridge operations during active exploits ### Rate Limiting and Risk Management - Transfer limits: maximum single transfer and daily aggregate limits - Rate limiting: slow down transfers during unusual activity patterns - Anomaly detection: automated monitoring for suspicious bridge activity - Insurance fund: reserve fund to cover losses from potential exploits - Graduated limits: higher limits for established tokens, lower for new assets ### Smart Contract Design - Source chain contracts: token vault/escrow, message dispatcher, fee collector - Destination chain contracts: token minter, message receiver, verification logic - Upgrade mechanism: how contracts are upgraded on each chain (coordinated upgrade) - Gas estimation: cross-chain gas estimation for destination chain execution - Composability: how other protocols can trigger cross-chain actions through the bridge ### Monitoring and Operations - Real-time dashboard: bridge TVL, message queue, validator health, transfer status - Alert system: anomaly detection, large transfer alerts, validator downtime - Incident response: runbook for different failure scenarios - Regular security reviews: quarterly audits, continuous monitoring, bug bounty - Performance metrics: average transfer time, success rate, cost per transfer ## OUTPUT FORMAT Complete bridge specification with architecture design, security model, transfer flow diagrams, failure handling procedures, and operational monitoring plan. ## CONSTRAINTS - Bridge security should not rely on a small number of trusted validators - Always include emergency pause capability with clearly defined trigger conditions - Rate limits and transfer caps are essential for limiting exploit damage - Include lessons from historical bridge exploits in the security design - Cross-chain timing assumptions must account for chain-specific finality periods
Or press ⌘C to copy