Writing Solidity & Rust Contracts with AI - The Boundary Testing Protocol

The constraint

My background

My background is frontend work. I had not shipped production Solidity or Rust before this, but the backend team was blocked and the contracts still had to be delivered.

STEP 1 - Spec first, code second

I wrote a Markdown specification for every contract before asking for code. Each one covered state variables, functions, events, invariants, access control, and edge cases. Copilot received that specification as context rather than a vague one-line prompt.

STEP 2 - Generate with iterative refinement

• I asked for a Solidity contract based on the specification, using OpenZeppelin ERC20Votes and ReentrancyGuard, with no external calls in the vesting logic.
• I reviewed the result line by line and followed up with concrete questions, such as what happens when vestingStart is 0 or whether claim() checks amount > 0.
• Each contract went through three or four generated versions before the structure felt sound enough to test.

STEP 3 - Boundary testing protocol (manual, exhaustive)

For every public or external function, I tested the following boundaries:

• Zero values, including amount 0, address 0x0, and timestamp 0
• Maximum values, including uint256 max and block.timestamp max
• Calls before vesting starts, after it ends, and exactly at the cliff
• Access-control cases, including callers that are not the owner or beneficiary and the paused state
• Reentrancy attempts, including nested calls even when ReentrancyGuard is present
• Integer overflow and underflow boundaries, despite Solidity 0.8+ built-in checks
• Event emissions, including indexed parameters and values against the resulting state change

STEP 4 - Cross-chain parity verification

• The Solidity and Rust contracts use the same vesting maths
• A TypeScript test suite calculates expected vesting amounts for both implementations at the same timestamps and compares the results
• The tests cover the immediate 25%, the remaining 75% over 3,600 seconds, a zero cliff, partial claims, and full claims

STEP 5 - Gas optimization pass (EVM only)

• Packed related fields into single storage slots where possible
• Cached block.timestamp in a local variable
• Used unchecked blocks for loop counters and maths with known bounds
• Removed require checks that the type system already guaranteed

STEP 6 - Deployment address registry

Contract addresses live in Postgres instead of the codebase. Adding a chain is a database row, and the frontend reads that registry to choose wagmi for EVM or @solana/web3.js for Solana.

Result