The scratch floor simulation passes too. The deliverable is complete.

Delivered: a Foundry project at the repository root for the Mutually Assured Destruction (MAD) token.

• src/MADToken.sol is the token, Solidity name MADToken. It is a plain OpenZeppelin v5.1.0 ERC-20 that mints 1,000,000,000 MAD with 18 decimals to the deployer in the constructor and emits a one-time SupplyMinted event. It has no owner, mint, burn, pause, blocklist, upgrade path, fee on transfer, or constructor arguments, and the constructor calls no other contract.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none" with CBOR metadata off, enables the optimizer, and grants no ffi or filesystem access. Remappings point at vendored lib/forge-std v1.9.7 and lib/openzeppelin-contracts v5.1.0, copied in as ordinary files with no nested git metadata.
• test/MADToken.t.sol holds 31 tests: metadata and supply, success and failure paths for transfer, approve and transferFrom, a sweep confirming no mint or admin selectors exist and the deployer cannot move a holder's balance, a reachable-opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and four fuzz tests for conservation of supply and allowance bounds. test/DeployMADToken.t.sol calls the deploy script's function directly.
• script/DeployMADToken.s.sol is a reference deploy script that reads no environment variables.
• README.md documents behaviour, assumptions, the launch-decided deployment parameters, the absence of post-launch configuration, operational responsibilities, and security notes.

Verification: forge build, forge test with the verifier's fuzz seed, and forge fmt --check all pass on a clean rebuild, 33 tests passing. A scratch test also deployed the raw creation code through CREATE2 from a factory stand-in and confirmed the whole supply lands on the factory and the protected floor's privileged-call list cannot move or freeze a holder. Slither was not available on this machine, so it did not run.

Not done by design: no launch.json was written, no transactions were signed, and no features beyond the brief's name, symbol and supply were added.

The economics review of src/MADToken.sol found no defects. .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds. I didn't run any tests or write a Foundry proof, because there was nothing to reproduce. I didn't run the two protected test files either.

The contract is OpenZeppelin's standard ERC20 with nothing changed except decimals(), which always returns 18. It has no owner, no extra mint or burn functions, no transfer fee or burn, no pause, no blocklist and no upgrade path.

• Supply: exactly 1,000,000,000 × 10^18 is minted to msg.sender (the factory) in the constructor. No function can mint or burn after that, so the supply can never grow.
• Launch flows: transfers move exactly the amount requested. The swarm's share to the distributor, the pool seed through the PoolManager and later swaps all arrive in full.
• Privileged powers: none exist, so no one can move or freeze a holder's balance.
• Static analysis: aderyn's one low lead, the large number on line 25, is just how the total supply is written. Slither reported nothing.

I also added two invariant rows, fixed supply and no privileged control over balances, and both hold.

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

forge build succeeded. All 33 tests passed with the supplied fuzz seed. Manifest fields and constructor ABI checks passed. Only launch.json is changed for submission.

The review is complete. The findings file holds an empty findings list and eight coverage rows, and the working tree is clean apart from that file.

Result: no defects in the math, boundary or numerical-gap area. The token is a thin wrapper over OpenZeppelin ERC20 v5.1.0 whose only arithmetic is the supply constant in the constructor. I verified every failure mode the three guides list against it rather than assuming.

What I checked and how:

• Supply constant. The literal flagged by aderyn evaluates to exactly 1e27 at compile time under checked arithmetic. Both the constant getter and totalSupply() return that value. It is below 2^90, so no unchecked add in OZ's balance update can ever wrap.
• Max-input boundaries. Transferring 2^256-1 or supply+1 reverts with the insufficient-balance error before the unchecked subtraction. A self-transfer of the whole supply leaves the balance untouched.
• Allowance edges. The max-uint sentinel is not decremented, max-1 is. An exact-match allowance drops to zero and the next wei reverts. An infinite allowance over a small balance still reverts on balance, so no wrap through the allowance path.
• Zero-value fast paths. Zero transfers from empty accounts and zero transferFrom with no allowance succeed as no-ops with no state drift, which is the ERC-20 standard's required behaviour.
• Conservation invariant. A 256-run fuzz of random transfers among three holders kept the sum of balances equal to the supply with no rounding, since the contract has no division, fee or burn.
• External boundaries. The compiled ABI has no payable, receive or fallback entry. The only sentinel branches are OZ's zero-address checks, traced on both sides. There are no external call sites and no bytes decoding.
• Dependency integrity. The five vendored OpenZeppelin files the token compiles against are byte-identical to the upstream v5.1.0 tag.

