Threat Model#

Detailed analysis of attack surfaces and mitigations.

Adversary Model#

Capabilities#

Limitations#

Trusted and Semi-Trusted Roles#

Attack Surfaces#

1. Instruction-Level Attacks#

2. Economic Attacks#

3. Protocol-Level Attacks#

4. Operational Attacks#

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 applies the following checks to every oracle reading before it is accepted:

• Positive price: the price must be greater than zero, otherwise the reading is rejected (InvalidPrice).
• Published after the boundary: the reading's publish_time must be at or after the relevant snapshot boundary, otherwise it is rejected as stale (StaleOracle). The reading's prev_publish_time is also used to prove it is the first price at or after the boundary (Sampling Rule A).
• Optional confidence gate: when a confidence limit is configured, the ratio of the reading's confidence interval to its price must fall within that limit, otherwise the reading is rejected.

The protocol reads the Pyth PriceUpdateV2 account directly at fixed byte offsets (it does not depend on a Pyth client SDK), verifies the account's discriminator and verification level, then extracts the price, confidence, exponent, and timestamps before applying the checks above.

Solvency Enforcement#

Invariant:

vault.balance >= max(total_yes_shares, total_no_shares) + accumulated_creator_fees

Known Considerations and Mitigations#

This section calls out subtle risk areas integrators sometimes ask about, and how the protocol handles each.

Oracle Price Staleness#

Consideration: Stale Pyth prices could affect how a market resolves.

How it is handled: Sampling Rule A requires the first price at or after each boundary:

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

A reading published before the boundary is rejected, and the candidate's predecessor timestamp is used to confirm it is the first qualifying price.

Settlement Double-Claim#

Consideration: A user might try to settle the same position more than once.

How it is handled: Each position carries a settled flag that is checked first; once settled, further settlement calls are no-ops with no additional payout. See the idempotency code in Architecture Security → Reentrancy Protection.

Crank Liveness#

Consideration: A market could stall if no one performs its lifecycle operations (snapshotting, resolution, settlement).

How it is handled: All lifecycle operations are permissionless and reward-incentivized, so anyone can perform them, and multiple independent operators are expected. A force-close fallback exists for positions in markets that are not resolved within the expiration window.

Settlement-Token Issuer Freeze#

Consideration: The current Solana beta uses a single settlement mint per market. If that mint has an active freeze authority, the issuer can freeze a market vault PDA or a user's associated token account. A frozen treasury recipient can be bypassed by routing protocol fees to another configured recipient shard, but a frozen market vault or payout destination blocks the affected SPL Token transfer until the issuer unfreezes the account.

How it is handled: This is an accepted settlement-asset tail risk, not an on-chain bug. The program cannot override an issuer freeze. Operators must:

• monitor live market vault addresses and known payout/treasury addresses against the issuer's freeze or blacklist surface;
• keep a tested stablecoin-default rotation path for new markets via UpdateMarketDefaults (0x32);
• communicate that affected redemptions or fee claims are blocked by the settlement token program until unfreeze, while unrelated markets continue normally;
• treat per-asset settlement allowlists and multi-mint risk controls as a v-next structural improvement.

Epoch Boundary Race#

Consideration: Clock drift near epoch boundaries could create timing gaps.

How it is handled: Boundaries use inclusive comparisons (>=), so there is no gap between consecutive epochs.

Price Conversion Precision#

Consideration: Converting NO-side quotes to the canonical YES book could lose precision.

How it is handled: Conversions use exact integer arithmetic with protocol-favorable rounding, backed by extensive test and property-test coverage.

Known Limitations (v1)#

What to Expect If an Issue Occurs#

Because every protocol rule is enforced on-chain, a transaction that would violate an invariant simply fails rather than committing bad state. For broader issues, the protocol exposes safety controls and a disclosure process you can rely on:

• Trading can be halted. The protocol can be paused globally (Pause) or restricted per market (SetMarketEmergencyStatus, including a post-only mode that lets makers cancel but blocks new aggressive flow). The separate pauser guardian is escalation-only: it can halt or make a market more restrictive, but it cannot unpause, clear emergency state, or rotate itself. Pausing stops new trading while a fix is prepared; it does not seize user funds.
• Funds remain fully collateralized. Every share is backed by collateral held in the market vault, and solvency is enforced at runtime, so a pause or delay does not put deposited collateral at risk.
• Markets have a force-close fallback. Positions in a market that is not resolved within its expiration window can be force-closed permissionlessly, so funds are not stranded if normal lifecycle operations stall.
• Vulnerabilities are handled under responsible disclosure. If you find a security issue, report it privately (see Reporting Vulnerabilities) and allow time for a fix before any public disclosure.

Next Steps#

• Review Invariants for formal guarantees
• See Architecture Security for implementation