The MAD token is built. forge build, forge test (12 tests, run with the verifier's fuzz seed) and forge fmt --check all pass. I didn't make the commit: git stopped it because this machine has no author identity set, and I didn't set one for you. All the files are staged, so they're ready for the harness's upload or for you to commit.

• Contract: src/MADToken.sol (contract MADToken), a plain ERC-20 written from scratch with no outside libraries. It returns name "Muttualy Assured Destruction", symbol MAD and 18 decimals.
• Supply: all 1,000,000,000 tokens (1e27 in the smallest unit) are minted once, in the constructor, to the deployer (the launch factory). It takes no constructor arguments.
• No admin powers: there is no owner, minting, pausing, blacklist or fee. Every transfer moves exactly the amount sent, so the launch transfers to the distributor and pool arrive in full. The only way the supply changes is a holder burning their own tokens with burn, and it can only shrink.
• Small choices of mine: a maximum allowance counts as unlimited and is never reduced, and sending to the zero address is refused (use burn instead).
• Tests: test/MADToken.t.sol checks the name, symbol, supply, transfers and allowances. It also checks failures: spending more than a balance or allowance, sending to the zero address, approving the zero address and calling a mint function that doesn't exist. A fuzz test checks the total supply never changes on transfer. I didn't run the protected launch checks from the read list here, because they need the launch's own settings and contracts that aren't in this repository. Passing tests are not a security audit.
• Config: foundry.toml pins solc 0.8.26 with bytecode_hash = "none" and the optimizer on. forge-std is copied into lib/forge-std as plain files, not a git submodule.
• Docs: README.md covers the assumptions and deployment details. Its "After launch" section says there is nothing to configure.

I found no medium, high or critical defects in MADToken, and one info-level finding. The findings and coverage rows are in .imd-findings.json; I changed no tracked files.

Finding 1 (info), src/MADToken.sol:43, transferFrom: anyone can call transferFrom(address(0), anyAddress, 0) and it succeeds.

• Why it gets through: the allowance check passes because 0 < 0 is false, and the balance check passes the same way. Only to == address(0) is rejected, never from.
• Effect: the call emits Transfer(address(0), anyAddress, 0), which explorers and indexers display as a mint. No balance or the total supply changes.
• Fix: reject from == address(0) in _transfer, as OpenZeppelin v5 does.

Coverage:

• approve: holds. It rejects a zero spender, sets the allowance and emits the event, and makes no external calls.
• burn: holds. It checks the balance before the unchecked subtraction, so neither the balance nor the total supply can underflow, and both drop by the same amount.
• transfer: holds. Sending to yourself is handled correctly, and the unchecked addition can't overflow because all balances together equal the total supply of at most 1e27. The exact amount always moves, so the factory → distributor → pool-manager launch flows arrive whole.
• transferFrom: finding 1. The rest of its allowance handling is correct: an unlimited allowance is not reduced, and a revert undoes the partial write.
• Constructor and supply rule: the constructor mints exactly 1,000,000,000 × 10^18 to the deployer and creates no roles. Nothing can raise the supply afterwards: there is no mint, owner, DELEGATECALL or SELFDESTRUCT.

Guides applied:

• Execution Trace: I checked parameter mismatches, special values such as the zero address and the unlimited allowance, half-finished state updates, and leftover allowances.
• Periphery: the contract has no libraries and makes no external calls. Its only outside contacts are the pool manager's transfer-then-settle and the distributor's claims, both of which depend on exact transfers.
• First Principles: I checked that balances and the total supply stay in step, and the zero, maximum and self-transfer edge cases.

Checks run: the existing 12 Foundry tests pass. The aderyn "large numeric literal" note is the intended supply constant, not a defect. I wrote no proof test because nothing reached high or critical. I could not run the protected launch tests: they import floor/OwnerChecks.sol and src/LaunchLiquidity.sol, which are not in this tree.

Several dotfiles I did not create (.bashrc, .gitconfig, .mcp.json and others) now show as untracked in the repository root. I left them alone, but they should be kept out of the submission.

I added test/MADTokenInvariant.t.sol and committed it. With the verifier's fuzz seed, forge test passes all 30 tests, the 12 already in test/MADToken.t.sol included.

What the new file covers:

• Invariant tests: four actors make random sequences of transfer, approve, transferFrom and burn calls, plus calls that are meant to revert (spending more than the balance or more than the allowance). After every sequence the tests check three things:

  • all balances add up to the total supply;
  • the total supply plus everything burned still equals exactly 1,000,000,000 MAD, so the supply can never grow;
  • every allowance matches what the test expects it to be.

  This ran 128 runs of 64 calls each (8,192 calls), with every function exercised.

• Edge cases:

  • moving the full supply works, and the full supply plus 1 wei or the maximum value reverts;
  • zero-amount transfers work, even from an empty account;
  • transferring to yourself leaves your balance unchanged;
  • a transferFrom that reverts (to the zero address, or from an account that is short) does not use up the allowance;
  • spending the exact allowance leaves it at zero, and the next spend reverts;
  • approve overwrites the old amount and emits its event;
  • burning zero and burning the full supply both work;
  • the deployment emits the mint event;
  • there is no burnFrom, and the token refuses ETH.

• Fuzz tests: transferFrom keeps balances and allowances correct for any approved amount, and burning more than you hold always reverts.

Findings: none. I found no defect in src/MADToken.sol, so I did not write .imd-findings.json. The token has no owner, no mint function, no fees and no pause, and a holder can only burn their own tokens.

Git had no identity set on this machine, so the commit failed at first. I made it with your name and email passed on that one command and did not change the git configuration.

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

forge build succeeded. All 12 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete and the findings file is written. Nothing further is needed from the tree or the user.

Result: no defects found in the Math Precision, Boundary and Numerical Gap areas. The findings file at the repository root holds an empty findings list and seven coverage rows, one for each of the four entry points plus three invariant and boundary rows.

What I checked and how

• Arithmetic surface. The token has no division, no multiplication at runtime, no scaling and no casts. The only arithmetic is the compile-time supply constant and the subtractions and additions inside the unchecked blocks of transfer, transferFrom and burn. Each unchecked subtraction is preceded by the matching < check, and the unchecked addition cannot overflow because the sum of balances never exceeds the initial supply.
• Boundaries. The contract makes no external calls, has no payable function, decodes no bytes, and has no receive or fallback. I disassembled the compiled runtime and found no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT opcodes.
• Edges exercised in a scratch Foundry suite (17 tests, 2000 fuzz runs, all passed, then deleted): zero value, exact balance, balance plus one, max uint, self-transfer of the full balance, allowance of max minus one, allowance spent exactly to zero, allowance sufficient but balance short, infinite allowance with no balance, burn to zero total supply, burn of max, and a randomized 24-step sequence of all four entry points keeping the sum of balances equal to total supply.
• Static analysis lead. The aderyn large-literal note is stylistic. The literal evaluates to exactly 1e27, which matches the manifest supply.

One behaviour noted but not reported as a defect. A zero-value transferFrom from any account succeeds without allowance and emits a Transfer event. This matches OpenZeppelin ERC-20 and moves nothing, so it is not a defect under the acceptance criteria.

Coverage. All four entry points are marked holds. Nothing in my area was left unreached.

The review is complete and the findings file is written. The working tree holds only the findings file and build artifacts, with no source changes.

Outcome: no defects found in the assigned area. The token at src/MADToken.sol has no owner, roles, modifiers, initializer, proxy, fee, pause or blacklist. Its four state-changing entry points each act only on the caller's own balance or on an allowance the owner granted, and no path can increase supply.

What I checked, against the Access Control, Trust Gap and Asymmetry guides:

• Permission map: all writers to balanceOf and allowance were traced. Every write is keyed by msg.sender or guarded by a balance or allowance check that precedes the unchecked arithmetic.
• Asymmetry pairs: constructor mint versus burn mirror both totalSupply and balanceOf. transfer and transferFrom share one private path. Self-transfer keeps the balance intact because the sender write happens before the receiver read.
• Trust Gap seams: with no privileged actor, no settable parameter and no price formula, no seam exists.
• Static-analysis lead: the large numeric literal on line 11 equals exactly 1e27, the manifest supply. Not a defect.

Verification run: the existing test suite passed, and a scratch Foundry file with seven tests passed, including a 2000-run fuzz of the sum-of-balances equals totalSupply invariant across transfer, infinite-allowance transferFrom and burn. The scratch directory was removed afterwards.

Reported: one informational note on the standard ERC-20 approve race, with a concrete call sequence where a spender realises 150 tokens against an owner who intended at most 100. It is inherent to the standard, not a permission bypass, and needs no design change.

Coverage record: all four listed entry points plus four invariant rows are answered in .imd-findings.json. approve is marked as carrying the info note. burn, transfer and transferFrom hold.

Review complete. The findings file is written and validated, the scratch tests are removed, and the tree is otherwise unchanged.

Outcome: the MAD token has no defect that would block the launch. Both specialist observations reproduced and are kept at info severity. Nothing new surfaced in my own pass.

What I verified against the code

• Zero-address sender in transferFrom. Reported by two specialists, merged into one finding. A caller with no allowance can call transferFrom(address(0), anyone, 0) and the contract emits a mint-shaped zero-value Transfer event. Balances and supply never change, so this is cosmetic for indexers only. Reproduced with a Foundry test using expectEmit.
• Approve front-running race. Standard ERC-20 behaviour, identical to OpenZeppelin v5. Reproduced the exact 100 then 50 sequence yielding 150 spent. Kept as info, not a defect in the agreed design.
• Dropped nothing except the aderyn large-literal lead, which is the supply constant and not a defect.

Coverage: all four entry points answered. Transfer and burn hold. Approve and transferFrom carry the two info findings. I also recorded two invariant rows: supply conservation with no mint path, and deployability under the factory's CREATE2 model, where the no-argument constructor, manifest supply, name, symbol, decimals and code size all match.

The existing 30 project tests pass on this code. No critical or high findings, so no proof files were attached.