> ## Documentation index
> Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt
> Use it to discover every available page before exploring further.

# SX Bet

> The client-side trading lane for SX Bet, its account preconditions, and the V3 API cutover.

## What you need first

- **Production status:** **Client-side only.** There is no hosted SX Bet execution lane, so
  `GET /v1/exec/venues` never lists it and every `/v1/exec/sxbet/…` route answers
  `404 VENUE_NOT_SUPPORTED`. The venue-direct SDK integration at `client.accounts.sxbet` has been
  live since 2026-07-27.
- **Wallet and chain:** An EVM wallet on SX Network (chain `4162`). The private key stays in your
  process and signs every order and cancel locally.
- **Venue account:** Yes, and the preconditions are hard. The trading wallet must have a
  **registered sx.bet account** — a key-only wallet is rejected with `INSUFFICIENT_KYC` even when
  its signature is correct. Betting must also be **enabled once per token per network**, either
  through `TokenTransferProxy` approval or one manual bet in the sx.bet UI. On **V3** (the
  venue's hard cut lands 2026-08-25 14:00 UTC) one more precondition joins: the account's
  **proxy wallet must be deployed and pre-funded** before the venue accepts resting limit bets
  (externally verified against live V3, 2026-08-23).
- **Credentials:** The wallet private key, and an SX Bet API key where the version requires one.
  Both stay in your process and go only to sx.bet; neither transits Predictefy.
- **Funding:** Six-decimal SX Network USDC in the wallet. SX Network is not on LI.FI, so the funding
  lane routes through Glide: `POST /v1/bridge/session`. Minimum order size is 10 USDC on V2;
  V3 lowers it to 5 USDC (live `orderSizeMinimum`, obv3 metadata).

## The client-side write surface

```ts
import Predictefy from '@predictefy/sdk';

const client = new Predictefy({
  apiKey: process.env.PREDICTEFY_API_KEY,
  venueCredentials: {
    sxbet: {
      privateKey: process.env.SXBET_WALLET_KEY!,
      apiKey: process.env.SXBET_API_KEY, // required on V3; optional on V2
    },
  },
});
```

- **Maker limit orders:** `createOrder({ type: 'limit', ... })` posts the order with EIP-191
  signing.
- **Taker fills:** `createOrder({ type: 'market', ... })` posts the fill with EIP-712 signing. The
  first response is honestly `PENDING`; track it to `SUCCESS` or `FAILED` rather than treating the
  acknowledgement as a fill.
- **Cancellation:** `cancelOrder` / `cancelOrders`, `cancelOrdersByEvent`, and `cancelAllOrders` use
  the three EIP-712 cancel endpoints.
- **Betting enablement:** `client.funding.buildPermitRequest` builds the one-time EIP-2612 permit.
  SX Network USDC uses version `"1"`; its contract has no `version()` getter, so the version cannot
  be read on-chain and is pinned.
- **Dead-man switch:** `armHeartbeat` and `disarmHeartbeat` require the optional SX Bet API key.
  Trading itself is private-key-signature-only on V2.

## The V3 API cutover

SX Bet is migrating its order API from V2 to V3. **V2 retires 2026-08-25 10:00 ET.** The SDK
therefore ships both and **defaults to `v2` until that date**.

Select a version with the `SXBET_API_VERSION` environment variable (`v2` or `v3`), or pin one
explicitly through `SxbetAccountClient`'s `apiVersion` option. Pinning is what testnet rehearsal
needs, because only V3 exists there.

Three things change on V3, and each one is a hard rejection rather than a soft fallback:

- **Routes move.** Order create, cancel, cancel-by-event, cancel-all, metadata, and heartbeat all
  move to their `-v3` paths.
- **The API-key header is renamed.** V3 reads `x-sx-api-key` and rejects the V2 spelling.
- **An API key becomes mandatory for trading.** V2 order placement was signature-only; V3 requires
  the key as well. If you trade on SX Bet without an API key today, obtain one before the cutover.

Disarming the heartbeat also changes shape: V2 has a separate cancel route, while V3 disarms by
posting `timeoutSeconds: 0` to the same heartbeat route. The SDK handles that difference for you.

## Venue properties, not gaps

- **No hosted lane, no hosted relay.** This client-side integration does not imply hosted execution
  or unlisted verb coverage. Signing keys and venue credentials never leave your process.
- **No withdrawal route.** SX Bet publishes none, so `withdrawFromProxy()` throws `NOT_SUPPORTED` by
  design. Withdrawals and proxy-to-proxy transfers are Safe-authorised in the sx.bet app, and this
  lane will not emulate a route the venue does not offer. See
  [Accounts & funding](/guides/accounts/).
- **Order books.** SX Bet has a real CLOB. An earlier Railway-egress incident that returned honest
  empty books **healed on 2026-08-15**; production `fetchOrderBook` returned real two-sided depth.
  That healing changed book availability only — the execution boundary above is unchanged.

Venue and jurisdiction eligibility remain the operator's and integrator's compliance
responsibility.