What to check before you deploy a vibe-coded smart contract to mainnet

If your blockchain app built with AI tools works on a test network, the next stretch runs to real money. Mainnet is the real network, where transactions move real value. We suggest this order: whether you need a blockchain at all, what the contract lets people do, where the keys live, and what has to happen on a testnet and in an audit before mainnet. ethereum.org says deployed contract code usually cannot be changed to patch security flaws, so all of it comes first.

On 3 February 2026, researchers at Deakin University posted a study of Solidity smart contracts that three AI coding agents had written. The contracts were syntactically correct and functionally complete, the authors report, yet many carried security flaws that could be exploited in real-world settings. What they counted were findings of one static analysis tool, a program that scans code for known mistakes, not attacks (arXiv study of LLM-generated smart contracts, 3 February 2026).

On 29 October 2026 we planted four problems in a demo fan-token project and ran the five commands below on it. The problems were an open mint function, a withdraw that pays out before it updates the balance, a version mismatch and a key committed to git.

Where do I start without risking real money?

Work on a copy of the project, made without .env files or any file that holds a real key. Use a test network only, with new accounts that hold nothing of value. The ethereum.org Networks page does not recommend reusing mainnet accounts on testnets, or the other way round.

While you check, do not deploy to mainnet, do not move real funds and do not paste a real key anywhere. Stop after 60 minutes and write down what you still do not know.

Does my app need a blockchain at all?

Possibly not, and whether you need a blockchain is the question that comes before any Solidity. Many organisations start from a wish to use a blockchain somewhere and then look for a place, NIST's 2018 overview says. It recommends the reverse: understand where the technology fits, then find the systems that match (NIST IR 8202, Blockchain Technology Overview, October 2018).

The features NIST lists as making a blockchain suitable include many participants, distributed participants, and a want or need for no trusted third party. It also names further factors to weigh. Data on a permissionless network is generally public, there is no removal process for the original data, and many permissionless networks process transactions more slowly than other IT systems.

Answer three questions in writing. They are our advice, not NIST's rule.

1. Who writes to the record, and do the readers trust that writer? If it is only your app, and your users trust you, the features NIST lists are not what the app needs.
2. Does anyone outside your company have to verify the record without asking you?
3. Would you be comfortable with this data being public and permanent?

If the answers are "only us", "no" and "no", compare a regular database with backups before you spend another week on contracts.

What did the Deakin study find in AI-written Solidity?

Between 47.4% and over 75% of an agent's contracts had at least one vulnerability, depending on the agent. The authors report 1,033 contracts from three coding agents, checked with Slither, a static analysis tool. Low-severity findings were the largest group for all three agents (arXiv study).

The 34 prompts were worded the way an inexperienced developer might describe an idea, and each was run 10 times per agent. The paper's own count does not add up to exactly that design, so treat the total as approximate.

These are findings of one tool on single contracts, so read them as a pattern for your app, not a rate. The categories counted include lack of input validation, denial of service, insecure randomness, arithmetic issues, unchecked external calls, reentrancy, logical errors and access control. The authors also report that more lines of code meant more findings.

The OWASP Smart Contract Top 10 for 2026 is a general list of smart contract risks, not one about AI-written code. It builds on 2025 incident data covering 122 smart contract incidents, and it ranks access control vulnerabilities first and business logic vulnerabilities second.

What should I ask the person reviewing the contract?

Turn those risks into five questions. Our demo contract failed two of them and raised a third.

1. Who can call each function that moves money or changes who is in charge? Any account can call a public or external function, which is a problem if anyone can then perform a sensitive operation such as minting tokens (ethereum.org, Smart contract security). Our demo's mint function was public with no check on who calls it, so anyone could mint.
2. Does the money math follow rules you can state in plain sentences? OWASP describes business logic flaws as design-level flaws that break the intended rules. Write each rule as a sentence and ask for one test per rule.
3. Is a balance updated before money is sent out? A malicious contract can call back into a vulnerable one before the first call finishes, ethereum.org explains. It recommends the checks-effects-interactions order: checks, then state changes, then calls to other accounts. Our demo's withdraw sent ETH before it set the balance to zero, the order ethereum.org warns about.
4. Which Solidity version does the code use? Since version 0.8.0 the compiler rejects code that overflows or underflows an integer, and older versions need explicit checks or a library (ethereum.org). The line that starts with pragma solidity shows which versions a file accepts. The version actually used is set in the project's build settings, so ask for both. In our demo the two disagreed: the pragma line said ^0.7.6 and the build setting named 0.8.24.
5. How much of this code is needed? The study says AI models sometimes add unnecessary code and sometimes invent functions that do not exist. ethereum.org advises reusing audited libraries such as OpenZeppelin Contracts.

