Vaquum

Bitcoin research and trading · open source

The record

2021-01-01 → 2026-09-24 12:02 UTC

6,173,120,060 trades

5,245,163,016,011 USDT

We will never ask you to trust. We ask you to verify.

We are a research collective that deploys its own capital through an auditable and verifiable system we build and maintain. At Vaquum, open source is a first principle.

Open source

Closed-source trading software is a structural contradiction for a financial system built to eliminate counterparty risk.

It asks you to do the one thing Bitcoin was designed to eliminate: trust a black box as your operational infrastructure.

Our alpha does not live in the algorithms. It lives in our research and our thesis. So the algorithms are public, and you can check every one of them.

  1. 01Read the docs.
  2. 02Audit the code.
  3. 03Pull your data.
  4. 04Run your research.
  5. 05Set your strategy.
  6. 06Execute your trades.
  7. 07Judge the results.

We never touch your keys. You deploy our software on your own infrastructure.

The system

Seven products.
One system.

Every one of them is public on GitHub under the MIT License.

01 · The data layer

Bitcoin research and trading · open source

Event-sourced market data. Each trade is kept as recorded, and every derived number can be rebuilt from it.

Read the source ↗Return to the system

Scroll · Day one ↓

Source events are preserved as the checksum-verified canonical record. The same inputs produce the same outputs, and every projection rebuilds from the ledgered raw layer.

Repository
github.com/Vaquum/Origo
License
MIT

  1. Day one

    2017-08-17, the first day of BTCUSDT on Binance. Its first trade: 0.1 BTC at 4,261.48 USDT, at 04:00:28.322 UTC.

  2. Every trade, as recorded

    3,427 trades by midnight, each kept exactly as Binance recorded it: its ID, price, quantity, time, and which side took it.

  3. Checked before it is read

    Binance publishes each day as an archive with a SHA-256 sidecar, and Origo checks one against the other before it reads a row. Your browser has just done the same.

  4. The canonical day

    Every number Origo derives from this day, from a one-minute bar to a cell of the market-state cube, is built from these rows and can be built again.

Bars

One day.
Five cuts.

Origo cuts the same trades by the clock, by money, by coin, by count and by imbalance. Here is day one, cut each way in your browser with Origo’s formulas.

  1. 01TimeOne bar for every UTC minute that holds a trade.831 bars on day one
  2. 02DollarA new bar each time a million USDT has traded since midnight. A trade is never split between bars.4 bars on day one
  3. 03VolumeA new bar each time 100 BTC has traded since midnight.8 bars on day one
  4. 04TickA new bar every 1,000 trades.4 bars on day one
  5. 05ImbalanceA bar closes at the first trade that takes taker buys minus taker sells, in USDT, 100,000 either way from where the bar opened.19 bars on day one, the last still open at midnight

Each bar carries 16 measures: open, high, low, close, mean, standard deviation, volume, the share of trades in which the maker bought, the trade count, the USDT of its first, largest, smallest and last trade, its total USDT, and the maker side’s volume and USDT. Origo also writes source-labelled one-minute rows; they are not shown here.

Verify

Rebuild a
published day.

2020-01-01 is the first day of Origo’s published series. Rebuild it here, from Binance’s archive, and compare every bar with what Origo published.

  1. Fetch the official archive
  2. Check its SHA-256 against Binance’s sidecar
  3. Unpack its trades
  4. Build the day’s one-minute and million-USDT bars
  5. Compare every bar with Origo’s published files

Archives: Binance’s official daily trade files for 2017-08-17 and 2020-01-01, byte for byte as Origo keeps them in its test fixtures at e77d2d5. Published bars: vaquum/binance_btcusdt_1m_klines at db3d1be and vaquum/binance_btcusdt_1M_dollar_klines at bd303c2, the day’s rows read from their full-history files. Nothing is fetched from outside this page.

Accepted state

Proven before
it is read.

Readers see one accepted state at a time. A new build becomes that state only after it has been staged and checked, and the last complete one stays until it has.

  1. PartitionA bounded UTC interval: a day of archive, or a minute of provisional data.
  2. Provider revisionOne particular upstream input for that interval, with the evidence it came with.
  3. BuildThe components made from that input, each with its own content hash.
  4. GenerationThe build readers are given. A competing change cannot slip in while it is chosen.
  • Canonical archive days take precedence over the provisional minutes they cover.
  • A replacement that fails leaves the previous complete generation in place.
  • Missing, changed, failed or damaged partitions are repaired; a bad one can be rolled back or quarantined.
  • New components are added over the raw trades already kept, without fetching them again.
Six sources
SourceStageDeclared fromInput
Spot tradesLive2017-08-17Daily archive, then minutes over REST until the archive arrives
Perpetual tradesLive2019-09-08Daily archive and continuous capture, with a spool and repair
Spot aggregate tradesLive2017-08-17Daily archive, then minutes over REST
Perpetual aggregate tradesCanary2019-12-31Daily archive, then minutes over REST
Spot top 20 bookLive2026-10-24 13:00Two independent collectors; missing seconds stay missing
Perpetual top 20 bookLive2026-10-24 13:00Two independent collectors; missing seconds stay missing

The data laws

R1
The newest readable minute, with physical proof behind it
C1
The newest canonical interval that is due
C2
Every older canonical interval on the calendar
M1
The market-state cube readers are given
M2
The cube’s history, complete

Each law is judged from the builds, counts and hashes actually selected. Missing evidence is reported as unknown, never as a pass, and an archive not yet due is told apart from a failure.

Specifications

Vaquum
‘Origo’

