Implemented SeedClock, royalty distribution, animated on-chain art, deployment script, tests, and documentation.

Passed forge build, all 56 tests with the supplied fuzz seed, and forge fmt --check.

README and deployment handoff

Mainnet deployment, final addresses, and explorer verification remain with IdentityMD’s launch service.

I found two medium-severity problems in how the royalty money is shared out. Both are reproduced with Foundry tests and written to .imd-findings.json, along with a coverage row for all 15 entry points and two invariants I checked. The working tree is unchanged; I deleted my scratch tests and embedded the one that proves finding 1 in the JSON.

1. Claiming gets more expensive with every receipt ever recorded (src/RoyaltyDistributor.sol:209, medium)

• Mechanism: every payment of at least one wei per token adds a receipt. Each claim reads receipts one by one, 64 per transaction, and every address starts at receipt 0.
• New holders pay for history: someone who buys or mints after 640 receipts gets 0 from their first claim and spends about 410k gas. They need 10 claims before any payout. The embedded test fails on this.
• Small holders can't afford to claim: each receipt costs about 6.4k gas to process. At 20 gwei, a one-token holder only breaks even on royalties from sales above roughly 10 ETH. Below that, the gas costs more than the payout, so most of the money stays in the contract for good (there is no sweep, by design).
• Anyone can make it worse: sending 5,555 wei at full supply (about 102k gas) adds a receipt that every holder then has to process.
• Fix: the brief suggested a running per-token total, which makes each claim cost the same regardless of history. At minimum, start each holder's position at the first receipt after they first held a token.

2. WETH royalties are split by who holds tokens when someone syncs, not when they were earned (src/RoyaltyDistributor.sol:129, medium)

• ETH royalties are recorded the moment they arrive. WETH royalties (for example from accepted OpenSea offers) are only recorded when someone calls syncToken.
• While the public mint is open, minting is free, and one IMD can be passed through many wallets. So someone can mint new tokens right after a WETH royalty lands, then sync in the same transaction.
• In the test, 57 tokens existed when 6.9 WETH arrived. 20 wallets sharing one IMD minted 100 more and then synced. They could claim 4.39 WETH, and the treasury (55 tokens) got 2.42 WETH instead of about 6.66.
• The brief does allow "current balance (or snapshot at claim time)", so whether this counts as a defect depends on what was intended. Even so, the ETH path was deliberately built to stop new mints taking earlier royalties, and WETH doesn't get that protection.

Checked and holding:

• Royalty accounting: money in equals what's owed, and receipts line up with the ownership snapshots. Leftover wei from each payment goes to whoever holds token 1. ETH sent back into the contract during a claim is accounted correctly, and a holder that refuses ETH can't block anyone else. The binding window only opens during the one-transaction deployment.
• SeedClock: 690 bps always goes to the distributor, and royalty enforcement can't be switched off. The mint keeps the supply cap, the five-per-wallet limit and the IMD check, and it can't be re-entered.

Not reviewed: the art libraries, including the static-analysis leads in SeedArt and SeedData. I also didn't check on mainnet that OpenSea's registry and signing zone enforce the 6.9%; the project's own tests only run the registry's code offline.

Created launch.json with both contracts in dependency order, matching constructor ABIs and using $owner for treasury.

forge build succeeded. All 56 tests passed with the specified fuzz seed. Only launch.json is changed for submission.

The review is complete. The findings file is written and validated, both proof tests fail on the current code for the stated reasons, and no repository file outside the scratch area and .imd-findings.json was touched.

What I covered I applied the Math Precision, Boundary and Numerical Gap guides to RoyaltyDistributor, SeedClock, SeedData and SeedArt. I traced every division, remainder, cast and coordinate computation, the checkpoint binary search, the receipt conservation invariant, every external call and sentinel branch, and verified on mainnet via RPC that IMD has 18 decimals so the one-whole-IMD mint threshold is correct. The lrand48 skip-ahead, the published seed vectors and the SVG coordinate bounds all hold. The existing 56-test suite passes.

Findings written to .imd-findings.json (6 findings, 20 coverage rows, all 16 entry points answered)

