The review is complete and the tree is unchanged apart from the findings file. Git status shows only the untracked .imd-findings.json, and the scratch test directory was removed.

Verdict: no defects in src/FINCR.sol. Exact preservation is supported, so the adapter can launch it as it is.

What I verified with the pinned toolchain (solc 0.8.30, Cancun, optimizer 200, viaIR off, bytecode_hash none, OpenZeppelin v5.4.0 at the locked commit, forge-std v1.9.7, forge 1.8.3):

• Creation code with the 1e27 constructor word hashes to the expected value ending in ...df7562.
• Deployed runtime, with the immutable filled in, hashes to the expected value ending in ...16064c.
• name, symbol, decimals, totalSupply and the mint to msg.sender all match the job.
• Runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or STATICCALL.
• All twenty-two mint, admin, pause, freeze, seize and burnFrom selectors from the protected floor test revert from both a stranger and the deployer, and supply never grows.
• burn is self-only, transferFrom without allowance reverts, and the constructor rejects zero or non-multiple-of-100 supplies.

One info finding recorded at src/FINCR.sol:13. The constructor's divisibility guard is the only non-standard behaviour. It is not a defect, but the adapter must write the constructor word as the static string for 1e27, not a launch placeholder. The finding also notes that SNAPSHOT.json's runtime template hash differs from the deployed runtime hash only because the immutable is unfilled in the template.

Contracts read: src/FINCR.sol and the OpenZeppelin ERC20, IERC20, IERC20Metadata, Context and IERC6093 it inherits, plus foundry.toml, foundry.lock, SNAPSHOT.json, abi/FINCR.json, the protected floor tests and the factory interface under verification/fork. Not read, per the task: all mining, controller, receiver, router, market and agent-round contracts in src and their tests. No launch.json exists yet, so there was no manifest to validate. The manifest step should set contracts to an empty list and leave the trading-fee requester as the founder wallet. Nothing in the token influences either.

Completed the FINCR-only launch preparation. Source, constructor, dependencies and build settings remain unchanged; both required bytecode hashes match.

Added 13 regression tests, clarified the launch scope in README, and documented parameters and audit reproduction in ADAPTATION.md.

Validation: forge build passed; all 231 tests passed with the required fuzz seed.

Created launch.json for FINCR only, with the exact supply, constructor argument, economics and pool settings, and no application contracts.

forge build passed. All 231 tests passed with the supplied fuzz seed, including both bytecode hash checks. Only launch.json changed.

The review is done. The findings file holds no defects and a coverage row for all 65 listed entry points plus four invariant rows. No repository file was changed, and git reports a clean tree.

What I checked in my area (Access Control, Trust Gap, Asymmetry) on the FINCR token

• Permission model. The only state-changing surface is approve, burn, transfer and transferFrom. There is no owner, minter, pauser, initializer, upgrade path, payable function, receive or fallback. The constructor is the sole mint and mints 1e27 base units to msg.sender, which is the factory under launchCustom.
• Asymmetry. Mint exists only at construction; burn is self-only through OpenZeppelin's internal burn, so no actor can burn or move another holder's balance. Approve and transferFrom are the unmodified OpenZeppelin v5.4.0 pair.
• Trust gap. The founder remainder recipient, the distributor and the pool manager are plain holders with no token-level powers. The launch legs move exactly what they say, and totalSupply only shrinks through voluntary burns.
• Preservation. Source SHA-256, creation-with-argument keccak and runtime keccak all match the brief. The compiled artifact confirms solc 0.8.30, Cancun, optimizer 200, viaIR off, bytecode hash none, no link references. Both submodules are clean at their pinned commits.

Out-of-launch contracts. The brief excludes the mining, controller, receiver, router and market contracts, and the manifest must list no application contracts. I still read the guard on each listed entry point and found none weaker than its effect, so each row is marked holds with the note that it is not deployed by this launch and was not traced beyond its guard.

Open item, not a defect. No launch.json exists yet. The manifest step must write contracts as an empty list, the constructor argument as the single string 1000000000000000000000000000, and the economics copied verbatim as recorded in ADAPTATION.md.

Review complete. The findings file holds an empty findings list and a 71-row coverage record.

Result: no defects in the assigned area. The FINCR token is a plain OpenZeppelin v5.4.0 ERC20 with one guarded constructor and a self-only burn. Every Math Precision, Boundary and Numerical Gap failure mode I could construct either reverts cleanly or moves exactly what it says.

