Implemented MADToken.sol: 1 billion MAD, 18 decimals, minted once to the deployer, with no administrative powers.

Dependencies are vendored, and deployment assumptions and responsibilities are documented in README.md.

Passed:

• forge build
• forge test with the supplied seed: 34 unit/fuzz tests and three invariant properties across 8,192 calls
• forge fmt --check

Full launch integration remains with the network’s protected harness.

Created launch.json matching MADToken, its exact supply, empty constructor arguments, and the required pool and economics. Only the manifest changed; local JSON checks passed.

Both forge build and forge test were attempted with the supplied seed but failed because Solidity 0.8.26 returned “Permission denied.”

The review is complete and the findings file is written. No source changes were made.

Result: no access-control, trust-gap or asymmetry defect in the token. src/MADToken.sol is a 16-line contract inheriting the vendored OpenZeppelin v5.0.2 ERC-20 with no overrides, no roles and no extra entry points. The compiled ABI confirms the only state-changing functions are approve, transfer and transferFrom. The constructor mints the whole supply to msg.sender, which is the factory under the launch flow, and the two supply-changing branches of the inherited update function are unreachable afterwards.

What I checked against the three guides:

• Access Control. Permission map is empty: no owner, minter, pauser, initializer, receive, fallback or hook. Internal mint and burn helpers have no external caller. The deployer holds no bypass over other holders' balances or allowances.
• Asymmetry. The approve and transferFrom pair write the same allowance slot under the same key. The transfer and transferFrom pair funnel through one validation path. There are no admin, force or batch variants to diverge.
• Trust Gap. No privileged actor, settable parameter, fee recipient or exemption list exists, so none of the four seams has an actor. The only trust assumption is that the factory, as an ordinary holder, performs the launch split, and that lives outside this code.

The project's 35 tests pass with the pinned fuzz seed, and the formatter check is clean.

One info-level finding was recorded. The checksum file under lib fails for 23 of its 36 entries, including the ERC-20 file the token inherits, while the README claims it records each delivered file. I downloaded the upstream v5.0.2 archive, confirmed its hash matches the README, and diffed every vendored file: the only differences are line wrapping from the formatter, so semantics are the audited upstream code. The finding asks the author to regenerate the checksums or vendor unformatted files.

The coverage record has nine rows: the three listed entry points, the constructor and role handout, the fixed-supply invariant, the paired-function asymmetry check, the trust-gap seams, the dependency provenance finding, and the standard ERC-20 approve race, which I noted as a known property rather than a defect.

I found no defects in MADToken, so I didn't write .imd-findings.json. The token is a plain OpenZeppelin ERC20: name "Mutually Assured Destruction", symbol MAD, 18 decimals, 1,000,000,000 tokens minted once to the deployer. It has no owner, no mint, burn or pause, no permit, and no code that could hand over control to another contract.

Result: forge test passes all 48 tests across 4 suites with the verifier's fuzz seed, run in the foreground. The 36 earlier tests (test/MADToken.t.sol, test/MADToken.invariant.t.sol) are unchanged. My three new files are not committed.

What I added (only under test/):

• test/helpers/MADOpenHandler.sol and test/MADToken.openworld.invariant.t.sol: random-sequence invariant tests that start with the whole supply in one "factory" account. The fuzzer then spreads it to addresses it picks, up to 24 holders, which can include the token's own address. The handler also makes calls that should fail and checks the exact error and that nothing changed:

  • sending to the zero address, or more than the balance (up to the largest possible amount);
  • spending more than the allowance, or within the allowance but beyond the balance;
  • calling any function that isn't part of ERC-20, from any holder.

  After every call it checks that:

  • total supply never changes and the holders' balances add up to all of it;
  • every balance and every allowance matches the model;
  • the zero address holds nothing and the token holds no ETH.

  Runs are set in the file to 256 × 64 (16,384 calls), with no unexpected reverts. A scratch check confirmed the handler really adds new holders, so these invariants aren't passing vacuously.

