Done. The Proof House contracts, tests and documentation are complete and verified locally.

What was built (Foundry project at the repository root, solc 0.8.26, via-IR, bytecode_hash = "none", forge-std vendored as plain files):

• ArtStorage($owner): SSTORE2 chunk store, written only by ArtHouse after the one-time setHouse.
• ArtHouse($owner, ArtStorage, IMD): the ledger. Artists with artist-only payout kept on re-approval, brokers, sale modules, per-collection basis-point splits with the house taking rounding and unearned broker shares, balances per currency with pull withdrawals, 7.5% ERC-2981 royalties, plain SVG collections as ArtCollection clones with on-chain base64 JSON, curation with the 100 KB cap, exact-price ETH and IMD minting, and open submissions.
• ArtifactsPiece(): locked implementation. One-token ERC-721 + ERC-2981 holding ciphertext pointer, traits, commitment and wrapped key, with keyed resale escrow, 72-hour release, re-keying after plain transfers, the R8 seal tokenURI, and THE SOURCE's write-once reveal.
• ArtifactsFactory($owner, ArtHouse, ArtifactsPiece): publication and lock of 255 pieces, closed-by-default sale, VRF v2.5 set once by the owner, Fisher-Yates edition assignment in the callback, and claim deploying EIP-1167 clones.
• ArtifactsSource($owner, ArtHouse, ArtifactsPiece): split out for size. Stores THE SOURCE payload with SSTORE2 and locks it, runs the 5% / 10-minute single-lot auction with pull refunds through the ledger, and settles.

Verification: 39 tests pass with the verifier's fuzz seed, forge build and forge fmt --check pass, every launched runtime is under 24 KB with no DELEGATECALL, CALLCODE or SELFDESTRUCT. Tests cover split invariants per currency, all 255 VRF assignments without repeats or gaps, claim, escrow and re-keying, the auction, reveal, access control, reentrancy, seals byte-for-byte against the reference frame, and THE SOURCE's revealed tokenURI equal to the payload file and decoding to framed-MASTER.svg.

Two design decisions worth knowing:

• THE SOURCE's contract is a full byte copy of ArtifactsPiece's runtime rather than a proxy. A proxy copies the 1.8 MB answer a second time, which pushed the revealed tokenURI to about 13M gas. The copy keeps it near 7M.
• The reference files live under reference/, not artifacts/, because the harness's git exclude list silently drops artifacts/.

After launch, the curator must run the steps listed in the README: setHouse, approve the artist, register both ARTIFACTS modules as sale modules and collections, configureVRF with Chainlink's Sepolia coordinator and the curator's subscription, publish and lock the pieces, set the price, store and lock the payload, then open the sale and auction. Nothing here is a security audit, and the curator holds every content key until the last claim, as the reference protocol discloses.

I've written launch.json for the five contracts in the accepted source, in the order each depends on the last. All 38 tests pass with the verifier's fuzz seed, and launch.json is the only file I changed.

• Fifth contract: the brief lists four contracts, but the accepted source moved THE SOURCE's auction out of ArtifactsFactory into its own ArtifactsSource to stay under the contract size limit. The brief allows splits like this, and script/Deploy.s.sol and the README use the same arguments.
• Sizes: every contract that gets deployed fits under the 24,576-byte limit. The largest is ArtifactsPiece at 18,472 bytes.
• Size warning: forge build --sizes still reports that some contract is over the limit. It isn't one of these five, and I didn't check which one it is.
• Notes: at about 1,600 characters, well under the 4,000 limit. They describe each contract's role and what the curator does after deployment: call ArtStorage.setHouse, then approve and register both sale contracts on ArtHouse.

I checked the manifest by reading it against the rules; there's no local tool that validates it.

The review is complete and .imd-findings.json holds five substantiated findings plus a coverage row for every one of the 73 listed entry points (all answered, none unreached).

Findings, by severity