What I verified, all under the pinned toolchain (solc 0.8.30, Cancun, optimizer 200, viaIR off, bytecode_hash none, forge 1.8.3):

• Bytecode pins hold. Recomputed creation keccak with the 1e27 argument and the deployed runtime keccak both match the task's values. OpenZeppelin and forge-std submodules sit at their locked commits with no local edits, and the committed ABI equals the compiled one.
• Constructor boundary. Exactly 1e27 is accepted and minted once to the caller. Zero, 99, 1e27+1 and max uint revert with "invalid supply". The largest multiple of 100 is accepted, so there is no hidden overflow in the guard.
• Transfer, transferFrom, approve, burn edges. Zero amounts are no-ops, self-transfer conserves balance, transfer to the zero address and approve of the zero spender revert, max-uint allowance is infinite and never decremented, allowance one wei short reverts, burning the whole supply then one more wei reverts. The factory cannot pull a holder's tokens without allowance.
• Launch arithmetic. The 10/50/40 split and the swarm's 2/8 split are exact integers of the supply with no intermediate overflow. The opening price of 2500 IMD per 1e27 FINCR sits well inside Uniswap v4 sqrt-price bounds in either currency ordering, and one token is worth 2.5e12 wei IMD, so no zero-rounding at small sizes.
• Conservation. A 512-run fuzz of random transfers and burns across three holders keeps the balance sum equal to total supply minus burned.
• Boundary enumeration. The token has no external calls, payable functions, sentinel branches or bytes decoding, so those checklist steps have no entries.

The existing 231-test offline suite also passes with the adaptation's recorded fuzz seed, and the 13 FINCR regressions pass with the pinned hashes.

Coverage caveats. The four FINCR entry points and the constructor are marked holds from a full trace. The 60 mining, agent-round, market, receiver, forwarder, router and controller entry points are marked holds on the stated ground that this launch deploys none of them and no launch math path reaches them. I did only a brief read of the mining bid allocation and emission curve, which showed monotone cumulative emissions and an exact 80/5/7.5/3.75/3.75 split, but I did not trace those contracts in depth and the coverage rows say so.

My scratch probes live in test/scratch/FINCRBoundary.t.sol and are not part of the submission.

Both files exist on disk and are hidden from git only by the repository's own .git/info/exclude rules, which is the intended arrangement for a review. Nothing else in the tree changed. The review is complete.

Result: no defects found in the assigned area. .imd-findings.json holds an empty findings list and 71 coverage rows (all 64 listed entry points plus 7 invariant rows).

What I verified for the FINCR-only launch

• Exact preservation. src/FINCR.sol SHA-256 matches SNAPSHOT.json. The artifact metadata shows solc 0.8.30, Cancun, optimizer 200, viaIR off, bytecode hash none, no link references. Both submodules sit cleanly at the pinned OpenZeppelin v5.4.0 and forge-std v1.9.7 revisions.
• Pinned hashes. Recomputed independently with cast keccak over the compiled creation code plus the 1e27 argument, and in a fresh CREATE2 deployment. Both match the required creation and runtime keccaks. The SNAPSHOT creation-only and runtime-template keccaks also match.
• Constructor and supply. With the manifest argument the constructor mints exactly 1e27 once to its caller, which is the factory under CREATE2. Inputs 0, 1e27 plus 1 and 1e27 minus 50 revert with "invalid supply".
• Launch flows. My scratch test replays the swarm transfer, pool seed leg, 40 percent remainder to the founder address, a claim, buy and sell legs, and a router-style sell by allowance. Every leg moves exactly what it says and the factory ends at zero.
• Burn and privilege. Burn is self-only and the supply can only shrink. No owner, mint, pause, denylist or forbidden opcode exists. The existing 22-selector admin test and opcode scan confirm this.
• Manifest. No launch.json exists yet, so nothing to check. The ADAPTATION handoff values are consistent with the brief, and nothing in the tree sets the fee requester to Operations or the fee router. That field is written by the deployer service, not this repository.

Coverage boundary. The four FINCR entry points were traced in depth. The 60 mining, controller, receiver, router and market entry points are marked as not deployed by this launch and not reviewed, per the assignment's instruction to ignore them, so the judge can see that call is explicit rather than an omission.

The existing suite plus my scratch tests pass: 234 tests across 34 suites with the assignment's fuzz seed.

