Verifiable Randomness with Pyth Entropy
How Entropy generates on-chain randomness that nobody — including Pyth — can predict or manipulate.
The randomness problem on-chain
Blockchains are deterministic — every node must compute the same result. That makes true randomness impossible from on-chain data alone. Common workarounds like blockhashare manipulable by miners/validators. NFT mints, lotteries, and games need better guarantees.
Why blockhash is unsafe
A miner who sees an unfavorable blockhash result can simply discard their block and mine a new one. The expected cost to manipulate a lottery: approximately (expected profit) / (block reward). For high-value NFT mints, this is economically rational.
How Pyth Entropy works
Pyth Entropy uses a commit-reveal scheme between two parties: the user and the Pyth Fortuna provider. Neither party can know the final random number in advance.
Why neither party can cheat
Your random number is committed before the provider reveals theirs. You can't change it retroactively — the hash binds you.
The provider's random numbers come from a pre-published hash chain. They're committed long before any request is made — the provider cannot retroactively change them.
Entropy in this app
The Oracle Challenge uses Pyth Entropy to seed each round. The app reads the current sequence number from the Fortuna provider on Base mainnet — a value that changes with every entropy request made by any user on the network. This is used as a deterministic, verifiable seed to pick which price feed appears in the game round.
Contracts on Base mainnet
Use cases
Assign traits randomly at mint time — verified fairly on-chain.
Loot drops, critical hits, matchmaking — all provably fair.
No miner manipulation — the random seed is unknowable until reveal.