BMC ILLUMINATI — INTEGRATE NFT MINTING INTO EXISTING WEBSITE

The review is complete. Findings are in .imd-findings.json, no project file was changed, and the working tree is clean apart from the ignored scratch test.

Outcome: no critical or high defect in the contract. I found three medium contract issues, one medium and one low website issue, and recorded coverage as an info entry. All snippets were verified against the tree.

Contracts read: src/BMCIlluminatiPass.sol, src/StandardArt.sol, src/interfaces/IBMCToken.sol, script/Deploy.s.sol, all three test files and both mocks, the website files, README and the self-review. The live BMC token was read over a public RPC and its verified source fetched from Sourcify. It is a plain OpenZeppelin ERC20 with ERC20Burnable, so the burn verification in the pass is sound. The mainnet fork test was run against the real token and passed. All 77 Genesis images resolve on the requester's gateway under the filenames the contract expects. Not reachable: live Chainlink node behaviour for expired requests, and the deterministic GitHub branch, which the brief says not to use.

Findings:

• Medium, head-of-line blocking. A single VRF request the coordinator never fulfils freezes every later reveal forever. There is no timeout or re-request path, and the owner cannot help. A scratch test confirms ten tokens with stored randomness stay pending behind one unfulfilled token, with 3.85M BMC burned for them. The README and site promise a stronger guarantee than the code gives.
• Medium, post-deployment configuration of the Genesis CID. The launch forbids owner setup after deployment, and nothing can mint until the owner calls the setter. The CID is already known and verified, so it should become a constant.
• Medium, post-deployment VRF configuration and design mismatch. The VRF setter is also post-deployment, phase 2 depends on an externally funded Chainlink subscription, and the brief describes block-derived randomness rather than VRF. The adapter needs a decision on which design ships.
• Medium, website safety. With no pass address configured, the approve button submits an approval to the zero address and the mint button sends a transaction with an empty recipient. No chain-id check guards sends, and there is no Coming Soon state.
• Low, website images. The gallery loads from a relative path and the configured IPFS gateway is never used, so images 404 on the hosted site.

Checked and sound: access control, reentrancy ordering, exact-burn verification, draw uniqueness, coordinator-only callback, a constructor that calls nothing external, and a runtime of 23,488 bytes with no forbidden opcodes.

Implemented locally: preserved the existing site assets, added /mint, fixed the reproduced audit issues, and verified all 77 Genesis images.

Validation passed: forge build, forge test, both mainnet-fork tests, protected factory checks, 33 JavaScript tests, and 3 Python tests.

Minting remains disabled pending finalized-source confirmation, verified deployment, and explicit launch approval. Nothing was deployed or published.

Changes and audit dispositions are documented in ADAPTATION.md.

Created launch.json for BMCIlluminatiPass with $owner and the supplied BMC token address, matching the accepted constructor ABI.

Validation: forge build passed; forge test reported 34 passed, 0 failed, and 2 fork tests skipped.

Only launch.json changed. No deployment or public-mint activation occurred.

I found one issue, and it is an informational one: no defect you'd need to fix before launch turned up in the contract or the mint flow. The findings are in .imd-findings.json, with a coverage row for each of the 9 listed entry points plus 3 extra checks. The project's own test suite passes (35 passed, 2 mainnet-fork cases skipped offline), and no repository file was changed.

The one finding (info): one buyer can take all 37 Mystery Genesis NFTs. A buyer using a smart contract can throw away any Standard draw and try again. When mintMystery hands over the NFT (src/BMCIlluminatiPass.sol:165), the buyer's contract can check the tier and cancel the transaction. Cancelling undoes the BMC burn, so a failed try costs only gas.

