The review is complete. The findings file holds two entries and the tree is otherwise unchanged.

Outcome. The art launch's three contracts, WorkerArt1, WorkerArt2 and WorkerFrensRenderer, have no defect I could substantiate. The one real problem is outside their code: the committed manifest is the pre-split one.

Finding, medium: launch.json still describes the launch that failed. The split commit did not touch it. It lists PlaceFrens, WorkerArt1, WorkerArt2 and PlaceModules as one launch, passes three arguments to a constructor that now takes one, and omits the renderer entirely, while its notes still claim PlaceModules creates it. Priced by the repository's own formula, the four contracts cost 23.76M gas, about 7.0M over the 2^24 cap, so the deployer's simulation would revert again. The adapter must replace it with the three-contract art manifest, which the sources' test prices at 13.6M. ADAPTATION.md carries the same stale table.

What was read. The three art-launch contracts in full, including the renderer's assembly, plus WorkerArtIndex, FrensPlacement, FrensPlan, the deploy script, the launch and framing tests, the protected harness and the manifest. The collection's contracts were read only where the renderer touches them, since they are unchanged since the earlier hardening job and belong to the other launch. IMD's launcher contract was not reachable, so its overhead remains the sources' extrapolation.

What was verified.

• The offline suite and the mainnet fork suite pass. The renderer draws the art kit's reference frens and unrevealed cards byte for byte, and the seven swarm chunks on Ethereum hash exactly to the index.
• Beyond the shipped tests, a scratch fork test parsed all 82 art entries against the drawing loop's format, drew every character, face, hat and item, and fuzzed 256 seeds over all 12 backgrounds to confirm the window always covers the canvas. All passed.
• The three contracts hold no owner, role, payable path, external call or forbidden opcode. The renderer's constructor only compares code hashes, so a mis-ordered chunk reverts and it deploys on a fresh chain. Runtime and initcode sizes sit under the EIP-170 and EIP-3860 limits.

The findings are in .imd-findings.json. The scratch tests were removed after running.

The review is complete and written to .imd-findings.json. The tree is otherwise unchanged.

Outcome for the assigned area. The three art-launch contracts hold under the Access Control, Trust Gap and Asymmetry guides. WorkerArt1 and WorkerArt2 have no functions, storage or roles. WorkerFrensRenderer has only view and pure functions, no owner, and a nonpayable constructor that makes no calls and refuses any chunk pair but the exact art. Every chunk read re-checks the code hash. The combo ranges the renderer rejects match the ranges the collection's reveal check enforces, so the permissive attributes function is unreachable with a bad combo. I confirmed the seven swarm chunk hashes in the index against mainnet with cast at block 26,149,046, and all match. The manifest validates against the schema and the offline suite passes (173 tests).

Two findings, both at the seam where the collection is wired to this renderer, neither in the art contracts:

• Low, script/frens/DeployFrens.s.sol line 66. The setup script accepts any address with code as RENDERER. It never checks the target is a WorkerFrensRenderer over the launch's art. Reproduced offline: with RENDERER set to the collection launch's PlaceModules, setup completes, seals the traits and wires the collection to a contract whose tokenURI call reverts. A second setup run with the right value fails on TraitsAreSealed, so recovery is a manual setRenderer transaction the scripts do not provide. Suggested fix: check art1 and art2 code hashes or dry-call pendingURI before broadcasting. No source under src/ changes.
• Info, src/frens/IMD6900Frens.sol line 1012. freezeArt has no check that a working renderer is set, so a freeze before or with a wrong setRenderer breaks tokenURI permanently. It is curator-only self-harm with no unprivileged amplifier, and src/frens/ is frozen by the address constraint, so it is recorded as an operator trust assumption rather than a blocking defect. The curator modifier also admits the governor, so the timelock can change or freeze the art after handover.

Coverage. All 57 listed entry points have a row, 55 holds and 2 finding, plus six rows for the art launch's own constructors, view surface, hash invariants and the manifest. No row is unreached. The collection rows reflect the access-control lens only. Economic and numerical depth on the floor and swap paths belongs to the other specialists.

The review is complete. The findings file is written with an empty findings list and 63 coverage rows.

Result: no defect substantiated in the art launch. I traced the Execution Trace, Periphery and First Principles checklists against WorkerArt1, WorkerArt2 and WorkerFrensRenderer and could not produce a failing input.

What I verified, beyond reading the code:

• Offline suite passes as the author states (173 passed, 5 fork suites skipped), and the manifest regression script passes.
• Mainnet fork today reproduces the art kit's reference renders byte for byte, and the renderer's setup path points the collection at the launch's renderer. The seven swarm chunks still hash to the index's values.
• A scratch fork test I wrote (now deleted) covered what the repo's tests do not: all 57 non-background layers, including every one of the 39 faces, are well formed for the run decoder, every swarm index entry fits inside its chunk's code, and no face, hat, item or coat uses a colour index outside the shared palette or the nine slots. That last point is the split-palette design's key invariant; a violation would have made a fren's colours depend on its background.
• Decoder and reader safety: the framed read arithmetic stays inside its buffers for every index entry, a zero-length run ends in Missing rather than an infinite loop, off-canvas clipping uses signed compares, and the slot lookup only fires for indices 244 to 252.
• Boundary with the collection: check() bounds each trait value to exactly the ranges the renderer draws, so a revealed token can never hit Missing, and a revealed seed is forced odd so it never falls back to the pending card.
• Launch shape: three nonpayable, ownerless contracts in dependency order with backward references, within EIP-170 and EIP-3860, clean under the admission scan, and the one-transaction pricing leaves about 3.2M gas under the EIP-7825 cap.

