Every argument about fairness in crypto gaming is an argument about randomness. Is the number random? Who generated it? Can the house grind seeds until it likes the answer? These are good questions and the industry has spent two years failing to answer them honestly.
But there is a second question, and almost nobody in crypto gaming asks it out loud: who decides the order?
A blockchain is not a set of simultaneous events. It is a queue. Someone, somewhere, decides which transaction goes first, and that ordering power is worth money. On Ethereum it is worth billions of dollars a year and it has a name: MEV, or maximal extractable value. In DeFi it shows up as sandwich attacks and liquidation races. In gaming it shows up as something far more embarrassing: a game that is provably fair on paper and trivially beatable in practice.
TL;DR
- Provable fairness answers “was the number random”. It does not answer “who chose the order of play”. Those are separate guarantees and most crypto games only attempt the first one.
- Any game that generates a result in the same transaction as the bet is exploitable by an atomic revert bot: the attacker simulates the outcome, and if they lose, the whole transaction reverts and they pay only gas.
- Randomness derived from
blockhash,block.timestamporblock.prevrandaohands a measurable edge to whoever produces the block, no cryptographic break required. - Chainlink VRF fixes ordering by accident of design: the bet is committed in one transaction and resolved in a later one, so the randomness does not exist yet when the player is locked in. There is nothing to simulate and nothing to revert.
- Satoshie runs on Base, where every raffle ticket carries equal weight and the resolve happens in a separate VRF callback. Ordering within a raffle window cannot change anyone’s odds.
The attack nobody wants to demo on stage
Here is the simplest exploit in on-chain gaming, and it has been public knowledge for years.
Suppose a coinflip contract takes your stake, computes a result, and pays out, all inside one transaction. The contract might use a hash of the block data, or a value from an on-chain feed, or a number the front end passed in. It does not matter which. What matters is that the result is knowable inside the same call.
An attacker does not play that game with a wallet. They play it with a contract. Their contract calls the coinflip, checks the balance afterwards, and if the balance did not go up, it reverts the entire transaction. Reverting undoes everything: the stake never left, the loss never happened. The attacker pays gas and tries again. They win every time they win and they never lose, which is a fairly comfortable position to be in.
Notice what this attack does not require. It does not require the randomness to be biased. The random number can be perfect. The distribution can be flawless. The game is still broken, because fairness was never the vulnerability. Atomicity was.
The block producer’s edge
The second ordering problem is quieter. Plenty of games still derive randomness from chain state: the hash of a recent block, the timestamp, the beacon randomness value. It looks decentralised. It is on-chain. It is verifiable after the fact. And it is worth exactly nothing as a fairness guarantee, because the entity assembling the block also influences those values.
A validator or sequencer with a stake in the outcome does not need to break any cryptography. They need to decide whether to include your transaction now or one block later, or whether to include it at all. On a game with a meaningful pot, that discretion is a direct financial edge. Nobody has to be caught doing anything. The architecture simply leaves the door open and asks you to trust that nobody walks through it, which is the exact trust assumption blockchains were invented to eliminate.
This is why “our randomness comes from the blockchain” is a marketing line, not a security property. The blockchain is not a random number generator. It is a ledger with a queue, and the queue has an operator.
Why the two-transaction design wins
Chainlink VRF is usually sold on its cryptography, and the cryptography is genuinely the point: a verifiable random function produces a number alongside a proof, and the proof is checked on-chain before the number is allowed to touch your contract. No oracle node can hand back a number it prefers, because a preferred number fails verification.
But the structural property matters just as much, and it gets almost no airtime. VRF is asynchronous. Your bet goes into one transaction. The randomness arrives in a later one, delivered by the VRF coordinator after a minimum number of block confirmations, and only then is the game resolved.
Work through what that removes:
- Atomic reverts die. You cannot revert a transaction based on information that did not exist when you sent it. By the time the number arrives, your stake is already escrowed by a contract you do not control.
- Simulation dies. Bots front-run by simulating outcomes locally before broadcasting. There is no outcome to simulate. The entropy is generated off-chain, after the commitment, by a network the player has no relationship with.
- The confirmation delay is a feature. Those required confirmations before fulfilment exist so a reorg cannot be used to retry an unfavourable result. What looks like latency is the anti-manipulation mechanism.
The awkward truth for the industry is that most crypto games chose the single-transaction design for user experience reasons. One click, instant result, no waiting. They optimised for a snappy demo and shipped an exploitable settlement model, then wrote “provably fair” on the landing page.
What this means for a raffle
Raffles have their own ordering question: does it matter when you buy your ticket?
In a badly built raffle, it can. If entry weight depends on timing, or the draw is triggered by whoever calls a function first, or the winner is derived from the block in which the final ticket landed, then position in the queue is worth money and bots will pay for it.
Satoshie’s raffles are deliberately boring here. Every ticket carries identical weight. The draw is not triggered by a player, it is resolved by the VRF callback, and the winning index is derived from the returned random word against the total tickets minted. Buying first, buying last, or buying in the same block as fifty other people changes nothing about your odds. There is no ordering advantage to extract because the contract does not read anything an attacker can position themselves in front of.
Running on Base helps too, though it is worth being precise about why. Base currently orders transactions through a single sequencer on a first-come-first-served basis with no public mempool, which strips out the classic sandwich surface that makes Ethereum mainnet such a hostile place to play games. That is a meaningful reduction in attack surface. It is not the guarantee. The guarantee is that the contract’s resolution logic does not depend on ordering in the first place, which is why it still holds if Base’s sequencer set changes tomorrow.
Three questions worth asking
Next time a platform tells you it is provably fair, do not stop at the randomness. Ask:
- Is the outcome computed in the same transaction as the bet? If yes, it is atomically revertable and the “fairness” is decorative.
- Where does the entropy come from? If the answer contains the word “blockhash” or “timestamp”, the block producer is a silent participant in your game.
- Can you point to the resolve transaction? A real VRF integration leaves two transactions on a block explorer, minutes apart, with a verified proof between them. You can go and look. If a platform cannot show you the second transaction, there was never a second transaction.
The crypto gaming industry keeps treating fairness as a single checkbox, and it is not. It is randomness plus ordering plus settlement, and a failure in any one of them makes the other two irrelevant. Getting the dice right is the easy part. Getting the queue right is what separates a verifiable game from a well-marketed one.
Satoshie was built on the assumption that both have to hold. Randomness you can verify, ordering you cannot exploit, and a resolve transaction sitting on Base that anyone can go and read.
📷 Photo by Meizhi Lang on Unsplash
