The Sellout Machine

Implemented and documented in README.md.

• Build and formatting checks passed.
• 46 local tests and 11 actual mainnet-fork tests passed.
• Independent AI security review found no reproduced vulnerability.
• Deployment handoff, gas benchmarks, and Etherscan instructions included.

Vessel’s existing SVG renderer requires 422–471 million gas, which may exceed RPC limits.

Mainnet deployment, Etherscan verification, and GitHub publication remain pending IMD’s launch pipeline. No live Craft attachment was made.

I found no math defects I could back up in src/SelloutMachine.sol, so .imd-findings.json has an empty findings list plus coverage rows. I read the code and wrote no test files; the existing tests and the mainnet-fork tests were not run in this review.

What I checked and why it holds:

• setTrackedCollection(address) (the only entry point): every check runs before anything is stored. It requires the owner as caller, then a non-zero address that has code, the ERC-165 and ERC-721 interface checks, and a totalSupply() reply that is exactly one 32-byte word. There is no arithmetic on this path.
• Payload bounds: the count is capped at 10,000. The 32-byte fill loop only runs while cursor + 31 < end, so its last write ends at or before the payload's end. A byte-by-byte loop handles the remaining 0–31 bytes. So the payload is always exactly 10,000 bytes and nothing is written outside it.
• Pixel boundaries: byte i is black (0x00) exactly when i < count. This is exact for the brief's examples: 0, 1, 100, 101, 5,000, 9,999 and 10,000.
• mintProgress: it returns the capped count directly. One NFT is one basis point of 10,000, so there is no division and no rounding.
• Bad supply replies: a failed call, or a reply that is not exactly 32 bytes, returns 0 (all white). A huge value, including the largest possible uint256, is capped at 10,000 without overflowing.

Two things I noted but did not report, because neither has a concrete failure against the brief:

• If a collection's totalSupply() needs more than the 100,000 gas allowed for the call, or the caller supplies too little gas, the grid silently shows all white instead of reverting.
• A collection that returns more than 32 bytes from totalSupply() is treated as broken, which is the intended "reject malformed replies" behaviour.

