> ## Documentation Index > Fetch the complete documentation index at: https://docs.useslip.xyz/llms.txt > Use this file to discover all available pages before exploring further. # SDK and public API > AI Rulebook compilation, TxLINE access, Solana transactions, account reads, and HTTP contracts. # SDK and public API reference Package: `@slip/sdk` ## AI Rulebook compiler `compileMarketRule(options)` calls an AI SDK language model with `generateText` and `Output.object()`. Its Zod schema permits only semantic concepts that Slip can map to canonical TxLINE leaves. | Option | Type | Behavior | | ------------- | ------------------------------------- | ------------------------------------------------------------------------------- | | `model` | AI SDK model or AI Gateway identifier | Required. The SDK does not silently select a provider. | | `text` | `string` | Natural-language market request. Empty input fails. | | `fixture` | `Fixture` | Trusted fixture ID, teams, competition, and kickoff supplied outside the model. | | `abortSignal` | `AbortSignal` | Optional request cancellation. | `createOllamaRuleModel({ model, baseURL })` returns an AI SDK `LanguageModel` for a local or LAN-hosted Ollama server. The default URL is `http://127.0.0.1:11434/api`; remote MBP setups must pass their server-side LAN URL explicitly. The structured output contains: * `supported` and a nullable rejection reason; * one semantic expression kind: team stat, total, home-away difference, or team minimum; * one TxLINE concept: goals, yellow cards, red cards, or corners; * one documented period; * two to five unique outcome labels; * two to eight ordered, contiguous integer bands; * a human-readable Rulebook sentence. The model cannot provide raw stat keys, fixture IDs, fees, deadlines, stakes, proofs, or results. `compileMarketRuleOutput` deterministically maps its semantic output to TxLINE keys and calls `validateRule`. Unsupported, ambiguous, non-integer, incomplete, or incoherent output throws `MarketRuleCompilationError` before an instruction can be built. `RULEBOOK_PROMPT_SKILLS` separates stat selection, expression selection, outcome partitioning, and settlement safety. `RULEBOOK_PROMPT_EXAMPLES` supplies diverse five-band, BTTS, 1X2, red-card, and unsupported-player demonstrations. `buildRulebookSystemPrompt()` assembles both for every provider; no example bypasses schema or deterministic validation. ## Deterministic construction These functions do not call a model: | Export | Behavior | | --------------------- | ---------------------------------------------------------------- | | `statExpression` | One team stat for any supported concept and period. | | `totalExpression` | Home plus away for any supported concept and period. | | `binaryExpression` | Canonical `Add`, `Sub`, or `Min` over the two team leaves. | | `resultExpression` | Home goals minus away goals. | | `bothTeamsExpression` | Minimum of the two team values. | | `thresholdRule` | Complete binary partition for `gt`, `gte`, `lt`, `lte`, or `eq`. | | `resultRule` | Complete three-outcome match-result partition. | | `validateExpression` | Stat key, side, period, fixture, and operation coherence. | | `validateRule` | Expression plus complete outcome partition. | | `validateMarket` | Rule, u64 ID, safe timestamps, and fee configuration. | Validation mirrors program constants: five outcomes, eight bands, 48 UTF-8 bytes per label, 500 fee bps, 200 resolver-tip bps, and a 1,000,000-unit minimum stake. ## TxLINE client `TxlineClient` is browser-safe and uses the real TxLINE HTTP boundary. It owns short-lived guest JWT acquisition, concurrent JWT reuse, one renewal after HTTP 401, API-token headers, timeouts, JSON validation, and precise boundary errors. | Method | Boundary | | ----------------------------------------------- | ----------------------------------------------------------------------------------------- | | `listFixtures(startEpochDay?)` | `GET /api/fixtures/snapshot` | | `getFixture(fixtureId, referenceEpochSeconds?)` | Finds one fixture in the applicable live snapshot. | | `scoreSnapshot(fixtureId)` | `GET /api/scores/snapshot/{fixtureId}` | | `latestSeq(fixtureId)` | Validated latest sequence from the score snapshot. | | `proofForMarket(expression, seq?)` | Stat-validation request plus independent Tier-A verification. | | `activate(options)` | Confirmed subscription callback, exact wallet signature, then `POST /api/token/activate`. | Activation accepts real `subscribe()` and `signMessage()` callbacks because wallet and transaction authority remain application-owned. It rejects missing subscriptions, non-64-byte signatures, and invalid activation responses. ## Solana client ### Instruction builders `SlipClient` exposes: * `createMarketIx` * `buyTicketIx` * `resolveMarketIx` * `claimTicketIx` * `voidMarketIx` These return legacy `TransactionInstruction` objects at the isolated Anchor compatibility boundary. `@slip/sdk/generated` contains the Kit-native Codama output. ### Executed transactions The matching high-level methods are `createMarket`, `buyTicket`, `resolveMarket`, `claimTicket`, and `voidMarket`. They use `executeInstructions` to: 1. obtain a recent blockhash and last-valid block height; 2. assemble required instructions and compute budget; 3. request the application-owned authority signature; 4. simulate with signature verification; 5. submit without skipping preflight; 6. confirm using the blockheight strategy; 7. return signature, simulation compute units, and confirmation slot. `keypairAuthority` adapts a server-side `Keypair`. Browser wallets can implement `TransactionAuthority` or continue using the instruction builders with Wallet Standard tooling. Buy, resolve, and claim prepend idempotent SPL-token ATA creation for required user, resolver, treasury, and refund destinations. ### Accounts * `getMarket`, `getTicket`, `listMarkets`, `listTickets` * `listMarketsPage`, `listTicketsPage` * `watchMarkets`, `watchTickets` * `marketAddress`, `ticketAddress`, `rootsPda` Page cursors are ordered account public keys. Solana core RPC still performs one `getProgramAccounts` scan because it provides no server-side limit or cursor. The SDK states this explicitly; production indexing requires a real Geyser or indexed RPC boundary. ## Money helpers | Export | Return | | ----------------- | ---------------------------------------------------------- | | `settlement` | Integer total, fee, tip, and net. | | `marketOdds` | Probability bps and decimal-odds strings for each outcome. | | `projectedPayout` | Floored payout, or `null` for zero winning liquidity. | | `validateStake` | u64 range and one-USDT minimum validation. | All token arithmetic uses `bigint`. No floating-point token calculation enters the SDK. ## Public HTTP API All routes are uncached and CORS-readable. Live-boundary failures do not return sample data. | Route | Response | | ------------------------------- | ----------------------------------------------------------------- | | `POST /api/v1/compile` | AI-compiled, schema-validated Rulebook for a live TxLINE fixture. | | `GET /api/healthz` | Solana program and TxLINE health. | | `GET /api/v1` | Deployment and Rulebook-compiler capabilities. | | `GET /api/v1/openapi.json` | OpenAPI 3.1 document. | | `GET /api/v1/fixtures` | Future TxLINE fixtures. | | `GET /api/v1/markets` | Unified Solana markets with fixture metadata and tickets. | | `GET /api/v1/markets/{address}` | One market by Solana address. | The compile route returns 422 when language cannot become a supported market and 503 when AI or TxLINE configuration is unavailable. Market creation controls remain absent when either the unified program or the server-side compiler is unavailable.