Smart contract security checklist for web3 developers

How to use this checklist

Access control

• Every privileged function has an access check. Why: anyone can call a public function. Test: list all external functions, and try each one from an unprivileged account.
• Roles are written down: who can do what, and who can change the roles. Test: compare the list against the code.
• No tx.origin for authorization. Why: a malicious contract can relay a user's call. Test: search the code for tx.origin.
• Initializers can run once and only by the intended caller. Test: call initialize a second time on a deployed copy.
• Nothing can send out funds or selfdestruct without a check. Test: grep for selfdestruct and raw ether transfers, then check who can reach them.

Oracles and price inputs

• No price taken from a single thin pool. Why: one trade can move it. Test: write a test that trades a large amount in the pool, then reads your price.
• Use a time-weighted or multi-source price, and reject large gaps between sources. Why: Nostra's oracle blended a distorted quote instead of rejecting the gap.
• Units, decimals and ratios are checked. Why: Moonwell priced an asset with a ratio instead of a USD price. Test: compare the oracle output against a known market price for every asset.
• Stale prices are rejected. Test: feed an old timestamp and confirm the call reverts.

Business logic

• Write down the invariants, such as "total shares never exceed total assets". Test: turn each into a fuzz or invariant test.
• Rounding goes in the protocol's favor. Test: run deposits and withdrawals of tiny amounts.
• Share and asset accounting stays consistent after every state change. Test: check balances before and after each path.

Input validation

• Zero, negative and maximum values are handled. Why: Dango's contracts did not check that donation amounts were positive.
• Array lengths match and are bounded.
• address(0) is rejected where it makes no sense.
• Test: call every external function with edge values.

Reentrancy

• Follow checks-effects-interactions: update state before external calls.
• Add reentrancy guards where state is shared across functions, and on read-only paths other contracts rely on.
• Review token hooks and callbacks, such as ERC-777 and ERC-721 receive hooks. Why: Solv's loss came from a callback that fired before the books were balanced.
• Test: write a malicious contract that calls back in from every hook.

External calls

• Return values are checked.
• Failed low-level calls are handled, not ignored.
• Test: use a mock callee that reverts or returns false.

Flash loans and same-block manipulation

• Assume any value readable in one transaction can be moved in that transaction.
• Don't base share prices or collateral values on balances or pool states that can change within a block.
• Test: simulate a flash-loan-sized trade before your function runs.

Arithmetic

• Use Solidity 0.8 or later, which checks overflow by default.
• Review every unchecked block.
• Check type casts that shrink a number.
• Legacy contracts on older compilers get a dedicated review. Why: Truebit lost $26.2M to an overflow in a contract about five years old.
• Test: run boundary values through every calculation.

Signatures

• Signed data includes a nonce, the chain ID and the contract address. Use EIP-712. Note: EIP-712 does not include replay protection itself, so add your own nonce.
• Every parameter that matters is covered by the signature. Why: GiddyDeFi's attacker changed parameters the signature did not cover.
• Signatures can't be malleated or reused. Test: replay a valid signature with changed fields, and on another chain.

Randomness

• No block values (timestamp, block hash) as a source of randomness.
• Test: search the code for block.timestamp and blockhash and check what they feed.

Denial of service and gas

• No unbounded loops over user-controlled lists.
• Prefer pull payments to push payments, so one failed transfer can't block everyone.
• Test: grow the list until the call runs out of gas.

Upgrades and deployment

• Storage layout is kept when you upgrade a proxy. Test: diff the layout between versions.
• The proxy admin is controlled and documented.
• Deploy scripts are reviewed like contract code.
• Source code is verified on the block explorer.
• Constructors and initializers set up state as intended.

Keys, signers and operations (off-chain)

• Multisig thresholds are set, and signers are separate people on separate devices.
• No single-signer bridge, minter or admin.
• Hardware keys for privileged accounts.
• CI and cloud secrets are locked down, and third-party access is reviewed.
• Monitoring and a pause switch are in place.

Audit readiness

• A frozen commit.
• A list of files in scope.
• Docs or a spec describing intended behavior.
• Tests pass, and coverage is known.
• Known issues are listed.
• Output from tools like Slither is triaged.

Automate the code part

• Smart contract audit
• Pricing
• What a pre-audit is
• AI smart contract auditor

Standards and sources

• OWASP Smart Contract Top 10 (2025 edition)
• SWC Registry. No longer actively maintained; content has not been thoroughly updated since 2020. The page points to the EEA EthTrust Security Levels and the Smart Contract Security Verification Standard for maintained guidance.
• EIP-712: typed structured data
• Halborn: Top 100 digital asset hacks, H1 2026
• DeFi hacks in 2026

FAQ

What is smart contract security?

It is the work of making sure a contract can't be made to lose or lock funds. It covers the code, and the keys and systems around it.

What should I check before a smart contract audit?

Freeze a commit, list the scope, write a spec, make tests pass and triage tool output. See the audit readiness section.

What are the most common smart contract vulnerabilities?

OWASP's 2025 Top 10 lists: access control, price oracle manipulation, logic errors, lack of input validation, reentrancy, unchecked external calls, flash loan attacks, integer overflow and underflow, insecure randomness, and denial of service.

Is web3 development security different from web2?

Yes, in several ways. Deployed contracts are hard to change. Code and transactions are public. Contracts call each other, so one weak input can reach many protocols. And a stolen key is often enough to lose everything.

Does an audit make my contract safe?

No. No audit guarantees safety. An audit reviews code. It does not cover keys, signers or infrastructure, which caused most 2026 losses by value. See DeFi hacks in 2026.