Ask It Simply
Build With AI · Advanced · Lesson C3

Test and audit smart contracts

about 10 minutes. Level: On-chain. Nothing to install: Remix in your browser, using the Remix VM test chain with play money. A copy-paste sample contract and answer key are below.

By Dontè

Education only. Not financial advice.

Education only. Not financial advice.

Watch the video

Lesson video, about 3 min 55 s. Captions are off by default. Press CC to turn them on. It starts muted. Press Sound to hear the lesson from the start. Press and hold the playing video (or hold the period key) to watch at 2x speed.
Show transcript

Welcome to Lesson C3. Before we start, this lesson is education only. It is not financial advice. Today you'll hunt for a bug with Grok, prove it on a test chain, and learn what an audit can and can't do.

In Lesson C2 you saw that contract code is hard to change after launch. So the time to find bugs is before.

Start with a list of common bugs. OWASP calls its Smart Contract Top 10, quote, "a standard awareness document providing Web3 developers and security teams with insights into the top 10 vulnerabilities found in smart contracts." End quote. Number one on the 2025 list is access control. OWASP says, quote, "Access control flaws allow unauthorized users to access or modify a contract's data or functions." End quote.

You might also find the older SWC Registry. It now says, quote, "this content is no longer actively maintained." End quote. Our tip: use OWASP's list first.

Now the hunt. This sample piggy bank has one serious bug, on purpose. Paste it into a new Remix file called PiggyBank dot sol.

Paste the prompt from the lesson page into Grok, then the contract. We say it's a practice contract for the Remix VM only, and ask for the most serious bug, who could abuse it, and a one-line fix. Pause the video and try it before we reveal the answer.

Here's the answer key. The withdraw all function has no owner check. Anyone can call it and take all the money. That's an access control bug, number one on OWASP's list. The fix is one line: require that the caller is the owner. Did Grok find the same bug? In our run, it did, and it suggested the same owner check. Our tip: an AI is a helpful second pair of eyes, not a security guarantee. It can miss bugs, or invent ones that aren't there.

Let's prove it. Deploy the piggy bank in the Remix VM with the first test account. Set value to one ether and press deposit. Now switch to the second test account, our pretend thief, and press withdraw all. It works. The thief took the play money. Now do the same with the fixed version. This time it fails, with the message Only the owner can withdraw.

So what's an audit? It's a paid review by security experts. Ethereum dot org says, quote, "Smart contract audits won't catch every bug." End quote. It also says, quote, "you should avoid treating audits as a silver bullet." End quote.

Here's a real example. Euler Finance writes that in March 2023, its protocol was exploited for about 197 million dollars in assets. And Euler also writes, quote, "Our audits invariably came back with excellent feedback from auditors." End quote. Audits lower risk. They don't remove it.

When you're ready, developers write automatic tests with tools like Foundry. It needs an install, so it's a next step, not part of this lesson.

Safety check. Our tip: never deploy a contract that holds real money without a professional audit. While you learn, stay in the Remix VM or on test networks.

Quick check. What was the bug? Anyone could withdraw, with no owner check. Does a good audit mean a contract is safe? No. If Grok says no bugs found, are you done? No. Check with tests and a human expert. Education only. Not financial advice. Next up is the Capstone, or try the bonus Lesson C4.

What you'll learn

Step 1: Why testing matters

In Lesson C2 you saw that contract code is hard to change after launch. So the time to find bugs is before.

Step 2: Know the common bugs

The OWASP Smart Contract Top 10 "is a standard awareness document providing Web3 developers and security teams with insights into the top 10 vulnerabilities found in smart contracts." Number one on its 2025 list is SC01, Access Control Vulnerabilities: "Access control flaws allow unauthorized users to access or modify a contract’s data or functions." (OWASP Smart Contract Top 10)

You may also see the older SWC Registry. It now says "this content is no longer actively maintained" and that it "has not been thoroughly updated since 2020." (SWC Registry) Our tip: use OWASP's list first.

Step 3: Hunt the bug with Grok

This sample piggy bank has one serious bug on purpose. Paste it into a new Remix file named PiggyBank.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// PRACTICE ONLY. This contract has a bug on purpose. Remix VM only.
contract PiggyBank {
    address public owner;

    constructor() {
        owner = msg.sender;        // whoever deploys it is the owner
    }

    function deposit() public payable {}

    function withdrawAll() public {
        payable(msg.sender).transfer(address(this).balance);
    }
}

