new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Quant · Exchange APIs · all subjects

Authentication and signing

5 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

How do I sign a Binance API request with HMAC-SHA256?

Build the exact query string (or URL-encoded body for POST) of all parameters you will send, in the same order. Compute HMAC-SHA256 of that string using your API secret, hex-encode it, and append it as the LAST parameter: `&signature=<hex>`. Send your API key in the `X-MBX-APIKEY` header. Signed (TRADE/USER_DATA) endpoints require a `timestamp` parameter in server milliseconds and accept an optional `recvWindow`. The signature itself is never part of the signed payload. Content type is `application/x-www-form-urlencoded`. The same scheme works on spot `/api/v3` and USD-M futures `/fapi/v1`. Most 'signature invalid' errors (-1022) come from re-serializing the body differently than what was signed, or from URL-encoding mismatches.

Why do I get Binance error -1021 (timestamp outside recvWindow)?

-1021 means your `timestamp` differs from Binance server time by more than `recvWindow` (default 5000 ms, max 60000 ms). Root causes: local clock drift, NTP disabled, or a request that sat in a client-side rate-limit queue after its timestamp was generated. Fix: at startup fetch `GET /api/v3/time` (or `/fapi/v1/time`), compute `offset = serverTime - localTime`, apply it to every signed request, and refresh periodically. Generate the timestamp immediately before sending, not before queueing. Keep NTP running. Do not paper over drift by setting `recvWindow=60000` permanently — a wide window also widens the replay-attack surface. CCXT has `options.adjustForTimeDifference` for exactly this.

Can I use Ed25519 or RSA keys instead of HMAC on Binance?

Yes. As of early 2026 Binance supports asymmetric API keys — Ed25519 (recommended) and RSA (PKCS#8) — on spot and futures, including the WebSocket API. You generate the key pair locally, upload only the PUBLIC key in API Management, and sign the same payload string with your private key (Ed25519 signature, base64-encoded, appended as `signature=`). The `X-MBX-APIKEY` header then carries the key identifier Binance assigned. Advantages: the secret never leaves your machine, signing is fast, and key rotation does not expose a shared HMAC secret in config. Verify the exact signature encoding and supported endpoints in the current docs — asymmetric-key rollout has been expanding endpoint by endpoint.

How do I sign a Bybit v5 API request?

Bybit v5 signing: build the pre-sign string by concatenating `timestamp + apiKey + recvWindow + payload`, where payload is the raw query string for GET or the raw JSON body string for POST. HMAC-SHA256 it with your API secret and hex-encode. Send headers: `X-BAPI-API-KEY`, `X-BAPI-SIGN`, `X-BAPI-TIMESTAMP`, `X-BAPI-RECV-WINDOW` (default 5000 ms), and `X-BAPI-SIGN-TYPE: 2`. Get server time from `GET /v5/market/time`. Common failures: signing a re-serialized JSON body whose key order or whitespace differs from the body actually sent (sign the exact string you transmit), timestamp drift, and forgetting that the payload for GET must include the full query string in the order sent.

How does OKX signing work (passphrase and base64 HMAC)?

OKX pre-hash string: `timestamp + method + requestPath + body`, where timestamp is ISO-8601 with milliseconds (e.g. `2026-01-01T00:00:00.000Z`), method is uppercase (`GET`/`POST`), requestPath includes the query string (`/api/v5/trade/order?instId=...`), and body is the raw JSON for POST (empty string otherwise). HMAC-SHA256 with your secret, then BASE64-encode (not hex — a classic porting bug). Headers: `OK-ACCESS-KEY`, `OK-ACCESS-SIGN`, `OK-ACCESS-TIMESTAMP`, and `OK-ACCESS-PASSPHRASE` — the passphrase you set when creating the key; a wrong passphrase is the most common OKX 401 cause. Timestamps must be within 30 s of server time (`GET /api/v5/public/time`). Demo trading additionally needs header `x-simulated-trading: 1`.

Give your agent this brain