AI generation of smart contracts: where the process breaks
The model confidently produces code, it compiles, and stub tests pass — and that is exactly why the failure looks harmless.
AI generation of smart contracts shifts errors from syntax to semantics: the compiler catches a typo, but it does not analyze the order of checks and withdrawal rights.
The most common group is errors in generated code around transfers. Funds are sent before balances are updated, the return value of a low-level call is ignored, token decimals and fees are not taken into account.
Checking transfer logic on a copy of the main network with real balances exposes this in minutes — if such a check is provided for at all.
The second group is access rights and external calls. The withdrawal function remains public without a modifier, initialization is called again, an external contract gets control before state is finalized.
Such a contract vulnerability does not break the build, but it provides a ready-made withdrawal scenario.
A separate cost is deployment without verification. A compiled Solidity contract is immutable: an incorrect threshold or recipient address cannot be fixed by an update; state migration and reissuing addresses for everyone already interacting with the contract are required.
That is why we keep generation as a draft, not as a release: next come manual review of rights, order of checks, automated input fuzzing, and attack simulation on a network copy. Below is how this is covered step by step.
Generation speed versus the cost of a logic error
Generation from a formalized description compresses the release of the first version of a contract and edits to it.
The skeleton — access roles, events, input argument checks, state parsing — is assembled in one pass, and changing a rule leads to a coordinated update of related places rather than manual edits in five functions.
Mechanical error classes disappear fastest: a missing zero-address check, incorrect order of operations, a forgotten state transition.
The most expensive things are what generation does not see: economic logic, order of external calls, state invariants under competing transactions.
They are formulated manually and checked with property runs on random inputs — Echidna selects them itself and breaks the contract where examples did not think of it.
| What we check | What we cover it with | What remains for review |
|---|---|---|
| Syntax, order of checks, access restrictions | Template-based generation and static analysis | Role model and trust boundaries |
| State invariants, balance integrity | Property runs on random inputs | Formulation of the invariants themselves |
| Economic logic, reentrancy, transaction rollback | Manual scenarios and failure tests | Threat model |
The time budget should be divided consciously: generation covers release and edits, while investment goes into invariants, failure tests, and pre-deployment verification.
A run on a test network with the same parameters as on the main network is mandatory — what is saved on generation cannot be taken back from verification.
Contract creation modes: manual, template, generative
Contract creation mode determines not the speed of writing code, but the amount of attention that remains for checking logic.
Manual contract development gives full control over storage structure and call order — this is mandatory where an error in one branch of a condition leads to loss of funds. Template contracts lock in an already verified scheme: token issuance, roles, pause, withdrawal limits. All that remains is to fill in parameters and not reinvent the rights model.
| Mode | When it fits | Limitations |
|---|---|---|
| Manual contract development | Unique economics, non-standard rights, calculations with external data sources | Longer cycle, higher requirements for test coverage and external audit |
| Template contracts | Typical scenarios: token, payout distribution, multi-signature wallet | Logic is limited by the template; a non-standard requirement breaks its rights model |
| Generative mode | Skeleton for a non-typical scenario, tests, migrations, auxiliary modules | Review is mandatory: arithmetic, outdated syntax, hidden external calls |
Generative mode speeds up the draft but does not replace verification. The model assembles the skeleton and supporting code for a specific task, while the engineer checks arithmetic, rights, and external calls line by line: unverified code does not enter the deployment script.
The choice of mode comes from the nature of the task, not from fashion. In practice, we combine: a generative draft for the skeleton, template modules for typical parts, manual refinement of the core and boundaries where the cost of an error is highest.
Stages of work: from task analysis to handover to operation
Code generation by a model is a draft, not a finished artifact: it quickly provides the contract structure, but it is not responsible for edge states and call rights. Therefore, a normal engineering process is built around AI generation, where every result is verifiable. Below are the implementation stages we go through on a project.
- Requirements analysis and state diagram. We fix roles, transitions, and invariants: what the contract allows and what it always prohibits. The diagram is agreed upon before writing code — later, changing it costs more.
- Draft generation. The model assembles the Solidity contract structure according to the agreed diagram: storage, functions, events. We set constraints and style in advance so the code is easy to maintain.
- Security checks. Static analysis, tests on boundary and random datasets, manual review of access rights and external calls. Every found issue becomes a test that will no longer miss it.
- Run on a test network. We reproduce real operation sequences, including erroneous ones: transaction rollback, repeated call, unavailability of an external service.
- Acceptance of the result. We verify coverage of key paths by tests and divergence from the original requirements; a report with checks goes to the client.
- Handover to operation. Deployment, fixing environment parameters, training the client's team to launch and monitor the contract's operation.
- Change procedure. How a change is made, who approves it, what checks are mandatory before redeployment.
Project artifacts: specifications, threat models, procedures
After handover, the client's team retains a set of documents by which contracts can be developed and maintained without us.
This is not a folder with files, but a connected set: the specification defines behavior, the threat model defines trust boundaries, and the change procedure defines the order of changes.
Every artifact is checked against the code at handover: if the description of invariants diverges from the logic, the work is not accepted. Below is what remains in hand.
- Contract specification — roles, states and transitions, external calls and events: what the contract must do and what is prohibited.
- Invariant description — conditions that hold under any scenario, tied to code sections and automated tests.
- Threat model — attack vectors against a specific contract, impact assessment, and built-in restrictions: limits, withdrawal delays, pause.
- Change procedure — who makes changes and how, what checks are mandatory before an update, how to roll back to a previous version.
- Access rights — a map of roles and keys: who has what authority, where they are stored, how they are transferred and revoked.
- Maintenance documentation — deployment, state migrations, event monitoring, typical failures, and response procedures.
- Verification report — what was found during static analysis and manual review, what was fixed, what was deliberately left.
The document set lives with the code: an edit entails updating the specification and threat model, otherwise the documentation diverges from the contract within a couple of weeks.
Case: share of failures in transfer logic dropped threefold
Client — a platform for regular partner payouts. Transfer contracts were written manually for each campaign: rights were held by a single developer key, there were no limits on amounts and recipients, and there was no separate role for stopping operations.
Over a quarter, several incidents accumulated: transfers went to an address from the test environment, some payouts went through twice on a repeated call, and there was no way to revoke an erroneous operation.
Our engineers moved contract release to generation from verified templates: the static analyzer Slither runs every variant and blocks deployment if there are findings.
Roles were separated — payment initiator, confirmer, treasury administrator, and a separate pause role; critical actions require two confirmations.
What changed
The share of incidents in transfer logic fell threefold: from nine requests per quarter to three, and all three were errors in input data, not in code.
Releasing a new contract takes hours instead of several days, and the share of automatically verifiable paths grew from 40 to 90%.
Limits are set both per operation and per day, so one error no longer takes out the entire treasury.
Review is done via the journal: you can see which role initiated the operation, who confirmed it, and at which step the restriction triggered; rollback is pause and repeat transfer, without editing and redeploying the contract.
How does formal verification differ from code audit?
Formal verification and code audit answer different questions and do not replace each other. The first proves properties: according to the specification, it mathematically verifies that no execution path violates it. The second reads the implementation and looks for what was not in the specification.
Property proof runs through all branches, including rare ones: balance invariant, unreachability of negative accounting, preservation of administrator rights.
But exactly what is formulated is checked — a property that did not make it into the model will not be seen by formal verification. This is its boundary of applicability.
Audit gets what cannot be formalized: economic assumptions, order of external calls, behavior of oracles and counterparties, logic of admin functions.
Manual scenarios catch an error in the intent — when the contract does exactly what is written, but what is written is not what the product needs. The model will confirm such an error, not find it.
Hence the main risk — a false sense of security. The 'formally verified' mark does not say that the specification is correct, and a passed audit does not guarantee the absence of an error in a rare path that was not manually played through.
Therefore, we divide the perimeter: core invariants — accounting, rights, limits — go into formal models; integrations and admin contours are covered by audit with manual scenarios. In the report, we separately list what remains unproven.
Common technical doubts before starting
Doubts before starting are almost always the same: who is responsible for an error in logic, what to do with an already deployed contract, who owns the rights to the result, and whether the code can be verified without publishing it publicly. Below are direct answers, without caveats in the spirit of 'it depends on the task'.
Who is responsible if an error is found in the contract?
We are responsible for the compliance of the generated code with the agreed logic.
Edge states, rights to call methods, and the order of debits are described before generation, and any divergence found during verification is eliminated before acceptance — not as a separate estimate.
We already have a deployed contract — can it be modified?
Yes. We capture the current state on the network, compare the logic with the actual behavior, and propose a plan: a targeted fix, an upgrade via proxy, or redeployment with transfer of accumulated records and access rights.
Who owns the rights to the code?
Exclusive rights to the source code, configurations, and description transfer to the client after acceptance — without restrictions on modification by third-party engineers. Our internal developments enter the project as ordinary dependencies with an open license.
Can the result be verified without publishing the source code?
Yes. Test runs are performed in the client's closed environment or in an isolated environment; you receive a report, a state diagram, and an analysis of critical paths. Publication in a public registry is a separate decision; it is not required for logic verification.
What is included in post-launch support?
Monitoring contract events, incident response, dependency updates, and edits due to changing requirements. We separately fix the on-call procedure and response time to a request.
Let's discuss the task and come back with an estimate and plan
An accurate estimate of work rests not on guesses, but on source data. The more specifically you describe the contracts and their place in the product, the fewer assumptions we will include in the implementation plan — and the less often deadlines will slip during the process.
- Role of contracts in the product: token and distribution, escrow, voting, paid access — the scope of logic and depth of checks depends on this.
- Target network and compatibility requirements: whether ERC-20, ERC-721, or ERC-1155 standards are needed, external calls to oracles and bridges.
- Existing code: current contracts, templates, and developments — we will review them and say what we reuse and what we rewrite.
- Rights model: who issues, freezes, and updates the contract; whether roles, pause, multi-signature, and a logic upgrade mechanism are needed.
- Integrations: wallets, backend, indexers, and external services with which the contract exchanges data.
- Expected load and sensitivity to transaction cost — affects data structures and state storage.
- Work format and timelines: one-time generation with verification or support with modifications after launch.
After the analysis, we will come back with a stage-by-stage implementation plan and review points, a list of checks — static analysis, fuzzing, test coverage of critical paths — a risk map with probability assessment and rollback scenarios, as well as the scope of work and timelines for each stage.
Describe the task in free form: that is enough to discuss it substantively and come back with an estimate and plan.
