# knowm/XChange: a Java client for 60+ crypto exchange APIs

> XChange wraps dozens of incompatible exchange REST and WebSocket interfaces behind one Java API, which is useful if you trade across venues in the JVM and painful if you expect a stable release cadence.

**knowm/XChange** — XChange is a Java library providing a streamlined API for interacting with 60+ Bitcoin and Altcoin exchanges providing a consistent interface for trading and accessing market data.

- Repository: https://github.com/knowm/XChange
- Website: http://knowm.org/open-source/xchange/
- Stars: 4,081 · Forks: 1,995
- Language: Java
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/knowm-xchange

## The problem XChange solves for JVM trading code

Every exchange publishes its own REST shape. Bitstamp wants a user name plus key and secret; other venues use only a key and secret; some add a passphrase. Endpoint names, symbol formats, pagination and error codes differ again. If you write against three venues directly, you maintain three clients, three sets of DTOs and three retry policies.

XChange's answer is a single Java interface layer. You create an Exchange, ask it for a service (MarketDataService, AccountService, TradeService) and call methods that return library types such as Ticker and CurrencyPair.BTC_USD. The README states that all exchange implementations expose the same API, while still allowing direct access to the underlying raw data from individual exchanges when the common surface is not enough. That last part matters: the abstraction is deliberately leaky at the edges rather than pretending every venue is identical.

The audience is Java and JVM developers building bots, portfolio trackers, arbitrage scanners or internal tooling that talks to more than one venue. It is not aimed at end users, and it is not a hosted service.

## How the module layout and service interfaces fit together

The repository is a multi-module Maven build. xchange-core holds the shared interfaces and value types; each venue gets its own directory, from xchange-binance and xchange-kraken to xchange-bitstamp and xchange-deribit. That structure is the design: the abstraction lives in core, the per-exchange translation lives in the venue module, so a change to one exchange's API should not disturb the others.

Data flow is straightforward. ExchangeFactory.INSTANCE.createExchange(SomeExchange.class) returns an Exchange. You pull a service off it and call a method. For public data no credentials are needed. For private data you build an ExchangeSpecification from the exchange's default specification, set credentials, and pass that to createExchange instead. The factory then returns an Exchange whose AccountService and TradeService can reach private endpoints.

Streaming is a second, parallel path. StreamingExchangeFactory returns a StreamingExchange, and the README describes the websocket API as built on Reactive streams, so a subscriber can watch many currency pairs without spawning a thread per subscription. The README's own advice is to use the REST API for occasional requests and polling at long intervals, and to move to websockets when an exchange rate-limits REST calls.

## Installing XChange and reading your first ticker

The build is Maven based (pom.xml at the repository root, plus jitpack.yml). The README points to snapshot jars on Sonatype OSS and says that for the latest bugfixes and features you should use those snapshots or build from the develop branch yourself. It does not document a tagged stable release line in the text available here, so treat the artifact you pin as something you chose deliberately.

Dependency coordinates are not printed in the README, so add the core artifact and the venue module you need according to your own build setup. For public market data, the README gives this example almost verbatim. Create the exchange, get the market data service, request a ticker for a currency pair and print it:

```java
Exchange bitstamp = ExchangeFactory.INSTANCE.createExchange(BitstampExchange.class);
MarketDataService marketDataService = bitstamp.getMarketDataService();
Ticker ticker = marketDataService.getTicker(CurrencyPair.BTC_USD);
System.out.println(ticker.toString());
```

What you should see is a Ticker object rendered to standard output. Private calls need credentials first. The README builds an ExchangeSpecification from the exchange's default specification and sets user name, API key and secret key before calling createExchange with that specification. It notes that some venues need extra fields, such as a passphrase on Coinbase Pro, and links a wiki FAQ page for storing keys in a configuration file.

For websockets you swap factories and connect explicitly. The README's example uses a blocking wait before subscribing:

```java
StreamingExchange exchange = StreamingExchangeFactory.INSTANCE.createExchange(BitstampStreamingExchange.class);
exchange.connect().blockingAwait();
```

After that, subscriptions come from exchange.getStreamingMarketDataService(), and the README's sample subscribes to getTrades for a currency pair, receiving a Disposable it later uses to unsubscribe.

## Where XChange is the wrong tool

The integration status table is the honest part of the README, and it is also the warning. Only bitfinex, bitget, bitmex, coinex, deribit, gate.io, kraken, mexc and a few stream- prefixed entries appear there. The repository listing contains far more venue modules than the table names, which means the table is a statement about which integrations are exercised by CI, not a full inventory of what exists. If your venue is not in that table, you are relying on code that the project's own status page does not vouch for.