• test/MADToken.launch.t.sol (12 tests):

  • Launch: a helper deploys the token and makes the swarm, pool and remainder transfers in a single call, like the factory's one transaction; each arrives exact and the distributor's claims pay out whole. Deploying twice with the same salt reverts.
  • Floor checks: the reachable bytecode has no DELEGATECALL, CALLCODE or SELFDESTRUCT. The deployer can't use any of the 17 privileged calls the launch floor tries, or move a holder's tokens with transferFrom, and the holder can still transfer afterwards.
  • Edge cases: increaseAllowance, decreaseAllowance, permit, nonces and DOMAIN_SEPARATOR all revert. An allowance one below the maximum still goes down when spent. Spending exactly the balance works and one more wei fails. Allowances are separate for each spender. Tokens sent to the token's own address are stuck, since there is no rescue function.
  • Fuzz: approve always replaces the old allowance, outsiders can't spend without approval, and chains of transfers conserve the supply.

The review is complete and written to .imd-findings.json. No source files were changed, and git status shows a clean tree apart from the findings file, which is ignored.

Outcome. The MAD token has no economic, invariant or flow defect. It is a 16-line contract inheriting the OpenZeppelin v5.0.2 ERC-20 unchanged, with one constructor mint of 10^27 units to msg.sender and no other entry point. One low-severity provenance finding is reported.

What I checked in the assigned area

• Economic Security: no external dependency, oracle or callback. No fee, burn, rebase, pause or blacklist, so the swarm share, pool seed and trader swaps move exactly what they say. Transfers to the zero address and approvals of the zero spender revert. The paired FWA token on Ethereum mainnet has code, symbol FWA and 18 decimals, matching the README.
• Invariant: total supply is fixed at deployment and the sum of balances equals it. The ABI has only ten functions and no receive or fallback, so there is no mint, burn, owner or freeze path. The project's 35 tests, including fuzz and stateful invariants, pass.
• Flow Gap: the constructor takes no arguments and mints to the deploying factory. The runtime bytecode has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. The aderyn large-literal lead is a compile-time constant and not a defect.

Finding reported (low). The vendored library checksum record is stale. Running sha256sum -c lib/SHA256SUMS from the repo root fails on 23 of 36 files, including the ERC-20 core, while lib/README.md says the sources are unmodified. I compared every file against the upstream v5.0.2 and v1.9.7 archives and they are identical apart from forge fmt whitespace, so behaviour and bytecode are unaffected. The fix is to regenerate the sums or exclude lib/ from formatting and restore the byte-exact files.

Coverage. All three entry points are marked holds, plus rows for the supply invariant, constructor mint, launch flows, privileged-call absence, bytecode scan, paired currency and the provenance finding. Nothing was left unreached.

The review is complete and .imd-findings.json holds the result. The tree is otherwise untouched.

Outcome: the token's arithmetic is sound. Every Math Precision, Boundary and Numerical Gap check I could apply to this code holds, and I found one low-severity provenance defect outside the math area.

What was checked

• MADToken is a plain OpenZeppelin v5.0.2 ERC-20 with one constant and one mint in the constructor. The supply literal folds to exactly 10^27 and cannot overflow, which closes the aderyn large-literal lead.
• All three entry points were traced through the vendored _update, _spendAllowance and _approve. The unchecked subtractions are guarded by prior comparisons, the unchecked additions are bounded by the fixed supply, and self-transfer reads the balance once so it is unchanged.
• A scratch Foundry suite of 12 tests exercised the edges: max-uint amounts, whole-supply round trips, zero amounts to and from empty accounts, unlimited versus max-minus-one allowances, allowance larger than balance, spender equal to owner, and ETH sent with or without calldata. All passed, and the scratch directory was removed afterwards.
• Launch arithmetic: the supply divides by 10,000 exactly, so the 10/80/10 split has no truncation. Both currencies have 18 decimals, and the derived sqrt price and seed liquidity for the 2,000,000 FWA cap sit well inside Uniswap v4's bounds. The deployer's own liquidity code was not available, so that row is marked as reasoning only.
• The token has no external calls, no payable path, no bytes decoding and no division, so the Boundary and Numerical Gap seams have nothing to attach to.

The one finding (low): lib/SHA256SUMS fails for 23 of its 36 entries, including the vendored ERC20.sol, while lib/README.md says the sources are unmodified. I downloaded the v5.0.2 archive the README names, confirmed its hash, and diffed every OpenZeppelin file. The only differences are forge fmt line reflows, so the deployed logic is upstream's. The fix is to regenerate the checksum file from the delivered tree and reword the provenance note.

Coverage: all three ABI entry points are recorded as holds, plus five invariant rows. Nothing in the assigned area was left unreached.

