Security Vulnerability Checklist for Smart Contract Auditors

Read the whitepaper, technical docs, and understand the intended behavior before looking at code.

Confirm exactly which contracts are in scope and document any dependencies that are out of scope.

Clone the repo, install dependencies, and ensure tests pass before starting review.

Execute Slither, Mythril, and other static analysis tools to get an initial vulnerability report.

Map out contract interactions, inheritance, and external dependencies visually.

Every function that modifies state should have explicit access restrictions unless intentionally open.

Administrative functions must be protected. Look for functions that should be restricted but aren't.

If using roles, verify proper role assignment, revocation, and role hierarchy logic.

Identify single points of failure where one compromised key could drain funds or break the protocol.

Critical ownership changes should require acceptance to prevent accidental lockout.

Check if administrative actions are properly timelocked for user protection.

All state changes must happen before external calls. No state updates after external calls.

Functions making external calls should use reentrancy protection, especially those handling value.

Check if an attacker could re-enter through a different function that shares state with the vulnerable function.

Analyze if reentrancy is possible through calls to other contracts in the same protocol.

Check if view functions return stale data during reentrancy that other protocols might rely on.

If accepting arbitrary tokens, verify protection against token callback reentrancy.

Solidity 0.8+ has overflow protection, but unchecked blocks bypass it. Verify intentional use.

Check if rounding favors the protocol or user, and if it can be exploited through dust amounts.

Multiply before divide to minimize precision loss. Check for cases where order matters.

Check that fees are calculated correctly and cannot exceed 100% or cause unexpected behavior.

All division operations should be protected against zero denominators.

Test behavior at max/min values, empty arrays, zero amounts, and other edge cases.

Check that return values from external calls are validated, especially for token transfers.

Use SafeERC20 or check return values. Some tokens don't return bool on transfer.

Check that oracle prices have staleness checks and fallback mechanisms.

Analyze if price manipulation or large position changes via flash loans could be exploited.

Contracts relying on balance checks can be manipulated via selfdestruct force-send.

If implementing callbacks (like uniswapV3SwapCallback), verify caller authentication.

Verify that spot prices cannot be manipulated to extract value from the protocol.

Check that liquidations properly handle edge cases and cannot be griefed or blocked.

Verify first depositor cannot inflate share price to grief subsequent depositors.

Check that rewards cannot be claimed multiple times or drained by flash deposits.

Check that cross-chain messages are properly validated and cannot be replayed.

Verify that minting cannot exceed supply and randomness cannot be manipulated.

Loops over arrays that can grow indefinitely may cause out-of-gas failures.

Functions processing many items may exceed block gas limit as usage grows.

Use pull payments instead of push to prevent recipient-controlled failures.

Verify that a failing external call cannot block critical protocol functions.

Check if gas costs can vary dramatically based on input, enabling gas griefing.

New implementation must be storage-compatible with previous version. No reordering variables.

Initializers must only run once. Check for reinitializer if needed for upgrades.

Implementation contract should be initialized or made non-initializable to prevent takeover.

Only authorized parties should be able to upgrade. Check for timelock on upgrades.

Proxy admin functions must not clash with implementation function selectors.