How injecting an auditor’s mindset into the development loop catches vulnerabilities before the contract is frozen.
Smart-contract projects typically involve two distinct activities before a contract ships: implementation and independent security review. These may overlap in practice, but they are usually owned and approached by different teams with a significantly different knowledge set.
Phase one is implementation: the Solidity contracts, together with their test suite, deployment tooling, and off-chain ‘harness ’, i.e. integrations with backend and services that connect to the contract. The contract is almost always written in Solidity (Ethereum/EV-compliant network); the surrounding tooling is often written in Python or TypeScript.
Phase two is independent security review. An audit team examines the code, its design assumptions and relevant attack paths from a fresh adversarial perspective. The question is not merely whether the contract works as intended, but how it may fail when it meets hostile inputs, integrations or incentives.
Strong auditors know dozens of vulnerability classes by heart, and approach the code with a suspicious, independent mindset — constantly testing assumptions, privilege boundaries, invariants, and external dependencies.
Because implementation and independent review are usually separated in time, and in most cases require more than a single iteration, a significant part of contract development is spent on the round trip between them, rather than on writing the code itself. To a large extent, this is understandable, yet the cost in terms of time and team effort remains.
In many of the projects I was involved in, a large portion of total completion time went into audit/repair cycles: code that passed my own review, then came back flagged, then got patched, then went back for another pass.
The idea
After enough of these cycles, a clearer and more efficient approach became obvious. A development team may understand the system deeply, but it cannot keep every known failure mode and attack path actively in working memory while it is delivering features.
Auditors add an independent, adversarial perspective. My goal is not to replace that perspective, but rather, to bring this type of knowledge and critical thinking into the process way earlier. In fact: while the code is being written.
And, once AI is introduced into the process, the implementation becomes straightforward: first, obtain a curated vulnerability-database with is (sort of) well known in the community.
Once you have it, turn it into an AI skill that either a human developer or an AI coding agent can consult and activate during the ongoing development effort. This simple change significantly improves the effectiveness of the development process.
A 293-entry security knowledge base
I built this as an open-source tool called Smart-Contract-AI-Audit-Skill. It contains 293 known Solidity vulnerability and security-pattern entries, assembled from public audit findings, security registries, best-practice guides, proof-of-concept collections, and Solidity’s security documentation. The sources I mostly used were Solodit’s audit-finding catalog, the SWC Registry, ConsenSys and SCSFG best-practice material, DeFiVulnLabs’ proof-of-concept collection, and Solidity’s security-considerations documentation.
I began with 411 raw entries. Many described the same underlying issue from different sources or in different terms, so I merged duplicates while preserving a trail back to their original sources.
The resulting workflow supports two distinct modes.
Audit mode — code already written.
Give it a Solidity codebase, and it will check the relevant vulnerability entries against that code. For each possible finding, it reports the affected location, explains the failure mechanism, sets a severity score and suggests a concrete fix. Also, when the problem cannot be deduced from code structure but rather depends on runtime behaviour, it recommends which test should be added. These are candidate findings for review — not proof that the contract is secure.
CODING mode — while coding.
Same database, opposite direction. While you are writing or editing Solidity, the skill routes what you are working on into the relevant category checklists: a withdraw function pulls in Reentrancy plus External Calls, a price feed pulls in Oracle, touching an upgradeable contract pulls in Proxy & Upgradeability and Storage. Each checklist entry gives you a Don’t (the failure mode) and a Do / Detection (the concrete fix or check), with wording lifted straight from the database entry and a line pointer back to the full record if you need the aliases or the source citation. Most functions only touch one to three categories, so you never read all 21 files for a single function. There is also a short always-on list — 28 Critical and Critical/High items worth knowing by default no matter what you are touching. The rule is simple: consult the relevant checklist before you consider a function done, not after.
Note, that is not a deterministic static-analysis engine, but rather AI-guided review workflow. It uses the vulnerability entries to direct review and testing; its output is intended to guide human verification, not replace it.
As part of my work here, I tested the workflow against seven public Solidity targets, which I believe make up a decent representation of the types of vulnerabilities smart contracts may experience.
The test list is made of two clean baselines (OpenZeppelin’s current ERC20 implementation and WETH9), three deliberately vulnerable teaching examples, and two production contracts from GitHub: Uniswap V2’s pair and SushiSwap’s MasterChef. This is a small validation exercise, not a benchmark of detection accuracy, false-positive rate or audit coverage.
After compiling this list, I ran the AI-audit workflow and reviewed the resulting audit results. As expected, no critical/high findings were detected in the baselines contracts; rather, it surfaced the intended issues in the deliberately vulnerable examples. On Ethernaut’s Delegation, it identified the dangerous unrestricted delegatecall path that allows callee logic to write to the caller’s storage. On MasterChef, it raised a potential reentrancy concern in emergencyWithdraw because the token transfer occurs before the user state is cleared. That concern still requires a reproducible exploit path and independent review before it should be treated as a confirmed vulnerability.
A representative audit-mode result from Ethernaut’s Delegation challenge. The workflow identifies the unrestricted delegatecall path, traces its storage-impact mechanism, and links the finding to the supporting security entry.
Delegation is deliberately vulnerable. This example demonstrates the form and traceability of the output. It is not a benchmark of real-world detection accuracy.
Where this genuinely helps (and where not)
Some entries can be assessed primarily from code structure — for example, missing access control or a state update placed after an external interaction. For those cases, the workflow can identify relevant locations and suggest a remediation for review.
Other entries depend on behaviour rather than shape: whether a meaningful test exists, whether a particular state transition is reachable, or whether an external call can be exploited in context. The audit workflow can inspect the code and recommend the tests to add, but it cannot prove that those tests cover the relevant behaviour or were executed in a representative environment.
Of course, this is not intended to replace static analysis tools e.g., Slither. Static analysis is stronger at many mechanical static checks. Rather, it is aimed at review questions that require context , cases where a function may look reasonable in isolation but becomes dangerous because of its role in the surrounding protocol.
As is true to human contract auditing, code vulnerability detection is one layer of smart-contract security. The highest-impact failures are often protocol-specific: incorrect accounting, price and liquidation assumptions, privileged roles, upgrade paths, and cross-contract interactions. This workflow can bring those questions into development earlier, but it does not derive the protocol’s security specification or replace independent adversarial review.
Another problem: will you want to maintain your code in six months?
The vulnerability database solves one half of the problem: do not ship a known bug class. The other half is a different kind of debt: code that is technically fine today but that nobody, including future you, will want to maintain in six months.
For that, I built a second, separate skill: Solidity-Smart-Contract-Best-Practices-Skill. It is not an audit methodology; it is a handbook for engineering quality: naming, layout, invariants, how you write and structure tests, how you handle reviews and deploys. Seventy-four items, every one citing where it comes from (Solidity’s own docs, OpenZeppelin, SCSFG, Trail of Bits, Solcurity, the SWC Registry, the Foundry Book), organized into categories like access control, checks-effects-interactions, upgradeability, and oracle handling.
The interesting design choice here is the same one from the audit skill, applied to a different problem. Some of these 74 items are code-checkable: an AI can read the .sol file and just check whether the pattern is there. Others are test-checkable, meaning the item is not about the contract’s code at all; it is about whether a specific test exists for it, so the skill recognizes the situation that creates the need and tells you what the test should look like.
Try them
Feel free to use either skill on its own, or both together: the vulnerability database catching known attack patterns early, the best-practices skill keeping the code itself maintainable while you are at it.
Both repositories are intentionally curated rather than self-updating. Any extension should be sourced, reviewed and versioned before it is used on production code.
Both repos are also open source. If you try either one, I would genuinely like to know what it catches and what it misses.
Get the code: Smart-Contract-AI-Audit-Skill
Solidity-Smart-Contract-Best-Practices-Skill
If you are building Solidity systems and want to discuss adapting this workflow to your team, reach out on LinkedIn.
Top comments (0)