• Medium. Revocation does not revoke curation rights. The curator-or-artist check in ArtHouse compares only against the collection's artist address and never reads the approved flag. A revoked artist still registers, uploads and finalizes pieces on their unsealed collections. Reproduced in a scratch test.
• Medium. A wrong contentHash is permanent. registerPiece writes the hash once and clearPiece resets only chunks and size. One piece whose hash matches no data blocks finalizePiece, so sealCollection and setSaleOpen revert forever for that collection. The artist can do this without the curator, and with the first finding, after being revoked. Reproduced.
• Low. Escrow seller keeps rewrap rights after release. previousOwner is set on the release transfer and never cleared, so the seller can overwrite the buyer's wrapped key with garbage at any later time. Reproduced.
• Info, trust assumption. setSplit on in-flight proceeds. The curator can change THE SOURCE collection's split between the final bid and settle, moving the artist's share to the house. Verified with a scratch test against the fixture. Recorded as a privileged power, not a bypass.
• Info. Zero viewing key accepted on ArtifactsPiece, unlike the factory. Only the registrant is affected.

What held in my area. Two-step ownership on all four owned contracts with no renounce path and explicit owner arguments. Implementation locking for both clone templates, with initialization atomic to creation. Sale-module gating of recordSale, house-only writes to ArtStorage and ArtCollection, coordinator-only VRF callback, buyer-or-curator claim, and the auction, escrow and withdrawal guards. No mint path exists outside exact payment at the ledger, claim, or settle.

Not covered. The IMD token at the Sepolia address was not checked against the ledger's boolean-return assumption, and the base64 and revealed tokenURI paths are outside my area and were not traced. No finding reached critical or high, so no proof files are attached. The scratch tests under test/scratch are disposable and nothing in src or test was changed.

All snippets match the tree and the findings file is complete. Review done.

Result: 5 findings written to .imd-findings.json with a coverage row for every one of the 76 listed entry points plus 4 invariant rows. No file in src/, test/ (outside test/scratch/), or configuration was changed.

Findings, most severe first

1. Medium, escrow re-key overwrite. After release(), the paid seller stays previousOwner and rewrapFor has no guard, so the seller can replace the wrapped key the buyer paid for. Proof test under test/scratch/RewrapOverwrite.t.sol fails on this tree and is attached as the finding's proof.
2. Medium, uncorrectable piece hash. A wrong contentHash in registerPiece can never be fixed, since clearPiece keeps the hash and pieces cannot be re-registered. The collection can then never be sealed or opened. Confirmed by a scratch test walking the dead end.
3. Low, empty escrow key accepted. postEscrowKey("") locks the buyer out of cancel and starts the 72-hour clock, unlike the factory path which rejects an empty key.
4. Low, revoked artist keeps curation rights. The curator-or-artist check never reads the approved flag, so a revoked artist can keep adding pieces, which combined with finding 2 blocks sealing.
5. Info, trust assumption. The curator can change a collection's split while THE SOURCE auction or the editions sale is live. The split is read at settle time.

What held

• ETH and IMD conservation in the ledger, the split arithmetic, and pull withdrawals.
• VRF flow: coordinator-only callback, replay guard, Fisher–Yates assignment, and a measured callback cost of about 165k gas under the 250k limit.
• Auction rules, refund accounting and settlement proceeds.
• The IMD token on Sepolia returns a boolean from transfer, so IMD withdrawals will not revert on decoding.

Not reached in depth: the seal SVG rendering, base64 encoding and the revealed tokenURI assembly, which sit outside the economics area. Their entry points are marked as holding on access grounds only.

The review is complete. The findings file is written and the source tree is unchanged.

Outcome. The code is well built. All 38 project tests pass, and the core value paths in my area (Execution Trace, Periphery, First Principles) hold: credits are written before any transfer, every withdrawal zeroes before paying, VRF assignment is a correct lazy Fisher-Yates, and the EIP-1167, code-copy and SSTORE2 creation sequences decode correctly by hand. I found four defects, one medium and three low, each with a reproduction run in a scratch test.

