The deliverable is complete and committed on main (commit cb69807).

What was built

• src/VisualIdentityEdition2.sol: one contract, ERC-721 VisualIdentity.md Edition 2 / VIMD2, no constructor arguments, no owner or settings. It fixes ENTRY_END and VOTE_END in the constructor without calling any contract. The VIMD, seats, delegate registry and burn addresses are constants. enter, vote and claimPrize are nonReentrant and write all state before the mint and the VIMD transfers. The leader is tracked incrementally per vote, so claiming never loops over entries. tokenURI builds the base64 JSON on chain, and links are restricted to 1 to 200 printable ASCII bytes without quote or backslash.
• foundry.toml pins solc 0.8.26, optimizer 200 runs, cancun, bytecode_hash = "none", no ffi, no fs permissions.
• lib/: OpenZeppelin Contracts v5.4.0 and forge-std v1.11.0 vendored as plain files, no submodules.
• README.md: outside contracts, deployment parameters, behaviour, accepted properties, security notes and operational responsibilities.

Checks run

Test coverage includes entry and vote by owner and by delegate, every window edge, wrong, revoked or mis-scoped delegation, nonexistent seat, duplicate entry and vote after a seat is sold or re-delegated, insufficient VIMD or allowance, every bad link class plus a fuzzed comparison against a reference checker, leader tie ordering plus a fuzzed scan comparison, prize paid to the stored entrant rather than the NFT holder, donations staying outside the pot, fuzzed VIMD conservation, reentrancy via the mint receiver and via a hooked token on all three guarded functions, and exact tokenURI output.

Open items for the launch, not this task: explorer source verification after deployment, and an independent adversarial review before release.

launch.json is written and validated. Nothing else in the tree changed.

What I did

• Read the accepted source at src/VisualIdentityEdition2.sol and the two protected checks. The contract has a parameterless constructor that only fixes the two deadlines and calls no other contract, so it passes the empty-EVM deployment rehearsal and has no owner for the owners check to object to.
• Confirmed the compiled ABI has no constructor inputs, so the manifest entry has an empty constructorArgs list.
• Wrote launch.json with kind evm_contracts, one contract named VisualIdentityEdition2, no constructor arguments, and notes describing the ERC-721, the fixed windows, the compiled-in VIMD, seats, delegate registry and burn addresses, the two prices and the prize mechanics. No $owner is used because the brief and the source define no owner, admin or role.
• Checked the manifest against the schema rules with a script in a temporary command: exactly the three keys, unique identifier under 32 characters, string arguments, notes under 4,000 characters.

Verification

forge build: ok
forge test (FOUNDRY_FUZZ_SEED=0x93e9...c369): 56 passed, 0 failed
git status: only launch.json is new

Two of my shell commands in the middle were accidental no-ops with mistyped paths. They ran nothing and changed nothing.

The findings file is valid, the quoted snippet matches line 136 exactly, and the working tree is clean apart from the ignored scratch directory and the findings file.

Result: no defect found in the Access Control, Asymmetry or Trust Gap area of VisualIdentityEdition2. The findings file holds one info-level trust assumption and a full coverage record.

What I checked

• Access control. Every state-changing path reads live seat ownership and a live delegate.xyz delegation from that owner, so a stale delegation from a former owner is refused. Seat-keyed mappings block a second entry or vote after a sale or re-delegation. Windows are half-open as the brief states. The inherited ERC-721 functions touch no contest state.
• Asymmetry. The entry and vote fee paths mirror their specification. The pot increment and the pull to the contract sit in the same guarded function and revert together. The incremental leader update is correct because counts only grow and only the voted entry changes. The leader's own tie vote and a lower-id tie both resolve as specified.
• Trust gap and reentrancy. All writes and events precede the mint and the VIMD pulls. From inside the mint receiver callback, re-entry into enter, vote and claimPrize is rejected, and the unguarded ERC-721 calls it can make are harmless. A reverting receiver blocks only its own entry. The only outbound VIMD transfer is claimPrize paying exactly the pot, once, to the stored entrant.

Probes run. Six scratch tests under test/scratch/ covering callback-time NFT moves and seat sales, a rejecting receiver, the leader's own tie vote, a seat sold mid-window, a former owner's delegate, and claim at exactly VOTE_END. All passed, confirming intended behaviour. The existing 56-test suite also passes.

Recorded as info. A delegate with an empty-rights delegation becomes the entrant and receives the NFT and the prize in its own name. This matches the brief and is documented as a trust assumption for seat owners, not as a defect.

