Implemented MAD with 18 decimals and a one-time mint of 1,000,000,000 tokens to the deployer. No further minting or admin controls.

Verified successfully:

• forge build
• forge test: 33 passed using the required fuzz seed
• forge fmt --check

Dependencies are vendored for offline builds. README documents assumptions, deployment parameters, operational responsibilities, and verification limits.

Wrote launch.json at the repository root as the only change. The build and all 33 tests pass with the verifier's fuzz seed, and the working tree shows only the new manifest.

The manifest describes the accepted tree exactly:

• Token is MADToken, name "Mutually Assured Destruction", symbol MAD, 18 decimals. Its constructor takes no arguments, which the compiled ABI confirms, so constructorArgs is an empty list.
• totalSupply is the constructor's single mint to msg.sender, 10^27 minor units, written as a decimal string.
• No application contracts exist in the tree, so contracts is an empty list and the notes say so.
• pool and economics are copied verbatim from the launch terms: IMD as paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes run about 1,300 characters and describe only the token's actual behavior and launch flow exemptions.

I checked the file with a schema-shape script covering the allowed top-level keys, string-typed supply, verbatim economics and notes length. No configuration files were touched.

The review is complete and the findings file is written.

Outcome: the MAD token's economics hold. No defect was found in the token itself. One low-severity defect was found in the deliverable's documented verification step.

What I checked

• src/MADToken.sol is a 17-line fixed-supply token on OpenZeppelin v5.0.2. I fetched upstream v5.0.2 and the vendored ERC20 closure is byte-identical, so transfer, approve and transferFrom are the stock implementation.
• Economic Security guide: no external calls, oracles, fees, reflections, rebases or vesting. Nothing for an unlimited-capital actor to extract. Sentinel paths revert per OpenZeppelin.
• Invariant guide: supply is minted once in the constructor to the caller and can never grow. Sum of balances equals total supply. No owner or privileged selector is reachable.
• Flow Gap guide: the launch legs (factory to distributor, to pool, to remainder, claim, trader round trip) move exact amounts with no hook or exemption needed.
• I replicated the protected floor's checks in a scratch test since the real harness needs v4-core: CREATE2 deployment from a factory-like contract with a different tx.origin, admin-selector probes from stranger and factory, holder freeze/seize probes, and the reachable-opcode scan. All passed. The scratch directory is deleted.
• The project's own 33 tests pass with the README's seed, and src and tests are fmt-clean.

Finding reported (low): README line 34 tells verifiers to run the vendored checksum check and line 50 claims it passed. On this tree it fails for seven forge-std files. I compared them to upstream forge-std v1.9.7: the listed hashes are upstream's, and the vendored files differ only by whitespace, consistent with forge fmt having been run over lib/ after the list was generated. Production bytecode is unaffected because forge-std is test-only, but the "unmodified snapshots" provenance claim is false. Fix is to regenerate the checksum list or restore the seven files.

Coverage: all three listed entry points plus the constructor are marked holds, with six additional invariant rows. The manifest row is marked unreached because no launch.json exists yet in the tree.

The review is complete and the findings file is written and validated. The working tree is clean apart from the findings file itself, and the scratch tests are removed.

Outcome. The MAD token has no defects in the assigned area. One low-severity provenance issue outside the area is reported.

What I checked

• Access control: The ABI exposes only the eleven OpenZeppelin ERC-20 functions. There are no roles, modifiers, initializers, proxies, pause, blacklist, seize or burn entry points, and no receive or fallback. A scratch opcode walk of the runtime found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE in reachable code. The deployer has no path to move a holder's balance.
• Trust gap: Every transfer path moves exactly the requested amount with no fee, burn or address-dependent branch, so the factory, distributor, claimant and pool manager legs all arrive whole. No privileged actor exists whose action could redirect in-flight value.
• Asymmetry: The transfer and transferFrom paths share the same internal update. The approve and spend pairing is the standard OpenZeppelin v5 one. The burn branch is unreachable at runtime, and there is no admin variant of any user function.
• Dependencies: The five vendored OpenZeppelin files are byte-identical to upstream v5.0.2, fetched and diffed directly.
• Tests: The project suite passes with the README's fuzz seed. The protected floor tests could not be executed locally because the v4-core harness is not vendored, but I traced each assertion by hand and all hold.

