CryptoExchange.Net: one C# shape for many exchange APIs

A base library you do not call directly

CryptoExchange.Net is described in the repository metadata as a C# .NET Standard base library used for implementing cryptocurrency exchange APIs, and the README is explicit about a point that trips people up. The CryptoExchange.Net package itself cannot be used directly for accessing APIs. You either install a client library from the list in the ecosystem table, or you use CryptoClients.Net, which includes access to all the exchange APIs. What the base library provides is a standardized way of implementing different APIs, which the README says results in a very similar experience for users of the API implementations. The audience is therefore a developer writing an exchange integration, or an application team that would rather consume a uniform interface than learn each venue's naming conventions. The project has existed since 2018 according to the badge in the header, is MIT licensed, and the current release is version 13.2.1, published on 2026-10-19 with the last push on the same day.

Shared client interfaces and the SharedApis V2 pattern

The mechanism behind the uniformity is a set of shared interfaces that each exchange implementation maps onto its own wire format. The README gives a concrete way to see this working, in the form of a prompt to give an AI coding assistant:

> "Show me how to fetch BTC/USDT spot tickers from Binance and OKX concurrently in C# using the SharedApis V2 pattern."

The expected output, as the README states it, should use the .SharedApi properties, SharedSymbol, IGetTickerRest and Task.WhenAll. That single sentence is a compact specification of the design. A ticker request is expressed against a shared interface, IGetTickerRest, the instrument is named with the shared symbol type, the client exposes its shared API surface, and the concurrency is ordinary .NET async code with Task.WhenAll. The value is that an application written against the shared interface keeps working when you swap the venue, and the same pattern holds for order books, trades and account calls.

The ecosystem table covers exchanges, and carries referral links

The README carries a table of the libraries in the ecosystem, with a column for API type, repository, NuGet package, referral link and referral fee discount. The venues listed include Aster as a DEX, and CEX venues such as Binance, BingX, Bitfinex, Bitget, BitMart, Bitstamp, BloFin, Bybit, Coinbase, CoinEx, CoinW and CoinGecko. The table also invites you to consider using a referral link to support development and mentions a possible trading fee discount, with the discount column showing entries such as 20 percent for Binance, BingX and CoinEx, 30 percent for BitMart and 4 percent for Aster, and dashes for the exchanges with no referral arrangement. That is worth naming plainly rather than glossing over. The libraries are MIT licensed and the base library is free, but the exchange client packages are distributed with a commercial referral attached, so a team that does not want its users routed through an affiliate link has to check the table before choosing a package.

The repository ships instruction files for AI coding assistants

One thing stands out about this repository compared with a typical exchange client library, and it is a section titled For AI Coding Assistants. The library and the wider ecosystem are described as providing first-class support for AI coding assistants, and the README then lists where those instructions live:

- **Agents**: `AGENTS.md` (auto-detected at repo root)
- **Cursor**: `.cursor/rules/cryptoexchange-net.mdc`
- **GitHub Copilot**: `.github/copilot-instructions.md`
- **Other tools** (Windsurf, Codex, Continue, Aider, etc.): `llms.txt` at repo root
- **Compilable examples**: `Examples/ai-friendly/`

For single-exchange code the README points at the same kind of files in each exchange's own repository, naming Binance.Net, Bybit.Net and OKX.Net as examples, and it links a cryptoexchange-skills-hub repository of installable skills. The top-level entries confirm the shape, with AGENTS.md, llms.txt, llms-full.txt and a .cursor directory at the root. For a library with a uniform but non-obvious interface, publishing the conventions as machine-readable instructions is a practical decision, and it is rare enough to be worth a paragraph on its own.

The examples folder does the work a tutorial would

The repository layout shows where a new user should actually start. Under Examples there is a BlazorClient, a ConsoleClient, a SharedClients directory, an ai-friendly directory and an example-config.json file, plus a README. The SharedClients project is the one to read if you want to see how a single application talks to more than one exchange through the shared interfaces, and the Blazor and Console clients show the same thing without a browser framework in the way. The example-config.json is presumably the shape of the client configuration, which is a useful reference when you are wiring credentials and options for the first time. The root also has a CryptoExchange.Net.sln, a CryptoExchange.Net directory for the library itself, a CryptoExchange.Net.UnitTests directory, a docs directory and the llms files, so the documentation exists in three forms, prose, compiled examples and machine-readable instructions.

Version 13 and a fast release cadence

The release history shows a project that ships often. Version 13.1.0 came out on 2026-09-28, 13.2.0 on 2026-10-13 and 13.2.1 on 2026-10-19, so the 13.2 line moved twice in three weeks. That cadence is typical of a library that has to absorb exchange API changes as they happen, and it is the main operational consideration for anyone depending on it, because a version number that moves this fast needs pinning rather than floating. The .NET Standard base is what lets a single library serve a wide range of target frameworks, and the library targets .NET, with the unit test project alongside it and the build running through GitHub Actions on the dotnet workflow. Documentation lives on a separate site, cryptoexchange.jkorf.dev, and the README is explicit that the base library and the client libraries are described there.

Editorial conclusion

CryptoExchange.Net fits a .NET team that supports several exchanges and wants one calling convention, one set of shared client interfaces and one place to fix a breaking change, rather than a separate hand-written integration per venue. It does not fit someone who wants a single exchange integration, since the base package cannot call an API on its own, and a project with one exchange is usually better served by that exchange's own client library. Before adopting it, read the documentation for the shared client interfaces, check the version history of the client library you intend to use against the base library version you pin, and decide whether the referral-linked client packages in the ecosystem table are acceptable for your project.

Frequently asked questions

Official sources

1. JKorf/CryptoExchange.Net on GitHub
2. License: MIT
3. Project website
4. README
5. Releases