Implemented Kitty with the fixed 1 billion supply, 18 decimals, 2% dead-address fee, and all requested endpoint exemptions. Dependencies are vendored; deployment parameters and responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build passed
• forge test: 27 passed, including fuzz and invariant tests
• forge fmt --check passed

The protected launch harness requires separate platform infrastructure and was not run locally.

Created launch.json with the exact supply, constructor placeholders, and verbatim economics.

Schema and constructor ABI checks passed. forge build succeeded; forge test passed all 27 tests.

Only launch.json is changed for submission.

Recorded .imd-findings.json with no substantiated defects and coverage for all three entry points.

All 27 local tests passed. Full protected launch integration remains unverified because required infrastructure is absent. No source or configuration files changed.

Wrote .imd-findings.json: no substantiated defects; all three entry points covered.

All 27 Foundry tests passed. Production registry permissions and full launch integration remain unverified because required implementations and deployment inputs are absent. Implementation files are unchanged.

Wrote .imd-findings.json: no substantiated defects; all three entry points covered.

All 27 local tests passed, including 512 fuzz cases and 8,192 invariant calls. Full protected launch integration remains unverified because required infrastructure and deployment inputs are absent.

The review is complete. The findings file validates as JSON, both cited snippets match the source lines exactly, and the only files I touched are .imd-findings.json and my scratch test under test/scratch/.

Outcome: no critical, high or medium defects. Kitty is a fixed-supply ERC-20 with no owner, no mint or burn entry point, and no forbidden opcodes. I traced all three entry points plus the supply, balance-conservation and launch-flow invariants against the Economic Security, Invariant and Flow Gap guides. The existing suite of 27 tests, including the 128x64 stateful invariant run, passes offline.

Two items are recorded in .imd-findings.json:

• Low, fee bypass through the pool manager. The exemption at src/Kitty.sol:75 applies to any transfer whose endpoint is the PoolManager, and Uniswap v4's unlock, sync, settle and take sequence is permissionless. Any holder can push tokens in and take them out to any recipient for gas alone, so the 2% burn binds only users who call plain transfer. My scratch test shows a 980e18 routed transfer arriving whole while the same direct transfer burns 19.6e18. This is a consequence of the floor's mandated exemption, so I framed it as a design decision for the requester rather than a code fix.
• Info, trust assumption on the factory registry. The lookup at src/Kitty.sol:47 fails open. When distributorOf returns nothing, points elsewhere, has a different selector, or exceeds 30k gas, claims from the distributor arrive 2% short instead of reverting. Verified with a 100e18 claim delivering 98e18 until the record is set. The protected harness's probe uses a matching uint64 mapping getter, so this is an operator verification item, not a token defect.

Coverage has eight rows: approve holds, transfer and transferFrom reference finding 1, the distributor claim flow references finding 2, and the supply, conservation, launch-flow and privileged-power invariants hold. I could not verify the real factory's getter cost or signature, since it is not in the tree. No proof files were attached because neither finding reaches high severity.

Done. The findings file is deliberately excluded from git by the harness, which is expected, and everything builds and passes.

Outcome: forge build and forge test pass: 46 tests across 5 suites in about 30 seconds, including the 3 scratch checks that are not submitted. No defect was found in the token. Three informational observations are recorded in .imd-findings.json, none needing a proof.

What I added on top of the accepted suite, without touching it:

• test/helpers/ProgrammableRegistry.sol: a factory stand-in whose answer shape can be changed while the token is live. It can return the record, revert, return a raw 32-byte word, return any byte length, or burn a chosen amount of gas.
• test/Kitty.model.invariant.t.sol: a second stateful suite driven by a shadow ledger written from the specification. Handlers cover raw unbounded transfers and transferFrom with expected-revert checks, bounded, full-balance and dust variants, approvals including unlimited, and a handler that rewires the registry mid-sequence. Invariants check fixed supply, every tracked balance against the ledger, the dead balance equals fees plus direct burns, allowances, and that the resolved distributor matches the registry state.
• test/Kitty.edge.t.sol: 15 tests for inputs the implementation did not necessarily plan for. Rounding stated algebraically rather than by recomputing the division, split and two-hop transfers, arbitrary fuzzed recipients, allowance and balance boundaries with atomic failure, the registry word accepted only when canonical, return sizes other than one word rejected, the gas budget bounded and never blocking transfers, a gas-starved claim reverting whole rather than paying the fee, and a mid-life registry outage that recovers.

Grounding the suite: two scratch mutants, one dropping the to-distributor exemption and one rounding the fee up, are caught by the handler within 176 and 76 calls. The handler's counters confirm the real token reaches the rejected, exempt and taxed paths, so no property is vacuous.

Findings recorded, all info: the exemption lookup is capped at 30,000 gas so a costlier production getter would silently tax swarm claims, transfers below 50 minor units pay no fee due to floor rounding, and the factory's registry record controls fee exemption for the token's whole life. Each has a concrete reproduction and is pinned by a test.

Wrote .imd-findings.json with no substantiated defects and coverage for all three entry points.

Foundry reported 43 passed, zero failed. Specialist reports describe required exemptions, expected rounding, or registry trust assumptions.

Full protected launch integration remains unverified because its required infrastructure is absent.