Now paste this into Grok, followed by the contract:

I'm a beginner learning smart contract security. This is a PRACTICE contract
for the Remix VM only. Find the most serious bug. Explain in plain words who
could abuse it and how, then show a one-line fix. Here is the contract:

Grok's real answer (our test run)

We ran this exact prompt through Grok (model grok-4.7) on Oct 30, 2026. Grok's answers change from run to run, so yours will differ. Quoted as Grok returned it, except where we mark [trimmed] and where we swapped dashes for commas to match our style.

The most serious bug is a missing access-control check on withdrawAll.

Who can abuse it: Anyone, not just the owner. The contract stores owner in the constructor but never uses it.

How: After someone deposits ETH, any address can call withdrawAll(). That function sends the contract’s entire balance to msg.sender, so the caller drains the piggy bank.

One-line fix: Require the caller to be the owner before transferring:

function withdrawAll() public {
    require(msg.sender == owner, "not owner");
    payable(msg.sender).transfer(address(this).balance);
}

Grok found the same bug as our answer key. Its fix sends the money to msg.sender. Our fixed version below sends it to owner. Once the owner check passes, both point to the same address. Education only. Not financial advice.

Step 4: Check the answer key

Don't peek until Grok answers.

Show answer key **The bug:** `withdrawAll` has no owner check. Anyone can call it and take all the money. This is an access control bug, OWASP's SC01. **The fix:** add one line so only the owner can withdraw: 
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// PRACTICE ONLY. Fixed version. Remix VM only.
contract PiggyBankFixed {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function deposit() public payable {}

    function withdrawAll() public {
        require(msg.sender == owner, "Only the owner can withdraw");  // the fix
        payable(owner).transfer(address(this).balance);
    }
}

Did Grok find the same bug? Our tip: an AI is a helpful second pair of eyes, not a security guarantee. It can miss bugs or invent ones that aren't there.

Step 5: Prove it in the Remix VM

  1. Deploy PiggyBank in the Remix VM with the first test account.
  2. Set Value to 1 ether and press deposit.
  3. Switch Account to the second test account and press withdrawAll. It works. The "thief" took the play money.
  4. Now try the same steps with PiggyBankFixed. Step 3 fails with "Only the owner can withdraw".

We ran both versions on a local test chain on our own computer: the buggy one let a second account take the full 1 test ETH, and the fixed one refused it.

Step 6: What an audit is

An audit is a paid review by security experts. Ethereum.org says: "Smart contract audits won't catch every bug and are mostly designed to provide an additional round of reviews, which can help detect issues missed by developers during initial development and testing." It also says: "you should avoid treating audits as a silver bullet." (Ethereum.org smart contract security)

A real example: Euler Finance writes, "In March 2023, the Euler Protocol was exploited for ~$197 million in assets." Euler also writes: "Our audits invariably came back with excellent feedback from auditors." (Euler post-mortem) Audits lower risk. They don't remove it.

Bug bounty sites like Code4rena and Immunefi, and incident trackers like Rekt and DefiLlama, are examples only, not endorsements.

Next step (optional): real test tools

Developers write automatic tests with tools like Foundry, which says it "is a fast, portable, and modular toolkit for Ethereum application development written in Rust." It needs an install, so it's a next step, not part of this lesson.

Check yourself

  1. What was the bug in PiggyBank? (Answer: anyone could call withdrawAll, with no owner check)
  2. Does a good audit mean a contract is safe? (Answer: No. It lowers risk, but can't catch every bug.)
  3. If Grok says "no bugs found," are you done? (Answer: No. Check with tests and a human expert.)

Caution box Ethereum.org says: "Smart contract audits won't catch every bug" (Ethereum.org smart contract security). An audit lowers risk but doesn't guarantee safety. Our tip: never deploy a contract that holds real money without a professional audit. While you learn, stay in the Remix VM or on test networks. Education only. Not financial advice.

Builds on

Sources

Creator credits

Education only. Not financial advice.

Keep going

PreviousC2 →NextC4 →TrackBack to Build With AI →