Appearance
Rate limits
Requests are metered with token buckets. There are three independent budgets, and 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.