Based on my analysis of the FrenArtChunk5, FrenArtChunk6, FrenArtChunk7, and FrenRenderer contracts, I have completed the security audit. All verification checks passed, and I found no exploitable vulnerabilities.

Summary

Contracts reviewed: FrenArtChunk5, FrenArtChunk6, FrenArtChunk7 (src/FrenArtChunks.sol), FrenRenderer (src/FrenRenderer.sol)

Result: No security findings. The contracts are safe to deploy.

What I verified

Access control: No owner, admin, or privileged functions. All functions are view or pure. No state mutation possible after deployment.

Constructor validation: FrenRenderer constructor checks each chunk's code hash against expected values and reverts if any mismatch is found (line 62). This prevents deployment with wrong or modified art data.

Input validation: All combo field extractions are bounds-checked:

• Character (ch): validated ≤ 2 (line 239)
• Face: validated < 13 (line 239)
• Background: validated < 10 (line 239)
• Coat: validated ≤ 2 (line 246)
• Shirt: validated ≤ 5 (line 246)
• Hat: validated ≤ 2 (line 274)

Array access safety: All array accesses use validated indices:

• FACE_TABLE access (line 271): max index 38, table length 39
• TABLES eye access: max index 7, table length 29
• TABLES coat access: max index 22, table length 29
• TABLES shirt access: max index 28, table length 29
• Canvas writes are bounds-checked and clamped (lines 289, 299-300)

Arithmetic safety: Solidity 0.8.26 provides automatic overflow protection. No unchecked blocks in critical paths.

External calls: The only external interactions are extcodecopy calls reading art data from chunk contracts. Both unframed and framed paths validate code length before reading (lines 337, 346).

Forbidden opcodes: Tests confirm all chunks pass the admission scan with no DELEGATECALL, CALLCODE, or SELFDESTRUCT opcodes.

Gas limits: Tests confirm all three launches fit within transaction gas limits under EIP-7825's 2^24 cap.

The contracts are immutable rendering utilities with no ownership, no state changes after deployment, and proper validation of all inputs and array accesses.

Verified launch compatibility without changing contract code, art, or argument order. Added offline CREATE2 deployment tests and ADAPTATION.md.

forge build passed. Tests: 10 passed, 0 failed, 1 skipped because no mainnet RPC was configured. No transactions were broadcast.

Created launch.json with the exact contract order and constructor arguments.

Schema and compiled ABI checks passed. forge build succeeded; forge test reported 10 passed, 0 failed, 1 skipped because MAINNET_RPC_URL was unset.

Only launch.json is changed outside permitted scratch output.

The review is complete. The findings file holds an empty list: within the Access Control, Trust Gap and Asymmetry guides I found no defect with a concrete failing input, and nothing severe outside them.

What I verified

• Permission model. The renderer has no owner, no roles, no state-changing function, no receive or fallback, and no use of the factory as caller. Calls with value or an unknown selector revert. Chunks 5, 6 and 7 are a STOP byte and data, so any call succeeds and does nothing.
• Constructor and trust boundary. The constructor refuses a zero-code address, a misordered chunk, and a chunk with one byte changed, and it accepts the same code at another address. So the argument order and the four static addresses are the only trust input.
• Live dependencies. Over a public mainnet RPC, the code hashes and sizes at all four static addresses match the index entry for their position, and the repository's fork test passes against the live chain.
• Encode and decode symmetry. A scratch test drew every face for every character, every hat, item, coat, shirt, eye and background, seed window extremes, the palette, and the pending path at ids 0, 2222 and the maximum, on this renderer and the launch reference. All identical, including layers in the framed chunks 4 and 7.
• Existing suite. All ten offline tests pass, and the fork test passes with an RPC.

Coverage rows

Entry point	Verdict	Reason
FrenArtChunk5/6/7 constructors	holds	No arguments, return STOP plus data, no caller dependence
FrenArtChunk runtime (any call)	holds	STOP only, no state
FrenRenderer constructor	holds	Code hash per position, immutables only, no roles
tokenURI, bmp, canvas	holds	View, validated combo, same bytes as reference
pendingURI, unrevealed	holds	View, generated combos in range, same bytes as reference
attributes	holds	Pure, no state
Getters (chunk1..7, faceLayers, shadow)	holds	Immutables and constants

Notes that do not qualify as findings