• Proof: I wrote and ran a test where one contract made 37 Mystery mints and got Genesis on every one. It burned exactly 37 × 350,000 BMC and nothing extra, and left none of the 37 Genesis outcomes for anyone else. An honest buyer would expect about 3 Genesis from 37 random mints. It takes about 18M gas per Genesis captured, which fits in one mainnet block. The test is attached to the finding as proof.
• Why it's only info: your brief accepts block-derived randomness. The code comments, docs/SECURITY-REVIEW.md and the mint page (website/mint/index.html:88) already tell buyers that contract buyers can reject results.
• What would fix it: the cheap fixes don't work. Minting without the receiver callback doesn't help, because the buyer's contract can still check the result after the mint returns and cancel. Rejecting contract callers can be bypassed by wallets using EIP-7702. Only a design change, like drawing from a future block hash or using Chainlink VRF, removes it. That's your call.

What holds up:

• Genesis mint: the cap is checked before the burn, and the exact BMC burn is confirmed against both total supply and the buyer's balance. IDs are sequential, #1 is the Legendary, and state is saved before the NFT is handed over, so nothing can re-enter a mint.
• Mystery draw: the shuffle logic is correct, so a full sellout gives exactly 37 Genesis and 423 unique Standard pieces.
• Burn total: it matches the prices at every point, up to 201M BMC at sellout.
• Transfers and approvals: these are the standard, unmodified OpenZeppelin code.
• Ownership: the owner has no special powers, so transferring or renouncing ownership can't affect minting or metadata.
• BMC supply: I checked mainnet, and BMC's total supply is about 988M. That is enough for the 201M a full sellout burns.
• Website mint flow: it approves only the exact price and waits for two confirmations. It checks the chain, account and phase again before minting, and stops safely on rejected, reverted or pending transactions. If the phase changes after an approval, some allowance can be left over. The page already warns about this, and only the buyer's own mint can use it.

Limits: I only read the website client in mint-client.js and the risk wording on the mint page. I didn't check the preserved homepage or the 77 IPFS images; the project's own report says all 77 passed its check. The two mainnet-fork tests were skipped in my run because no mainnet connection was configured.

The review is complete. Findings and coverage are in .imd-findings.json; no repository files were changed, and the only new files are the findings record and the scratch proof test, both ignored by git.

Scope covered. I read the Senior Auditor's Mindset and the Economic Security, Invariant and Flow Gap guides, then traced both mint paths, the exact-burn guard, the virtual Fisher-Yates draw, the phase gates and the ERC-721 and ownership entry points. I also verified the periphery directly: the live BMC token's Sourcify-verified source is a plain OpenZeppelin ERC20Burnable with no fee, pause, blocklist or owner, the two mainnet-fork tests pass against it at a current block, and the IPFS directory contains all 77 expected Genesis filenames. The website's approve-then-mint flow approves exactly the current price to the pass contract only.

Findings.

• High. Mystery outcomes are selectable inside the minting transaction (src/BMCIlluminatiPass.sol:155). The draw is computed from values fully known in the same transaction, written to storage, and only then minted. A caller can deploy a throwaway child per attempt, have it mint and revert unless tierOf says Genesis, and repeat with fresh senders in one block. The proof test under test/scratch/ obtained Mystery Genesis #41 on the 13th in-block re-roll, funded with a single mint price, and fails on the current code. Draining all 37 Mystery Genesis costs about 1,800 reverted calls of gas, after which the remaining 423 buyers burn 148M BMC with no chance at that tier. The author documents receiver reverts as accepted risk, but the fix stays within the requested block-random design: burn and mint as Pending, then settle the draw from a later block hash in a separate reveal call.

• Low. The Mystery phase can never open if the Genesis phase stalls (src/BMCIlluminatiPass.sol:150). With totalMinted stuck at 39, every mintMystery call reverts forever and 460 tokens are unreachable, with no owner or time fallback. This follows from the brief's sequential design, so it is reported for a scope decision rather than as a coding error.

Coverage. All nine listed entry points have rows: mintMystery as finding 1, the other eight as holds, plus rows for the burn-conservation invariant, the permutation invariant, the phase-gate invariant (finding 2), the live token, the IPFS directory and the website value flow. Nothing in my area was left unreached.

