vike
Getting started

Quickstart: first paper mount

A live Binance feed, every venue on the paper exchange, and a first order that cannot reach a real account.

A paper mount is the desktop app's default state, not a mode you switch on: with no credential store and no [venues] table, vike_mount::make_engine gives every venue the paper exchange, and the first order you place is filled locally against live bars. Ten minutes, no API key.

What you need

  • The vike-desktop binary — Windows or Linux; the backend Docker image ships no GUI, and the thin image's GUI is observe-only — it holds no local core, so it cannot do this walk. The desktop build needs the GPU Requirements names.
  • Internet access to Binance's public market-data endpoints (crates/bridges/binance/src/market_feed.rs's BINANCE_URLS).
  • No credentials. Leave <project>/settings/secrets.env absent for this walk.

Why nothing real can happen

Two gates sit in front of every venue, and crates/vike-mount/src/lib.rs's header states their order. The per-venue arming ceiling (policy.venues.<venue>: paper < demo < live) is consulted first, above the credential read — a paper venue "returns the paper client having loaded no credential, fetched no instrument grid and opened no socket". Only then does the older rule apply: absent credentials mean the venue stays paper.

The ceiling's default is the safe end. crates/vike-mount/src/policy.rs's MountPolicy::venues defaults to paper for every venue, and a missing policy.toml reads the same way, so a box with no [venues] table mounts everything paper whatever its credential store holds. The fold is vike_config::VenueMode::cap, a min: venues.bybit = "live" does not put bybit live, it only declines to stop it. VenueMode::Paper's own doc is the whole promise — "Simulated fills against the local paper exchange. No credential is used, no order leaves the process."

1. Launch the app

vike-desktop

Settings load before the log subscriber, the window, any feed and any core (crates/vike-desktop/src/main.rs's resolve_settings), and the startup disclosure (vike_config::boot_lines) logs every policy.* ceiling plus one aggregated venues line. The window opens maximized, titled vike_trader_rust — live, on the default layout from crates/vike-app-core/src/startup.rs's plan: one BTCUSDT 1m Binance chart, its bar feed already ensured.

Behind it, App::new builds the local core through vike_run::build_node — every wired venue's engine via make_engine, ("binance", "BTCUSDT") the primary (crates/vike-run/src/node.rs's BINANCE_MARKET), 10_000.0 seed per venue (NodeConfig::seed_cash). Each paper engine is crates/vike-mount/src/paper_fallback.rs's paper_engine: a PaperExecutionClient with slippage 0.0002, the venue's static fee schedule (vike_model::fee_schedule_for keyed by vike_catalog::fee_lane), BalanceMode::Delta, and the HALT sentinel armed (paper_client).

2. Open the Trade window

Click Trade in the launcher row (WinKind::LAUNCHERS). The window (crates/vike-app-core/src/tool_views/trade.rs's trade_tool_content) is a cross-venue equity hero, a per-venue Accounts table, a focused trade card and a working-orders table. Accounts rows carry a Δ mode tag — equity_panel::EquityRow's rendering of BalanceMode::Delta. The trade card's header shows the symbol, a PAPER badge and the mark; the ticket has Market / Limit / Stop tabs, a size field and an optional + TP / SL bracket. BUY and SELL stay disabled until the size is positive, a limit has a price or a stop a trigger, and the core reports no fault (trade_card).

3. Place a market order

Pick Market, enter a small size, click BUY. The ticket becomes a TradeSubmit, and the only path to the command lane is crates/vike-app-core/src/order_dispatch.rs's Planner::admit, which always validates against the local preview cap (order_entry::OrderLimits::with_max_notional, fed by policy.max_notional_per_order, permissive when unset), routes to the snapshot's market — binance BTCUSDT in the local build — and try_sends into the core's single ingest queue, so the GUI never blocks (crates/vike-core/src/runtime/mod.rs).

PaperExecutionClient's doc says what happens next: submit publishes Submitted + Accepted and rests the order; on_bar, "driven by the core on each closed bar of the mounted series", fills the book with the engine's exact semantics — next-open market fills, limit/stop triggers, adverse-first intrabar resolution, slippage plus maker/taker fees. So a market order fills at the open of the next closed 1m bar, up to a minute after you click.

Keep the 1m chart open on the mounted symbol

The paper book fills "against that venue's live 1m bars via the core's on_bar seam (so its bar feed must be subscribed)" — paper_fallback.rs's make_engine doc. The default BTCUSDT@1m chart is that subscription, and feed_lifecycle::reap_orphaned_feeds stops any feed no window references. Close or re-interval that chart and resting paper orders wait for bars that never arrive.

4. Verify

  • The working-orders table lists the order until a terminal status — is_terminal_status names FILLED, CANCELED, REJECTED, DENIED, EXPIRED, LIQUIDATED; anything else keeps its inline ✕ cancel.
  • After the fill, the trade card's position line reads LONG or SHORT with size, average price and unrealized P&L; the hero's Realized / Fees / Funding are hero_totals' folds over the Accounts rows.
  • The log lands under <project>/settings/state/logs by default (vike_log::resolve_log_dir), prefix vike-desktop. With journaling on (VIKE_JOURNAL_DIR or a run profile) the Tearsheet window reads the fill back from this session's command journal (tearsheet_tool_content).

Now rehearse the kill switch. touch <project>/settings/state/HALT — rung 2 of vike_bridge_core::halt::halt_path_from_env; VIKE_HALT_FILE names a path outright. A paper mount arms the sentinel precisely so this rehearsal is real (paper_client's doc): the next opening submit is refused with a terminal OrderRejected, a reducing submit is still admitted (vike_exec::halt::halt_admits_submit), and cancel is never gated. Delete the file to resume. Halt has the admit table.

Where to next

Troubleshooting

  • "I have credentials and the venue is still paper." The ceiling refused it. The mount logs ARMING CEILING: <venue> has live credentials, and this deployment's ceiling for it is paper → staying PAPER and names the key to set (report_capped_to_paper); with credentials and no [venues] table, a once-per-process ARMING CEILING NOW IN FORCE block lists every affected venue (venue_arming_migration_message). The Data Manager's Venues sub-tab shows Mode, Credentials and Effective per venue, each capped row naming its ArmingBlock (crates/vike-app-core/src/tool_views/venues.rs).
  • The order rests and never fills. The callout above; a limit far from the market rests until a closed bar crosses it.
  • BUY/SELL are greyed out. Size, price/trigger, or a core fault — after a panic the core enters safe state, HALTED, and denies every new order (runtime/mod.rs).
  • vike-desktop exits before a window appears. A removed risk variable is set (vike_config::REMOVED_ENV, exit code 2), or secrets.env carries a {VENUE}_MAINNET=1 line — vike_config::arming refuses a credential file that would arm real money; move the line to the process environment or delete it.

More in Troubleshooting.

On this page