vike
Desktop app

The cockpit

The Polymarket scalp cockpit — the rolling-window chain rail, the Price-to-Beat header, the one-click ticket with its arm switch, and the probability ladder over integer-cent rungs.

The cockpit is the Polymarket window kind, and its widgets live in crates/vike-cockpit/src/lib.rs: reusable egui panels for the rolling up/down markets a scalper trades. Like the DOM it is Rust-native, chart-engine-free and execution-core-free — each widget is a stateless draw over caller-owned view state and borrowed per-frame inputs, returning neutral actions the app maps to its own commands. Four modules make up the Phase-1 set: chain, header, ticket and ladder, each with a pure, unit-tested core beneath the paint. The wiring around them is crates/vike-app-core/src/tool_views/cockpit.rs.

The chain rail

crates/vike-cockpit/src/chain.rs states the law the rail is built on: Polymarket's short-horizon up/down markets are a deterministic chain of fixed-length buckets — each window opens on a boundary, open = now - now % window, and closes window seconds later, when the next one takes over. A scalper trades the current window while watching the next few line up, so the rail shows the current window plus the next N, each with a live MM:SS countdown, its Up/Down odds and its volume; the current window's countdown is rendered large and turns red inside the final URGENT_MS — ten seconds. The arithmetic is pure and tested: window_open_ms floors with rem_euclid so negative timestamps floor toward −∞, window_close_ms is the next open, chain_windows returns the current window plus n more, and fmt_countdown renders M:SS and clamps an already-closed value to 0:00. Clicking a card emits ChainRailAction::SelectWindow.

The glue fixes the constants: POLY_WINDOW_SECS is 300 — the five-minute market — and POLY_CHAIN_LOOKAHEAD shows four future windows. Colour follows Polymarket's language: YES/Up green, NO/Down red.

The Price-to-Beat header

crates/vike-cockpit/src/header.rs renders the four numbers a scalper lives off: the reference price the window opened at (the "price to beat", loudest), the live spot, the signed distance between them (ptb_delta is spot minus reference — positive means Up is winning, green; negative Down, red) and the time left, plus the current Up/Down odds. It is a readout: draw takes only borrowed PtbInputs and paints, and its countdown reuses chain::fmt_countdown so every cockpit clock formats identically.

The one-click ticket

crates/vike-cockpit/src/ticket.rs trades a form for two large BUY UP / BUY DOWN buttons with the live price on their face, quick-size chips (SIZE_CHIPS: +$1, +$5, +$25, +$100, each adding to the stake) and a fee-inclusive payout preview. payout_preview is the pure core: size / price shares each redeem at $1, the net profit is that minus the stake and the fee on winnings, and a degenerate price or stake yields nothing to win. FEE_BPS is 0 today — Polymarket charges none — but the preview is fee-aware so a future schedule flows through that one site. TicketState starts disarmed with a $1 stake.

The arm switch is the button colour

The header of ticket.rs describes the safety-versus-speed switch: disarmed, the buy buttons are muted and inert; armed, they light up and fire. draw emits TicketAction::BuyUp or BuyDown only while armed, so the trading mode is unmistakable before a click sends anything.

The probability ladder

crates/vike-cockpit/src/ladder.rs is the DOM's sibling adapted to a prediction market. Instead of an unbounded price grid the rungs are the integer-cent probabilities 1¢ through 99¢ — 0 and 100 are resolved states, never a live rung. Each rung carries its resting YES-token depth: a bid column (buying YES, Up, green) on the left and an ask column (selling YES, which is buying NO, Down, red) on the right. Each side paints a depth bar whose width is proportional to resting size and whose alpha rises with it — a liquidity heatmap normalised against the peak single-side size over the visible rungs, so a wall of depth is the widest, brightest rung. Clicking a rung's column rests a limit there (ProbLadderAction::PlaceLimit, the cent as a 0–1 probability); the inline ✕ on your own marker cancels (CancelOrder). The visible window centres on the inside market, or on 50¢ when neither side is known.

The glue buckets the book onto that ladder: bucket_prob_levels sums every level that rounds to the same cent, drops the resolved ends, and hands the ladder the top 64 levels per side. The YES/NO quote it derives from the single YES-token book is stated in its own comment: buying YES pays the best ask, and buying NO is approximately one minus the best bid.

What the cockpit does not yet source

cockpit_tool_content's doc is explicit about neutral inputs. Only the current window's rail card carries live odds; future windows' odds and every per-window volume stay None, because those markets are not yet resolved and full per-window Gamma resolution is a follow-up, deliberately not a fetch loop in the render path. The header's reference and spot are fed 0.0, because no BTC/ETH spot feed is threaded to the cockpit yet. Selecting a window on the rail emits no core action. The rail and ladder label is the resolved market name when the background Gamma resolver has cached one for the token, else the elided token id (poly_labels::poly_short_label) — the raw 78-digit id is unreadable. A book counts as stale after POLY_STALE_MS, fifteen seconds, about 7.5× the DOM's two seconds, because a Polymarket book ticks far less often and a valid quiet market would otherwise flash STALE.

Where an order goes

Ticket and ladder actions become CockpitCmd::Submit — a market taker when price is None, a resting limit otherwise, on venue "polymarket" — or CockpitCmd::Cancel, and drain through the same order_dispatch chokepoint as every other UI order as SubmitSource::Cockpit.

Polymarket has no testnet

crates/vike-desktop/Cargo.toml's polymarket feature only makes the live arm compile; what mounts at runtime is decided by two environment gates, both off by default — POLY_EXEC=1 for live execution and POLY_RECONCILE=1 for reconciliation — and its comment says plainly that enabling POLY_EXEC=1 trades real money on a venue that is US-geo-blocked. Without the feature the venue falls through to the paper arm. Polymarket operations carries the whole argument.

On this page