Implemented BlackOut (BLACKOUT): 1,000,000,000 tokens, 18 decimals, minted once to the deployer.

Includes vendored dependencies, deployment documentation, and 38 passing tests covering success, failure, fuzzing, and supply conservation.

Verified with Solidity 0.8.26:

• forge build
• forge test with the required seed
• forge fmt --check
• Clean offline build

Created launch.json matching BlackOut’s constructor, supply, and required pool and economics values.

Manifest checks and forge build passed. All 38 tests passed with the supplied fuzz seed. No other deliverable files changed.

The review is complete and the findings file is written and valid.

Result: no permission defect in the BlackOut token. The Access Control, Trust Gap and Asymmetry guides were checked in full against the source and the vendored OpenZeppelin v5.4.0 ERC20, whose checksums match upstream.

• Access control. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no owner, role, mint, burn, pause, blacklist, upgrade, receive or fallback, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. The constructor mints the exact supply to the immediate creator using msg.sender, so a factory CREATE2 deployment holds everything and cannot be front-run.
• Trust gap. No admin setters, fee recipients or price formulas exist, so there is no access-times-economics or access-times-asymmetry seam to exploit.
• Asymmetry. transfer and transferFrom share the same balance path, with transferFrom adding only the allowance spend. The factory, distributor, pool manager and ordinary holders are treated identically, so launch flows move exact amounts.

All 38 project tests pass, including the fuzz and invariant suites, and the format check passes.

One informational item outside the area is recorded in the file. The dependency README tells operators to verify vendored files with the checksum list, but seven forge-std test-library files fail that check on the committed tree. The token's runtime dependencies all pass, so deployed bytecode is unaffected.

The coverage record marks all three listed entry points as holds, plus three invariant rows for the constructor mint, the absence of privileged entry points, and the paired-surface comparison. No files other than .imd-findings.json were created or changed.

The review is complete and the findings file is written. Nothing else is needed.

Result: no math, boundary, or numerical-gap defects in the token. The findings file holds one informational note and a full coverage record.

What the token is. src/BlackOut.sol is an unmodified OpenZeppelin v5.4.0 ERC-20 whose constructor mints a compile-time constant of 1e27 units to msg.sender. There is no division, scaling, cast, fee, accumulator, external call, payable path, or sentinel branch. The three listed entry points are the inherited approve, transfer and transferFrom.

What I checked in the assigned area.

• Supply constant equals one billion times ten to the decimals, far below any overflow bound. The two unchecked blocks in the inherited update function are bounded by value at most balance at most supply.
• Edge inputs on every entry point: one wei, full balance, self-transfer of the whole supply, max uint, zero value from unfunded accounts, allowance exactly equal to the amount, max minus one versus max allowance, and over-balance transfers that stay within allowance. All behave as the ERC-20 contract specifies and revert atomically where they should.
• Launch split arithmetic on 1e27 for the ten, eighty-eight and two percent shares is exact with no remainder, so the launch flows move exactly what they say.
• The project's own 38 tests pass with the pinned fuzz seed, and a scratch suite of 15 additional edge tests passed. The scratch directory was removed afterwards.

One informational finding, outside my area. The vendored library README states the upstream files are unmodified and tells reviewers to run the checksum command, but that command fails on seven forge-std files. Diffing against upstream at the pinned commit shows only line-wrapping changes, and all OpenZeppelin production files match their hashes, so the token bytecode is unaffected. The reproduction is the checksum command from the repository root.

Coverage record. All three entry points are marked holds, with rows added for the constructor, the launch split arithmetic, the boundary enumeration, the numerical seams, and dependency integrity. No files in the tree were changed; only .imd-findings.json was written.

The review is complete. The findings file is written, both cited snippets match the tree, the scratch test is removed, and the working tree is clean apart from the gitignored findings file.

Outcome: the token holds. BlackOut is an unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint. All three entry points behave as specified, and the only defects are in the periphery evidence.

What I checked, per the Execution Trace, Periphery and First Principles guides

• approve, transfer, transferFrom: traced every check, state write and revert path through the vendored ERC20. Allowance decrement rolls back on a balance or receiver revert, max allowance stays infinite, max-minus-one is finite, from-zero and self-spend paths reject as expected. Scratch probes confirmed each of these.
• Constructor and supply: exactly 10^27 units minted once to the immediate creator, no arguments, no tx.origin, no external call, no mint or burn surface afterwards.
• Periphery: all six vendored OpenZeppelin files are byte-identical to upstream commit c64a1edb. Context uses plain msg.sender, no ERC-2771 path.
• Project tests: build clean, 38 tests pass including the invariant run, forge fmt --check passes.

Findings written to .imd-findings.json

1. Low: the integrity check the README tells operators to run fails. Seven forge-std files were reformatted after hashing. Differences are whitespace only, verified against upstream, and forge-std is test-only, so the token bytecode is unaffected. The README's claim that upstream files are unmodified is false.
2. Info: the runtime contains MCOPY, a Cancun-only opcode, from the configured EVM target. Harmless on the README's stated chain, Ethereum mainnet. Recorded because the real launch chain is chosen outside this tree and no network file is present to confirm it.

Coverage: 8 rows. The three ABI entry points plus the constructor and the no-privilege invariant all hold. The two periphery rows point at the findings. The protected floor tests are marked unreached because their v4-core and OwnerChecks imports are not in this repository, though by inspection a plain ERC-20 satisfies every assertion in them.

The review is complete and .imd-findings.json is written at the repository root. The working tree shows no tracked-file changes; the only additions are the findings file and my scratch test under test/scratch/, which is not kept.

Outcome: the token's economics hold. BlackOut is an unmodified OpenZeppelin v5.4.0 ERC-20 with one constructor mint of exactly 10^27 units to msg.sender and no other state-changing surface. I found no defect in the assigned area.

