You need a smart contract audit when your contract will hold or move value that you cannot afford to lose, and it is doing something specific to your product rather than being a well-worn standard. If neither of those is true, an audit is probably not the next thing your money should buy.

I do not perform audits, so treat this as an impartial answer rather than a pitch. Half the reason people ask me this question is that they have been told they need one without being told what it would actually give them.

What an audit actually is

An audit is a structured review of your contract's code by a specialist, looking for ways it can be made to behave differently than you intend. It produces findings with severities, and usually a report you can show to users, partners, or an exchange.

What it is not is a guarantee. An audit says a specific team looked carefully at a specific version of the code on a specific date and found these issues. It does not say the contract is safe. Contracts that passed audits have still been drained, often because the flaw was in how the contract was used, or in a dependency, or in something that changed after the audit.

When you genuinely need one

  • The contract custodies user funds. A vault, a bridge, a staking pool, an escrow. If a bug means users lose money, you need a specialist review before that money is there.
  • The logic is custom and non-trivial. Novel pricing, novel incentive mechanics, upgradeable proxies with unusual patterns. Anything where a small mistake in arithmetic or access control is expensive.
  • An exchange, partner, or institutional user requires it. Sometimes the commercial requirement is the whole reason. That is a legitimate reason.
  • The contract has been changed since the last audit. An audit of a previous version does not transfer. This is where a lot of projects quietly lose their coverage.

When you probably do not

  • Your contract holds no value. A registry that writes non-financial data is a different risk class from a vault holding user deposits.
  • You are pre-product and the contract may not survive. Auditing a contract you are about to rewrite is an expensive way to learn that.
  • You are using a widely deployed, unmodified standard. A plain token implementation that has been deployed thousands of times has a known risk profile. Your integration around it is where your risk actually lives.
  • You have not tested it at all yet. An auditor reviewing code that fails its own basic tests is being paid to find things you could have found for free.

What you need even if you skip the audit

Skipping an audit does not mean shipping untested. It means the specialist review is not your next dollar. Everything below is still worth doing, and it is cheap relative to a remediation cycle after launch.

  • Tests that check invariants, not just outputs. A test that asserts "calling this returns 5" is weak. A test that asserts "the sum of all balances always equals the total deposited" catches a whole class of bugs at once.
  • Hostile input testing. Reentrancy, unexpected callbacks, zero values, maximum values, and callers who are not who you expect. Most exploited contracts failed here first.
  • A staged rollout with limits. Caps on value, caps on volume, and a pause mechanism. If something does go wrong, the size of the loss is a design decision you made in advance.
  • Monitoring after launch. An alert on unexpected withdrawal patterns costs almost nothing and shortens the window between a problem starting and someone noticing.
  • A written disclosure of what has not been reviewed. If your contract has not been audited, say so, in the same place you describe the product. Users who are told what they are taking on can make a decision. Users who assume coverage exists and later find out it did not will not forgive it.

What I do and do not do

I build application-layer products and Web3 integrations. That includes straightforward contracts where the product needs one, and everything around them: frontend, backend, wallet flows, on-chain reads, deployment, and handover.

What I do not offer is a formal smart-contract audit, penetration testing, or security certification. If your product depends on a contract holding real value, that work belongs with a dedicated auditor, and I will say that clearly rather than quietly skip past it to win the build. It is one of the questions I answer plainly on the product build page, and it is the same line I hold on AgentHub, where the honest limitation is written down: the security properties of that project have not been formally audited.

The uncomfortable part

Most projects that skip an audit do it quietly, because writing down "we have not been reviewed" feels like a weakness. I think it is the opposite. A project that states its unverified surface is telling you it knows where its risk is, which is a better signal than a badge nobody can see the scope of.

Where the line sits between "not audited" and "not tested" is the question worth being honest with yourself about. If you want to talk through which of the two you are actually in, the reasoning in how to use AI in Web3 without blindly trusting it covers how I handle the parts of a build that cannot be undone.