Mint · Gen 1
Phase 1 of 2 · 3,500 NFTs · 90% Bee / 10% Bear — type and traits rolled randomly on reveal.
Gen 2 (another 3,500) is purchasable only with $HONEY — earned by staking Bees in the barn. Tiered prices, with a 10% chance a random staked Bear steals your fresh NFT.
We use commit-reveal over two transactions specifically to stop bots from cherry-picking rare Bears. With simple single-tx randomness, bots can wrap the mint in a contract that checks the result mid-tx and reverts on common outcomes — leaving honest minters with the leftovers.
Here, the outcome is sealed in mint, but determined later from a future blockhash you cannot predict. No way to game it, no way to revert — everyone gets a fair roll, just like a real raffle.
Why two transactions? (the bot story)
The problem we're solving: in single-tx mints with on-chain randomness, a bot calls mint()from a wrapper contract that checks the result mid-transaction. If it's a common type (Bee), the wrapper reverts the whole tx → bot pays nothing, walks away. If it's a rare type (Bear), the wrapper lets it through. Result: bots farm a disproportionate share of rares, real users get the leftovers.
How commit-reveal protects you:
1. Mint — you commit your tokenId(s) and pay. Type + traits are not yet decided.
2. Wait one Ethereum block (~12 seconds). The randomness source is the hash of the next block, which doesn't exist yet at mint time.
3. Reveal uses that future blockhash → derives your type and traits. By this point you're already committed, so there's nothing to revert.
4. If you forget to reveal within ~50 minutes (256 blocks), anyone can call forceReveal and your token defaults to a Bee. This stops indefinite stalling.
Net result: same fair odds for everyone, no bot sniping, no manipulation. Slightly worse UX (2 clicks instead of 1), much healthier launch.