Skip to content
Get an API key
  • 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).
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.

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.

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