1. Medium, with proof. Receipt queue griefing in RoyaltyDistributor._record. Anyone can append a receipt for 56 wei. Receipts must be paged in order, 64 per claim. Measured: 2,560 spam receipts cost the spammer about 143M gas once, then every holder needs 41 claim transactions and about 17.8M gas to reach a real royalty. Late joiners pay the same cost even without an attacker.
2. Medium, with proof. A plain transferFrom to the distributor's own address is accepted, and the token's share of every future receipt is credited to an address no claim variant can pay. ETH is stranded permanently and grows with each royalty.
3. Low. ERC-20 royalties snapshot at sync time, so free mints after a WETH royalty lands capture a share of it. The ETH path explicitly prevents this. Documented as an ordering caveat, so reported as an asymmetry.
4. Low. The per-receipt remainder goes entirely to token 1's holder. For low-decimal assets that is up to 5,554 base units per receipt, which for an 8-decimal token is real money and can be the whole receipt.
5. Low. RoyaltyReceived emits a receipt index for dust receipts that are never stored, so the index is reused by the next real receipt.
6. Info. royaltyInfo floors the fee where the checklist expects fees to round up. Impact is at most 1 wei per sale.

Not reached in depth The transfer-validator policy semantics and OpenSea zone behaviour are outside my area and were only checked for math and boundary effects.

The review is complete and written to .imd-findings.json at the repository root. No source or config files were changed.

Scope covered. I traced the Execution Trace, Periphery and First Principles guides against SeedClock, RoyaltyDistributor, the two art libraries, the deploy helper and the test suite. Build and all 56 existing tests pass. I confirmed on mainnet via a public RPC that IMD has 18 decimals and that the strict validator's codehash and default OpenSea SignedZone authorizer match the offline fixture. The published lrand48 seed vectors from the Anthropic report were not independently verified.

Findings (3), all reproduced with scratch tests:

1. Medium. Claim cost is linear in the global receipt log. Every OpenSea sale appends a receipt, and every new holder starts paging from receipt 0 even though they are owed nothing from the past. Measured: after 6,400 receipts a fresh holder needed 101 claim calls and 39M gas before their first payout. Anyone can inflate the queue for 5,555 wei and ~56k gas per receipt. Per-token royalties per sale are small enough that a one-token holder loses money claiming on sales under roughly 3 ETH at 5 gwei. Fix: an accumulator settled in updateShares, or at minimum a per-holder starting cursor.
2. Low. A token transferred to the distributor locks its royalty slice forever. Plain transferFrom to the distributor passes the owner-gift rule and skips the receiver hook. The distributor then holds a share it can never claim, since claims to self are rejected, and the token cannot leave.
3. Info. The RoyaltyReceived event reports a receipt index that does not exist for dust receipts, colliding with the next real receipt's index.

Coverage. All 16 listed entry points have a row, plus four invariant and periphery rows. Mint, both safeTransferFrom overloads, approvals, bindCollection, syncNative and syncToken hold. The claim variants, receive, updateShares and transferFrom carry finding references. No critical or high findings, so no proof files were attached.

I added two test files. The full suite passes with the verifier's fuzz seed: forge build is clean and forge test runs 84 tests with 0 failures, up from the 56 that were there. I also found one medium and two low defects, which are in .imd-findings.json instead of being blessed by tests. I changed nothing outside test/.

test/Adversarial.t.sol (27 tests, mostly failure paths):

• Mint checks: the quantity check runs before the IMD lookup, type(uint256).max can't overflow anything, and mint fails safely when IMD's balanceOf reverts or returns nothing. Only the caller's own IMD counts.
• Per-wallet limit: five single mints, a batch that would cross the limit (no partial fill), and the treasury gets no extra allowance.
• Supply cap: fills to exactly 5550, then 5553, then shows that batches over the cap are rejected and the last 2 tokens still mint. The wallet limit is checked before the sold-out check.
• Royalty discovery: the Limit Break interface id 0xad0d7f6c, ERC2981, the validator selector 0xcaee23ea and the validator address; nobody can call setTransferValidator.
• Royalty split: rounding at small sale prices, dust going to whoever holds token 1, and the claim-page boundary at exactly 64 and 65 receipts.
• Distributor failure paths: claiming with nothing owed, claiming the same receipt twice, claimFor(0), share updates from anyone but the collection (all reverts), the binding can't be reopened later, and syncing a non-contract or zero-balance token.
• Fuzz tests: share history checked against recorded balances, and a single payment split exactly and fully across holders.

test/DeepInvariant.t.sol drives random call sequences with 5 holders and an approved operator: 48 runs, 160 calls each, no reverts. Unlike the existing invariant suite, sequences go past one 64-receipt claim page. They also include ETH forced in without a sync (and later bundled into a payment), operator transfers both allowed and refused by the validator, and claims paid to a different address. The checks:

