AI analysis of smart contract vulnerabilities and audit blind spots
Smart contract vulnerabilities rarely look like an obvious error in a single function.
More often, it is correct code that behaves incorrectly in a specific sequence of calls: bypassing an access control check through an intermediary function, a reentrant call that returns execution to the middle of an operation before storage is written, or a contract logic error in a rare calculation branch. Static checking misses this — it looks at a function, not at contract state between transactions.
That is why AI analysis of smart contracts is built as a layer on top of static analysis: the model traverses the call graph in full, matches entry points with the rights they actually grant, and marks where an external call occurs before a state change.
The output is not an abstract warning but an exploitation scenario: which transaction sequence, from which address, and exactly what the protocol loses.
Solidity adds its own layer: inheritance, intermediary contracts, and delegation hide actual rights behind a chain of calls, while data from external sources changes between check and use.
A contract logic error most often manifests exactly here — a condition is true at read time and stops being true by write time.
We classify findings by class — permission bypass, reentrancy, external data manipulation, logic error — and for each describe whether it is reproducible on a test network and how it is closed by a fix. Then we look at what exactly is checked automatically and what remains with the engineer.
What continuous code checking before every release provides
Continuous code checking is built into the build pipeline and runs on every significant change, not at the end of the cycle.
Analysis proceeds along two lines: static analysis of the call tree on the current branch with Slither and scenario runs for invariants in an isolated network.
A finding arrives with a call trace and minimal reproduction — it is confirmed or refuted, not debated over the wording of a warning.
What this changes item by item:
- Removed failure class. Reentrancy, access control errors, and overflows are cut off before the release branch is built — they can no longer be deployed to mainnet.
- Review before release. The change report arrives at review, not a week after deployment, so fixes land in the same cycle.
- Managed finding flow. Critical items are raised to the top, duplicates are collapsed, noise is filtered out by rules — instead of an avalanche before launch, the team gets a prioritized queue.
- Release timeline. Checking runs in parallel with development, and final review stops being a separate waiting stage.
- Fewer manual runs. Automation covers routine checks, while manual review remains for protocol economics logic and admin rights.
The checking policy lives in the repository: the rule set, the release blocking threshold, and the decision history for each finding.
The share of changes checked before release and the number of findings per release are visible in the report — quality stops being discussed in words.
Code checking modes: one-time audit and continuous loop
No single checking mode provides the full picture on its own — they cover different classes of defects. A one-time contract audit catches logic errors that cannot be described by a template, but by the next commit its conclusions are outdated.
A continuous checking loop triggers on every change, but sees only what has been formalized by a rule or scenario. The choice depends on where the contract is in its lifecycle and what the cost of an error is.
| Approach | When it fits | Limitations |
|---|---|---|
| One-time manual audit | before freezing logic and deploying to the network, when access rights and payouts are non-standard | the result lasts until the first change; the check must be performed again |
| Static analysis | continuous checking on every commit: overflows, reentrancy, unsafe external calls | some findings are false; call order between contracts is not visible |
| Scenario runs | economic branches: liquidations, auctions, boundary amounts, rare call sequences | coverage depends on the paths built in — an unchecked path remains a hole |
| Formal property proof | core invariants: balance convergence, withdrawal unavailability after blocking | requires explicit formulation of properties and does not cover external dependencies |
How the modes combine
Static analysis runs on every commit, scenarios run in a nightly pass, properties are proved for the core, and a manual audit is brought in before a major release or a change in the access model.
Cheap checks cut off mass defects, while expensive ones go to the areas where an error costs the most.
How implementation proceeds: steps from audit to handover
Implementation proceeds in one- to two-week iterations: first we capture the current state of the contracts, then assemble the checking loop, and only after that integrate it into the release process.
The order is exactly this — if rules are configured immediately without an inventory, the analyzer starts making noise on the project's legitimate patterns, and the team stops trusting it.
- Contract code audit. We compile a list of contracts, their versions, relationships between them, role rights, and external calls. The output is a map of what needs to be checked at all.
- Checking loop scheme. We determine where analysis runs: on every change, before branch merge, or on a schedule for already deployed contracts.
- Rule configuration. We enable checks for domain logic: access control, handling of external calls, order of state changes. Irrelevant rules are disabled to avoid creating noise.
- Test scenarios. We run the loop on historical releases and on intentionally introduced errors — we see what it catches and what it misses.
- False positive triage. We label each disputed finding together with your team: confirmed issue, acceptable pattern, or gap in the rule. Based on the results, the rules are adjusted.
- Integration into the development process. Checking becomes a mandatory step before release, with a clear status and a threshold at which the release is blocked.
- Documentation handover and training. We provide a description of the loop, the rule set with rationale, instructions for triaging findings, and conduct team training.
Readiness is recorded by measurable criteria: the share of false positives on your code, the checking time for one change, and the number of findings confirmed as real. If the rules produce noise above the agreed threshold, the stage is not closed.
Handover artifacts: rules, schemes, and run regulations
Handover of the loop is not a final report but a set of artifacts that remain in your repository and work without us. If the team cannot run the check itself, triage a finding, and explain the origin of the result, the work is not closed.
- Role and access rights map: who runs the passes, who confirms a finding, who edits triage rules, who sees only reports. Rights are granted in groups — no permanent personal access remains.
- Architecture scheme: loop components, trust boundaries, and points where contract source code leaves your perimeter and how the result comes back.
- Triage configurations: rule files, trigger thresholds, and a list of suppressed warnings with rationale — everything is versioned alongside the code.
- Run regulations: what triggers the check (code change, release preparation, scheduled run), depth, expected time, and loop behavior on failure.
- Set of verification scenarios: contracts with known defects, which show that after refinements the loop did not start missing what it caught before.
- Finding triage procedure: criticality levels, response time for each, who makes the decision, and how the verdict "take into work" or "false positive" is recorded.
- Loop documentation: how to update rules, what to do when build tools change, and where to look in logs if the result diverges.
Case study: code review before launch instead of post-factum audit
The client is a team releasing a protocol with smart contracts where an error in transfer logic means loss of funds with no rollback.
Before implementing checking, they worked post-factum: auditors joined frozen code a few days before release, and between audits developers merged changes without automated checking.
Reports arrived in batches of warnings, a significant portion of which turned out to be false, and after a couple of weeks they stopped being read.
We assembled a loop that runs on every change. The core is the Slither analyzer, supplemented by a model trained on labeled findings from this specific project: it ranks warnings by the probability of real exploitation and cuts off template noise. The verdict on a commit arrives in the merge request before review, not after merge.
Metrics before and after
The share of vulnerabilities removed before release rose from about half to 92% — the rest goes into the fix plan, not into incidents. The share of false positives fell from 60% to 12%, so the report is looked at rather than ignored.
The time from commit to verdict on changes decreased from half an hour of manual review to 6-8 minutes of automated run.
On release timeline this had the opposite effect: the release cycle shrank from three weeks to nine days, because security fixes stopped accumulating into a separate phase at the end.
Most valuable is that the finding reaches the author of the change while the context is still fresh in mind.
How does AI analysis differ from rules and signature search?
Signature search and rules work by parsing code into a tree and searching for known patterns: calling an external address before a state change, an unchecked call result, permission checking by transaction origin.
Where a vulnerability class fits a pattern, the approach gives an accurate and explainable result — the finding can be shown on a specific line and a specific execution path.
The limit begins where the pattern stops matching reality. Proxy contracts, wrappers over third-party libraries, composite call chains through several contracts — rules crumble into dozens of special cases.
Formal methods close part of the gap: they prove invariants, but require manual specification and transfer poorly to code that changes every week.
AI code analysis removes this limitation differently: the model is trained on labeled findings — confirmed and refuted. It learns to distinguish a finding that an engineer closed as false from a real path to exploiting a vulnerability, and ranks output by probability.
Slither provides a fast first pass over known classes — the model refines what did not fit the pattern.
In practice the combination looks like this: rules provide cheap coverage of known classes, formal methods provide proofs on critical areas, and the model removes the main burden of false positives.
The share of findings that go into the report without manual rechecking is growing — it is exactly what determines how much time triage takes before a contract release.
Questions engineers ask before starting
Before starting, engineers ask the same questions: where the boundary is between automated analysis and manual audit, how much noise the model produces, and how its output will reach the build pipeline.
The model traverses the contract in full, including branches an auditor does not reach in limited time; economic scenarios and verification of critical findings remain with the human.
How many false positives will there be?
On the first run, the threshold is shifted toward completeness: an extra finding is better than a miss. Then the filter is tuned to your contracts, and each finding comes with a code fragment and a confidence level.
The contract is already deployed — is there any point in checking?
Analysis is performed on the published code and bytecode: owner rights, available functions, reception of external calls. This shows exactly what the deployed version is at risk of.
How should upgradeable contracts be checked?
Analysis is not one-time: the new implementation goes through the same checks before publication, and logic and storage are compared between versions. Otherwise a fix quietly opens what was closed.
Where should private code be sent?
It does not need to be posted to public services: analysis is performed in an isolated loop, access is role-based, and results remain with you. The workflow and deletion of copies are documented in writing.
How can checking be integrated into the build pipeline?
As a separate step before publication: trigger on changes, machine-readable report, release blocking when findings exceed a specified threshold.
Let's discuss the task and come back with an estimate and plan
To make the project estimate rest on facts rather than guesses, a few inputs are enough for the conversation. There is no need to send all the code in advance — it is important to understand how checking is integrated into your development and review process.
- List of networks and contract types: tokens, bridges, lending protocols — exactly what needs to be checked.
- Repository or archive with examples — at least a few contracts in their current state.
- Vulnerability classes critical to you specifically: reentrancy, access control errors, overflows.
- How findings reach developers: report, ticket in the tracker, comment on a code change.
- Access restrictions: where the code lives, what can be connected to the build loop.
- Who approves the rules and triages false positives.
- Accumulated examples of findings and misses — we use them to tune sensitivity.
In response you receive a loop scheme: where vulnerability analysis sits, how it is connected to the build and change checking, where results are stored, and how they reach tasks. Then a staged work plan with control points and the date of the first trial run on your contracts.
Based on the run results, it is visible what share of findings engineers confirm and how many go into noise — the final project estimate is built on these numbers.
