List: 100 Assumptions That Could Lead to Bugs

I’ve been getting questions about assumptions vs invariants, since the following tweet:

ChatGPT provided, surprisingly, a good list (not exhaustive by any means of course but the coverage is quite wide and can give some nice ideas):

1. Input-Related Assumptions

1. Users will not pass zero as an input.
2. Users will not pass maximum integer values.
3. Negative numbers are not possible as inputs.
4. Input arrays will always have unique elements.
5. Input strings will not be excessively large.
6. Addresses provided will not be zero address.
7. Addresses provided will not be the contract’s own address.
8. Token amounts will not exceed the balance of the sender.
9. Token amounts will not exceed the allowance provided.
10. Numeric inputs will not cause overflows or underflows.
11. Users will not use uninitialized or invalid token contracts.
12. Users will provide valid enum values.
13. Nonces will always increase as intended.
14. Inputs will match expected types (e.g., ETH vs. ERC-20).
15. Users will not duplicate input data.
16. Inputs will not reference non-existent IDs.
17. Inputs will be within specified ranges.
18. Invalid signatures will not be provided.
19. Hashes will match expected input formats.
20. Users will not send mismatched parameter types.

2. Call Order-Related Assumptions

1. Functions will always be called in the expected order.
2. Users will not skip initialization steps.
3. Deposits will always occur before withdrawals.
4. Staking will always precede claiming rewards.
5. Users will follow the required sequence for approvals and transfers.
6. State-dependent calls will occur in valid states only.
7. Users will not bypass intermediate validation steps.
8. Admins will set critical parameters before system activation.
9. Initialization will occur exactly once.
10. Reinitialization functions will not be called maliciously.

3. External Call-Related Assumptions

1. External contracts will not revert unexpectedly.
2. Tokens will implement the full ERC-20 or ERC-721 standard.
3. Fallback functions will not be exploited.
4. Oracles will provide timely and accurate data.
5. Token transfers will not trigger reentrancy.
6. External data feeds will not be manipulated.
7. Delegated calls will not execute malicious logic.
8. Proxy contracts will point to valid implementations.
9. External dependencies will not be updated unexpectedly.
10. Malicious tokens will not cause denial of service.

4. Permission and Role-Related Assumptions

1. Only authorized users will call sensitive functions.
2. Admin roles will not be misassigned.
3. No unauthorized user will gain access to restricted functionality.
4. Privileged roles will not be abused.
5. Ownership transfers will occur securely.
6. Contract migration will preserve permissions correctly.
7. Critical configuration functions will only be accessible to the owner.
8. Time-locked roles will wait for the correct duration.
9. Multisig wallets will function as expected.
10. No privileged roles will perform unexpected actions.

5. Economic/Game-Theoretic Assumptions

1. Users will not manipulate rewards for personal gain.
2. Users will not collude to break system fairness.
3. Flash loans will not exploit economic logic.
4. Users will not manipulate auction prices unfairly.
5. Liquidity providers will not abuse fee structures.
6. Validators will not act maliciously to gain rewards.
7. Users will not game staking mechanisms.
8. Governance participants will act in good faith.
9. Incentives will align with intended behaviors.
10. Arbitrage opportunities will not cause systemic loss.

6. Time and Sequence-Related Assumptions

1. Block timestamps will not be manipulated.
2. Functions will be called within expected time windows.
3. Timelocks will not be bypassed or miscalculated.
4. Rewards will be claimed in the correct time frame.
5. Events will occur in their expected order.
6. Blocks will be mined at expected intervals.
7. Expiry dates will be enforced correctly.
8. Users will not exploit outdated state between calls.
9. Epoch changes will trigger appropriate state updates.
10. State-dependent functions will execute atomically.

7. Math and Precision-Related Assumptions

1. Division operations will not cause rounding errors.
2. Decimal precision will match token standards.
3. Arithmetic operations will not cause overflow.
4. Subtractions will not result in negative balances.
5. Reward calculations will distribute funds accurately.
6. Fees will not reduce balances below zero.
7. Multiplication will not cause unintended scaling.
8. Token amounts will remain within expected precision.
9. Iterative calculations will not lose precision over time.
10. Conversion rates will be consistently applied.

8. State and Storage-Related Assumptions

1. State variables will always initialize correctly.
2. Storage reads will reflect the latest state.
3. State transitions will occur atomically.
4. No state updates will be partially applied.
5. Iterative processes will complete in one call.
6. Reserved storage slots will not be overwritten.
7. Contracts will not reference stale or uninitialized variables.
8. Mapping keys will not produce collisions.
9. System state will reflect accurate user balances.
10. Migration processes will transfer state correctly.

9. System and Deployment Assumptions

1. Contract addresses will not collide.
2. Proxy deployments will use valid initialization.
3. Libraries will not introduce unexpected behavior.
4. Immutable variables will not be overwritten.
5. Contract deployment order will follow dependencies.
6. Upgrades will preserve existing state and logic.
7. Deployed bytecode will match verified source code.
8. Deployment gas costs will not exceed block limits.
9. Multi-contract systems will synchronize correctly.
10. Contracts will not rely on deprecated or unsupported opcodes.