A Step-by-Step Guide to Auditing a Crypto Projects Smart Contract

A smart-contract audit is a structured attempt to discover how a contract can fail, be misused, or be controlled in a way users did not expect. It is not the same as running one scanner, reading an audit badge, or confirming that source code is verified. Use the workflow below to review a deployed EVM contract or a codebase before you trust it with meaningful funds.

Important: This is a practical review framework, not a guarantee that a project is safe and not investment advice. A production protocol holding substantial value should receive an independent review by experienced security professionals. The interface-style images in this guide are illustrative and should not be treated as evidence about any particular project or deployment.

Audit checklist at a glance

Step 1: Confirm the scope and the deployed artifact

Start with the exact chain and address. Record the deployment address, transaction hash, block number, compiler version, optimizer settings, constructor arguments, and the commit or release that the team says is deployed. A project may have several addresses for a token, router, vault, proxy, implementation, oracle, or test deployment. A review of the wrong address has no practical value.

Check whether the explorer’s verified source reproduces the deployed bytecode. Verification is useful because it lets you inspect source and ABI, but it is only an identity check: it does not prove that the business logic is safe. If the contract is upgradeable, identify both the proxy and its current implementation. Read the implementation address from the proxy’s documented mechanism or explorer information, then confirm that the implementation is the one you intend to review. Etherscan’s official Foundry verification guide documents verification for new and existing contracts.

Also define the boundary. Include imported libraries, inherited contracts, linked libraries, deployed helper contracts, oracle adapters, tokens received from users, and privileged off-chain components. Write down what is out of scope and why. This prevents a narrow review from being mistaken for a review of the complete system.

Step 2: Build an entry-point and asset map

List every public and external function, including inherited functions and fallback or receive handlers. For each one, record whether it can:

• move native currency or tokens;
• mint, burn, borrow, liquidate, or alter accounting;
• change an oracle, fee, limit, role, pause state, or implementation;
• make an external call, delegatecall, or low-level call; or
• read data that another state-changing function relies on.

Then map the assets and trust boundaries. Follow a deposit from the user into storage, through pricing and share calculation, to withdrawal. Identify every address supplied by a caller and every address loaded from storage. Ask which values are assumed to be honest: an oracle, a token, a bridge message, a keeper, a callback receiver, or an administrator. The highest-value review targets are functions that combine user-controlled input, privileged state, arithmetic, and an external call.

Step 3: Compile cleanly and run static analysis

Reproduce the project’s build with the stated Solidity version, dependency versions, optimizer configuration, and target chain assumptions. Treat compiler warnings as review items rather than harmless noise. Solidity’s security considerations specifically recommend taking warnings seriously, keeping contracts understandable, and checking known compiler issues. Consult the official list of known Solidity compiler bugs when the compiler version or affected code patterns make it relevant.

For a Hardhat, Foundry, or similar project, run Slither from the project root. Its official documentation describes the tool as a Solidity and Vyper static analyzer and gives the common command:

slither .

Save the output and triage each result by impact and confidence. Look closely at findings involving arbitrary token sends, unprotected upgrades, reentrancy, unchecked return values, dangerous delegatecall, tx.origin, weak randomness, and incorrect interfaces. A detector can report a false positive, miss a project-specific economic flaw, or flag code that is intentionally constrained elsewhere. Static analysis narrows the search; it does not replace manual reasoning. The Slither repository and documentation also list printers for entry points, authorization, call graphs, and contract summaries that help organize a review.

Step 4: Manually trace external calls and reentrancy

For each external call, stop and trace the state before, during, and after the call. The callee may be a malicious contract, a token with hooks, a callback receiver, or another protocol that changes a shared dependency. Solidity’s documentation explains that an interaction with another contract can hand control to that contract and recommends the Checks-Effects-Interactions pattern: validate first, update this contract’s state second, and interact externally last.

Do not limit the search to obvious Ether transfers. Check ERC-777-style hooks, ERC-1155 callbacks, flash-loan callbacks, arbitrary routers, oracle calls, and calls made through inherited libraries. Review cross-function and cross-contract reentrancy: a callback may enter a different function that reads an intermediate state. Confirm that every low-level call checks its success result and handles a returned value correctly. Ask whether a failed recipient can permanently block withdrawals or a loop.

Record a concrete attack sequence for every plausible issue. For example: attacker deposits, starts a withdrawal, receives a callback, re-enters a second withdrawal, and only then allows the first call to finish. If the sequence cannot be made to work because of a specific invariant or guard, write down that reason. This makes the conclusion auditable rather than speculative.

Step 5: Test arithmetic and business invariants

Check the meaning of every unit and conversion: wei versus ether, token decimals, basis points, shares versus assets, signed values, and time units. Follow rounding direction. A division that rounds in favor of a depositor, borrower, liquidator, or fee recipient may leak value when repeated. Review multiplication before division, minimum and maximum amounts, fee caps, stale prices, zero supply, zero balance, and the first depositor or last withdrawer.

Solidity 0.8 and later normally detect arithmetic overflow and underflow, but code inside an unchecked block deliberately changes that behavior. Checked arithmetic can also make a protocol revert or become unusable if limits are not designed correctly. Test both outcomes: theft or incorrect accounting, and denial of service caused by a value that can never be processed.