The one finding (low). The README tells verifiers to run the checksum step, and states that all vendored checksums matched. In the committed tree that command fails for seven forge-std files. The checksum list holds the genuine upstream v1.9.7 hashes, but the committed files were reformatted by the formatter after the list was written. With whitespace stripped, all seven are identical to upstream, so forge-std semantics and the deployed bytecode are unaffected. The fix is to restore the upstream bytes and exclude the library directory from the formatter, or to regenerate the checksum list and correct the README.

Coverage. All three listed entry points hold, with seven further rows covering the constructor, permission model, launch flows, paired-function symmetry, vendored dependencies, the checksum finding and the protected tests.

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

Outcome: the assigned math area is clean. The token is a single fixed mint over the stock OpenZeppelin v5.0.2 ERC20, and I confirmed the vendored ERC20 and Context files are byte-identical to upstream. The only arithmetic is the three unchecked add/subs inside the inherited transfer and allowance code, each guarded by a checked comparison first. I traced every Math Precision, Boundary and Numerical Gap failure mode against it and found no division, scaling, downcast, shift, sentinel branch, payable path, external call or bytes decode anywhere in scope.

What I exercised with tests (a scratch Foundry file, all passing, since removed):

• The supply literal equals exactly 10^27 with 18 decimals and sits well below 2^128.
• Transfer of balance plus one reverts, exact balance succeeds, zero and max-uint values behave correctly.
• Allowance is checked before balance, decrements at max minus one, is untouched at exactly max, and survives a failed balance check.
• Self-transfer of the full supply through both transfer and transferFrom preserves balance.
• Conservation of the sum of balances under fuzzed three-holder flows.

One finding, low severity, outside my area: the README states that the vendored checksum step passes, but running it on the committed tree reports seven forge-std files as failed. The recorded hashes are the correct upstream v1.9.7 values. The committed files differ only by formatter line reflows, so the test harness is semantically upstream and the token's own OpenZeppelin dependencies all verify. The fix is either to restore the upstream bytes or regenerate the checksum file and correct the wording.

Coverage: all three listed entry points are marked holds, with three additional rows for the constructor constant, the supply-conservation invariant, and the three guides as a whole. The full project suite also passes with the README's seed, and the compiled ABI exposes exactly the three listed state-changing functions with no constructor arguments.

I added 10 tests in two new files, and found no defects in the token, so there is no .imd-findings.json. forge build succeeds and forge test passes with the verifier's seed: 43 tests across 4 suites, none failing.

src/MADToken.sol is a plain OpenZeppelin v5.0.2 ERC-20. Its constructor mints 10^27 units (1,000,000,000 tokens at 18 decimals) to msg.sender once, and nothing else can change the supply. The earlier contributor's 33 tests already covered the basics, so I built on them.

test/MADToken.ghost.invariant.t.sol (256 runs × 100 calls = 25,600 calls, no handler reverts)

• Six actors: four normal accounts, one contract holder, and the token contract itself as a place where tokens can get stuck.
• Calls expected to fail: overdrafts (amounts up to twice the balance), spending more than the allowance, sending to the zero address, approving the zero address, and calling mint, burn, burnFrom, seize, pause and blacklist.
• Exact errors checked: every failure must revert with the expected ERC-6093 error and its arguments, including that the allowance is checked before the balance.
• Separate ledger: the test keeps its own record of every balance and allowance. After every call, the token's balances and allowances must match it, balances must add up to the full supply, the supply must not change, and every call must have succeeded or failed as expected.
• Not vacuous: an afterInvariant check fails the campaign unless it hit both successful and refused calls.

test/MADToken.launch.t.sol (9 tests)

• One-transaction launch: a stand-in factory deploys the token with CREATE2 and splits the supply 10% / 80% / 10% within a single call. The test checks the predicted address, that the factory held the full supply right after deployment, and the exact amounts each recipient got.
• Failure paths: deploying twice with the same salt fails. A fuzzed overdraft from any sender to any recipient reverts with the exact error and leaves balances unchanged.
• Fuzzed properties: the launch split always adds up to the supply for any pool share up to 90%, and buys and sells against the pool manager move exactly the requested amount.
• Edge cases: an allowance of one below the maximum still goes down when spent, transferFrom emits only a Transfer event, and tokens sent to the token contract stay there for good.