• the distributor's ETH and token balances always equal what holders are owed (plus any ETH not yet synced);
• every successful claim pays exactly what an independent model says is owed;
• nobody receives more than they earned;
• shares always match NFT balances;
• supply never goes down or past 5555;
• the royalty settings and validator never change.

Before relying on two constants, I checked mainnet: IMD has 18 decimals (so "1 IMD" is 1 ether in raw units), and the deployed validator's codehash matches the test fixture.

Findings in .imd-findings.json:

• Medium — claim cost grows with the number of royalty payments. A claim walks through payment records from the holder's last claim, and for a new holder that means from the very first record. Someone who mints after 640 payments needs 11 claims (about 4.7M gas) before they get the 5 ETH they actually earned. At full supply, processing one payment costs more gas than a 1–5 token holder earns from it. The finding includes a test that fails on the current code. The existing test test_zeroEntitlementBatchCanAdvanceToLaterEarnedReceipts asserts this behaviour and would need updating along with a fix.
• Low — receiving a royalty costs about 109k gas (177k for the first one). A sender that forwards only 2300 gas, as transfer()/send() do, reverts. OpenSea's Seaport forwards all gas so its sales go through, but each buyer pays the extra.
• Low — royalties are locked for tokens held by the distributor or the SeedClock contract. Those tokens keep earning a share that nobody can ever claim.

Still not covered: OpenSea's actual signed royalty approvals and the other live contracts on mainnet. That would need a test against a mainnet fork, which these offline tests can't run.

Review complete. The findings file is written and validated, the scratch tests are removed, and the working tree has no other changes.

Outcome: no critical, high or medium defects in the access-control, trust-gap and asymmetry areas. The permission model is tight: neither contract has an owner, the distributor binds once inside the deployment transaction via a transient-storage window, share updates are collection-only, and every claim path pays only the entitled holder. I confirmed on mainnet that IMD has 18 decimals and that the validator codehash matches the fixture, so the hard-coded assumptions in the mint gate and transfer hook hold today.

Findings written to .imd-findings.json (3 low, 2 info), each with a reproduction I ran against the code:

• Low, stuck shares. A plain transferFrom gift (which the registry allows) can park a token in the distributor or the collection itself. Those shares accrue royalties nobody can claim, since claimFor to the distributor reverts and SeedClock cannot receive ETH. Verified: 1 ETH of a 56 ETH receipt locked forever.
• Low, ETH versus WETH asymmetry. ETH royalties snapshot at receipt, but WETH royalties (every accepted OpenSea offer) snapshot when anyone calls syncToken. A wallet can mint five tokens for free then sync and take a share of WETH earned before it held anything. Verified: later minter gets 0.46 WETH and 0 ETH from identical 6-unit royalties.
• Low, cursor griefing. New holders page through every receipt from index 0, and anyone can push a receipt for 5555 wei. Verified: 640 spam receipts cost a late holder 10 claim calls and about 4M gas for zero payout.
• Info, registry trust. Marketplace transfers depend permanently on OpenSea's authorizer with no fallback, since setTransferValidator always reverts. Verified with real registry bytecode: after an authorizer rotation, operator transfers revert forever while royalty-free owner gifts continue.
• Info, dust rule. The per-receipt remainder goes to token 1's holder (the treasury), which is non-proportional and only material for low-decimal royalty assets.

Coverage: all 16 listed entry points have a row (12 hold, 4 reference findings), plus three invariant rows. Nothing was left unreached. Art rendering and seed derivation were outside my area and not reviewed beyond the static-analysis leads, which produced no reportable defect.

Review complete. The findings file is written at .imd-findings.json with 7 findings and 17 coverage rows, and no repository file was changed (the findings file is gitignored and test/scratch/ is my scratch area).

What I verified

• The project builds and all 84 of its own tests pass. Runtime sizes are 21,081 and 5,595 bytes, under the 24,576 limit, with no forbidden opcodes.
• All four specialist proof tests fail on the current code for the stated reasons. I reran each one.
• Every non-proof specialist claim I kept was reproduced in a scratch test: ERC-20 sync-time capture, event index reuse, the 2,300-gas receive failure, the low-decimal remainder, and stranding via the collection address.
• My own pass over the entry points found nothing new. The constructor handshake, mint checks, authorization ordering, checkpoint/revision consistency, claim reentrancy, and manifest arguments all hold.

Findings reported, after merging duplicates

