> ## Documentation Index
> Fetch the complete documentation index at: https://docs.horse.fun/llms.txt
> Use this file to discover all available pages before exploring further.

# Verifiable Randomness

> How Switchboard VRF ensures provably fair race outcomes

## 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

<Info>
  Unlike traditional online games where you must trust the operator, VRF provides mathematical proof of fairness.
</Info>

***

## How It Works

<Steps>
  <Step title="Request">
    When entries close, the protocol requests randomness from the Switchboard oracle network
  </Step>

  <Step title="Generation">
    Multiple independent oracle nodes generate random values and cryptographic proofs
  </Step>

  <Step title="Verification">
    The network validates proofs and commits a 256-bit random seed on-chain
  </Step>

  <Step title="Resolution">
    The seed deterministically determines:

    * Winner (1st place)
    * 2nd and 3rd place
    * Jackpot triggers
    * Next race track selection
  </Step>
</Steps>

***

## 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.

<Card title="Verify Past Races" icon="search" href="https://solscan.io">
  Use any Solana explorer to inspect VRF seeds and race outcomes
</Card>

***

## Security Guarantees

### What VRF Prevents

<CardGroup cols={2}>
  <Card title="Prediction" icon="crystal-ball">
    Impossible to know outcomes before VRF generation
  </Card>

  <Card title="Manipulation" icon="hand">
    Cannot influence results without invalidating cryptographic proof
  </Card>

  <Card title="Selective Publishing" icon="filter">
    All requested randomness must be published on-chain
  </Card>

  <Card title="Replay Attacks" icon="repeat">
    Each race has unique inputs preventing seed reuse
  </Card>
</CardGroup>

***

## FAQ

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="What if oracles collude?">
    Switchboard uses multiple independent oracle operators. Collusion would require compromising a majority of nodes simultaneously, which is economically irrational.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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 — 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.
  </Accordion>

  <Accordion title="Where does the very first seed come from?">
    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.
  </Accordion>
</AccordionGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="How It Works" icon="gears" href="/core-concepts/how-it-works">
    See the complete race cycle
  </Card>

  <Card title="Track Types" icon="road" href="/core-concepts/track-types">
    Understand probability distributions
  </Card>
</CardGroup>