Tools run: forge build, the project's 33 tests, and 16 scratch tests I wrote and then removed. Slither and aderyn output were supplied, not run. No launch.json exists in the tree yet, so there was nothing in the manifest to check; the README's stated supply of 1e27 matches what the constructor mints.

The review is complete. No defects were found in the assigned area, and .imd-findings.json holds an empty findings list with nine coverage rows.

What I checked. The token at src/MADToken.sol is a 43-line wrapper over OpenZeppelin ERC20 v5.1.0 whose only custom code is a constructor mint of 1e27 units to msg.sender and a decimals override returning 18. I read the Senior Auditor's Mindset and the Access Control, Asymmetry and Trust Gap guides from the Pashov reference, then checked each failure mode against the code.

• Access control. The compiled ABI exposes exactly three state-changing selectors, with no receive or fallback, no initializer, no owner, no minter, no pause, no blocklist and no proxy. A fuzz probe sent arbitrary selectors from arbitrary callers and never changed supply or any balance.
• Trust gap. There are no admin setters, so no privileged actor can redirect value or create an asymmetric outcome. The only trust assumption is that the deployer holds the whole supply after construction, which is the launch design: the ProjectFactory is the deployer and distributes it.
• Asymmetry. The transfer and transferFrom pair share the same internal path; a self-approved transferFrom produced identical balance deltas to transfer across 512 fuzz runs. The deployer and a stranger are treated identically on transferFrom without allowance.
• Library integrity. I read the vendored ERC20.sol and Context.sol line by line. Both match genuine v5.1.0 logic with no hidden hooks.

Verification. The project builds on solc 0.8.26 and all 33 existing tests pass. My seven scratch probes also passed, and the scratch directory has been removed so the tree is unchanged.

Static analysis leads. Slither reported nothing. The aderyn large-numeric-literal note on line 25 is a computed constant that equals the brief's supply, so it is not a defect.

Coverage rows. All three listed entry points are marked holds, plus rows for the constructor, the no-privileged-surface invariant, fixed supply, library integrity, the deployer trust assumption and the deploy script. Nothing was left unreached.

I added invariant tests and launch-flow and boundary tests for the MAD token, and found no defects to report. forge build is clean, and forge test with the verifier's fuzz seed passes all 58 tests (33 already there, 25 new).

The token is a plain OpenZeppelin ERC20 that mints 1,000,000,000 × 10¹⁸ to the deployer and has no other logic. Nothing in it needed reporting, so I didn't write a .imd-findings.json.

New files (only under test/):

• test/MADToken.invariant.t.sol: random-call invariant tests, at 256 runs × depth 64, set in the file.
  • A handler drives six actors, including the deployer, a stand-in distributor and a stand-in pool manager.
  • It mixes calls that should succeed (transfer, approve, transferFrom) with calls that should fail: transfers above balance, transferFroms above allowance, transfers to the zero address, approvals to the zero address, and ten admin-style functions such as mint, burnFrom, seize and freeze.
  • Each failing call must revert, and where OpenZeppelin defines a specific error, with exactly that error.
  • The handler keeps its own record of every balance and allowance, so the checks compare the token against that record rather than against itself.
  • After every call, these must hold: the supply never changes; the actors' balances add up to the supply; every balance and allowance matches the record; no call misbehaved; the zero address and the token itself hold nothing; name, symbol and decimals don't change.
  • The run made 16,384 calls with no unexpected reverts.
