# Barter Rust trading engine and market-data streams — live execution is a trait you implement. *https://cryptomarkets.tools/tools/barter · Backtesting & Research Libraries* ## Facts ### At a glance | Field | Value | | --- | --- | | Vendor | Barter | | Category | Backtesting & Research Libraries | | Job | backtesting | | Website | https://github.com/barter-rs/barter-rs | | Pricing model | open-source | | Free tier | true | | Open source | true | | Licence | MIT | | Self-hosted | true | | KYC required | false | | Tested hands-on | false | | Last updated | 2026-09-19 | ### Coverage | Field | Value | | --- | --- | | Asset classes | spot, perpetuals, futures, options | | Chains | none | | Venues | cex, derivatives | | Data latency | realtime | | Platforms | library | | AI features | none | ### Interfaces | Field | Value | | --- | --- | | API | false | | Webhooks | false | | Scripting | Rust | | MCP server | false | | Export | none | ### Capabilities Yes: backtesting, automation, paper_trading No: charting, screening, live_trading, 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 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](https://cryptomarkets.tools/tools/nautilus-trader) 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](https://cryptomarkets.tools/tools/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](https://cryptomarkets.tools/tools/hummingbot) and [Freqtrade](https://cryptomarkets.tools/tools/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](https://cryptomarkets.tools/categories/trading-bots) rather than the other way round. Come back to it as a bot the day a live `ExecutionClient` ships. ## FAQ ### Can Barter place a real order on a real exchange? Not with what it ships. `barter-execution` declares two clients — `mock`, which is public, and `binance`, which is private and whose source file is a single newline byte. The same one-byte file is in the 0.9.0 crate published to crates.io. Live execution means implementing the `ExecutionClient` trait yourself. ### Is Barter a backtester or a live-trading framework? One engine with swappable market-data and execution components, which is the design both claims rest on. Of what it ships today, the backtest and paper-trading paths are complete and the live path is a trait with no implementation, so it is listed here and in backtesting libraries. ### Which venues can Barter stream? Eight — Binance, Bitfinex, BitMEX, Bybit, Coinbase, Gate.io, Kraken and OKX. Binance and Bybit have separate spot and futures modules; Gate.io carries spot, perpetual, dated futures and options. ### Is barter.dev the project's website? No. It resolves to a Namecheap parking page advertising the domain at auction, and the bare https host does not answer at all. The repository is the project. ## Also worth comparing - [Backtesting.py](https://cryptomarkets.tools/tools/backtesting-py.md) — Two thousand lines, one OHLC series, and no idea what a funding payment is. - [HftBacktest](https://cryptomarkets.tools/tools/hftbacktest.md) — Tick-by-tick backtesting that models order queue position and feed and order latency. - [LEAN](https://cryptomarkets.tools/tools/lean.md) — The engine behind QuantConnect, Apache-2.0 and runnable on your own machine. - [Lumibot](https://cryptomarkets.tools/tools/lumibot.md) — One Python strategy that backtests and then trades live, across eight CCXT exchanges. - [NautilusTrader](https://cryptomarkets.tools/tools/nautilus-trader.md) — Event-driven Rust engine that settles perpetual funding at the venue boundary. - [Jesse](https://cryptomarkets.tools/tools/jesse.md) — Python backtesting and research framework whose live-trading half is a paid plugin.