> ## 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. # Security > Threat model, attack vectors, and security guarantees ## Security Model horse.fun is built with security-first principles: Cryptographically secure, verifiable on-chain Inherits Solana's BFT consensus security Rust checked math and Anchor account constraints 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 outcomes **Mitigation:** * VRF unpredictable before commit * Cryptographic proof ensures validity * No party can manipulate seed **Conclusion:** Cryptographically impossible **Attack:** Large entries to manipulate payout ratios **Mitigation:** * 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 alone **Mitigation:** * 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 distribution **Mitigation:** * 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 distribution **Mitigation 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 farming **Mitigation:** * 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(\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: $$ \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) = 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 * Unit tests for all functions * Integration tests * Fuzzing for edge cases * Mainnet simulations *** ## 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](mailto:security@horse.fun) 2. **Emergency Pause:** Multi-sig can pause the protocol if needed 3. **Community Alert:** Immediate notification via all channels *** ## Next Steps Deep dive into VRF security Contract architecture Expected value and protocol sustainability Common questions answered