API
Read the exchange, and trade against it, over plain HTTP.
The exchange node serves a small JSON HTTP API. Market data and account state are unauthenticated reads; trading is a signed transaction you build, sign with your account's trading key, and post. There is no private data path — the same endpoints back the web app.
On the testnet the base URL is:
https://app.testnet.lambdachain.xyz/v1Reading the market
All of these are GET requests that return JSON. None need authentication.
| Endpoint | Returns |
|---|---|
/v1/status | Node health: next block number, pending transaction count. |
/v1/markets | Every market with its live index and mark price, open interest, funding index, and per-market parameters (margin, fees, step sizes). |
/v1/market/{id}/book?depth=N | The order book for a market, N levels per side. |
/v1/market/{id}/trades | Recent fills in a market. |
/v1/market/{id}/candles?res=60 | OHLC candles at a resolution in seconds. |
/v1/blocks?limit=N | The most recent committed blocks. |
/v1/batches | Settlement ranges and their proof state. |
Reading an account
An account is addressed by its integer index. If you only know the owner address, resolve it first.
| Endpoint | Returns |
|---|---|
/v1/account?owner=0x… | The account index (and whether it exists) for an owner address. |
/v1/account/{index} | Collateral, positions, and registered keys. Add ?view=settled for the last proven state rather than the speculative one. |
/v1/account/{index}/orders | Working orders. ?history=1 includes closed ones. |
/v1/account/{index}/trades | The account's fills. |
/v1/account/{index}/events | Deposits, withdrawals, funding and liquidation touches. |
Most reads return two views. The speculative view reflects what the sequencer has applied but not yet proven; the settled view reflects the last proven block. They differ only for the few seconds between a block being committed and its proof landing — see Settlement.
Trading
Trading is a signed transaction. The flow is always the same three steps, whatever the transaction — place an order, cancel one, withdraw, rotate a key:
- Build the transaction as JSON (its type and fields).
POST /v1/tx/payloadwith it to get back the exact canonical bytes to sign. The node computes the signing payload so you never have to reproduce the encoding.- Sign those bytes with your account's trading key and
POST /v1/txwith the transaction and signature.
The node checks the signature, admits the transaction into the current block, and returns immediately — you do not wait for the block to prove. Read the account back to see it applied.
The trading key
Transactions are signed with a Schnorr signature over the ecGFp5 curve (not secp256k1). The key is not something you store; it is derived deterministically from an identity you already control:
- From a wallet: one
personal_signover a fixed derivation message (which binds the deployment id and the key slot) becomes the trading key. The same wallet always derives the same key for the same account. - From a passkey: the passkey's PRF derives the same trading key, plus a self-custodial owner address. See Self-custody.
The reference derivation and signing live in the Go apikey package and the browser WASM signer in the app; a programmatic client reproduces the same derivation and signs with any ecGFp5 Schnorr implementation.
The trading key can place and cancel orders and sign withdrawals to your own owner address — it cannot move funds anywhere else. It is safe to hold in an automated client; it is not a custody key. Custody stays with the owner address.
Keys and nonces
An account holds up to four trading keys, in slots 0–3. Each slot has its own nonce stream, so a market maker can sign from several slots in parallel without nonce contention. Slot 0 is the root key registered at the first deposit; the others are added or rotated with a signed KeyUpdate transaction, which moves no funds.