Skip to main content

How Slip settles a market

Slip separates product intent, chain execution, and sports truth.
User language


AI SDK structured-output compiler
    │ semantic concept + complete integer bands

SDK canonical TxLINE mapping and validation
    │ MarketExpression + labels + bands

Solana Market PDA ◄──── variable USDT stakes in market vault

    │ after entry close and resolve_at

Keeper or any resolver

    ├── TxLINE score snapshot: terminal-state decision
    └── TxLINE stat-validation: one- or two-stat Merkle proof


                          Slip program proof walk


                    TxLINE daily_scores_roots PDA

                     winning outcome or forced void


                     proportional claims / refunds

Product boundary

The web retrieves fixtures through TxlineClient and markets through SlipClient. It never fills missing upstream data with sample fixtures. Natural language is sent to the server-side AI SDK compiler, never directly from the browser to a provider. Zod validates structured output; a second deterministic pass derives canonical stat keys and rejects incoherent expressions or bands. The system prompt is assembled from named stat-selection, expression, partition, and settlement safety skills plus diverse worked examples. Those modules improve interpretation but have no path around the schema or deterministic validator. The model is an interpreter, not a settlement authority. It cannot choose fixture IDs, raw stat keys, fees, stakes, deadlines, proofs, or results. The complete Rulebook is shown before a wallet signs. Browser writes pass through the SDK instruction boundary, simulate, ask for a Wallet Standard signature, submit, and wait for confirmation.

Program boundary

The program stores the complete expression, outcome labels, and integer bands. Stakes move through classic SPL Token instructions into an ATA owned by the market PDA. The only settlement inputs not already committed in the market are the TxLINE proof and the resolver account that receives the disclosed tip. The program verifies:
  1. the stat leaf or leaves fold to the supplied event root;
  2. the event root folds to the fixture subtree root;
  3. the tagged fixture summary leaf folds to the daily root;
  4. the root equals the epoch-day PDA’s committed five-minute slot;
  5. the fixture, stat keys, second-stat shape, timestamp, and terminal phase match the market.

Keeper boundary

The keeper scans open markets and caches fixture terminal status during a pass. One-sided markets can void after entry closes. A market with two or more funded outcomes resolves when TxLINE reports a terminal state. Transient API, proof, or RPC errors enter durable backoff; they are not evidence for an early refund. A non-terminal funded market can void only after its explicit void_at deadline.

Trust and upgrade boundary

No market instruction takes an admin authority that can redirect escrow. The fee treasury and TxLINE program address are compile-time constants. The Solana program itself is upgradeable on devnet, so a production no-admin claim also requires the upgrade authority to be made immutable or governed under the deployment’s disclosed policy.