Skip to main content

​
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: 
VRF Seed: 0x7a8f9c2b4e3d1f6a8b9c3d2e5f7a1b4c...
This seed is used to:

​
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

Normal Jackpot: SHA256(seed || "normal_jackpot") mod 125 == 0 (0.8% chance)
Super Jackpot: SHA256(seed || "super_jackpot") mod 12500 == 0 (0.008% chance)

​
Select Next Track

Next track = seed mod 4
0 = Doubloon Downs, 1 = Stampede Canyon, 2 = Synthwave Strip, 3 = Crown Meadows

​
Verification

Anyone can verify race fairness:
  1. Check the VRF proof - Confirms the seed was generated correctly
  2. Recalculate outcomes - Apply the same deterministic algorithms
  3. Compare results - Verify they match what happened on-chain
All data needed for verification is permanently stored on Solana.

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

No. The protocol must use whatever seed Switchboard provides. Any attempt to modify or reject the seed would be visible on-chain.
Switchboard uses multiple independent oracle operators. Collusion would require compromising a majority of nodes simultaneously, which is economically irrational.
The 256-bit seed provides 2^256 possible outcomes - more than atoms in the observable universe. This is cryptographically secure randomness.
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 — resolution is simply late, and the race schedule continues around it. 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.
A dedicated VRF request is made at protocol initialization, before race 1 opens for entries. Even the first track selection and permutation are oracle-derived, never operator-chosen.

​
Next Steps

How It Works

See the complete race cycle

Track Types

Understand probability distributions