Reveal randomness in three live Ethereum NFT collections: blockhash vs VRF vs team-controlled reveal

Short answer:

• Bored Ape Yacht Club uses a future blockhash. Its contract commits to a block number and later takes that block's hash, mod 10,000, as an offset into the art order. A miner or validator can bias that number, and anyone can force a fallback hash by waiting. One secondary source says the offset was never actually used.
• Otherdeed for Otherside uses Chainlink VRF. The random value can't be predicted, and Chainlink proves it is correct on-chain. You still have to trust Chainlink to deliver it, and the team still controls when it is requested and how the metadata is served.
• Azuki has no randomness on-chain at all. The owner points the contract at metadata with setBaseURI, so the art-to-token assignment is decided off-chain by the team, like a server-side seed. There is nothing on-chain to check it against.

I couldn't confirm that Azuki uses a literal "server seed", so treat it as the team-controlled, off-chain category rather than a documented seed scheme.

1. Bored Ape Yacht Club: future blockhash

Contract: 0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D (BoredApeYachtClub, compiler v0.7.0)

How it works. The contract stores a BAYC_PROVENANCE hash that the owner sets, plus a startingIndexBlock. That block number is recorded during minting, either when the last ape is minted or once REVEAL_TIMESTAMP has passed. Anyone can then call setStartingIndex(), which computes startingIndex from that block's hash mod MAX_APES (Etherscan). The fallback to a recent block's hash described below is how I remember this common template. Etherscan cut off the source before those lines, so I couldn't confirm them.

Attack surface. Using blockhash for randomness is a known weakness. SWC-120 says block fields "are controlled by the miner", so whoever produces the block can pick a favourable hash and throw the others away. Since the Merge this is a smaller risk: a proposer can only skip their block, giving up the reward, which gives roughly one bit of bias. Two problems are specific to this contract:

• The 256-block window. blockhash returns zero for blocks more than 256 back, and this template then falls back to a recent block's hash. That means whoever calls setStartingIndex can choose when to call it and so influence the result.
• The owner can override it. There is an owner-only emergency function to reset the block.

There is a bigger structural problem. The metadata is served off-chain through a base URI that the owner can change. As an OpenZeppelin forum thread argues, that "allows them to defacto change the allocation of items in the collection" unless the URI is locked, whatever the offset says. A secondary search summary also says this offset code "was never actually used" during BAYC's mint. I couldn't open that source (ithelp.ithome.com.tw returned HTTP 403), so treat the claim as unconfirmed.

2. Otherdeed for Otherside (Yuga Labs): Chainlink VRF

Contract: 0x34d85c9CDeB23FA97cb08333b511ac86E1C4E258

How it works. The verified contract is set up with _vrfCoordinator, _linkTokenAddress, _vrfKeyHash and _vrfFee. It has two functions that request randomness, requestRandomnessForPublicSaleAndContributors and requestRandomnessForOwnerClaim, and Chainlink delivers the result through rawFulfillRandomness(bytes32 requestId, uint256 randomness) (Etherscan). The random word is used to shuffle the metadata assignment, so nobody can predict it before the request is answered, and the coordinator checks the proof on-chain.

Attack surface. The weak points move from block producers to how the integration is run and to trust in Chainlink:

• Re-requesting. Chainlink warns that "Any re-request or cancellation of randomness is an incorrect use of VRF", because an owner who can re-roll can keep the result they like.
• Inputs after the request. Projects should "Stop accepting further user actions that might affect the generated NFT and issue a randomness request." If minting can continue after the request, the outcome can be gamed.
• Reorgs. Builders "must choose an appropriate confirmation time" to limit reorg risk.
• A reverting callback. "If your fulfillRandomWords() implementation reverts, the VRF service will not attempt to call it a second time", so the reveal can get stuck.

(These quotes are from Chainlink's VRF security guide. That page covers v2.5; Otherdeed's interface is the older v1, but the same principles apply.)

Beyond those, you depend on the Chainlink network to answer at all, the owner decides when to trigger the request, and the off-chain metadata pointer can still be changed.

3. Azuki: team-controlled off-chain reveal

Contract: 0xED5AF388653567Af2F388E6224dC7C4b3241C544 (ERC721A)

How it works. The verified contract has no VRF, no blockhash, no starting index and no provenance hash. The owner sets where the metadata lives with setBaseURI (Etherscan). Which art goes with which token is decided entirely off-chain, before or at reveal, so it works like a hidden server seed with nothing committed on-chain.

Attack surface. Everything rests on trusting the team and their infrastructure:

• Insiders, or anyone who gets into the metadata pipeline, can learn or choose where the rare items go before reveal.
• Pre-reveal metadata can leak or be scraped, which enables sniping.
• The owner can change the base URI after the sale.

The OpenZeppelin thread makes the general point that without a locked, pre-committed mapping, developers keep control of which art each token gets. Problems in off-chain pipelines also happen in practice: during the Azuki Elementals reveal (a separate contract from the one above), metadata "for a few tokens were processed incorrectly due to event logs from a data provider that were outdated because of an eth block reorg" (NiftyNoon). Unlike the other two designs, holders have nothing on-chain they can check.

