Implemented MAD: 1 billion tokens, 18 decimals, minted once to the deployer. Includes vendored dependencies, success/failure tests, fuzz tests, invariants, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 34 tests using the supplied seed.
• forge fmt --check passed.

Full launch integration remains with the independent verifier.

Created launch.json matching MADToken’s constructor, supply, and the exact required pool and economics values.

Verified manifest fields and constructor ABI. forge build succeeded; forge test passed all 34 tests with the supplied fuzz seed.

Only launch.json changed outside the permitted scratch directory.

Review complete. The findings file is written and the working tree is otherwise unchanged.

Outcome. MADToken is a plain OpenZeppelin v5.0.2 ERC-20 with one constructor mint of exactly 10^27 units to msg.sender. I traced all three entry points plus the constructor against the Execution Trace, Periphery and First Principles guides and found no defect in token behaviour. All 34 project tests pass, including the 256-run stateful invariant suite, and the compiled runtime has no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT or external CALL.

One low finding, in the Periphery area. The vendored OpenZeppelin base contracts fail the integrity check the project itself documents.

• VENDORED.md states the Solidity sources are unmodified upstream bytes and tells the operator to run the checksum file. Running it reports two failures, on ERC20.sol and draft-IERC6093.sol.
• I fetched the real upstream files at the pinned commit. Their hashes match the checksum file, so the vendored copies are what drifted. The only difference is formatter whitespace, so there is no behavioural impact.
• The defect is a false integrity claim that produces the same signal a tampered base contract would. Fix: restore the two files to upstream bytes. I confirmed in a scratch copy that this keeps the formatter check, build and tests green.

Coverage record. Eight rows: the three listed entry points and the constructor hold, three invariants hold (fixed supply, exact launch flows, forbidden-opcode scan), and the vendored base contracts row points to finding 1. Nothing was left unreached. The static-analysis lead about the large numeric literal is a compile-time constant with the correct value and was not promoted.

Not in scope and not checked. The protected launch test needs the verifier's v4-core and factory harness, which are not in this tree, so the real pool seed and swap were not executed here. Chain and pair-token addresses in the README were not verified against a network file, since none was supplied.

The review is complete and .imd-findings.json holds one low finding and eight coverage rows.

Outcome. The MAD token's permission model is clean. The contract is a 17-line wrapper over OpenZeppelin v5.0.2 ERC20 with a no-argument constructor that mints the whole supply to the deployer. There is no owner, role, modifier, initializer, proxy, fee path, exemption list or external call, and the compiled ABI exposes only approve, transfer and transferFrom as state-changing entry points. I traced all three through the inherited code, checked the approve/transferFrom and transfer/transferFrom pairs for asymmetric writes, confirmed the mint and burn branches of the internal update function are unreachable after construction, scanned the runtime bytecode for reachable DELEGATECALL, CALLCODE and SELFDESTRUCT, and ran the project's full suite with the README's fuzz seed. All 34 tests pass, including the stateful invariants. The protected launch floor's requirements on supply, decimals, privileged selectors and whole-amount flows are met.

The one finding (low). The vendored OpenZeppelin directory ships a SHA256SUMS file and instructs readers to verify with it, and the README leans on that record as the dependency's provenance. Running that check fails for two files. I fetched the pinned upstream commit and confirmed the recorded hashes are the genuine upstream bytes, but the tree copies of ERC20.sol and draft-IERC6093.sol were line-wrapped by the formatter after the record was written. The logic is unchanged and the compiled bytecode is unaffected, so this is an integrity-claim defect rather than a token defect. The fix is either to restore the two files to upstream bytes or to regenerate the checksums and soften the "unmodified" claim.

Not reported. The standard ERC-20 approve race is documented in the README and is design, not a defect. The README's claim that the launch targets Ethereum mainnet is consistent with the FWA pair token, which I confirmed has code and the symbol FWA at the documented address on mainnet. No launch.json exists yet, which is expected at this stage.

Trust assumption to carry forward. The immediate deployer receives every token and has only ordinary holder rights afterwards. Deploying through anything other than the intended factory sends the supply to that contract.

