Barter

What it is

A set of six Rust crates for building a trading system, rather than a bot you configure. barter is the engine and its state machine, barter-data streams public market data, barter-execution holds the order model and account state, barter-instrument the exchange and asset types, and barter-integration the REST and WebSocket plumbing underneath the other two. You bring a Strategy and a RiskManager as plug-in components and the engine calls them.

The design idea worth the price of learning Rust is that market data and execution are both swappable behind traits, so the same engine runs against a historic data file with mock fills, a live feed with mock fills, or a live feed with a real venue. That is what lets a backtest and a live deployment be the same program, and it is also why this card sits in two categories.

Liveness, in dates, and the shape of it matters. The last commit on main was 20 August 2026, and every one of the 14 commits in the following month carries that same date — a release burst, followed by four weeks of nothing. Six crates were published to crates.io that day: barter v0.14.0 at 19:56 UTC, with barter-data 0.13.0, barter-execution 0.9.0, barter-integration 0.12.0, barter-instrument 0.3.3 and barter-macro 0.2.1 alongside. The develop branch has not moved since 6 April 2025, so anything you read about work happening there is two years out of date.

The licence is MIT, from the LICENSE file — "Copyright (c) 2024 Barter Ecosystem Contributors" — and every crate declares MIT on crates.io.

Pricing

Free, MIT, nothing for sale. No hosted tier, no commercial licence, no sponsor tier and no referral arrangement with any venue in the README. On a page where most free software is paid for by exchange rebates, this one appears not to be paid for at all.

Data & coverage

barter-data carries eight venue integrations: Binance, Bitfinex, BitMEX, Bybit, Coinbase, Gate.io, Kraken and OKX. Binance and Bybit each have separate spot and futures modules, and Gate.io is the broadest — spot, perpetual, dated futures and options. Subscriptions are typed by kind (public trades, L1 order books), and the MarketStream interface is the extension point for a venue that is not in the list.

There is no history and no storage. barter-data is a live stream; a backtest reads a file you supply, and the example ships its own data directory. Nothing here downloads or maintains a candle archive, which is a real difference from the Python frameworks in this category.

Trading summaries come with the engine rather than from a separate analytics step — PnL, Sharpe, Sortino and drawdown against a risk-free rate you pass in.

Integrations

The engine can be driven and watched from outside the hot path, which is the part of the design most likely to matter in production. Algorithmic trading can be switched on and off from another process while market and account data keep being consumed, engine commands such as CloseAllPositions, OpenOrders and CancelOrders can be issued the same way, and an AuditStream feeds a replica of the engine state for monitoring components — a UI, a Telegram relay — without those components touching the trading loop.

Limitations

It ships no live execution client. This is the fact that decides whether Barter is the right tool. barter-execution/src/client/mod.rs declares exactly two modules — pub mod mock and a private mod binance — and client/binance/mod.rs is one byte long, a bare newline. That is not an artefact of the working branch: the barter-execution-0.9.0 crate downloaded from crates.io contains the same one-byte file. ExecutionClient is a well-specified trait with account snapshots, streams, order open and cancel, balances and trade history, and implementing it against your venue is your work, not the library's.

Every shipped example runs on mock execution. All seven programs in barter/examples/ are backtests, historic-data replays or live-market-data-with-mock-execution — there is no example of the library placing a real order, because there is nothing in it that can.

The version numbers mean what they say. Everything is 0.x, and barter went from 0.13.0 to 0.14.0 in two hours and forty minutes on the same afternoon. The README's own examples are marked no_run. Expect the API to break between releases and pin exact versions.

The project's domain is not the project's. https://barter.dev/ does not answer; the plain HTTP host redirects to https://www.barter.dev/, which returns three kilobytes of Namecheap parking copy offering the domain at auction. Anything linking there is linking to an advert.

Release cadence is bursty. Four weeks of silence after a single day of releases is not abandonment — the crates are current and the maintainer clearly shipped in August — but it is not the steady drip that keeps a venue integration working when an exchange changes an endpoint, and there is no second maintainer visible in the commit log.

No funding, no fee model documented at the card level. Mock execution fills what you tell it to fill; what a backtest charges is what your own configuration charges. This is a framework, and realism is a property of what you build with it.

Alternatives

NautilusTrader is the closest thing in this catalogue by ambition — an event-driven engine built so the same strategy code runs in backtest and live — and the decisive difference is that its live adapters exist. It is Python with a Rust core rather than Rust throughout, and it costs more to learn than either.

If the attraction is Rust rather than the engine, CCXT ships a Rust build of its unified client, which solves the venue problem and none of the state-management problem Barter is mostly about. Going the other way, Hummingbot and Freqtrade are finished bots where this is a kit.

The automation half of what Barter claims is real but unfinished, which is why this card's home is the research shelf and its second listing is trading bots and execution SDKs rather than the other way round. Come back to it as a bot the day a live ExecutionClient ships.