The review is complete. The findings file is written with an empty findings list and a 15-row coverage record, and the working tree is clean apart from that file.

Outcome: no substantiated defect in the Math Precision, Boundary or Numerical Gap area of src/BMCIlluminatiPass.sol or src/StandardArt.sol.

What I verified, with concrete checks

• Price and burn arithmetic. Every burn is a strict equality on both payer balance and token total supply, so no rounding or fee path exists. The burn total lands exactly on 201,000,000 BMC at sellout, which is also the assert bound.
• Phase and supply boundaries. Genesis closes exactly at the 40th mint and Mystery opens at the same count. The draw divisor 460 - revealedCount stays in 1..460, so the modulo never hits zero.
• Draw permutation. The virtual Fisher-Yates stores value+1 and the maximum stored value fits. I fuzzed 8 full 460-draw sellouts with varying entropy and block advances. Every run produced exactly 37 Genesis artworks in 41..77 and 423 Standard artworks in 1..423 with no duplicates, and the remaining-inventory views agreed at each step.
• External BMC token boundary. The Sourcify-verified source is a plain OpenZeppelin ERC20 plus ERC20Burnable with no tax, reflection, pause, blocklist or mint. Both mainnet fork tests pass against a live public RPC.
• Metadata string formatting. All 500 token URIs decode to valid JSON. Genesis file names are exactly zero-padded genesis-01.png to genesis-77.png, matching the pinned IPFS record. The longest URI is 3,681 characters against the website decoder's 100,000 limit.
• Trait bijection. The stride 1327 is coprime with 5400 and the mixed-radix decode is exact.
• Website numeric paths. Balance, allowance, phase, price and burn checks mirror the contract at the 40 and 500 boundaries. All 33 Node tests, including the Anvil 500-mint integration, pass.

Static-analysis leads in my area. The strict-equality warnings on _slotValue and mintMystery are the intended sentinel encoding and the exact burn check, not defects. The weak-randomness lead is the requested, disclosed block-random design and belongs to another area.

Not reached. I did not re-audit OpenZeppelin ERC721 internals beyond confirming the inherited entry points touch no numeric state in this contract.

The review is complete. The findings file is written and validated against the tree, and the only new file in the repository is .imd-findings.json (scratch tests and build output sit in ignored directories).

What I covered. The access-control, trust-gap and asymmetry passes over src/BMCIlluminatiPass.sol, with the inherited OpenZeppelin ERC721, Ownable and ReentrancyGuard confirmed byte-identical to upstream v5.1.0, the real BMC token's verified source fetched from Sourcify, and the website's approval and live-gate code read as the off-chain permission layer. The existing 33-test suite passes. All nine listed entry points have a coverage row, plus four invariant rows.

Findings (2):

• Medium, no on-chain launch control. Both mint functions are open to anyone from the deployment block, and the owner has no function that could hold the sale. The brief's rule that minting stay disabled until verification and authorization is enforced only by the website flag, so the Legendary Genesis #1 and Early Genesis go to whoever watches the factory, not to launch buyers. A scratch test shows a fresh deployment handing token #1 to the first caller. Suggested fix is a one-way enable call or a constructor start time, flagged as a scope decision because the contract currently promises the owner no powers.
• Low, free outcome selection in the Mystery phase. This is the accepted block-randomness risk, reported with its measured size: because the caller's address is an entropy input and the draw is observable and revertible before the burn commits, one actor with 64 helper contracts took all 37 Mystery Genesis in 21 blocks for exactly the inventory price, and a plain EOA using simulate-then-submit paid nothing for losing slots. The website disclosure is accurate but understates that selection costs nothing and needs no validator.

