The MAD token project is complete and verified.

What was built

• src/MADToken.sol: contract MADToken, name "Mutually Assured Destruction", symbol "MAD", 18 decimals. The constructor takes no arguments, calls no other contract, and mints the full supply once to the deployer. It is OpenZeppelin v5.4.0 ERC20 + ERC20Burnable + ERC20Permit with no owner, no mint path, no pause, no blocklist, and no fee on transfer. The supply can only shrink, and only a holder or an approved spender can burn.
• test/MADToken.t.sol: 40 tests covering metadata and supply constants, the single constructor mint, absence of any mint or admin entry point, transfer and allowance success and failure paths, burns, permit (valid, expired, wrong signer, replay, domain binding) and six fuzz properties.
• script/DeployMADToken.s.sol: a local deploy helper whose function the tests call directly. Nothing reads the environment.
• README.md: assumptions, deployment parameters, launch settings for reference, the empty "After launch" section, operational responsibilities and security notes.
• foundry.toml pins solc 0.8.26, optimizer on, bytecode_hash = "none", cbor_metadata = false, no ffi and no fs permissions. lib/ vendors forge-std v1.10.0 and OpenZeppelin v5.4.0 as plain files, with no git metadata inside.

Verification results

• forge build, forge test with the verifier's fuzz seed and with an empty environment, and forge fmt --check all pass.
• A scratch mirror of the protected floor passed: CREATE2 deploy from a factory stand-in leaves the whole supply on the factory, the ten percent swarm flow arrives and claims whole, no admin selector grows supply or moves a holder, and the reachable runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Runtime is 4,353 bytes and the artefact carries no metadata hash.

Notes

• No application contracts were requested, so none were added. Pool seeding and swaps could not be exercised locally since v4-core is the verifier's harness dependency, but the token has no transfer hooks, so those flows move exactly what they send.
• Slither is not available on this machine. The contract has no custom logic that touches its rejected detectors.
• I did not commit, since .git/ is off limits. All deliverables are ordinary files in the working tree, and the untracked dotfiles at the root are sandbox artefacts, not mine.

I wrote launch.json for the Mutually Assured Destruction (MAD) token, but I couldn't commit it. Git on this machine has no author name or email set, and I didn't change that setting, so the file is in the working tree but uncommitted. It is the only file changed.

What the manifest says:

• Token: the contract is MADToken, named "Mutually Assured Destruction", symbol "MAD", 18 decimals. Its constructor takes no arguments, so constructorArgs is []. totalSupply is "1000000000000000000000000000", which is exactly what the constructor mints to the deployer.
• Application contracts: none, because the accepted code only contains the token.
• Pool: pair token 0xa0df17b5ac76ababa36e1450e2cbcd18a620c845, fee 12500, tick spacing 60, starting price 79228162514264337593543950336 (one to one).
• Economics: your object, copied exactly.
• Notes: they describe the token: a fixed supply minted once, no owner or admin, no pause, no transfer fee, and holders can burn only their own tokens or ones they have approved.

Checks: the JSON parses, forge build succeeds, and forge test passed all 40 tests with the required fuzz seed. Those tests are the project's own. The two required check files expect src/LaunchLiquidity.sol and two other src/ contracts that aren't in this tree, so I couldn't run them here.

The review is complete and the findings file is written and validated. The working tree has no tracked changes.

Outcome: no defects in the math area. The MAD token is OpenZeppelin v5.4.0 ERC20 + ERC20Burnable + ERC20Permit with no custom arithmetic, so the three guides (Math Precision, Boundary, Numerical Gap) have very little surface to attack. One info-level note is recorded; it needs no fix.

What I checked

• Library integrity. The vendored OpenZeppelin and forge-std files differ textually from upstream, but only by formatter rewraps. Compiling the token against pristine upstream v5.4.0 and forge-std v1.10.0 tarballs produced byte-identical creation and runtime bytecode.
• Math Precision. The only arithmetic is the compile-time constant for the supply, which evaluates to exactly 1e27. There is no division, no scale conversion, no downcast. The supply fits in uint128, so Uniswap v4 liquidity accounting cannot overflow.
• Boundary. No external calls except the ecrecover precompile, no payable path, no bytes decoding. A scratch suite of 25 tests drove every entry point at zero, max, one-wei-over, exact-allowance, infinite-allowance, deadline-equals-now, high-s, bad-v, zero owner or spender, and chain-id change. All behaved as the standard specifies.
• Numerical Gap. A fuzz over mixed transfers and burns held the sum-of-balances equals totalSupply invariant on every run. Allowance is checked before balance, and a balance revert leaves the allowance untouched.
• Forbidden opcodes. A reachability scan of the runtime bytecode finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Sending ETH reverts.
• Static analysis lead. The aderyn large-literal note on line 28 is not a defect; the constant is asserted exact.

Recorded finding (info only) Zero-value transferFrom and burnFrom succeed with no allowance and emit a Transfer event naming any from address. Balances and supply are untouched. This is ERC-20-conformant OpenZeppelin behaviour and is noted only as an address-poisoning vector for off-chain indexers.

Coverage. All six entry points have rows, plus five invariant rows. Not reached: nothing within my area. Outside it, I did not assess the deploy script's broadcast path or launch manifest contents, which belong to the other specialists.

The findings file is valid JSON and no tracked file in the repository changed. The review is complete.

Outcome: no economic defect found. The token is OpenZeppelin v5.4.0 ERC20 + ERC20Burnable + ERC20Permit with constants only and no custom transfer logic, so none of the failure modes in the Economic Security, Invariant or Flow Gap guides has a surface to land on. The findings file holds one informational entry and a full coverage record.

What I checked and how