Findings written to .imd-findings.json:

1. Medium, with proof. After a keyed escrow sale, the seller remains previousOwner, so they can call rewrapFor and overwrite the buyer's wrapped key forever. The escrowed key is deleted at release and never emitted, so the buyer's only on-chain copy can be destroyed by the seller they just paid. The proof test fails on this code and passes with previousOwner = address(0) after the release transfer.
2. Low. postEscrowKey accepts empty bytes, which counts as "posted", removes the buyer's cancel right, and lets the 72-hour release pay the seller with nothing delivered. The factory's equivalent rejects empty keys.
3. Low. The 5% minimum raise rounds to zero for high bids under 20 wei, so an equal bid replaces the high bidder. Only reachable with a sub-20-wei reserve.
4. Low. revokeArtist does not strip a revoked artist's curation rights on their existing unsealed collections. A revoked artist can register a piece with an unmatchable content hash, and since registered pieces cannot be removed, the collection can never be sealed.

Coverage. All 73 listed entry points have a row, 66 holding and 7 pointing at a finding, plus rows for the ledger and auction conservation invariants and for the periphery libraries. I also checked the live IMD token on Sepolia: it has code, reports symbol IMD, and both transfer functions return true, so the ledger's boolean decoding holds. The VRF callback measured about 147k gas against the 250k limit.

Not reached. I did not exercise the Chainlink coordinator's failure handling against a real coordinator, and I did not fuzz the seal rendering beyond the project's own byte-for-byte tests.

All four snippets match the tree, and the findings file is in place at the repository root with 4 findings and 78 coverage rows. Nothing outside test/scratch/ and .imd-findings.json was written.

Scope covered. I applied the Math Precision, Boundary and Numerical Gap guides to every value-moving formula and every external boundary: the basis-point split and its rounding, ERC-2981 royalty math, the auction raise and timing arithmetic, the Fisher-Yates VRF assignment, SSTORE2 sizes and the EIP-170 edge, the 100 KB piece cap, the base64 encoder, and the revealed-tokenURI memory copy. The existing 38 tests pass. I added scratch probes for tiny-value sales, auction boundaries, callback gas, chunk limits, dirty-memory encoding, and a 400-run fuzz of both tokenURI paths.

Findings, all low. Nothing in the math loses funds or pays the wrong party.

• Auction raise floors to zero below 20 wei. With reserve 1 wei, a 19 wei bid is displaced by another 19 wei bid because 19×500/10000 truncates to 0. The brief requires a strict 5% beat.
• Empty escrow key accepted. A seller posting zero-length bytes flips keyPosted, removes the buyer's cancel right, and the token releases after 72 hours with no wrapped key. The factory's equivalent function already rejects empty input.
• Wrong contentHash is permanent. A piece id registers once, clearPiece keeps the hash, so one typo leaves the collection unsealable forever. No funds at risk.
• Base64 encoder relies on zeroed tail memory. It reads up to two bytes past the input into the last group. Both production callers fuzzed clean, so this is latent, but it is the bug OpenZeppelin fixed in v5.

What holds. Per-currency conservation holds down to 1 wei with the house taking the rounding. The VRF callback measured 165k gas cold against the 250k limit. The chunk limit of 24,575 bytes writes and 24,576 reverts. lockPayload costs 7.74M gas and the revealed tokenURI stays under 10M. Every listed entry point has a coverage row and none is marked unreached.

The findings file is in place at the repository root; the harness excludes it from git deliberately, as it does test/scratch/. Everything is verified, so the work is complete.

Summary

Delivered (all under test/, nothing outside it touched): 50 new tests on top of the existing 38, all 88 passing both with the verifier's fuzz seed and without it.

Invariant suites over random call sequences (test/invariants/, each with a handler, several actors, ghost variables, and fail-on-revert = true so every handler path is asserted, 0 reverts across ~22,000 calls):