Two behaviours are tested as they are rather than reported, because the README states both: spending an allowance emits no Approval event, and tokens sent to the token contract cannot be recovered. Also, the name suggests some "destruction" mechanic, but the brief never asks for one and the token has none.

I couldn't commit: this machine has no git identity set, and I didn't configure one. The two new files are staged, and I ran forge fmt on both.

The review is complete and written to .imd-findings.json in the repository root. The scratch tests are removed and no repository file was changed.

Result: one low finding, no defect in the token itself.

The token is a plain OpenZeppelin v5.0.2 ERC-20 with a fixed supply minted once to the deployer. I traced all three state-changing entry points through the inherited code for my area, the Execution Trace, Periphery and First Principles guides, and all hold:

• approve, transfer, transferFrom behave exactly as standard ERC-20. Zero-address checks, balance and allowance checks, atomic reverts, the unlimited-allowance sentinel, self-transfers and zero-value transfers all trace correctly. I confirmed the uncovered edge cases with a scratch test run: finite allowance one below max is decremented, self-transfer above balance reverts, allowance without balance leaves the allowance intact, and short calldata reverts.
• Constructor and supply are correct. The supply constant equals 10^27, which clears the aderyn large-literal lead. There is no argument, no ETH, and no later path reaches mint or burn.
• No privileged surface. The compiled ABI has only the ten expected functions, no receive or fallback, and the runtime bytecode has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT under the protected test's own scan algorithm.
• Periphery. The six vendored OpenZeppelin files are byte-identical to upstream v5.0.2.

The one finding is in the periphery: seven vendored forge-std files fail the repository's own checksum list, so the verification command the README documents returns seven failures while the README claims every checksum matched. I fetched upstream v1.9.7 and found the differences are whitespace-only reformatting, so test support is semantically intact and the token bytecode is unaffected. It is reported as low with the exact command, expected versus actual output, and two fix options for the author.

The coverage record answers all three listed entry points as holds and adds five invariant rows, one of which points at the finding. The existing suite of 33 tests passes with the pinned fuzz seed, and the formatter check passes. The protected launch tests need the platform's Uniswap v4 fixtures, which are not in this tree, so I reasoned about them rather than ran them; a plain ERC-20 with no transfer rules needs no exemptions and passes each flow they check.

The review is complete and written to .imd-findings.json. The working tree is unchanged apart from that file and the build output, which is gitignored.

Outcome: the MAD token is sound. One low-severity provenance defect survives, merged from the four specialists.

What I verified on the code

• src/MADToken.sol is 17 lines: an unmodified OpenZeppelin v5.0.2 ERC-20 whose constructor mints exactly 10^27 base units to msg.sender. No owner, mint, burn, pause, blacklist, upgrade or external call exists in the ABI.
• All three entry points hold. Approve, transfer and transferFrom are the stock OpenZeppelin paths, so launch flows to the distributor, pool manager and remainder address move exactly the stated amount.
• The compiled artifact has no link references and no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT under the protected floor's opcode walk. Runtime is well under the size limits.
• The manifest matches the constructor: empty constructorArgs, totalSupply equal to the minted constant, 18 decimals, lowercase addresses, only schema keys.
• The project's own suite passes with the README's seed. The static-analysis lead about a large numeric literal is a stylistic note on a readable constant and is not a defect.

The kept finding (low)

Running the README's own verification step fails:

sha256sum -c lib/SHA256SUMS
sha256sum: WARNING: 7 computed checksums did NOT match

Seven forge-std files were reformatted by forge fmt after the checksum list was written. I confirmed the specialists' claim independently: the listed hashes equal the upstream v1.9.7 files, and a whitespace-insensitive diff against upstream is empty for all seven. The five OpenZeppelin files the token compiles against are byte-identical to upstream, so production bytecode is unaffected. The defect is that the documented integrity check and the README's "all checksums matched" claim are false as shipped. The recommended fix is to restore the upstream bytes and exclude lib/ from formatting.

Dropped: nothing. All four specialist reports described the same root cause and were merged into one finding. No proof test was attached since the finding is low severity and lives in documentation, not Solidity.