Three commands in your own terminal point to the places for questions 1 and 4. Our demo's build settings were in hardhat.config.js; on another setup, search the file that names the compiler version.

grep -rn "pragma solidity" contracts
grep -n solidity hardhat.config.js
grep -nE "function .*(public|external)" contracts/*.sol

On the demo the last command printed the mint and withdraw lines, two functions to read in full.

You can also paste this prompt into your AI tool while it works in a copy of the project.

Read only. Do not edit, create or delete any file, and do not run any command.
Do not open .env files and do not print any key, seed phrase or secret: give the file name and line number only.
Read the Solidity files in CONTRACTS-FOLDER and write a table with one row per public or external function: its name, who is allowed to call it, whether it moves ETH or tokens, whether it changes an owner, admin or upgrade address, and which external calls it makes.
Then list: the Solidity version range on the pragma line of each file; every place a state variable is updated after an external call; every owner, admin or role address and where it is set; every place the code reads a private key, a seed phrase or an environment variable, with file name and line number only.
Do not suggest fixes. If something cannot be answered from the code, write UNKNOWN. Stop after the table and the lists.

Treat its answer as leads to open, not as findings. The study's authors write that an LLM-based self review by developers cannot replace rigorous verification and independent auditing.

Where do the keys and wallets live?

Outside the code and out of your AI tool's reach. A private key is what proves that you may move funds or change a contract, so it never goes into the repository, a prompt, a chat or a rules file for an AI tool. NIST says that whoever steals a private key gets full access to all digital assets that key controls, and that a transfer made with it generally cannot be undone.

OWASP's list of attack vectors beyond contract code says that many of the largest losses of 2025 came from off-chain and operational threats, among them multisig manipulation, supply chain attacks, drainer malware and phishing.

Four rules follow.

1. Use separate keys for separate jobs: a throwaway key for the testnet, one for deploying, one for administering the contract. ethereum.org advises against reusing accounts between testnets and mainnet.
2. Do not let one account control the contract. A single owner address is a single point of failure, ethereum.org says, and if its keys are compromised the attacker can attack the contract. It suggests multiple administrative accounts or a multisig wallet that needs a minimum number of signatures, for example 3 of 5. A multisig only helps if each signer is a different person or device, with keys guarded like any other key.
3. Keep signing keys on a hardware wallet or another store that your AI tool cannot read. NIST notes that many users store private keys on special secure hardware.
4. If a real key was ever in the repository, in its history, or pasted into a chat, treat it as exposed and mark the check sheet at the end NOT READY. Do not move funds during this check. Replacing the key means a new key, moving what the old one holds and removing its roles on the contract, as a separate, planned step.

To look for secrets in a copy of the project, run these two commands in your own terminal window, not through an AI tool.

/usr/bin/grep -rIlE -i "private_key|mnemonic|seed phrase|secret" . --exclude-dir=node_modules --exclude-dir=.git
git log --all --full-history --oneline -- '*.env*'

The first command lists the names of files that mention those words, and the second lists commits that touched an env file. Both can list harmless files. An empty result means these commands found nothing, not that nothing exists.

On our demo the first command listed three files. The build config reads the key from the environment, as expected, and a README only warns about keys. The .env held one: the real finding. The second listed the commit that added the .env and the one that untracked it; the key was still in the history of the first. In a second scratch repository that day, git show of the commit that added the .env printed the demo key: it stays in the history until the history is rewritten.

The first command calls grep by its full path because on our Mac the shell's grep was a function wrapping another search tool, ugrep. It skipped the hidden .env file; /usr/bin/grep listed it.

What must happen on a testnet and in an audit before mainnet?

Our suggested order is to rehearse the contract on a testnet, have someone who did not write it review it, and fix what they find. Then rehearse the final version again, and only then deploy to mainnet. ethereum.org says to test any contract code on a testnet before deploying to Mainnet, and that deployed contract code usually cannot be changed to patch security flaws. So every gate below happens before launch.

ethereum.org describes an emergency stop, a function that blocks calls to vulnerable functions. It suggests decentralising its control with a timelock or a multisig, because the stop increases the need for users to trust whoever can activate it.

Decide in writing who can pause, who can upgrade and what each of them can do. A right to pause or upgrade is also a power someone can abuse or steal, so protect it like the admin key. An upgrade path is itself something to audit: OWASP ranks proxy and upgradeability vulnerabilities tenth in its 2026 list.

What does this look like on one app?

Picture a founder who builds a fan-rewards app with an AI tool. Members earn tokens for attending matches, and an admin function mints more.

The founder asks who can call that function, whether anyone but the allowed caller can mint and who can pause it. The answers go on the sheet at the end. Say the AI also puts the deployer key in a config file. That key counts as exposed, the sheet says NOT READY and a replacement is planned as a separate step.

All four problems we planted in our demo land on the sheet before any testnet run: a mint with no allowed caller (line 2), a withdraw that pays before it zeroes the balance (line 4), a pragma that disagrees with the build setting (line 5) and a key in the git history (line 6). On a real project, a real key in the history would on its own make the sheet NOT READY, by key rule 4 above.

After the fixes, the testnet rehearsal of the final version has to show that only the allowed caller can mint, that the pause works and that the deploy steps work. A line that stays UNKNOWN means the contract waits.

What are the limits of these sources and checks?

The Deakin paper's arXiv page does not say that it was peer reviewed. It used one static analysis tool on single contracts. Each contract came from one request, the prompts were themselves written by an AI model, and the paper reports no comparison with human-written contracts.

Its authors say they used Slither's own classification, which leaves out flash loan vulnerabilities. They also say Slither cannot detect complex and market-based vulnerabilities.

NIST's report is from October 2018 and describes blockchain in general, not smart contract coding. The study and the ethereum.org pages concern Solidity on Ethereum, while NIST and OWASP are broader. Other chains, token law, and the code of a website that connects to a wallet are not covered here. For that website, our four levels of launch checks depend on who can open the app, what data it holds and whether money moves.

Our own run on 29 October 2026 used a demo project built for the check, and the commands above pointed at each problem we had planted. None of this replaces an audit. If your answers to the three questions say you do not need a blockchain, skip the contract sections.

What can I check today?

Give it 60 minutes on a copy. Fill in the sheet below and mark each line OK, UNKNOWN or NOT READY; a line you could not check stays UNKNOWN.

WEB3 LAUNCH CHECK SHEET (work on a copy, testnet only, throwaway keys, stop after 60 minutes)
PROJECT:
CHAIN AND TESTNET:
CHECKED BY AND DATE:

1 NEED FOR A BLOCKCHAIN: WHO WRITES: ____ | WHO MUST VERIFY WITHOUT ASKING US: ____ | DATA MAY BE PUBLIC AND PERMANENT: YES / NO | DECISION: NEEDED / NOT NEEDED / UNKNOWN
2 CALLERS: FUNCTIONS THAT MOVE MONEY OR CHANGE CONTROL: ____ | EACH HAS A NAMED ALLOWED CALLER: YES / NO | STATUS: OK / UNKNOWN / NOT READY
3 MONEY RULES: RULES WRITTEN AS SENTENCES: ____ | TEST PER RULE: YES / NO | STATUS:
4 EXTERNAL CALLS: BALANCE UPDATED BEFORE SENDING: YES / NO / UNKNOWN | STATUS:
5 SOLIDITY VERSION: PRAGMA ____ | BUILD SETTING ____ | CODE I CANNOT EXPLAIN: ____ | STATUS:
6 KEYS: KEY WORDS FOUND IN CODE OR HISTORY: ____ | KEYS PER JOB: TESTNET / DEPLOY / ADMIN | ADMIN IS A MULTISIG: YES / NO | STATUS:
7 TESTS AND TOOLS: UNIT TESTS RUN: YES / NO | STATIC ANALYSIS RUN: YES / NO | TESTNET REHEARSAL OF THE DEPLOY STEPS: YES / NO | STATUS:
8 AUDIT AND FAILURE PLAN: INDEPENDENT AUDIT DONE: YES / NO | WHO CAN PAUSE: ____ | WHO CAN UPGRADE: ____ | MONITORING: YES / NO | STATUS:

NOT OK COUNT: ____
NOTES: EVERY UNKNOWN AND NOT READY LINE, WITH WHAT YOU SAW

Next step

Sources

Checked on 11 October 2026.

• arXiv, study of LLM-generated smart contracts (Deakin University), 3 February 2026
• OWASP Smart Contract Top 10, 2026
• NIST IR 8202, Blockchain Technology Overview, October 2018
• ethereum.org, Smart contract security
• ethereum.org, Networks