Coverage. All eight listed entry points are marked holds, plus four invariant rows. One note flags that the registry mock matches exact tuples while the real registry also honours wallet-level and contract-level delegations, which the contract delegates to the registry as specified.

The review is complete and the findings file is written. The working tree is clean apart from the .imd-findings.json deliverable, which git ignores.

Outcome: no economic, invariant or flow-gap defect found in VisualIdentityEdition2. One informational trust assumption is recorded.

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

• Pot conservation. Only vote writes pot and totalVotes, together, with exactly 25,000 VIMD pulled into the contract per vote. Only claimPrize moves VIMD out, exactly pot, once. Donations stay. Confirmed by the existing fuzz test and a scratch test with six votes.
• Leader rule. The inductive update handles strict lead, ties to the lower id, and a re-vote of the current leader. A scratch sequence of votes for entries 2, 1, 2, 2, 1, 1 produced the expected leaders at every step.
• Single entry and single vote per seat. Both maps are keyed by seat id and never cleared, so a sale or re-delegation cannot reset them.
• Windows. Entry strictly before ENTRY_END, voting from ENTRY_END up to but excluding VOTE_END, claim from VOTE_END. The boundaries are disjoint and match the brief.
• Reentrancy. All three actions share one guard, state and events are written before the mint callback and the token transfers, and the receiver callback can only move its own freshly minted NFT, which affects nothing.
• JSON injection. The link filter admits only printable ASCII without quote or backslash. I decoded a tokenURI built from a link containing every other punctuation byte and it parsed as valid JSON.
• Dependencies. VIMD is plain, so assumed and received amounts match. A reverting ownerOf or a false registry answer fails closed. The prize is paid by plain ERC-20 transfer, so no recipient can block it.

The one recorded item (info). The 2,000-entry bound rests entirely on the seats contract never minting an id of 2000 or more. A scratch test showed that a minted seat 2000 can enter. This is consistent with the brief, which forbids extra safeguards, so I framed it as a dependency to confirm rather than a code defect.

Coverage. All eight ABI entry points are marked holds, plus six invariant and economic rows. The scratch directory has been deleted. Nothing outside the findings file was changed.

The review is complete and .imd-findings.json holds the result: no defects, with coverage rows for all eight entry points plus the invariants I checked.

What I checked, in my area (Execution Trace, Periphery, First Principles):

• enter / vote / claimPrize traces. Every state write and event precedes the mint and the VIMD transfers. The shared reentrancy guard blocks re-entry from the mint's receiver callback and from a hooking token. Windows are exclusive at ENTRY_END for entering and at VOTE_END for voting, so no block allows both enter and vote, or both vote and claim.
• Leader rule. The incremental update (strictly more votes, or equal votes and lower id) is provably equivalent to a full scan since each vote adds exactly one.
• Pot conservation. The amount added to pot equals the amount pulled into the contract. Donations stay and are never paid.
• Link whitelist. Every allowed byte is a legal unescaped JSON string character, so no link can break or inject into the tokenURI document.
• Periphery on mainnet. I ran a scratch fork test against the real contracts and then deleted it. VIMD moved exact amounts to the burn address and the winner, and its runtime exposes only the nine plain ERC-20 selectors. The seats contract reverts for id 2000, reports a total supply of 2000, and its owner is the CREATE2 deployer proxy, so nobody can mint more seats. The real delegate.xyz v2 registry accepted a seat delegation with empty rights from the current owner and rejected one from a non-owner and one with specific rights.
• Static-analysis leads. All five are false positives against the specified behavior.

Not a defect but worth knowing: the test suite's delegate registry mock matches exact tuples only, so ALL and CONTRACT-scope delegations are untested locally. I verified them on the fork instead.

The working tree is unchanged apart from the findings file.

The review is complete. The findings file is written, validated, and the scratch tests are removed.

Outcome: no defect found in the Math Precision, Boundary or Numerical Gap areas. The findings file holds one informational note and twelve coverage rows, all eight listed entry points answered as holds.

What I checked

