The work is complete and committed. Build, tests and formatting all pass under the pinned compiler.

What was built (7 launch contracts, all under 13 KB runtime, no DELEGATECALL/CALLCODE/SELFDESTRUCT in any launch contract, verified with a scratch replica of the protected opcode scan):

• ArtStorage($owner): SSTORE2 chunk storage for plain SVG pieces; writes only from ArtHouse after the one-time setHouse. Next-id and next-index checks, clear until finalized, keccak256 check on finalize, seal needs every piece finalized, 100 KB cap.
• ArtHouse($owner, ArtStorage, IMD): the ledger. Artists with changeable payout, brokers, sale modules, per-collection basis-point splits (default 15/15/70, house keeps rounding, broker share falls to the house if unapproved or the buyer), per-currency balances with pull withdrawals, house balance paid to the current owner. Also plain SVG collections as EIP-1167 clones of an ArtCollection implementation the constructor deploys, with on-chain base64 JSON tokenURI, 7.5% ERC-2981 royalty, exact-ETH mint and exact-IMD mintWithIMD that rejects fee-on-transfer, plus the submission registry.
• ArtifactsPiece(): locked one-token ERC-721 + ERC-2981 implementation holding ciphertext pointer, traits, commitment and the current owner's wrapped key. Transfers clear the key and let the previous owner re-wrap.
• ArtifactsFactory($owner, ArtHouse, ArtifactsPiece): upload and lock of all 256 pieces, assignments, X25519 viewing keys, curator-posted wrapped keys, the buyer's claim that clones the piece, and the R8 seal tokenURI reproduced byte for byte from the reference framed pieces.
• ArtifactsSale, ArtifactsAuction, ArtifactsEscrow: the factory was split so each flow stays small and reviewable. The sale runs the one-price edition sale with Chainlink VRF v2.5 and a Fisher-Yates pool (tested over all 255 editions). The auction has the 5% increment, 10-minute extension, pull refunds and settlement through the ledger. The escrow runs the keyed resale with 72-hour release and buyer cancel until the key is posted.

Checks run: forge build, forge test with the verifier's fuzz seed (46 tests, all passing, including success and failure paths, not-configured states, reentrancy, conservation of funds, VRF stale-request handling), and forge fmt --check. Dependencies are vendored as plain files under lib/ and committed. The tree is clean.

Assumptions to note (also in the README): the brief's auction text was truncated after "proce", so auction proceeds go through the ledger split. The ARTIFACTS artist, module approvals, the one-time setModules wiring and the VRF coordinator, key hash and subscription are owner actions after launch, listed in order under "After launch". THE SOURCE's on-chain R9 render and revealed flag from PROTOCOL.md are outside the brief I was given and are not implemented. Tests use mocks for IMD and the VRF coordinator and are not a security audit.

I found one defect in the math area and wrote it to .imd-findings.json, with a coverage row for all 85 entry points plus 3 invariant rows. No source files changed, and the scratch test has been removed.

Finding 1 (medium): reading a stored piece costs gas that grows with the square of its chunk count. At src/ArtStorage.sol:161, _read rebuilds the whole piece with bytes.concat once per chunk, and each pass copies everything read so far. The 100 KB size cap doesn't limit the cost, because the curator or the artist can upload a piece in chunks of any size. _read is used by finalizePiece and, through pieceBytes, by ArtCollection.tokenURI. Gas measured on this tree for a 100 KB piece:

Chunk size	finalizePiece	tokenURI
4 KB	4.4M	not measured
2 KB	15.0M	38.3M
1 KB	54.8M (out of gas at a 30M limit)	over 50M (fails under the default 50M call limit of standard Ethereum nodes)

• Impact: a finalized piece can't be cleared, so once it is sealed and sold its tokenURI may be unreadable through standard nodes. A piece that can't be finalized blocks seal until the curator clears it and someone re-uploads it, wasting roughly 20M gas of storage writes.
• Fix: allocate the buffer once at the piece's recorded size and copy each chunk into it at its offset, so the cost is linear in the piece's size.
• Proof: the attached Foundry test fails on the current code. I applied that fix to a copy of the repo outside the working tree; there the test passed and all 47 existing tests still passed.

Checked and holding:

• Sale split: the shares always add up to the amount paid, and the house keeps any rounding (setSplit adds the parts at full width before comparing to 10,000).
• Resale royalty: 7.5%, rounded down; it is zero only for prices under 14 wei.
• Edition assignment: each of the 255 editions is assigned exactly once, and stale or retried randomness callbacks are ignored.
• Auction: the 5% increment rounds down, so a bid exactly equal to the high bid can win only when the high bid is under 20 wei. The 10-minute extension and end-time boundaries are consistent, and the ETH it holds always equals what it owes.
• Escrow: the exact-price checks, the 72-hour release boundary and refund accounting hold.
• Size casts: the narrowing casts are safe. The 16-bit length in the storage library can't overflow because Ethereum caps contract creation code at 49,152 bytes.
• Static analysis leads: the reentrancy and timestamp warnings involve only trusted contracts or safe comparisons.

Outside my area, noted but not reported:

• A previous owner keeps the right to overwrite a piece's wrapped key indefinitely.
• When a buyer cancels an escrow sale, the seller's on-chain wrapped key is lost.
• An escrow listing is not cleared when the piece is transferred away, so it becomes buyable again if the seller gets the piece back.
• Titles and descriptions supplied by artists go into the token's JSON metadata without escaping.

All three guides (Math Precision, Boundary, Numerical Gap) were covered and nothing was left unreached.

The manifest is written and verified. Only launch.json was added to the tree.

What I delivered

launch.json describes the seven accepted application contracts in constructor dependency order, matching the README's launch table and the Deploy script that the accepted tests exercise:

1. ArtStorage takes the owner.
2. ArtHouse takes the owner, ArtStorage and the existing IMD ERC-20 address from the brief.
3. ArtifactsPiece takes no arguments and is the locked EIP-1167 implementation.
4. ArtifactsFactory takes the owner, ArtHouse and ArtifactsPiece.
5. ArtifactsSale takes the owner, ArtHouse and ArtifactsFactory.
6. ArtifactsAuction takes the owner, ArtHouse and ArtifactsFactory.
7. ArtifactsEscrow takes ArtHouse and ArtifactsFactory. It has no owner because it has no administrative power.

Every privileged owner argument is $owner, every contract reference points backward and fills an address parameter, and the IMD address is the static one the brief states. The notes explain the four-way split of the factory and the post-launch owner wiring.

Checks run

• Clean build at solc 0.8.26 with via-IR. Every runtime is under the EIP-170 limit, the largest being ArtifactsPiece.
• Full test suite passed with the verifier's fuzz seed: 46 tests, 0 failures, including the deploy wiring test and the VRF assignment fuzz test.
• A script compared the manifest against the compiled constructor ABIs: the manifest has exactly the three schema keys, every name is a unique identifier under 32 characters, every argument count matches its constructor, every reference resolves to an earlier contract, and the notes are under the 4,000-character limit.
• Git status shows launch.json as the only new or changed file.

One note for the reviewer: the task text says Sepolia while the pinned launch policy says Ethereum mainnet. The chain is not a manifest field, so the manifest is correct either way and the pinned policy decides the chain.

The review is complete and the findings file is written and validated. No source files were changed.

Outcome: the economics, invariants and flow gaps hold up well. I found no critical, high or medium defects, so no proof files were attached. Four lower-severity issues are recorded in .imd-findings.json, each reproduced by a scratch Foundry test that passes on the current code to demonstrate the behaviour.

Findings:

• Low, escrow stale listing. A listing is not invalidated by a plain transfer. If the seller moves the piece away and later gets it back, the old listing becomes executable again at the old price, and any watcher can buy at that stale price.
• Low, sale opens without factory wiring check. ArtifactsSale.openSale does not require the factory's sale module to be this contract. Purchases are paid and credited in the ledger immediately, but the VRF callback can never assign an edition, and there is no refund path. Harm needs a curator misconfiguration. The missing state check is the defect.
• Low, previous owner's key power never expires. After a plain transfer the previous owner can overwrite the wrapped key at any later time, even after the new owner posted their own.
• Info, auction increment rounds to zero below 20 wei. An equal bid then displaces the leader. Dust only.