Review complete. The findings file is written at .imd-findings.json with one low finding and eight coverage rows, and no tracked file was changed.

Outcome. The MAD token is a 16-line OpenZeppelin v5.0.2 ERC-20 with no overrides, no admin surface, and a constructor that mints exactly one billion tokens with 18 decimals to the deployer. All three state-changing entry points (approve, transfer, transferFrom) hold under the Execution Trace, Periphery and First Principles checks. The one defect is in dependency provenance, not in token behavior.

Finding 1, low. The checksums in lib/SHA256SUMS do not verify the delivered files. Running sha256sum -c lib/SHA256SUMS from the root fails 23 of 36 entries, while lib/README.md line 4 claims the upstream sources are unmodified and recorded. I fetched OpenZeppelin v5.0.2 and forge-std v1.9.7 from GitHub: every recorded hash matches the upstream file byte for byte, and every one of the 23 delivered files differs from upstream only in whitespace, because a formatter re-wrapped long lines at 100 columns. So the inherited ERC-20 semantics are genuinely upstream's, but the documented integrity check is broken and cannot distinguish this formatting noise from a real edit. The fix is to restore the byte-exact upstream files, which I verified does not break the documented forge fmt --check step since it ignores lib by default, or to regenerate the checksums and reword the claim.

What I verified as holding:

• approve, transfer, transferFrom traced through the vendored base: zero-address guards, overdraft and over-allowance reverts before any write, atomic rollback of the allowance decrement, infinite allowance untouched, exact amounts for the factory, distributor and pool manager flows with no exemptions needed.
• Constructor mints the brief's supply to msg.sender; name, symbol and decimals match.
• No mint, burn, pause, blacklist, owner, receive or fallback in the compiled ABI. I re-ran the protected test's opcode-reachability scan over the compiled runtime and found no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The project's 34 unit and fuzz tests and 3 invariants pass under the documented seed.

Not reached. Nothing in my area. The protected launch harness itself (pool seeding and swaps through a real PoolManager) needs the network's deployment values and was not run locally; the token has no transfer hooks, so there is no mechanism by which it could tax those flows.

The review is finished. I kept one finding, a low-severity mismatch in the dependency checksum record, and it doesn't affect how the token behaves. I changed no repository files; my results are in .imd-findings.json.

The kept finding. All four specialists reported the same root cause, so I merged it into one finding. lib/README.md:4 says the vendored dependency files are unmodified and that lib/SHA256SUMS records each one. That isn't true as shipped.

• Reproduction: running sha256sum -c lib/SHA256SUMS gives 13 OK and 23 FAILED. The failures include the OpenZeppelin ERC20.sol that MADToken inherits from.
• Cause: I downloaded the upstream OpenZeppelin v5.0.2 archive, and its hash matches the one the README records. All five vendored OpenZeppelin files match upstream once whitespace is ignored. The only differences are two lines the code formatter re-wrapped (ERC20.sol:284 and draft-IERC6093.sol:121).
• Impact: the token code is the upstream code, so nothing it does changes. The problem is that the published integrity check can't confirm that, so anyone relying on it has to redo the upstream comparison by hand.
• Severity: low, so no proof test was needed.
• Possible fixes: regenerate SHA256SUMS and reword the README's claim, or restore the 23 files to their exact upstream bytes. Either fix means editing files under lib/. This task's rules don't allow submissions to touch lib/; if the same restriction applies to the author, this finding can't be fixed without that permission.

Coverage. I marked all three entry points (approve, transfer, transferFrom) as holds. I also added a row for the fixed-supply rule:

• src/MADToken.sol is a plain OpenZeppelin ERC-20 with no overrides, no owner, no mint after the constructor and no transfer fee. The launch transfers (factory to distributor, distributor to claimant, pool seeding and swaps) therefore move exact amounts.
• The constructor mints 1e27 base units (1,000,000,000 MAD with 18 decimals) to msg.sender. That matches launch.json's totalSupply, and its empty constructorArgs matches the no-argument constructor. The manifest uses only schema keys, and the deployed contract is far below the size limits.
• forge test passed all 48 tests. I could not run the protected launch tests, because they need the service's own harness.

Dropped. I dropped the static-analysis note about a "large numeric literal" at src/MADToken.sol:10. It's the supply constant 1_000_000_000 * 10 ** 18, which is correct.