Write invariants in plain language before turning them into tests. Examples include “total shares correspond to assets under the stated rounding rule,” “a user cannot withdraw more than their recorded claim,” “total token supply equals the sum of balances where that model applies,” and “a fee cannot exceed its configured cap.” Compare storage balances with actual token balances, because tokens can be sent directly to a contract or may behave differently from the assumed ERC-20 implementation.

Step 6: Review permissions and upgradeability

Build a privilege matrix. For every administrative function, identify its required role, current holder, transfer mechanism, delay, multisignature or governance control, and emergency behavior. Pay particular attention to minting, pausing, changing fees, changing oracle sources, rescuing funds, upgrading code, and changing trusted token or router addresses. OpenZeppelin’s access-control documentation distinguishes simple ownership from role-based permissions and describes least privilege as a useful security practice.

Separate “the code lets an administrator do this” from “an arbitrary user can do this.” The first may be an explicit governance or custody risk; the second is an authorization vulnerability. Verify that role checks cover every sensitive path, including internal helpers reachable from public functions. Check whether a default admin can grant itself or others additional power, and whether ownership transfer can be accidentally sent to an unusable address.

For proxies, review the initializer, implementation authorization, upgrade delay, storage layout, and rollback or emergency plan. OpenZeppelin’s upgradeable-contract guidance explains why constructors do not initialize proxy storage, why initializers must be protected, why an implementation should not remain uninitialized, and why changing storage order or types can corrupt an upgrade. Treat a proxy admin key as part of the protocol’s security boundary, not as an implementation detail.

Step 7: Exercise the system with fuzzing, invariants, and forks

Run unit tests for expected behavior, then add negative tests for unauthorized callers, zero values, maximum values, expired signatures, stale oracle data, failed transfers, and repeated operations. Fuzz inputs rather than testing only a few hand-picked numbers. Include multiple actors and malicious receiver contracts where the design permits callbacks.

Use invariant testing for properties that must remain true after many randomized calls. The Foundry invariant-testing documentation describes randomized sequences, fuzzed inputs, runs, depth, target contracts, and target senders. Configure handlers so calls are meaningful; if every fuzzed deposit reverts because the test actor has no tokens, a passing invariant may simply mean that no useful state changed.

When possible, use a fork of the target network to exercise the deployed addresses, current configuration, token behavior, and proxy routing. Keep fork tests safe and read-only unless you are using an isolated local fork. Minimize every failing sequence and preserve the counterexample, caller addresses, block context, balances, and relevant storage values. A test that passes is evidence about tested paths, not proof of all possible paths.

Step 8: Write findings that can be fixed and retested

Use one record per issue. A practical finding should contain:

• Title and location: contract, function, file, and line or code reference.
• Impact: what can be stolen, frozen, inflated, bypassed, or made incorrect.
• Precondition: the permissions, balances, timing, or configuration needed.
• Reproduction: a short transaction sequence, test, trace, or proof.
• Recommendation: a specific code or operational change, with tradeoffs.
• Status: open, fixed, mitigated, accepted risk, or not reproducible.
• Retest: the exact test or observation that confirms the resolution.

Severity should reflect realistic impact and exploitability, not how alarming a code pattern looks. Explain assumptions. A low-level call may be safe behind a strong invariant; a seemingly ordinary parameter change may be critical if it controls an oracle or upgrade. After a fix, review the diff, rerun the relevant test, rerun the full suite, and check for regressions. If the deployed address was already upgraded or changed, retest the actual on-chain implementation and configuration.

Common audit mistakes to avoid

• “The source is verified, so it is safe.” Verification establishes correspondence between source and bytecode; it does not validate the design.
• “The scanner found nothing, so there are no bugs.” Tools are strongest at known patterns, while economic and cross-contract flaws often require human analysis.
• “The project has an audit report, so the current deployment is covered.” Compare the report’s commit, scope, deployment addresses, fixes, and upgrade history.
• “Fuzz tests passed, so the invariant is correct.” First confirm that the invariant expresses the intended economic property and that handlers reach meaningful states.
• “Admin control is not a security issue.” It may be an intentional trust assumption, but users should be able to see who can mint, pause, change parameters, or upgrade.

Final self-check before trusting the result

You should be able to answer yes to these questions:

• Did I record the exact chain, address, bytecode, proxy, implementation, and build settings?
• Did I inventory every state-changing entry point and the assets it can affect?
• Did I compile cleanly, inspect warnings, and triage automated findings?
• Did I trace every external call, callback, low-level call, and failure path?
• Did I test rounding, limits, zero values, stale data, and repeated actions?
• Did I map all privileged roles, keys, delays, initializers, and upgrade paths?
• Did I preserve meaningful fuzz and invariant counterexamples?
• Can an independent reviewer reproduce each finding and verify each fix?

If any answer is no, label the audit incomplete and state the missing evidence. A transparent limitation is more useful than a vague “secure” conclusion. Smart-contract security is a continuing process: every upgrade, dependency change, new integration, and privilege change can create a new review boundary.