đźš§ SportsPerp is currently live on devnet. Mainnet target: before Jun 12, 2026 (World Cup kickoff).
RisksSmart Contract Risk

Smart Contract Risk

SportsPerp’s smart contract is ~6,354 lines of Rust with 30 instructions, 7 account types, and 47 error codes. It is written with defensive discipline, extensively tested, and has undergone a thorough internal audit. It has not yet been externally audited. This page documents the risks honestly.

What could go wrong

Smart contract bugs fall into a few categories:

CategoryWhat it meansExample
Logic bugsMath or state transition doesn’t match intentA liquidation formula returns the wrong threshold
Reentrancy / CPI abuseAn external program call re-enters the handler with unexpected stateSPL token program misuse (Anchor prevents most of this)
Account validation bugsWrong or missing PDA derivation / ownership checksAn attacker spoofs a vault account
Overflow / underflowArithmetic exceeds type boundsu64 + u64 wraps silently
Economic attacksIntended mechanics produce unintended outcomesFlash-loan-style manipulation of mark price

What mitigations are in place

Language and framework discipline

  • No unsafe Rust. The entire program is safe Rust. No raw pointer manipulation, no uninitialized memory.
  • All arithmetic is checked_*. checked_add, checked_mul, checked_div everywhere that matters. Overflow surfaces as an explicit MathOverflow error, not undefined behavior.
  • Anchor’s account validation. Every instruction’s account constraints (seeds, owner, is_signer) are enforced by Anchor at the framework level, not at the handler level. Bypassing them requires bypassing Anchor itself.
  • Fixed-point integer math only. No floats. See Fixed-Point Math.

Testing

  • 70+ Rust unit tests (programs/obv-perps/src/math/*.rs #[cfg(test)]).
  • ~30 Anchor integration tests (tests/obv-perps.ts).
  • 28 Phase 5 risk-engine tests covering 9 risk scenarios.
  • 72 E2E tests against live devnet across 12 .test.ts files — full trade lifecycles, partial-close, liquidations, sunset (incl. extended), triggers, pool-solvency, risk-floor gate, S4-01 expiry regression.
  • ~73 SDK parity tests verifying TypeScript math matches Rust math bit-for-bit.
  • ~258 engine Vitest tests across 30+ suites — composite math, EMA blender, live-processor replay, ID bridge, shadow pipeline, candle store, WS server.

Every PR runs the full suite before merge. Every devnet deploy runs the E2E suite on the candidate binary before promotion.

Internal audit

A full self-audit was completed April 17, 2026. 17 findings across all severity levels. 1 Critical and 5 High — all fixed. The remaining 11 are Medium/Low/Informational and documented. See Self-Audit Summary.

Admin surface is narrow and keyed

Admin instructions (pause_market, update_market_params, deposit_insurance, etc.) are gated on a single keypair today. On mainnet this moves to a 3-of-5 multi-sig with 48-hour timelock on parameter changes. The upgrade authority follows the same path.

An admin-key compromise on devnet would be bad but recoverable (re-initialize markets, redeploy program). On mainnet, the multi-sig + timelock materially lowers the attack success probability.

Upgrade authority

The program is upgradeable today (standard Solana upgradeable loader). A critical-severity bug on mainnet could be patched in a coordinated deploy. Long-term, the upgrade authority will move to the same 3-of-5 multi-sig as the admin, and eventually to a timelocked governance contract.

We do not plan to make the program permanently immutable. The trade-off — “freeze the code” vs “ability to fix critical bugs” — strongly favors continued upgradeability given the complexity of the system. Immutability becomes viable only after multiple independent audits, extended mainnet history, and community governance maturity.

What is still not mitigated

No external audit yet

External audits are pending — two Solana-specialist firms will be engaged before mainnet. Until those reports land and findings are remediated, an experienced third party has not independently reviewed the code. This is the largest single open risk.

Mainnet is gated on audit completion. Devnet trading is at the trader’s own risk.

Complex risk logic

The three-layer liquidation cascade, the 18.3% anti-manipulation check, the composite mark EMA, and the TWAP funding mechanism are more complex than most perpetual protocols in existence. More complexity = more corners for bugs to hide.

Mitigation: each piece has dedicated tests; the Phase 5 integration tests exercise the interactions. But integration complexity is not fully collapsable.

Permissionless keepers imply rational actors

Liquidations rely on at least one keeper running. If every keeper goes offline simultaneously and stays offline, underwater positions would remain open until a keeper returns. Our own liquidator bot is one keeper; third-party keepers are welcome and expected post-mainnet.

Mitigation: the incentive structure (5% Layer 1 reward, 3% Layer 2 reward) is strong enough that multiple competing keepers are a realistic equilibrium.

Upgrade authority is a trust point

While upgradeability is a feature (bug fixes), it is also a risk: a compromised upgrade authority could deploy a malicious binary. See above — mainnet multi-sig + timelock.

What we won’t do

  • Obscure the risk. If an audit finds a critical issue, we’ll disclose it publicly with a fix timeline.
  • Ship to mainnet without audit. Devnet is testing ground; mainnet is real capital.
  • Hide admin capability. Every admin instruction is visible on-chain and in the public repo.

How to think about smart contract risk as a trader

Perpetual futures protocols have a track record:

  • Loss-free protocols. Hyperliquid, dYdX v4, Drift v2 (post-audit). All multi-year track records.
  • Loss events in other DeFi primitives. Lending protocols and spot DEXes have had far more incidents than perp DEXes historically. The specific model — USDC collateral, zero-bad-debt cascade, EMA-smoothed mark — has a strong safety record in adjacent protocols.

That said: only trade what you can afford to lose in any new protocol, especially one that hasn’t been externally audited. Devnet USDC has no real value; mainnet positions should be sized accordingly until multiple audits + extended track record build confidence.

Further reading