Vibe Fuzzing Guide for Wake’s Manually-Guided Fuzzing

Introduction

Writing comprehensive fuzz tests for Solidity contracts is necessary but time-consuming. Manual code reviews cannot catch all vulnerabilities because complex state machines have too many execution paths and states of smart contracts.

Vibe coding—using AI to generate boilerplate code while keeping humans in charge of logic offers a better workflow. Testing smart contracts in Python with Wake supports this approach because switching languages requires thinking about behavior, not syntax.

This guide defines the line between what AI can safely generate and what always requires human verification in manually guided fuzzing tests.

Vibe the Structure, Verify the Logic

MGF involves writing a lot of repetitive code where mostly importing pytypes, python state definition and static logics.

Python for-loops iterating over accounts can be vibe-coded. If-elif control structures can be vibe coded. Error message strings can be vibe-coded. The structural elements of your test are mechanical work.

However, three components require manual verification every single time.

Verification Checklist

1. What are the tests asserting: The right property to check. All event parameters checked, not just event existence. Every error condition is mapped to an assertion. Invariants express true mathematical or logical properties.
2. Which values are they asserting with: Values are compared against the Python state computed before the transaction. Error parameters verified completely. State changes mirror contract behavior, including edge cases like fees and rounding.
3. Which execution branches were reached: Use Wake’s coverage report and the output of manually guided fuzzing to confirm that the intended code paths were executed and adequately tested.

Missing any of these three makes your test look perfect while catching nothing.

The Four Phases of Every Flow Function

Every flow function in Wake follows the same pattern. Understanding which phases can be vibe-coded versus which need manual verification determines test effectiveness.

@flow()
def flow_something(self):
    ## Phase 1: prepare random input

    ## Phase 2: run transaction

    ## Phase 3: check events

    ## Phase 4: update python state
    pass

Phase 1: Preparing Random Input

Vibe code the structure of random selection—picking accounts, generating amounts, selecting from collections. AI handles this mechanical work effectively.

Manually specify the constraints. Your business logic determines valid ranges, preconditions, and parameter relationships. These encode domain knowledge that AI lacks.

Phase 2: Running the Transaction

Vibe code the may_revert() wrapper structure. This is standard Python error handling.

Manually specify the exact parameters passed from your Python state. The transaction parameters depend on your test scenario and current state.

Phase 3: Checking Events

This phase causes the most common testing errors. You can vibe code the event filtering loop structure, but you must manually verify what you assert.

Most importantly, event validation must depend only on Python state variables computed before the transaction.

Never write this:

if len(tx.events) > 0:
    assert events[0].amount == expected_amount

That checks the wrong thing. Instead, verify all parameters deterministically:

events = [e for e in tx.events if isinstance(e, Contract.Transfer)]
assert len(events) == 1
assert events[0].sender == sender
assert events[0].recipient == recipient
assert events[0].amount == expected_amount

Every parameter is verified against the state you calculated beforehand. AI will generate the first version. You must verify it becomes the second.

Phase 4: Updating Python State

Vibe code the assignment structure—the basic syntax of updating dictionaries and variables.

Manually verify which values are being updated. Fees, rounding, edge cases—all encode your understanding of how the contract works. Errors cascade through every subsequent test because invariant functions depend on accurate state tracking.

Handling Reverts to Verifying Python Model

When transactions revert, it needs exhaustive error mapping. You can vibe code the if-elif control structure and error message strings. It must manually verify what you are asserting and which execution branch you reached.

with may_revert() as e:
    tx = self.contract.transfer(recipient, amount, from_=sender)

if self.balances[sender] < amount:
        assert e.value is not None
        assert isinstance(e.value, Contract.InsufficientBalance)
        assert e.value.required == amount
        assert e.value.available == self.balances[sender]
        return "insufficient_balance"

elif recipient == Address.ZERO:
    assert e.value is not None
    assert isinstance(e.value, Contract.InvalidRecipient)
    return "zero_address"

assert e.value is None

Python State Design

A subtle mistake reduces test effectiveness. Many contracts use special values like address(0) to represent native tokens, creating branches in contract code. Do not replicate these implementation details in your Python state.

You can vibe code the for-loop structure, but verify what you are asserting.

Bad version that mirrors contract implementation:

@invariant()
def invariant_token_balances(self):
    for token in self.tokens + [Address.ZERO]:
        for account in self.all_accounts:
            if token != Address.ZERO:
                assert self.token_balances[token][account] == IERC20(token).balanceOf(account)
            else:
                assert self.token_balances[token][account] == account.balance

Better version using natural semantic representation:

@invariant()
def invariant_erc20_balances(self):
    for token in self.erc20_tokens:
        for account in self.all_accounts:
            assert self.erc20_balances[token][account] == token.balanceOf(account)

@invariant()
def invariant_native_balances(self):
    for account in self.all_accounts:
        assert self.native_balances[account] == account.balance

The second version separates semantically different things. Your test code reflects what tokens actually are, not how the contract implements them. This independent model catches bugs instead of hiding them.

Consider whether you are validating contract logic or reproducing it. If your test has the same conditional branches as the contract, you are missing bugs.

The Development Cycle

Start with the simplest state-changing function in your contract. Something foundational that other operations depend on.

Vibe code the flow structure. Flow function name, the decorator, the outline, transaction call and filling parameters. Then manually verify the critical parts, parameter selection from state, complete revert handling, thorough event validation, precise state updates and their logics.

Write invariant functions that verify python state and contract state. Vibe code function structure and loops. Manually verify what the assertion verifying.

Run fuzzing and check coverage. Find untested branches. Verify those branches are meaningful, not dead code. Each iteration reveals how the contract behaves under edge cases you had not considered.

Real-World Example: Token Transfer Flow

This complete example demonstrates a token transfer function:

@flow()
def flow_transfer_tokens(self):
    # Phase 1: Prepare random input (vibe code structure, manually verify constraints)
    sender = random_account()
    recipient = random_account()
    amount = random_int(0, 10**30)

    # Phase 2: Run transaction (vibe code wrapper, manually specify parameters)
    with may_revert() as e:
        tx = self.token.transfer(recipient, amount, from_=sender)

    # Phase 3: Check events (vibe code filtering, manually verify all parameters)
    if self.balances[sender] < amount:
            assert e.value is not None
            assert isinstance(e.value, Token.InsufficientBalance)
            assert e.value.required == amount
            assert e.value.available == self.balances[sender]
            return "insufficient_balance"

    assert e.value is None

    events = [e for e in tx.events if isinstance(e, Token.Transfer)]
    assert len(events) == 1
    assert events[0].from_ == sender.address
    assert events[0].to == recipient.address
    assert events[0].value == amount

    # Phase 4: Update Python state (vibe code structure, manually verify values)
    self.balances[sender] -= amount
    self.balances[recipient] += amount

AI generates the structural patterns while you verify every assertion, every value, and every execution branch.

Conclusion

Testing smart contracts in Python with Wake enables vibe coding workflows that accelerate test development while maintaining security.

Always manually verify what you are asserting, which values you are asserting, and the execution branch reached. These three verification points are where security vulnerabilities hide.

The boundary between what to vibe code and what to verify determines whether you write comprehensive fuzz tests efficiently or ship vulnerabilities hidden in generated code that appears correct.

Master this balance to strengthen your smart contract security testing.

Additional Resources

Wake Testing Framework Documentation: Wake Fuzzing Guide

For more fuzzing techniques and best practices, follow @WakeFramework on X.

Naoki Yoshida

meditationduck