What is Vike Trader?
Three surfaces over one execution core, fourteen venue bridges, a backtester that shares its fill model with paper trading, and a safety model in which every venue starts on paper.
Vike Trader is a trading platform written in Rust. It ships as three surfaces over one core: a desktop GUI with native charts, a headless daemon for unattended live trading, and a CLI that is also an MCP server for AI agents. Free. Source-available under FSL-1.1; every release becomes Apache-2.0 two years on. Every venue connection starts on paper.
The three surfaces
| Surface | Binary | What it is for |
|---|---|---|
| Desktop GUI | vike-desktop | egui/wgpu charts over a live feed, order entry, the Studio, venue and credential management. Its default fat build carries the local trading core and every venue bridge the mount wires by default — the IBKR, Polymarket and FXCM arms each need their own cargo feature; a thin build is the observe-only client. |
| Headless daemon | vike-tradehub | Runs a strategy from a TOML profile with no GUI, survives an SSH disconnect, and serves an authenticated observe/control socket that the CLI, the REPL and agents talk to. |
| CLI / MCP | vike-cli | backtest / sweep / walkforward against a data service, an interactive trade REPL over a running node, and mcp — a stdio MCP server for any MCP client. |
Two of them — vike-desktop and vike-tradehub — are composition roots over the execution core.
vike-cli is deliberately not: its manifest links only the light client crates, no concrete
backend, no vike-backtest, no engine crate. A backtest runs inside vike-datahub, the
compute-to-data server that sits next to the history and returns only the report; trade and
mcp are wire clients to a running vike-tradehub node. Where each of these runs, and what it
needs, is on Where it runs.
A Rhai strategy is the same code in a backtest and on the daemon, by decision rather than
accident: the daemon compiles a script through vike-script's one engine builder and registers no
host function of its own — crates/vike-tradehub/src/config.rs's resolve_script states both
halves. What does not carry over is user_data/indicators/: vike-tradehub never calls
install_user_indicators, so a user indicator that resolves under backtest is a
function-not-found on the daemon. Compiled strategies are a per-name question instead: the
registry's LIVE_CAPABLE ledger records which names would resolve on the daemon and then never
trade, with a written reason for each (a funding reader, for one, because live bars carry no
funding series).
Fourteen venue bridges
Every venue adapter implements one ExecutionClient contract: submit and cancel are required,
everything else has a default, and no order may silently vanish — a dead venue path must
synthesize a terminal rejection. The canonical roster is vike_model::VENUES
(crates/vike-model/src/venues.rs): binance, bybit, okx, deribit, oanda, ig, fxcm, dukascopy,
polymarket, ibkr, ctrader, alpaca, aster, hyperliquid.
That roster is a contract, not a list. Every per-venue capability table's completeness test iterates it and asserts a declared row for each entry, so adding a venue fails every table's tests until its rows land — time-in-force, fees, margin support and the rest are classified or the build is red. The generated pages under Venues are rendered from those same tables.
A backtester you can trust next to live
Backtest fills and paper-exchange fills come from one shared crate, vike-fills: one definition
of what a fill costs, when it happens and at what price, extracted verbatim from the backtester so
that a paper executor mounted on a live feed charges exactly what the simulator charges. Costs
([engine]), risk ([risk]) and the data slice ride in one run-profile TOML whether you run a
single backtest, a parameter sweep or an anchored walk-forward — the sweep and walk-forward verbs
ship the profile text verbatim so the server honours the whole [engine] surface, not a subset.
Start with Quickstart: first backtest.
Live reconciliation
A live session can run the reconciliation engine (VIKE_RECONCILE=1): on a schedule, and on
reconnect for the venues wired for it, it fetches the venue's own order, fill and position
reports, diffs them against local state, and resolves divergences under an explicit policy
(VIKE_RECONCILE_POLICY — hybrid, synthesize, quarantine or external-quarantine). Unset,
it is off and the process is byte-identical to one that never had it. The kinds and the policies
are documented under Reconciliation.
A measured latency budget
The core event hop is covered by a latency gate that runs in CI on a dedicated quiet runner with
reserved cores: crates/vike-core/tests/runtime_latency.rs's baseline harness gates the p99
core-hop tail against P99_BUDGET_NS, ten microseconds. It is an assertion on a measured number,
and it is honestly advisory: main carries no required status checks, so a red gate reports rather
than blocks, and merging past one is a human decision.
Paper by default
Two independent gates sit in front of live trading, and both default to closed:
- Absent credentials are the live gate. A venue whose keys are not in the credential store
(
<project>/settings/secrets.env) mounts as paper. There is no flag that arms a venue without keys. - A per-venue arming ceiling.
policy.venues.<venue>in<project>/settings/policy.toml(paper/demo/live, defaultpaper) is read before the credential read and can only ever refuse —vike_config::VenueMode::captakes the minimum. A box with no[venues]table mounts everything paper, whatever the credential store holds.
Risk and arming carries the whole model; Arm one venue for demo is the first time you open either gate.
Licence
Free. Source-available under FSL-1.1; every release becomes Apache-2.0 two years on. The
conversion is per version and rolling — each release starts its own two-year clock, and the
Apache-2.0 grant is irrevocable. Paid support and consulting on Vike Trader are explicitly
permitted; what the licence blocks is selling Vike Trader itself as a competing product or hosted
service. LICENSE.md is the whole grant, including the future-licence clause.
Getting started
Pick the surface you actually want — the desktop app, the headless daemon, the data service or the one-shot runner — then install it and run something that cannot reach a real account.
Where it runs
The desktop app, the headless daemon, the data service, the standalone runner and the two container images — what each can do, who manages it, and what it needs.