Coverage: the 56 listed entry points all belong to the collection launch. Seven that touch the art boundary (setRenderer, freezeArt, reveal, the trait-rule setters) are traced with reasons. The rest are marked as untouched by the art launch, per the assignment's rule for entry points outside the area. Seven extra rows record the renderer's constructor, the chunk constructors, the reader, the decoder, the palette invariant, the view surface and the manifest.

One observation that is not a defect: pendingURI costs 13.06 to 13.65M gas on the fork, as the brief says, which is fine for an RPC read but rules out any on-chain caller.

The review is complete and .imd-findings.json is written and validated: all 57 listed entry points have a coverage row (69 rows total, including the art launch's own entry points and the gas-model invariant), the one finding's snippet matches the tree, and no tracked file was changed.

Outcome: no math, boundary or numerical-gap defect in the art launch. One info-level finding, outside the art contracts, about a fork test that has gone stale against live mainnet.

What I verified in the assigned area

• Byte-for-byte correctness on mainnet. With a public RPC, FrensPlacementForkTest's render check passed: all 7 revealed and 3 pending references in expected.json match the renderer's output exactly, reading the swarm's chunks on chain plus the two new ones.
• Every art entry, not just the sampled ones. A scratch fork test walked all 82 index entries (swarm chunks 0 to 3, launch chunks 7 and 8): each layer is a well-formed 4-byte header plus runs covering exactly its width, each palette is BGR0-aligned, and all 39 faces, 3 hats and 16 items draw. Swarm chunks 3 and 6 are framed on chain, matching the index's FRAMED bits.
• Edge arithmetic in the renderer. The framed read's frame/offset math, the palette layout (the largest own palette ends at exactly byte 1024), the background window (offsets up to 36 over 120-wide art always cover the 84 canvas), signed clipping in the drawing loop, the pending-combo bit packing (max bit 22, so the uint24 cast never truncates), and the BMP header fields all check out. The custom-error selector hardcoded in the assembly revert is the right one.
• Gas boundaries. The launch model prices the art launch at about 13.6M gas with its overhead term sitting above both real receipts, leaving about 3.2M under the 2^24 cap. Worst-case revealed render is about 4.7M gas; the pending card's worst case is about 14.9M, under the cap and under common eth_call limits.
• Collection math (secondary pass). I read all of IMD6900Frens, FrenMinter, FrenSwapper and FrenWorkerGate for rounding, underflow, scale mixing and casts. The pair hook's fee reads 690 on mainnet, confirming the swapper's bips assumption. Nothing reportable.

The one finding (info). test_fork_WorkersFirstThenPublic now fails on live mainnet because the team has already scheduled the exact timelock batch the test schedules. The timelock reports that operation as pending (ready at timestamp 1791649787), so the test's scheduleBatch reverts with an "already scheduled" state error. It is a stale test assumption, not a contract defect, and the other five fork tests pass. The suggested fix is to skip scheduling when the operation already exists and warp to its ready time instead.

The full offline suite passes (173 tests). The scratch tests under test/scratch/ were working material only and carry no proof, since there are no critical or high findings.

The review is complete and the findings file is written. No source files were changed. The findings file and the scratch tests are the only additions, and both are git-ignored by the harness.

Outcome. The art launch is economically inert and I found no defect in its three contracts. One low finding sits in the handoff script.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Dependencies. The renderer's only external dependency is seven swarm data contracts on mainnet. Their code hashes match the index at the current head, and post-Cancun nothing can remove existing code, so the dependency is permanent. Every read checks the hash, and the constructor makes no call, so it deploys on a fresh chain.
• Invariants. On a mainnet fork, all 82 art entries read back and are well-formed for the drawing loop, and all 39 faces, 2 hats, 15 items and 12 backgrounds draw. The repository's fork suite reproduced the 10 byte-for-byte reference renders. All 12 backgrounds are 120x120, so the seed window never exposes an unfilled pixel. The collection's reveal check and the renderer's combo guards enforce identical value ranges, so no revealed token can make the renderer revert.
• Gas economics. The launch prices at 13.6M gas all in, 3.17M under EIP-7825's cap. Through the collection's own tokenURI, a pending fren costs 12.6M and a revealed one 4.1M. Both are under the cap, but the pending read uses about 80% of it. I noted that as an open item rather than a finding since I could not reproduce a failure against a specific provider.
• Flow gaps. Either launch may land first; the art launch has no dependency on the collection.

The finding (low). The setup script's only check on RENDERER is that the address has code. Pointing it at WorkerArt1, which appears in the same launch output, succeeds and then every tokenURI reverts. That is recoverable with another setRenderer, but freezeArt has no check either, so the same mistake followed by freezing is permanent and the collection's bytes cannot change. Reproduced on a fork with a scratch test. The fix belongs in the script, which is not address-sensitive.

Coverage record. All 56 listed entry points have rows, plus 10 rows for the art launch's own functions and invariants. The entry points outside my area are marked as untouched by the renderer rather than traced in depth.

One existing fork test fails against the live chain because the timelock batch it schedules is already scheduled on mainnet. That matches what the adaptation notes already record.