When we started building Satoshie, the first and most important technical decision was how to generate randomness. Everything else, the game mechanics, the user experience, the economics, all of it depends on having a source of randomness that is genuinely unpredictable, independently verifiable, and resistant to manipulation.
We evaluated every serious option available. We chose Chainlink VRF. Here is why, and what we rejected.
TLDR
Satoshie evaluated block hash randomness, commit-reveal schemes, RANDAO, threshold signatures, and Chainlink VRF for on-chain random number generation. We chose Chainlink VRF because it is the only solution that combines cryptographic proof of fairness, decentralised generation, battle-tested infrastructure, and practical usability for gaming applications. Every other option had a critical flaw.
Option 1: Block Hash Randomness
The simplest approach. Use the hash of a future block as your random seed. It is built into the EVM, costs almost nothing, and requires no external dependencies.
We rejected it immediately.
The problem is straightforward: validators know the block hash before anyone else. In a proof-of-stake system, the block proposer can choose not to publish a block if the hash would produce an unfavourable game outcome. This is called a "last-revealer" attack, and it is not theoretical. It has been exploited in the wild.
For a platform handling significant value in gaming outcomes, block hash randomness is not random enough. A validator with a financial interest in the game outcome has both the means and the motive to manipulate results.
Verdict: Simple but fatally flawed. Not suitable for any game where money is at stake.
Option 2: Commit-Reveal Schemes
A more sophisticated approach. The game collects commitments (hashed secrets) from participants, then reveals them after everyone has committed. The combined reveals produce the random outcome.
This is better than block hashes because no single party knows the outcome in advance. But it has its own problems:
- Griefing: The last revealer can choose not to reveal if the outcome is unfavourable. They lose their deposit but might save more by avoiding a bad result.
- UX friction: Players need to submit two transactions (commit and reveal), which doubles gas costs and adds waiting time.
- Coordination overhead: Requires multiple participants to be online and cooperative. If someone disappears between commit and reveal, the game stalls.
Verdict: Theoretically sound but practically clunky. The griefing problem alone makes it unsuitable for a consumer gaming platform.
Option 3: RANDAO
Ethereum’s beacon chain includes RANDAO, a mechanism where validators contribute to a shared random value each epoch. It is built into the protocol and available to smart contracts.
RANDAO is designed for protocol-level randomness (validator selection, committee assignment) rather than application-level randomness. The key limitation is the same last-revealer problem that affects block hashes: the final validator in each epoch can influence the RANDAO value by choosing whether to participate.
For low-stakes applications, this might be acceptable. For gaming with real money on the line, it is not. The cost of manipulation scales with the validator’s expected block reward, but the payoff scales with the game’s prize pool. A large enough prize pool makes manipulation economically rational.
Verdict: Good for protocol-level use cases. Insufficient for high-value gaming applications.
Option 4: Threshold Signature Schemes
Distribute the randomness generation across a group of signers using threshold cryptography. No single signer can predict or manipulate the outcome. The random value is only revealed when a threshold number of signers contribute.
This is a strong approach in theory. The decentralisation eliminates single points of manipulation. But the practical challenges are significant:
- Infrastructure burden: You need to run or coordinate a network of signers. For a gaming startup, this is a massive operational overhead.
- Liveness dependency: If too many signers go offline, the system cannot produce randomness. Games stall.
- Limited ecosystem support: Few mature, audited implementations exist for EVM-compatible chains.
- Trust assumptions: The signer set needs to be trusted not to collude. Selecting and maintaining a trustworthy signer set is an ongoing governance challenge.
Verdict: Cryptographically elegant but operationally impractical without significant infrastructure investment.
Option 5: Chainlink VRF
Chainlink VRF generates randomness off-chain using a verifiable random function. The oracle node produces a random number along with a cryptographic proof that is verified on-chain before the smart contract accepts it.
Here is what made it the clear winner:
Cryptographic proof of fairness. Every random number comes with a proof that is verified on-chain. This is not an attestation or a reputation system. It is mathematical verification. The proof either checks out or it does not. No trust required.
Decentralised oracle network. Chainlink operates hundreds of oracle nodes across independent operators. No single node can manipulate the randomness. The network has been running for years and secures billions in value across DeFi.
Battle-tested infrastructure. Chainlink VRF is not new. It has been used by hundreds of protocols across gaming, NFTs, and DeFi. The attack surface has been scrutinised by some of the best security researchers in the industry. It is as close to "proven" as anything in crypto gets.
Simple integration. From a development perspective, requesting randomness from Chainlink VRF is a single function call. The complexity of key generation, proof creation, and verification is handled by the infrastructure. We focus on building games, not randomness infrastructure.
No operational overhead. We do not need to run oracle nodes, manage signer sets, or coordinate multi-party protocols. Chainlink handles the infrastructure. We pay per request and focus on what we do best.
The Cost Question
Chainlink VRF is not free. Each randomness request costs LINK tokens, which adds to the operational cost of every game. This is a legitimate consideration, and one we evaluated carefully.
Our conclusion: the cost is worth it. Security and fairness are the foundation of a gaming platform. Saving money by using a cheaper but less secure randomness source is a false economy. One exploit, one manipulated outcome, one provable instance of unfairness, and the platform’s reputation is gone.
The VRF cost is built into our game economics. Players know the games are provably fair. That trust has value. It is, in fact, the primary value proposition.
The Decision Was Not Close
When we weighed every option against our requirements, specifically cryptographic verifiability, decentralisation, operational simplicity, and proven track record, Chainlink VRF was the only solution that checked every box.
Block hashes are manipulable. Commit-reveal is clunky. RANDAO is insufficient for high-value applications. Threshold signatures are operationally complex. Chainlink VRF is the right tool for the job.
Every Satoshie game, every raffle, every coinflip, is built on this foundation. Provably fair. Cryptographically verified. Powered by the most battle-tested oracle infrastructure in crypto.
We chose the best available option and built everything on top of it. That is not going to change.
📷 Photo by Logan Voss on Unsplash
