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:
```solidity
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)