|
190 | 190 | - **Error Codes**: `DeliveryPaymentTooLow` (EVM) |
191 | 191 | - **Code Reference**: `_quoteDeliveryPrice()` and payment validation |
192 | 192 |
|
| 193 | +### INV-021: Revert On Dust |
| 194 | + |
| 195 | +- **Invariant**: All cross-chain transfers should revert if the user included more than the exact amount ("dust") |
| 196 | +- **Description**: Ensures funds do not become locked in the contracts |
| 197 | +- **Enforcement**: Amount calculations in processing |
| 198 | +- **Error Codes**: `TransferAmountHasDust` (EVM) |
| 199 | + |
193 | 200 | ## Peer Management |
194 | 201 |
|
195 | | -### INV-021: Peer Management |
| 202 | +### INV-022: Peer Management |
196 | 203 |
|
197 | 204 | - **Invariant**: NTT Manager's peers must not be registered on the same chainID as the NTT Manager |
198 | 205 | - **Description**: Peers refer to NTT Managers on other chains; peers must not register each other on the same chain as they are operating on |
|
201 | 208 |
|
202 | 209 | ## Transceiver Management |
203 | 210 |
|
204 | | -### INV-022: Transceiver Registration Requirement |
| 211 | +### INV-023: Transceiver Registration Requirement |
205 | 212 |
|
206 | 213 | - **Invariant**: A transceiver can be enabled only when it is also registered |
207 | 214 | - **Description**: It is invalid for an enabled transceiver to be unregistered |
208 | 215 | - **Enforcement**: Assertions on transceiver management code paths |
209 | 216 | - **Code Reference**: `TransceiverRegistry.sol` (EVM) |
210 | 217 |
|
211 | | -### INV-023: Minimum and Maximum Threshold Bounds |
| 218 | +### INV-024: Minimum and Maximum Threshold Bounds |
212 | 219 |
|
213 | 220 | - **Invariant**: Threshold must be 1) greater than zero and 2) less than or equal to the number of enabled transceivers |
214 | 221 | - **Description**: Attestation threshold must not exceed available transceivers and must be positive |
215 | 222 | - **Enforcement**: Explicit bounds checking in threshold setting functions |
216 | 223 | - **Error Codes**: `ThresholdTooHigh`, `ZeroThreshold` (EVM/Solana) |
217 | 224 | - **Code Reference**: `_checkThresholdInvariants()` (EVM), error enforcement (Solana), `EThresholdTooHigh` (Sui) |
218 | 225 |
|
219 | | -### INV-024: Minimum Transceiver Requirement |
| 226 | +### INV-025: Minimum Transceiver Requirement |
220 | 227 |
|
221 | 228 | - **Invariant**: At least one transceiver must be enabled for operations (after initial deployment) |
222 | 229 | - **Description**: Prevents operations when no transceivers are available to process messages |
223 | 230 | - **Enforcement**: Enabled transceiver count validation before operations |
224 | 231 | - **Error Codes**: `NoEnabledTransceivers` (EVM), `NoRegisteredTransceivers` (Solana) |
225 | 232 |
|
226 | | -### INV-025: Transceiver Registration Requirement |
| 233 | +### INV-026: Transceiver Registration Requirement |
227 | 234 |
|
228 | 235 | - **Invariant**: A transceiver cannot be unregistered and its index must not change |
229 | 236 | - **Description**: Transceivers should never be truly deleted, only disabled. This preserves their index into the bitmap which is crucial for attestation. |
230 | 237 | - **Enforcement**: Assertions on transceiver management code paths |
231 | 238 |
|
232 | | -### INV-026: Transceiver index should always increase |
| 239 | +### INV-027: Transceiver index should always increase |
233 | 240 |
|
234 | 241 | - **Invariant**: The next transceiver index must always increase monotically |
235 | 242 | - **Description**: The next transceiver index should always go up by one. This guarantees uniqueness of indices into the bitmap which is crucial for attestation. |
236 | 243 | - **Enforcement**: Assertions on transceiver management code paths |
237 | 244 |
|
238 | 245 | ## Timing and Release Controls |
239 | 246 |
|
240 | | -### INV-027: Release Timing Validation |
| 247 | +### INV-028: Release Timing Validation |
241 | 248 |
|
242 | 249 | - **Invariant**: Transfers can only be released after rate limit delay expires |
243 | 250 | - **Description**: Enforces time-based delays for rate-limited transfers |
244 | 251 | - **Enforcement**: Timestamp validation before transfer release |
245 | 252 | - **Error Codes**: `CantReleaseYet` (Solana), `ECantReleaseYet` (Sui) |
246 | 253 | - **Code Reference**: Rate limiter queue system with timestamp checks, `try_release()` functions |
247 | 254 |
|
248 | | -### INV-028: Transfer Redemption Controls |
| 255 | +### INV-029: Transfer Redemption Controls |
249 | 256 |
|
250 | 257 | - **Invariant**: Transfers must be properly approved and not already redeemed before processing |
251 | 258 | - **Description**: Prevents unauthorized or duplicate transfer redemptions |
|
255 | 262 |
|
256 | 263 | ## Message Size Constraints |
257 | 264 |
|
258 | | -### INV-029: Payload Length Limitation |
| 265 | +### INV-030: Payload Length Limitation |
259 | 266 |
|
260 | 267 | - **Invariant**: NttManagerMessages and AdditionalPayloads must not exceed uint16 in size |
261 | 268 | - **Description**: Prevents unbounded message sizes that could cause processing issues |
262 | 269 | - **Enforcement**: Assertions in encoding logic |
263 | 270 | - **Error Codes**: `PayloadTooLong` (EVM) |
264 | 271 | - **Code Reference**: `TransceiverStructs.sol` (EVM), implementation of `Writable` trait for `NativeTokenTransfer` (Solana) |
265 | 272 |
|
266 | | -### INV-030: Transceiver Instruction Length Limitation |
| 273 | +### INV-031: Transceiver Instruction Length Limitation |
267 | 274 |
|
268 | 275 | - **Invariant**: Individual transceiver instruction payloads must not exceed uint8 in size |
269 | 276 | - **Description**: Prevents unbounded message sizes that could cause processing issues |
|
0 commit comments