# Challenge Window Documentation ## Overview This document describes the challenge window mechanism for the trustless bridge system, including rationale, duration, and optimization recommendations. ## Current Challenge Window ### Duration - **Default**: 30 minutes (1800 seconds) - **Configurable**: Set during contract deployment - **Immutable**: Cannot be changed after deployment ### Purpose 1. **Fraud Detection**: Allow time for challengers to detect fraud 2. **Proof Generation**: Time to generate fraud proofs 3. **Network Finality**: Buffer for network finality 4. **User Experience**: Balance security with speed ## Window Analysis ### Too Short (< 5 minutes) **Risks**: - Insufficient time for fraud detection - Challengers may miss fraudulent claims - Reduced security **Benefits**: - Faster finalization - Better user experience ### Optimal (5-30 minutes) **Benefits**: - Sufficient time for fraud detection - Good balance of security and speed - Standard for optimistic systems **Current**: 30 minutes is in optimal range ### Too Long (> 1 hour) **Risks**: - Poor user experience - Unnecessary delays - Reduced competitiveness **Benefits**: - Maximum security - More time for fraud detection ## Factors Affecting Window ### 1. Block Time - Ethereum: ~12 seconds average - 30 minutes = ~150 blocks - Sufficient for finality ### 2. Fraud Detection Time - Average: 5-10 minutes - Maximum: 15-20 minutes - 30 minutes provides buffer ### 3. Gas Price Volatility - High gas = slower transactions - May need longer window during congestion - Current window accounts for normal conditions ### 4. User Experience - Users expect < 1 hour total time - 30 minutes window + finalization = acceptable - Balance security with UX ## Optimization Recommendations ### Dynamic Challenge Window Consider dynamic window based on: - Network congestion - Gas prices - Historical challenge patterns - Deposit amount ### Adaptive Window ``` baseWindow = 30 minutes if gasPrice > threshold: window = baseWindow * 1.5 # 45 minutes elif depositAmount > largeThreshold: window = baseWindow * 1.2 # 36 minutes else: window = baseWindow # 30 minutes ``` ### Analysis Tool Use `scripts/bridge/trustless/analyze-challenge-window.py` to analyze optimal window duration for different scenarios. ## Security Considerations ### Minimum Window - Should allow time for fraud detection - Account for network delays - Consider gas price volatility ### Maximum Window - Balance with user experience - Avoid unnecessary delays - Monitor user feedback ## References - Challenge Manager: `contracts/bridge/trustless/ChallengeManager.sol` - Analysis Tool: `scripts/bridge/trustless/analyze-challenge-window.py` - Security Model: `docs/bridge/trustless/SECURITY.md`