Skip to main content

Risks & Security

Status: Active Audience: Grant reviewers, security researchers, internal team Related: build-plan.md · milestones.md

Security Philosophy

Onchain perpetuals custody user funds and manage leverage. Security is not a feature - it is the minimum bar. Our approach is defense-in-depth at the protocol level, with explicit threat modeling, automation testing, and a staged security review roadmap.

Common Attack Surfaces

#Attack SurfaceSeverityMitigation
1Oracle manipulation - attacker moves Pyth price to trigger wrongful liquidations or extract profitCriticalUse Pyth EMA price (not spot); apply deviation circuit breaker (reject >X% moves in one update); require multiple confidence-interval checks
2Oracle staleness - stale price causes under-collateralized positionsCriticalEnforce max oracle age (e.g., 30s); reject trades if price feed is stale; pause market if no update within 120s
3Missing signer verification - instruction executes without verifying user signed the transactionCriticalExplicit is_signer checks on all accounts that transfer funds or modify positions; Anchor #[account(signer)] on all user-controlled accounts
4CPI target validation - Cross-Program Invocation redirects to malicious programCriticalHardcode target program IDs in constants; validate program_id before every CPI; reject dynamic program IDs from user input
5Compute budget exhaustion - complex matching runs out of CU mid-transactionHighBatched matching with per-batch CU budget; early CPI budget audit; pre-compute worst-case CU per order type
6Slab data structure bugs - corrupted order book leads to incorrect matchingHighFormal verification of slab insert/remove/scan operations; property-based tests (quickcheck); Bankrun integration tests with adversarial order sequences
7Crank / queue stalling - order book matching queue halts if incentives too low or congestion highHighInline matching in place_order (no separate crank); priority fee bidding for time-sensitive ops; fallback keeper network for stale queue detection
8State bloat & rent exhaustion - dust orders inflate protocol state, hit account size limitsHighMinimum order size enforcement; rent-exempt calculations with buffer; auto-close expired orders; account resizing via reallocation
9Flash loan / price manipulation - attacker uses transient capital to move mark priceHighMark price uses TWAP + EMA (not instantaneous); liquidations require minimum profitability; no flash-loan composability in MVP
10Funding rate manipulation - whales manipulate perp price to extract risk-free funding payoutsHighTWAP-based funding rate (not instantaneous mark); clamp funding rate magnitude; max position caps per account; monitor for correlated position clusters
11Socialized loss from bad debt - underwater positions exceed insurance fundHighADL (auto-deleveraging) as hard backstop; aggressive liquidation parameters (105% maintenance margin); maximum leverage capped at 10x for MVP
12Upgrade authority compromise - attacker deploys malicious program upgradeHighMulti-sig upgrade authority (3-of-5); 48-hour timelock on upgrades; immutable programs where possible (no upgrade flag on core matching)
13Frontrunning / MEV - validators or searchers extract value from order flowMediumCommit-reveal for large orders (post-MVP); order ID derived from trader key - no private order book state; match events visible on confirmation
14Account reinitialization - attacker reinitializes a closed account to steal fundsMediumAnchor init_if_needed guards; discriminator checks on all account deserialization; close-program enforces rent recovery
15Integer overflow / underflow - arithmetic bugs in PnL or margin calculationsMediumChecked math (SafeMath or Rust overflow checks) in all financial calculations; integration tests that verify boundary positions
16Frontend / DNS hijacking - compromised UI redirects user approvals to malicious addressMediumSubresource integrity (SRI) on all CDN assets; decentralized hosting (IPFS/Arweave); domain monitoring (DNSSec, CAA records); user education on payload verification

Solana-Specific Implementation Hardening

The following patterns must be enforced across all Anchor programs to mitigate Solana-specific attack vectors:

CheckWhereEnforcement
Signer verificationEvery instruction modifying user state (margin, positions, vault shares)#[account(signer)] on user accounts; explicit is_signer runtime checks for any account transferring lamports or tokens
Account ownershipAll account deserializationVerify account.owner == program_id before deserializing; use Account::try_from with owner check
Account discriminatorsAll account typesAnchor discriminator (8-byte) on every account; reject accounts with mismatched discriminator
CPI target validationEvery Cross-Program InvocationTarget program ID as constant; validate program_id matches expected before invoke_signed
Rent-exempt sizingAccount initialization & resizingRent::get()?.minimum_balance(size) + 20% buffer; enforce minimum order sizes to prevent dust spam
Checked arithmeticAll financial math (PnL, margin, funding, fees)checked_add, checked_sub, checked_mul, checked_div; fixed-point with explicit precision constants
Account close safetyclose_account instructionsRequire is_signer on authority; verify zero lamports/token balance before close; recover rent to owner

Security Roadmap

During Development

PhaseActivity
M1Threat model documented (this document); attack surface enumerated
M2Property-based tests for slab matching; Bankrun integration suite with adversarial scenarios
M3Chaos tests (oracle stall, partial fill floods, rent edge cases); targeted external review of liquidation math ($15k budget)
M4Friends-and-family test program ($12k budget); internal triage of reported issues; open-source release enables community review

Mainnet

ActivityDetail
Bug bounty on ImmunefiBounty pool, focused on critical + high severity
Full professional auditTo be completed before mainnet deployment
Operational runbookIncident response, key management, upgrade procedure documented
Public post-mortemsEvery incident published within 7 days

Audit Strategy

A full professional audit will be completed before mainnet deployment. Our strategy:

  1. During grant - targeted external reviews + continuous open-source community review
  2. Before mainnet - full professional audit (funded separately by the Solana Foundation)
  3. Post-launch - ongoing bug bounty program

Operational Risks

RiskLikelihoodImpactMitigation
Insufficient MM liquidityMediumHigh - CLOB needs two-sided flowReference MM bot ships in M4; MM partnerships in Post-M4; liquidity mining incentives
RPC / Geyser downtimeMediumMedium - trading pausedMulti-provider failover (Triton + Helius); local fallback RPC
Regulatory uncertaintyLowHigh - forced shutdownDeployed as fully onchain; no KYC in MVP; DAO governance path for fee setters
Team attritionLowMedium - timeline slipAll code is open-source; collective code ownership (no bus-factor 1)
Solana network congestionMediumMedium - failed transactionsPriority fee bidding in SDK; transaction retry with increasing fees
Frontend / DNS hijackingLowCritical - funds drained via UISRI on CDN assets; decentralized hosting (IPFS/Arweave); DNSSec/CAA; user payload verification education

Incident Response Plan

  1. Detection - onchain monitoring (insurance fund balance, open interest spikes, failed match sequences) + community reports
  2. Triage - on-call engineer assesses severity within 15 minutes
  3. Containment - pause market (via multi-sig, bypass 48h timelock for emergency) if funds at risk
  4. Resolution - patch + deploy via normal upgrade path
  5. Post-mortem - published within 7 days; root cause, timeline, fixes applied
  6. Bug bounty payout - if applicable, within 30 days of confirmed report

Insurance Fund

  • Capitalization source: 100% of liquidation penalties flow to the insurance fund
  • Target size: 5% of open interest (monitored weekly)
  • Governance: Protocol-level, no human discretion on payouts
  • Solvency: If insurance fund drops below 1% of OI, ADL triggers on all positions and new position opening is blocked until recapitalized