The MAD token is implemented, tested, documented, and committed on main as d30bb41.

What was built

• src/MADToken.sol: the MADToken contract. The constructor mints 1,000,000,000 MAD with 18 decimals to msg.sender once, with no constructor arguments and no external calls. It inherits OpenZeppelin's ERC20 and ERC20Permit, and adds a holder-only burn that rejects zero. There is no owner, mint, pause, blocklist, burnFrom, fee or upgrade path, so the launch flows move exactly what they say and nothing can grow the supply.
• test/MADToken.t.sol: 39 tests, all passing with the verifier's fuzz seed. They cover metadata, the single mint and its events, exact transfers and supply conservation, failure cases for transfer, transferFrom, approve and burn, permit success, expiry, wrong signer and replay, the launch flow from factory to distributor to claimant arriving whole, the floor's list of mint and freeze selectors all reverting, and a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT. Four fuzz tests check supply, burn and allowance accounting.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables CBOR metadata and ffi, and grants no filesystem permissions. remappings.txt maps forge-std and OpenZeppelin.
• lib/forge-std v1.9.7 and lib/openzeppelin-contracts v5.4.0 are vendored as plain files, trimmed to source and licenses, with no git metadata or submodule.
• README.md documents behaviour, assumptions, the manifest values for supply and decimals, and the operational responsibilities after launch. There is nothing to configure post-launch since the token has no owner or settable value.

Checks run

forge build --offline     Compiler run successful
forge test --offline      39 passed, 0 failed
forge fmt --check         clean

Not done here

Slither was not run since the task does not provide it. The design avoids its rejected detectors: no selfdestruct, no library calls, no assembly shifts, no packed encoding of dynamic values, and transferFrom only spends the caller's allowance. The pinned protected tests run in the verifier's own harness with v4-core, which is not part of this repository.

I wrote launch.json for the MAD launch, and it is the only file I changed. I left it uncommitted.

What's in the manifest, based on the accepted code in src/MADToken.sol:

• Token: contract MADToken, named "Mutually Assured Destruction", symbol MAD, 18 decimals. Its constructor takes no arguments, so constructorArgs is an empty list. totalSupply is "1000000000000000000000000000", which is exactly the one billion tokens the constructor mints to the deployer.
• Contracts: an empty list. The accepted code contains only the token.
• Pool: paired with FWA (0xa0df17b5ac76ababa36e1450e2cbcd18a620c845), fee 12500, tick spacing 60, and starting price 79228162514264337593543950336 (one to one).
• Economics: copied word for word from the brief.
• Notes: 644 characters (the limit is 4,000) describing the token: a fixed supply, no owner, no fee on transfer, and holders can burn only their own tokens.

Nothing here validates the manifest itself. I checked it by reading it against the brief and the schema rules, and confirmed it parses as JSON. forge build and forge test passed, with 39 of 39 tests using the required fuzz seed. Those are the repo's existing token tests, not the protected check files, which weren't run.

I found no defects in the economics area for MADToken. .imd-findings.json has an empty findings list and 8 coverage rows: all 5 entry points marked holds, plus 3 rows for invariants I checked.

What the code is: src/MADToken.sol is OpenZeppelin ERC20 and ERC20Permit with nothing changed, plus a 4-line burn that only the holder can call. I compared the vendored OpenZeppelin copy in lib/ against the upstream v5.4.0 release, and the only difference is that the mocks/ folder is left out. So there are no altered library internals to worry about.

Checks against the three guides:

• Economic Security: the token has no transfer fee, rebase, blacklist or pause, and makes no calls to other contracts. So none of the launch transfers can arrive short of what was sent: factory to distributor, distributor to claimant, the pool seed, and swaps. Supply can't grow after deployment. The permit signature format is the standard one (name "Mutually Assured Destruction", version "1"), it follows the chain ID, and each signature works only once.
• Invariant: I checked that all balances add up to total supply, that supply only goes down after the constructor, and that each burn lowers supply by exactly its amount. A throwaway fuzz test of these covered transfer, approve, transferFrom and burn across four holders. It passed, and I deleted it afterwards.
• Flow Gap: there is no point where an amount is computed before a call and reused after it, no callbacks, and no external calls. Nobody can burn another address's tokens, so the distributor's and the pool's balances can't be destroyed by anyone else.