Coverage: all 85 listed entry points have a row, plus five invariant rows. Verified as holding: full-value conservation in the ArtHouse ledger, escrow and auction balances, the Fisher-Yates edition assignment with no repeats or skips, the 15/15/70 split with house rounding, exact-price enforcement in ETH and IMD, the fee-on-transfer rejection, pull-based withdrawals and refunds, and the reentrancy ordering. Trust assumptions noted but not reported as defects: one-time VRF and module configuration, the curator posting content keys, and the unverifiable wrapped key on resale.

Not reached: the seal SVG rendering and JSON escaping of trait strings, which are outside my area.

The review is complete. The findings file is written and validated.

Outcome. The permission model holds on its core guarantees: no mint bypasses payment, the escrow's blanket operator right is only ever exercised from the listed seller, initializers are locked on both implementations, and every ledger movement is pull-based with credits written before transfers. I found no critical or high defects in the Access Control, Trust Gap, or Asymmetry areas, so no finding carries a proof file. Six low findings and one info note are recorded in .imd-findings.json, each with a concrete call sequence I confirmed in a scratch Foundry test.

Findings reported (all low unless noted):

• Re-approving an artist overwrites the artist-chosen payout. The curator can redirect future artist credits and ERC-2981 royalties by calling approveArtist again, which contradicts the brief's "payout address the artist can change".
• A registered piece can never be unregistered or have its hash fixed. clearPiece only drops chunks, so one wrong contentHash permanently blocks seal and the collection can never open.
• Revoked artists keep write rights on their collections. The curator-or-artist guard checks identity, not approval, so revocation does not stop registerPiece, uploadChunk, or finalizePiece.
• The previous owner's re-wrap right never expires. After a plain transfer the old owner can overwrite the holder's wrapped key with garbage at any later time.
• Revoking the escrow or auction module mid-flight strands buyer funds. With a key posted, confirm and release revert and cancel is blocked, so the buyer's ETH and the piece sit in the escrow until the curator re-approves. Documented as a privileged-power risk.
• openSale does not check the factory names this sale. Buyers are charged and the split is credited while every VRF callback reverts. If setModules named another address, the one-time wiring makes the purchases unrecoverable.
• Info: trust assumptions the code does not bound. setSplit works while a sale is open, and the owner-chosen VRF coordinator fully controls edition assignment.

Coverage. All 85 listed entry points have a row, plus three invariant rows. None are marked unreached.

Verification notes. The project's own suite could not run in this sandbox because the via-IR compile of all 67 files exceeds the 1.5 GB memory cap, and a non-via-IR build fails with stack-too-deep. I worked around this by compiling only the sources plus one self-contained scratch test under test/scratch/, which passed all five reproduction checks. That directory is gitignored and nothing else in the tree changed.

Review complete. The findings file is written and validated: every snippet matches the tree, and all 85 listed entry points have a coverage row.

What I did

I read the Senior Auditor's Mindset plus the Execution Trace, Periphery and First Principles guides, then traced every state-changing entry point across the seven contracts and two libraries. The build only fits the 1.5 GB memory cgroup when the large existing test files are skipped, so I confirmed each claim with a scratch Foundry test compiled against the source alone. All seven probes passed, meaning each defect reproduces on this tree.

Findings, most severe first

1. Medium, ArtStorage.clearPiece: a registered piece's content hash can never be corrected. Clear only resets chunks, re-registration needs the next id, so one typo leaves the collection unsealable and unsellable forever.
2. Low, SSTORE2.write: the length is cast to 16 bits. A 65535-byte chunk deploys an empty pointer and reads revert; 65536 to 90111 bytes store silently truncated data. Both pass the 100 KB check and are reachable from uploadChunk.
3. Low, ArtHouse revocation: a revoked artist keeps write access to its collection and can block seal indefinitely by registering pieces nobody can finalize.
4. Low, ArtifactsSale.openSale and ArtifactsAuction.configure: neither checks the factory's module wiring. Buyers can pay into a sale whose VRF callback reverts forever if setModules was consumed with another address.
5. Low, ArtHouse.revokeModule: revoking the escrow or auction strands the buyer's ETH and the escrowed token with no refund path once the key is posted.
6. Low, ArtifactsPiece.setWrappedKey: the previous owner keeps key-posting authority indefinitely and can overwrite the key the current owner set.
7. Info: the auction increment rounds to zero below 20 wei, so an equal bid wins.
8. Info: ArtCollection.tokenURI does not escape artist-supplied title and description.

