The review is complete. The findings file is in place at the repository root, and nothing else in the tree changed.

Outcome for launch 1: FrenArtChunk1 and FrenArtChunk2 have no defects of their own. Both pass every check the protected floor applies, and I verified each one by deploying the compiled contracts:

• Runtime starts with a STOP byte, so calling either contract does nothing.
• Runtime sizes are 24,001 and 24,139 bytes, under the EIP-170 limit; init code is under the floor's 49,152-byte limit.
• The deployed code hashes equal the first two entries of the renderer's hash table, so launch 3 will accept them.
• The floor's forbidden-opcode scan finds zero hits in both.
• No constructor arguments, nonpayable, no owner, no storage, no custody, no proxy or initializer.

Findings written to .imd-findings.json:

1. High, with proof. FrenArtChunk4 and FrenArtChunk7 fail the floor's forbidden-opcode scan. The art's coat-shade slot indices are 0xf4 to 0xf8 and the palette contains 0xff, and the scanner cannot tell data from code. Chunk 4 has 234 flagged bytes and chunk 7 has 14. Launches 2 and 3 would be rejected automatically, and since the renderer only accepts these exact code hashes, no working renderer can be deployed without re-encoding the art and regenerating the index. Launch 1 is only worth its gas if the regenerated art keeps chunks 1 and 2 byte-identical. The proof test under test/scratch/FloorScan.t.sol fails on the current code with the message below.

[FAIL: FrenArtChunk4: forbidden application opcode: 234 != 0]

2. Low. The project's gas-fit test does not measure contract creation in this Foundry build. It logs about 1.0M gas for launch 1 while the code deposit alone is 9.6M. My by-hand estimate agrees with the README's 10.7M and sits under the 2^24 cap, so the launch is not blocked, but the test cannot show that.

3. Info. The index's chunk-size table is documented as checked by the renderer but has no reader.

4. Info. Coverage statement: all three source files, the test, the generator script, the README and the floor test were read in full. The reference renderer body was read only in part. The live frens contract and the policy row were not reachable from the repository.

The project's own six tests pass, including the byte-for-byte match against the reference renderer.

Implemented the adaptation, preserving FrenArtChunk1 and FrenArtChunk2 exactly. Fixed the reproduced audit findings and documented every change in ADAPTATION.md.

Validation passed: forge build, all 13 Solidity tests, and four Python tests. No deployment was broadcast.

The review is complete. The findings file is in place, the scratch tests are removed, and the working tree is clean apart from the harness-ignored findings file.

Outcome: no defect in the assigned area. The math, boundary and numerical-gap checks on launch 1 all hold. Two informational notes are recorded in .imd-findings.json, neither of which asks for a code change.

What I verified for chunks 1 and 2

• Index arithmetic. Decoded all 70 index entries on the deployed chunks. Chunk 1 holds 14 entries covering exactly 24,000 decoded bytes, chunk 2 holds 11 covering exactly 24,138, with no gaps, overlaps or out-of-range offsets. The reader's 1 + off + len bound and extcodecopy from offset 1 + off are correct for the STOP-prefixed layout.
• Layer data. Every one of the 69 layers, including the 25 faces in chunks 1 and 2, consumes exactly its indexed length, has no zero-length run, sums each row to its width, and stays inside the 120x120 space. A zero run would have been an infinite loop in _draw, so this was the key data boundary to rule out.
• Window math. All ten backgrounds are 120x120 at the origin, so the 0..36 seed shift always covers the 84x84 canvas. Rendering every background at both shift extremes left no unpainted pixel.
• Sizes and gas. Runtimes of 24,001 and 24,139 bytes sit under EIP-170, initcodes under EIP-3860, and the opcode scan passes. Launch 1 costs about 10.7M gas against the 2^24 cap, dominated by code deposit. The constructor is a nonpayable PUSH31/MSTORE sequence with negligible execution cost.
• Slither leads. All ten target the renderer, not launch 1. The uninitialized locals are intentional zero defaults, and the missing zero-checks are covered by the codehash comparison, which fails for the zero address.

Informational notes recorded

• The chunk runtime is a bare STOP, so ETH sent to it succeeds and is permanently stuck. This is by design and only harms the sender.
• Initcode size depends on the compiler. Under this worker's solc 0.8.37 the initcodes are 27,486 and 28,867 bytes rather than the sizes in ADAPTATION.md. Runtime hashes are unaffected, but the CREATE2 addresses launch 3 needs must be read from the actual deployment, not predicted locally.

Entry point coverage. FrenArtChunk1 constructor: holds. FrenArtChunk2 constructor: holds. Chunk runtime fallback: holds, with the ETH note above. Renderer reads of chunks 1 and 2 via _entry and _draw: holds. Renderer constructor, tokenURI, pendingURI, canvas, attributes: outside the launch-1 area, traced for math only and holding. The PUSH-encoded read path for chunks 4 and 7 belongs to launch 2 and 3 and was checked for arithmetic consistency but not exhaustively.

The review is complete. The findings file is in place, the scratch test is removed, and the working tree holds nothing new beyond the harness-excluded findings file.

Outcome: no defects in the launch-1 contracts. FrenArtChunk1 and FrenArtChunk2 behave exactly as the repository states, and .imd-findings.json records two informational notes only, neither of which blocks deployment.

What I verified for the assigned area (Execution Trace, Periphery, First Principles):

• Constructors are nonpayable, take no arguments, read no storage, and return the hex literal as runtime. The existing suite passes under solc 0.8.37, pinning runtime sizes 24,001 and 24,139 and the two code hashes the renderer and generator both require.
• Launch-floor opcode scan reproduced independently with the protected test's exact algorithm against freshly deployed chunks 1 and 2. Both pass. Initcode sizes are under the 49,152 limit.
• Index integrity for the entries pointing into these chunks: 14 entries tile chunk 1 contiguously to decoded byte 24,000 and 11 entries tile chunk 2 to 24,138, each exactly one byte short of the runtime length, so the renderer's bounds check at src/FrenRenderer.sol:315 and the STOP offset line up with no gap or overlap.
• Gas from the real initcode bytes: calldata plus code deposit alone comes to about 10.6M, consistent with the repo's 11.6M estimate and under the 2^24 transaction cap.

Informational findings recorded:

1. The STOP runtime accepts value, so ETH sent to a chunk address is stranded with no recovery path. Reproduced with a 1 ether call that succeeds and leaves the balance in place. This is the intended data-contract design, flagged as a trust assumption.
2. Creation code varies with the auto-detected solc version (27,586/29,281 bytes under 0.8.26 versus 27,486/28,867 under 0.8.37) while runtime hashes are identical. The CREATE2 address therefore depends on the toolchain, so launch 3's static chunk addresses must be read from the confirmed launch-1 deployment rather than precomputed, or the renderer constructor reverts with BadArt.

Coverage rows:

• FrenArtChunk1 constructor: holds.
• FrenArtChunk2 constructor: holds.
• Chunk runtime fallback (any call): finding 1 (value accepted and stranded, otherwise inert).
• FrenRenderer constructor: holds for my area, with finding 2 as a deployment-process note.
• FrenRenderer tokenURI, pendingURI, silhouette, attributes, bmp, canvas: holds for the chunk-1/2 read path; full rendering logic is outside this area and rests on the passing reference-equivalence tests. The slither leads on FrenRenderer are default-initialised locals and non-defects.

No high or critical findings, so no proof tests were attached.

Created launch.json with FrenArtChunk1, then FrenArtChunk2, both with empty constructor arguments.

Schema and compiled ABI checks passed. forge build succeeded; all 11 tests passed. Only launch.json changed.

Review complete. The findings file holds one informational entry and no defects of medium severity or above.

Outcome. Part 1 of the launch, FrenArtChunk1 then FrenArtChunk2 with no arguments, holds under the Economic Security, Invariant and Flow Gap guides. The .imd-findings.json file at the repository root contains one info finding and nothing blocking.

What I verified independently rather than trusting the existing tests:

• Runtime identity. I re-extracted both literals from the source and hashed them with cast keccak. Both match the hashes pinned in the index library and in the launch test, and both begin with a STOP byte.
• Index invariants. Every layer entry for chunk 0 ends exactly at byte 24000 and for chunk 1 at byte 24138, matching the data behind the STOP byte with no gap or overrun. The informational size table equals the real runtime lengths.
• Original bytes. The retention test compares all 69 decoded layers and the palette against the exported art files, and it passes. I could not verify that the export itself is the artist's original, which is outside the tree.
• Opcode floor. The test's scan is byte for byte the protected harness's scan, and both chunks pass it. All vendored library files are regular blobs, so the offline verifier will find them.
• Gas economics. An isolated scratch measurement of a factory CREATE2 for each chunk came to about 5.3M gas each including code deposit. With roughly 867k gas of calldata that is about 11.6M per launch transaction, in line with the repo's estimate and under the 16,777,216 cap. The policy's wei ceiling is a service setting I cannot see, so that remains an open item for the deployer simulation.
• Flow gaps across launches. The renderer's constructor fails closed on any address whose code hash differs, and chunk code cannot change after deployment because the floor forbids SELFDESTRUCT. The static chunk addresses for launch 3 must come from the confirmed deployment handoff, not from a prediction, since initcode and therefore the CREATE2 address depends on the solc version the verifier builds with.

The one finding (info). The STOP runtime accepts value: a call sending 1 ether to a deployed chunk succeeds and the balance is stranded forever. This is normal for SSTORE2-style data pointers and no protocol funds pass through these contracts, so I recommend only a documentation note. Changing the chunks is not an option because their hashes are pinned.

Coverage rows. FrenArtChunk1 constructor: holds. FrenArtChunk2 constructor: holds. Chunk runtime fallback behaviour: finding 1 (info). FrenRenderer constructor and read path: holds for the properties that touch launch 1, not fully reviewed otherwise since it belongs to launch 3. The Slither leads all point at FrenRenderer and are outside this launch, so I left them to the launch-3 review.

I removed the scratch test after measuring, so the tree is unchanged apart from the findings file.

Review complete. The findings file holds two informational notes and no defects in the assigned area.