• test/MADTokenLaunch.t.sol:
  • Launch tests: a stand-in factory deploys the token with CREATE2 and splits the supply 10% / 80% / 10% in a single call, the way the launch does in one transaction. The tests check that every share arrives whole, that the CREATE2 address can be predicted, and that the same salt can't be used twice. Fuzz tests check that the distributor can pay out its whole share with nothing left over, and that the pool manager can pay out and pull back exact amounts. The factory can't take holders' tokens after launch.
  • Boundary tests: transfers of the full supply, 1 wei, supply + 1 and the maximum uint256. Also: the owner needs an allowance to use transferFrom on their own tokens; a zero-amount transferFrom needs no allowance; approving from the zero address reverts; only an approval of exactly the maximum uint256 is treated as unlimited; a revoked allowance blocks the spender; a failed transfer changes nothing; the token rejects plain ETH.

To make sure the invariant tests can actually fail, I temporarily added one that should break ("the deployer keeps the whole supply"). It failed within a few calls once 1 wei moved, so the random calls really do move tokens. I then deleted that temporary file.

The new files are not committed.

The review is complete. The findings file is written with an empty findings list and nine coverage rows. Nothing was changed in the tree beyond that file.

Result: no defects found in the Execution Trace, Periphery or First Principles areas.

What I checked and how:

• Entry points. All three (approve, transfer, transferFrom) are the unmodified OpenZeppelin v5.1.0 ERC20 implementations with no override. I traced each check, state write and revert path, and confirmed them with the project's 33 tests plus a scratch suite that mirrored the launch: CREATE2 deployment from a factory contract, the 10/80/10 split, distributor to claimant, pool manager to trader and back. Every leg moved exactly the stated amount and supply stayed at 1e27.
• Constructor and supply. The supply is minted once to msg.sender, which under CREATE2 is the factory. The creation bytecode contains no CALL, STATICCALL, CREATE or DELEGATECALL, so the constructor cannot call out or move the supply. No selector in the ABI, nor a probing mint call from the deployer, changes totalSupply. There is no receive or fallback.
• Periphery. I diffed the vendored OpenZeppelin and forge-std against the upstream v5.1.0 and v1.9.7 release tarballs. The five files the token compiles against are byte-identical. Every other difference is forge fmt reformatting only: whitespace, uint widened to uint256, and hex"19_00" versus hex"1900". No library code was altered.
• Bytecode. A reachability-aware opcode scan of runtime and creation code found no DELEGATECALL, CALLCODE or SELFDESTRUCT. The runtime does use PUSH0 and MCOPY, which Ethereum mainnet, the chain the README names, supports since Cancun. That would only matter on a chain without Cancun, so it is a note, not a finding.
• First principles. Name and symbol are short strings stored by the base constructor, decimals() is a pure override returning 18, storage is only the five standard ERC20 slots, and no privileged role exists after deployment.

Coverage not reached: nothing in my area. The static-analysis lead (large numeric literal at line 25) is a style note; the literal evaluates to exactly 1,000,000,000 × 10^18 and is not a defect. The scratch test directory and the downloaded upstream sources were removed after use.

The review is complete and .imd-findings.json holds the result: no findings, with coverage rows for all three entry points plus three invariants. The working tree is otherwise unchanged.

What I checked

• The token in src/MADToken.sol is a thin wrapper over the vendored OpenZeppelin v5.1.0 ERC20. It adds only constants, a parameterless constructor that mints the whole supply to the caller, and a decimals() override returning 18.
• I read the inherited approve, transfer, transferFrom, _update, _approve and _spendAllowance bodies line by line. They are the unmodified OpenZeppelin code with the standard revert paths.
• A scratch Foundry test deployed the token through CREATE2 from a factory stand-in with empty constructor arguments and exercised every success and revert path of the three entry points. All behaved as the standard specifies, including the deployer being unable to pull from a holder without allowance. The scratch directory was removed afterwards.
• The project's own 58 tests, including the invariant suite, pass.
• The compiled runtime is well inside the size limits and a reachable-opcode scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The manifest is consistent with the code: empty constructor arguments, supply of one billion with 18 decimals, lowercase addresses, schema keys only.

Specialist input and static analysis

All four specialists and the test writer reported nothing, so there was nothing to reproduce or merge. Slither reported nothing. Aderyn's low-severity "large numeric literal" lead at line 25 is a compile-time constant that evaluates to exactly the manifest supply, confirmed by totalSupply(), so it is not a defect and was left out.