One writer, one queue, 63 crates
A single dedicated OS thread owns the execution engine and is the only code that mutates it. Everything else reaches it through one totally-ordered ingest queue — determinism by construction rather than by locking. Underneath sits a library of 63 crates in 18 layers whose dependency direction is not a convention but a build failure.
01The live core— runtime · one thread · one queue
One dedicated OS thread — vt-core — owns the ExecutionEngine and is the only mutator. Everything reaches it through one totally-ordered ingest queue, so determinism is by construction rather than by locking. The three inbound lanes do not behave alike, and that asymmetry is the design.
◂ drag to pan the drawing ▸
Exec events
fills, order updates, account, funding, liquidation — nothing is dropped.
Commands
place, cancel, flatten — sent with try_send. A full-queue rejection is returned to the caller and counted in the snapshot.
Market data
a conflation slot plus a marker message. At most one marker in flight, so a slow core sees the freshest price rather than an unbounded queue.
Outbound — the lossy observer
~16 ms COALESCEDA dirty flag drives the publish: at least every ~16 ms while busy, immediately when the queue goes idle, into an arc_swap cell the GUI reads on repaint. The snapshot build never runs per event.
Failure path — safe-state
CATCH_UNWINDEvery dispatch runs under catch_unwind. On a panic the core does not die and does not keep trading: trading halts (the risk gate denies every new order), all working orders get a best-effort cancel, and the fault surfaces in the snapshot.
Ordering is a property of the one queue rather than of a broker, and nothing outside the core mutates core state. That is a trade, not a free win: it buys determinism and a tail a lock cannot spike, and it costs the fan-out a bus would give you — every new observer is another reader of one snapshot, not a new subscriber on a topic.
02The crate ladder— dependency direction, machine-checked
63 crates over 18 layers, highest at the top. Dependency direction is down only — and the same spine runs through it.
[package.metadata.vike] layer = N, and CI fails a pull request whose
non-dev dependency does not declare a strictly lower layer. The ordering below is
therefore a verified fact about the tree.vike- prefix
aster sits at L41 because
binance at L40 forces it there — the
tightest fit on the sheet, and the reason one bridge is a rung above the others —
while report sits 25 layers above
core, the highest crate it depends on. Same rule both
times, and neither gap means anything.
Every dependency points down this spine. The bottom rung is the most depended-upon crate in the tree; the top depends on the most and is depended on by nothing.
The 14 bridges are the same 14 adapter threads feeding lane ① on sheet 01. Layer numbers are declared in each manifest — they are not inferred from the graph.
03The same 63 crates, by what they are
The bands above answer “what may depend on what”. This answers the question a reader actually arrives with — what is this crate. The layer rides on every chip, because that is the half a machine checks.
chart belongs under Desktop, and nothing verifies the one-line gloss on
an anchor crate either. What CI does verify is that every dependency declares a strictly
lower number — and that survives whatever grouping you choose.
Domain & primitives
the pure bottom — types, the venue roster, no I/O L10–L25 · 9Engines & analytics
the machinery a strategy is run by L20–L30 · 10Runtime
the single-writer core and the shared venue scaffolding L30–L62 · 5Venue bridges
one adapter per venue, each on its own thread L40–L41 · 14Research & ops
backtesting, reporting, collection, alerting L35–L55 · 10Binaries
what actually ships and runs L65–L68 · 6Desktop
the GUI shell and its panels L70–L90 · 9Layers, the bridge flag and each crate’s forcing dependency are read from the workspace manifests, so a crate joins this page by joining the workspace. The roles and the anchor glosses are the hand-made part, and this page says so rather than letting them look derived.
Every venue starts on paper.
Credentials arm a venue; your policy file caps it. Nothing goes live by accident.