Result for the assigned area (Access Control, Trust Gap, Asymmetry) on FrenArtChunk1 and FrenArtChunk2: no permission bypass, trust gap or asymmetry found. These contracts have no roles, no storage, no initializer and no external calls. Each constructor is nonpayable and returns the art literal as runtime, which begins with STOP. I verified on this tree: both runtimes deploy through a CREATE2 factory probe with the pinned hashes (0xf86a2dec…, 0x8579d215…) and sizes 24,001 / 24,139 bytes, contain zero raw 0xF2/0xF4/0xFF/0xEF bytes, pass the exact protected floor scan when run with the real creation bytes, and every FrenArtIndex entry that points at chunk 0 or 1 stays inside the deployed code. The renderer's hash check rejects address(0), a funded code-less address and any swapped order, so the launch-3 static addresses cannot substitute other art. The vendored libs contain no git submodule. All 11 existing tests pass.

Findings written to .imd-findings.json (both info, neither blocks the launch):

• Chunk runtimes accept and permanently trap ETH sent to them. A value call succeeds because STOP keeps msg.value. Self-harm only, and unfixable without changing the pinned code hashes, so documentation is the only action.
• ADAPTATION.md's creation-code sizes hold only under solc 0.8.26. Auto-detect picks 0.8.30 here and yields 27,486 / 28,867 bytes. Runtime bytes and hashes are identical under both compilers, so this affects only cross-checks of signed creation bytes or predicted addresses.

Coverage rows:

Entry point	Status	Reason
FrenArtChunk1 constructor	holds	nonpayable, no args, returns literal; rejects value, deploys pinned hash
FrenArtChunk1 runtime fallback	finding (info 1)	STOP, no state, no return; keeps value
FrenArtChunk2 constructor	holds	same as chunk 1
FrenArtChunk2 runtime fallback	finding (info 1)	same as chunk 1
FrenRenderer constructor (launch 3)	holds	codehash check per chunk, immutables only, no owner
FrenRenderer tokenURI / pendingURI / silhouette / bmp / canvas / attributes	holds	all view or pure, no state, index reads bounded by combo checks; tests match the reference renderer byte for byte

Slither leads on FrenRenderer (uninitialized locals, missing zero checks) are intentional zero-initialised locals and addresses covered by the codehash check, so none became findings. Out of area and not reached: economics and gas-ceiling behaviour of the real factory transaction, which the deployment service simulates. My scratch tests were removed and no repository file was changed.

Added deployment failure/retry tests, CREATE2 collision checks, corrupted-art rejection tests, and ETH conservation/art immutability invariants.

Offline forge build and forge test pass: 20 tests, including 16,384 randomized invariant calls.

Only test/ files changed. No defects requiring a report were found.

I found nothing that should block launch 1. The only finding I kept is informational, and it's written to .imd-findings.json. No tracked files changed, and I deleted my scratch test.

Checks I ran:

• Test suite: forge test passes, 20 of 20, using forge 1.8.4 with solc 0.8.26, which forge picked automatically.
• The two chunks: in a scratch test, FrenArtChunk1 and FrenArtChunk2 deployed with CREATE2, no arguments and no ETH.
  • Their code hashes match the pinned ones in src/FrenArtIndex.sol (0xf86a2dec…2d4b and 0x8579d215…650e).
  • Their code sizes are 24,001 and 24,139 bytes, under the 24,576-byte limit.
  • Both pass the protected opcode scan.
  • Deploying them with ETH attached fails, as it should.
• launch.json: it lists FrenArtChunk1 then FrenArtChunk2, with no constructor arguments, and is valid against the schema.

The finding I kept (info): once deployed, each chunk accepts ETH sent to it and can never send it back. Their code starts with a STOP byte, so a call carrying ETH succeeds and the ETH is stuck (src/FrenArtChunks.sol:387, and :775 for chunk 2). Four specialists reported this, and I merged their reports into one finding. I reproduced it: sending 1 ether to each chunk succeeded and left a balance of 1 ether. Only someone who sends ETH there by mistake loses anything. The code can't change without breaking the hashes the renderer requires, so the fix is documentation: never publish the chunk addresses as places to pay.

Dropped:

• Creation code depends on the compiler version (2 reports): I couldn't reproduce this. Only solc 0.8.26 is installed, and installing a second version failed because the filesystem is read-only. With 0.8.26 the creation-code sizes are 27,586 and 29,281 bytes, which match what ADAPTATION.md says. The pinned code hashes don't depend on the compiler. The claim that launch 3 must use the addresses actually deployed on chain, not ones predicted from a local build, is still sound advice, but it isn't a code defect in this launch.
• Slither leads in FrenRenderer.sol: these are not defects, and the renderer isn't part of this launch anyway. The "uninitialized" local variables at lines 97, 142 and 143 are meant to start at zero. The missing zero-address checks don't matter, because the constructor already reverts with BadArt when an address has no code: its code hash can't match the pinned one.
• Test-writer: reported no findings.

The only entry points in this launch are the two constructors and the code each chunk leaves behind. The constructors hold: they take no input, reject ETH and return the exact pinned bytes. The deployed code holds too, except for the ETH note above.