1. Medium. Claim cursor starts at receipt 0 and the queue is append-only and permissionlessly growable, so claims cost gas proportional to all receipts ever recorded. Five specialists reported this. Proof attached: a late minter's first claim returns 0 instead of 5 ether.
2. Medium. Plain transferFrom to the distributor or the collection credits shares no claim path can pay, permanently locking that slice of all future royalties. Four specialists reported this. I attached a proof that also passes if the fix rejects the transfer.
3. Low. ERC-20 royalties snapshot at sync time while ETH snapshots at receipt, so free mints after a WETH royalty lands capture it.
4. Low. The receive function costs about 104k gas and reverts for stipend-only payers.
5. Low. The per-receipt remainder goes entirely to token 1's holder, which is material for low-decimal tokens.
6. Low. The RoyaltyReceived event reuses receipt indexes for unstored dust receipts.
7. Info. Trust assumption: marketplace transfers depend permanently on OpenSea's registry with no rotation path.

Dropped: the royaltyInfo floor-rounding note, since the impact is at most 1 wei per sale. The slither and aderyn leads were all benign on inspection (intentional integer grid math, zero-initialized locals, a constructor call to the trusted distributor).

Both medium findings reproduced and are fixed. forge build, forge test and forge fmt --check all pass, using the verifier's fuzz seed. The tests are 64 of 64 green, counting the two reviewer proofs and one gas-measurement test of mine in test/scratch/. The stateful invariants also pass at a heavier 512 runs × depth 128. Every finding has an answer in .imd-responses.json. I didn't commit anything.

Medium findings

• Claim cost grew with every receipt (proof 175459b5f1ac): each receipt now stores a running per-token total. A claim works through each stretch where the holder's balance didn't change, with two binary searches per stretch, so its cost no longer depends on how many receipts exist.
  • The proof's late holder gets the 5 ether on the first claim.
  • A new test with 1,000 earlier receipts pays out in one claim of under 200k gas. Spamming tiny receipts no longer costs holders anything to claim through.
  • The per-call limit is now 64 balance changes instead of 64 receipts. Only a holder whose own balance changed more than 64 times needs more than one call.
• Shares stranded on the distributor or SeedClock (proof 6c7c6cbaaef8): transfers to either contract now revert with ERC721InvalidReceiver. This covers both transferFrom and safeTransferFrom, and a new test checks both.

Advisory findings

• WETH royalties captured by later minters: fixed. Before any mint or transfer, the distributor first records any mainnet WETH that has arrived. A mint or purchase made after WETH lands can no longer claim part of it. I confirmed the WETH address against the reference and on chain.
• Remainder sent to token 1's holder: fixed. The leftover from each split now carries into that asset's next receipt instead of going to one wallet. It is always less than one unit per token (undistributed(asset)), and the invariant tests cover it.
• Same event index reported twice: fixed. An amount too small to create a receipt now reports NO_RECEIPT as its index.
• receive() fails with the 2,300-gas stipend: disputed. Recording ETH immediately is what stops later minters from claiming earlier royalties, and Seaport forwards all gas. The cost did drop, from about 104k to about 83k gas per receipt.
• Permanent dependence on OpenSea's validator: disputed as a defect. It is the intended trade-off of having no owner, pause or upgrade, and docs/SECURITY.md now spells it out.

Things to know about this revision

• Event signature changed: RoyaltyReceived fields are now ordered (asset, amount, receipt, revision). With the extra WETH call, the compiler moved the old event's hash into a data section at the end of the code. That hash contains a 0xff byte, which the launch's opcode scan reads as SELFDESTRUCT and refuses. The new order's hash has no such bytes. This is fragile: a future code change could push another constant there, so re-run the opcode scan test after any edit.
• Public interface changes: roundingCredit, firstTokenOwner and MAX_CLAIM_RECEIPTS are gone. MAX_CLAIM_SEGMENTS, NO_RECEIPT, WETH and undistributed are new. receipt() now returns (revision, perToken, cumulative). Any website or indexer built against the old names will need updating.
• Docs and tests: README.md, docs/SECURITY.md and docs/SITE-HANDOFF.md describe the new accounting. I rewrote the existing tests that asserted the old rounding and pagination behaviour.

Done. Only launch.json changed.

What I checked

• The accepted source's constructors still match the manifest. RoyaltyDistributor takes one address, the treasury. SeedClock takes the treasury and the distributor address. The brief names no treasury wallet, so both receive $owner, and SeedClock's second argument is $contract:RoyaltyDistributor, keeping constructor dependency order.
• Neither contract exposes an owner role. The distributor records the factory only as the expected deployment caller for its one-time constructor binding, which is not an ownership or admin power.
• The protected deployment probe deploys both contracts in one call, so the constructor handshake between SeedClock and the distributor holds there as it does on chain.
• The build passes and all 61 tests pass with the verifier's fuzz seed, including the three stateful invariants.
• A local schema check confirms the manifest has only the three allowed keys, unique identifiers within 32 characters, string arguments with backward-only contract references, and notes under 4000 characters.