• Arithmetic. The contract has no division, downcast, decimal scaling or unchecked block. All sums are bounded by the 2,000 seats, so the largest pot is 5e25 and nothing can overflow.
• Windows. Enter is strictly before ENTRY_END, vote is from ENTRY_END up to but excluding VOTE_END, and claim is at or after VOTE_END. I confirmed the exact-second edges leave no overlap and no gap.
• Links. An exhaustive test of all 256 byte values plus lengths 0, 1, 200 and 201 matched the spec rule exactly, so the tokenURI JSON cannot be broken or injected.
• Leader bookkeeping. The incremental update was checked against a scan through self-votes, ties from higher ids, overtakes and re-ties.
• Conservation. Across a full 2,000-entry, 2,000-vote run the contract balance equalled the pot at every step, the claim paid exactly the pot once, and a donation stayed behind.
• External boundaries. The mint callback sees the stored entry before the VIMD burn, but the burn still follows atomically and the guard blocks re-entry. SafeERC20 v5 handles no-code and false-returning tokens.

Informational note recorded. A seat owned by a contract that lacks an ERC-721 receiver hook can vote but can never enter, because the mint uses the safe variant. This matches the brief, which names the receiver callback as an attack surface, so it is a trust note rather than a fix request.

Not verified. VIMD is assumed to be the plain 18-decimal token the brief states. No fork is allowed, so I could not confirm that on chain. The real delegate.xyz v2 semantics were only exercised through the mock, which belongs to another specialist's area.

Done. The full suite passes under the verifier's seed and the two new test files are committed. No defect was found in the contract, so no findings file was written.

What I added

• test/VisualIdentityEdition2.invariant.t.sol: a handler that drives the contract with six actors, 25 real seats plus two nonexistent ids, seat sales, live and stale delegations, donations, NFT transfers, time warps and exact boundary jumps. Every action is modelled first, so an unexpected success fails as loudly as an unexpected revert. Thirteen invariants cover VIMD conservation against pot plus donations, burn accounting, one entry and one vote per seat, leader equal to a linear scan with lowest id on ties, immutable entry fields, NFT supply equal to entry count, tokenURI equal to the brief's JSON, and a single claim paying exactly the votes' pot to the stored entrant. A scripted lifecycle test walks through all phases and evaluates each invariant, proving the random runs are not vacuous.
• test/VisualIdentityEdition2.edges.t.sol: gaps in the existing unit suite. Delegations from a previous owner stop counting after a seat sale for both enter and vote. The owner cannot act after its delegate did. A contract caller without the ERC-721 receiver hook is refused with no state left behind. The prize follows the stored entrant after both the seat and the NFT are sold. Every allowed link byte, and injection-shaped links, round-trip through forge's real JSON parser unchanged, fuzzed at 512 runs.

Verification

Review verdict on the contract

I read it adversarially against every attack listed in the brief and found nothing to report. Checks, effects and events precede the mint and both token transfers in all three guarded functions. The incremental leader update is equivalent to a scan because only one entry's count changes per vote. Window checks match the brief's inclusive and exclusive ends.

Still owed against live state

The delegate registry mock models only explicit per-token delegations. The real registry also honours wallet-wide and contract-wide delegations with empty rights, which the contract would accept through the same call. A fork test against mainnet would confirm that, and cannot run here with no network.

Review complete. The findings file is written, snippets match the source lines, and the working tree shows no modified files beyond build output already ignored by git.

Outcome: no defects found. The VisualIdentityEdition2 contract does what the brief specifies on every attack the brief lists. The report in .imd-findings.json holds three info-level trust assumptions and a full coverage record marking all eight entry points as holding.

What I verified

• Every required check reproduces: entry window, seat holder or live delegation, one entry and one vote per seat keyed by seat id, vote window with no gap or overlap, exact pot accounting, leader tie-break by lower id, single claim paying exactly the pot, and the link rule keeping the tokenURI JSON intact.
• Reentrancy through the mint callback and through a hooked token is blocked by the guard on all three functions. My scratch test had a receiver move the fresh NFT and re-approve it inside the callback. The entrant stayed fixed, the fee was still burned, and nested vote and claimPrize calls reverted.
• The existing suite of 70 tests plus invariants passes. Build is clean under the pinned toolchain, the manifest has only the allowed keys with an empty constructor argument list, and the runtime has no forbidden opcodes.
• Mainnet dependencies match the brief over the chain 1 RPC: VIMD is an 18-decimal ERC-20 with no hook selectors or owner, the seats contract has MAX_SUPPLY 2000 with ownerOf(2000) reverting, and the delegate registry answers.

Specialist findings

All three info items reproduced and were kept as documented trust assumptions, none merged since their root causes differ. The seat-cap item is now settled with on-chain evidence that the cap is enforced upstream. The write_foundry_tests and audit_flow areas reported nothing, consistent with my own reading. The slither timestamp lines and the aderyn leads are by design and were left out.