Streaming coverage is narrower still. The README says the websocket StreamingExchange API is available for "a smaller number of exchanges", and the status table shows stream- entries for bitfinex, deribit and kraken-v2. A venue can be fully supported over REST and have no streaming implementation at all, so an architecture built around subscriptions may not port across your venue list.

Rate limits are another boundary. The README is explicit that many exchanges heavily limit REST request frequency and advise websockets for real-time data. XChange gives you a consistent call, not a consistent quota. Throttling, backoff and reconnect logic remain your problem, and they will differ per venue.

Finally, the release situation. The README tells you to use snapshot jars or build from develop for the latest fixes. That is fine for a team that can absorb a moving dependency, and awkward for anyone who needs a frozen artifact and a changelog. The last push to the repository was on 2026-09-04, so the project is not dormant, but movement on develop is not the same as a curated release.

## XChange versus writing your own per-exchange clients

The real alternative for most teams is not another library but a small in-house client per venue, or a language-specific SDK published by the exchange itself. The difference is where the maintenance sits.

With XChange you inherit a shared type system: CurrencyPair, Ticker, AccountInfo, AccountService, TradeService. Adding a second venue is mostly a new module dependency and a new Exchange class, and code that reads a ticker keeps working. The cost is a dependency on a project whose per-venue modules can lag an exchange's API changes, and whose CI coverage varies by venue as the status table shows.

With hand-written clients you control exactly which endpoints you call and when you migrate. You also re-implement symbol mapping, authentication signing, error translation and DTO parsing for every venue, and you do it again the next time an exchange changes a field. For two venues that you know well, that is often the cheaper path. For eight venues, the shared interface is the point.

A middle option the README itself mentions: use the common API for the bulk of your logic and drop to the raw exchange data when a venue exposes something the abstraction does not model. XChange is designed to permit that rather than forbid it.

## Licence, maintenance and the cost of upgrading

The repository is MIT licensed, which is permissive and places few obligations beyond retaining the copyright and permission notice. That is a statement about the licence file, not legal advice; if you redistribute XChange inside a product, have your own counsel read the LICENSE text.

Maintenance is visible in two places. The last push was on 2026-09-04, so the codebase is being touched. The README also points to a Discord server and a GitHub issues page, and the status table is backed by per-exchange CI workflows under .github/workflows, including separate workflow files for bitfinex, bitget, bitmex, coinex, deribit, gateio-v4, kraken, mexc and the stream variants. Those workflows tell you which integrations get tested on push; they do not tell you how quickly a broken venue is fixed.

Upgrade cost is where XChange asks for patience. Because the README steers you to snapshot jars or a develop build, an upgrade can move several venue modules at once, and a change in a shared core type can ripple into code you wrote against it. Teams that pin a snapshot and upgrade on a schedule will have an easier time than teams that follow develop continuously. The README does not document a deprecation policy or a rollback procedure for a bad snapshot, so plan to test an upgrade against your own venue list before you deploy it.

## Conclusion

Adopt XChange if you already live in the JVM and need one code path across many exchanges, and you are willing to track the develop branch or snapshot jars rather than wait for tagged releases. Do not adopt it if you need a vendor-held SLA, a non-Java stack, or guaranteed websocket coverage for every venue you touch: the README shows streaming is implemented for a smaller subset. Before writing production code, verify that the specific exchanges you need appear in the integration status table, check whether the service you intend to call is REST-only or also has a StreamingExchange implementation, and read the wiki FAQ page the README links for credential handling.

## FAQ

### Is XChange free?

Yes. The repository is MIT licensed, which permits commercial and private use as long as the copyright and permission notice are retained. Read the LICENSE file in the repository for the exact terms.

### How does XChange work?

You create an Exchange through ExchangeFactory, request a service such as MarketDataService, AccountService or TradeService, and call methods that return shared library types like Ticker. Private endpoints need an ExchangeSpecification carrying your API credentials, and a separate StreamingExchangeFactory path exists for websocket subscriptions.

### How do you use XChange in Java?

Add xchange-core plus the module for your venue, then call ExchangeFactory.INSTANCE.createExchange with the venue's Exchange class and pull a service from it. The README's first example gets a MarketDataService and requests a Ticker for CurrencyPair.BTC_USD.

## Sources

- [Issues](https://github.com/knowm/XChange/issues)
- [knowm/XChange on GitHub](https://github.com/knowm/XChange)
- [License: MIT](https://github.com/knowm/XChange/blob/develop/LICENSE)
- [Project website](http://knowm.org/open-source/xchange/)
- [README](https://github.com/knowm/XChange/blob/develop/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/knowm-xchange