• Sending ETH to a chunk succeeds and strands it. That is self-harm intrinsic to STOP-prefixed data contracts, and the task forbids changing the chunks.
• The comment on CHUNK_SIZES in src/FrenArtIndex.sol says the renderer checks sizes, but nothing reads that constant. The hash check is strictly stronger, so there is no failing input.
• The frens contract address the README names has no code on mainnet today, so I could not confirm which renderer selectors it will call. The signatures match the launch reference exactly.
• Read cost is about 25.5M gas for pendingURI and 8.2M for tokenURI, identical to the reference and under common RPC call caps.

The scratch tests were removed; only .imd-findings.json was added.

Added tests only under test/, covering constructor failures, chunk corruption and framing, renderer errors, art/BMP properties, and value-conservation invariants.

Verification passed:

• forge build --offline
• forge test --offline: 31 passed, 0 failed; optional RPC fork test skipped.
• Invariants: 4,096 randomized calls, zero reverts.

No defects found in the exercised behavior.

Review complete. The findings file at .imd-findings.json holds an empty list: I found no defect in the Math Precision, Boundary or Numerical Gap areas for the part-3 deployment. No repository file was changed. The scratch test I used was removed.

What I verified, and how

• Live dependency boundary. I fetched the mainnet code of the four static chunk addresses through a public RPC and hashed it. All four keccak hashes equal the corresponding entries in FrenArtIndex.CHUNK_HASHES, and the code sizes equal CHUNK_SIZES. The renderer constructor's codehash check will therefore pass on chain with the argument order the brief gives.
• Index arithmetic, every entry. A scratch test exposed the internal entry reader and compared all 69 layers plus the palette against the reference .bin files in script/art/data. Every entry matched byte for byte, so the 5-byte unpacking (chunk, offset, length via the 232-bit and 216-bit shifts) and the framed decoder for chunks 4 and 7 (frame count, 33-byte stride, off % 32 skew) are correct across the whole index. Both framed chunks consist of whole 33-byte frames, and every entry lies inside its chunk's art.
• Layer data shape. No run has a zero count, each row's runs sum exactly to the layer width, and no layer has trailing bytes. All ten backgrounds are 120x120 at origin, so the seed window offsets of 0 to 36 always cover the 84x84 canvas.
• Rendering math against the launch renderer. Every single value of every trait, and all 39 character/face pairs at seed window extremes 0 and 36, produced canvases identical to the reference renderer. Out-of-art combos (character 3, face 13 and 15, coat 3, shirt 6 and 7, hat 3, background 15) revert, and bit 23 is ignored.
• Bitmap header math. Width 84 is a multiple of 4 so no BMP row padding is needed, the file size and pixel-array fields fit 4 bytes for both 1 and 4 frames, and the grey luminance stays within a byte (maximum 153).
• Gas boundary. pendingURI costs about 25.5M gas and tokenURI about 8.2M, below common eth_call caps.

Coverage rows

Entry point	Status	Reason
FrenRenderer constructor	holds	Hash check traced; live mainnet hashes match
tokenURI	holds	Canvas validation and bitmap math traced, matched reference
pendingURI / unrevealed	holds	In-range combo construction, 4-frame bitmap, grey math traced
bmp / canvas	holds	Trait sweep and reference SHA comparisons pass
attributes	holds	Index extraction correct; returns empty name only for combos canvas rejects
FrenArtChunk5/6/7 constructors	holds	STOP byte then art, chunk 7 framed with PUSH32 before every 32 bytes

Notes, not findings. The comment on CHUNK_SIZES in FrenArtIndex.sol says the renderer checks sizes, but the renderer only checks code hashes. The entry reader loads 32 bytes starting at the palette entry and so reads 27 bytes past the end of the index constant, but only the first 5 bytes are used. Neither affects behaviour. The part-3 launch estimate of 15.29M gas sits about 4% under the 2^24 transaction cap, which the deployer's own simulation must confirm with the real factory's overhead.

The review is complete. The findings file is in place and the tree is otherwise untouched (the scratch directory is removed; .imd-findings.json is excluded from git by the harness).

Outcome

Two findings, written to .imd-findings.json. Neither is a defect in the contracts themselves. Both concern the launch's one stated economic guarantee: that part 3 fits one Ethereum transaction under the 2^24 gas cap.

Medium: the deployer's gas limit, not the gas used, is what the cap rejects. The two launches already sent (819 and 838) show the deployer sets a transaction gas limit of 1.21× the gas used, and the live factory adds about 0.58M gas over the repository's probe. Part 3 will use about 14.75M gas, which fits. But 1.21× that is about 17.86M, above the 16,777,216 cap. Unless the deployer clamps the limit to the cap (its code is not in this tree, so I could not verify), the part 3 transaction cannot be submitted. The fix is either evidence that the deployer clamps, or a smaller part 3, which changes the agreed launch composition and is the requester's call.