Coverage

The ledger, VRF assignment, Fisher-Yates uniqueness, escrow and auction flows, withdrawals and clone initialization all hold under my area's checks. ETH conservation holds in ArtHouse, the escrow and the auction. No critical or high defect was found, so no proof test file is attached. The scratch probes remain under test/scratch for the judge's reference and are not part of the submission.

I added 30 new tests and 4 invariant suites in two new files. The full suite passes with the verifier's fuzz seed: 76 tests, 0 failing. I found four defects in the contracts and wrote them to .imd-findings.json instead of writing tests that treat them as correct.

test/Invariants.t.sol has a random-call-sequence suite for each contract that holds value:

• ArtHouse: the handler mints in ETH and IMD, records module sales and resales, withdraws, and changes splits, brokers, the artist's payout and prices. After every sequence, the contract's ETH and IMD balances must equal the sum of everyone's credits, and must equal what came in minus what went out. Withdrawals pay exactly what is owed, and there is one token per paid mint, never more than the registered pieces. Each recorded sale is also checked for the right broker, artist and house shares, with the house taking the rounding.
• Auction (THE SOURCE): the auction always holds exactly the pull refunds plus the open high bid. The end time never moves earlier, a bid always leaves at least 10 minutes, a bid below the minimum changes nothing, and settling assigns THE SOURCE to the winner and pays the ledger.
• Resale escrow: it holds exactly the refunds plus the funded listings. A funded piece is always held by the escrow and an unfunded one never is. A release hands the buyer the piece and the re-wrapped key. The ledger's balance stays matched to what it owes.
• Edition sale: no edition is assigned twice, the assigned buyer is correct, and a repeated VRF callback changes nothing. The sale contract keeps no ETH; everything goes to the ledger.

test/FailurePaths.t.sol covers the failure paths:

• ArtHouse: wrong price, closed sale, unknown or already-sold piece, IMD with the wrong price or not enough allowance, and module-only collections. It also covers who may upload, finalize, clear and seal; splits that don't sum to 100%; revoked modules; and the house balance following a change of owner.
• Edition sale: VRF set only once, and the price changeable only while the sale is closed. The 256th purchase is refused as sold out, and retries follow their rules. The VRF callback fits within its 250,000 gas limit.
• Claim and piece contract: the order of the claim steps, and re-initialising a piece or the implementation is refused. Only the right people can post keys, and the 7.5% royalty goes to the current payout address.
• Auction: a bidder who rejects ETH blocks only their own refund, and a bid at the exact end time is refused. Settling while the auction is not an approved module is refused.
• Escrow: steps out of order are refused, and the refund can't be re-entered.

Defects reported in .imd-findings.json:

1. Medium: a buyer who cancels a resale permanently erases the seller's wrapped key on their own piece. The curator can't re-post it once the piece is claimed, and any buyer can do this to any listed seller for just gas.
2. Low: after a plain transfer, the previous owner can keep overwriting the new owner's key with garbage.
3. Low: the minimum bid rounds down, so with a reserve of a few wei an equal bid can take the lead (two bids of 19 wei).
4. Low: the tokenURI JSON for later collections doesn't escape titles or descriptions, so a quote in a title breaks the JSON or injects fields.

I reproduced the first three in throwaway tests, which fail on the current code as expected. The fourth comes from reading the code and I did not run it. None of the four carry a proof file, since none is critical or high.

The VRF and IMD token are local stand-ins. Nothing has been run against the live Sepolia coordinator or the real IMD token, so those checks are still owed.

The review is complete and .imd-findings.json holds 14 findings and 87 coverage rows covering all 85 entry points.

What I verified

• Every specialist claim I kept was reproduced with a Foundry test in test/scratch/Review.t.sol, and all 14 of those tests pass on this tree, confirming the behaviour. The existing suite still passes.
• The audit_math proof for the quadratic storage read fails on this code as stated, so it stays attached as the one proof.
• Duplicates across the four specialists and the test writer were merged: the previous-owner key overwrite (four reports), the sale wiring check (three), the auction rounding (three), the JSON escaping (two), the content-hash repair gap (two), the revoked-artist guard (two) and the module revocation freeze (two).

Findings kept, by severity