What holds. BMC is only ever burned from the caller, so stale approvals cannot be spent by third parties. The BMC token has no owner, pause, blocklist or fee. ERC-721 approvals and transfers are unmodified upstream code. Ownership transfer and renouncement are harmless on-chain since the owner holds no power. Paired state writes between the two mint paths are symmetric. The website approves only the exact price and never unlimited.

Not reached. No real-browser wallet test, no mainnet fork run of the deployed-token tests (they skip without a fork RPC), and no review of the future launch.json, which does not exist yet.

Added failure-path, fuzz, and stateful invariant tests under test/.

• forge build passed.
• forge test: 59 passed; 4 optional fork tests skipped.
• All 4 mainnet fork tests passed separately.
• Existing website and Python checks passed.

No implementation defects reproduced. Coverage and reproduction commands are in test/TESTING.md.

The review is complete. The findings file is written, validated against the source lines, and the only proof attached fails on the current code as required.

Outcome: three findings kept, written to .imd-findings.json, with 12 coverage rows (all 9 entry points plus 3 invariants). No repository files were changed; scratch tests live only under the ignored test/scratch/ directory.

Findings

• High. Mystery outcome selectable inside the mint transaction. Three specialists reported the same root cause at three severities; I merged them into one. The draw is written to storage and readable through tierOf before the transaction ends, a revert rolls the burn back, and msg.sender is an entropy input, so one throwaway contract per attempt gives fresh in-block draws. The economics specialist's proof fails on this code as claimed (13 attempts, Genesis #41, one mint price spent). I also reproduced the EOA variant with a snapshot-and-send loop: 11 slots skipped, then a guaranteed Genesis with zero failed transactions. The flow specialist's proof passes on current code, so it is a demonstration rather than a valid proof and I did not attach it. Suggested fix stays VRF-free: mint as Pending and reveal from a later block hash.
• Medium. No on-chain launch gate. From the permissions specialist. Any BMC holder can mint token #1 Legendary Genesis in the deployment block while the website shows Coming Soon. Reproduced with a scratch test; the owner has no pause, open or start-time function. The requester must choose between a one-way open switch or a constructor start timestamp.
• Info. Mystery phase unreachable if Genesis stalls below 40 sales. From the economics specialist. Reproduced at 39 Genesis mints: mintMystery reverts forever. This is the brief's sequential design, so I kept it informational for the requester to decide knowingly.

What held. The math specialist's clean result stands. I verified the virtual Fisher-Yates draw, artwork mapping, exact-burn delta checks, the 201M BMC burn ceiling, and factory deployability. Runtime and initcode sizes are inside the limits and the manifest uses only schema keys. I confirmed the mainnet BMC token is a plain OpenZeppelin v5 ERC20Burnable from its bytecode, and the four fork tests pass against it over the provided RPC. The full existing suite passes (59 tests). The website requests exact-price approval only, gates every write path on the LIVE configuration, and carries the required MINT BMC PASS button and manipulation disclosure.

Both reopened findings reproduced and are fixed, the advisory note is answered, and every suite passes.

