Appearance
Rate limits
Requests are metered with token buckets. There are three independent budgets — exhausting one never blocks another:
read— reads and cheap non-order mutations.order— order entry (place, cancel, mint a session,cancel-all-after).withdraw—POST /v1/withdrawalsalone. The payout path gets its own budget so a busy trading loop can never stand between an account and its money.
Two levels: per-key and per-account
Each budget is enforced at two levels. The per-key bucket isolates one delegate from another. The per-account bucket is a second ceiling above it, drawn on the account across every key it holds — so minting more keys cannot multiply your throughput.
The numbers below are the testnet starting values, in requests per minute, with the burst a quiet bucket may spend at once. They are policy served from the same config GET /v1/limits reports — always trust that endpoint over this table.
| budget | per-key / min | burst | per-account / min |
|---|---|---|---|
read | 600 | 120 | 3,000 |
order | 60 | 20 | 180 |
withdraw | 10 | 5 | 20 |
Read your own limits
GET /v1/limits returns your tier's budgets and how much of each remains — the authoritative, live view. A static page can go stale; that endpoint cannot.
Headers on every metered response
| header | meaning |
|---|---|
X-RateLimit-Limit | the binding budget's per-minute limit |
X-RateLimit-Remaining | tokens left in the binding budget |
X-RateLimit-Reset | epoch seconds when the budget next admits |
Retry-After | seconds to wait, sent on a 429 |
A refused request returns 429 with a machine code and Retry-After. A well-behaved client reads X-RateLimit-Remaining and paces itself rather than walking into the 429.
The live-key cap
Independently of the buckets, an account may hold at most
20 live keys at once. Minting past that returns403 {"code":"session_limit"}; revoke an unused session first. Together with the per-account ceiling this closes the "mint more keys to get more budget" bypass.
One gateway, in-memory buckets (testnet)
On testnet the buckets are per-gateway and in-memory. That is exactly the single-gateway deployment testnet runs; horizontal scale needs a shared bucket store and is tracked, not pretended.