Review complete. The findings file is at .imd-findings.json in the repository root, the proof test is under test/scratch/, and no tracked file was changed.

What I read. All three source files (BMCIlluminatiPass.sol, StandardArt.sol, IBMCToken.sol), the deploy script, all tests and mocks, the README and security review, the vendored Chainlink v2.5 mock, and the pinned Pashov, x-ray and Trail of Bits references. I also fetched the real VRFCoordinatorV2_5 source and Chainlink's subscription and security documentation to verify the expiry behaviour independently. Not reachable: the live BMC token and mainnet coordinator (no fork RPC), and the Genesis CID hard-coded in the fork test, since two IPFS gateways returned HTTP 429.

Findings, most severe first:

• High. One expired VRF request freezes every later reveal. Chainlink documents that under-funded requests "remain pending for up to 24 hours before they expire", the coordinator has no on-chain retry, and the contract never opens a second request for a token. Because finalizeReveals only advances past the head of the mint-order queue, a single dropped request for token 41 leaves tokens 42 to 500 "Pending Reveal" forever even when their words were stored. The contract's NatSpec and README assume the opposite. The proof fails on the current code at the stated assertion and passed against a local reference patch, which I reverted. It binds the fix to a permissionless, timeout-gated rerequestRandomness that keeps mint order, rejects stored or revealed tokens and unmaps the abandoned request id. That trial also pushed runtime size to 319 bytes under the EIP-170 limit, which the adapter must watch.
• Medium. Genesis image CID is set after deployment. Launch rules forbid post-deployment configuration except for values only the requester holds. The VRF subscription setter qualifies for that exception. The CID does not, since the fork test already hard-codes it, and until the owner sets it no mint is possible.
• Low. Single-step Ownable. A mistaken transfer freezes the VRF config, after which mystery mints keep burning BMC for requests that may never be served.
• Low. Documentation misstates the pending-request guarantee. The 24-hour expiry is absent from the trust model and operational responsibilities.

Randomness and fairness assessment. The current draw is sound: order-independent, no reroll path, immutable coordinator, idempotent duplicate callbacks. The recommended recovery keeps those guarantees because the re-request only opens long after any legitimate fulfilment could arrive, so there is no unfavourable word to discard, and the owner gains no selective power. The adapter also needs to add the missing LaunchToken, which the launch requires and which this repository does not contain.

The work is complete and verified. Summary:

What was wrong. The pass gave each mystery token one Chainlink VRF request and finalized strictly in mint order, assuming an unpaid request waits forever. Chainlink's own docs say an unpaid request expires after 24 hours and a failed callback is never retried, so one dropped request would have frozen every later reveal permanently. The stuck state reproduces in the first half of test_ExpiredRequestBlocksQueueUntilRerequest.

