dYdX v4 Clients

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, 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 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 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 lists it among its perpetual venues, and NautilusTrader 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 listing is the same trade-off at different heights.