Implemented MAD with 1,000,000,000 tokens, 18 decimals, minted once to the deployer. Includes vendored dependencies, deployment documentation, and success/failure tests.

Passed with Solidity 0.8.26:

• forge build, including a clean offline rebuild
• 32 unit/fuzz tests and both invariant properties
• forge fmt --check

The separate protected launch harness remains for independent verification.

I found no defects in the MAD token, so .imd-findings.json has an empty findings list plus a coverage record for all three entry points. The JSON is valid.

What the code is: src/MADToken.sol is a plain OpenZeppelin v5.1.0 ERC20. It has no overrides, admin roles, fees, burns or hooks, and its constructor takes no arguments. It mints 1_000_000_000 * 10**18 to msg.sender (the factory) once, in the constructor. Every vendored OpenZeppelin file matches its sha256 in dependencies.lock.json, so the library code is unmodified.

Coverage against the three assigned guides:

• Economic Security:
  • With no transfer tax, the factory's transfers to the distributor, the distributor's claims, the pool seed and the PoolManager's settlement all move exactly the stated amount.
  • There are no oracles, outside dependencies or special-case addresses, and no fee formula that could be pushed to zero or to its maximum.
  • The ERC-20 behaviour is the library's own: transfers to or from the zero address revert, and an unlimited allowance is never reduced.
• Invariant:
  • The sum of balances equals a total supply that stays fixed at 1e27, because minting happens only in the constructor.
  • transferFrom has no route that skips the allowance check.
  • The existing invariant suite ran 8,192 calls with 0 reverts.
• Flow Gap: No external calls or callbacks happen mid-transfer, and no value is read before an outside call and reused after it.

Entry points: approve, transfer and transferFrom are all holds. I also added rows for the fixed-supply invariant, the absence of any privileged power over holders, and exact launch flows.

Tests: All 33 existing tests pass. I wrote no proof tests because there were no findings to prove.

Static analysis: The aderyn line at src/MADToken.sol:11 is not a defect. It is the supply constant, written readably and matching the brief. The usual approve front-running race is standard ERC-20 behaviour and I didn't report it.

Not run: The protected floor tests in .imd/reads/protected/ need the launch environment variables and factory harness, which this machine doesn't have. From the code alone, nothing in the token conflicts with them.

Created launch.json matching MADToken, its exact supply, empty constructor arguments, and the required pool and economics.

Manifest and compiled ABI checks passed. forge build succeeded; forge test passed all 33 tests with the specified fuzz seed. Only launch.json is changed outside permitted scratch artifacts.

The review is complete. The findings file is valid JSON and the working tree shows no tracked changes.

Result: no defects found in the Math Precision, Boundary or Numerical Gap areas. The findings file at the repository root holds an empty findings list and nine coverage rows, one for each of the three state-changing entry points plus six invariant and lead rows.

What I checked:

• Source and dependency. The token is a constructor mint on top of OpenZeppelin v5.1.0 ERC-20. The three vendored Solidity files hash identically to the upstream v5.1.0 archive, so the arithmetic reviewed is the unmodified library code.
• Math precision. The supply constant evaluates exactly to ten to the twenty-seventh. The only arithmetic is OZ's checked balance comparison followed by unchecked subtraction and addition, which cannot wrap because every balance is bounded by the fixed supply. The launch split percentages divide exactly with no dust, and the supply fits the signed 128-bit deltas and sqrt-price range Uniswap v4 uses in either currency order.
• Boundary. The token makes no external calls, has no payable or fallback surface, and decodes no bytes. The zero-address sentinel branches inside the balance update are reachable only through the constructor, because the public transfer and approve paths reject zero addresses first. One wei, exact balance, balance plus one, and both max and max-minus-one values behave as ERC-20 specifies.
• Numerical gap. Zero-amount transfer, transferFrom and approve calls leave every balance and allowance unchanged, and still cannot reach the zero-address paths. The unlimited-allowance sentinel is only the exact maximum value. A balance or receiver failure inside transferFrom leaves the allowance untouched.
• Static-analysis lead. The aderyn large-literal warning is a constant equal to the intended supply, not a defect.

The existing 33-test suite passes, formatting passes, and the ten scratch probes I wrote under test/scratch all pass. Nothing was left unreached in the assigned area.

Nothing further is needed. The review is complete and the findings file is validated, so this is the closing recap.

The MAD token holds under the Access Control, Trust Gap and Asymmetry guides. It is a sixteen-line contract inheriting unmodified OpenZeppelin v5.1.0 ERC-20, with a no-argument constructor that mints exactly 10^27 units to the deployer. The compiled ABI exposes only the three state-changing ERC-20 functions, four views and the supply constant. There is no owner, pause, blacklist, mint, burn, upgrade, receive or fallback, and neither the creation nor the runtime bytecode contains a reachable CALL, DELEGATECALL, CALLCODE or SELFDESTRUCT. The three entry points mirror each other's state writes, zero-address and zero-value branches behave consistently, and the deployer cannot pull a holder's balance without an allowance. Each of these claims was exercised with throwaway Foundry tests that I removed afterwards, and the existing suite of 33 tests passes.

One low-severity finding is recorded in .imd-findings.json, outside the token itself:

• Vendored forge-std provenance. Seven files under lib/forge-std differ from the SHA-256 hashes that dependencies.lock.json records for them, while the lock hashes match upstream v1.9.4 exactly. A whitespace-insensitive diff shows the local copies are forge-fmt reformatted versions with no code change. README line 63 still claims the vendored files are unmodified upstream copies, so anyone verifying the tree against the lock gets seven mismatches. All five OpenZeppelin files match both the lock and upstream byte for byte. The reproduction in the finding is a single node command.

The coverage record has six rows: holds for approve, transfer, transferFrom, the constructor mint, and the overall access-control surface, and finding pointing at the provenance issue. No tracked file was changed, test/scratch is gone, and temp files under /tmp were removed. Nothing in the assigned area was left unreached.

The review is complete and .imd-findings.json holds the result. Nothing in the repository was changed; the scratch test was removed after it ran.

Outcome: the production code holds in my area. MADToken is sixteen lines over an unmodified OpenZeppelin v5.1.0 ERC20, and I found no defect in it. One info-level provenance discrepancy is reported.

What I checked

• Execution Trace. Traced approve, transfer and transferFrom through _transfer, _update, _approve and _spendAllowance with concrete values. Zero sender and receiver revert, balance is checked before the unchecked subtraction, self-transfers re-read storage and net to zero, and allowance spent before a failing balance check is rolled back by the revert. Max allowance is not decremented, max minus one is. Zero-value transferFrom from any account needs no allowance, which is standard and documented in the README.
• Periphery. Verified every vendored OpenZeppelin file against the lock file hashes and the lock against upstream v5.1.0. decimals() is hardcoded to 18, _msgSender is plain msg.sender, and there is no meta-transaction or hook surface.
• First Principles. The constructor mints exactly 10^27 to msg.sender once, under CREATE and CREATE2, with no constructor arguments. The compiled ABI exposes no mint, burn, owner, pause, initialize or upgrade entry point. An opcode walk of the compiled runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE, so transfers cannot call out or reenter and the launch legs arrive whole.
• Checks run. Full project suite with the README's fuzz seed (33 tests, 8192 invariant calls, all passing), forge fmt --check (clean), and a scratch probe of six edge cases (all passing). Slither reported nothing; the aderyn large-literal lead is the compile-time supply constant and is not a defect.

The one finding (info). Seven forge-std files under lib/ were re-wrapped by the formatter and no longer match the hashes in dependencies.lock.json, which the README says vouch for unmodified upstream copies. I downloaded the pinned v1.9.4 archive and confirmed the differences are whitespace only and the lock itself matches upstream. This touches test tooling only and has no effect on deployed bytecode, so the fix is to restore the files or regenerate the lock, and to exclude lib/ from forge fmt.

Coverage record. All three verifier-listed entry points are marked holds, plus rows for the fixed-supply invariant, the bytecode floor, and both dependency provenance checks. Nothing in scope was left unreached.

Added 16 adversarial tests and expanded stateful invariants covering failures, rollback, allowance replay, and integer boundaries.

Validation passed:

• forge build
• Seeded forge test: 50 passed
• 32,768 invariant calls
• 1,000 runs per fuzz test

All changes are under test/. No implementation defects were found.

The review is complete and .imd-findings.json is written. The tree is otherwise unchanged.

Outcome. The MAD token is a bare OpenZeppelin ERC20 v5.1.0 with a constructor that mints the fixed supply to the deployer. No code defect was found. One low provenance finding is kept, merged from the two specialists who reported it.

What I reproduced

• Specialist finding (audit_permissions low, audit_flow info), kept as one low. Seven forge-std files under lib/ hash differently from the lock file, while the README claims unmodified upstream copies. I ran the hash check and got the same seven mismatches. I fetched upstream v1.9.4 for two of them and confirmed the whitespace-stripped hashes match, so the drift is a forge-fmt reformat. forge-std is test-only, so the deployed token is unaffected.
• Production dependency verified. All six vendored OpenZeppelin files match both the lock and the files fetched from the v5.1.0 tag.

My own pass over the entry points

• approve, transfer and transferFrom are inherited unmodified. Transfers move exactly the stated amount, so the factory, distributor, pool seed and remainder flows arrive whole.
• Supply is 1e27 minted once to msg.sender and matches the manifest. The ABI has no mint, burn, pause, blacklist or owner function.
• The constructor takes no arguments, matching the manifest's empty list. Creation and runtime code are well under the size limits, and the disassembled runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The project builds on solc 0.8.26 and all 50 tests pass.

The coverage record answers all three entry points as holds, plus five invariant rows. The static-analysis lead about a large numeric literal is cosmetic and was not promoted.