What I changed

The latest accepted source commit reworked the distributor's accounting, so the previous notes described behavior that no longer exists. I rewrote the notes to match the current implementation: rounding remainders are now carried into the asset's next receipt instead of paid to token 1's holder, mainnet WETH is synced before every mint or transfer, other ERC-20s snapshot on a public sync call, claims settle at most 64 balance segments per call, and the binding handshake now also verifies the deployment caller. The contract entries and constructor arguments are unchanged.

My tests had stopped compiling because the distributor was rewritten. I've updated them to the new accounting, and the full forge test now passes with the verifier's fuzz seed: 92 tests across 8 suites, none failing. I found no defect in the new code, so I didn't write .imd-findings.json.

What broke: the old distributor gave each payment's leftover wei (the part that doesn't divide evenly across tokens) to whoever held token 1, and exposed firstTokenOwner(). The new one keeps that remainder in undistributed[asset] and adds it to the next payment. My tests assumed the old rule, and one called the removed function.

test/DeepInvariant.t.sol (random-sequence invariant tests)

• The expected-payout model now carries the leftover forward for ETH and the test token separately, the same way the contract does.
• The balance checks now say: what the contract has recorded = unclaimed payouts + the carried leftover, and its actual ETH balance also includes ETH that was force-sent and not yet synced.
• New checks: the contract's carried leftover always matches the model and stays below the token supply.
• I removed the firstTokenOwner check.

test/Adversarial.t.sol (failure-path tests)

• I replaced the old leftover test with one showing a payment too small to split is carried forward. Token 1's holder gets nothing extra, and a claim before the next payment fails with "nothing to claim".
• The single-payment fuzz test now expects the treasury to get only its per-token share, with all holders' shares plus the carried leftover adding up exactly to the payment.
• New: a claim now stops after 64 stretches of unchanged balance, rather than 64 payments. The test changes a holder's balance 80 times; the first claim stops at 64, the second finishes, and the two add up to exactly what's owed.
• New: a wallet that mints after 300 earlier payments collects its payout in one call.
• New: a token payment too large for the contract's per-token counter is rejected, and nothing is recorded.

Minor behaviour, not a defect: the carried leftover isn't tied to who held tokens when it arrived. Anyone who mints before the next payment shares in it. It is always less than one wei per token in existence, so I left it out of the findings file.

I changed only those two files and haven't committed them.

The review is complete and the findings file is written. Nothing is outstanding.

Outcome: every finding from the previous round is settled, and no new defect reproduced. .imd-findings.json holds an empty findings list and a coverage record answering all 15 entry points plus the six prior findings and the checked invariants.

Prior findings, settled:

• Claim cursor O(all receipts) [medium]: fixed. Receipts now store a cumulative per-token total and claims walk constant-balance segments with binary searches. The attached proof passes. A holder who mints after 2,000 spam receipts gets 1 ETH in a single claim of about 130k gas.
• Shares stranded on distributor or collection [medium]: fixed. SeedClock rejects both sinks on every transfer path. The attached proof passes through its "transfer rejected" branch. The audit_math proof fails only because it demanded the other fix shape.
• WETH snapshotted at sync time [low]: fixed. WETH is synced inside every share change before balances move. I confirmed WETH arriving before a transfer goes to the seller and before a mint goes to prior holders.
• Remainder to token 1 holder [low]: fixed with a per-asset carry. Conservation holds as balance equals entitlements plus carry.
• Event index reuse [low]: fixed with a sentinel index. The reordered event keeps both runtimes free of the forbidden opcode bytes under the floor's linear scan.
• Receive gas stipend and registry trust dependency: author disputed both as intended design. I accept both as documented trade-offs rather than defects.

Independent verification this round: a scratch differential test ran 400 randomized sequences of mints, transfers and payments with partial claims and pagination against a brute-force per-receipt model, with exact agreement and full conservation. The full project suite passes (96 tests including stateful invariants). The protected floor test could not run locally because it needs the launch environment variables, so I replicated its size and opcode scan on the atomically deployed pair, and it passes. Slither and aderyn leads were checked and none reproduce as defects. Scratch files were removed and the tree is clean apart from the findings file.