Bitfinex API vs dYdX

Bitfinex API 41

Read as a closed service with open clients. The last dated change we could read is bitfinex-api-node 9.1.0 on 18 July 2026, 108 days before the check; the docs changelog stops in October 2024 (10). Not three dated releases in the last 90 days (0). The bitfinexcom organisation pushes often (bfx-report on 3 November 2026) and the clients have issue trackers, but support articles answered 403 and no reply times were read (10 of 25). Official clients current in four languages, Node 9.1.0 of July 2026 and Python 4.0.0 of October 2025; not in the MCP registry (15). The Node client has a dependency history of security fixes (its last GitHub release notes name two) and no CI was read (6 of 10). 10 + 0 + 10 + 15 + 6 = 41.

dYdX 83

Read on the clients and the chain. v4-clients was pushed on 29 October 2026 and protocol v9.8.0 shipped on 12 October (30). Protocol v9.7 on 11 September, v9.8.0 on 12 October, v4-client-js tags 3.5.0 and 3.6.0, three or more in 90 days (20). A Discord, a help centre and 36 open issues on v4-clients whose replies couldn't be read (12 of 25). Official SDKs current, the TypeScript client at 3.6.0 and the Python client at 1.1.6 from February 2026 (12 of 15). CI workflows for lint, test, publish and audit, with trusted publishing and provenance on npm (9 of 10). Total 83.

Bitfinex API 40

No machine payment protocol (0). The fees page is public without login (20), though it shows zero maker and taker with no tiers or date. The API is free, public endpoints need no account, and paper trading needs no money (20). A person must sign up in a browser with identity checks and mint the key (0). 0 + 20 + 20 + 0 = 40.

dYdX 60

No machine payment protocol (0). Fees public per tier without login (20). Testnet with a faucet and no card anywhere (20). No signup; an agent with a funded wallet trades, subject to the geographic terms (20). Total 60.

Bitfinex API 62

Revocable keys with per-scope read and write flags, a permissions endpoint, 2FA and email confirmation at creation, strictly increasing nonces, and IP binding to 20 addresses per the support article's search text (the article answered 403); no key expiry (24 of 30). withdraw and ui_withdraw are separate scopes and read-only keys are possible, but the support text says keys from email-and-password accounts start with every permission enabled and no confirmation step is documented for API withdrawals (14 of 20). The API returns exchange data, not third-party text (10). Login history and an account changelog (audit) endpoint are documented (10 of 15). No security.txt, no readable disclosure policy and no certification page readable (4 of 20). 24 + 14 + 10 + 10 + 4 = 62.

dYdX 78

Orders are signed by the account key or by a permissioned key the owner adds as an authenticator, limited by message type, subaccount and market with AllOf or AnyOf, and revoked by remove_authenticator; no shared secret and nothing in a URL (28 of 30). A key can be confined to placing and cancelling orders on one subaccount with withdrawals and transfers excluded, though not to a position or order size, and the interface's default API wallet trades all cross-margin pairs (16 of 20). The API returns no untrusted content (10). Every action is a chain transaction and the indexer lists fills, orders and transfers per subaccount, and authenticators can be listed; no per-key log (10 of 15). A Cantina bug bounty up to $1,000,000 sponsored by dYdX Trading Inc. over the protocol, indexer, web client and SDKs, an Informal Systems audit; no security.txt and no certification (14 of 20). Total 78.

Bitfinex API 48

No OpenAPI or AsyncAPI file was found on docs.bitfinex.com, in llms.txt or in the client repositories (0). llms.txt and a .md twin of every docs page (10). Each reference page states the endpoint's purpose and fields, and the introduction says when to use api-pub against api, but nothing says when not to use an endpoint (14 of 20). Responses are positional arrays described in field tables, inputs are typed in prose with some enumerations (wallet names, order types) and required fields marked; the withdrawal CODE field is work in progress (7 of 15). Signed-request recipes in five languages, but authenticated errors are documented as 400 with an empty object and there is no error reference (9 of 15). Version v2 in the path and a dated changelog, whose last entry is October 2024 and whose v1 deprecation has no date (8 of 15). 0 + 10 + 14 + 7 + 9 + 8 = 48.

dYdX 58

No OpenAPI file found for the indexer; the docs publish a types reference of about 200 pages (OrderSide, TimeInForce, OrderStatus and the rest) and the chain's protobuf messages are in the clients (8 of 25). llms.txt and Markdown docs (10). Endpoint pages describe each call and the guides say when to use short-term against long-term orders and the indexer against the node, but descriptions are short (12 of 20). Enums and types on every field in the reference, with pagination and cursor parameters typed (11 of 15). Examples in Python, TypeScript and Rust for each step; errors are described by HTTP status (400 malformed, 404 not found) with no code list (9 of 15). A /v4 path, protocol releases dated on the status page, deprecated rate-limit fields marked, but no API changelog (8 of 15). Total 58.

Bitfinex API 61

Graded on the REST API. Limits on trades, candles and book depth, and pub:list config endpoints keep responses small, but positional arrays make every field a lookup (14 of 25). start, end, limit and sort on history endpoints and per-symbol variants (16 of 20). ERR_RATE_LIMIT is actionable; authenticated 400s return {} and withdrawal status strings may change, so an agent cannot branch on causes (8 of 20). A client id on orders, order multi-op and cancel-multiple, but no idempotency key and no retry contract (8 of 20). Few required parameters and official clients in Node, Python, Go and Ruby (15). 14 + 16 + 8 + 8 + 15 = 61.

dYdX 66

An API, read for response sizing. limit on list endpoints, candles by resolution, sparklines by period; the order book comes whole (16 of 25). limit, page on fills, transfers and funding, and height or time cursors (16 of 20). Indexer errors are a status and a sentence; order rejections come back from the chain as transaction results the clients surface (8 of 20). Unique 32-bit client IDs, goodTilBlock expiry on short-term orders, cancel by order ID; no MCP annotations apply (14 of 20). Few required fields with market parameters fetched for unit conversion, and official clients in TypeScript, Python and Rust (12 of 15). Total 66.