Skip to main content

Verifiable Randomness

Every race outcome is determined by Switchboard VRF, a decentralized oracle network that provides cryptographically verifiable randomness.

How It Works

  1. Request: At the end of each entry phase, the protocol requests randomness
  2. Generation: Switchboard oracle nodes independently generate a 256-bit random seed
  3. Verification: The seed is committed on-chain with a cryptographic proof
  4. Resolution: Race outcomes are determined using the verified random seed

Guarantees

  • ✅ Outcomes cannot be predicted before generation
  • ✅ Results are cryptographically verifiable on-chain
  • ✅ No single party can manipulate the outcome
  • ✅ Complete transparency for all participants

Learn More About VRF

Deep dive into the technical implementation of verifiable randomness

Four Distinct Track Types

Each track offers a unique competitive scenario with different risk/reward profiles:

Doubloon Downs - Strong Favorites

Profile: Clear hierarchy with dominant favoriteTop Horse Probability: 24%Strategy: Back favorites for safer, moderate returnsEntropy: 2.98 bits (most predictable)

Stampede Canyon - Balanced Field

Profile: Moderate favorite with competitive mid-tierTop Horse Probability: 18%Strategy: Mid-tier horses offer good valueEntropy: 3.11 bits (moderate)

Synthwave Strip - Pure Chaos

Profile: Wide open race, anyone can winTop Horse Probability: 14%Strategy: Rewards skilled pool analysisEntropy: 3.16 bits (most unpredictable)

Crown Meadows - Dark Horses

Profile: Slight favorite with strong underdogsTop Horse Probability: 17%Strategy: Balance between safety and valueEntropy: 3.13 bits (moderate-high)
Track selection is determined by the VRF seed from the previous race, ensuring unpredictability. All tracks have equal probability (25% each) over time.

Pari-Mutuel Pool System

Pari-Mutuel System

What Makes It Special?

In the pari-mutuel model, no operator ever sets the payout ratios — the players do. The system:
  • Pools all entries together into a collective prize pool
  • Divides winnings proportionally among winners based on entry size
  • Self-balances: Popular horses yield lower returns per entry
  • No operator advantage: the protocol only distributes the pooled funds — it never takes a position of its own

Understanding Pari-Mutuel

Learn how payouts are calculated and prize distribution works

Dual Progressive Jackpots

Two independent jackpot pools accumulate from every race and distribute to lucky winners:

Blazing Hoof (Normal Jackpot)

Trigger Probability: 1 in 125 races (0.8%)Expected Frequency: ~5.2 hours between triggersAccumulation: 2% of total entry volume per raceToken Burn: 10% of winner’s staked HORSE
With 576 races per day, Blazing Hoof triggers approximately 4-5 times daily, ensuring frequent excitement and player rewards.

Distribution Model

Each winner’s share is proportional to their entry, boosted linearly by their staked HORSE:
score = (your entry on the winning horse) × (1 + λ × your staked HORSE)
your share = jackpot × score / (sum of all winners' scores)
The entry is the ticket, tokens are the multiplier: a winner with no staked HORSE still gets their entry-proportional base share, while staked HORSE multiplies it — with no point of diminishing returns. Staked amounts are snapshotted at entry close. A trigger pays out only in races above the volume-gate threshold.

Jackpot Details

Explore the complete jackpot mechanics and distribution formulas

HORSE Token Economy

Token Flow Diagram

Volume-Linked Emission

HORSE is minted per race in proportion to that race’s entry volume, capped per race:
E = min(c × volume, cap)      // bootstrap: c = 0.5, cap = 25 HORSE
Your tokens = E × (your entry / total volume)   // = c × your entry below the cap
Because emission tracks real volume, supply is endogenous — it grows only as fast as genuine activity, with no fixed daily or annual issuance.

Deflationary Mechanism

Supply is reduced by two kinds of sink:
SinkRate
Buyback-and-burn1% of every race’s volume buys HORSE and burns it
Blazing Hoof burn (normal)10% of winner’s staked HORSE
King’s Run burn (super)50% of winner’s staked HORSE
The volume-funded buyback offsets emission by construction; jackpot burns are a secondary, staking-dependent sink.

Token Utility

HORSE tokens serve one critical purpose:
Jackpot Distribution: each winner’s jackpot share scales with entry × (1 + λ·staked HORSE). Staking more tokens multiplies your share, with no diminishing returns.
This creates a retention mechanism where active players accumulate and stake tokens that increase their share of future jackpots.

Token Economics

Understand the complete token emission, burning, and utility model

High-Frequency Racing

Race Cycle

Each race lasts 2.5 minutes total:
  • Entry Phase: 120 seconds (2 minutes)
  • Race Phase: 30 seconds

Daily Volume

Races per day: 576
Game rounds per month: ~17,280
Annual races: ~210,240
This high-frequency model ensures:
  • ✅ Constant availability — a race every 2.5 minutes
  • ✅ Frequent jackpot opportunities
  • ✅ Rapid HORSE token accumulation
  • ✅ Dynamic and exciting gameplay

Fee Structure

The protocol operates on a transparent 5% fee on total entry volume:
1

Referral Rewards

Up to 1% allocated to referral incentives
2

Protocol Operations

4% for development, maintenance, and treasury
This 5% fee ensures sustainable protocol development. The remaining 95% goes to players: 90% direct prizes to winners, 4% to progressive jackpots, and 1% to the HORSE buyback-and-burn.

Where Fees Go

  • Smart contract development
  • Switchboard VRF oracle costs
  • Protocol infrastructure and hosting
  • Community incentives and growth
  • Treasury reserves for stability

Fee Breakdown

Detailed explanation of fee allocation and usage

Security & Transparency

On-Chain Verification

All protocol operations are fully verifiable:
  • Race outcomes and winner selection
  • Pari-mutuel payout calculations
  • Jackpot trigger conditions
  • Token minting and burning
  • Fee distribution

Security Features

VRF Integrity

Cryptographic proofs ensure randomness cannot be manipulated

Atomic Transactions

All state transitions execute atomically within Solana transactions

Overflow Protection

Rust’s checked arithmetic prevents integer overflow attacks

Multi-Sig Treasury

Protocol upgrades require multi-signature wallet approval

Security Analysis

Comprehensive security considerations and threat model