• ArtHouseInvariant.t.sol: ETH and IMD held equal what is owed and equal in-minus-out; nobody withdraws more than credited; the exact split is checked per sale against the live bps with the house taking rounding; supply fixed and seal never lifts; survives split, broker, payout, price and two-step ownership changes mid-sequence.
• ArtifactsFactoryInvariant.t.sol: assigned ≤ sold ≤ 255, every purchase is pending or assigned, no edition twice, ledger holds every purchase, claimed tokens belong to their buyers, replayed and stranger callbacks always rejected.
• PieceEscrowInvariant.t.sol: piece balance equals escrowed payment plus pending withdrawals; one token, one owner, moving only by release or plain transfer; seller keeps the token while a buyer is in escrow; each of list/buy/postKey/cancel/release/transfer/rewrap asserts "succeeds iff the rules allow it".
• SourceAuctionInvariant.t.sol: auction balance equals live high bid plus refunds owed; high bid monotone; 5% rule and 10-minute extension checked on every bid; settlement final with proceeds split in the ledger.

Adversarial edge suite (test/Adversarial.t.sol): zero dependencies and no-code dependencies in constructors, pending owner powerless, revoked artist and broker behaviour, split extremes and a 512-run split fuzz, fee-on-transfer and false-returning IMD rejected, stale IMD price rejected, 24,576-byte chunk rejected, VRF coordinator that reverts or returns a duplicate id, empty callback, 1-wei price, wrapped-key re-posting, EIP-1167 bytecode of a claimed clone, seal byte-for-byte against the R8 reference frame for fuzzed trait vocabularies, escrow boundaries (exact 72 h, operator approvals, rejecting and re-entering receivers), THE SOURCE reveal gate via a stub controller, auction boundaries (exact reserve, exact +5%, exactly 10 minutes left), launched runtimes under EIP-170 with no DELEGATECALL/CALLCODE/SELFDESTRUCT.

Findings reported in .imd-findings.json rather than tested around, each confirmed by a scratch test that fails on the current code: empty escrow key strips the buyer's cancel right (low, with proof), previous owner can overwrite a confirmed escrow key (low, with proof), 5% raise rounds to zero under 20 wei (low), piece accepts a zero viewing key (info), and an unfulfilled VRF request has no on-chain recourse (low). No critical or high defects were found.

Still owed: fork runs against the live Sepolia IMD token and Chainlink coordinator could not run here with no network; the mocks reproduce their documented behaviour only.

The review is finished and written to .imd-findings.json. It holds 8 findings (2 medium, 4 low, 2 info) and covers all 73 entry points plus one invariant check. Nothing is critical or high. The existing suite passes (88/88), and the working tree is unchanged; my scratch tests are deleted.

Medium

1. The previous owner can overwrite the current owner's key at any time (src/ArtifactsPiece.sol:137). After an escrow sale completes, the seller still counts as the previous owner and can replace the key the buyer paid for, as often as they like. The same applies after a plain transfer. Four specialists reported this; I merged them into one finding. One specialist's proof test fails on the current code for that reason, and I attached it.
2. One wrong contentHash makes a collection unsellable for good (src/ArtHouse.sol:284). clearPiece resets the piece's size and chunks but not its hash, and a piece ID can only be registered once. So a mistyped hash means the piece can never be finalized, the collection can never be sealed, and its sale can never open. I confirmed this with a scratch test. Three specialists reported it; merged.

Low 3. Revoking an artist doesn't stop them from registering, uploading or finalizing pieces in their existing collections (ArtHouse.sol:242). Combined with finding 2, a revoked artist can block a collection on purpose. Confirmed with a scratch test. 4. A seller can post an empty escrow key (ArtifactsPiece.sol:182). That ends the buyer's right to cancel, and after 72 hours anyone can release the payment to the seller. The factory's equivalent function rejects empty keys. Confirmed by the specialist's proof test. 5. THE SOURCE's 5% minimum raise rounds down to zero when the high bid is under 20 wei, so a bid equal to the high bid wins (ArtifactsSource.sol:127). This only matters if the curator sets a reserve that tiny. Confirmed with a scratch test. 6. If Chainlink never answers a randomness request, there is no way to re-request or refund (ArtifactsFactory.sol:161). The buyer has paid, gets no edition, and the slot still counts as sold. I confirmed this by reading every factory entry point, not with a test.