• Medium: ArtStorage._read is quadratic in chunk count, so a 100 KB piece in 1 KB chunks cannot be finalized in 30M gas or rendered in a 50M eth_call.
• Medium: a registered piece's content hash can never be corrected or removed, so one bad hash permanently blocks seal and sale of the whole SVG collection.
• Low: revoked artists keep write access; buyer cancel wipes the seller's wrapped key; previous owner can overwrite the key forever; sale and auction do not check the factory wiring; revoking a module strands escrow and auction funds; re-approving an artist overwrites their payout; SSTORE2 truncates lengths above 65534 bytes; stale escrow listings revive; tokenURI JSON is unescaped.
• Info: auction increment rounds down below 20 wei; ERC-2981 on pieces reverts if the factory's module approval is revoked (my own finding); setSplit while open and the owner-chosen VRF coordinator are documented trust assumptions.

Leads dropped

• The slither reentrancy line on ArtifactsSale.buy and the aderyn locked-ether line do not reproduce. The function is guarded, calls only trusted contracts and forwards all value.
• The VRF callback measures about 103k gas, well within its 250k limit, so that path holds.
• The manifest lists seven contracts in dependency order with matching argument counts, and every runtime is under the size limits.

All checks are green. Recap of this revision:

Outcome. The reviewer's proof for the quadratic read now passes, every one of the 14 findings reproduced and was fixed, and the suite grew from 46 to 62 tests. Build, tests with the pinned fuzz seed, and the format check all pass. Answers to each finding are in .imd-responses.json.

The two blocking findings

• Quadratic storage read. ArtStorage now allocates the piece once and copies each SSTORE2 chunk at its offset. A 100 KB piece in 100 chunks finalizes well inside 30M gas and renders inside a 50M gas call.
• Unrepairable content hash. The curator gained two repairs for unfinalized pieces in unsealed collections: rewrite the hash and text in place, or drop the last registered piece so the count shrinks and the seal is unblocked.

Advisory findings, all fixed

• Revoked artists lose write access to their collections until re-approved.
• Cancelling a resale restores the seller's wrapped key, which the escrow saves at purchase.
• A previous owner can post a key only while the new owner has none, so it can never overwrite one.
• The edition sale and the auction refuse to open or configure unless the factory names them.
• Revoking the escrow or auction module no longer strands anyone: the piece still moves, and proceeds are held for pull or forwarded later.
• Re-approving an approved artist keeps the payout the artist chose.
• SSTORE2 rejects payloads above one contract's size instead of truncating them, with a clear chunk-size error upstream.
• Escrow listings are bound to the piece's transfer count, so any transfer kills a listing.
• Plain collection titles and descriptions are JSON-escaped in the token metadata.
• The auction increment rounds up, so a bid never merely equals the high bid.
• Module revocation keeps the collection on record, so ERC-2981 royalty lookups keep resolving.
• Splits of plain collections change only while their sale is closed. The remaining curator powers over the ARTIFACTS split, the VRF coordinator choice, and key posting are documented as trust assumptions.

Not run here. The two protected check files in the read list need a helper source and environment variables that only the verifier provides, so they do not compile on this machine. Constructors, opcodes and runtime sizes are unchanged in kind, and every contract stays under 13 KB.

The README documents the new repair functions, the chunk-size cap, the escrow and auction fallbacks, and the added trust assumptions. Nothing was committed, and no launch manifest or blocked file was written.

The manifest is verified against the revised sources and only one stale figure in the notes needed correcting.

What I checked

• All seven manifest entries match the constructors in the accepted tree: ArtStorage($owner), ArtHouse($owner, ArtStorage, IMD), ArtifactsPiece(), ArtifactsFactory($owner, ArtHouse, ArtifactsPiece), ArtifactsSale and ArtifactsAuction ($owner, ArtHouse, ArtifactsFactory), and ArtifactsEscrow(ArtHouse, ArtifactsFactory). Order is dependency order and every reference points backward.
• The IMD address in the manifest is the correct EIP-55 checksum of the address the brief gives.
• The file has exactly the keys kind, contracts and notes. Contract names are unique and under 32 characters. Notes are well under the limit.
• Every post-launch function the notes name still exists in the revised sources, including setHouse, approveModule, setModules, configureVRF, setPiece, lock, setPrice, openSale and configure.
• All eight runtimes are under the EIP-170 limit. The largest is ArtifactsPiece.
• The build succeeds and the full suite passes with the verifier's fuzz seed.

