A smart contract audit that finishes before your next standup.

What a smart contract audit actually checks

Most people arrive at the phrase "smart contract security audit" with a vague sense that someone senior reads the code and blesses it. That is not what happens. An audit is a search for a specific and mostly well-catalogued set of failure modes, and knowing the list is what turns the report from a formality into something you can act on.

The failures that drain contracts fall into a handful of families. Reentrancy, where an external call hands control to an attacker before your own bookkeeping is finished. Broken access control, where a function that moves money or changes ownership has no modifier guarding it, or guards it with tx.origin, which any intermediary contract can forge. Arithmetic that wraps, on Solidity below 0.8 without SafeMath, or inside an unchecked block that was added for gas and never revisited. Unsafe delegatecall, where a user-influenced address runs with your storage and your balance. Weak randomness, where a lottery seeds itself from block.timestamp and the proposer picks the winner. And centralization, which is rarely a bug at all — it is an owner who can mint, pause, blacklist or drain, working exactly as written, which is why it belongs in a report rather than in a bug tracker.

Our engine ships a detector for each of these and fourteen more. Every hit is mapped to its entry in the SWC Registry and the OWASP Smart Contract Top 10, so the report shows not just what was found but what was looked for and passed — the half of the coverage question that most audit PDFs quietly leave out. The full list is in the audit checklist.

How the audit runs

Four passes, in order, each feeding the next.

1. Source resolution

Give it a verified address and the chain, and the fetcher pulls the flattened source and compiler settings straight from the explorer. If the address is a proxy, it resolves the implementation and audits both, labelled separately — auditing a proxy alone tells you almost nothing about the logic your users actually hit. You can skip this entirely and paste Solidity or upload a .zip of the project.

2. Static analysis

The source is parsed into an AST and walked by the detector suite. This is the pass that finds structural bugs deterministically — a state write after an external call, a privileged function with no modifier, a loop over an unbounded array — and it does so without executing anything, so it is fast and it cannot be fooled by an environment you do not control.

3. Slither

On the Enterprise tier the engine also runs Slither, the Trail of Bits analyser, and merges its findings with ours. Two engines disagreeing about a line is a signal worth having; agreement raises confidence that a finding is real.

4. AI deep analysis

Static tools are excellent at patterns and blind to intent. They will not tell you that a fee function is mathematically capable of setting a 100% tax, that a staking reward loop pays out before it debits, or that the pause switch has no corresponding unpause. The AI pass reads the contract for business-logic traps, tokenomics abuse and honeypot patterns, then gets cross-checked against the static results so the same issue does not appear twice under two names.

What the report looks like

Audits are bought to be shown to other people, so the deliverable matters as much as the findings. Every audit produces a PDF with a risk gauge and severity breakdown up front, the standards coverage grid, and then one entry per finding: the affected code with the line highlighted, an attack-path diagram tracing how a caller would reach it, the severity and confidence, and the concrete fix.

Three report styles are available — a summary for a quick internal read, a detailed report with the full per-finding treatment, and a combined PDF with both. If you have never had to evaluate one of these documents, how to read an audit report walks through what the severity labels mean and which sections a serious reader checks first.

Audit smart contract online, three ways

You can audit a smart contract online here with no toolchain to install and nothing to configure. Every EVM smart contract audit runs the same pipeline regardless of how the code reaches it:

• By address — paste a verified contract address, pick the chain, go. The fastest path, and the one to use for a contract that is already deployed, including one you did not write and are considering putting money into.
• By source — paste Solidity directly into the box. Useful before deployment, when there is no address to point at yet.
• By upload — a .sol file, or a .zip of a multi-contract project with its imports intact, which is what most real systems look like.

Testnet scans are free and need no account, which is the honest way to evaluate an audit tool: run it on a contract you already understand and see whether the findings match what you know is there. Start with a free scan.

Where an automated audit stops

Being straight about this is more useful than a sales page. An automated engine is very good at the known and the structural, and it is not a substitute for a human expert on novel economic design. It will not model an oracle manipulation across three protocols it has never seen. It will not tell you your governance timelock is too short for your community to react. It does not read your documentation and check that the code matches your promises.

What it does do — reliably, in minutes, for a fraction of a firm's fee — is clear the ground. Every known bug class, every standards gap, every centralization lever, found and written up before a human ever opens the file. If you then hire a manual auditor, they start on the interesting problems instead of billing you to find a floating pragma. That argument is laid out in full on the audit companies comparison.