Info 7. A piece contract accepts an all-zero viewing key, which the factory rejects. Only the owner who registers it is affected. 8. Trust assumption, not a defect: the curator can change a collection's revenue split after bids are placed, because the split is read when the sale is recorded.

Dropped or checked and fine

• I dropped the base64 dirty-memory issue. It only reproduces when the library is called directly, and the specialist found no failing input through the real tokenURI functions.
• None of the static-analysis warnings held up against the code.
• All deployed contracts fit the size limits. The size warning comes from the Deploy script, which isn't in the manifest.
• The manifest's constructor arguments match the brief, including the IMD address.

The responses file is excluded by the harness's own .git/info/exclude, so it is read from the working tree by design. The revision is complete.

Outcome. All eight findings reproduced and are answered in .imd-responses.json. Seven are fixed in code or docs. The rewrap-overwrite finding is fixed too, but its proof is disputed on form only.

What changed

• src/ArtifactsPiece.sol: release clears the previous owner's re-key right. rewrapFor is one shot, refuses an empty key, and clears the right after posting. postEscrowKey refuses an empty key. registerViewingKey refuses a zero key.
• src/ArtHouse.sol: a revoked artist loses curation rights over existing collections. New updatePiece lets the curator or approved artist correct an unfinalized piece's hash, title and description without losing uploaded chunks.
• src/ArtifactsSource.sol: the 5% minimum raise rounds up, so every bid strictly exceeds the high bid.
• src/ArtifactsFactory.sol: owner-only rerequestRandomness for a request unanswered for 7,200 blocks. The old id is forgotten so a late callback cannot award a second edition.
• README: documents all of the above plus the split-at-sale-time trust assumption.
• Tests: seven new tests across the three suites covering each fix's success and failure paths.

Why the proof is disputed. The finding says the expected result is a revert with NotPreviousOwner and an unchanged key, which is what the code now does. The proof calls the seller's late rewrapFor without expectRevert, so it can only pass if an unauthorised call silently succeeds as a no-op. I kept the revert and explained this in the response. A copy of the proof with that one expectRevert added passes.

Verification. forge build, forge fmt --check, and the 46-test suite with the verifier's fuzz seed all pass. The verbatim proof now fails only with NotPreviousOwner, the behaviour the finding asked for.

The manifest needed no change: launch.json as accepted still describes the current tree exactly, and I left it byte-identical.

What I verified

• Constructors match. The latest contributor commit (c00dccf) added rerequestRandomness, updatePiece and one-shot re-keying but touched no constructor. The five entries still line up with the signatures: ArtStorage(owner), ArtHouse(owner, ArtStorage, IMD), ArtifactsPiece(), ArtifactsFactory(owner, ArtHouse, ArtifactsPiece), ArtifactsSource(owner, ArtHouse, ArtifactsPiece). The deploy script in script/Deploy.s.sol wires them the same way.
• Schema shape. A script checked that the file has only kind, contracts and notes, that names are unique identifiers under 32 characters, that every argument is a string that is $owner, a backward $contract: reference or a static address, and that notes are a string of 1,605 characters.
• Floor rehearsal. A scratch test in test/scratch/Manifest.t.sol deploys the five contracts from a stand-in factory in manifest order with the manifest's arguments, then replays the protected checks: every runtime is present and under the EIP-170 limit, has no DELEGATECALL, CALLCODE or SELFDESTRUCT outside push data, and every owner is the curator rather than the factory or IMD. It also confirms the storage, IMD and piece-implementation wiring and that the piece implementation is locked.
• Full suite. forge build succeeds with lint warnings only. forge test with the verifier's fuzz seed passes all 49 tests, including the two split-invariant fuzz tests, the VRF assignment over all 255 editions, escrow, auction, reveal and the byte-for-byte revealed tokenURI.

