Skip to main content

​
Security Model

horse.fun is built with security-first principles:

VRF Randomness

Cryptographically secure, verifiable on-chain

Solana Security

Inherits Solana’s BFT consensus security

Checked Arithmetic

Rust checked math and Anchor account constraints

On-Chain Transparency

All operations verifiable

​
Threat Model

​
Considered Adversaries

  1. Financial adversary: Can place arbitrary entries
  2. Network adversary: Can observe transactions
  3. Collusion: Multiple players coordinating
  4. MEV searcher: Can reorder transactions

​
Not Considered

  • Solana validator compromise (beyond BFT assumptions)
  • Cryptographic breaks of VRF
  • Protocol bugs (assume correct implementation)

​
Attack Vectors & Mitigations

Attack: Predict or influence race outcomesMitigation:
  • VRF unpredictable before commit
  • Cryptographic proof ensures validity
  • No party can manipulate seed
Conclusion: Cryptographically impossible
Attack: Large entries to manipulate payout ratiosMitigation:
  • Self-balancing system
  • Heavy entries reduce own payout ratio
  • 5% fee makes manipulation unprofitable
Conclusion: Economically unfeasible
Attack: Capture jackpot payouts with minimal stake — out-positioning winners in an active race, or placing dust entries on every horse in near-empty races so any trigger landing there pays out aloneMitigation:
  • The volume gate voids triggers in races below the minimum-volume threshold, turning the empty-race strategy into a recurring qualification cost with negative expected return
  • Within eligible races, distribution requires a committed entry on the winning horse (placed BEFORE the VRF resolves), and the share scales with entry size — token holdings alone cannot capture the jackpot with a dust entry
  • Stake weights are frozen at entry close, so observing a trigger on-chain during the race phase can change neither the boost nor the burn
  • The token burn on wins consumes the winner’s staked tokens, rotating the advantage over time
Conclusion: Cannot exploit after trigger; empty-race camping has negative EV
Attack: Inflate volume to farm tokens and dominate jackpot distributionMitigation:
  • Emission is volume-linked but capped per race
  • Minting tokens requires paying the protocol fee on the committed volume, so farming is self-limiting
  • The volume gate prevents self-generated low-volume races from recapturing their own jackpot contributions, keeping the effective cost of volume inflation at its full fee rate
  • Jackpot burns (10% normal / 50% super) create deflationary pressure on large staked holders
Conclusion: Economically self-limiting
Attack: MEV searchers reorder entries within a block; sophisticated players wait until the last moment to enter with full knowledge of the pool distributionMitigation and design position:
  • All entries are committed before the VRF is requested, and entry ordering doesn’t affect outcomes or payouts — classic MEV extraction has no surface
  • Late entries with full pool information are possible and deliberately so: probabilities and pool distributions are public to every participant by design, so a late player’s advantage is informational skill, not privileged access — the same dynamic as any pari-mutuel market, where payout ratios move until post time
  • Value-seeking players sharpen the pools, and the protocol fee applies to them like everyone else
Conclusion: No exploitable MEV; late entries are priced in transparently
Attack: Create multiple identities for referral farmingMitigation:
  • Referral rewards only 1% of volume
  • Requires actual play (pays the 5% protocol fee)
  • Self-referral unprofitable
Conclusion: Economically deterred

​
Security Properties

​
Formal Guarantees

  1. Outcome Fairness: the finishing order follows the Plackett-Luce distribution induced by the permuted weights and is deterministically verifiable on-chain. Each horse wins with its assigned probability: Pr⁡(horse i wins∣σ)=pσ(i)\Pr(\text{horse } i \text{ wins} \mid \sigma) = p_{\sigma(i)}
  2. Payout Correctness: every unit of the prize allocation is accounted for — paid to winners or routed to the buyback: ∑upayoutu+rollover=0.90⋅B+Jtriggered\sum_u \text{payout}_u + \text{rollover} = 0.90 \cdot B + J_{\text{triggered}}
  3. Token Conservation: total supply equals the premint plus all volume-linked emissions, minus the burns from both sinks: S(t)=Spremint+∑rEr−∑β⋅Ru−burnbuyback(t)S(t) = S_{\text{premint}} + \sum_r E_r - \sum \beta \cdot R_u - \text{burn}_{\text{buyback}}(t)

​
Implementation Security

  • Rust with Anchor framework
  • Integer overflow protection
  • Access control on admin functions
  • Multi-sig wallet for upgrades

​
User Security Best Practices

  • Use hardware wallets for large amounts
  • Never share private keys
  • Verify transaction details before approving
  • Use reputable wallets (Phantom, Solflare)
  • Always check URL (official: horse.fun)
  • Never enter seed phrase on websites
  • Beware of fake social media accounts
  • Verify contract addresses
  • Choose entry sizes appropriate to your budget
  • Use proper position sizing (1-5% per race)
  • Keep entry sizes consistent regardless of recent results

​
Incident Response

In case of security issues:
  1. Report: security@horse.fun
  2. Emergency Pause: Multi-sig can pause the protocol if needed
  3. Community Alert: Immediate notification via all channels

​
Next Steps

VRF Technical

Deep dive into VRF security

Smart Contracts

Contract architecture

Economic Analysis

Expected value and protocol sustainability

FAQ

Common questions answered