No files other than .imd-findings.json were created, and no proof tests were needed since nothing rose above low severity.

The review is complete and written to .imd-findings.json.

Outcome. The MAD token's math holds. The contract is a two-line wrapper around OpenZeppelin ERC20 v5.0.2 with one constructor mint, and every arithmetic path in my area (Math Precision, Boundary, Numerical Gap) traced correctly. I found one low-severity provenance defect and no defects in the token's arithmetic.

What I checked and confirmed:

• Supply constant. The literal is constant-folded to exactly 10^27 and that value appears in the creation bytecode. The aderyn "large numeric literal" lead is style only. Decimals return 18, matching the brief.
• transfer and transferFrom. The balance check reverts before the unchecked subtraction, the unchecked addition cannot overflow because the balance sum equals the fixed supply, and full-supply self-transfers stay exact. Allowance of max is infinite but still bounded by balance. Allowance of max minus one is finite and decrements. All of this was exercised by the existing 34 tests plus 7 scratch edge tests I ran, all passing.
• Boundary surface. The token makes no external calls, has no payable function, no receive or fallback, decodes no bytes, and its only sentinel branches are the zero-address guards. There is nothing for a boundary corner case to hit.
• Launch splits. The 10/85/5 percent flows and the 2+8 percent swarm share are exact integers of 10^27 with no truncation, and the token takes no fee, so the protected launch flows arrive whole.

The one finding (low). The vendoring note in lib/openzeppelin-contracts/VENDORED.md states the Solidity sources are unmodified upstream bytes and tells reviewers to run the checksum command. That command fails for two of the five files. I fetched both from the pinned upstream commit and diffed them. The differences are only two declarations rewrapped by a formatter, so compiled behaviour is unchanged. The defect is that the documented integrity evidence is false, which matters because the token's entire math guarantee rests on this copy being real OZ. The fix is either restoring the exact upstream bytes or regenerating the checksum file and rewording the note. The author must do it, since lib/ is off limits to reviewers.

Not reached. The deployer-side pool price and liquidity math lives outside this tree. I sanity-checked that the opening sqrtPriceX96 and single-sided liquidity for the 85 percent seed fit v4's integer bounds, but could not verify the deployer's tick choice.

The coverage record answers all three listed entry points as holds, plus rows for the constructor, two invariants, the boundary surface, the vendored-library finding, and the unreached pool math. The scratch test under test/scratch/ is mine and is not part of the submission.

The review is complete and written to .imd-findings.json. No tracked file was changed.

Result: the assigned area is clean. MADToken is an unmodified OpenZeppelin v5.0.2 ERC-20 with a single constructor mint of 10^27 units to msg.sender, no constructor arguments, and no owner, fee, burn, pause, hook or external call. Every item in the Economic Security, Invariant and Flow Gap guides either does not apply or holds when traced through the actual _update, _approve and _spendAllowance code.

What I verified:

• Supply conservation. The only mint path runs once in the constructor, _burn has no caller, and the runtime bytecode contains no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. The invariant suite passes under the pinned seed and three extra seeds.
• Launch flows arrive whole. Factory to distributor, distributor to claimant, and both PoolManager legs move exactly the requested amount, so the 10/85/5 split and the seed cannot arrive short.
• Entry points. All three state-changing functions trace to standard OZ behaviour, including the zero-address sentinels and the from-equals-zero transferFrom path, which reverts rather than minting.
• Leads. The aderyn large-literal line evaluates to exactly 10^27. Slither reported nothing.

One low finding, outside the economic area but on the audit's evidence chain: the vendored library's own sha256sum --check SHA256SUMS step fails for ERC20.sol and draft-IERC6093.sol. I fetched upstream v5.0.2 and confirmed the recorded sums are upstream's and the only differences are formatter line wraps, so the compiled token is semantically genuine. The provenance claim in VENDORED.md is nonetheless false as shipped.

Not run: the protected CustomTokenProtectedTest, which needs the network's v4-core and launch harness that are absent from this tree. The coverage record has eight rows covering all three listed entry points plus the invariants checked.