Working tree. git status is clean apart from my scratch test, which is discarded before submission. No configuration, library or source file was touched.

The revision is complete: all 100 tests pass with the verifier's fuzz seed, and only files under test/ changed.

What was wrong. The implementation changed after my suite was accepted, and three of my tests encoded the old rules:

• A unit test expected the paid seller to re-key the piece after an escrow release. The release now spends that right, so the test asserts the delivered key stands and both a garbage and an empty re-key are refused.
• The escrow handler assumed re-keys were repeatable and unbounded. It now derives success from the new rules (previous owner only, empty slot, non-empty key, right spent on use), checks that a refused re-key changes nothing, and expects zero viewing keys and empty escrow keys to be rejected.
• The auction handler computed the minimum raise rounding down. It now uses the round-up formula, with the validity check written independently of it so the two cannot agree by construction.

What was added.

• Re-request edges in the adversarial suite: the retry window is exact to the block, the same old id cannot be re-requested twice, a re-request can itself be re-requested after another full window, forgotten ids never fulfil, and sold, remaining, the ledger balance and the buyer's edition count stay fixed. A second test uses a new switchable coordinator mock to show a reverting re-request leaves the original request intact and retryable.
• The factory invariant handler now re-requests pending purchases, both too early and after the window, and tries it as a stranger. The count invariant also checks every pending id still maps to its buyer with no edition.
• A fuzzed property that the minimum raise is the exact ceiling of 105% of any high bid, one wei less is refused, and it always strictly exceeds the high bid.
• Update-piece access edges: an empty collection, an approved artist of a different collection, a pending owner, and a revoked artist are all refused, while the event carries the corrected values and the curator can still finish the piece.

Every handler action is reached with no reverts across 96 runs of 60 calls. I found no defect that had to be reported rather than tested, so no findings file was written. Fork runs against the live Sepolia coordinator and IMD token remain owed, as before.

All 75 entry points have a row, the tree is clean apart from the findings file, and the scratch tests are removed.

Outcome: every finding from my previous round is fixed, and I found no new defect. The findings file holds an empty list and a 78-row coverage record.

Settlement of my earlier findings, each re-run against the revised code:

• Seller keeps rewrapFor rights after release (medium). Fixed. release() now deletes previousOwner, and rewrapFor is one-shot and non-empty. The attached proof now fails only because the seller's call reverts NotPreviousOwner, which is the behaviour the finding asked for, so the author's dispute about the proof's assertion form is correct. The wrapped key stays rewrapped-for-bob.
• Wrong contentHash permanently strands a collection (medium). Fixed by the new updatePiece. I reproduced the typo, correction, finalize and seal path, plus the Finalized, Sealed, NotCurator and BadPieceId failure paths.
• Revoked artist keeps curation rights (low). Fixed. The artist path in the shared guard now requires approval. Register, upload, update and finalize all revert for a revoked artist, and re-approval restores them.
• Empty escrow key accepted (low). Fixed. postEscrowKey("") reverts and the buyer can still cancel.
• 5% raise rounds to zero under 20 wei (low). Fixed. Equal bids of 19 and 20 wei revert, and the 1 ether to 1.05 ether threshold is unchanged.
• Unfulfilled VRF request has no recovery (low). Fixed by owner-only rerequestRandomness after 7,200 blocks. The old id is rejected afterwards, a second re-request of the same id reverts, and exactly one edition is assigned with sold unchanged.
• Piece accepts a zero viewing key (info). Fixed.
• Split read at sale time (info). Documented in the README trust section as agreed.

Other checks this round: the full suite passes with 100 tests, every runtime is under the EIP-170 limit with the largest at 18,537 bytes, and the manifest's five contracts and constructor arguments match the code. The slither and aderyn leads traced to intended behaviour, so none became a finding.