What I checked against the Economic Security, Invariant and Flow Gap guides

• Entry points. The compiled ABI exposes only approve, transfer, transferFrom and seven views. No mint, burn, owner, pause, blacklist, proxy, receive or fallback exists, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Conservation. Sum of balances equals totalSupply equals 10^27 after construction. The project's stateful invariant run and my own scratch tests confirm it across arbitrary transfer, approve and transferFrom sequences.
• Launch flows. Factory to distributor, factory to pool manager by push and by pull, factory to remainder recipient, distributor to claimants, and trader round-trips all move exactly the requested amount. The supply is divisible by 10,000, so the 10 / 88 / 2 percent split produces no dust at the token level.
• Token behaviour. No fee, rebase, hook or callback, so Uniswap v4 sync/transfer/settle receives exactly the delta. The approve overwrite race is standard ERC-20 and documented in the README, so it is recorded as a trust note rather than a finding.
• Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is a compile-time constant equal to 10^27 and is not a defect.

One low finding, outside my area. The documented integrity step sha256sum --check lib/SHA256SUMS fails on 7 forge-std files. The recorded hashes match upstream v1.9.7 exactly, but the committed files were re-flowed by a formatter. The diff is formatting only, the OpenZeppelin files the token compiles from verify correctly, and the token bytecode is unaffected. The finding cites lib/README.md:4 with the reproduction command and hashes.

Coverage record. All three listed entry points are marked holds, with five additional invariant and economics rows. The manifest row is unreached because no launch.json exists in this tree yet. The full protected Uniswap v4 seed-and-swap test needs infrastructure not in this repository and is left to the verifier.

Done. The BlackOut token is a plain OpenZeppelin v5.4 fixed-supply ERC-20 and I found no defect in it, so there is no findings file. I added two test files on top of the earlier contributors' suite, and the full run is green with the verifier's fuzz seed and without it.

Results with the pinned seed:

Suite	Tests	Result
Existing unit and fuzz suite	37	pass
Existing single-invariant suite	1	pass
New edge-case suite	25	pass
New ghost-variable invariant suite	6 invariants, 256 runs x 64 calls	pass, 0 reverts, 0 discards

New invariant suite in test/BlackOut.ghost.invariant.t.sol:

• The handler drives an open holder set. Four seeded actors plus any address the fuzzer sends tokens to, which then becomes a holder that can transfer and approve.
• Ghost variables record seeded amount, inflow and outflow per holder, and every allowance pair the handler set. Invariants check that each balance equals its ghost net flow, that holder balances sum to the supply, that allowances equal their ghosts, that supply and metadata never change, and that the zero address and the token hold nothing.
• Failure paths run inside the random sequences with the exact custom error asserted and state checked unchanged afterwards: overspending a balance, transfers to the zero address, overspending an allowance, allowance rollback when the balance is short, zero-spender approvals, and sixteen privileged signatures from random callers.
• I grounded the suite against a mutant token that skims one wei per transfer in the scratch area. The handler caught it on the first call, so the properties are not vacuous.

New edge-case suite in test/BlackOut.edge.t.sol covers what the earlier suite missed:

• Deployment paths: raw CREATE2 from creation code with the supply check in the same call as the launch probe does, duplicate-salt redeploy failing without a remint, the non-payable constructor rejecting value, and deployment from inside another contract's constructor.
• Surface: no fallback, receive or owner, a fuzzed unknown selector always reverting with empty data, and all twenty-two privileged signatures from the protected floor test tried from the deployer and a stranger with no effect.
• Allowance boundaries: one below the maximum is finite, unlimited survives zero and full spends but conjures nothing, revocation stops spending immediately, transferFrom emits only a Transfer event, and a spender cannot delegate an allowance onward.
• Fuzz: delivery to any non-zero address including the token itself, multi-hop and round-trip conservation, exact allowance spend, atomic rollback when allowance covers more than the balance, and unauthorized spenders blocked for every positive amount.

Both files are formatted and committed on the current HEAD as a single commit touching only the test directory.

The review is written to .imd-findings.json. I kept one low-severity finding and found no defects in the token itself. I changed no other files.

The finding I kept (merged from four specialists): lib/README.md:4 says the vendored files are unmodified, but its own check fails. Running sha256sum --check lib/SHA256SUMS on the clean tree reports 7 forge-std files under lib/forge-std/src as FAILED and exits non-zero. The OpenZeppelin files the token is built from, and DEPENDENCIES.json, all pass. The permissions, flow, math and economics specialists all reported this one cause, so I merged their four reports into one finding at low. It affects only the provenance claim and test-only code; the token's bytecode is unchanged. The specialists say the differences are only formatting, compared against upstream forge-std; I did not repeat that comparison.

What I dropped: the flow specialist's info note that the runtime bytecode contains the Cancun-only opcode MCOPY. The README names Ethereum mainnet as the launch chain, and Cancun is active there, so it isn't a defect. The finding only depends on which chain the launch actually runs on. I also dropped aderyn's large-number warning at src/BlackOut.sol:12: that line is 1_000_000_000 * 10 ** 18, the intended supply.

Coverage, my own pass:

• src/BlackOut.sol is a plain OpenZeppelin v5.4.0 ERC20. The library files match their recorded hashes and the token overrides nothing.
• Its only mint is in the constructor: exactly 1e27 units to msg.sender, with no later mint, burn, fee or privileged function.
• launch.json agrees with the code: an empty constructor argument list for the parameterless constructor, a total supply of 1e27 and 18 decimals.
• forge test passes all 64 tests.
• I marked approve, transfer and transferFrom as holds, plus one row for the fixed-supply rule.