How It Works#

Purpose: This section explains how the Seesaw protocol behaves — the lifecycle a market moves through, how prices are determined, and why outcomes are trustworthy — so you can reason confidently about what will happen and why. It is not a how-to; for step-by-step instructions see For Traders or the SDK docs.

How a Seesaw market works end to end: the lifecycle, oracle integration, order matching, and settlement.

The Core Concept#

Seesaw creates binary prediction markets - markets with exactly two outcomes:

Market Timing#

Every market follows a precise cadence based on its configured duration and Unix timestamps. Durations range from 60 seconds to 7 days (default: 15 minutes):

market_id = floor(unix_timestamp / duration_seconds)
t_start   = market_id × duration_seconds
t_end     = t_start + duration_seconds

Example Timeline (UTC) — 15-minute markets#

Multiple markets with different durations can run concurrently for the same asset (e.g., a 1-minute and a 1-hour SOL/USD market).

Complete Lifecycle#

Note: create_market atomically initializes the market account and captures the start price from Pyth, transitioning through the transient CREATED state directly into TRADING.

Note on EXPIRED: expire_market first attempts a real UP/DOWN resolution (late-capturing the end price from the oracle if needed). Only when no acceptable oracle sample exists does it fall back to EXPIRED, where both YES and NO redeem at 50%. See Oracle Integration.

State Details#

Price Mechanics#

Shares are priced between 0 and 1 USDT (stored as basis points internally):

The Probability Relationship#

Since YES and NO are complementary:

P(YES) + P(NO) = 100%

If YES trades at 0.60:
└── Implied P(UP) = 60%
└── NO should trade at 0.40
└── Implied P(DOWN) = 40%

Order Book Mechanics#

Seesaw uses a single unified order book for YES shares. NO orders are automatically converted by price complement so all liquidity concentrates in one place, eliminating YES/NO fragmentation and arbitrage. For the full conversion table, order types, tick-rounding rules, and matching algorithm, see Order Book.

Oracle Integration#

Seesaw uses Pyth Network for price data:

Sampling Rules#

Start Price (P_start):

• First Pyth update where publish_time >= t_start
• Must have positive price
• Immutable once captured

End Price (P_end):

• First Pyth update where publish_time >= t_end
• Must have positive price
• Immutable once captured

Resolution Logic#

if P_end >= P_start:
    outcome = UP
else:
    outcome = DOWN

Important: Equality (no change) resolves as UP.

Collateralization#

Every share in circulation is backed 1:1 by USDT. Shares are created only by pair-minting: depositing 1 USDT into the market vault mints 1 YES and 1 NO. Trades then move those already-backed shares between users — a fill is an escrow transfer, never a mint:

For the complete picture of where money sits at every stage, see Flow of Funds.

Solvency Invariant#

The vault always holds enough to pay all possible winners:

vault_balance >= max(total_yes_shares, total_no_shares) + accumulated_creator_fees

This ensures the protocol can always settle regardless of outcome.

Fee Structure#

Seesaw uses a capped-linear-decay taker fee curve. Makers pay zero. Only takers (the incoming order that matches against a resting order) pay, and the rate shrinks as the fill price approaches 1.00. Every taker fee is split three ways: 50% to the protocol treasury, 10% to the market creator, and 40% to the taker's referrer (or back to the protocol if none). For the full fee and split tables, see Treasury and Fee Split.

Settlement Process#

After resolution, winners claim their payouts.

Important: Claim within 7 days of resolution. After that, the market is eligible for permissionless cleanup, and unclaimed positions can ultimately be forfeited to the market creator at teardown. See Settlement for the full deadline rules and safety nets.

Related Documentation#

• Order Book Details - How the matching engine works
• Slippage & Fill Estimation - How fill previews, price impact, and slippage are computed
• Oracle Integration - The Pyth push-vs-pull deep dive: sampling, validation, and the 2026 cutover
• Settlement Rules - Claim process, the 7-day deadline, and edge cases
• Flow of Funds - Where your money lives at every stage
• Maker Price Band - How resting maker prices are constrained
• Referrals - On-chain attribution and payout for the 40% referrer slice
• Treasury and Fee Split - How the 50% protocol-treasury slice routes to 8 admin-configured accounts