Flowsurface backfills footprint charts over Arrow IPC, and disables windows on Windows

Five exchanges, six panel types, one process

Flowsurface is a native desktop charting application for crypto markets, built in Rust on the iced framework, supporting Binance, Bybit, Hyperliquid, OKX and MEXC.

The panel types are where a crypto charting tool distinguishes itself from a candlestick viewer.

The heatmap, described as historical DOM, uses live trades and the L2 orderbook to build a time-series heatmap with customizable price grouping, different time aggregations, and either a fixed or a visible-range volume profile. That combination is the reason the tool exists: it shows where liquidity sat over time, not where price went.

The footprint chart layers price grouping and interval aggregation on top of a candlestick, with configurable clustering methods, imbalance and naked-POC studies. The naked-POC study in particular is the thing order flow traders look for, since a price level that traded without moving much volume often matters.

DOM or ladder shows the current L2 orderbook alongside recent trade volumes on grouped price levels. Time and sales is a scrollable list of live trades, which is the simplest panel and still useful as a sanity check.

Candlestick supports both time-based and custom tick-based intervals, so you can chart by trade count rather than by clock.

Comparison is a line graph for multiple data sources normalised by kline `close` prices on a percentage scale, which is the only sane way to put two assets with different prices on one axis.

Around those: real-time sound effects driven by trade streams, pane linking for switching tickers across panes, persistent layouts, and themes with editable colour palettes.

Three sources for historical trades, and the default gives you none

By default Flowsurface captures and plots live trades in real time over WebSocket, and does nothing else. Historical trades on a footprint chart are opt-in, enabled through Settings to Network, and there are three modes.

Exchange mode fetches directly from Binance's public REST API and its bulk data mirrors at data.binance.vision. The README characterises it as fast for daily archives and paginated and rate-limited for intraday ranges, and it is Binance only, covering spot, linear and inverse markets. That last limit is the practical one: the mode everyone will try first simply does not exist for Bybit, Hyperliquid, OKX or MEXC.

Server mode is the general answer. It fetches from any HTTP server exposing a `GET /trades.arrow` endpoint that returns an Arrow IPC stream. The contract is specified closely enough to implement against, which is unusual and useful:

Content-Type: application/vnd.apache.arrow.stream

with columns matched by name rather than position: `ts` as int64, `price` as float64, `qty` as float64, `is_sell` as bool. Query parameters are `venue`, `market`, `symbol`, `from` and `to` (both inclusive) and `limit`, and bearer-token auth is optional through an `Authorization: Bearer <token>` header.

Self-signed TLS certificates are accepted, which is what makes this usable with a local collector. It works with all exchanges and has no exchange rate limits, at the cost of you owning the infrastructure. A reference implementation exists as a separate repository, a self-contained collector that writes trades to DuckDB and serves them over this protocol.

Off mode is the default behaviour restated: live trades only, no backfill.

Two data paths are never configurable. Historical klines, open interest and ticker metadata or stats are always fetched from exchange REST APIs, and live trades, orderbook and kline updates are always streamed from exchange WebSocket feeds.

Windows loses multi-window to an upstream redraw bug

Multi-window and multi-monitor support is listed for macOS and Linux, and the platform notes section explains why Windows does not have it. The README attributes the limitation to a redraw issue affecting iced's current winit backend, and links the upstream issue in the rust-windowing winit repository.

That is a good example of stating a limitation with its cause rather than a shrug. It also tells you what is actually missing: you can lay charts out in panes inside one window, with pane linking for switching tickers, but you cannot put a chart on one monitor and another on a second as separate windows.

For a trading desk setup that is the difference between a tool you keep and a tool you tolerate, so the limitation is worth more than a line in a feature list.

The macOS situation is the mirror image. Multi-window is supported there, but the application has no Apple Developer ID signature or notarization, so security warnings appear. The workaround is the standard one: control-click or right-click the app and choose Open, or allow it through System Settings, Privacy and Security.