The fix in src/BMCIlluminatiPass.sol is a permissionless rerequestRandomness(tokenId). It only works for a token that holds no randomness at all, only once its request is at least 72 hours old (three times Chainlink's window), unmaps the abandoned request id before opening a new one, and records the new request time. Finalization order and callback handling are unchanged. The owner has no lever the public lacks. The design, considered alternatives, fairness argument and trust assumptions are in docs/VRF-RECOVERY-DESIGN.md, written before the code.

Other audit findings, all reproduced and fixed with tests:

• Genesis artwork CID is now a compile-time constant. The value is the one the requester committed in the fork test, and I verified via the Pinata gateway that genesis-01, 40 and 77 are byte-identical to the repo artwork. The owner setter is gone; the two read-only views the mint site calls remain.
• Ownable2Step replaces single-step Ownable.
• NatSpec and README no longer claim unpaid requests wait indefinitely. Daily funding duty and the 72-hour re-request are documented.

Launch requirements. src/LaunchToken.sol ("Illuminati Pass", IPASS) is the fixed-supply launch token with tests. The pass keeps its three-argument constructor and makes no external call in it. I ran the pinned floor tests against the real creation code in a scratch harness: constructors run on an empty chain, supply stays with the factory, no forbidden opcodes, runtime 23,416 bytes.

Tests. forge build is clean and forge test gives 64 passed, 0 failed, 1 skipped. The skip is the requester's mainnet fork test, which I changed to skip rather than revert when no fork is present. New test/VRFRecovery.t.sol covers expired requests, the timeout boundary, late and duplicate callbacks, out-of-order fulfilment with a re-request, stored-word and front-running manipulation attempts, owner privilege probes, and a 500-mint simulation with expired requests that still yields 77 Genesis, 423 Standard and 201,000,000 BMC burned.

Guarantee changes are reported in docs/PULL-REQUEST.md and the re-review in docs/SECURITY-REVIEW.md Part C. The re-review was written adversarially by me against my own change, so it is not independent; IMD's final review is the independent one.

Not done, and why. The branch and PR could not be pushed or opened: this machine has no GitHub credentials or gh. The remote already has an empty security/vrf-recovery branch, and the full PR title and body are in docs/PULL-REQUEST.md for the requester to open. Nothing was deployed, broadcast, approved or merged, and the website was not changed. ADAPTATION.md lists every change with its reason.

launch.json is written and validated. No other tracked file was changed.

What the manifest contains

• Token: LaunchToken, "Illuminati Pass" / IPASS, 18 decimals, as src/LaunchToken.sol sets them.
• One application contract, BMCIlluminatiPass, with constructor arguments in declaration order: $owner for initialOwner, the mainnet BMC token address for bmcToken, and the mainnet Chainlink VRF v2.5 coordinator for vrfCoordinator. Both addresses are lowercase and match the deploy script, README, tests and NatSpec in the accepted tree.
• Pool exactly as the launch section gives it: native ETH, fee 12500, tick spacing 60, the one-to-one initial price.
• Notes under 4,000 characters describing the pass, the owner's only power (setVRFConfig, set after launch), the permissionless 72-hour re-request recovery, and that no contract receives launch token supply.

StandardArt is an internal library inlined into the pass, so it is not a deployable contract and is not listed.

Checks run

• forge build clean, forge test 64 passed, 0 failed, 1 skipped (the mainnet fork test without a fork).
• Schema check in Python: only the five top-level keys, unique names within 32 characters, address strings lowercase, pool values verbatim.
• The pinned floor tests run from test/scratch against the real creation code with a CREATE2 stand-in factory, chain id 1, the launch owner as $owner, and the policy supply: 9 passed. The pass constructor runs on an empty chain, the supply stays with the factory, and the runtime is within EIP-170 with no DELEGATECALL, CALLCODE or SELFDESTRUCT.

git status shows launch.json as the only new tracked-path file. The other untracked entries are sandbox device nodes, not repository changes. No submodules exist, and nothing was deployed, broadcast or merged.

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

Outcome. One substantiated finding, medium severity, in the assigned area (economic security, invariants, flow gaps). Everything else I traced holds, and all 17 listed entry points have coverage rows plus three invariant rows.

The finding. The recovery design claims nobody can ever choose between two VRF words for a token. That guarantee depends on the abandoned request's word being unknown, which fails in the exact scenario the recovery targets. On the real Chainlink v2.5 coordinator, a fulfilment that reverts for insufficient subscription balance publishes the proof in calldata while leaving the request commitment live, and anyone can later resubmit that proof. So at the 72-hour mark the pending token's holder has two open paths: resubmit the known word, or call rerequestRandomness to discard it. They take whichever is better, roughly doubling their Genesis odds per leaked request. I reproduced both branches from one state with the project's mock coordinator and anchored the finding at src/BMCIlluminatiPass.sol:274. The contract cannot detect a leaked proof, so the recommended fix is to state the precondition honestly in the design doc and README, and to add an operational rule that any reverted fulfilment's proof is resubmitted promptly while the old id is still mapped.

What held. Mint pricing and exact-burn verification, the 500/40/460/77/423 supply and artwork invariants with re-requests in the loop, strict mint-order finalisation, the Fisher-Yates draw, callback idempotence, owner powers being delay-only, re-request griefing bounds, and the plain launch token.

Not covered. I did not re-derive the gas-per-reveal measurements or the IPFS pin verification, and I could not exercise the live BMC token or a mainnet fork from this environment.

The review is complete. The findings file is at .imd-findings.json in the repository root, the scratch tests are removed, and no project file was changed.

Outcome: the math, boundary and numerical-gap area of the BMC Illuminati Pass contract holds. I found one documentation-level defect and no arithmetic, rounding, overflow, off-by-one or external-boundary defect that affects fairness, supply or funds.

What I verified

• Draw arithmetic. The virtual Fisher-Yates over 460 slots is correct, including the sentinel encoding and the r == remaining-1 case. The divisor is never zero, artwork ids land in 41..77 and 1..423, and the 500-mint simulations (in order, shuffled, and with expired requests) produce exactly 77 Genesis and 423 Standard with every artwork once. Modulo bias is below 2^-247 as documented.
• Boundaries. Phase gates at 40 and 500, the exact-burn delta check, the MAX_TOTAL_BURN assert (reached exactly at sell-out, never exceeded), and the 72-hour re-request gate (rejects at +72h-1, allows at +72h) all behave as the design document states.
• Real external dependencies. I ran the project's mainnet fork test against a public RPC: the real BMC token's burnFrom reduces supply by exactly the price. I also read the live VRF v2.5 coordinator: minimum confirmations 3, max callback gas 2,500,000, max confirmations 200, matching the contract's setVRFConfig bounds.
• Callback gas arithmetic. A 1k-step sweep of callback gas from 150k to 700k, with the worst case of a first-ever Genesis reveal and four words queued, never produced a failed callback and every attempted inline batch succeeded. A stored word is never lost.

The one finding (info): the NatSpec on GAS_PER_REVEAL says a reveal was measured at ~85k gas, but it costs about 110k to 117k, so the budget is tight rather than conservative. As a consequence the README runbook's claim that 500k callback gas finalizes up to 4 reveals is wrong: 500k gives 3, and 4 needs at least 503k. There is no safety impact because permissionless finalization covers the remainder.

Static-analysis leads: the Slither reentrancy lines concern calls into the fixed BMC token and the coordinator before state writes, both guarded by nonReentrant and verified against the real token. The Aderyn "storage array edited with memory" line is a false positive, since vrfConfig is copied to memory. None reproduce as defects.

Coverage: all 17 listed entry points have a row (16 hold, one carries the info finding), plus four invariant rows. Nothing in my area was left unreached.

The findings file is valid, both cited snippets match the tree exactly, and the working tree shows no tracked changes (only the git-ignored scratch directory and the findings file). The review is complete.

Outcome: the VRF recovery fix holds up under the Execution Trace, Periphery and First Principles guides. I found one low-severity defect and one documentation-level correction to the stated fairness guarantee. No critical or high findings, so no failing proof tests were required.

What I verified independently

• Chainlink's subscription docs confirm the 24-hour expiry statement the fix relies on. The node job-spec docs show this is a per-node requestTimeout default, and the real v2.5 coordinator has no on-chain expiry at all.
• The real coordinator source confirms a dropped request permanently blocks both cancelSubscription and removeConsumer, and that requestRandomWords deliberately skips key-hash validation.
• All 64 existing tests pass. Scratch gas sweeps from 400k to 700k callback gas never produced a failed inline batch, so the gas-budget lead from static analysis is dead.

Findings written to .imd-findings.json

1. Low. setVRFConfig cannot detect an unserviceable key hash, and the real coordinator accepts any value. A mistyped or retired lane means every mystery mint burns 350k BMC into a request no node will ever serve, and the 72-hour re-request reopens the same dead lane. The README states a bad config only blocks mints, which is false. Reproduced against Chainlink's own coordinator mock in test/scratch/BadLane.t.sol. Suggested fix is to query the coordinator's public proving-key mapping in the setter.
2. Info. The 72-hour margin is sound only while node operators keep the default 24-hour timeout. The design doc presents this as documented Chainlink behaviour rather than a node configuration default. No code change needed, but the stated guarantee and the owner runbook should say so.

Coverage: all 17 listed entry points have a row, plus three invariant rows and the rejected gas lead. Everything traced holds except setVRFConfig, which carries finding 1.

Build is clean and the whole suite passes. Only two new files sit in the working tree, both under test/, so nothing is out of scope.

What I did

I tested the accepted VRF recovery implementation as an adversary rather than re-testing its happy paths. The Chainlink docs confirm the premise of the 72h gate: underfunded requests stay pending for up to 24 hours and then expire. Two new test files were added.

• test/BMCIlluminatiPass.invariant.t.sol drives the pass with a handler over random call sequences from six actors plus the owner: both mint phases, full-gas and starved deliveries in any order, duplicate callbacks, late callbacks for abandoned ids, unknown ids, deliveries from non-coordinators, finalization, time travel, re-requests by holders, strangers and the owner, config changes and transfers. Eight invariants cover supply caps, burn conservation against ghost accounting, reveal counts and pool sizes, Genesis tokens being fixed forever, strict mint-order reveal, immutability of revealed outcomes and artwork uniqueness, request-mapping consistency, and that a delivered word is never discarded or re-requested. It runs with fail-on-revert so every unexpected revert or handler assertion is a failure. Result: 48 runs, 0 reverts, all invariants hold.
• test/VRFRecoveryEdges.t.sol pins edges the existing suites did not: the callback at the minimum configurable gas, a fuzz over the whole allowed gas range showing the callback never reverts and the word is always stored, the inline-finalize budget running dry, a callback that failed at the coordinator being recoverable only after the timeout, reentrancy from the mint receiver into re-request and finalize, request id zero, extra random words, zero and huge finalize counts, batching independence, queue position after a re-request, and a fuzz showing outcomes are independent of the whole recovery history.

Test results

Finding reported, not asserted

One informational finding is in .imd-findings.json. The per-reveal gas budget in the callback is 110k with a comment claiming 85k measured, but a first reveal that lands on Genesis costs about 156k, so between roughly 165k and 172k of callback gas the inline attempt runs out of gas inside the try/catch and is wasted. The word survives, the callback succeeds, and the token finalizes permissionlessly with the identical outcome, so fairness and supply are unaffected. I did not find a defect in the randomness or fairness guarantees: no path replaces a stored word, no caller including the owner can re-request inside the timeout or for a token holding a word, and late deliveries for abandoned ids are always rejected.

Still owed outside this environment: the fork test against live mainnet state, which needs an RPC the verifier does not have.

The review is complete. The findings file is written and no tracked files were changed.

Outcome. The access-control, trust-gap and asymmetry audit of the VRF recovery fix found no permission bypass, no owner reroll or selective-retry lever, and no asymmetry that breaks the draw. One low-severity information asymmetry is reported, with a scratch test that fails on the current code.

Finding 1 (low), src/BMCIlluminatiPass.sol:545. Pending metadata says the outcome is "not yet determined on-chain" even when the token is in the RandomnessStored state. At that point the word is public and the outcome is computable by anyone, so a seller can trade a known Standard token against a buyer who sees "Pending Reveal". The 72-hour recovery window makes this structural: while one request is stuck, every later token sits in that state for days because finalization is strictly in mint order. The draw itself stays fair. Reproduction: deliver a word with 95k callback gas, compute the tier from the stored word, confirm it matches after finalization, and observe the token URI is byte-identical to the awaiting-randomness URI. The proof test is at test/scratch/StoredWordMetadata.t.sol.

What held, by area.

• Access control: every state-changing entry point was mapped. The only owner powers are setVRFConfig and the two-step ownership transfer. The config setter cannot touch open requests, stored words, request maps or the timeout. The re-request gate is identical for the owner and the public. Renouncing ownership freezes the config, which is documented and has no unprivileged amplifier.
• Trust gap: the owner can delay reveals through subscription funding or a dead lane but cannot bias them. The callback has no holder-controlled code, so a callback failure cannot be value-dependent. Re-request spend is bounded to genuinely stuck tokens once per 72 hours.
• Asymmetry: mint and re-request write the same request state through one helper. A coordinator revert during re-request restores the old mapping. Fulfilment for the abandoned id reverts, duplicates are ignored, and the Fisher-Yates swap is correct at the last-slot edge.

Coverage. All 17 listed entry points have rows, plus three invariant rows. Baseline suite: 64 passed, 1 skipped. The claim that Chainlink never serves a request older than 72 hours remains a documented trust assumption, not a code defect, since a late word is rejected at the cost of one fulfilment fee.