EIP-712 Order Signing

Overview

All orders on Limitless are signed using EIP-712 structured data. The venue’s exchange address is used as the verifyingContract in the signing domain.

If you’re using the Programmatic API with delegated signing, the server handles EIP-712 signing for you via managed wallets. This page is for partners and traders who sign orders with their own private keys.

EIP-712 domain

{
  "name": "Limitless CTF Exchange",
  "version": "1",
  "chainId": 8453,
  "verifyingContract": "<venue.exchange address>"
}

The verifyingContract must be fetched from the market’s venue data via GET /markets/:slug. See Venue System.

Order type definition

{
  "Order": [
    { "name": "salt", "type": "uint256" },
    { "name": "maker", "type": "address" },
    { "name": "signer", "type": "address" },
    { "name": "taker", "type": "address" },
    { "name": "tokenId", "type": "uint256" },
    { "name": "makerAmount", "type": "uint256" },
    { "name": "takerAmount", "type": "uint256" },
    { "name": "expiration", "type": "uint256" },
    { "name": "nonce", "type": "uint256" },
    { "name": "feeRateBps", "type": "uint256" },
    { "name": "side", "type": "uint8" },
    { "name": "signatureType", "type": "uint8" }
  ]
}

Field reference

Field	Type	Description
`salt`	uint256	Unique order identifier (typically timestamp-based)
`maker`	address	Checksummed address of the order creator — must match your profile’s trading wallet (see Trading wallet mode)
`signer`	address	Same as maker in EOA trading mode (see Trading wallet mode)
`taker`	address	`0x000...000` for open orders (any taker)
`tokenId`	uint256	Position ID — YES or NO token from market data
`makerAmount`	uint256	Amount the maker offers, scaled by 1e6 (see Amount calculation)
`takerAmount`	uint256	Amount the maker wants in return, scaled by 1e6 (always `1` for FOK orders)
`expiration`	uint256	Must be `0`. Non-zero expiration is not currently supported and orders signed with a non-zero value are rejected.
`nonce`	uint256	Must be `0`. Non-zero nonce is not currently supported and orders signed with a non-zero value are rejected.
`feeRateBps`	uint256	Fee rate in basis points. On fee-bearing markets (the market’s `metadata.fee` flag is set) this must exactly equal your profile’s `rank.feeRateBps` from `GET /profiles/me`, or the order is rejected with `feeRateBps[...] is out of user's band`. Sign `0` only on markets without a fee flag.
`side`	uint8	`0` = BUY, `1` = SELL
`signatureType`	uint8	`0` = EOA signature

Trading wallet mode: whose address signs

The backend validates signer and maker against your profile’s trading wallet mode (tradeWalletOption on your profile), not against how you authenticate:

Profile trading mode	Expected `maker`	Expected `signer`
`eoa`	your wallet address (`account`)	the same address
`smartWallet`	your smart-wallet address	your embedded wallet address (a managed key you cannot export)

An account connected with an external wallet can still be in smartWallet mode. Accepting the app’s one-time “choose your trading wallet” prompt sets it, and the prompt does not reappear. In that state, every self-signed API order fails with:

400 — Signer does not match - you should use embedded address for smart wallet

Self-signed API orders need eoa mode. Switch it with an authenticated profile update (HMAC-signed like any other request):

PUT /profiles
{"tradeWalletOption": "eoa"}

The switch is immediate and reversible. Sending {"tradeWalletOption": "smartWallet"} restores the previous mode, since your profile keeps its stored smart-wallet association. One side effect: with eoa mode set, trading in the Limitless web app on this account runs through your raw wallet (a confirmation per action) instead of 1-click trading. For a dedicated bot or API account, that is usually the right end state.

The TypeScript SDK’s HttpClient has no put helper. Send the request with any HMAC-signing HTTP client, or use the SDK’s underlying axios instance (client.http.client.put(...)), which signs every verb.

Two related errors from the same validation: Signer does not match authenticated profile account and Maker does not match expected profile wallet mean the respective field doesn’t match the table above for your current mode.

Order types

Type	Description
GTC (Good Till Cancelled)	Remains active until filled or cancelled
FAK (Fill And Kill)	Matches immediately available liquidity; any unmatched remainder is cancelled
FOK (Fill Or Kill)	Must fill completely or be cancelled

Amount calculation

USDC has 6 decimals (1 USDC = 1,000,000 units). Shares are also scaled by 1e6.

GTC (limit orders)

Side	`makerAmount`	`takerAmount`
BUY	`price * size * 1e6` (USDC to spend)	`size * 1e6` (shares to receive)
SELL	`size * 1e6` (shares to sell)	`price * size * 1e6` (USDC to receive)

// BUY 10 shares at $0.50
makerAmount = 0.50 * 10 * 1e6 = 5,000,000
takerAmount = 10 * 1e6         = 10,000,000

// SELL 10 shares at $0.50
makerAmount = 10 * 1e6         = 10,000,000
takerAmount = 0.50 * 10 * 1e6  = 5,000,000

FAK (fill-and-kill limit orders)

FAK orders build makerAmount and takerAmount with the same price/size formulas as GTC, but the matching engine treats the fields differently:

makerAmount is the hard spend cap — the order tries to use the full amount (USDC to spend for BUY, shares to sell for SELL).
takerAmount is a protected minimum — the minimum output implied by the signed price (shares to receive for BUY, USDC to receive for SELL), acting as slippage protection rather than a hard cap on matched size.
Any portion not matched at or better than the signed price is cancelled; FAK never rests on the book.

postOnly is not supported for FAK.

FOK (market orders)

Side	`makerAmount`	`takerAmount`
BUY	`usdcToSpend * 1e6`	`1` (constant)
SELL	`sharesToSell * 1e6`	`1` (constant)

FOK orders always set takerAmount = 1 and omit price. The makerAmount represents the raw amount being offered.

The SDKs handle amount scaling automatically. You pass human-readable values (price, size, or makerAmount) and the builder calculates the scaled on-chain amounts.

Getting Started

Quick Start

TypeScript SDK

Python SDK

Go SDK

Rust SDK

WebSocket

Overview

EIP-712 domain

Order type definition

Field reference

Trading wallet mode: whose address signs

Order types

Amount calculation

GTC (limit orders)

FAK (fill-and-kill limit orders)

FOK (market orders)

​Overview

​EIP-712 domain

​Order type definition

​Field reference

​Trading wallet mode: whose address signs

​Order types

​Amount calculation

​GTC (limit orders)

​FAK (fill-and-kill limit orders)

​FOK (market orders)

Overview

EIP-712 domain

Order type definition

Field reference

Trading wallet mode: whose address signs

Order types

Amount calculation

GTC (limit orders)

FAK (fill-and-kill limit orders)

FOK (market orders)