Why VRF Matters
Every race outcome in horse.fun is determined by Verifiable Random Function (VRF) - a cryptographic system that ensures:- Unpredictable: No one can know the outcome before it happens
- Verifiable: Anyone can verify the randomness was generated correctly
- Tamper-proof: Impossible to manipulate without detection
Unlike traditional online games where you must trust the operator, VRF provides mathematical proof of fairness.
How It Works
1
Request
When entries close, the protocol requests randomness from the Switchboard oracle network
2
Generation
Multiple independent oracle nodes generate random values and cryptographic proofs
3
Verification
The network validates proofs and commits a 256-bit random seed on-chain
4
Resolution
The seed deterministically determines:
- Winner (1st place)
- 2nd and 3rd place
- Jackpot triggers
- Next race track selection
The Random Seed
Each race receives a unique 256-bit random seed:Determine Winners
Using Plackett-Luce sequential weighted sampling (integer-only, fully on-chain verifiable):- Horses are drawn one finishing position at a time
- Each draw picks a horse with probability proportional to its remaining weight
- This produces the full finishing order (1st, 2nd, 3rd, …) and guarantees each horse wins with exactly its stated probability
Trigger Jackpots
Select Next Track
Verification
Anyone can verify race fairness:- Check the VRF proof - Confirms the seed was generated correctly
- Recalculate outcomes - Apply the same deterministic algorithms
- Compare results - Verify they match what happened on-chain
Verify Past Races
Use any Solana explorer to inspect VRF seeds and race outcomes
Security Guarantees
What VRF Prevents
Prediction
Impossible to know outcomes before VRF generation
Manipulation
Cannot influence results without invalidating cryptographic proof
Selective Publishing
All requested randomness must be published on-chain
Replay Attacks
Each race has unique inputs preventing seed reuse
FAQ
Can the protocol choose favorable outcomes?
Can the protocol choose favorable outcomes?
No. The protocol must use whatever seed Switchboard provides. Any attempt to modify or reject the seed would be visible on-chain.
What if oracles collude?
What if oracles collude?
Switchboard uses multiple independent oracle operators. Collusion would require compromising a majority of nodes simultaneously, which is economically irrational.
How random is 'random enough'?
How random is 'random enough'?
The 256-bit seed provides 2^256 possible outcomes - more than atoms in the observable universe. This is cryptographically secure randomness.
What if the oracle doesn't respond?
What if the oracle doesn't respond?
The protocol re-requests randomness on a deliberately slow cadence (rapid retries would let a censoring adversary “re-roll” outcomes) and the race stays pending — races are strictly sequential, so the schedule pauses until resolution completes, and no race is ever skipped. Retries are permissionless: anyone can re-request randomness and trigger resolution. There is no deterministic fallback seed: a known fallback would make the emergency outcome computable in advance. In the extreme case of a permanent oracle shutdown, the multi-sig upgrade authority migrates the protocol to another VRF provider and pending races resolve with fresh randomness.
Where does the very first seed come from?
Where does the very first seed come from?
The first race’s track and permutation derive from a fixed, public zero seed — a constant in the open-source program, verifiable by anyone and chosen by no one. It carries no outcome information: race 1’s winners and jackpot triggers come from its own fresh seed, drawn at entry close like every other race’s.
Next Steps
How It Works
See the complete race cycle
Track Types
Understand probability distributions