Implemented MADToken.sol: exact name/symbol, 18 decimals, and one billion tokens minted once to the deployer.

Dependencies are vendored for offline builds. Assumptions, deployment parameters, and operational responsibilities are documented.

Validation passed with Solidity 0.8.26:

• forge build
• forge test: 31 tests passed using the supplied fuzz seed, including 8,192 invariant actions
• forge fmt --check

I found no defects in MADToken within the area I was assigned (control flow, using the Execution Trace, Periphery and First Principles guides), so .imd-findings.json has an empty findings list. I ran no tests or Foundry proofs, because nothing turned up that needed one.

Why it comes back clean: src/MADToken.sol is OpenZeppelin's standard ERC20 with nothing changed. It adds one constant, INITIAL_SUPPLY = 1_000_000_000 * 10**18, and a constructor that mints that amount once to msg.sender, which is the factory. It has:

• no overrides of the transfer logic;
• no fees, burns or blacklists;
• no owner, pause or admin functions;
• no external calls or callbacks, so no reentrancy path;
• no way to mint more after deployment.

Launch flows: Because transfers move the exact amount, the factory's transfer to the distributor, the pool seed, claims and swaps through the PoolManager all arrive whole. That matches what the protected tests check: supply, decimals, the swarm share, a seed and a swap each way, and no admin powers.

Static analysis: Slither reported nothing. Aderyn's only lead, a "large numeric literal" at line 12, is just that supply constant and is correct (10^27).

Coverage rows written:

Entry point	Verdict	Reason
MADToken.approve(address,uint256)	holds	Standard approve: rejects a zero spender, sets the allowance, nothing else runs
MADToken.transfer(address,uint256)	holds	Standard transfer: the full amount arrives, no fee, burn or blocking
MADToken.transferFrom(address,address,uint256)	holds	Spends the allowance, then transfers; reverts if the allowance is too small; an unlimited approval is left as is
Invariant: total supply is fixed at 1e27	holds	The only mint is in the constructor, and nothing can mint or burn afterwards

No repository files were changed; git status is clean apart from the findings file.

I found no math defects in MADToken. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, plus one for the fixed-supply rule; all four rows are holds. I didn't change any other file.

What I reviewed. src/MADToken.sol is OpenZeppelin v5's standard ERC-20 with nothing overridden. The only extras are the fixed-supply constant INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 and a single mint to the deployer in the constructor. So the math to check is the constant and OpenZeppelin's balance and allowance arithmetic, which I read in the bundled library under lib/.

Precision and the supply figure:

• The constant comes out to exactly 1e27, the 1,000,000,000 tokens with 18 decimals that the task specifies, and it fits easily in a uint256.
• There are no fees, ratios or rounding anywhere, so every transfer delivers exactly what it says.
• The 10% swarm share is exactly 1e26, so nothing is lost to division.
• The static-analysis "large numeric literal" warning only points at that constant, which is correct. It's not a defect.

Boundaries:

• transfer / transferFrom: the balance is checked before the subtraction, so sending your whole balance works and one unit more reverts. Sending 0 also works.
• Allowances: the allowance is checked the same way before it is reduced, and an unlimited allowance (the maximum value) is never reduced.
• approve: stores the exact amount with no arithmetic, and a zero address as owner or spender is rejected.

Gaps between figures:

• OpenZeppelin skips overflow checks when crediting the recipient, which is safe only if the total supply can't grow. Here _mint is called only in the constructor, and the token has no other mint function, burn or admin role, so the total stays at 1e27 forever.
• No balance can ever exceed that total, so the credit can't overflow.

Not covered:

• The other specialty guides (access control, reentrancy and so on) are outside my area. The token has no state-changing code of its own beyond what's described above.
• No launch.json exists yet to compare the supply against.

The project's existing test suite passes (31 tests, 0 failures). I wrote no proof tests because there was no high or critical finding that needed one.

Done. I wrote launch.json for the MAD custom token launch and verified it against the accepted tree.

What the manifest contains