• Economic Security guide. No external dependencies, oracles, callbacks or price-dependent paths exist. The launch flows (factory to distributor, distributor to claimant, pool manager seed and both swap directions, remainder to the requester) move exactly what they say because there is no fee, tax, blocklist or pause. ERC-20 and ERC-2612 compliance were traced through the vendored code and the project's 40 tests, which all pass.
• Invariant guide. I wrote a Foundry invariant test with a handler driving random transfer, approve, transferFrom, burn, burnFrom and permit calls across five signers and the factory. The conservation law (sum of balances equals totalSupply, which equals initial supply minus burned) never broke. Supply is monotone non-increasing and no mint path exists after the constructor. The 10/50/40 split of 1e27 is dust-free.
• Flow Gap guide. The constructor takes no arguments and makes no external call, so the single-transaction launch cannot be derailed by it. The protected floor tests for supply, decimals, swarm share, seed and swaps, no supply growth, and no privileged freeze would all pass on this code by inspection.
• Supply chain. Because the library is vendored as plain files, I diffed every Solidity file against the upstream v5.4.0 tag. All differences are forge fmt reformatting, including in the files that compile into this token, so the library is semantically v5.4.0.

The one entry, severity info. Anyone can submit a holder's permit signature first, which makes the holder's own bundled permit-plus-transferFrom transaction revert. The allowance still lands with the intended spender and no funds move, so this is the documented ERC-2612 property rather than a MAD defect. I recorded it with a reproduction so integrators building routers on MAD know to wrap permit in try/catch.

Coverage. All six verifier entry points have rows (five holds, permit marked finding pointing at the info entry), plus rows for the conservation invariant, the launch split, the constructor mint, the vendored-library check, and the documented stuck-tokens note. Nothing was left unreached. The scratch tests live in test/scratch/EconScratch.t.sol, which is not part of the submission.

The review is complete and the findings file is written. No defects were found in the MAD token.

Outcome. The token is OpenZeppelin v5.4.0 ERC20 + ERC20Burnable + ERC20Permit with constant name, symbol, decimals and a one-time constructor mint of 1e27 units to msg.sender. The control-flow area (Execution Trace, Periphery, First Principles) is clean. The file .imd-findings.json holds two informational notes and ten coverage rows, all six listed entry points answered.

What I checked and how:

• Execution trace. Traced approve, transfer, transferFrom, burn, burnFrom and permit through the vendored ERC20 core to their guards and state writes. Zero-address checks, balance and allowance reverts, infinite-allowance handling, nonce consumption, deadline, domain separator and signature malleability all behave as the standard specifies. A scratch Foundry test confirmed each edge case and was removed afterwards.
• Periphery. The vendored OpenZeppelin tree differs from the npm 5.4.0 tarball in many files, but only by forge-fmt reformatting. Compiling the same MADToken against the pristine npm package produced byte-identical creation bytecode, runtime bytecode and ABI, so no library tampering reaches the deployed contract.
• First principles. Supply constant evaluates to exactly 1,000,000,000 × 10^18. No mint path exists after construction. No external calls other than the ecrecover precompile, no receive or fallback, and an opcode walk of the runtime with the floor test's algorithm found no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. The launch flows move exactly what they send since there is no fee, hook or blocklist. The project's 40 tests pass.

The two info notes are inherent ERC-20 and ERC-2612 behaviours, not code defects, and recommend no code change: the approve overwrite race, and permit relay front-running that can revert an integrator's bundled permit-plus-transferFrom. Each has a concrete reproduction so the author can decide whether to document them.

Static analysis leads. Slither reported nothing. Aderyn's "large numeric literal" at line 28 is a style note on a correct compile-time constant and was not promoted.

Not reached. Nothing in the assigned area. The manifest was not reviewed because no launch.json exists in the tree yet.

Added failure-path, permit, fuzz, and stateful invariant tests. Fixed the existing self-transfer assertion. All changes are under test/.

Offline verification with the required seed passed: build successful, 82 tests passing, and three invariants checked across 32,768 random calls.

No implementation defects found.

The findings file is written and valid, with the snippets copied from the source lines they cite. The review is complete.

Outcome: no defect in MADToken. Three info notes kept, one specialist finding dropped, nothing blocks the launch.

What I verified against the code:

• The token is pure OpenZeppelin 5.4.0. Compiling the same source against the pristine npm package yields byte-identical creation and runtime bytecode, so the vendored copy's formatter-only diffs change nothing.
• Launch floor holds. A scratch test mirroring the protected floor passes: CREATE2 from a factory stand-in mints the whole supply to the factory, decimals are 18, swarm and claim flows move exactly, no admin selector raises supply, no privileged call from the deployer moves or freezes a holder, burnFrom without allowance reverts, no receive or fallback, and a reachable-opcode scan finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. Runtime is 4353 bytes, far under the limit.
• Project suite is green. All 82 tests pass, with the fuzz contract at 1000 runs.
• Manifest is consistent. Schema keys only, empty constructorArgs matching the no-arg constructor, totalSupply equal to the minted constant, lowercase addresses, short notes. Whether economics match the job verbatim is admission's check and not visible from here.

How I settled the specialists:

• Merged the audit_flow and audit_economics permit front-run reports into one info finding. Reproduced in my own scratch test. Inherent to ERC-2612, no loss.
• Kept as info the approve race and the zero-value transferFrom event note. Both reproduced. Both are standard ERC-20 behaviour, no change recommended.
• Dropped the audit_permissions low about the failing fuzz test. The cited test already carries the self-transfer branch, added in the test commit after that specialist ran, and the suite passes.

Coverage: all six entry points marked holds, plus rows for the constructor, bytecode, manifest and the dropped finding. The result is in .imd-findings.json at the repository root. Scratch tests under test/scratch are mine and not part of the submission.