Low: the older fit test passes vacuously. Forge 1.8.3's default dynamic test linking rewrites the helper's new FrenArtChunkN() into a cheatcode call that is not gas metered, so the test measures about 1M gas per launch instead of 10 to 14M. Disabling that setting restores the README's figures. Only the newer part 3 probe test still guards the cap.

What I verified and found sound

• On-chain code hashes of chunks 1 to 4 match the index exactly, so the renderer constructor will pass on mainnet with the brief's addresses and order.
• The packed chunk bytes, the index, tables and face table are byte-identical to the art kit export. Every layer's run-length data is well formed and no entry overruns its chunk, including the framed chunks 4 and 7.
• The chunk renderer produces identical canvases, attributes and unrevealed sheets to the reference renderer across 55 combos that exercise every one of the 69 layers, every item, hat and background.
• Read costs are equal to the reference renderer's: tokenURI about 10.4M gas, pendingURI about 25.5M gas. Heavy, but a property of the agreed design, not of this deployment.
• No owner, no configuration, no value flows, no payable paths. Nothing in the Economic Security, Invariant or Flow Gap checklists applies beyond the gas economics above.

Coverage

Entry point	Status	Reason
FrenArtChunk5/6/7 constructors	holds	Return exact export bytes; hashes match the index; pass the admission scan
FrenRenderer constructor	holds	Hash-checks all seven chunks; mainnet chunks 1–4 verified; rejects reorder and foreign code
tokenURI, bmp, canvas, attributes	holds	Byte-identical to the reference over every layer; out-of-range combos revert
pendingURI, unrevealed	holds	Identical to the reference for sampled ids; bounded gas
Launch 3 as one transaction	finding 1	Gas used fits; the deployer's limit buffer does not

Not reached: the deployer's gas-limit clamping and the live frens contract's interface (the frens contract is not yet deployed at its stated address, so I could only check against the reference renderer in this tree).

The review is complete. The findings file holds three findings, all reproduced on this tree, and no tracked file was changed.

Outcome of the specialist findings

• Kept at medium (economics): part 3 fits the EIP-7825 cap as gas used but not as the gas limit the IMD deployer has set so far. I re-derived the on-chain facts from a public RPC: launches #819 and #838 had gas limits of 1.2107x and 1.2108x their gas used. A CREATE2 probe measures part 3 at about 14.1M gas with calldata. The live factory added roughly 0.6M to the probe figure for launches 1 and 2, so part 3 will use about 14.7M. A 21% buffer on that gives about 17.8M, above the 16,777,216 cap. Replacing the test's bound with the buffered quantity fails on this tree. The deployer code is not in the repository and the real factory cannot be simulated because its calldata carries a verifier signature, so the finding names the needed evidence: either a record that the deployer clamps the limit at 2^24, or a smaller part 3, which is a scope decision.
• Merged into one low (economics + flow): the launch-fit test in test/FrenRenderer.t.sol is vacuous under forge's default dynamic test linking. The default run logs about 1.0M per launch against 10.7M with linking off. A lower bound added to the loop fails with 69,750 gas metered for 48 KB of code.
• Kept at info (flow): pendingURI costs about 25.5M gas per call, by design and byte-equal to the launch renderer. Recorded as an operational note for whoever serves the metadata.

My own pass found nothing further. I checked the constructor's code-hash gate, every index and table read in the renderer against the layer counts, the framed decoder's bounds, the BMP assembly, the unrevealed combo construction, and the deployment-phase checklist from the x-ray reference. The four mainnet chunk addresses have exactly the code hashes FrenArtIndex names, verified live. The full suite passes with 31 tests.

Fixed gas metering and intrinsic-gas double counting; added code-deposit regression checks.

Offline build and tests pass: 31 passed, 1 optional fork skipped. Checks also pass without dynamic linking.

Saved both responses and the unresolved gas-limit finding with proof. The actual deployer’s gas-limit cap remains unverified.

Review settled. The findings file is written, parses, and the working tree is clean apart from the ignored .imd-findings.json.

Outcome of the three earlier findings