• Token: contract MADToken, name "Mutually Assured Destruction", symbol MAD, 18 decimals, empty constructorArgs. The accepted constructor takes no parameters and mints the INITIAL_SUPPLY constant once to msg.sender.
• totalSupply: the decimal string for one billion tokens in minor units, which matches the constant in the source exactly.
• Contracts: an empty list. The accepted tree has only the token, with no application contracts.
• Pool and economics: copied verbatim from the launch reference, with the FWA pair address, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object.
• Notes: about 1,200 characters describing the token's behavior and the launch flows. No swarm share or stand-in values are written.

Checks run

• The file parses as JSON with only the six schema keys and no extras.
• The supply string equals 10^27, the value the constructor mints.
• forge build succeeds and forge test with the verifier's fuzz seed passes all 31 tests.
• Git status shows launch.json as the only change. No config, lib, or test files were touched.

The review is complete and .imd-findings.json is written. The working tree is clean apart from that output file.

Outcome: no economic defect in the token. MADToken is the unmodified OpenZeppelin v5.4.0 ERC20 (the OZ files pass their recorded checksums) with one constructor mint of 10^27 units to msg.sender. I checked it against the Economic Security, Invariant and Flow Gap guides and against the protected launch harness, and every failure mode they list is structurally absent.

What I verified, with a scratch Foundry test mirroring the protected harness plus the project's own 31 passing tests:

• Supply and minting. Total supply equals exactly 1,000,000,000 × 10^18, minted once to the deploying factory. Mint is internal and unreachable after construction. Twenty-two common mint, admin, pause, freeze, blacklist and burnFrom selectors revert from both a stranger and the factory, and supply never changes.
• Launch flows are exact. The 10% distributor leg, 80% pool leg, 10% remainder, a claim, and a buy and sell through transfer and transferFrom each move precisely the stated amount. No fee, burn, hook, exemption list or callback exists to short any leg.
• Invariants. Sum of balances equals total supply; allowances consume exactly, max-uint allowance is not decremented; failed transfers roll back atomically. The project's stateful invariant run (128 runs × 64 depth, zero reverts) agrees.
• Privileged hand and bytecode. No owner, roles, receive or fallback. The factory cannot move a holder's balance without allowance. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT and is under the EIP-170 limit.

The aderyn "large numeric literal" lead is the constant 1_000_000_000 * 10 ** 18, which evaluates to 10^27 and is confirmed at runtime. Not a defect.

One info-level finding reported. DEPENDENCIES.md says forge-std is unmodified and tells reviewers to run sha256sum -c lib/SHA256SUMS, but that check fails for seven forge-std files. I downloaded upstream v1.9.7 and diffed: the recorded hashes match upstream, and the committed files differ only by forge fmt line re-wrapping. It is test-only tooling with no semantic change and no bearing on the token's economics, so the author only needs to restore the pristine files or regenerate the checksum list.

Coverage. All three entry points (approve, transfer, transferFrom) are recorded as holds, with three invariant rows also holding. The manifest row is unreached because no launch.json exists yet; when written it needs empty constructorArgs, decimals 18 and totalSupply of 1000000000000000000000000000.

The review is complete and the findings file is written. No tracked files were changed, and the scratch tests were removed.

Result: the MAD token holds in my area. It is the unmodified OpenZeppelin v5.4.0 ERC20 with one constructor mint of 10^27 units to the caller, no owner, no roles, no initializer, no fallback, and no forbidden opcodes. All three listed entry points were traced and marked holds.

What I checked:

• Access control: the compiled ABI exposes only approve, transfer and transferFrom as mutating functions. Twenty-four privileged selectors called from the deployer all revert. The CREATE2 fixture confirms the factory, not its caller, receives the whole supply.
• Asymmetry: both transfer paths share the same internal update. The spend path differs only by the documented skipped Approval event and the untouched max-uint allowance. Burn is unreachable.
• Trust gap: no fee, tax, parameter, or settable recipient exists, so no actor class is treated differently and launch flows move exact amounts.
• Verification: the project's 31 tests, the format check, my reachable-opcode scan and a selector probe all pass. OpenZeppelin file hashes verify.

One finding, low severity: the documented integrity check sha256sum -c lib/SHA256SUMS fails on seven forge-std files. The recorded hashes match upstream v1.9.7, so the tree drifted, not the hash list. With whitespace stripped the files are byte-identical to upstream, so this is formatting only and affects test code alone. It is reported because the dependency notes claim an unmodified tree and the verification step they prescribe fails as shipped.