Markets
Binance BTCUSDT spot and USDT-M perpetual
Sources
6: individual and aggregate trades, and top 20 books, for each market; five live, one canary
Bars
Time, dollar, volume, tick and dollar-imbalance, plus source-labelled one-minute rows
Series
Time 1m to 4h and dollar 1M to 240M for each trade family, from 2020-01-01: 48 declared
Publication
Monthly Parquet with per-file checksums, versioned Arrow, and full-history snapshots on Hugging Face
Cube
56.25 s × 125 USDT base cells of spot trades from 2021, queried over HTTP
Research
Monthly bar readers, the cube, rally discovery and recent microstructure
Monitoring
7 checks and 5 data laws, an evidence tape, a read-only dashboard and email alerts
Admission
100 GB of free space and 10 % of free inodes kept back
Not here
Order execution, portfolios and strategy backtests
Source
github.com/Vaquum/Origo · e77d2d5 · 2026-10-28 · MIT

Read the source ↗Return to the system

Every claim about Origo on this page is its source at e77d2d5, 2026-10-28. Source dates are the ones its registry declares, not a measure of complete coverage. The trades are Binance’s own archives; the bars are rebuilt in your browser and compared with Origo’s published files. As of 2026-10-29.

02 · The research engine

Bitcoin research and trading · open source

Puts trading ideas to recorded markets, keeps the evidence, and carries what is chosen into inference.

Read the source ↗Read the docs ↗Return to the system

Scroll · From a question to a Sensor ↓

Limen searches the parameters of models and rules alike, in your own Python or from a declared YAML pipeline. Every round is recorded, and a chosen one is rebuilt before it becomes a Sensor.

Repository
github.com/Vaquum/Limen
Install
pip install vaquum-limen
License
MIT

  1. The question

    Does recent momentum still pay after costs? Limen’s research book puts it to 1,920 recorded quarter-hour bars of BTCUSDT, from 2025-01-01.

  2. Split first

    960 bars to fit, 480 to choose, 480 for later. Each part makes its own features and labels, so none reaches across a boundary.

  3. A feature and a label

    Momentum is the close against the close 4 bars earlier. The label is the next bar’s open-to-close return. Each training bar becomes one point.

  4. Fitted on the past

    A scaler and a Ridge line, fitted to the 947 training rows alone. It tilts down: after a rise, it expects a slight fall.

  5. Four candidates

    Two windows, 4 and 12 bars, and two Ridge penalties. Each candidate trades the next 467 bars the way its forecast points, and pays 2 basis points a round trip.

  6. Costs decide

    Before costs, the 4-bar window earned 0.48 basis points a bar. After them, it lost 1.52, and the 12-bar window lost 1.80. Neither penalty changed a single decision.

  7. Carried forward

    Limen keeps one candidate per window, losers both, and wraps each as a Sensor. A Cohort averages them over 480 bars research never saw; its last forecast is +3.68 basis points.

Rules

Eight rules.
One year.

Limen ships eight classic long-or-flat rules as baselines. Here they are on 2024’s hourly bars, at 10 basis points a fill and 5 of slippage, each position worked out again in your browser.

  1. 01Buy and holdLong from the first bar to the last.Nov–Dec: +2.12 bp an hour after costs · 1 trade
  2. 02SMA crossLong while the 50-hour average is above the 200-hour.Nov–Dec: +0.82 bp an hour after costs · 5 trades
  3. 03EMA crossLong while the 12-hour exponential average is above the 26-hour.Nov–Dec: +1.17 bp an hour after costs · 21 trades
  4. 04MACDLong while MACD 12/26 is above its 9-hour signal line.Nov–Dec: −1.44 bp an hour after costs · 63 trades
  5. 05RSI reversionIn when the 14-hour RSI falls to 30; out when it reaches 70.Nov–Dec: −0.21 bp an hour after costs · 4 trades
  6. 06Bollinger reversionIn at or below the lower 20-hour band, 2 deviations out; out at the middle.Nov–Dec: +0.65 bp an hour after costs · 34 trades
  7. 07Donchian breakoutIn above the prior 20-hour high; out below the prior 10-hour low.Nov–Dec: +0.34 bp an hour after costs · 22 trades
  8. 08MomentumLong while the close is above the close 20 hours earlier.Nov–Dec: −0.89 bp an hour after costs · 84 trades

Each rule runs on its own in each period, from no history, so its warm-up stays flat. A signal at a close is acted on at the next bar. Results are Limen’s own, from the run published with 6.0.1: train January to September, validation October, test November and December. In the test months, no rule beat holding.

Verify

Run them
again.

Limen recorded both experiments when it published 6.0.1. Run them here, from the same bars, and compare every number with Limen’s record.

  1. Read the recorded bars
  2. Split, and prepare each part on its own
  3. Fit and score the four candidates
  4. Keep one per window, and forecast the 480 later bars
  5. Run the eight rules in each period, with costs
  6. Compare everything with Limen’s record

The quarter-hour bars are spot_15m_20250101_20250531.parquet, SHA-256 eb3392d…, and the hourly bars spot_1h_20240101_20241231.parquet, a634bbd…: Origo’s bars, as Limen’s example bundle pins them. The record is Limen’s native output from its 6.0.1 documentation publication, and the book’s own retained result. Nothing is fetched from outside this page.

Compiled Research

Declared,
then run.

The same engine runs a declared pipeline. The book’s second project writes its experiment as YAML, and the command line checks it, runs it and assesses it.

data_source
HistoricalData.get_any_file · the same 2025 quarter-hours
split_dates
Train 01-01 to 01-15 · validation to 01-18 · test to 01-22
indicators
roc, period 1: each bar’s rate of change
target
QuantileBinaryTarget: whether the next bar’s change beats the training median
scaler
The logistic policy, fitted on training rows
reference_architecture
logreg_binary, with C of 1.0 and 0.5
backtest
Cash spot BTCUSDT, 1 basis point a fill, 900-second bars
objective
backtest_total_return, maximized on validation
assessment
The top round by validation return, rebuilt as a Sensor, with predictions
  1. limen validateChecks the declaration: fields, types, dates, callables and parameters.
  2. limen profileLoads the data, samples preparation and fitting, and sizes the search.
  3. limen run --dry-runCompiles the experiment without running it.
  4. limen runEvaluates both candidates and records every round.
  5. limen assessRanks by validation, rebuilds the top round and writes its predictions.

