|
| 1 | +# Meta-TX Replay Attack Fix - Quick Reference |
| 2 | + |
| 3 | +## 🎯 What Was Fixed |
| 4 | + |
| 5 | +The Meta-TX Example contract had a **replay attack vulnerability** where the same transaction could be executed multiple times. This implementation adds comprehensive protection. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## 🔒 Protection Mechanisms |
| 10 | + |
| 11 | +### 1. **Nonce-Based Protection** |
| 12 | +Each user has an independent nonce that increments with each transaction. |
| 13 | +```solidity |
| 14 | +mapping(address => uint256) public nonces; |
| 15 | +``` |
| 16 | +- Prevents reusing old signatures |
| 17 | +- Makes each signature unique |
| 18 | +- Enables sequential transaction ordering |
| 19 | + |
| 20 | +### 2. **Used Signature Tracking** |
| 21 | +Executed signatures are marked as used to prevent exact replay. |
| 22 | +```solidity |
| 23 | +mapping(bytes32 => bool) public usedSignatures; |
| 24 | +``` |
| 25 | +- Prevents the exact same signature from being replayed |
| 26 | +- Works as a second line of defense |
| 27 | + |
| 28 | +### 3. **Domain Separator (Chain ID)** |
| 29 | +Includes the chain ID in the signature domain. |
| 30 | +```solidity |
| 31 | +domain = { |
| 32 | + chainId: <current_chain_id>, |
| 33 | + ... |
| 34 | +} |
| 35 | +``` |
| 36 | +- Prevents cross-chain replay attacks |
| 37 | +- Each chain has a different domain separator |
| 38 | +- Signature valid only on its original chain |
| 39 | + |
| 40 | +### 4. **Deadline Validation** |
| 41 | +Signatures have an expiration time. |
| 42 | +```solidity |
| 43 | +require(block.timestamp <= deadline, "Signature expired"); |
| 44 | +``` |
| 45 | +- Prevents old signatures from being executed |
| 46 | +- Time-bounds transaction validity |
| 47 | +- Gives users time window to revoke intent |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +## 🧪 Test Coverage |
| 52 | + |
| 53 | +| Category | Tests | Key Coverage | |
| 54 | +|----------|-------|--------------| |
| 55 | +| **Domain & Nonce** | 3 | Domain separator, nonce initialization | |
| 56 | +| **Signature Verification** | 3 | Valid/invalid/expired signatures | |
| 57 | +| **Replay Prevention** | 4 | Same signature, old nonce, sequential ops | |
| 58 | +| **Cross-Chain** | 2 | Chain ID in domain, different chains | |
| 59 | +| **ERC2771** | 1 | Context integration | |
| 60 | +| **Validation** | 2 | Zero address, zero amount | |
| 61 | +| **Nonce Management** | 4 | Increment, independence, events | |
| 62 | +| **Service Tests** | 16 | EIP-712, verification, environment | |
| 63 | +| **Fuzz Tests** | 11 | Invariants, properties | |
| 64 | +| **Total** | **49+** | Comprehensive coverage | |
| 65 | + |
| 66 | +--- |
| 67 | + |
| 68 | +## 📋 Example Flow |
| 69 | + |
| 70 | +### 1. User initiates transfer (off-chain) |
| 71 | +```javascript |
| 72 | +const transferData = { |
| 73 | + from: userAddress, |
| 74 | + to: recipientAddress, |
| 75 | + amount: ethers.parseEther("10"), |
| 76 | + nonce: 0, // Current nonce |
| 77 | + deadline: Math.floor(Date.now() / 1000) + 3600 // 1 hour |
| 78 | +}; |
| 79 | +``` |
| 80 | + |
| 81 | +### 2. User signs with wallet (off-chain) |
| 82 | +```javascript |
| 83 | +const signature = await userWallet.signTypedData( |
| 84 | + domain, // Includes chainId, contractAddress |
| 85 | + types, // Transfer type definition |
| 86 | + value // transferData |
| 87 | +); |
| 88 | +``` |
| 89 | + |
| 90 | +### 3. Relayer submits transaction (on-chain) |
| 91 | +```javascript |
| 92 | +await metaTxContract.executeTransfer( |
| 93 | + userAddress, |
| 94 | + recipientAddress, |
| 95 | + amount, |
| 96 | + deadline, |
| 97 | + signature |
| 98 | +); |
| 99 | +``` |
| 100 | + |
| 101 | +### 4. Contract validates (on-chain) |
| 102 | +- ✅ Deadline not expired |
| 103 | +- ✅ Signature recovers to userAddress |
| 104 | +- ✅ Nonce matches current nonce |
| 105 | +- ✅ Signature digest not already used |
| 106 | +- ✅ Execute transfer |
| 107 | +- ✅ Increment nonce |
| 108 | +- ✅ Mark signature as used |
| 109 | + |
| 110 | +--- |
| 111 | + |
| 112 | +## 🚨 Attack Scenarios Prevented |
| 113 | + |
| 114 | +### Scenario 1: Exact Replay |
| 115 | +**Attack**: Submit same signature twice |
| 116 | +**Protection**: `usedSignatures` mapping marks signature as used after first execution |
| 117 | + |
| 118 | +### Scenario 2: Nonce Manipulation |
| 119 | +**Attack**: Reorder transactions by re-executing old signatures |
| 120 | +**Protection**: Nonce is part of signature, old nonces won't verify |
| 121 | + |
| 122 | +### Scenario 3: Cross-Chain Replay |
| 123 | +**Attack**: Use signature from Chain A on Chain B |
| 124 | +**Protection**: Chain ID in domain separator makes signatures chain-specific |
| 125 | + |
| 126 | +### Scenario 4: Deadline Bypass |
| 127 | +**Attack**: Execute signature months later |
| 128 | +**Protection**: Deadline validation rejects expired signatures |
| 129 | + |
| 130 | +### Scenario 5: Sequential Manipulation |
| 131 | +**Attack**: Execute transaction 2 then transaction 1 |
| 132 | +**Protection**: Nonce must match current nonce for verification |
| 133 | + |
| 134 | +--- |
| 135 | + |
| 136 | +## 🔍 Key Functions |
| 137 | + |
| 138 | +### `executeTransfer(from, to, amount, deadline, signature)` |
| 139 | +Executes a meta-transaction with full validation: |
| 140 | +- Checks deadline |
| 141 | +- Verifies signature |
| 142 | +- Prevents replay via nonce and digest tracking |
| 143 | +- Increments nonce |
| 144 | +- Emits events |
| 145 | + |
| 146 | +### `getNonce(address)` |
| 147 | +Returns current nonce for address (used for signing) |
| 148 | + |
| 149 | +### `getDomainSeparator()` |
| 150 | +Returns EIP-712 domain separator for verification |
| 151 | + |
| 152 | +--- |
| 153 | + |
| 154 | +## 🛠️ Integration Steps |
| 155 | + |
| 156 | +### For Smart Contract Developers |
| 157 | +1. Inherit from both `ERC2771Context` and `EIP712` |
| 158 | +2. Declare `nonces` mapping and `usedSignatures` mapping |
| 159 | +3. Implement signature verification in your functions |
| 160 | +4. Increment nonce after successful execution |
| 161 | + |
| 162 | +### For dApp Developers |
| 163 | +1. Retrieve user's current nonce |
| 164 | +2. Prepare transfer data with nonce |
| 165 | +3. Have user sign with their wallet |
| 166 | +4. Submit signature to relayer endpoint |
| 167 | + |
| 168 | +### For Relayer Operators |
| 169 | +1. Verify signature is valid |
| 170 | +2. Verify nonce hasn't been used |
| 171 | +3. Submit transaction to contract |
| 172 | +4. Monitor for successful execution |
| 173 | + |
| 174 | +--- |
| 175 | + |
| 176 | +## ✅ Verification Checklist |
| 177 | + |
| 178 | +- ✅ Nonce starts at 0 for new addresses |
| 179 | +- ✅ Nonce increments by 1 with each transfer |
| 180 | +- ✅ Same signature cannot be replayed |
| 181 | +- ✅ Old nonces are rejected |
| 182 | +- ✅ Different users have independent nonces |
| 183 | +- ✅ Expired signatures are rejected |
| 184 | +- ✅ Chain ID is part of domain |
| 185 | +- ✅ Zero addresses are rejected |
| 186 | +- ✅ Zero amounts are rejected |
| 187 | + |
| 188 | +--- |
| 189 | + |
| 190 | +## 📚 Standards Compliance |
| 191 | + |
| 192 | +- ✅ **EIP-2771**: Meta-transaction execution via trusted forwarder |
| 193 | +- ✅ **EIP-712**: Typed structured data signing |
| 194 | +- ✅ **OpenZeppelin**: EIP712, ECDSA libraries |
| 195 | + |
| 196 | +--- |
| 197 | + |
| 198 | +## 🎓 Learn More |
| 199 | + |
| 200 | +- Read the full test suite in `test/MetaTxExample.test.ts` |
| 201 | +- Check invariant tests in `test/fuzz/MetaTxReplayAttackFuzz.sol` |
| 202 | +- Review service implementation in `meta-tx/meta-tx.service.ts` |
| 203 | +- See API usage in `meta-tx/meta-tx.controller.ts` |
| 204 | + |
| 205 | +--- |
| 206 | + |
| 207 | +## 📞 Support |
| 208 | + |
| 209 | +For questions about the implementation: |
| 210 | +1. Check `META_TX_IMPLEMENTATION.md` for detailed documentation |
| 211 | +2. Review test cases for usage examples |
| 212 | +3. Examine service code for integration patterns |
| 213 | +4. Check fuzz tests for invariant properties |
0 commit comments