ANTHERA08 / Framework and Nautilus decisionsDesign edition 0.1 · fe342eePDF
08

decision

Framework and Nautilus decisions

Leverage means adopting the coherent Nautilus kernel, then owning only the distributed service gaps it leaves open.

Question
Which dependencies buy durable leverage instead of operational overlap?
Binding decision
Nautilus is the trading runtime; every additional framework must solve a measured gap outside that kernel.
Owner input
All dependency versions and licenses are rechecked immediately before adoption in the target repo.

Scroll horizontally to inspect the full decision ledger.

Decision ledger for Framework and Nautilus decisions
CandidateDecisionOwned roleActivation evidence
Nautilus kernelAdoptCanonical trading runtimeOne revision, feature, precision, and license policy
nautilus-databentoAdoptHistorical and live Databento data clientDBN fixture and failure proof
nautilus-interactive-brokersAdoptLive execution clientPaper execution and reconciliation proof
nautilus-event-storeConditionalState-history and replayCrash and recovery proof
iiiConditionalPlugin/adapter experimentOnly for a demonstrated execution-model need
Supabase ETLRejectNo hot-path roleReopen only for separate PostgreSQL CDC
irohRejectNo browser roleReopen for measured node-to-node transfer
warpgateOperationsStaff bastion onlyNever a data-plane dependency

Nautilus is the runtime

LiveNode composes model, DataEngine, Cache, MessageBus, Trader, Portfolio, RiskEngine, and ExecutionEngine. nautilus-databento produces canonical values through the official SDK; IBKR completes live execution. Adopt the system compositionally, not as unrelated crates.

  • Direct runtime: core, model, live/node, trading when used, Databento, and IBKR.
  • Kernel closure: common, data, system, execution, portfolio, risk, analysis, network, and cryptography.
  • Conditional: event-store/live; persistence plus serialization/arrow for catalog or cold history.
  • Development or deferred: backtest, selective testkit, indicators, plugin, PyO3, Nautilus CLI, cloud, and PostgreSQL infrastructure.

EvidenceOfficial architecture, Databento, Cache, Event Sourcing, Live, and IBKR docs plus frozen crate source.

Framework roles stay narrow

iii, Restate, Supabase ETL, iroh, Warpgate, and additional brokers remain outside the kernel until a measured unsolved requirement names their role. Arrow/DataFusion and Parquet are already part of Nautilus catalog capabilities; Vortex remains a later cold-format comparator.

  • One broker role is selected only if multi-replica service fanout cannot remain simpler.
  • Zenoh requires a concrete edge topology before comparison.
  • tracing and OpenTelemetry become essential with runtime implementation.

EvidencePrompt: framework-and-tool evaluation.

Inspect dependency policymise x -- task security

Advisories, licenses, bans, and sources satisfy the current policy.