The project's own 39 tests all pass. The one static-analysis lead (aderyn, "large numeric literal" at line 26) is just the supply constant, which is correct as written (1e27). It isn't a defect.

Two standard ERC-20 behaviours I deliberately didn't report, because neither is a defect in this code: tokens sent to the token's own address are stuck for good, and someone can get a permit signature in first, so a later contract call that uses that permit fails.

No repository files were changed. The empty {"findings":[]} placeholder was replaced by the final report.

The review is complete. The math audit of the MAD token found no defects.

What I checked. The token is OpenZeppelin v5.4.0 ERC20 + ERC20Permit plus a twelve-line holder-only burn, and nothing else. I ran the Math Precision, Boundary and Numerical Gap passes against every entry point and the inherited code paths they reach:

• Precision. The only arithmetic the contract adds is the compile-time constant for the supply, which evaluates to exactly 1e27 minor units. No division, scaling, casts or fixed-point math exist anywhere in the token.
• Boundary. Transfers and burns at zero, whole balance and max uint all revert or succeed exactly as the ERC-20 spec says, with the right error values. Permit accepts a deadline equal to the current timestamp and max uint, rejects high-s malleable signatures, cannot be satisfied for the zero owner, and rolls back its nonce when the spender is zero.
• Seams. Balance conservation held under fuzzing across transfer and burn mixes, including burning the whole supply down to zero. The unchecked subtractions in the inherited update logic are guarded by the preceding balance check.
• Library integrity. The OpenZeppelin tree is vendored as plain files, so I compared all 207 Solidity files against the upstream v5.4.0 release tarball. Every one is byte-identical.

Static-analysis lead. The aderyn large-literal warning is the supply constant itself, which is exact. It is not a defect.

Output. The findings file at the repository root holds an empty findings list and nine coverage rows: one holds row for each of the five entry points, plus rows for the single-mint invariant, decimals agreement, library integrity and the absence of any payable path. The existing test suite passes, and I removed my scratch tests after running them.

One non-defect worth knowing: decimals() returns OpenZeppelin's default 18 rather than reading the contract's own DECIMALS constant. Both are 18 today, so there is no failing input, but wiring them together would make the agreement structural rather than coincidental.

The review is complete and the findings file is written. The tree is otherwise unchanged (scratch tests removed, no source edits).

Outcome: no defects found in the control-flow area. The MAD token is OpenZeppelin v5.4.0 ERC20 + ERC20Permit plus a 5-line holder-only burn, with no constructor arguments and no privileged role.

What I checked, per the three assigned guides:

• Execution Trace. Traced all five entry points from call to final state. Sentinel inputs (zero owner, zero receiver, zero spender, max amounts), signature malleability (high-s), nonce replay, deadline boundary, cross-chain domain separator, approval residuals and infinite allowance all behave as ERC-20 and EIP-2612 specify. Verified with an 8-test scratch suite, all passing, and the project's own 39 tests.
• Periphery. All 19 OpenZeppelin files compiled into the token were compared byte-for-byte against the upstream v5.4.0 tag. All identical, so no vendored modification hides in the base contracts.
• First Principles. The constructor mints exactly 1e27 to msg.sender once, reads no chain state and calls nothing. The ABI exposes 18 selectors, none of them mint, owner, pause, freeze, upgrade or burnFrom. Supply can only shrink, which the launch floor explicitly permits.

Written to .imd-findings.json:

• One informational note, not a defect. burn and permit go beyond the brief's literal words, so after any burn totalSupply is below 1,000,000,000 MAD. Reproduction given. The requester should confirm this is intended, or drop burn for a strictly constant supply.
• Eight coverage rows, all holds: the five listed entry points, the constructor mint, the vendored library periphery, and the supply and opcode invariants.

Not covered: no launch.json exists yet, so the manifest was not reviewed. When it is written, constructorArgs must be empty and totalSupply must be 1000000000000000000000000000.

The review is complete. The findings file holds zero defects and nine coverage rows, and the working tree is otherwise clean.

Result: no defects found in the permissions area. The token is OpenZeppelin ERC20 plus ERC20Permit plus a twelve-line holder-only burn, with no owner, role, modifier or settable state.

What I checked, per guide

• Access Control. The compiled ABI has exactly five state-changing functions and no hidden ones. Storage holds only balances, allowances, supply, name/symbol strings and permit nonces. Every writer of every slot is bound to the caller or to a verified EIP-712 signer, so there is no weaker-guard writer to exploit. The constructor takes no arguments and mints the full supply once to the deployer, with no second mint path.
• Trust Gap. The only trusted actor is the deployer, and after construction it has no power beyond any holder. I verified this with a probe: the deployer gets the same allowance and balance errors as a stranger. I also diffed all 207 vendored OpenZeppelin files against the published v5.4.0 npm release, byte for byte, with no differences, so the inherited code carries nothing hidden.
• Asymmetry. Approve and permit set the same slot under equivalent authority. A third party relaying a permit sets only what the owner signed and gains nothing. Burn reaches only the caller's balance, and an approved spender cannot route a burn through a transfer to the zero address. Transfers from the zero address cannot mint under either a positive or a zero amount.

Static analysis leads. Slither reported nothing. Aderyn's large-literal note on line 26 is the supply constant, which evaluates to exactly 1e27 and is not a defect.

Limits. The protected launch floor test could not be run here because it depends on v4-core, a LaunchLiquidity source and environment variables absent from this tree. The repository's own suite mirrors its checks and passes, 39 tests including fuzz runs. My scratch probe of seven permission edge cases also passed and was removed afterwards.

Added failure-path, boundary, permit-security, and multi-actor invariant tests, plus coverage notes. All additions are under test/.

Validation passed:

• forge build
• forge test with the specified seed: 75 passed, 0 failed
• Invariants: 32,768 calls, no unexpected reverts
• Formatting checks

No implementation defects were reproduced.

Review complete. The MAD token has no defects; the findings file holds one reproduced info note and a full coverage record.

What I verified

• The contract is OpenZeppelin v5.4.0 ERC20 plus ERC20Permit with a five-line holder-only burn. Every vendored OpenZeppelin file it depends on hashes identically to upstream v5.4.0, so the token's behaviour is the library's.
• The project's own 75 tests pass, including the invariant suite. The formatter check is clean.
• Constructor takes no arguments and mints exactly 1e27 to msg.sender with no external calls. Runtime and creation code are far below the size limits, and there is no receive, fallback, owner, mint, DELEGATECALL or SELFDESTRUCT path.
• launch.json matches the contract: name, symbol, decimals, empty constructorArgs and a totalSupply equal to the constructor mint, with schema-valid types and lowercase addresses.

Specialist findings

Four specialists and the tester reported one item in total, from audit_flow at info severity. I reproduced it in a scratch test: the factory calling burn(1) lowers totalSupply and its own balance by exactly one, while a stranger's burn reverts and burnFrom does not exist. It is a scope confirmation, not a defect, since the launch floor permits a shrinking supply and the README documents it. I kept it as the single info finding so the requester can confirm burn and permit are wanted. Nothing to merge, nothing dropped.

Coverage

All five entry points are marked holds, with two extra rows for the constructor and the manifest. No proof files were needed because there is no critical or high finding. The scratch test was removed, so the only file written is .imd-findings.json.