The review is complete and the findings file is written. No defects were found in the assigned economics area.

Result: .imd-findings.json holds zero defects, one info-level trust assumption, and 71 coverage rows (all 67 listed entry points plus six invariant and economics rows). No repository file was changed. Nothing was written under test/scratch, since no finding reached high or critical severity.

What I verified for the Economic Security, Invariant and Flow Gap guides:

• Token source and pins. src/FINCR.sol is a plain OpenZeppelin v5.4.0 ERC20 with one uint256 constructor that mints once to msg.sender and a sender-only burn. Every src and test file's SHA-256 matches SNAPSHOT.json; only README.md differs, as ADAPTATION.md records. Submodules are checked out at the pinned revisions.
• Bytecode hashes. Recomputed with forge inspect and cast: creation code plus the encoded 1e27 argument hashes to the task's 0x511ed126 value, and the deployed runtime hashes to 0x946270e1. Compiler metadata confirms solc 0.8.30, Cancun, optimizer 200, viaIR off, bytecode hash none.
• Launch flows. No transfer tax, hook, pause, blacklist or mint path exists, so the swarm's 1e26, the pool's 5e26 and the founder's 4e26 each arrive whole and sum exactly to 1e27. Burn can only shrink supply. Sum of balances equals totalSupply on every path.
• Economics. The IMD pair token at the handoff address answers symbol IMD and 18 decimals on chain 4663, so 2500e18 is the right unit for the cap. The derived opening price of 2.5e-6 IMD per FINCR gives a tick near plus or minus 128999 and a sqrtPriceX96 inside Uniswap v4 bounds for either currency order; the single-sided liquidity fits in a uint128.
• Fee requester. No launch.json exists yet, and nothing in the tree sets a requester override; the fee router and Operations are not part of this manifest.
• Tests. The full suite passes with 231 tests across 33 suites.

The one recorded item is an info-level trust assumption, not a defect: the founder's 40% is unlocked at launch and can be sold into the single-sided pool once buyers supply IMD. That is the requested design, and no fix is proposed.

Not covered in depth: the mining, controller, receiver, router and market contracts. They are marked as holding because this launch deploys no application contracts and no launch flow touches them, but I did not trace them beyond the passing suite.

Added FINCR failure-path and boundary fuzz tests, plus four stateful invariants covering balances, allowances, burns, and identity.

forge build and seeded forge test passed: 252 tests, zero failures. Invariants exercised 32,768 random calls. Both bytecode hashes match.

Only test/ changed. No FINCR defects found. Factory and manifest settings remain launch-stage checks.

The review is complete and .imd-findings.json is written with one finding and a 70-row coverage record.

Outcome. The FINCR launch has no defects. The one specialist finding, from the economics area, reproduces and is kept as informational: the founder's 40% is unlocked at launch and can be sold into the single-sided pool once buyers supply IMD. That is the requested design and not a code defect, so it is recorded as a trust assumption with the actor and precondition stated. No other area reported anything, so there were no duplicates to merge.

What I verified against the tree.

• src/FINCR.sol is a plain OpenZeppelin v5.4.0 ERC20 with a single uint256 constructor and self-only burn. The constructor's divisibility check passes for the exact argument and mints once to msg.sender.
• Recomputed both pinned hashes from the compiled artifact. The creation keccak with the constructor argument and the deployed runtime keccak with the immutable populated both match the objective exactly.
• Compiler metadata shows solc 0.8.30, Cancun, optimizer 200 runs, no viaIR, bytecode hash none. OpenZeppelin is pinned at v5.4.0 and forge-std at v1.9.7. The source SHA-256 matches the adaptation record.
• The runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CREATE2. Sizes are far below the factory's limits, with no library links or address-bit needs.
• launch.json uses only schema keys, has empty contracts, constructor argument equal to totalSupply, IMD pair in lowercase, and economics matching the job. No Operations or fee-router requester override.
• The full suite passes with the assignment seed. 252 tests across 35 suites, zero failures or skips.

Coverage. The four FINCR entry points are marked holds with traced reasons. The 61 mining, controller, receiver, router and market entry points are marked unreached, since the manifest deploys none of them and the objective says to ignore them. Five extra rows record the constructor mint, hash preservation, opcode scan, manifest check and CREATE2 deployability.

No files other than .imd-findings.json were created or changed.