Finding cfb1eeea (high, held proof) — fixed. The proof failed on the accepted tree exactly as reported (Genesis #41 taken on the 13th in-block attempt). Mystery is now commit-reveal in src/BMCIlluminatiPass.sol: the mint burns and issues a pending pass recording its block, and a permissionless reveal(maxCount) settles passes in mint order from the hash of the block after the mint block. The caller, prevrandao and timestamp are no longer entropy inputs, so observe-and-revert, simulate-then-send and helper-contract re-rolls all stop working. The reveal hash is readable natively for 256 blocks and through the EIP-2935 history contract for 8,191 blocks. After that a pass settles as Standard, so delaying a reveal never pays and nobody can be stranded. The proof now passes, backed by nine new regressions.

Finding b5ce1446 (medium) — fixed. On chain id 1 the contract deploys closed and both mint functions revert until the owner's one-way openMinting(). Nothing can close or pause it afterwards and the open state survives renunciation. The gate is scoped to chain id 1 because the held proof constructs with two arguments and mints in its own setUp, so an unconditional gate would break it in setup. This is stated in the responses and ADAPTATION.md.

Finding 7c97fe79 (info) — disputed. The Genesis-then-Mystery sequence is the brief's design, so the contract is unchanged. The mint page now states that Mystery opens only after all 40 Genesis sell.

Website follows the new flow: it reads the pending count and gate with the pinned stats, refuses writes while closed, sends a separate reveal after the next block, shows the unrevealed state, and offers "Reveal pending passes". The risk disclosure now names the reveal-block proposer as the remaining bias and the 27-hour window with its Standard fallback.

Verification results:

Answers are in .imd-responses.json. Operators should run a periodic reveal keeper, which docs/LAUNCH.md now describes alongside the owner's opening step.

The revision is complete. Only launch.json changed, and the build and test suite pass.

What was stale. The accepted contract was revised after the manifest was written. It gained a one-way owner-only launch gate and a next-block commit-reveal for Mystery outcomes. The old notes said the contract had no on-chain launch gate, that ownership carried no privileges, and that receiver contracts could revert unwanted outcomes. All three claims now contradict the accepted source.

What I changed. The contract entry and both constructor arguments are untouched. They still match the compiled constructor, which takes an owner address and the BMC token address. Only the notes were rewritten so they describe the accepted implementation:

• On chain 1 the contract deploys closed, and both mint functions revert until the owner sends a single one-way opening call. That is the owner's only power and it survives ownership renunciation.
• Mystery outcomes settle through a permissionless reveal call from the hash of the block after the mint block, in mint order. A pass not revealed inside the 8,191-block window settles as Standard.
• Block-derived randomness is still manipulable by the reveal block proposer and builders, and must not be advertised as tamper-proof.
• The manifest neither deploys nor authorizes minting. The site stays in pre-launch until the address, bytecode, review and authorization are confirmed, after which the owner opens minting.

Verification. A scratch script confirmed the manifest has exactly the schema keys, one unique valid identifier, string arguments, an argument count equal to the constructor's two address parameters, and notes under the limit.

The two skipped tests are the mainnet fork tests, which need an RPC URL and are skipped by design.

Findings file written and verified against the tree. Recap:

Settled from the previous round

• Mystery outcome selection (high, cfb1eeea): fixed. The held proof now passes on the revised code (300 in-block attempts obtain nothing and burn nothing), the flow specialist's capture proof no longer completes, and my own scratch test shows the outcome of a token minted in block n varies with the hash of block n+1, which does not exist at mint time. Commit-reveal closes observe-and-revert, simulate-then-send and helper-contract re-rolls.
• No on-chain launch gate (medium, b5ce1446): fixed. On chain id 1 the contract deploys closed, both mints revert until the owner's one-way openMinting(), and nothing can close it again. Factory and gate tests pass.
• Mystery unreachable if Genesis stalls (info): settled as accepted design. It still reproduces, but it is the brief's sequential design, and the disclosure I suggested is now on the mint page and in the README.

Reported this round (in .imd-findings.json)

1. Low: a successor token's outcome depends on whether its predecessor was settled naturally or force-settled after its window, contradicting the "does not depend on when" claim in the reveal NatSpec, docs and website. The specialist's proof fails on the current code and is attached. Impact is small and needs a 27-hour quiet window.
2. Low: renouncing or mis-transferring ownership before openMinting() on mainnet bricks the collection permanently. Reproduced in a scratch test.
3. Info: reveal(460) on a fully pending collection costs about 29.5M gas; keepers should bound the batch.
4. Info: BurnMismatch reports the supply delta even when the balance delta failed, so the revert can read as equal values.
5. Info: the accepted-design note above, recorded as settled.

Coverage: all 11 entry points answered, plus three invariant rows. The full project suite passes (80 tests, 2 fork tests skipped offline). Nothing outside test/scratch/ and the findings file was changed.