Recorded by 6.0.1: 2 rounds, each −0.051 % on validation and −2.30 % on test after 81 trades; 1 selected and 1 Sensor rebuilt. Manifest sha256:dd58886c…

  1. Fetch the raw input
  2. Select before the split, if declared
  3. Split into train, validation and test
  4. Form bars inside each split
  5. Indicators and features
  6. Fit the target on train; apply it across
  7. Feature shims and ablation
  8. Fit the scaler on train; apply it across
  9. Align the schema; fit PCA on train
  10. Finalize the data
  11. Run the model

Every manifest runs in this order, so nothing is fitted before the split. The order cannot repair a feature that reads the future; feature causality stays the researcher’s.

  1. Every round is recorded.Its parameters, identity and metrics, and on request its predictions, alignment, trade ledger and fold details.
  2. A chosen round is rebuilt.Trainer refits it under the recorded manifest and replays it. Where the results file is kept, the replayed metrics must match it before a Sensor is made.
  3. Costs are declared.Fees, slippage, the product, funding and timing belong to the experiment, not to the result.
  4. The last window is reserved first.limen reserve marks it before research begins; research stops short of it, and its assessment is written to the project’s history. That history cannot show what was read elsewhere.

Specifications

Vaquum
‘Limen’

Interfaces
Python Research, with your own functions, and Compiled Research, from typed YAML through the CLI; one engine
Data
Origo’s BTCUSDT candles, 1m to 4h, and dollar bars, 1M to 240M; Binance archives; Parquet, CSV, ZIP and Arrow
Bars
Trade-count, volume, liquidity, imbalance and run bars over the source candles, formed inside each split
Features
117 indicators, 47 of them candlestick patterns; 120 feature helpers; a seven-label market-regime classifier
Targets
16 target classes, fitted on training rows
Models
18 reference architectures, from logistic regression and LightGBM to TabPFN, LSTM, linked learning and rule strategies
Search
Grid, random and Sobol; a mutable search queue; 5 reducers
Execution
Snapshot backtests with 20 measures; event execution for cash spot and linear perpetuals, with five ledgers and funding
Evidence
Walk-forward with purge and embargo, deflated Sharpe and PBO; Trainer reconstruction
Inference
Sensors, and Cohorts of compatible Sensors
Command line
14 commands, from validate to reserve and assess
Not here
Live order routing, order books, venue queues and liquidation models
Source
github.com/Vaquum/Limen · 6.0.1 · 9bc8a63 · 2026-10-29 · MIT · Python 3.10–3.13

Read the source ↗Read the docs ↗Return to the system

Every claim about Limen on this page is its source and documents at 6.0.1, 9bc8a63, 2026-10-29. The experiments are the research book’s own, and their results are what Limen recorded; your browser repeats them. The book runs the momentum case to show execution, selection and inference on recorded bars, not to settle the question. As of 2026-10-29.

03 · The decision layer

Bitcoin research and trading · open source

Turns signals into validated decisions, controlled capital deployment, and recoverable state.

Read the source ↗Return to the system

Scroll · One decision through Nexus ↓

Nexus separates user-defined decision logic from non-negotiable capital, risk, price, health, and platform controls. Each instance manages one trading account with durable state and crash-safe recovery.

Repository
github.com/Vaquum/Nexus
License
MIT

  1. One account

    One Nexus instance runs one account. In Nexus’s example it holds a pool of 10,000 USDT, and no order may take more than 15 % of it, nor all orders together more than 80 %.

  2. A decision

    A strategy returns an action: buy 0.01 BTC at the market, the same order you can follow through Praxis. Priced at the book’s best ask, it costs 805.14 USDT, plus an estimated fee.

  3. Six checks

    Intake, risk, price, capital, health and platform limits, in that order, and the first refusal stops it. On a real book 12 milliseconds old, all six allow it.

  4. Set aside

    The capital stage checks the pool and reserves the cost in the same step, under one lock, so two strategies cannot spend the same money. Unsent, the reservation lapses after 60 seconds.

  5. Sent, then working

    When Praxis sends the order, the reservation becomes capital in flight; when the venue acknowledges it, a working order. Every unit stays accounted for.

  6. Filled

    Praxis reports the fill: 0.01 BTC at 80,514.49. The working order becomes a position at its full cost, fee included, and 9,194.05 USDT stays available.

  7. Written down

    After every change Nexus appended the whole account to its log: five records, each with a CRC32. A restart reads them back, and the fill is marked applied, so replaying it does nothing.

Validation

Six gates.
One refusal.

Change one thing about the same decision, and a different stage refuses it. Every verdict and message here is Nexus’s own.

  1. 00As decided0.01 BTC, on a real book 12 milliseconds old.All six allow it, and 805.95 USDT is reserved
  2. 01HaltedAn operator has halted the account.Intake refuses · INTAKE_MODE_BLOCKS_ENTER
  3. 02A bad dayThe account has lost 250 USDT in 24 hours.Risk refuses · RISK_ROLLING_LOSS_24H_LIMIT
  4. 03A stale bookThe book is 6 seconds old.Price refuses · PRICE_BOOK_STALE
  5. 04Twice the size0.02 BTC: 16.1 % of the pool.Capital refuses · CAPITAL_RESERVATION_DENIED
  6. 05A slow venueThe venue takes 1.5 seconds to answer.Health refuses · HEALTH_LATENCY_BREACH
  7. 06A full handThe account already holds 0.045 BTC.Platform limits refuse · PLATFORM_LIMITS_MAX_POSITION_LIMIT

The limits are example settings: at most 10 orders a second, a book at most 5 seconds old, a spread of at most 5 and a price deviation of at most 10 basis points, at most 200 USDT lost in 24 hours, latency under 1,000 ms, and at most 2,000 USDT an order and 0.05 BTC held. Praxis, which runs Nexus, takes the price and platform limits from deployment caps that a live account must set. Exits, amendments and aborts skip the five stages after intake, so no limit can trap a position; a halted account still refuses exits and amendments at intake.

