Skip to main content

Threat Model

Detailed analysis of attack surfaces and mitigations.

Adversary Model

Capabilities

CapabilityDescriptionRisk Level
Arbitrary TransactionsCan submit any valid Solana txHigh
Sybil AccountsCan create unlimited walletsMedium
Flash LoansLarge capital for single txMedium
MEV ExtractionFrontrun/sandwich attacksMedium
Market ManipulationTrade to move pricesMedium

Limitations

LimitationAssumptionConfidence
Forge SignaturesEd25519 secureVery High
Break PythOracle honestHigh
Control SolanaNetwork honestHigh
Infinite CapitalFinite per txHigh

Attack Surfaces

1. Instruction-Level Attacks

InstructionAttack VectorMitigation
create_marketSpam creationRent cost limits
place_orderOrderbook manipulationSolvency constraints
place_orderSelf-trade washSelf-trade prevention
cancel_orderUnauthorized cancelOwner signature
snapshot_*Oracle manipulationPyth security
resolve_marketWrong outcomeDeterministic logic
settle_positionDouble claimSettled flag
close_marketPremature closeAll-settled check

2. Economic Attacks

AttackDescriptionMitigation
Naked ShortSell without owningBalance validation
Undercollateralized BuyBuy without fundsCollateral locking
Oracle Front-runningTrade on future pricesPyth latency
Market CornerAccumulate to manipulateNo position limits (v1)

3. Protocol-Level Attacks

AttackDescriptionMitigation
ReentrancyCallback during executionSolana locks, no callbacks
Integer OverflowArithmetic overflowChecked math
PDA CollisionSame PDA, different purposeUnique seed prefixes
Account ConfusionWrong account typeDiscriminator checks
Rent DrainForce account closureRent-exempt accounts

4. Operational Attacks

AttackDescriptionMitigation
Crank DoSPrevent lifecycleMultiple operators
Treasury DrainExhaust crank rewardsCapped rewards
State BloatCreate many accountsRent costs

Detailed Mitigations

Reentrancy Protection

Solana's runtime provides inherent protection:

  1. Account Locking: All accounts locked for transaction
  2. No Recursive CPI: Cannot borrow mutably twice
  3. No Token Callbacks: Unlike ERC-777, SPL Token has no hooks
  4. Idempotency: Settlement checks settled flag first

Oracle Security

Price validation:

fn validate_price(price: &PythPrice, boundary: i64) -> Result<()> {
    // Positive price
    require!(price.price > 0, Error::InvalidPrice);

    // Published after boundary
    require!(price.publish_time >= boundary, Error::StaleOracle);

    // Optional confidence check
    if max_confidence_ratio > 0 {
        let ratio = price.conf * 10000 / price.price.abs();
        require!(ratio <= max_confidence_ratio, Error::ConfidenceTooWide);
    }

    Ok(())
}

Solvency Enforcement

Invariant:

vault.balance >= max(total_yes_shares, total_no_shares)

Audit Findings

Finding 1: Oracle Price Staleness

Concern: Stale Pyth prices could affect resolution.

Status: Mitigated

Mitigation: Sampling Rule A enforces:

  • Start snapshot: publish_time >= t_start
  • End snapshot: publish_time >= t_end

Finding 2: Settlement Double-Claim

Concern: Users could settle multiple times.

Status: Mitigated

Mitigation: Atomic settled flag:

if position.is_settled() {
    return Ok(()); // No-op
}
// ... calculate payout ...
position.set_settled();

Finding 3: Crank Liveness

Concern: Markets stall if no cranks available.

Status: Accepted Risk

Rationale:

  • Permissionless operation
  • Incentivized with rewards
  • Multiple operators expected
  • Force close fallback

Finding 4: Epoch Boundary Race

Concern: Clock drift at boundaries.

Status: Mitigated

Mitigation: Inclusive bounds (>=) prevent gaps.

Finding 5: Price Conversion Precision

Concern: NO to YES conversion precision loss.

Status: Mitigated

Mitigation:

  • Exact integer arithmetic
  • Protocol-favorable rounding
  • Comprehensive test coverage

Known Limitations (v1)

LimitationDescriptionFuture
No position limitsUnlimited accumulationAdd optional limits
Single oracleOnly PythMulti-oracle support
64 order limitPer side per marketExpand capacity
Full collateralNo leverageAdd margin

Incident Response

Severity Levels

LevelDescriptionResponse Time
P0Funds at riskImmediate
P1Potential loss< 4 hours
P2Non-critical< 24 hours
P3Minor issue< 1 week

Response Procedure

  1. Detect: Identify the issue
  2. Assess: Determine severity and scope
  3. Mitigate: Pause if possible
  4. Fix: Deploy remediation
  5. Disclose: Coordinate public disclosure

Next Steps