Cross-Chain Bridge Contract

## ROLE
You are a cross-chain infrastructure engineer who has built and audited bridge protocols. You understand the security tradeoffs between trusted, optimistic, and zero-knowledge bridge designs and have studied every major bridge exploit in DeFi history.

## OBJECTIVE
Design a cross-chain bridge for [PROTOCOL NAME] connecting [SOURCE CHAIN] to [DESTINATION CHAIN] supporting [TOKEN TYPES: ERC-20, ERC-721, native tokens] with [BRIDGE TYPE: lock-and-mint, burn-and-mint, liquidity pool].

## TASK

### Bridge Architecture
- Bridge type selection: lock-and-mint vs liquidity network with security tradeoff analysis
- Message passing: how cross-chain messages are transmitted and verified
- Finality handling: waiting for source chain finality before releasing on destination
- Canonical vs wrapped tokens: when to create wrapped tokens vs use existing canonical tokens
- Multi-chain hub: architecture that scales to N chains without N^2 pair contracts

### Source Chain Contract
- Lock function: deposit tokens and emit bridge event with destination chain and recipient
- Burn function: for wrapped tokens being bridged back to their native chain
- Deposit tracking: nonce-based sequential deposit IDs for ordering and replay prevention
- Fee collection: bridge fee in native token or bridged token with configurable rates
- Batch deposits: allow multiple tokens in a single bridge transaction

### Destination Chain Contract
- Mint function: create wrapped tokens upon valid cross-chain message verification
- Unlock function: release locked native tokens for return bridges
- Message verification: validator signatures, merkle proofs, or ZK proofs
- Rate limiting: maximum mint per time period to limit damage from compromises
- Nonce tracking: prevent replay attacks with sequential nonce verification

### Validator Network
- Validator set: N-of-M multi-sig or threshold signature scheme (TSS)
- Validator rotation: how validators are added, removed, and rotated
- Slashing conditions: penalties for validators who sign invalid messages
- Liveness requirements: timeout handling for non-responsive validators
- Economic security: validator stake must exceed bridge TVL for rational security

### Security Measures
- Fraud proofs: optimistic bridge with challenge period for contested messages
- Rate limiting: per-token and aggregate limits on bridge throughput
- Emergency shutdown: guardian multi-sig can pause bridge operations immediately
- Fund recovery: process for recovering funds stuck in failed bridge transactions
- Monitoring: on-chain watchtower contracts that detect anomalous activity

### Operational Concerns
- Gas estimation: accurate cross-chain gas cost prediction and prepayment
- Stuck transactions: timeout and refund mechanism for unprocessed bridges
- Token registry: mapping between source and destination token addresses
- Upgrade path: how to upgrade bridge contracts without disrupting pending transactions
- Analytics: comprehensive event emission for bridge explorer frontends

## OUTPUT FORMAT
Complete bridge architecture document with source and destination contracts, validator protocol, security analysis, and operational runbook.

## CONSTRAINTS
- Bridge must survive single validator compromise without fund loss
- Maximum bridge time must be defined and guaranteed (or refund triggered)
- All bridge operations must be reversible in case of detected fraud
- Include post-mortem analysis framework for security incidents
- Design must account for chain reorganizations on both source and destination