Vaquum Solution About Code Contact

Five modules, one loop.

Data ingestion, alpha research, decision validation, trade execution, and system-wide auditability form a single parametric closed loop, built for Bitcoin operators who run research and trading as one discipline.

Get started on GitHub

Five modules. Each auditable. Each replaceable.

Each module runs standalone, all five run together as a closed loop, and every module connects to an existing stack.

Origo delivers rich Binance trade data — spot and futures — through source-native tables or a normalized multi-source aligned table at 1-minute resolution.

  • Source events are preserved as the checksum-verified canonical record.
  • The same inputs produce the same outputs; backfills and projection rebuilds are first-class capabilities.
  • Raw trade ingestion is ledgered to source files, checksums, partitions, and ingest runs; every projection rebuilds from that ledgered raw layer.
  • Interfaces are schema-strict and fail loudly on missing or invalid data.
  • Multi-market data — Binance spot and futures — aligns in one table without manual joins.

Kline rollups

from origo.query.binance_spot_kline_rollups import (
    dollar_month,
    time_month,
)

# 15-minute time klines for one month
klines = time_month(
    interval_minutes=15,
    year=2026,
    month=6,
)

# 15M dollar bars for the same month
bars = dollar_month(ratio=15, year=2026, month=6)

Limen unifies parameter search across machine learning and rule-based strategies. It evolved from Talos, a hyperparameter optimization framework cited in more than 1,000 scientific papers, with zero breaking bugs in six years.

  • Experiment pipelines are manifest-driven and reproducible, with checkpointing, resumption, and retraining.
  • Search spans rules, features, targets, and hyperparameters — with any model architecture, built-in or custom.
  • Train, validation, and test workflows are leakage-safe.
  • Backtesting, confusion analytics, and parameter diagnostics are built in.
  • Decoder cohort construction pools models with pluggable selection.

Experiment loop

import limen
from limen.data import HistoricalData

historical = HistoricalData()
historical.get_spot_klines(kline_size=7200)
uel = limen.UniversalExperimentLoop(
    data=historical.data,
    sfd=limen.sfd.logreg_binary,
)
uel.run(
    experiment_name="logreg-first",
    prep_each_round=True,
)

Manifest workflow

pip install "vaquum-limen[data]"

limen init logreg-first.yaml \
    --template logreg_binary
limen validate logreg-first.yaml
limen profile logreg-first.yaml
limen run logreg-first.yaml

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.

  • A multi-stage pipeline validates intake, risk, price, capital, health, and platform limits.
  • Atomic capital reservation and order lifecycle control prevent over-deployment and race conditions.
  • Strategy-level capital budgets account for deployed capital within a shared pool.
  • Safety modes cover active, reduce-only, and halted operation.
  • Durable persistence combines write-ahead logging, snapshots, replay, and crash recovery.

Strategy hook · excerpt

from decimal import Decimal
from nexus.core.domain.enums import OrderSide
from nexus.core.domain import order_types as ot
from nexus.strategy import Action, ActionType, Strategy

class LongOnBinarySignal(Strategy):
    def on_signal(self, signal, params, context):
        preds = signal.get("_preds")
        if preds != 1 or context.positions:
            return []
        budget = context.capital_available
        return [Action(
            action_type=ActionType.ENTER,
            direction=OrderSide.BUY,
            quote_qty=budget * Decimal("0.10"),
            execution_mode=ot.ExecutionMode.SINGLE_SHOT,
            order_type=ot.OrderType.MARKET,
            deadline=60,
        )]

Praxis unifies order routing, venue communication, lifecycle management, and recovery around a single event spine. Orders persist before they are sent, so no trade is lost to a crash.

  • Supported order types include market, limit, IOC, and OCO; standalone stop, stop-limit, and take-profit arrive in Q3/26.
  • Client order identifiers are deterministic; submission is persist-before-send.
  • Fills, open orders, closed orders, and per-trade positions are durably tracked.
  • Startup replay, reconciliation, and WebSocket recovery rebuild state from the event log.
  • Walk-the-book estimation reports execution and arrival slippage per fill; slippage lands in trade outcomes from Q3/26.

Trading runtime

import aiosqlite

from praxis import Trading, TradingConfig
from praxis.infrastructure.event_spine import EventSpine

conn = await aiosqlite.connect(
    "event_spine.sqlite",
)
spine = EventSpine(conn)
await spine.ensure_schema()

trading = Trading(
    config=TradingConfig(epoch_id=1),
    event_spine=spine,
)
await trading.start()  # replay, reconcile, ready

Veritas projects the event streams of Origo, Limen, Nexus, and Praxis into one observable, attestable, queryable system-wide record without displacing source authority. The first release lands in Q3/2026.

  • Lineage will run end to end, from data partitions through signals and decisions to fills, traversable in both directions.
  • Decision-time attestation will record the exact data state, model version, features, and risk conditions each action consumed.
  • Boundary verification will detect mismatches between what one module emitted and the next consumed.
  • Profit-and-loss attribution will span data, signal quality, capital rules, and execution costs.
  • Point-in-time reconstruction will replay system-wide state across all four modules.

How the modules connect.

Unbroken edges carry the trading pipeline from data to execution; dashed edges carry each module's truth into the one place where the full picture is visible.

Fig. 01. Data flows from Origo through Limen and Nexus to Praxis, and Veritas observes every module stream.
Origo the data layer Limen the research engine Nexus the decision layer Praxis the execution system Veritas the source of truth data feed data feed signals · cohorts trade command trade outcome

Vaquum architecture · 2026-07-15

Show structure
Connections for Fig. 01.
from to relation kind
Origo Limen data feed flow
Origo Nexus data feed flow
Limen Nexus signals · cohorts flow
Nexus Praxis trade command flow
Praxis Nexus trade outcome flow
Limen Veritas observation
Nexus Veritas observation
Praxis Veritas observation
Origo Veritas observation

The strategy deployed is always the strategy tested.

When everything is a parameter, the system becomes explorable, traceable, and accountable. The Origo data configuration, the Limen manifest, the Nexus risk and capital rules, and the Praxis execution settings are one parametric surface, not separate configurations in separate places.

The loop is closed in both directions

What defines a research experiment is what defines its live deployment, and what the deployment produces feeds back into the next experiment. Every outcome maps back to the configuration that produced it, and every configuration maps forward to measured outcomes. No state exists only in production. A result that cannot be reproduced from its parameters is treated as a failure.

In practice

  • Nexus validates prediction series from any producer — Limen is one — and Praxis executes what Nexus approves; every module also runs alone.
  • Origo’s data partitions, ingest runs, and source configurations are part of the same parametric surface.
  • Veritas will observe every state transition, so divergence between expected and actual behaviour becomes immediately detectable.

Every configuration testable. Every state traceable.

Read the documentation, audit the code, run the research, and judge the results.

Get started on GitHub