smom-dbis-138/docs/bridge/trustless/SECURITY.md

Trustless Bridge Security Model

Security Assumptions

The trustless bridge system relies on economic security and cryptographic verification rather than trusted third parties or governance. The security model is based on:

1. Economic Incentives: Fraud is economically unprofitable due to bond requirements
2. Cryptographic Proofs: Claims are verified against source chain state
3. Permissionless Participation: Multiple relayers and challengers reduce centralization risk

Economic Security

Bond Mechanism

• Bond Size: 110% of deposit amount (minimum 1 ETH)
• Rationale: Ensures bond exceeds potential profit from fraud
• Formula: bondAmount = max(depositAmount * 1.1, 1 ETH)

Slashing Mechanism

• Slash Condition: Fraudulent claim challenged and proven
• Split: 50% to challenger, 50% burned (sent to address(0))
• Incentive: Challengers earn rewards for detecting fraud
• Disincentive: Relayers lose bond if fraudulent

Economic Attack Scenarios

Scenario 1: Relayer Submits Fraudulent Claim

Attack: Relayer claims deposit doesn't exist on source chain

Defense:

• Challenger detects fraud and submits challenge
• Bond is slashed (110% of deposit lost)
• Fraud is unprofitable: cost (bond) > profit (deposit)

Result: Attack fails economically

Scenario 2: Collusion Between Relayer and Challenger

Attack: Relayer and challenger collude to share slashed bond

Defense:

• Only 50% goes to challenger, 50% is burned
• Relayer still loses 110% of deposit
• Net loss: 60% of deposit (even with collusion)

Result: Attack is still unprofitable

Scenario 3: Large Deposit Attack

Attack: Attacker tries to claim large non-existent deposit

Defense:

• Bond requirement scales with deposit amount (110%)
• Larger deposits require larger bonds
• Economic unprofitability remains regardless of deposit size

Result: Attack fails at any scale

Cryptographic Security

Deposit ID Generation

Deposit IDs are generated using:

depositId = keccak256(asset, amount, recipient, nonce, msg.sender, block.timestamp, block.number)

Properties:

• Unique per deposit
• Includes timestamp and block number
• Prevents replay attacks
• Cannot be predicted or manipulated

Replay Protection

• Nonces per user prevent duplicate deposits
• Processed deposit tracking prevents double-processing
• Deposit IDs ensure uniqueness

Fraud Proofs (Future)

Future implementations will use:

• Merkle Proofs: Verify deposit existence/non-existence in source chain state
• Light Clients: Trustless verification of source chain state
• ZK Proofs: Zero-knowledge proofs for state transitions

Operational Security

Permissionless Participation

• Relayers: Anyone can become a relayer
• Challengers: Anyone can challenge claims
• Liquidity Providers: Anyone can provide liquidity

Benefit: Reduces centralization risk, no single point of failure

Challenge Window

• Duration: 30 minutes (configurable)
• Purpose: Allow time for fraud detection
• Trade-off: Longer window = more security, slower finality

Rate Limiting

• Per Relayer: Max claims per epoch (e.g., 100 per hour)
• Purpose: Prevent spam and bound tail risk
• Configurable: Adjustable based on network capacity

Risk Analysis

Risk: Smart Contract Bugs

Mitigation:

• Comprehensive unit and integration tests
• Security audit (recommended before mainnet)
• Gradual rollout with testnet deployment first
• Bug bounty program (recommended)

Risk: Liquidity Pool Depletion

Mitigation:

• Minimum liquidity ratio enforcement (110%)
• LP withdrawals blocked if below ratio
• Multiple LPs can provide liquidity
• Economic incentives for LPs (fees)

Risk: Chain Reorganization

Mitigation:

• Use finality checkpoints on source chain
• Challenge window provides buffer
• Merkle proofs include block hash (future)

Risk: DEX Slippage

Mitigation:

• amountOutMin parameter protects users
• Uniswap V3 provides deep liquidity
• Multiple DEX options (Uniswap, Curve, 1inch)

Risk: Economic Attacks

Mitigation:

• Bond sizing ensures unprofitability
• Slashing mechanism disincentivizes fraud
• Multiple challengers reduce collusion risk

Known Limitations

1. Fraud Proof Implementation: Currently placeholder - needs actual Merkle proof verification
2. Light Client: Not yet integrated - relies on RPC nodes for verification
3. Challenge Window: Fixed duration - doesn't adapt to network conditions
4. Bond Sizing: Fixed multiplier - could be dynamic based on risk
5. Relayer Fees: Currently none - may reduce relay incentives

Recommendations

Before Mainnet Deployment

1. Security Audit: Comprehensive audit by reputable firm
2. Testnet Deployment: Extended testing on testnets
3. Bug Bounty: Launch bug bounty program
4. Gradual Rollout: Start with small deposit limits, increase over time
5. Monitoring: Set up comprehensive monitoring and alerting

Ongoing Operations

1. Monitor Events: Track all key events (deposits, claims, challenges)
2. Liquidity Management: Monitor pool balances and ratios
3. Economic Analysis: Track bond amounts, slashing events, challenge rates
4. Performance Metrics: Monitor relay times, challenge rates, swap success rates

Incident Response

If Fraud Detected

1. Challenger submits challenge with fraud proof
2. Bond is automatically slashed
3. Claim is reverted
4. Challenger receives 50% reward
5. Monitor for patterns indicating systemic issues

If Smart Contract Bug Discovered

1. Pause system (if pause mechanism exists)
2. Assess impact and scope
3. Deploy fix (if possible)
4. Reimburse affected users (if needed)
5. Post-mortem and improvements

If Liquidity Crisis

1. Monitor pool ratios
2. Encourage additional LP deposits
3. Temporarily increase minimum ratio (if mechanism exists)
4. Consider emergency withdrawals (if needed)