Implemented IMDPunks with 87 on-chain accessories, the 200-token reserve, five lifetime claims per address, and immutable SVG/JSON rendering.

Validation passed: forge build, all 31 tests, and forge fmt --check. Deployment measured approximately 4.79 million gas including a conservative transaction allowance.

Deployment parameters, assumptions, and review results are documented in README.md.

Updated launch.json with explicit deployment notes, preserving the correct IMDPunks constructor and reserve address.

Schema and constructor ABI validation passed. forge build succeeded; all 32 tests passed, including the pinned deployment check. Only launch.json changed outside permitted scratch files.

Review complete. I found no substantiated defects in the Economic Security, Invariant, or Flow Gap areas, and wrote .imd-findings.json with an empty findings list and 13 coverage rows (all six entry points plus the invariants and static-analysis leads I checked). The tree is otherwise unchanged.

What I verified

• Supply and uniqueness. claim rejects ids at or above 10,000, already-minted ids (explicit or implicit reserve owner), and a sixth claim. The counter and totalSupply are incremented before _mint, which has no receiver callback. No burn path exists, so a transferred reserve id can never fall back to its implicit owner and be re-claimed.
• Reserve accounting. The _ownerOf override is paired with _increaseBalance(reserve, 200), exactly as OpenZeppelin's own documentation requires. I traced the unmodified v5.0.2 _update: the first transfer of a reserved id reads from as the reserve, decrements its balance once, writes the explicit owner, and clears approval. The unchecked decrement cannot underflow because each reserved id is implicitly owned at most once.
• Reentrancy. safeTransferFrom finalizes state before calling onERC721Received. A reentering receiver can only spend its own five claims, cannot re-claim the received id, and cannot pull another reserve id.
• Approvals. approve and getApproved resolve through the overridden _ownerOf, so the reserve can approve untouched reserved ids, and operator approvals authorize correctly.
• Rendering. All 92 sprites are bounded to the canvas and palette, so imageOf cannot index out of bounds for any id below 10,000. I regenerated the sprite data from the committed generator and it matched byte for byte. Rendering one punk per type plus the zero- and seven-accessory extremes produced complete faces on the correct head. Worst sampled tokenURI cost was about 3.2 million gas, well under common RPC call caps.
• Economics. There is no value flow, no payable path, no privileged role, and the reserve beneficiary is a static constructor argument matching the brief. Free first-come claims and a per-address rather than per-person limit are documented design choices, not defects.

Static-analysis leads from Slither and Aderyn were all false positives for this code: intentionally zero-initialized locals, an unused return by design, encodePacked output that is never hashed, and _mint required by the brief.

Not reached: nothing within the assigned area. The pixel-level art quality beyond "complete, recognisable face" is outside this review's scope and was only spot-checked.

The findings file is in place at the repository root (it is ignored by git along with the other review artifacts, which is expected), the scratch tests are removed, and no source file was changed.

Outcome: no defects found in the assigned area. The review covered Access Control, Trust Gap and Asymmetry against src/IMDPunks.sol and its OpenZeppelin v5.0.2 ERC721 base, plus a sanity pass over the renderer. .imd-findings.json holds one informational entry and ten coverage rows, all six listed entry points marked holds or finding.

What I verified

• Reserve ownership override. The _ownerOf override feeds every OpenZeppelin path (_update, _requireOwned, _approve, getApproved). The constructor's balance pre-credit of 200 matches the 200 implicit owners, so a reserved token's first transfer decrements correctly, writes an explicit owner, clears approval, and cannot be replayed by the reserve. Self-transfer, transfer to zero, and a receiver callback that retries the same token or approves as the reserve all behave correctly.
• Claim guards. Range, reserved, already-minted and the five-claim counter are all checked before _mint, which has no callback. A reentrant receiver during safeTransferFrom cannot reach a sixth claim or claim a reserved number. The reserve address is also capped at five public claims.
• Permissions. No owner, admin, pause, upgrade, withdraw, receive or fallback exists. The reserve comes from the constructor argument, and the launch manifest passes the brief's static address rather than $owner.
• Beyond my area. All 10,000 imageOf outputs render without revert. One tokenURI call costs about 3.05M gas, well under RPC call caps. Deployment stays at about 4.44M gas. The slither and aderyn leads are false positives.

Informational entry only. The five-claim limit is per address, so throwaway contracts multiply it. The brief and README both state this is intentional, so it is recorded as a trust assumption with a reproduction, not as a defect requiring a fix.

Extended the suite with randomized ownership invariants, nested callback attacks, rollback checks, approval regressions, and metadata fuzzing.

forge build and all 40 tests pass, including 16,384 invariant calls. Only test/ changed. No confirmed defects found.

The review is complete and found no defects. The findings file holds an empty list and a 15-row coverage record, and no project file was changed.

What I covered (Execution Trace, Periphery, First Principles guides from the Pashov reference, plus the x-ray deployment phase and the entry-point inventory):