Recovery

Pull the
plug.

Nexus wrote the account to its log after every change above. Cut the log at any byte, as a power failure would, and see what a restart recovers.

The log is the file Nexus’s StateStore wrote at 953477a for the example above: an 8-byte header, then for each record its length, its CRC32 and the record in MessagePack, each holding the whole account. Its entries carry the example’s own times. Your browser reads the bytes, checks every CRC32, and decodes every record; nothing is fetched from outside this page.

Modes

Three modes.
One writer.

Six holds can halt an account and two can confine it to reducing. Nexus’s mode controller weighs them against health, and nothing else writes the mode.

Halted
Any halt hold, or health reading halted. Refuses entries, exits and amendments at intake; only aborts and cancels pass.
Reduce only
Otherwise, a reduce-only hold or health reading reduce only. Refuses entries.
Active
Otherwise. The holder is named in the order shutdown, manual, risk, reconciliation, protection, then health.

Specifications

Vaquum
‘Nexus’

Role
One account per instance: strategies’ actions in, validated orders out, outcomes back into durable state
Strategies
Python classes with seven callbacks, each on its own executor, sharing one capital pool by percentage
Signals
Prediction series read from Conduit as Arrow, matched to their bar’s close; timers per strategy
Actions
Enter, exit, modify and abort; 7 execution modes and 8 order types, carried out by Praxis
Validation
6 stages, in order and fail-fast: intake, risk, price, capital, health, platform limits
Capital
Reserved, in flight, working, filled or released; 15 % per order and 80 % in all; reservations lapse after 60 s
Modes
Active, reduce only, halted; 6 halt holds and 2 reduce-only holds
Recovery
A CRC32-checked write-ahead log, atomic snapshots, durable outcome deduplication, and boot reconciliation with Praxis
Loops
Predictions every 0.25 s, health every 5 s, mark-to-market every 30 s, snapshots every 300 s
Tests
1,619 test cases
Not here
A launcher or service of its own, venue connections, and research; Praxis runs Nexus, and Limen produces signals for it
Source
github.com/Vaquum/Nexus · 0.76.1 · 953477a · 2026-09-15 · MIT · Python 3.10 and later

Read the source ↗Return to the system

Every claim about Nexus on this page is its source at 953477a, 2026-09-15, version 0.76.1. The decision is an example; the book and the fill are the real ones on the Praxis page. The verdicts, the log and the modes were produced by Nexus’s own code, and your browser reads and checks them again. As of 2026-10-29.

04 · The execution system

Bitcoin research and trading · open source

Turns decisions into execution, durable state, and auditable outcomes.

Read the source ↗Return to the system

Scroll · One order through Praxis ↓

Praxis unifies order routing, venue communication, lifecycle management, and recovery around a single event spine. Every order is written to the spine before it is sent, and a restart rebuilds the account from what was written.

Repository
github.com/Vaquum/Praxis
License
MIT

  1. One record

    Praxis keeps one record of what it does: an append-only spine of events in SQLite. Its first row hangs from an anchor the spine keeps for itself.

  2. A decision arrives

    Buy 0.01 BTC at the market, in one shot, on a paper account. Praxis accepts the command, and writes that down first.

  3. Written before it is sent

    The order is named and recorded before the venue hears of it. Whatever a crash interrupts, the spine already holds the order’s name.

  4. Sent and filled

    Binsim, the paper venue, fills it from a real observed book: 0.01 BTC at 80,514.49 USDT, for a commission of 0.00001 BTC.

  5. Reported

    The outcome goes back to Nexus: filled, 0.01 of 0.01 BTC, for 805.1449 USDT.

  6. The process dies

    Everything Praxis held in memory is gone: the order, the position, the outcome. The spine is on disk.

  7. It starts from the spine

    Before it may send again, Praxis checks every row of the chain, replays the rows into its state, and asks the venue what happened while it was down.

  8. Ready

    The account stands again exactly as its five rows say it should.

  1. 0Genesis anchorSHA-256 of praxis.spine.chain.v1.genesis
  2. 1CommandAcceptedThe command, accepted into the account’s queue
  3. 2OrderSubmitIntentThe order, named before it is sent
  4. 3OrderSubmittedThe venue’s order ID
  5. 4FillReceived0.01 BTC at 80,514.49 USDT
  6. 5TradeOutcomeProducedFilled, and back to Nexus

Verify

Try to
break it.

These are the five rows a Praxis spine wrote for that order. Praxis checks them at every start, before it will send an order. Change one, and see what the check says.

verify_chain

event spine chain verified · 5 rows