Check	Result
Tests	61 passed, 0 failed
Largest runtime	ArtifactsPiece, 12,395 bytes

What changed

The other contributor's later revision grew ArtifactsPiece, so the notes' claim of a 12.2 KB largest runtime was stale. I replaced it with the measured figure. Nothing else in the manifest changed, and git status shows launch.json as the only modified file.

The scratch reproduction confirms the finding. The work is complete.

Outcome. The implementer's revision changed two behaviours my previous tests asserted, so those two tests failed. I updated them to the new design and extended coverage of the new code. forge test with the verifier's seed passes all 105 tests, and only test/FailurePaths.t.sol and test/Invariants.t.sol changed.

What changed in my tests

• Auction settle while revoked no longer reverts. The test now checks that the winning bid is held, the winner can still claim THE SOURCE, the outbid refund is unaffected, forwarding fails until re-approval, anyone can forward once, and a second revocation cannot recreate a hold.
• Revoked module royalty lookup no longer reverts. The test now checks it still resolves, strangers still get the revert, and re-approval restores recording.
• New failure-path tests: escrow release under a revoked module via timed release holds the full price for the seller with no royalty and no double payment on re-approval; cancel restores the seller's key only if one existed; a self-transfer keeps the key but kills the listing; an old owner's stale listing cannot sell the new owner's piece; split changes are frozen only for an open SVG sale; re-approving keeps an artist's payout and revocation removes write access; repair functions reject strangers, module collections, finalized pieces and sealed collections, and a dropped id can be re-registered and sealed; chunk and piece limits at the exact boundary; a 100-chunk piece finalizes under block gas.
• JSON escaping, which the implementer's suite did not test as a property: a fuzz round-trip through an independent unescaper that rejects raw quotes and control characters, pinned edge cases, and a full decoded tokenURI check.
• A fuzz over tiny bids confirms the minimum bid is strictly above the high bid and at least 5% over.

Invariant handlers. The escrow and auction handlers now toggle module approval mid-flow and track held proceeds, so conservation is checked across revocation. I also found and fixed a bug in my previous handlers: a prank placed before a view call was consumed by it, so every broker toggle had silently reverted. All handler actions now run with zero reverts.

Finding reported. One low-severity trust note in .imd-findings.json: revoking an artist and re-approving them lets the curator overwrite the payout address the artist chose, redirecting future royalties. I verified the reproduction in a scratch test. No critical or high defects were found in the revised code.

The review is complete and .imd-findings.json holds the result.

Outcome: every finding from the previous round is fixed. Both medium findings and all twelve advisory findings were re-run against the revised code and hold up.

• Quadratic read (medium): both attached proof files now pass. A 100 KB piece in 100 one-kilobyte chunks finalizes and renders within the stated gas limits.
• Unrepairable contentHash (medium): the new curator-only redescribePiece and dropLastPiece paths repair or remove an unfinalized piece, after which seal and openSale succeed.
• Advisory items: revoked artists lose write access, escrow cancel restores the seller's key, the previous owner cannot overwrite a posted key, sale and auction refuse to open unless the factory names them, module revocation holds proceeds for pull instead of stranding the buyer or winner, approved artists keep their payout, SSTORE2 rejects oversize chunks, listings die on any transfer, tokenURI escapes JSON, the auction increment rounds up, royalty lookups survive factory revocation, and setSplit is closed-only for SVG collections.

Verification done. The full project suite passes with 105 tests, all eight runtime sizes are under the EIP-170 limit, and the manifest has valid keys, seven uniquely named contracts in dependency order, and one argument per constructor parameter. I wrote an eleven-test scratch file reproducing each earlier scenario on the fixed code, then deleted it, so the tree is unchanged.

One residual, reported as info. The payout fix only protects a currently approved artist. Revoking and re-approving still lets the curator write a new payout over the one the artist chose, redirecting future artist shares and ERC-2981 royalties until the artist calls setPayout again. This is a visible curator power inside the documented trust model, not a bypass, so it does not block the launch. The suggested fix is to keep the stored payout whenever it is non-zero.

The coverage record answers all 90 entry points, with every row marked holds except approveArtist, which points to the info finding.