Skip to main content
This page explains what the external execution lane is, who it is for, how to get access, and what you have to have in place before your first order. When you’re ready to write code, go to Signing & Order Lifecycle. The external execution lane lets an approved market maker or institutional desk trade through Kairos’s execution infrastructure while holding its own keys, gas, and funds — you sign orders locally with your own externally-owned account (EOA); Kairos builds the exact payload, verifies your signature, and forwards it to the venue. This is the low-latency, self-custody counterpart to the default Kairos path, where orders are signed for you by a managed key. It exists for one reason: latency. A managed signature makes a cross-region round-trip to a cloud HSM (~50–100 ms per order). On this lane you sign locally — sub-millisecond and free — so the only added latency is the network hop to your regional execution node, minimized with regional colocation and a persistent WebSocket signing channel. Kairos never custodies your key and never moves funds you did not sign for.

​
What you bring vs. what Kairos does

Every order Kairos submits on your behalf carries a signature that recovers to an address registered to your account. A signature over one order cannot be replayed onto another — the signed digest pins price, size, side, token, maker/signer, and venue (the verifying contract, which differs between standard and neg-risk markets). Expiration and post_only sit on the outer payload rather than inside Polymarket’s signed Order struct; replay is instead foreclosed by the per-order salt and timestamp, and by single-use intents.

​
The account model

You trade as an EOA (signatureType = 0 on Polymarket) by default: the wallet that signs is the wallet that makes the order and holds the funds. There is no Safe, proxy, or managed sub-org — the simplest, fully non-custodial shape. It signs orders (EIP-712), holds the settlement asset (e.g. pUSD on Polygon), and pays its own gas for any on-chain operation; owner, signer, and maker are always the same address. If your users hold smart-contract wallets instead — a MetaMask Smart Account, a Safe, or a Polymarket proxy — set signature_type = 3 (Poly1271) and the order is verified with EIP-1271 isValidSignature rather than ecrecover: Kairos binds the wallet to your account, and the Polymarket CLOB performs the ERC-1271 check. No bundler or userOp is involved. GET /v2/providers reports the accepted signature_schemes per venue.

​
Access

The lane is open to any authenticated account — there is no allow-list to join and no per-account approval step. You need a credential (a Kairos JWT, a SIWE wallet session, a scoped API key, or a delegation grant) and a signing wallet registered to your account, but you do not need to be pre-approved. An API key is optional. Wallet/JWT auth is enough to trade; an API key is only worth holding because it earns a higher rate limit — see rate limits.
Signing is the real gate. Opening access widens who may try; it does not widen who may sign. Every order must be signed by a wallet registered to your account, and the venue still enforces your balance, approvals and tick. Kairos verifies the signature and forwards it — it never signs for you.

​
Rate limits

Heavy endpoints (onboarding, balances, credential provisioning, on-chain ops, SIWE, delegation) are rate-limited per client and per endpoint. API-key callers get a materially higher budget than wallet/JWT callers: Exceeding it is a 429. The budgets are deployment-configured; treat them as a guide, not a contract.
Gotcha: the kill-switch is prompt, not atomic. A deployment can restore the per-account allow-list (FASTLANE_OPEN_ACCESS=false); when it does, the per-user flag is served from a short-lived cache, so a change takes effect within a couple of seconds — longer if the central database is degraded. Do not build anything that assumes an instant cutoff.

​
Getting started

  1. Authenticate. Use a Kairos JWT, a SIWE wallet session, a scoped API key, or a delegation grant. No allow-list approval is required.
  2. Register your signing EOA(s). Kairos only accepts signatures that recover to an address registered to your account. Self-serve: POST /v2/wallets/challenge → sign the returned message → POST /v2/wallets/register. You may register several (e.g. a primary and a backup HSM key); any of them can sign. Revoke one with POST /v2/wallets/revoke.
  3. Fund your wallet. Deposit the venue’s settlement asset into your EOA on the venue’s chain (for Polymarket: pUSD on Polygon). You control the deposit entirely; there is no custody step.
  4. Set on-chain approvals. Before the venue can move your collateral on a fill, your EOA needs one-time approvals (for Polymarket: pUSD.approve and ConditionalTokens.setApprovalForAll against the CTF Exchange, plus the NegRisk variants). Self-serve: call POST /v2/onchain/intent with op: "approvals", sign each returned signing_digest_hex with your EOA, and post the signatures to POST /v2/onchain/submit. You supply the nonce and gas_price_wei and you pay the gas. Your account manager can also walk through this during onboarding.
  5. Keep a small gas balance. Order placement and cancellation on Polymarket are off-chain and gasless; gas is only needed for the on-chain operations above (a few cents of POL for approvals, more only if you later redeem resolved positions).
  6. Get your credentials & node assignment. Obtain your Kairos JWT (or a scoped API key) and confirm which regional execution node you connect to for lowest latency. Self-serve credential paths: log in with your wallet via SIWE (POST /v2/auth/siwe/challenge → /verify) to mint a scoped API key, and self-provision your Polymarket L2 credentials via POST /v2/credentials/polymarket/intent → /submit. A partner integrating on behalf of others can delegate authority with an off-chain EIP-712 grant.
  7. Check readiness, then place your first order. GET /v2/onboarding/status reports, per provider, your registered wallets, credential/approval state and the next step; GET /v2/wallets/balances shows gas and settlement balances. Then follow the Signing & Order Lifecycle walkthrough. See Partner auth & self-serve onboarding for the full surface.

​
Onboarding checklist

  • Account authenticated (JWT, SIWE, API key, or delegation) — no allow-list approval needed
  • Signing EOA(s) registered to your account (self-serve via /v2/wallets/*)
  • Wallet funded with the venue settlement asset (e.g. pUSD on Polygon)
  • On-chain approvals set (self-serve via /v2/onchain/*, or with your account manager)
  • Small native-gas balance (POL) on hand for approvals and any future redemptions
  • Kairos JWT / API key in hand (JWT, or one minted via SIWE or self-provisioned for Polymarket)
  • Regional node / colocation confirmed with Kairos
  • GET /v2/onboarding/status reports next_action: null for your venue

​
What’s live today

This page — and the rest of this section — documents only what you can integrate against today. See Signing & Order Lifecycle for the full request/response flow and runnable code.

​
Security model in one paragraph

You authenticate to your regional node with a Kairos JWT (or scoped API key). Every order Kairos submits is reconstructed server-side from stored inputs, and its signature is ecrecover’d to an address that must be registered to your account. Intents are single-use, short-TTL, and bound to the account that created them. A leaked intent id is useless without the matching signature, and a signature over one payload cannot be replayed onto another. You never supply a contract address or calldata — the only thing Kairos submits is bytes you signed.

​
See also

  • Signing & Order Lifecycle — EIP-712 signing rules, the intent → sign → submit flow, the WebSocket one-round-trip path, order types, fills, and cancels, with runnable code.
  • Partner Auth & Self-Serve Onboarding — SIWE wallet login, self-serve wallet registration, Polymarket credential self-provisioning, partner delegation, and the readiness/balance introspection endpoints.
  • Regional Execution Nodes — where to connect for the lowest latency, what’s served regionally vs. centrally, and the live-position source-of-truth caveat.
  • API Reference — full request/response schemas for every endpoint referenced in this section.
  • REST › Orders and WebSocket › Order Execution — the general execution API surface (custodial signing).