AI system for smart contract audit and analysis

Why manual smart contract audits miss vulnerabilities

Smart contract audits still rely on humans: a reviewer reads the logic, verifies it against the intent, and checks edge cases of calls.

As long as a contract fits within a few hundred lines, manual code review confidently finds dangerous ordering of external calls, gaps in access separation, and unhandled failures during fund transfers.

The problem manifests with the volume of changes. When a single release mixes new logic, state migration, and renames, the reviewer loses context between reviews: they judge a function by the last version read, not by the entire chain of edits.

Missed vulnerabilities then settle not in the core but in the surrounding code — access modifiers, fee calculation, and branches at zero and maximum values.

A separate source is regression after edits. A change to one function alters state that neighboring functions depend on, and without re-running the full set of checks, the defect returns in a different place. Accumulating small edits without re-review shifts system behavior imperceptibly to the eye.

And one more thing: manual review has no reproducible scenarios. Every audit starts from a blank slate, negative cases are kept in the reviewer's head and are not reused from contract to contract. Let's break down how this is addressed.

What automated code analysis provides: measurable effects

Automated code analysis does not replace an audit entirely but redistributes attention: the machine covers typical failure classes, while the engineer examines economics, role permissions, and scenarios that cannot be derived from templates.

A run takes minutes, so the check lives in the build pipeline and runs on every change, not once before release.

The first level is formal rules and symbolic execution: a suite such as Slither checks the entire repository, including external libraries, not just changed files. The second is manual inspection of critical paths: fund issuance, logic upgrades, and administrator rights.

The set of checks accumulates: each closed finding becomes a rule and is caught automatically in the next version. The result is that the share of detected defects grows not through engineers' time but through runs that proceed without human involvement.

Review formats: one-time analysis or continuous control

Smart contract review is not a single procedure but a set of system operating modes that differ in depth, frequency, and scope of analysis: only published code or its entire lifecycle together with upgrades.

The one-time mode answers the question “can it be released,” while the others answer “what changed since last time and what does that break.” Below is how this looks in practice and what limitations of the mode need to be considered in advance.

The modes are not mutually exclusive: a one-time review at intake, continuous change analysis during active development, and scheduled reviews.

They share one common limitation: the system analyzes only what it has access to, so without the repository, build artifacts, and a description of the protocol economics, some paths remain outside the review.

How a smart contract audit is conducted: stages of work

A smart contract audit is not a one-time check of a single file but the configuration of analysis for a specific codebase. We structure the implementation stages so that the checks fit into the current development process.

Dangerous spots look different across projects: in some, the right to issue tokens is critical; in others, external calls without result checks are critical.

That is why we first study the code and then configure the rules — otherwise we get a stream of false positives that the team will stop reading.

1. Repository and logic review. We study the contract structure, dependencies, entry points, roles, and access rights. We note which parts are upgraded and which are frozen — this determines the priority of checks.
2. Behavior model. We describe invariants: what must not be violated under any call scenario. This model becomes the basis for the rules.
3. Rule configuration. We enable checks for overflows, reentrancy, access to administrative functions, and unhandled external calls. We tune thresholds and exceptions to the project, not to a generic template.
4. Run on historical changes. We test the settings on past versions and edits: how many findings were confirmed and how many turned out to be noise. We adjust thresholds based on the result.
5. Engineer review of results. A human reviews each alert: confirms or rejects it with a reason. This builds a decision base for similar cases.
6. Handover of policies. We provide a description of the rules, analysis of contentious cases, and the procedure for handling new findings, and we train the team on its own examples.

Artifacts and policies that remain with your team

Reviewing an individual contract is not the end result.

We hand over to your team a reference set of review rules, a data flow diagram with marked trust boundaries, and policies by which the review can be reproduced without us: a new contract is run through the same rules, and findings receive the same severity level and handling procedure.

What exactly remains in the repository alongside the code and in internal documentation:

• A set of review rules: signatures of typical defects — reentrancy into a function, unsafe external calls, integer overflow, and unrestricted owner rights. Rules are versioned together with the code and refined as reviews accumulate.
• Data flow and trust boundary diagram: who calls the contract, which external value sources are considered untrusted, and where the boundary lies between your code and third-party calls.
• Access policies: changing rules, closing a finding, and signing off on a release are different roles. An action log is maintained and is not rewritten retroactively.
• A review report for each analysis: contract address, source code fingerprint, list of findings with severity level, line reference, rationale, and status — fixed, accepted as risk, or rejected.
• Response policy: what to do if a critical finding surfaces between review and release — who stops the release, who decides on further work or rollback, and within what timeframe.
• Team instructions: how to run the review on every code change, how to add a custom rule, and how to challenge a false positive with the decision recorded.
• Coverage matrix: which contracts and which logic branches have already been reviewed and which remain outside review — this is visible before release, not after an incident.

