# dYdX v4 Clients Four language clients for one perp DEX, under a licence that is not the one on the badge. *https://cryptomarkets.tools/tools/dydx-v4-clients · Crypto Trading Bots & Execution SDKs* ## Facts ### At a glance | Field | Value | | --- | --- | | Vendor | dYdX | | Category | Crypto Trading Bots & Execution SDKs | | Job | execution_sdk | | Website | https://github.com/dydxprotocol/v4-clients | | Pricing model | free | | Free tier | true | | Open source | false | | Licence | LicenseRef-dYdX-Custom | | Self-hosted | true | | KYC required | false | | Tested hands-on | false | | Last updated | 2026-09-19 | ### Coverage | Field | Value | | --- | --- | | Asset classes | perpetuals | | Chains | none | | Venues | dex, derivatives | | Data latency | realtime | | Platforms | library | | AI features | none | ### Interfaces | Field | Value | | --- | --- | | API | false | | Webhooks | false | | Scripting | TypeScript, Python, Rust, C++ | | MCP server | false | | Export | json | ### Capabilities Yes: live_trading, paper_trading No: charting, screening, backtesting, automation, portfolio_tracking, exchange_import, tax_reporting, alerts, news, onchain_data, wallet_tracking, derivatives_analytics *Verified: pricing 2026-09-19; capabilities 2026-09-19; coverage 2026-09-19.* ## What it is The official client layer for placing orders on dYdX v4, and the first thing to know is that it is not a package. It is a monorepo holding six things with separate release cycles: `v4-client-js` (TypeScript, published as `@dydxprotocol/v4-client-js`), `v4-client-py-v2` (Python, published as `dydx-v4-client`), `v4-client-rs` (Rust, published as `dydx`), `v4-client-cpp`, `dydxjs`, and a deprecated first-generation Python client still sitting in the tree. Pick one; nothing here is a single SDK with four bindings, and the versions have no relationship to each other — `@dydxprotocol/v4-client-js` is at 3.6.0, `dydx-v4-client` at 1.1.6, the `dydx` crate at 0.3.0. Two of the four are not maintained by dYdX. The README states that the Python and Rust clients are "developed and maintained by the Nethermind team", and that the C++ client came out of a grant from the dYdX Grants Trust, "an unaffiliated and independent third-party from dYdX Trading Inc." — it is pulled in as a git submodule and only builds on Linux. `dydxjs` is the low-level Cosmos proto and amino layer that the README itself tells you not to use directly. Like the [Hyperliquid Python SDK](https://cryptomarkets.tools/tools/hyperliquid-python-sdk), this is a single-venue client, and the trade is the same one: you get the whole of one venue's surface and none of anybody else's. The difference is that dYdX v4 is a Cosmos application chain rather than an exchange server, so an order here is a signed chain transaction broadcast to a validator, while reads come from a separate hosted indexer with its own REST and WebSocket endpoints. That split is the thing the client exists to hide, and it is also why writing your own against the raw protocol is a much larger job than it would be for a REST venue. ## Pricing Free to obtain and free to use. The venue's own trading fees apply and the client adds none. There is no free tier to describe because there is nothing above it — but "free" and "open source" are not the same claim here, which is the next section. ## Data & coverage dYdX v4 perpetuals, and nothing else. Reads go through the indexer — REST plus a WebSocket feed — and orders go on chain. A public testnet is wired in rather than documented elsewhere: the Python client ships network constants for `dydx-testnet-4`, the indexer at `indexer.v4testnet.dydx.exchange`, its WebSocket endpoint, and a faucet at `faucet.v4testnet.dydx.exchange`. Rehearsing a strategy costs a faucet request, not an account application, and no part of that flow asks for identity documents. ## Limitations **The licence is not the one three of its own files claim.** This is the fact worth the card. The LICENSE file — identical in all six client directories — opens by conditioning the grant: "Subject to your compliance with applicable law and the v4 Terms of Use, available at dydx.exchange/legal, you are granted the right to use the Software … provided, however, that if you violate any such applicable law in your use of the Software, all of your rights and licenses to use … will automatically and immediately terminate." The MIT text follows that sentence. Meanwhile the README badge says AGPL v3, the Python client's README repeats it, and `v4-client-js/package.json` declares AGPL-3.0, which is what npm's registry reports to every tool that reads package metadata. Only `v4-client-rs/Cargo.toml` is accurate, declaring `LicenseRef-dYdX-Custom`. Three different licence claims for one body of code, two of them contradicting the file. This card takes the file, treats the result as source-available rather than open source, and leaves the reading of the terms of use to whoever has to sign off on it. **One commit in six months.** Thirty-five commits reached `main` in the year to 19 September 2026, the last of them on 27 April. Split by client over that year: TypeScript 18, Python 12, Rust 5, C++ 1, `dydxjs` 1, deprecated Python 1. The newest tag is v3.6.0 from 4 March 2026, and npm's latest matches it. A client for a chain that keeps shipping is exactly the place where a quiet half-year is worth knowing about before you build on it. **The published Python package is ahead of the repository.** PyPI's `dydx-v4-client` is at 1.1.6, uploaded 12 February 2026, while `v4-client-py-v2/pyproject.toml` on `main` still reads 1.1.5. Whatever 1.1.6 contains was not released from the default branch. **The C++ client is somebody else's, and Linux-only.** dYdX says so plainly, which is more than most projects do, but it means the C++ path has a different maintainer, a different repository and a different risk profile from the other three. **It is a client, not a bot.** No strategy layer, no scheduler, no risk limits, no backtester and no persistence. Everything that turns an order into automation is yours to write. **A deprecated client is still in the tree**, with its own README and its own PyPI name, which is the sort of thing a search engine keeps surfacing long after it stops working. ## Alternatives [CCXT](https://cryptomarkets.tools/tools/ccxt) is the answer whenever a second venue is in the plan; it trades away the venue-specific surface and the chain-level operations for one vocabulary across a hundred exchanges. The [Hyperliquid Python SDK](https://cryptomarkets.tools/tools/hyperliquid-python-sdk) is the same shape of product for the other large perp DEX — one venue, official, MIT, and considerably more active in the last six months. If what you want is a bot rather than a client, two frameworks in this catalogue already carry a dYdX v4 connector and save you this layer entirely: [Hummingbot](https://cryptomarkets.tools/tools/hummingbot) lists it among its perpetual venues, and [NautilusTrader](https://cryptomarkets.tools/tools/nautilus-trader) among its decentralised adapters. Both bring the scheduling, sizing and risk machinery a client deliberately does not. The rest of the [trading bots and execution SDKs](https://cryptomarkets.tools/categories/trading-bots) listing is the same trade-off at different heights. ## FAQ ### Is dYdX v4 Clients open source? The source is public and free to use, but the LICENSE file is not an OSI licence. It grants the usual MIT rights only while you comply with applicable law and dYdX's v4 Terms of Use, and says your rights terminate automatically and immediately if you do not. This card calls that source-available rather than open source. ### Why do the README and npm say AGPL-3.0? Because they are wrong, or at least out of step with the file. The README badge reads AGPL v3 and `v4-client-js/package.json` declares `"license"` as AGPL-3.0, while every LICENSE file in the repository — six of them, one per client — carries the custom dYdX text. The Rust crate is the only one that matches, declaring `LicenseRef-dYdX-Custom`. ### Is this one package or several? Several, in one repository. TypeScript (`@dydxprotocol/v4-client-js`), Python (`dydx-v4-client`), Rust (`dydx`), a third-party C++ client that only builds on Linux, the low-level `dydxjs` Cosmos layer, and a deprecated Python client. They are versioned independently. ### How actively is it developed? Thirty-five commits landed on `main` in the twelve months to 19 September 2026, and exactly one of them in the last six — a Python scale-order feature on 27 April 2026. The newest tag, v3.6.0, is from 4 March 2026. ## Also worth comparing - [ccapi](https://cryptomarkets.tools/tools/ccapi.md) — Header-only C++ market data and execution for 30 venues, on a Bloomberg-shaped API. - [CCXT](https://cryptomarkets.tools/tools/ccxt.md) — One MIT client for 104 crypto exchanges, 76 of them over websocket. - [CoinAPI EMS Trading API](https://cryptomarkets.tools/tools/coinapi-ems.md) — One order model over 26 exchange destinations, TWAP and VWAP, priced per account-hour. - [Hyperliquid Python SDK](https://cryptomarkets.tools/tools/hyperliquid-python-sdk.md) — The official Python client for signing and sending orders on one perp DEX. - [3Commas](https://cryptomarkets.tools/tools/3commas.md) — Hosted DCA, grid and signal bots over nine exchanges, with your keys on their servers. - [Bitsgap](https://cryptomarkets.tools/tools/bitsgap.md) — Hosted grid, DCA and futures bots on seventeen venues, with no API and no webhooks.