The static-analysis lead (aderyn's "large numeric literal" at line 10) is only about how 10_000 is written as a constant. It has no effect on behaviour.

Review complete. The findings file is written and validated, snippets match the tree, and the scratch directory is removed so no tracked file changed.

Outcome: the permission model of SelloutMachine.sol holds. No critical, high or medium defect in the Access Control, Trust Gap or Asymmetry areas. Two low findings are recorded in .imd-findings.json.

What I verified

• Only the immutable owner can call setTrackedCollection. The factory, tx.origin, and any callee reached during validation are rejected, and all probes are STATICCALLs, so no re-entry or log fabrication is possible.
• Failed selections are atomic and leave the previous collection intact. There is no transfer, renounce, initializer, proxy, DELEGATECALL, SELFDESTRUCT, receive or fallback path.
• The read path degrades to white on reverts, bombs, short or long replies, state-writing or recursive callees, so Vessel's tokenURI never reverts for Craft #10000.
• Byte encoding and ordering match the mainnet renderer source: grayscale mode writes rgb(v,v,v) at (i % 100, i / 100), so 0x00 is black and 0xff is white.
• The full existing suite passes with 46 tests and 0 failures.

Findings (both low)

1. Gate asymmetry at the ERC-165 ceiling. The three interface probes forward exactly 30,000 gas, the ERC-165 allowance for the callee itself. Behind a beacon or EIP-1967 proxy, the proxy's own overhead comes out of that budget. A compliant implementation measuring about 21k gas directly was accepted, but the same implementation behind a beacon proxy measured about 31k and was rejected with InvalidCollection. Uncommon precondition, owner-only impact, but it contradicts "change the collection anytime" for that class of collection.
2. Deployment guidance uses $owner for a brief-stated owner. The launch recipe says a brief-stated owner is written as the static address. If $owner resolves to a paying wallet other than the named one, the immutable owner is wrong with no recovery path. This is in the docs and the pending manifest, not in the contract logic.

Coverage: the one listed entry point, the constructor, all four view functions, and two trust-assumption rows are recorded. Nothing in my area was left unreached.

Review complete. The findings file is written and validated, the scratch directory is removed, and the working tree holds no other changes.

Outcome. No defect in the economic, invariant, or flow-gap area was found in src/SelloutMachine.sol. I report one informational documentation gap and nine coverage rows.

What I checked against the three guides

• Economic Security. The contract holds no value, has no payable path, and its only dependency is a view read of the tracked collection's totalSupply. Every dependency failure mode (revert, short or long reply, return or revert bomb, infinite loop, state write, removed code) degrades to a white image and recovers automatically. Nothing can be stranded or extracted.
• Invariant. Pixel i is black exactly when i is below the clamped supply, the payload is always 10,000 bytes, the ABI padding stays zero, and progress in basis points is an identity with no rounding. I confirmed the renderer places byte i at column i mod 100, row i div 100, with grayscale mode 0 as rgb(v,v,v).
• Flow Gap. I probed three seams with scratch tests. An underfunded outer call reverts rather than returning a wrong image. A delegatecall proxy collection selects and reads correctly under the cold 30k and 100k budgets. A collection with an O(n) totalSupply loop falls to white once past the budget, which is the documented limitation and matches no common ERC-721 implementation.

Live evidence. Thirteen major mainnet ERC-721 collections (BAYC, Azuki, Doodles, Pudgy Penguins, Milady, CloneX, Moonbirds, Cool Cats, World of Women, Nouns, Autoglyphs, Chromie Squiggle, Meebits) pass all four selection gates with totalSupply reads of roughly 2,700 to 4,800 gas.

The one finding (info). The Vessel itself is a plain OpenZeppelin v5 ERC721 without totalSupply, so the owner calling setTrackedCollection with the Vessel address reverts with InvalidCollection. This follows the brief, but neither the README nor the deployment guide says that the Vessel, Manifold, Art Blocks, or CryptoPunks contracts are rejected. A sentence in each would prevent a confusing first Etherscan attempt.

Not reached. No mainnet-fork run was executed by me. I relied on the integration test source, the saved verified Vessel and renderer code, and live read-only calls to the Vessel for the selection gates.

Review complete. The findings file is written and validated, the scratch tests are removed, and the tree is otherwise unchanged.

Outcome: no exploitable defect in SelloutMachine.sol. I traced the Execution Trace, Periphery and First Principles guides against the contract and found the control flow sound. Two low-impact items are recorded in .imd-findings.json.

What I verified

• setTrackedCollection checks the owner first, then zero address, code presence, three bounded ERC-165 reads and one 32-byte totalSupply read, all via STATICCALL, before a single state write and the event. A failed selection leaves the previous collection intact, and an owner-contract callback cannot re-enter from the static context.
• craftToPayload clamps the count before using it as a memory offset. Both fill loops stay inside the 10,000-byte buffer at every alignment, including counts 0, 9968, 9969 and 10000. The ABI return is exactly 10,016 padded bytes.
• The read helper copies at most one word into scratch space, requires success and an exact 32-byte reply, and compares booleans canonically. I added a probe confirming a 32-byte revert reads as zero and a same-address reselect emits the event.
• Vessel periphery: Vessel routes Craft #10000 straight to the attached Machine with tokenId 10000. The renderer builds a 100x100 grid, places byte i at (i%100, i/100) and writes rgb(v,v,v) in grayscale mode, so 0x00 is black and 0xff is white. The renderer calls name() inside try/catch.
• Live state through the mainnet endpoint: the lock clock has not started, the stated owner holds Craft #10000, and no delegate is set.
• Fork re-run against the real Vessel at block 26,200,148: the four routing and payload tests plus the SVG-101 render passed with gas figures identical to the recorded run. The default suite of 46 tests also passed.

Findings recorded

1. Low, docs/deployment.md line 16. The handoff tells the manifest step to pass $owner, while the pinned launch recipe says a brief-stated owner is written as the static address. The owner is immutable with no transfer path, so a $owner resolving to a different paying wallet would leave the intended wallet locked out permanently.
2. Info, src/SelloutMachine.sol line 63. A caller whose gas budget sits just under an expensive collection's totalSupply cost gets a successful all-white payload rather than a revert. Reproduced with an 85k-gas collection and caller budgets of 86k to 95k. This follows from the documented white fallback and needs documentation only.

Coverage: 10 rows, including the single listed entry point as holds. One row is unreached: I did not survey mainnet collections for ones whose supportsInterface(0xffffffff) reverts or exceeds 30k gas, and I did not re-run the six remaining SVG fork tests beyond the one I chose.

The review is complete. The findings file is written at the repository root, the working tree has no other changes, and the scratch tests were removed.

Outcome: the contract itself holds. All 65 offline tests pass, the payload and pixel logic trace correctly against the saved Vessel renderer, and the single state-changing entry point is sound. One substantive finding survives, in the manifest rather than the Solidity.

Findings kept (3):

• Medium, launch.json line 6. The manifest writes $owner even though the brief states the owner address. The pinned launch recipe says a brief-stated owner is written as the static address. The owner is immutable with no transfer path, and the protected Owners floor only rejects the factory or IMD, so a $owner that resolves to the paying wallet deploys a permanently wrong owner. The two specialist reports on this were merged into one. The fix is the static address in constructorArgs plus matching text in the deployment doc and README.
• Info, src/SelloutMachine.sol line 12. The three ERC-165 probes forward exactly the 30,000-gas ceiling with no margin. I reproduced the specialist's case: the same implementation is accepted directly at 21,423 gas and rejected behind a beacon proxy at 31,580 gas. Strictly the proxied contract exceeds the ERC-165 ceiling, so this is a boundary note, not a defect.
• Info, README.md line 40. The Vessel itself has no totalSupply() in its verified source, so it is rejected as a tracked collection, and the docs never say so.

Dropped: the audit_flow claim that a gas-starved craftToPayload returns an all-white image. My scratch run showed the starved payload call reverts at every budget below the supply cost. Only mintedCount returns zero there, which the README already documents as the failure policy.

Coverage: setTrackedCollection(address) holds. Additional rows record the constructor and manifest (finding 1), payload generation, supply reads, the staticcall helper, and factory deployability, all holding. The static-analysis line about large numeric literals is style only and was left out.

The revision is complete.

Finding reproduced and fixed. A scratch test confirmed that deploying SelloutMachine with any constructor argument other than the brief-named wallet permanently locks that wallet out of setTrackedCollection, since the owner is immutable with no transfer path. The pinned recipe directs that an owner address stated in the brief be written as a static address rather than $owner.

Change made. Only launch.json changed. Its single constructor argument is now the static address 0xCcf0a1307E5e5Ad04E85d94d7f9D400390F0118a, and the notes explain why the static form is used and state that it supersedes the $owner wording in README.md and docs/deployment.md. Those two docs are outside the paths this assignment may modify, so they were left alone and the response file says so.

Verification.

The answer to the finding is recorded in .imd-responses.json with verdict fixed. The scratch test lives in test/scratch/ and is gitignored, so nothing else enters the submission.

The review is complete and written to the findings file. Nothing blocks this launch.

Settled finding (fixed). The medium finding about the manifest passing $owner is closed. launch.json now writes the brief-stated owner address as a static constructor argument. I reproduced the author's check with a scratch test: constructing with that exact argument gives the named wallet exclusive authority over setTrackedCollection, and an unrelated wallet is rejected. The manifest is schema-valid with one argument for the one constructor parameter and notes well under the limit.

Advisories carried over unchanged. The contract source did not change between rounds, so both info items still reproduce and remain non-blocking:

• ERC-165 probes forward exactly the 30,000-gas ceiling, so a heavy but compliant implementation behind a proxy is rejected while the direct deployment is accepted.
• The Vessel itself has no totalSupply and is rejected as a tracked collection, and the docs never say so.

Residual documentation drift. README and docs/deployment.md still describe the constructor argument as $owner. The manifest notes state the static address supersedes them, and the author could not edit those files within the manifest assignment's write budget. I recorded this inside the settlement entry rather than as a new finding.

Verification run. The full offline suite passed with 68 tests and no failures under the pinned fuzz seed. The protected floor harness is not shipped in the tree, so I checked its properties by hand: single nonpayable address constructor with no external calls, 1,555 creation bytes, 1,384 runtime bytes, and no DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT in the runtime. The slither output was empty and the aderyn large-literal lead is cosmetic, so neither produced a finding.

Coverage marks the one listed entry point, setTrackedCollection, as holding, plus rows for the constructor, payload and count functions, and the manifest. Scratch tests were removed and the tree has no other changes.