Case study: how the share of defects found before release grew

The client was releasing a protocol on smart contracts and updating it every two weeks. Each release underwent manual review: two engineers read the changes line by line and spent about 30 hours on review, while new modules took noticeably longer.

Before implementation, the review produced a predictable but limited sample. Before release, 58% of defects were caught; the rest surfaced on the testnet or after the contracts were published — and then fixing them required a new release and state migration.

The share of findings was limited by attention: by the end of the review, an engineer was worse at noticing repetitive patterns — incorrect access checks and calculation overflows.

What was changed

We built a model on labels from past audits and placed it as the first layer: the static analyzer Slither and the model label candidates and rank them by the probability of a real defect, while an engineer confirms or dismisses each finding. False positives are filtered out before they reach the report, so triage time does not grow.

On releases after implementation, the share of defects found before release grew from 58% to 91%, and the time from finding to fix dropped from two days to several hours — the fix goes into the same cycle, without a separate release.

Reviewing one release takes about 12 hours instead of 30, while coverage of non-obvious logic branches is higher than with purely manual review.

How static analysis differs from protocol logic review

Static analysis works with code without executing it: it builds a call tree and dependency graph and checks the result against a catalog of typical weaknesses such as the SWC Registry.

This covers overflows, unprotected external calls, missing permission checks, and uninitialized variables. The check is complete, repeatable, and does not depend on the engineer's imagination — but it sees only what is expressed in the syntax.

Logic review begins earlier — with a model of the protocol's behavior. We record what the system promises participants, which invariants must hold under any transaction ordering, and only then look for places where the code violates these invariants.

“Compiles and passes tests” and “behaves correctly” are different statements, and the entire area of economic defects lies between them.

The second layer is abuse scenarios: analysis of call sequences where each step is legal but together they give an attacker an advantage.

Oracle price manipulation within a single transaction, reentrancy through an external callback, uncollateralized borrowing for voting, front-running someone else's liquidation. The syntax is flawless, and formal checks on such code remain silent.

Therefore, the layers do not compete. Static analysis quickly filters out mass error classes across the entire set of contracts, while the behavior model and scenario analysis catch compositional defects invisible in a single function.

In the report, these are two different lists of findings with different remediation costs — and the client sees what is actually covered by the review and what remains an explicit assumption.

Limitations of the method and common engineer doubts

The system does not replace an audit entirely, and we state the boundaries of applicability directly. Typical classes — reentrancy before balance deduction, overflow, unprotected access to storage, and errors in external call ordering — are found reliably.

But economic logic: oracle stability, liquidation scenarios, price manipulation within a single transaction — the model does not infer; this requires task context and a threat model.

False positives are filtered out in two steps. First, we check reachability: if a branch is not executed under the given conditions, the finding is marked as insignificant.

Then an engineer confirms or rejects the signal, and only confirmed cases make it into the report — the share of noise on the first screen drops severalfold, and triage does not turn into paging through hundreds of identical warnings.

Manual verification is mandatory where the conclusion depends on agreements rather than code: administrator rights, contract upgrade procedure, fee distribution, and calculation of holder shares.

How do you check the quality of the model?

We run it on historical incidents with a known outcome and calculate what share of confirmed defects it finds and how many unconfirmed alerts it produces. We additionally compare it with independent static analysis and review discrepancies manually. We set target metrics before work begins — the result remains measurable, not subjective.

Let's discuss the task: what is needed for an estimate and work plan

Estimating a smart contract audit project depends not on the number of lines of code but on how fully the system boundaries are described.

If only contract files are sent, without the release process and edit history, a buffer has to be included for the unknown: timelines stretch, and some paths remain outside the review. To calculate the scope of work accurately, input data is needed.

• Repository or a copy: read access to the code, tests, deployment scripts, and build settings.
• Addresses of already deployed contracts and the network they operate on, including cases where logic is spread across multiple contracts.
• Answers about the release process: who publishes changes, whether code goes through review, who holds administrator keys, and how rights are transferred.
• Role and access rights scheme: which operations are available to the owner, which to the governing contract, and which are open to everyone.
• Known problem areas and history: what past reviews already found, what edits were made after launch and why.
• What is considered critical specifically for you: fund withdrawal, fee changes, external calls, pausing and stopping the system.

The startup sequence is almost always the same. First, we discuss the task and the review boundaries — the conversation takes less than an hour and immediately shows where the estimate will differ from expectations. Then you open access to the repository or a copy and answer questions about the release process.

After that, we return with a project estimate and work plan: stages, what we review at each, what artifacts we hand over, and what report format is more convenient for your team to read. Then comes timeline approval and the start.

If some data is closed, this does not block the start: we mark such areas in the plan as unreviewed and say so directly, rather than replacing silence with general wording.