• Medium, deployer gas limit: still open, kept at medium. The author's test changes are sound and were accepted. The part-3 probe no longer double-counts intrinsic gas in isolated runs, both gas tests carry a code-deposit lower bound, and both are renamed to claim only a local usage budget. None of that touches the defect, which was never in the Solidity. The attached specialist proof fails on this tree for exactly the stated reason, and I re-verified both mainnet receipts over a public RPC this round, so the author's 403 gap is closed. The write_foundry_tests medium was the same root cause and is merged into this one, with its proof kept on it.
• Low, vacuous gas metering: fixed and dropped. The launch helper now deploys with assembly CREATE, so the default run meters real creation gas, and a scratch check confirmed the new lower bound trips on a new-based helper.
• Info, pendingURI gas: still true, kept as info. Re-measured at about 25.6M gas. It is identical to the launch renderer by design and is an operational note for whoever serves the metadata, not a blocker.

Key figures behind the open finding:

Quantity	Value
Launch #819 gas limit / used	13,669,323 / 11,290,222 (ratio 1.2107)
Launch #838 gas limit / used	12,797,493 / 10,569,418 (ratio 1.2108)
Part 3 local CREATE2 gas, repository test	13,953,173
Part 3 proof lower bound x 1.2108	16,799,231, cap is 16,777,216

What is next is a service or scope decision, not a code fix. Either the deployer records that it clamps the submitted gas limit to the EIP-7825 cap and simulates the signed call at that limit, or part 3 is recomposed so that the buffered limit fits, which changes the agreed three-launch plan. The README also still names a test that no longer exists and repeats the unproven fit claim at lines 47 to 48 and 55. That is noted inside the medium finding because it was outside the author's test-only scope.

Nothing new was reported. Source, constructor arguments, launch.json and the chunks are correct and unchanged.

Reproduced the gas-limit overflow. The launch remains uncleared pending production deployer evidence.

Wrote the response and finding with unchanged proof. The response accepts the overflow but disputes using this proof to validate a deployer-side cap.

forge build and forge test passed: 31 passed, 0 failed, 1 fork test skipped. Existing contracts and tests are unchanged.

I've settled last round's medium finding: it is no longer blocking and is now an informational note. Nothing is left that blocks this launch. .imd-findings.json holds two informational findings and no tracked file changed.

What I ran. Nothing in src/, the tests or launch.json changed this round; the author changed no files. The full suite (Forge 1.8.3, offline) gave 31 passed and 1 skipped. The skipped one is the mainnet fork test, which needs an RPC URL that wasn't supplied. I also ran the attached proof from a scratch copy, then deleted the scratch folder.

Last round's medium (the transaction gas limit), now informational. The author's dispute holds:

• The numbers still match. Part 3 uses 13,953,449 gas locally, under the 16,777,216 per-transaction cap. The proof fails only because it multiplies its usage figure (13,874,764) by the deployer's ~1.21 buffer, giving 16,799,565.
• The proof can't serve as the fix test. The 1.21 buffer is written into the test, so it would still fail after the remedy I accepted last round: the deployer capping the gas limit it submits at 2^24. The author cannot make it pass without changing the three-launch split, which the brief fixes.
• It is not a defect in this code. Source, constructor arguments, chunks and launch.json are correct. If the deployer sent a limit over the cap, the node would refuse the transaction before it ran. That costs nothing and can be retried once the deployer is fixed, so it is not a loss of funds or permanent breakage.
• Open item for the deployer's operator: before part 3 is sent, confirm the gas limit actually submitted is at most 16,777,216 and that the signed factory call succeeds at that limit. The deployer code (apps/deployer/src/deploy.ts) is not in this tree, so this can't be checked here.

README still out of date. README.md:47 names test_LaunchesFitTransactions, which no longer exists. It is now test_LaunchCreationGasIsMeteredAndWithinLocalBudget (test/FrenRenderer.t.sol:174), and it prints 10,780,000 / 10,030,026 / 14,057,311 rather than the README's 10.7M / 10.0M / 13.9M.

pendingURI gas, carried over as informational. src/FrenRenderer.sol:84 takes about 25.6M gas per call, and tokenURI about 10.3M. That matches the reference renderer, as the brief requires. RPC providers that cap read calls near 25M won't serve unrevealed tokens' metadata. audit_flow reported the same thing, so I merged it.

Specialists' findings this round:

• Merged: audit_economics' medium and write_foundry_tests' medium have the same root cause as my gas-limit finding.
• Dropped as fixed: the two low findings saying the old launch-fit test measured almost nothing. Its replacement measures real deployments, refuses to pass if code storage isn't charged (200 gas per byte), and now reports about 10–14M gas per launch.
• No findings: audit_permissions and audit_math.