Skip to main content

​
How Slip settles a market

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

​
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, replaces model prose with canonical copy, preserves validated caller labels, mechanically builds three-way result bands, and rejects incoherent expressions or partitions. Untrusted fixture and request values are serialized as JSON data rather than interpolated as instructions. 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. Provider authentication, rate limits, unavailable service, malformed output, timeout, caller cancellation, unsupported semantics, and invalid input have separate stable failure codes. Public errors never include provider request or response bodies. 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.
The market stores a domain-separated SHA-256 commitment to the exact proof argument plus market, resolver, and TxLINE roots addresses. Judges and clients can recover the full resolution instruction from Solana and rebuild the commitment with calculateResolutionEvidenceHash without expanding every market account. TxLINE aggregate proofs do not provide a canonical event-order/zero witness, so the compiler rejects first-event markets instead of exposing an unresolvable path.

​
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.