# dYdX vs Upbit Open API (slim)

> dYdX scores 69.5 (B) to Upbit Open's 54.7 (C) for exchange market data. Prices, MCP, x402, uptime and agent notes side by side.

- Full: https://www.anchorterminal.com/compare/dydx-vs-upbit.md (~4,250 tokens) · this version ~2,030 tokens · JSON https://www.anchorterminal.com/compare/dydx-vs-upbit.json · canonical https://www.anchorterminal.com/compare/dydx-vs-upbit
- Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · MCP: https://www.anchorterminal.com/mcp · Updated: 2026-11-04
- Licence: CC BY 4.0, credit Anchor Terminal and link this page (https://www.anchorterminal.com/terms/#data)

dYdX scores 69.5 (B) on agent readiness against Upbit Open API's 54.7 (C), and leads in 3 of 7 scored categories. Upbit Open API leads on schema & documentation. Both do exchange market data.

- dYdX: B 69.5, rank #222 of 1349 · https://www.anchorterminal.com/tools/dydx.min.md
- Upbit Open API: C 54.7, rank #802 of 1349 · https://www.anchorterminal.com/tools/upbit.min.md
- dYdX, good for An agent trading perpetuals from its own Cosmos wallet or through a permissioned key on an owner's account, outside the US, Canada and UK. Ahead on Reliability, 83 against 42; Security & auth, 78 against 59; Payments & pricing, 60 against 15. Also Open source.
- Upbit Open API, good for KRW-market trading for agents acting for a verified Korean account, with first-party SDKs, a CLI and skills but no MCP. Ahead on Schema & documentation, 66 against 58.

| Category | dYdX | Upbit Open API |
| --- | --- | --- |
| Reliability (16%) | 83 | 42 |
| Performance (10%) | pending | pending |
| Schema & documentation (13%) | 58 | 66 |
| Agent ergonomics (13%) | 66 | 70 |
| Security & auth (14%) | 78 | 59 |
| Payments & pricing (10%) | 60 | 15 |
| Task success (10%) | pending | pending |
| Maintenance & community (7%) | 83 | 83 |
| Transparency & trust (7%) | 50 | 54 |

| Fact (where they differ) | dYdX | Upbit Open API |
| --- | --- | --- |
| Vendor | dYdX Trading Inc. | Dunamu Inc. |
| Auth | OAuth or key | API key |
| Licence | The clients are AGPL-3.0 with a use condition tied to the v4 Terms of Use; the chain software (dydxprotocol/v4-chain) carries a custom licence GitHub cannot classify. The hosted indexer at indexer.dydx.trade and the front end are run by third parties, not dYdX Trading Inc. | none |
| Last release | 2026-10-29 | 2026-10-20 |
| Terms last updated | 2026-03-12 | no document linked |
| Privacy policy last updated | 2025-06-06 | no date given |
| Customer content may train models | not found in the text | not read yet |
| Terms restrict automated access | not found in the text | not read yet |
| Terms restrict benchmarking | not found in the text | not read yet |
| Terms or service can change without notice | yes | not read yet |
| Arbitration or class-action waiver | yes | not read yet |
| Popularity | 119 stars, 86k npm/wk | 91 stars |

Why the edge:
- Payments & pricing, dYdX +45: 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.); Upbit Open API 15 (No machine payment protocol (0). The fee schedule is on upbit.com, which disallows every crawler path, so no price is recorded (0 of 20, unchecked). Public quotation endpoints need no key, card or account; trading needs a verified Korean account. Judgement call (15 of 20). A person must sign up, pass identity checks and issue keys on the PC web site (0). 0 + 0 + 15 + 0 = 15.)
- Reliability, dYdX +41: dYdX 83 (Read with the hosted lines on the indexer API and the chain endpoints the clients submit to. status.dydx.trade is an Atlassian Statuspage with Frontends, dYdX Chain, Indexer, Order Gateway and Client Libraries components and an RSS history (20). From 1 August to 3 November 2026 the feed has eight items, seven scheduled maintenance windows of 29 minutes to 2 hours (indexer on 9 September, 8 and 15 October, protocol v9.7 on 11 September and v9.8.0 on 12 October, WebSocket compression on 26 and 28 October) and one degraded instant-deposit path through an onboarding partner from 24 to 29 September, outside the trading API. Clean or trivial (30). Rate limits documented with numbers for the indexer, the block limits and the public nodes (15). No 429 shape or Retry-After for the indexer; short-term orders expire by `goodTilBlock` and client IDs let an agent find an order after a timeout (8 of 15). No SLA (0). Mainnet generally available; the Order Entry Gateway is marked testnet-only (10). 20 + 30 + 15 + 8 + 0 + 10 = 83.); Upbit Open API 42 (Read with the hosted lines. No status page found on docs.upbit.com or in llms.txt; a wallet-status endpoint and an announcements stream stand in (0). No readable incident history (5). Rate limits documented with numbers per group, per IP and per pocket, updated 7 October 2026 (15). 429 then 418 with a stated block length and a Remaining-Req header, an order-test endpoint and a self-match-prevention default; an order identifier for safe retries was not checked (12 of 15). No SLA found (0). Generally available (10). 0 + 5 + 15 + 12 + 0 + 10 = 42.)
- Security & auth, dYdX +19: 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.); Upbit Open API 59 (Keys limited to chosen functions, a mandatory public IPv4 allow-list, a JWT per request with a fresh nonce, keys listed with expiry through the API, and a withdrawal safe-lock on by default (27 of 30). Read-only keys, the default withdrawal lock lifted only in the app, and skills that require a typed CONFIRM before writes (17 of 20). The API returns exchange data and announcements, no third-party content (10 of 15). An API key list endpoint; no per-call log for the operator (5 of 15). No disclosure policy, bug bounty or certification found; security.txt on upbit.com could not be fetched under its robots.txt (0 of 20). 27 + 17 + 10 + 5 + 0 = 59.)
- Schema & documentation, Upbit Open API +8: 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.); Upbit Open API 66 (No OpenAPI found; the reference is a readme.io site with a Markdown twin of every page (5 of 25). llms.txt on docs.upbit.com and a kr/llms.txt index (10). Each reference page states what the endpoint does, its group and its errors, with warnings such as market_offline after maintenance (14 of 20). Typed parameters with enums for order type, side and time in force and required flags (11 of 15). Recipes in Python, Java and Node.js and an error format of error.name and error.message with HTTP statuses (13 of 15). Feature versions in page histories (v1.6.1) and dated notices with effective dates, no single API version (13 of 15). 5 + 10 + 14 + 11 + 13 + 13 = 66.)