The deliverable is complete and committed as a Foundry project at the repository root.

What was built

• src/IMDBlackoutToken.sol is a fixed-supply ERC-20 on OpenZeppelin v5.1.0. It returns the name IMDBlackout and symbol IMDBLACKOUT with 18 decimals. The constructor takes no arguments, calls no contract, and mints the entire supply of one billion tokens once to the deployer. Holders can burn their own tokens, and nothing else exists: no mint, owner, pause, blacklist, freeze, seize, proxy or upgrade path.
• script/Deploy.s.sol exposes a deploy() function with no configuration and a broadcast wrapper, as the reference asks.
• test/IMDBlackoutToken.t.sol holds 29 tests that deploy through a CREATE2 factory stub the way the launch does. They cover metadata, the one-time mint, transfer and approval success and revert paths, burning, every admin selector the protected floor probes from a stranger, the factory and the requester, the bytecode opcode scan, EIP-170 size, the script function, and a simulation of the launch flows checking each leg arrives whole.
• README.md documents behaviour, assumptions, deployment parameters, after-launch steps, and operational responsibilities.
• forge-std v1.9.7 and the ERC20 subset of OpenZeppelin v5.1.0 are vendored under lib/ as plain files with no submodules. foundry.toml pins solc 0.8.26 and sets bytecode_hash = "none".

Checks run

forge build --offline   Compiler run successful
forge test --offline    29 passed, 0 failed
forge fmt --check       clean

One assumption to flag. The brief's "Transfer rules" field contained only the requester's wallet address and no rule. I implemented unrestricted ERC-20 transfers and recorded that address as an informational REQUESTER constant with no power. This satisfies the protected floor, which refuses any privileged power over balances. If the requester intended a specific rule such as a tax, cap or cooldown, that must be stated and the token re-issued before launch, since nothing is changeable afterwards. The README states this explicitly.

Done. I wrote launch.json as the only new file, and the build and all 29 tests pass.

What the manifest says

• Kind is custom_token. The token contract is IMDBlackoutToken, with name IMDBlackout, symbol IMDBLACKOUT and 18 decimals.
• Constructor arguments are the empty list, matching the accepted constructor, which takes nothing and mints the whole supply to msg.sender.
• totalSupply is the constructor's mint in minor units, 1,000,000,000 tokens times 10^18.
• contracts is empty, since the accepted tree has no application contracts and no initialization calls.
• pool and economics are copied exactly as the launch reference gives them: IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object verbatim.
• notes describe the fixed supply, self-only burn, plain ERC-20 transfers with no privileged powers, and the brief's transfer rules field naming only the requester's wallet.

Checks run

• forge build compiled cleanly and forge test passed every test in the existing suite.
• A local script confirmed the manifest has only the schema's top-level keys, the economics object is byte-identical to the job's, totalSupply equals 10^27, and the contract name fits 32 characters.
• git status shows launch.json as the only change.

Review complete. The findings record is written to .imd-findings.json and the working tree is otherwise untouched.

Outcome: no defects found. The token is a plain OpenZeppelin v5.1.0 ERC-20 with a self-only burn, and every path I traced in my area behaves as intended.

What I covered, against the Execution Trace, Periphery and First Principles guides:

• Execution trace. Traced approve, transfer, transferFrom and burn from entry to final storage through the vendored ERC20. Zero sender or receiver reverts, balance and allowance checks precede every write, infinite allowance is not decremented, self-transfer and whole-supply moves are exact. No stale reads, partial updates or sentinel paths exist.
• Periphery. All five vendored OpenZeppelin files are sha256-identical to upstream v5.1.0. The deploy script only runs the constructor and holds no configuration. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT and fits EIP-170.
• First principles. The constructor mints exactly one billion tokens with 18 decimals to the deployer once, takes no arguments and makes no external calls. The ABI exposes thirteen methods, none privileged, so no mint, pause, freeze or seize path exists. Sum of balances equals total supply before and after burns.
• Launch floor. No fee or exemption list, so the swarm share, pool seed, remainder and swaps all move exactly what they say.

I ran the project's 29 tests plus a scratch probe of boundary cases, all passing, and removed the scratch file afterwards.

The one entry in the record is informational, not a defect: the brief's "Transfer rules" field holds only the requester wallet, and the token applies no rule to it. The requester is an ordinary holder, which the README documents as the intended reading. Since the contract has no setters or upgrade path, a rule intended for that address would need the token re-issued before launch. The coverage record marks all four listed entry points as holding, with four extra rows for the constructor and supply invariant, the vendored library, the deploy script and the bytecode checks.

The review is complete. No defects were found in the Math Precision, Boundary or Numerical Gap areas, and .imd-findings.json holds an empty findings list with nine coverage rows.

