EIP-712 Order Signing

How to sign orders using EIP-712 structured data

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
signer	address	Same as maker for EOA wallets
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	0 for no expiration
nonce	uint256	Order nonce
feeRateBps	uint256	Fee rate in basis points
side	uint8	0 = BUY, 1 = SELL
signatureType	uint8	0 = EOA signature

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.