Windows binaries and MSIX installers are code-signed, with free signing from SignPath.io and a certificate from the SignPath Foundation. If App Installer cannot verify the publisher or the signing certificate, the README asks you to report it as an installation issue rather than work around it.

The macOS download is a universal DMG supporting Apple Silicon and Intel on macOS 11 or newer. Windows is an x64 MSIX installed for the current user with no administrator approval. Linux is an archive with install and uninstall scripts that preserve settings and credentials, and a portable path running the binary directly.

Building needs a Rust toolchain, ALSA headers on Linux, and Cargo

The source path is conventional for a Rust desktop application, with one Linux-specific hurdle.

Requirements are the Rust toolchain, Git, and system dependencies that differ per platform. On Linux that means a C toolchain and ALSA development headers, since the application processes audio for its trade-driven sound effects:

sudo apt install build-essential pkg-config libasound2-dev

on Debian or Ubuntu, `sudo pacman -S base-devel alsa-lib` on Arch, and `sudo dnf install gcc make alsa-lib-devel` on Fedora. On macOS you install the Xcode Command Line Tools with `xcode-select --install`. Windows needs nothing beyond the toolchain.

There are two build routes. Installing the published crate directly:

cargo install --git https://github.com/flowsurface-rs/flowsurface flowsurface

or cloning and building:

git clone https://github.com/flowsurface-rs/flowsurface
cd flowsurface
cargo build --release
cargo run --release

The manifest shows a Cargo workspace on edition 2024 with two internal members, `data` and `exchange`, published as flowsurface-data and flowsurface-exchange at the same version as the main crate. Splitting the data model and the exchange connectivity out of the UI crate is the right shape for a charting application, and it is what lets an external collector or a future backend share the same types.

The UI is iced 0.14 with default-features disabled and an explicit feature list: wgpu for GPU rendering, tokio for the async runtime, canvas, sipper, advanced, unconditional-rendering, crisp, and both x11 and wayland. Declaring both display servers explicitly is what enables the Linux support the earlier section relies on.

Networking is reqwest 0.12 with rustls-tls rather than the system TLS stack, and Arrow 59.1 crates back the historical trade protocol. There is also `clippy.toml`, `rustfmt.toml` and a `rust-toolchain.toml`, plus separate lint and format GitHub Actions workflows whose badges sit at the top of the README.

GPL-3.0 on a desktop binary, with release discipline behind it

The licence is GPL-3.0-or-later, stated in Cargo.toml, with the LICENSE file at the repository root and a badge in the README.

For a desktop application this is a clean case rather than a complicated one. Redistributing the application or a modified build can trigger GPL obligations. The obligation attaches if you redistribute the application or a modified build, which for a charting tool most people never do.

The metadata declares the crate categories as finance, visualization and gui, which is a reasonable self-description for something between a terminal and a full trading platform.

Release cadence is the more useful signal here. v0.8.10 shipped on 2026-10-13, three days before the last push on 2026-10-16. Before that, v0.8.9 on 2026-06-23 and v0.8.8 on 2026-04-24.

The gaps are wide and that is worth noticing. Four months between v0.8.8 and v0.8.9, then nearly four more to v0.8.10. A version line under 1.0 with month-long gaps is a project shipping when it has something to ship rather than on a schedule, which is a different risk profile from a monthly release: you may wait a while for a fix, and you may also find a fix in a patch release sooner than expected.

The acknowledgements also name an origin for the project's design: Kraken Desktop, formerly Cryptowatch, described as the main inspiration that sparked the project. For anyone choosing between charting tools, that lineage explains the design language more usefully than a feature list does.

Editorial conclusion

Adopt Flowsurface if you analyse crypto markets from a desktop and want footprint, DOM and historical DOM heatmaps across several exchanges without running a browser tab per chart. Do not adopt it if you need multiple windows on Windows, or if you need historical trades on an exchange other than Binance without standing up your own data server. Verify first which of the three trade fetching modes you will actually use, since the default is live trades only, and whether self-signed certificates on your own server are acceptable in your environment.

Frequently asked questions

Official sources

1. flowsurface-rs/flowsurface on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases