PAPER · no real money
Learn FBatchEx
One row per feature: what it is, why it is there, how to use it, and what you
should see. The same list lives in FEATURES.md in the repo.
One clearing price §21.1
What: Every trade in one auction fills at a single price.
Why: A shared price means no one gets a better deal for being fast.
How: Send two crossing orders to a pair, then watch the pair clear on the Markets screen, or run `cargo run -p fbx-auction --example crypto_spot_uncross`.
You should see: All fills print the same price; the transcript shows one `p*`.
Most-volume clearing §21.2
What: The auction picks the price that trades the most, with a fixed tie-break ladder.
Why: It fills the most willing buyers and sellers at a fair, repeatable price.
How: Run `cargo test -p fbx-auction clearing` or read the ladder artifact.
You should see: The clear sits at the volume-max price; the same book always picks the same one. See `artifacts/phase-02-clearing-ladder.txt`.
No time priority §21.3
What: Reordering the same orders gives the same fills and prices.
Why: Arriving a microsecond sooner buys no edge in a batch.
How: Run `cargo test -p fbx-auction properties` (the shuffle property test).
You should see: Shuffled order sets clear to byte-identical fills. See `artifacts/phase-02-properties.txt`.
Price-first, pro-rata fills §21.4
What: Better-priced orders fill in full; the edge price splits by size.
Why: It rewards a keener price, then shares the last level fairly.
How: Run `cargo test -p fbx-auction allocate` or read the allocation artifact.
You should see: Top prices fill fully; the marginal level splits pro-rata with lot rounding. See `artifacts/phase-02-allocation.txt`.
Market-to-limit residual §21.5
What: A market order that does not fully fill rests as a limit at the clearing price.
Why: It caps the price a market order can pay and obeys its time rule.
How: Run `cargo test -p fbx-auction residual` (the AUD-10 golden case).
You should see: The residual rests at `p*` tagged `market_residual` and obeys `TIF`. See `artifacts/phase-02-residual.txt`.
Time-in-force (IOC / FOK / GTD) §21.6
What: `IOC` cancels the rest, `FOK` is all-or-none, `GTD` rests until day end.
Why: It lets a trader say how long an order should live.
How: Pick a time-in-force on the Trade ticket, or run `cargo test -p fbx-auction fok`.
You should see: `IOC` leaves no rest; a killed `FOK` does not move `p*`; `GTD` expires at the day edge.
Dark orders with a minimum size §21.7
What: Hidden orders fill at the lit clearing price, only when the fill meets the minimum.
Why: A big order can trade without showing its hand or being picked off.
How: Run `cargo test -p fbx-auction dark` (dark + `MEQ` golden cases).
You should see: Dark fills only at lit `p*` and only at or above the minimum. See `artifacts/phase-03-meq.txt`.
Sealed order book §21.8
What: No one sees the resting book before the clear; lit prints right away, dark prints later and summed.
Why: A hidden book stops snooping and front-running.
How: Open the Markets screen during a batch; the book is not shown until it clears.
You should see: No pre-trade book is exposed; only post-clear prints appear.
Random sealing lock §21.9
What: Orders at or after a seeded random lock roll to the next auction.
Why: A random cut-off stops last-instant timing games.
How: Run `cargo test -p fbx-scheduler cadence` (the seal and lock test).
You should see: The lock `δ` is journaled and replay reproduces it. See `artifacts/phase-04-cadence.txt`.
Price collar and halt §21.10
What: A clear outside the price band does not trade and sets off a halt.
Why: It guards against a runaway or bad-data price.
How: Run `cargo test -p fbx-risk reference` or `cargo test -p fbx-auction collar`.
You should see: An out-of-band clear makes no fills; a break starts a journaled halt and reseed. See `artifacts/phase-05-reference.txt`.
Collateral pre-check §21.11
What: Orders past your collateral at the band edge are turned away; positions net after the trade.
Why: No one can trade more than they can cover.
How: Fund a paper account on the Funding screen, then send an order over your balance.
You should see: The over-collateral order is rejected; reserved equals released on an end state. See `artifacts/phase-05-stp-collateral.txt`.
1s / 1m / 1h pools §21.12
What: Three auction rates run side by side and never share liquidity.
Why: A trader picks the beat that fits, fast or patient.
How: Pick a pool on the Trade ticket, or run `cargo test -p fbx-scheduler cadence`.
You should see: Each pool clears on its own; orders never cross between pools.
FIX and REST parity §21.13
What: The same order gives the same outcome over `FIX` or `REST`.
Why: A maker can use either wire and get the same result.
How: Run `cargo test -p fbx-fix parity` (the shared scenario golden).
You should see: `FIX` and `REST` produce identical fills for one scenario.
Deterministic replay §21.14
What: Replaying the journal rebuilds byte-identical engine state.
Why: Every run can be audited and reproduced exactly.
How: Run `cargo run -p fbx-replay -- --journal <J>` against a saved journal.
You should see: Replay state matches the original byte for byte.
Thesis simulation §21.15
What: The sim shows speed wins no edge in a batch and makers stay paid.
Why: It tests the core idea before the heavy build.
How: Run `cargo run -p fbx-backtest -- real-thesis --tape <tape> --out <dir>`.
You should see: Within-pool latency edge is zero; makers stay profitable. See `artifacts/phase-00-real-data/real-data-thesis.md`.
Throughput and stress §21.16
What: An auction of at least 100,000 messages for one pair clears inside budget.
Why: The venue must hold up under real load.
How: Run `cargo run -p fbx-bench` or the stress harness.
You should see: The big auction clears in budget with no lost or doubled messages.
Double-entry funding §21.17
What: Every deposit and withdrawal balances and is logged once.
Why: Money in and out is always accounted for.
How: Deposit and withdraw on the Funding screen, or run `cargo test -p fbx-funding`.
You should see: The ledger always balances; no free balance goes below zero; entries are idempotent.
Paper / live isolation §21.18
What: Paper and live accounts never mix; live funding stays off until every gate is met.
Why: Paper play can never touch real money by accident.
How: Check the `PAPER` badge in the header; try `{"mode":"live"}` on sign-in.
You should see: A live sign-in is refused with `403` until the gates pass.
Web and phone parity §21.19
What: The web and phone apps show the same state and use only the public `API`.
Why: A user sees the same account on any device.
How: Open the same paper account on the web app and the Android build.
You should see: Both show the same positions and orders; the server re-checks all input.
Security controls §21.20
What: Rate caps, a signed-request replay guard, scoped access, and withdrawal `MFA`.
Why: It keeps accounts and orders safe and private.
How: Run `cargo test -p fbx-security` and `cargo test -p fbx-rest auth`.
You should see: Replayed or unscoped requests are refused; no pre-trade order state leaks.
Local and cloud setup §21.21
What: `docker-compose up` gives a working local stack; the Terraform plan stands up the cloud.
Why: Anyone can run the venue locally or deploy it.
How: Run `docker compose up`, or `cargo run -p fbx-replay` for journal recovery.
You should see: The local stack serves the app; journal recovery brings state back.
Compliance gates §21.22
What: Every compliance must-have maps to a real config gate checked at boot.
Why: Live trading cannot start until the rules are met.
How: Run `cargo run -p fbx-modes --example crypto-gates-transcript`.
You should see: Live stays fail-closed while any gate is unmet. See `artifacts/phase-31-crypto-compliance/crypto-gates.txt`.
Backtest and replay tools §21.23
What: `fbx-backtest` runs a settable sim through the real engine and writes golden artifacts.
Why: Strategies can be tested and runs reproduced.
How: Run `cargo run -p fbx-backtest -- --scenario <toml>`.
You should see: The same seed makes the same artifacts every run. See `artifacts/phase-06-backtest/`.
Quality gate §21.24
What: One gate runs tests, coverage, lint, complexity, infosec, and the artifact rule.
Why: Bad code cannot reach the main branch.
How: Run `./scripts/quality.sh`.
You should see: Any failed check rejects the push; coverage stays at or above 80%.
Maker batch and quotes §21.25
What: Batch submit, scoped mass cancel, two-way quotes, and cancel-on-disconnect.
Why: A market maker can post and pull many quotes at once.
How: Use the Maker screen, or run `cargo test -p fbx-rest maker`.
You should see: A `MassQuote` posts both sides; a disconnect pulls the maker's live quotes.
High availability §21.26
What: Killing the active node lets a hot standby carry on with no acked order lost.
Why: The venue keeps running through a node failure.
How: Run `cargo test -p fbx-ha` (the failover golden).
You should see: The standby matches state byte for byte; one writer per shard holds.
Tracing and logs §21.27
What: Key calls carry spans with set fields; one request id flows gateway to engine.
Why: An operator can trace any order across the stack.
How: Run `cargo test -p fbx-rest trace` and read the trace artifact.
You should see: Logs are structured `JSON`; the hot path stays at `trace`. See `artifacts/phase-00-observability/rest-trace.json`.
Fault replay §21.28
What: A saved fault replays byte-identical in a clean checkout from its bundle.
Why: A live bug becomes a regression test.
How: Run `cargo run -p fbx-replay -- --bundle <dir>` or `--journal <J> --compare`.
You should see: The fault replays exactly; a fixed build shows it gone. See `artifacts/phase-00-cross-replay/`.
Deploy safety §21.29
What: `deploy.sh` refuses to apply unless the preflight passed for this commit and the tree is clean.
Why: No cloud spend before a green local run.
How: Run `./scripts/deploy-ready.sh --local`.
You should see: The gate passes only on a clean tree and green preflight. See `artifacts/phase-26-deploy-bundle/`.
Slow-pool guide §21.30
What: The `1m` and `1h` pools publish a per-second would-be price, volume, and imbalance.
Why: Patient traders get a hint without a pre-trade feed.
How: Watch the guide on the Markets screen for a slow pool, or run `cargo run -p fbx-guide`.
You should see: The `1s` pool stays sealed; a spoof of the guide never pays. See `artifacts/phase-30-indicative-guide/guide-evidence.md`.
Crypto spot trading §21.31
What: Crypto pairs fund and withdraw in `USDC` / `USDT` on chain and trade through the same engine.
Why: The first live path is a crypto exchange.
How: Trade `BTC/USDT` or `ETH/USDC` on the Trade ticket; run `cargo run -p fbx-funding --example proof-of-reserves`.
You should see: Crypto pairs clear like any pair; reserves cover the owed sum. See `artifacts/phase-31-custody/proof-of-reserves.txt`.
Web and phone apps §21.32
What: A person can paper-trade and paper-make a market from the web app or an Android build.
Why: Real users can try the venue end to end.
How: Open the web app, sign in to paper, then trade and make a market.
You should see: Orders book and quotes go live, all `PAPER`-badged.
Clean-room verification §21.33
What: Each feature's artifact is rebuilt from a fresh checkout in a clean container and a real use is driven.
Why: A feature is proven for a stranger, not just the build box.
How: Run `./scripts/independent-verify.sh` (needs docker).
You should see: The artifact rebuilds byte-identical and the real use reaches `USE OK:`.
Asks register §21.34
What: Every operator ask is a row with a clean-room check, an artifact, and a real use.
Why: Nothing is called done without a named, runnable check.
How: Run `cargo run -p fbx-health --example asks-register` and `./scripts/audit-asks.sh`.
You should see: Each row passes its check or is marked human with a reason. See `artifacts/asks-register.json`.
Done means green §21.35
What: A task is done only when the asks audit is zero-fail and the commit's `CI` run is green.
Why: A red check or a failing row reopens the task.
How: Run `./scripts/gate-done.sh verify`.
You should see: The gate passes only on a zero-fail audit and green `CI`. See `artifacts/phase-25-done-gate/done-gate.txt`.