• Claim path. Range, minted and 5-claim checks all run before state writes. The counter is keyed by the caller only. Minting uses _mint, so no receiver callback exists on a claim, and re-entry from a safe transfer callback only spends the receiver's own remaining claims.
• Reserve accounting. The _ownerOf override and the one-time balance credit match OpenZeppelin's documented pairing. I traced the first transfer of a reserved id through _update, including an approval set before the transfer, an operator transfer, a receiver that bounces the token back mid-callback and then tries the stale implicit-owner path, and a rejecting receiver. Owner, balances and approvals are correct in every case, and no burn path can resurrect the implicit owner.
• Rendering and metadata. I regenerated the sprite tables from the generator and they match the committed bytes exactly. The catalogue slot ranges match PunkTraits.bounds. I swept imageOf for all 10,000 numbers with no revert and no stray bytes from the oversized buffer. All accessory names are plain letters and spaces, so the JSON needs no escaping.
• Deployment. Reserve comes from the constructor argument in launch.json, never from the factory caller. The runtime opcode scan stays clean across 64 different deployment addresses, which matters because the renderer address is an immutable embedded in the bytecode.

Static analysis leads were all false positives: the Slither uninitialized locals are zero-initialised memory arrays, the ignored return in metadata is intentional, and the abi.encodePacked output is never hashed.

Gas measurements, for the author's reference only:

Two cosmetic notes that are not defects: ear accessories sit slightly inside the wider Ape outline and float beside the narrower Alien outline, and the ERC721 base constructor stores name and symbol that the pure overrides never read.

The review is complete and written to .imd-findings.json. No source files were changed, and my scratch tests have been removed.

Outcome. The arithmetic, boundary handling and numerical couplings in IMDPunks hold. I found one low-severity art-data defect and no defects in the math itself.

What I verified in my area

• Type permutation. The rank formula uses a multiplier coprime to 10,000, its largest intermediate is far below overflow, and the four thresholds match the brief exactly. The exhaustive count test confirms the five totals.
• Accessory selection. The partial Fisher-Yates modulus never reaches zero, the slot ranges are contiguous and sum to 44 and 43, the stored id fits a byte, and all 87 accessories are reachable. The count thresholds sum to 100% and match the stated proportions.
• Packed tables. Both offset tables decode strictly monotonically, every digit is below 128, and the final offsets equal the exact lengths of the run data and the name string.
• Renderer bounds. The 40,000-byte output buffer, the two-digit writer and the skin-tone index are all comfortably within range. I rendered every one of the 10,000 numbers through the project's strict SVG parser with no revert. The largest image is 9,389 bytes at about 1.57M gas, and a full tokenURI costs about 3M gas.
• Reserve bookkeeping. The 200 fallback ids match the pre-credited balance and the constructor events. Every later write goes through OpenZeppelin's _update, and since transfers to the zero address are rejected and no burn exists, an explicit owner can never revert to the fallback.
• Supply and claims. Totals cap at exactly 10,000, the five-claim limit survives transfers, and reentrancy through the receiver hook cannot exceed it.

The one finding (low). Ear variant 2 in the generator paints palette index 0, which is the background colour, over two base-head pixels. In the deployed sprite data this punches a see-through notch through the head outline for Male, Zombie and Female punks and a hole inside the Ape face. Concrete example: imageOf(8152) has background colour at pixels (18,12) and (18,13) with face colours on both sides. The fix is in tools/generate_art.py line 162 followed by regeneration; the Solidity needs no change.

Static-analysis leads were all traced and dismissed with reasons recorded in the coverage rows. The coverage record answers all six listed entry points as holding, plus nine invariant rows.

Review complete. The findings file is written and validated, scratch tests removed, and the tree is clean apart from the gitignored .imd-findings.json.

Outcome: the IMDPunks contracts hold up. No critical, high or medium defects. I kept two specialist findings after reproducing both, merged nothing (no duplicates across areas), and found nothing new on my own pass.

Findings written to .imd-findings.json:

• Low, cosmetic: ear accessory variant 2 (ids 33 and 76) paints palette index 0, the background colour, at two pixels that the base heads fill with outline or skin. I rasterised imageOf for 8152, 9980, 8546 and 9948 and confirmed background pixels inside or on the head edge, with the hoop drawn over the cheek on Female heads. A parse of the committed sprite bytes shows these are the only two sprites with colour-0 runs. 881 punks are affected. The fix is in the generator plus a regeneration of the sprite library.
• Info, by design: the five-claim limit keys on msg.sender, so throwaway contracts multiply it. The brief and README specify per-address limits explicitly. I reproduced it (three contracts, 15 punks to one EOA with claimedBy still 0) and recorded it as a trust assumption needing no change.

What I verified myself:

• All six entry points traced through OpenZeppelin v5.0.2 and marked holds. The _ownerOf override plus the 200-unit balance pre-credit is sound, since no burn path exists to resurrect the fallback.
• Reentrancy through onERC721Received cannot reset the counter or remint; claim uses _mint with state updated first.
• Raw CREATE2 deployment re-measured at 4,441,889 gas. tokenURI costs about 2.7M to 3.0M gas.
• The full project suite passes (40 tests). No git submodules; all vendored files are plain blobs.
• Every Slither and Aderyn line checked: intentional zero-init locals, an intentionally ignored return, non-hashed encodePacked, and the brief-mandated _mint. None is a defect.