Design an NFT Raffle/Lottery Platform

Problem statement

Design an NFT raffle/lottery platform where users buy NFT tickets, each a unique token, and after sales close a random selection picks winners who claim tiered prizes. The platform must mint and distribute tickets, close sales deterministically, source randomness that no party can manipulate, select single or multiple winners across prize tiers, run a claim window with fallback for unclaimed prizes, and refund participants when a raffle fails to reach viability.

This is not a standard NFT mint site. A normal drop cares about mint throughput, reveal art, and royalty plumbing. A raffle's entire product promise is that the winner selection is uniformly random and provably fair. If the randomness source can be predicted, delayed selectively, or influenced by the operator, a validator, or a whale holding many tickets, the platform is not a raffle at all but a fraud surface. The design therefore separates three planes: the commerce plane (ticket sale, payment, inventory), the fairness plane (randomness sourcing, draw execution, winner proof), and the settlement plane (claims, prize custody, refunds, forfeit).

Why the problem is distinctive

A marketplace can tolerate eventual consistency in floor-price displays. A raffle cannot tolerate a biased draw even once, because every participant is implicitly betting that their odds equal ticketCount/totalSupply. Two properties are non-negotiable. First, unpredictability before commitment: no one may know or influence the winning seed before ticket sales close, otherwise insiders front-run. Second, verifiability after the draw: anyone must be able to recompute winners from published inputs without trusting the platform. Ethereum block hashes fail both tests at scale: proposers can grind or withhold blocks, and post-Merge validators have some influence over block content. A secure design uses a committed verifiable random function (VRF), most commonly Chainlink VRF v2/v2.5, where a coordinator signs a seed with a key whose ECDSA signature is verified on-chain, making the output unpredictable before publication and checkable after.

Public operating baseline versus design assumptions

Public evidence shows the category is real. Chainlink documents VRF v2 as a production randomness service used by hundreds of dApps, with a subscription payment model, configurable confirmation depth, and on-chain proof verification. OpenSea's public engineering materials describe infrastructure indexing millions of NFT contracts and metadata assets, which is the indexing scale this platform inherits for ticket tokens. Galxe's public materials describe web3 campaign infrastructure with millions of registered users running quest and reward mechanics adjacent to raffles. These are cited public context figures, not our design requirements.

For capacity planning, this answer explicitly assumes a growth-stage platform: 500,000 registered wallets, 15,000 DAU, 300 concurrent live raffles, 40 new raffle launches per day, 2,000,000 ticket mints per day at peak, and a 5x drop-spike multiplier when a marquee collection opens sales. Unless tied to a citation, every number is a stated design assumption, budget, or target.

The four architectural planes

1. Commerce plane: raffle configuration, ticket inventory, payment, per-wallet caps, allowlists, mint pipeline.
2. Fairness plane: VRF request, proof verification, winner derivation, public audit trail, anti-manipulation envelope.
3. Settlement plane: prize custody, claims, deadlines, forfeit, re-draw, refunds.
4. Trust & compliance plane: jurisdiction gating, KYC/AML policy, audit evidence, incident workflow.

A strong interview answer keeps these planes separate. The commerce plane may degrade under drop traffic; the fairness plane must never degrade, and the settlement plane must remain correct even if the front end is down.