I added 24 tests in two new files and found no defects in the token, so I didn't write .imd-findings.json. The full suite passes with the verifier's fuzz seed: 58 tests in 5 suites, 0 failures, and forge build is clean. I changed only files under test/; the earlier contributor's tests and helper are untouched. Nothing is committed.

The token is plain OpenZeppelin ERC-20. Its constructor mints 10^27 units (1,000,000,000 with 18 decimals) once to the deployer, and nothing overrides the transfer or approval logic. The existing suite already covered the basics well, so the new tests go after what it left out.

test/MADToken.adversarial.t.sol (22 tests):

• Edge cases: one wei over the balance, a one-wei transfer and back, repeating the same transfer or transferFrom (neither can overdraw), and an allowance of max−1 behaving as a normal finite allowance.
• Callers the code might not expect:
  • The owner needs an allowance even to move their own tokens with transferFrom.
  • Allowances only work in the direction they were given.
  • An unlimited allowance still can't move more than the holder's balance.
  • After giving away its supply, the deployer has no special rights.
  • Contracts can hold and spend tokens exactly like ordinary wallets.
  • A call claiming to come from the zero address is refused.
• Tokens sent to the token's own address stay stuck there but still count toward the supply. This is standard behaviour the README already documents, not a defect.
• Missing functions: there is no fallback, no permit, no nonces and no rescue function.
• Bytecode scans: the deployed code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, and makes no external calls or contract creations.
• Fuzz tests (1,000 runs each):
  • Random calldata from a stranger changes no balance, allowance or supply.
  • Whether a transferFrom succeeds, and what it moves, matches a model over random owner, spender, recipient, balance, allowance and amount, including the zero address.
  • Two transfers add up to the same as one.
  • Sending tokens there and back restores both balances.
  • Approving twice changes nothing, and the latest approval wins.

test/MADToken.hostile.invariant.t.sol: a second random-sequence test (256 runs of 100 calls). It uses six actors, one of them the token's own address. It mixes valid calls with hostile ones: the zero address as receiver, spender or owner, amounts one wei over the balance or allowance, and arbitrary function calls. Every call's success or failure must match the model. The checks after each sequence:

• the supply never changes and is fully held by the actors;
• each actor's balance equals what they started with, plus what they received, minus what they sent;
• allowances match the model, and those involving the zero address stay zero;
• name, symbol and decimals never change.

A separate fixed test confirms the random-sequence tester really does produce both successful moves and refused calls. I added it because a per-run version of that check could fail by chance: some runs contain only one call.

The review is complete and written to .imd-findings.json. No tracked file was changed. The build output directory and the findings file are untracked and ignored by git.

Outcome: one low finding, merged from the four identical specialist reports, and all three entry points hold.

The kept finding. The vendoring note in VENDORED.md claims the OpenZeppelin sources are unmodified upstream bytes and tells readers to verify with the checksum file. That check fails for ERC20.sol and draft-IERC6093.sol. I reproduced it: the recorded sums are the real upstream hashes at the pinned commit, and the tree copies differ only by two formatter line-wraps, so the compiled token is semantically genuine v5.0.2. The defect is a false integrity claim, not token behaviour, so it stays at low. The fix belongs to whoever owns lib/, either restoring the upstream bytes or regenerating the sums and dropping the "unmodified" wording.

Dropped leads. The aderyn large-numeric-literal line points at a readable, correct constant equal to the manifest supply. The standard ERC-20 approve race is documented in the README and is not a defect.

Independent checks I ran:

• Traced approve, transfer and transferFrom through the vendored ERC20: zero-address reverts, exact balance and allowance accounting, no fee, burn, owner or hook path.
• Built the project and ran the full suite with the README's fuzz seed. All 58 tests passed, including the stateful and hostile invariants.
• Scanned the compiled runtime and creation code: no DELEGATECALL, CALLCODE or SELFDESTRUCT, no immutables or unlinked libraries, and both sizes are far below the protocol limits.
• Confirmed the parameterless constructor matches the manifest's empty constructorArgs and that the launch.json keys, types, address casing and supply string are consistent with the tree and the protected launch tests.

The coverage record answers the three listed entry points as holds, plus three invariant rows for supply, CREATE2 deployability and the manifest.