Go to Website Go to Dashboard
Go to Dashboard
Knowledge Base
Important

Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

A smart contract audit is an independent review of code and architecture within a defined scope. Its purpose is to identify vulnerabilities, implementation errors, and mismatches between intended and actual behavior.

An audit can reduce uncertainty, but it does not make a contract risk-free. Ethereum’s official security guidance describes audits as an additional review, not a silver bullet that catches every bug.

This article is for educational purposes only. An audit does not guarantee security, recovery of funds, or returns.

Scope comes first

A useful report identifies exactly what was reviewed:

  • repository and commit hash;
  • files and contracts;
  • compiler version and build settings;
  • dependencies;
  • architecture and privileged roles;
  • branch or release;
  • exclusions, limitations, and assumptions;
  • review date.

This matters because a genuine audit may cover an old version, a different deployment, or only one part of a larger system.

What auditors commonly examine

1. Intended behavior and invariants

Auditors compare code with its specification:

  • who may call each function;
  • how amounts and fees are calculated;
  • when status changes occur;
  • which properties must always remain true;
  • how edge cases and failures are handled.

If the specification omits an important requirement, technically correct code can still implement an unsafe or unwanted design.

2. Access control

Reviewers inspect owner, admin, operator, and other privileged roles, including powers to:

  • grant or revoke permissions;
  • pause the system;
  • change fees and limits;
  • mint tokens;
  • withdraw assets;
  • upgrade an implementation.

They also consider whether one key can make a critical change and whether controls such as multisig or a timelock are part of the design.

3. External calls and reentrancy

A contract may hand control to another contract during execution. This can enable reentrancy, where the external contract calls back before the original state transition is complete. Solidity’s official guidance recommends carefully ordering checks, state effects, and external interactions where appropriate.

4. Calculations and units

Auditors look for:

  • rounding and precision loss;
  • mismatched token decimals;
  • incorrect order of operations;
  • boundary values;
  • division by zero;
  • unsafe unchecked arithmetic;
  • discrepancies between internal and displayed units.

5. Denial of service and gas

Unbounded loops, growing arrays, failed external calls, or expensive operations may make a function impractical to execute. Reviewers test whether the design remains usable as data grows and under unusual inputs.

6. Proxies and upgrades

For upgradeable systems, the review should cover:

  • proxy and implementation contracts;
  • upgrader or admin rights;
  • initialization;
  • storage-layout compatibility;
  • unauthorized-upgrade paths;
  • the effect of changing logic after the audit.

A proxy can preserve the same user-facing address while delegating to new logic. Claims that “the contract cannot change” must therefore be checked against the actual architecture.

7. Integrations

Contracts may depend on tokens, price oracles, bridges, DEXs, signatures, or other contracts. Auditors examine assumptions about those dependencies, stale data, unusual token behavior, and external failure modes.

8. Events and monitoring

Reviewers may check whether events accurately expose significant actions such as role changes, upgrades, pauses, and transfers. Events support monitoring, but they do not replace state inspection.

Methods used in an audit

A review commonly combines:

  • manual code and architecture analysis;
  • unit and integration testing;
  • static and dynamic analysis;
  • fuzzing with generated inputs;
  • property-based testing;
  • checks for known vulnerability classes;
  • build and deployment review;
  • sometimes formal verification of selected properties.

No single method covers everything. Formal verification can prove that code satisfies a formal specification; it cannot prove a property that the specification failed to express.

How a user should read an audit

1. Match the reviewed version

Find the commit hash and determine:

  • whether the current implementation was built from that code;
  • whether upgrades occurred after the report date;
  • whether chain and deployed addresses match;
  • whether critical dependencies were in scope.

If this cannot be established, the report provides limited evidence about the live deployment.

2. Read findings, not only the summary

For every finding, review:

  • severity and scenario;
  • affected code;
  • recommendation;
  • developer response;
  • current status;
  • whether the auditor retested the fix.

Fixed or Resolved is meaningful only when tied to a specific corrected version.

3. Read limitations

Reports may exclude:

  • frontend and backend systems;
  • key management;
  • economic design;
  • third-party contracts;
  • deployment infrastructure;
  • production configuration;
  • legal and operational issues.

Users interact with the entire system, not just its Solidity files.

4. Review administrative risk

Ask:

  • who controls upgrades;
  • whether operations can be paused;
  • whether fees or linked addresses can change;
  • whether a timelock exists;
  • whether a multisig is used;
  • how users learn about changes.

These are governance and trust questions even when the code has no discovered vulnerability.

5. Look for security after the audit

Useful ongoing measures include:

  • testing every release;
  • reviewing significant upgrades;
  • a bug-bounty program;
  • monitoring roles and implementations;
  • incident-response procedures;
  • limiting the amount of assets exposed.

What an audit does not guarantee

An audit does not guarantee:

  • absence of every bug;
  • safety of code changed after review;
  • safety of the website, wallet, DNS, or servers;
  • security of privileged keys;
  • correctness of external tokens, oracles, and bridges;
  • resistance to every economic attack;
  • integrity of a team;
  • legal compliance;
  • token liquidity;
  • return of funds;
  • fixed or any other returns.

Questions a cautious user should ask

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Report checklist

  • The report is available from the auditor.
  • Repository and commit hash are stated.
  • Critical contracts and dependencies are in scope.
  • The reviewed version matches the live deployment.
  • Proxy, implementation, and admin are covered.
  • Finding status and retesting are documented.
  • Assumptions and exclusions were read.
  • Risks outside the code were assessed separately.

Sources and Further Reading

  1. Ethereum.org — Smart Contract Security
  2. Ethereum.org — Testing Smart Contracts
  3. Ethereum.org — Formal Verification of Smart Contracts
  4. Solidity Documentation — Security Considerations
  5. OpenZeppelin Docs — Proxy Upgrade Pattern