Every row agrees with its own contents and with the row before it.

    Rows, hashes and verdicts are Praxis’s own: its Event Spine and verify_chain at d036870 wrote and checked them, and your browser works every hash out again from the same length-framed preimage. The order is an example; the book it filled from is a real observation.

    Execution

    One decision.
    Seven ways.

    The same 0.06 BTC, carried out seven ways. Single shot runs by default; a host turns on the other modes it allows.

    1. 01Single shotOne order: market, limit, IOC, stop, stop-limit, take-profit, take-profit-limit, or an OCO pair.On by default. A limit price can be amended; trigger prices cannot.
    2. 02TWAPEqual market slices at a fixed interval, buying or selling.The slice count and interval can change while it runs.
    3. 03Time DCAMarket buys on a schedule.Buys only.
    4. 04Scheduled VWAPMarket slices sized by weights you supply, summing to one.The weights are fixed once it starts; the interval can change.
    5. 05BracketA market entry, then a take-profit and a stop-loss on the other side, as one OCO pair.The protection can be amended. It rests, so Binsim cannot run it.
    6. 06IcebergOne limit order that shows the venue only part of its size.The venue refills it, not Praxis. It rests, so Binsim cannot run it.
    7. 07Ladder DCAResting limit orders at several prices, sized equally or by weight.It rests, so Binsim cannot run it.

    Paper

    Walk
    the book.

    Binsim fills a market order from a real book: three sealed observations of BTCUSDT, one second apart, collected on 2026-10-24. Choose a size and watch the order walk.

    The book: Vaquum/binance-book-collector A, BTCUSDT spot, segment 428, the first three original sealed observations, SHA-256 b0d9b7b…, from Praxis’s test fixtures. Binsim fills at each level in turn and does not use the liquidity up; it refuses a size beyond what the book shows, and charges 10 basis points, in BTC on a buy and in USDT on a sell.

    Live

    Armed,
    not assumed.

    Praxis runs on paper unless told otherwise. A live start needs every one of these, or the host refuses to start.

    1. The modeTRADE_MODE=liveWith no paper venue configured: live alongside BINSIM_URL is refused.
    2. The arm phrasePRAXIS_LIVE_ARM=I_UNDERSTAND_THIS_ENABLES_REAL_BINANCE_MAINNET_ORDERSByte for byte, checked before any adapter, socket or credential backend exists.
    3. Six capsPRAXIS_MAX_ORDER_NOTIONAL · PRAXIS_MAX_POSITION · PRAXIS_MAX_ORDER_RATE · PRAXIS_MAX_SPREAD_BPS · PRAXIS_BOOK_STALENESS_SECONDS · PRAXIS_MAX_SLIPPAGE_BPSEvery one set, and positive.
    4. Two breakersmax_daily_loss · max_drawdown or max_drawdown_pctIn every account’s manifest, so an account that loses halts on its own.
    5. Live credentialsA live credential backend, with separate keys for each account.

    The operator’s controls

    Halt
    Holds an account until it is resumed.
    Resume
    Clears that hold, and only that hold: a risk breaker stays tripped.
    Cancel all
    Asks to abort every open piece of work, and returns receipts for what it submitted.
    Close all
    Cancels, then sends market orders the other way. Its receipts are not proof the account is flat.

    Loopback only, behind a bearer token compared in constant time.

    Evidence

    Every claim,
    sourced.

    Praxis’s wiki explains one piece per article, in plain words, and every claim in it names the lines of code that make it true.

    What the chain provesdocs/wiki/atoms/what-the-chain-proves.md · traced against 49aa659
    1. The walk reads the marker before any row, and stops there if it is goneevent_spine.py 1254, refused at 879–884
    2. An unhashed row after a hashed one is refusedevent_spine.py 1263–1268
    3. A backward link that does not match is refusedevent_spine.py 1272–1277
    4. A hash that does not come out the same is refusedevent_spine.py 1279–1287
    5. It stops at the first row it refusesevent_spine.py 1277 or 1287, whichever check fails first
    6. The marks are worked out afresh from the fields beside themevent_spine.py 1279–1283, the working-out at 419–434
    Articles
    115
    Checker
    7,115 lines
    Its tests
    540
    Pages checked
    120

    The checker refuses evidence it cannot stand behind: a comment, a docstring or a signature offered as behaviour, a line range that does not hold what it claims, a term left unlinked from the article that owns it. It reasons over the code itself, branch by branch, to tell reachable lines from dead ones.

    Specifications

    Vaquum
    ‘Praxis’

    Role
    Turns Nexus’s decisions into venue orders, durable execution state and auditable outcomes
    Spine
    Append-only SQLite, schema 4, SHA-256 chain over a length-framed preimage, checked at every start
    Events
    42 durable types
    Execution
    7 modes; single shot by default
    Checks
    Intake, risk, price, capital, health and platform limits, before a command reaches execution
    Accounts
    One writer each, with its own credentials and a queue of up to 1,000 commands
    Ledger
    Double-entry per account, FIFO or average cost, BTC and USDT
    Venues
    Binance Spot testnet · Binsim on observed depth · Binance mainnet when armed
    Replay
    The real launcher, Nexus and execution over recorded bars, against a simulated venue
    Tests
    2,957 test functions
    Status
    Paper and testnet; not yet a live-trading-hardened production deployment
    Source
    github.com/Vaquum/Praxis · d036870 · 2026-10-25 · MIT

    Read the source ↗Return to the system

    Every claim about Praxis on this page is its source and documents at d036870, 2026-10-25. The spine rows were written by Praxis’s own Event Spine for one example paper order; the verdicts are its own verify_chain’s. The book is a real observation from Vaquum’s book collector, kept in Praxis’s test fixtures. As of 2026-10-29.

    05 · The market state cube

    Bitcoin research and trading · open source

    Every BTCUSDT trade since 2021, counted into cells of time and price, and the instrument that reads them.

    Read the source ↗Return to the system

    Scroll · Into the cube ↓

    The cube counts every Binance BTCUSDT spot trade since 2021-01-01 into cells of 56.25 seconds by 125 USDT. Nothing is sampled and nothing is smoothed.

    Repository
    github.com/Vaquum/Cube
    License
    MIT

    1. The record

      Every Binance BTCUSDT spot trade since 2021-01-01: 6,173,120,060 trades in 785 columns of 64 hours by 112 rows of 1,000 USDT.

    2. Every cut doubles

      Time and price are cut independently, and each cut halves a column or a row. Seven cuts read the last 30 days at 2 hours by 250 USDT.

    3. The same trades at every level

      A cell is the sum of the cells inside it, so no cut adds or loses a trade. The last seven days, at 1 hour by 250 USDT.

    4. One day

      The 24 hours to 2026-09-24 12:00 UTC, at 15 minutes by 125 USDT: 3,475,972 trades.

    5. One cell

      The busiest cell of that day: 38,598 trades from 14:15 to 14:30 UTC, between 84,125 and 84,250 USDT.

    6. The base cell

      Four more cuts reach 56.25 seconds by 125 USDT, the cell every level is made of. Seven of these sixteen held no trade, so they are outlined, never drawn as zero.

    7. 56.25 seconds × 125 USDT

      The busiest of them held 8,446 trades. The record is 3,214,083 base columns long.

    The instrument

    Three views.
    One count.

    The instrument that reads the cube is built from three views of the same cells. Here they are, on the same 24 hours.

    1. ElevationFrom the front, the cells: each one as dark as the USDT traded in it.
    2. End view and planSummed along time, the cells give volume by price. Summed along price, they give volume by time.
    3. The screenUnfold the three views and you have Cube: the chart, its profile beside it, and the Columns pane beneath.

    Cells

    In view

    2026-09-23 12:00 → 09-24 12:00 UTC · 82,750–86,000 USDT

    Volume
    1,918,601,006 USDT
    Trades
    3,475,972
    Taker-bought
    45.5 %
    POC
    84,312.5
    70 % value area
    83,625–84,750

    Point at a cell, or focus the chart and use the arrow keys.

    Verify

    Two projections.
    One record.

    The cube and Origo’s 4-hour klines are built separately from the same trades. In all 784 whole 64-hour columns their trade counts are equal, and their USDT agree within the klines’ own rounding.

    Each dot is one 64-hour column, 2021–2026: the cube’s USDT against the 16 klines inside it, vaquum/binance_btcusdt_4h_klines revision 45183e4.The dashed line is the klines’ rounding.
    Columns compared
    784
    Trade counts equal
    784 of 784
    Largest difference
    0.393 USDT
    The klines’ rounding
    16 × 0.05 USDT
    1. An unavailable value is never a zero.Fourteen typed results, from finite to invalid input. A measure without a value says why, and nothing is drawn as a number it does not have.
    2. Unfinished looks unfinished.An open column carries a cap, a coarser cell a corner tick, and the provisional minutes a dashed edge where the archived days end.
    3. Replay never looks ahead.Its edge governs every measurement, history, reference and comparison, and nothing beyond it is read.
    4. A zero is a measurement.Delta is 2 × taker-buy USDT − USDT. A cell whose buys equal its sells holds a zero; a cell without trades holds no delta at all.
    5. Motion moves structure, never values.One spring for Cube and for this page: stiffness 180, damping 20, mass 1.

    For people and agents

    One document.
    Two readers.

    An investigation is one document, cube-analysis@1: the view, its frozen evidence, the selection, the comparisons, the drawings, and where every number came from.

    A person opens it in Cube. An agent reads and extends it through nine MCP tools, and every import is validated before anything changes.

    • cube_capabilities
    • cube_inspect
    • cube_query
    • cube_compare
    • cube_configure
    • cube_replay
    • cube_annotate
    • cube_share
    • cube_refresh

    Specifications

    Vaquum
    ‘Cube’

    Market
    Binance BTCUSDT spot, from 2021-01-01 00:00 UTC
    Base cell
    56.25 s × 125 USDT
    Levels
    21 in time by 10 in price: 210 ways to read the same trades
    Counters
    USDT, taker-buy USDT, trades, taker buys
    Cells
    Volume, Trades, Trade size, Taker flow, Taker trades, Delta, Cascade, Path, Dwell, Geometry, Candles
    Typed results
    14, and an unavailable value is never a zero
    Reference
    60 searchable topics
    Agents
    cube-analysis@1 · 9 MCP tools · loopback HTTP
    Build
    No runtime dependencies beyond vendored D3, assembled deterministically
    Source
    github.com/Vaquum/Cube · f7b786e · 2026-10-28 · MIT

    Read the source ↗Return to the system

    Every figure on this page is computed from Cube’s recorded snapshot of Binance BTCUSDT spot, cutoff 2026-09-24 12:02:48.750 UTC: the record in 64-hour by 1,000 USDT cells, the last 30 days at 2 hours by 250 USDT, the last 7 days at 1 hour by 250 USDT, the 24 hours to 12:00 at 15 minutes by 125 USDT, and that day’s busiest cell in its 16 base cells. Coarser levels are exact sums of finer ones; each level is read on its own scale. The klines are Origo’s, vaquum/binance_btcusdt_4h_klines revision 45183e4. Claims about Cube are its documents at f7b786e. Cube’s backend lives in Origo. As of 2026-10-29.

    06 · The pattern composer

    Bitcoin research and trading · open source

    Draw bars, find the closest windows in BTCUSDT history, and read what they became.

    Read the source ↗Return to the system

    Scroll · One drawing through Composer ↓

    Patterns are composed in Filang’s g1 language and matched against 15-minute to 4-hour BTCUSDT bars, compared exactly in integer cents. No estimate is shown for fewer than 30 supporting windows.

    Repository
    github.com/Vaquum/Composer
    License
    MIT

    1. Two bars

      Composer opens on a drawing of two bars: a rise, then a fall whose body covers it, which it names a bearish engulfing. Any end can be dragged, and bars added up to twenty.

    2. Chained

      Each drawn bar opens exactly where the one before it closed, as in a market that never shuts. Recorded BTCUSDT bars do so 46.6 % of the time, to the cent, and 37.6 % open one cent away.

    3. Order, not size

      Composer reads a drawing as the order of its eight ends, equal ends sharing a rank. In Filang’s g1 this one is g1:o:1,3,4,5,u;0,2,4,6,d, one of 7,452 two-bar patterns, of which 1,573 have occurred.

    4. Every window

      It searches every two consecutive bars of BTCUSDT from 1 January 2020, at 15 and 30 minutes and at 1, 2 and 4 hours: 463,536 windows, none across a missing bar.

    5. 1,741 twins

      1,741 windows have the drawing’s exact order and colours, compared in integer cents, from 854 at 15 minutes to 79 at 4 hours. With 30 or more twins, Composer reads its answers from them.

    6. What came next

      Each twin’s next six bars, in the twin’s own scale: the low of its two bars is 0 and their high 1. For the 1,739 with all six, the middle half of the sixth close lies between −0.44 and 1.19.

    7. Within limits

      After six bars, 29.8 % had closed above the pattern’s high, 33.7 % inside its range and 36.5 % below its low. Every rate carries a Wilson 95 % interval, and none is shown for fewer than 30 windows.

    One comparison away

    Flip one
    comparison.

    Twenty-eight comparisons between its ends fix a two-bar pattern, and one changed makes another, with a history of its own. These are the six neighbours of the opening drawing that BTCUSDT holds most often.

    1. 00The opening drawingA rise, then a fall whose body covers it.1,741 windows · the next bar rose after 54.3 %
    2. 01Bar 2’s close below bar 1’s lowThe fall closes beneath all of the rise.3,797 windows · the next bar rose after 54.4 %
    3. 02Bar 2’s high below bar 1’s highThe fall stays under the rise’s high.3,151 windows · the next bar rose after 52.3 %
    4. 03Bar 2’s low above bar 1’s lowThe fall stays above the rise’s low.2,893 windows · the next bar rose after 50.6 %
    5. 04Bar 2’s close above bar 1’s openThe fall’s body no longer covers the rise’s body.1,373 windows · the next bar rose after 51.3 %
    6. 05Bar 2’s open above bar 1’s closeThe fall opens above the rise’s close: the joint is no tie.1,013 windows · the next bar rose after 52.4 %
    7. 06Bar 2’s open below bar 1’s closeThe fall opens below the rise’s close.947 windows · the next bar rose after 50.5 %

    Each group is Composer’s own: its matcher took every two-bar window on the five timeframes with the drawing’s colours and exactly one comparison between bar ends different, and grouped them by that comparison. The bars drawn for each group are its closest-looking window, scaled to the drawing as Composer’s Try it places them, with their prices as recorded, so a joint can miss by a cent. Rates are the share of windows whose next bar closed above their last close, with Wilson 95 % intervals; they describe what happened, not what will.

    Compose

    Draw it.
    Find its twins.

    Drag any end of a bar, add bars, flip the first. On every change your browser searches every window again, ranked as Composer ranks them, in the same bars Composer reads.

    The search needs the script on this page.

    The bars are Composer’s own payload: its bars.py read vaquum’s five BTCUSDT kline files at the revisions pinned for this page, refused any price finer than a cent, and wrote them as CBAR1, 3.5 MB in five files. Your browser checks each file’s SHA-256, decodes it, and searches it in a background worker; nothing is fetched from outside this page. As Composer does, it keeps the 480 closest windows, shows the 6 closest that do not overlap in time, and reads its answers from the exact twins, or from the 480 closest when there are fewer than 30 twins.

    Specifications

    Vaquum
    ‘Composer’

    Role
    A workbench for BTCUSDT bar patterns: draw bars, find their closest windows in history, and read what followed
    Drawing
    2 to 20 chained bars; drag shadows, bodies and closes, which snap onto exact ties; 400 steps of undo
    Identity
    Filang g1, with colours (g1:o) or as shape only (g1:u); 14 classical names, and a sentence for each pair of bars
    Matching
    Every window at 15m, 30m, 1h, 2h and 4h, in integer cents: exact twins, and the closest by colours, shape and sizes, with a charge for each flipped comparison
    Holds
    Pins on relations and colours, a skeleton of swings, a stretch of up to 4 skipped bars, and next-bar filters by direction, basis points or ATR
    What came next
    The next bar’s close; the six bars after as paths, branches, and states above, inside or below the range; a fan of 10, 25, 50, 75 and 90 % quantiles from up to 20,000 continuations
    Readings
    Volume, trades and trade size against the 11 bars before; maker share; range and body in ATR14; place in the prior UTC day’s range
    Statistics
    Wilson 95 % intervals for rates, t for means, and nothing for fewer than 30 windows
    Data
    Vaquum’s BTCUSDT kline datasets on HuggingFace at 15m, 30m, 1h, 2h and 4h, from 2020-01-01, checked by SHA-256 and row count; missing bars stay missing
    Serving
    Python’s standard HTTP server on 127.0.0.1:8488, reading the files with PyArrow; a checksummed snapshot refreshed hourly; behind the Vaquum portal login
    Checks
    21 Python tests and 23 check files, among them a brute force of the ranking and an independent recomputation of the panes
    Not here
    Live prices, orders, accounts, saved drawings and share links
    Source
    github.com/Vaquum/Composer · 133e301 · 2026-10-17 · MIT · Python 3.12 and a browser

    Read the source ↗Return to the system

    Every claim about Composer on this page is its source at 133e301, 2026-10-17. The bars are vaquum’s BTCUSDT kline files at the revisions of 2026-10-30, from 2020-01-01 through 2026-10-29, encoded by Composer’s own bars.py. The drawings, counts, rates, neighbours and words were produced by Composer’s own matcher.js and page functions, and your browser computes them again. The count of 7,452 two-bar patterns is Composer’s, and this page’s record enumerates them to check it. As of 2026-10-30.

    07 · The sweep monitor

    Bitcoin research and trading · open source

    Shows how each parameter of a sweep moves the outcome, with the uncertainty of every number.

    Read the source ↗Return to the system

    Scroll · One sweep through Grid ↓

    Grid follows a running sweep’s results file and log. A Limen experiment is read live while limen run writes it, and nothing is inferred.

    Repository
    github.com/Vaquum/Grid
    License
    MIT

    1. A sweep

      Grid reads a sweep while it runs. This one is in Grid’s own tests: Limen 5.14.0 drawing 37 parameters of a LightGBM experiment at random, 10,000 rounds planned, read at the first 200. Each round is tested on hourly BTCUSDT from March to September 2026.

    2. One needle

      Every view measures one outcome, the needle. For a Limen run with no declared objective it is net PnL per bar: here −0.025 basis points, with a 95 % interval from −0.037 to −0.012, over the 200 rounds.

    3. Rows arrive

      As rows arrive, each parameter gets a card: the needle at each of its values, every card on one scale. A value is drawn hollow, with no number, until it has 30 rows; at row 60, 8 of the 123 values have one.

    4. A leader

      For all but two of the rows from 52 to 128, the strongest parameter is min_child_weight. But 37 parameters are tested at once, and after Benjamini–Hochberg its q never falls below 0.078: Grid never calls it detectable.

    5. Two move the needle

      At row 129 use_calibration takes the lead with q under 0.05, and at row 140 class_weight follows. At 200 rows those two move the needle; min_child_weight is sixth, at q 0.35.

    6. Where it acts

      Calibrated models averaged +0.003 basis points a bar and uncalibrated ones −0.055, an ω² of 10.3 %. Read on entries, the same parameter leads: 84 of the 105 calibrated rounds entered no trade at all, against 29 of the 95 others.

    7. Within noise

      At p under 0.05, four parameters would pass; corrected for 37 tests, two do. The other 35 have no detectable effect: their spread is within noise, and their intervals bound how far each could move the needle.

    The needle

    Change the
    question.

    The same 200 rounds, measured another way, answer differently. Grid tests every parameter again for whichever needle is chosen, and corrects the board as a whole.

    1. 00Net PnL per baruse_calibration and class_weight.2 of 37 move it · use_calibration, ω² 10.3 %
    2. 01Entriesuse_calibration, class_weight and lookahead_hours: calibrated models enter less.3 of 37 · use_calibration, ω² 21.2 %
    3. 02AUClookahead_hours alone: how far ahead the target looks.1 of 37 · ω² 30.4 %
    4. 03Precisionuse_calibration and max_duration_hours.2 of 37 · use_calibration, ω² 10.7 %
    5. 04Mean losing barnotional_rate alone: the size of the position.1 of 37 · ω² 48.4 %, over the 80 rounds that have one
    6. 05Drawdown p5use_calibration, class_weight and notional_rate.3 of 37 · use_calibration, ω² 17.1 %
    7. 06Seconds per rowmax_duration_hours and feature_groups: what the features cost to compute.2 of 37 · max_duration_hours, ω² 31.0 %

    Each needle is one of the run’s own columns, as Grid names it and reads its direction, or Grid’s own count of entries. Every board here is Grid’s engine on the needle over all 200 rounds: 37 one-way tests, q from Benjamini–Hochberg, detectable under 0.05, strength as ω². A parameter that moves no needle is not called inert; its intervals bound how much it could.

    Pocket

    Stack values.
    Read the pocket.

    A pocket holds the rounds whose values you choose: any of a parameter’s chosen values, every chosen parameter at once. Grid reads the needle inside it and ranks the next value by the cautious end of its interval.

    The pocket needs the script on this page.

    The rounds are Grid’s own test fixture at 01ac611: the first 200 rows that a real Limen 5.14.0 run wrote, with its manifest, as Grid’s own pack reads them. Because the sampler drew every parameter independently and uniformly, a pocket’s mean estimates what a new sweep drawn inside it would give; the halves compare its rounds in the first and second half of their arrival. Nothing is fetched from outside this page.

    Specifications

    Vaquum
    ‘Grid’

    Role
    A monitor for parameter sweeps: it follows a sweep’s results and log while they are written, and shows how each parameter moves the outcome, with the uncertainty of every number
    Reads
    JSON lines and Limen result directories, live or recorded, local or over SSH; several shards of one manifest read as one run
    Views
    Experiment, Board, Pocket, Pairs, Features, Trials, Gates, Run and Cohort, each shareable by its address and replayable to any row
    Statistics
    95 % intervals, t for means and Wilson for rates; nothing for fewer than 30 rows; ω² with the F test, or the G-test for a rate; Benjamini–Hochberg q
    Interactions
    Beyond an additive fit, up to six parameters at once; moderators across the board; sampler dependence by Cramér’s V
    Halves
    Each test window’s two halves read as windows of their own; an effect counts only when it shows in both
    Experiments
    Manifests checked by limen validate as they are typed, run in shards with Limen’s own stop and resume, recorded as Sweep or Inspect
    Cohorts
    Chosen on the first half of the test window, judged on the second, and made a predictor in the layout Furnace reads
    Agents
    18 operations over a JSON API, a command line and MCP, running the page’s own engine in Node
    Retention
    Content-addressed exact evidence, sealed runs compacted and reconstructed before anything is pruned
    Serving
    Python’s standard library on 127.0.0.1:8490, behind the Vaquum portal login, inside a 199,000,000,000-byte storage boundary
    Checks
    272 Python, 167 JavaScript and 88 browser tests; the statistics checked against scipy on a sweep with planted effects
    Not here
    Limen itself, which Grid runs through its command line; the portal login; Furnace, which reads the predictors
    Source
    github.com/Vaquum/Grid · 01ac611 · 2026-10-19 · MIT · Python 3.11 and later, Node 18 and later

    Read the source ↗Return to the system

    Every claim about Grid on this page is its source at 01ac611, 2026-10-19. The sweep is its test fixture tests/fixtures/limen_run_200: the first 200 rounds of lightgbm_binary_full, a 10,000-round random search Limen 5.14.0 began on 2026-10-09, trained on hourly BTCUSDT from 2024-01-01 and tested from 2026-03-01 to 2026-09-30. Grid’s own pack read it and Grid’s own engine produced every board, edge and pocket; your browser computes them again. As of 2026-10-30.

    Open source

    Don’t trust.
    Verify.

    Every configuration testable. Every state traceable. The strategy you deploy is the strategy you tested.

    Read the source on GitHub ↗

    • OrigoMIT
    • LimenMIT
    • NexusMIT
    • PraxisMIT
    • CubeMIT
    • ComposerMIT
    • GridMIT

    The record is Cube’s recorded snapshot of Binance BTCUSDT spot, from 2021-01-01 00:00 to 2026-09-24 12:02:48.750 UTC, in 785 columns of 64 hours by 112 rows of 1,000 USDT. Column prices and trade counts are Origo’s 4-hour klines (vaquum/binance_btcusdt_4h_klines, revision 45183e4, SHA-256 e0b5256…), grouped 16 to a column. Motion uses one spring — stiffness 180, damping 20, mass 1 — and moves structure, never a value. As of 2026-10-29.