Not reported: the standard ERC-20 approve-replacement race, which is inherent to the interface and already documented in the README. The coverage record carries ten rows, three for the entry points and seven for invariants.

I added two test files and found no defects in the token. The full suite passes with the verifier's fuzz seed: 47 tests in 5 suites. forge build is clean.

The token is OpenZeppelin v5.4.0's standard ERC-20, unchanged, with one constructor mint of 10^27 (1,000,000,000 × 10^18) to the deployer. It has no owner, mint, burn, pause or other admin functions, and transfers take no fee. So there was nothing to put in .imd-findings.json and I didn't create it. The three test files already there are untouched.

test/MADTokenAdversarialInvariant.t.sol: an invariant suite set to 256 runs of 100 calls (25,600 calls in total). Five holders start with uneven balances, and a sixth address that nobody ever funds or approves tries to spend.

• Valid calls: transfer, sending a whole balance, approve (including unlimited), and transferFrom.

• Invalid calls, mixed in at random:

  • sending more than the balance
  • sending to the zero address
  • approving the zero address
  • transferFrom above the allowance
  • transferFrom above the balance while within the allowance
  • transferFrom to the zero address
  • pulling tokens with no approval

  Each invalid call must revert with its exact error and leave every balance, allowance and the supply unchanged.

• Invariants checked after every call:

  • the supply stays fixed and all of it stays with the five holders
  • the zero address, the token and the unapproved address hold nothing
  • balances and allowances match a separate ledger the test keeps itself
  • no invalid call ever succeeded or changed state

test/MADTokenProperties.t.sol: fuzz tests with fixed edge cases alongside, mostly at 1,000 runs each.

• Fuzzed properties:
  • sending tokens and back restores the original state
  • two transfers equal one transfer of their sum
  • sending to yourself changes nothing
  • repeating or replacing an approval behaves as expected
  • an unlimited allowance never goes down
  • an empty account can't send any positive amount
  • a stranger can't pull from the deployer
  • when a transfer exceeds both the allowance and the balance, the allowance error is the one reported
• Fixed edge cases:
  • an allowance one below the maximum does go down
  • one wei moves exactly
  • the zero address can't send, approve or be spent from
• Launch path: deploying and distributing in one call, as a launch factory does in one transaction, and the whole launch reverting if it tries to hand out more than the supply.

One fuzz test failed on the first run. The cause was my test, not the token: it sends the same amount twice, so the inputs have to fit in half the supply. I fixed the input range and it now passes.

I didn't commit anything; both new files are in the working tree, untracked.

Review complete. The findings file is written and no repository files were changed.

Outcome: MADToken is a plain fixed-supply OpenZeppelin ERC-20 and I found no code defect. One specialist finding survives, merged from two reports, at low severity.

What I verified

• The token source is 17 lines: a zero-argument constructor minting exactly 10^27 units to the caller, with no owner, mint, burn, pause, upgrade, fallback or receive in the compiled ABI.
• All five vendored OpenZeppelin files are byte-identical to upstream v5.4.0, fetched and compared directly.
• All 47 project tests pass with the documented fuzz seed. My own scratch test over approve, transfer and transferFrom passed and was deleted afterwards.
• Creation and runtime bytecode are far under the size limits, and no delegatecall, callcode or selfdestruct appears in the token or its dependencies.
• The manifest matches the code: zero constructor arguments, supply equal to the mint, decimals 18, lowercase addresses, schema keys only.

Kept finding (low): The documented provenance check in DEPENDENCIES.md fails. Seven forge-std files differ from the recorded v1.9.7 hashes. I confirmed the recorded hashes are the genuine upstream ones and the tree files differ only by whitespace, so it is a formatter pass over test-only code with no effect on the token. The audit_permissions and audit_economics reports share this root cause and are merged into one entry. The audit_economics claim that the hash file is gitignored did not reproduce and was dropped.

Coverage: all three entry points answered as holds, plus rows for the constructor, manifest, deployability and dependency provenance. No proof test was attached since nothing reaches high severity.