Comparison

	BAYC (blockhash)	Otherdeed (VRF)	Azuki (off-chain)
Can it be predicted early?	No, but block producers can bias it	No	Yes, by insiders
Can anyone check it?	Partly (provenance hash plus offset)	Yes (proof checked on-chain)	No
Main thing you trust	Block producers, the caller's timing, owner override	Chainlink's availability, owner's request timing	The team and its servers
Can the owner change the metadata pointer?	Yes	Yes	Yes

The table's caveat applies to all three: on-chain randomness only guarantees a fair reveal if the metadata it indexes was committed in advance and can't be changed.

---

Sources offered but not confirmed by this machine:

• https://swcregistry.io/docs/SWC-120 — does not contain the quoted text
• https://forum.openzeppelin.com/t/are-nft-projects-doing-starting-index-randomization-and-provenance-wrong-or-is-it-just-me/14147 — does not contain the quoted text

Checks Originals, Art Gobblers, and MekaVerse illustrate three different trust models: future Ethereum block data, a VRF oracle, and an operator-selected server seed. “Live” here means deployed Ethereum-mainnet collections; this compares their documented reveal designs, not whether minting remains open today. MekaVerse’s randomness is off-chain, an important distinction from an on-chain reveal.

Collection	Ethereum NFT contract	Reveal mechanism
Checks — VV Originals	0x036721e5a769cc48b3189efbb9cce4471e8a48b1	Epoch commitment to a future block; subsequent on-chain seed calculation. Project source and deployment
Art Gobblers	0x60bb1e2aa1c9acafb4d34f71585d7e959f387769	Chainlink VRF at launch, feeding an on-chain shuffle through a replaceable provider. Deployment, design
MekaVerse	0x9a534628b4062e123ce7ee2222ec20b86e16ca8f	Python shuffle with a disclosed server-side seed; metadata assignment occurs off-chain. Contract, developer account

Checks Originals — future-block commitment. Migrating an Edition into an Original assigns it to an epoch. resolveEpochIfNecessary() commits that epoch to block.number + 50; a later call computes randomness from the committed block’s hash and the resolving block’s block.difficulty, now representing Ethereum’s PREVRANDAO. If the target becomes more than 256 blocks old without resolution, the contract commits to another future block. Checks implementation, Solidity semantics. Attack-surface assessment: the delay prevents a minter from simply reading the final seed during initial commitment, but this is not randomness fixed solely by the target block. Resolution timing changes the additional input, creating opportunities for selective resolution and proposer censorship; Ethereum’s specification explicitly discusses this censorship-based influence on PREVRANDAO applications. Permissionless resolution limits any single caller’s control, while the timeout permits a replacement entropy target if nobody resolves. These are design risks inferred from the code, not evidence of an exploit. Implementation, EIP-4399.

Art Gobblers — VRF with an administrative escape hatch. The published design uses daily reveal batches and a Fisher–Yates shuffle. The contract fixes the batch size when requesting randomness and blocks another ordinary request until outstanding reveals finish; the designated provider supplies the seed. The original provider wraps Chainlink VRF v1, whose output is backed by an on-chain-verified cryptographic proof. Project design, contract, Chainlink. Attack-surface assessment: VRF provides stronger evidence about seed generation, but does not remove application-level trust. The owner can replace randProvider, including resetting a pending request, so a malicious or compromised owner could substitute a provider that supplies chosen randomness. Oracle availability and sufficient LINK also affect completion. Chainlink specifically warns that cancellation and re-request paths can enable discarding unfavorable outcomes. This describes the original architecture; I have not established which provider is configured today. Provider and upgrade logic, LINK requirement, VRF security guidance.

MekaVerse — reproducible server seed, without an on-chain fairness proof. Its developers describe assigning images with Python’s random.shuffle(list) and random.seed(561), then serving the resulting metadata. They published a reproduction procedure, including an adjustment for an accidentally included Thumbs.db file. The Ethereum contract’s initial metadata base URI pointed to the project API. Developer explanation, verified contract deployment. Attack-surface assessment: reproducing a shuffle establishes consistency with the disclosed seed and input ordering; it does not establish that either was fixed before ownership became known. An operator controlling those inputs could search for favorable assignments, and advance knowledge or leakage of the finished mapping could enable rarity sniping before public reveal. These are trust-model implications, not allegations that manipulation occurred. Unlike Checks’ block commitment or Gobblers’ VRF flow, this documented process relies on the operator’s account of how the assignment was selected. Developer’s process and timing disclosure.

---

Sources offered but not confirmed by this machine:

• https://raw.githubusercontent.com/visualizevalue/checks-contracts/main/contracts/Checks.sol — does not contain the quoted text
• https://github.com/artgobblers/art-gobblers/blob/master/src/ArtGobblers.sol — does not contain the quoted text
• https://etherscan.io/token/0x9a534628b4062e123ce7ee2222ec20b86e16ca8f — did not return a page
• https://medium.com/@Miinded/behind-the-scene-of-mekaverse-launch-e6343e2acc6f — did not return a page