What was reviewed

• src/IMDBlackoutToken.sol is a plain OpenZeppelin v5.1.0 ERC20 with a self-only burn. It has no fee, tax, scaling, division, cast, external call, payable path or sentinel branch, so most failure modes in the three guides have nothing to attach to.
• The vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tags by SHA-256, so the unchecked subtractions in _update and _spendAllowance are the audited originals, each guarded by a prior balance or allowance check.
• The supply constant folds to exactly 1e27, well under the uint128 and int128 limits a Uniswap v4 pool uses, and divisible by 10 to the decimals. This closes the aderyn large-literal lead as not a defect.

How it was checked

• The project's own 29 tests pass.
• A scratch suite of 23 boundary tests under test/scratch/ passed, covering 1 wei, whole-supply, supply plus one, max uint, self-transfer, burn to zero supply, exact allowance consumption, the max and max-minus-one allowance sentinels, zero-value transferFrom without allowance, and the zero-address paths on every entry point.
• A Foundry stateful invariant run over random transfer, transferFrom and burn sequences across six actors held both that the sum of balances equals the total supply and that the supply only ever shrinks by what was burned.

Coverage

All four listed entry points are marked holds, with five extra rows for the invariants checked. Nothing in the assigned area was left unreached. Tools that ran: forge build, forge test with fuzzing and invariant mode. Slither was not run here beyond the verifier's supplied output.

The review is complete and the findings file is written. Working tree is clean apart from .imd-findings.json and my gitignored scratch test.

Outcome: no defects of severity found in the economics area. The token is an unmodified OpenZeppelin v5.1.0 ERC-20 with a self-only burn, no constructor arguments, no owner, and no transfer rules.

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

• Dependency integrity. All five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag. This was the one place a plain token could hide a defect, and it is clean.
• Conservation invariants. A scratch Foundry invariant run of 128,000 handler calls over all four entry points held sum of balances equals total supply equals minted minus burned, with zero reverts.
• Launch flows. No path deducts anything, so the swarm share, claims, seed and PoolManager swap legs move exactly what they say. The constructor takes no arguments and mints exactly the manifest supply to msg.sender.
• Privileged powers. None exist. The requester address is a constant with no effect on any branch.
• Entry points. All four listed entry points received a holds row with reasons, plus four invariant rows.

Two informational notes are recorded, each with a concrete reproduction, so the judge can decide whether they matter:

1. The brief's "Transfer rules" field was only the requester's address, and the implementation treats that as "no rule". The README documents this reading. If a rule involving that address was intended, the token must be re-issued since it is immutable.
2. The public constant named TOTAL_SUPPLY diverges from the live totalSupply() after any burn. Harmless to funds, but an integrator reading the constant as circulating supply would over-report it.

No critical or high findings, so no proof test files were attached. No launch.json exists in the tree yet, so there was no manifest to review.

The review is complete. The findings file is written, the scratch test is removed, and the working tree is clean apart from the ignored findings file.

Result: no defects found in the Access Control, Trust Gap or Asymmetry area. .imd-findings.json holds an empty findings list and ten coverage rows, one for each of the four entry points plus six invariants I checked.

What I verified, in src/IMDBlackoutToken.sol:

• Permission model is empty by design. The compiled ABI has exactly four state-changing functions, all stock OpenZeppelin v5.1.0 ERC20 scoped to msg.sender or to an explicit allowance. There is no owner, role, initializer, setter, pause, mint, upgrade, receive or fallback. The requester address is a constant that no code path reads.
• No pull path onto a holder. The deployer and the requester both revert with ERC20InsufficientAllowance when pulling 1 wei from a holder without approval. A third party approving itself gains nothing on another holder's balance. Allowance gives no burn power because burn only touches the caller.
• Mint/burn asymmetry is the intended one. Mint happens once in the constructor to the factory. Only self-burn exists, so supply can shrink but never grow. Conservation of sum(balances) == totalSupply held under fuzzing with transfers and burns mixed.
• No external surface. The 2060-byte runtime contains zero CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2, SELFDESTRUCT or ORIGIN opcodes.
• Vendored dependencies are genuine. Every OpenZeppelin file is byte-identical to upstream v5.1.0, and lib/forge-std/src is byte-identical to v1.9.7, so neither the token nor the verifier's floor tests are built on altered library code. All library files are plain mode-644 files, no submodule.
• Launch floor compatibility. The constructor takes no arguments, mints the manifest supply to the factory, and every launch leg moves exact amounts, matching what the protected test demands.

Two items worth the requester's attention, neither reproducible as a defect:

• The brief's "Transfer rules" field contained only the requester's address. The build treated it as "no restrictions" and documented that assumption in the README. If a tax, cap or cooldown was intended, it must be stated before launch since nothing is changeable afterwards.
• burn(uint256) was not requested in the brief. It is self-only and harmless to other holders, but it is an added feature.

Tools run: forge build, forge test (29 existing tests plus 7 scratch traces, all passing), forge fmt --check, an opcode scan of the deployed bytecode, and byte-level diffs against upstream OpenZeppelin and forge-std. Slither and aderyn output had no lead above the line-39 numeric literal, which I confirmed evaluates to exactly 1e27.

The findings file is in place and valid JSON. It is excluded from git by the harness's own .git/info/exclude, which is expected since the harness collects it from the repository root rather than from the commit.

Recap

Outcome: two new test files under test/, all 62 tests across 4 suites pass, forge build is warning-free, and forge fmt --check is clean. No defect was found in the token. One info-level note was recorded in .imd-findings.json.

What was already there. The accepted implementation is a plain fixed-supply OpenZeppelin ERC-20 with a self-only burn, and the existing test/IMDBlackoutToken.t.sol already covered metadata, revert paths, privileged selectors, bytecode opcodes and the launch flows. It had no invariant tests, which the acceptance criteria require.

What I added.

• test/IMDBlackoutToken.invariant.t.sol. A handler with seven actors, including the deployer as factory and the requester wallet, drives random sequences of transfer, approve, transferFrom and burn with bounded inputs, plus seven failure-path functions that attempt over-balance transfers, over-allowance and unapproved transferFrom, transfers to zero, over-burns, unknown selectors and ether, asserting each is refused and moves nothing. Ten invariants check conservation against ghost accounting: supply equals minted minus burned, sum of balances equals supply, every balance and allowance matches its ghost, nothing leaks to bystanders or the zero address, metadata is fixed, and only the known paths move tokens. It runs with fail-on-revert on, 256 runs at depth 64. A second contract fuzzes the token's raw ABI directly from random senders with reverts allowed, checking the supply never grows.
• test/IMDBlackoutToken.properties.t.sol. Thirty-one stateless tests at 1000 fuzz runs: exact-balance and balance-plus-one transfers, self-transfers, additivity, a conservation chain through four holders, approve overwrite semantics, a transferFrom oracle over all three outcomes, allowance consumption to the last wei, self-spending still needing an allowance, burn edges from zero to the whole supply, burn by an approved spender touching only its own tokens, random unknown selectors, truncated calldata, ether refusal, and view purity. Zero, one wei, full supply, max uint and the zero-address deployer are pinned as unit tests.

Verification of the suite itself. I ran the invariant file against a deliberately broken mutant token in test/scratch that skimmed one wei per transfer and exposed a mint. The handler postconditions caught the skim and the open-surface invariant caught the mint, so the properties are not vacuous. The scratch directory has been removed.

The info finding. The brief's "Transfer rules" field contained only the requester's wallet address and no rule. The implementation treats it as "no restriction" and documents that. The tests confirm the address is an ordinary holder with no power. If the requester intended an actual rule for that wallet, the token would need re-issuing before launch, since nothing is changeable after deployment. No proof is attached because no input fails.

The review is complete and the findings file is written. No blocking defects.

Outcome. The IMDBlackout token is a plain fixed-supply OpenZeppelin v5.1.0 ERC-20 with a self-only burn. I found no defect that opens a revision. The findings file holds two informational notes, both reproduced, and a coverage record for all four entry points plus four invariants.

What I checked

• Built with solc 0.8.26 and ran the existing suite: 62 tests passed, including the 256-run invariant campaign.
• Diffed every vendored OpenZeppelin file against upstream v5.1.0: all byte-identical, no submodules.
• Wrote and ran a scratch test confirming the mint goes to the CREATE2 deployer, runtime is 2,060 bytes with no DELEGATECALL, CALLCODE or SELFDESTRUCT, burn only touches the caller, and no burnFrom selector exists.
• Checked launch.json against the schema rules: schema keys only, lowercase addresses, empty constructorArgs matching the no-argument constructor, supply equal to the mint, notes under the limit.

Specialist findings settled

• Three specialists reported the same item, that the brief's "Transfer rules" field names only an address and the token applies no rule to it. Merged into one info finding with a reproduction showing the requester wallet behaves like any holder. Kept at info because the token has no setters, so if a rule was intended the token must be re-issued before launch.
• The TOTAL_SUPPLY constant diverging from totalSupply after a burn reproduces exactly as described. Kept at info as a naming ambiguity.
• The aderyn large-numeric-literal lead is the underscored 1_000_000_000 constant and is not a defect, so it was dropped.

The scratch test directory was removed, so the only change in the tree is .imd-findings.json.