Live Trading

TL;DR

Live trading adds two boundaries to a strategy: an exchange account and a live executor. Credentials live in $AURUM_HOME/secrets/, never in source code. Always validate with paper trading first, use an exchange sandbox where available, and grant only the permissions required by the application.

Why this matters

The gap between paper trading and live trading is not just about real money. It is about real infrastructure: network latency, exchange rate limits, credential rotation, partial fills, venue-specific rejection rules, and the operational reality that a running strategy cannot be debugged with a breakpoint.

This page covers the mechanics of connecting to a live venue. The operational practices — pre-flight checklists, release controls, rollback procedures — are equally important. A correct strategy deployed incorrectly loses money just as fast as an incorrect strategy.

Declare an account

#include <aurum/venue/okx.hpp>

auto account = venue::okx::Account("trading", TRADE);

bind<Datafeed>(venue::okx::Bar("BTCUSDT", "1m"));
auto executor =
    bind<device::BoundExecutor>(venue::okx::Executor(account));

The account name is also the default credential reference.

Store credentials

Create $AURUM_HOME/secrets/okx-live.toml with owner-only permissions:

[[accounts]]
venue = "okx"
name = "trading"
permissions = "READ,TRADE"
api_key = "..."
api_secret = "..."
passphrase = "..."

mkdir -p "$AURUM_HOME/secrets"
chmod 700 "$AURUM_HOME/secrets"
chmod 600 "$AURUM_HOME/secrets/okx-live.toml"
aurum run . --auth okx-live

Alternatively, pass an explicit absolute file URI:

aurum run . --auth file:///secure/path/okx-live.toml

Warning

Never place credentials in the strategy source, deployment archive, or shell history. aurum push does not include local secrets. A remote Forge run resolves the credential reference in the target environment — the secret must already exist on the Forge host. If you commit a credential file to version control, rotate the key immediately.

Pre-flight checklist

Before a production push, verify every item on this list:

[ ] Increment the project VERSION in CMakeLists.txt
[ ] Verify the intended account name and permission set (READ, TRADE,
    DEPOSIT, WITHDRAW)
[ ] Handle all terminal receipt outcomes: accepted, rejected,
    partial_filled, filled, canceled, timeout, err
[ ] Define position and notional limits in strategy code
[ ] Test with paper account using the same market data source
[ ] Test with exchange sandbox if the venue provides one
[ ] Confirm logs and runtime health are visible in Terminal
[ ] Keep a known-good version available for rollback
[ ] Verify credentials exist on the Forge target with correct permissions
[ ] Confirm the venue account has sufficient balance for expected order sizes

Tip

Run through this checklist out loud with a teammate before the first production push. The act of verbalizing each item catches omissions that reading silently misses. This is standard practice in trading operations and costs five minutes.

Release controls

These are not suggestions. They are the minimum operational baseline for a production trading strategy:

  • Version before push. A published version is immutable. If you discover a bug in production, you need a different version to roll forward or a known-good version to roll back to.

  • Start small. Use minimum order sizes for the first live run. Increase gradually while monitoring fills and positions.

  • Monitor in real time. Keep Terminal open on the project Summary and Inspect views during the first hour of live trading. Do not deploy and walk away.

  • Have a rollback plan. Know the exact aurum stop and aurum run commands to roll back to the previous version. Test the rollback procedure during paper trading, not during a live incident.

  • Set alerts. Configure external monitoring on the Forge /health and /doctor endpoints. A strategy that silently stops is worse than one that loudly fails.

Common mistakes

Including credentials in the deployment archive.

aurum push packages the project source directory. If okx-live.toml is in the project tree, it will be included in the package. Use $AURUM_HOME/secrets/ for credential files.

Using the wrong permission set.

TRADE permission is required for order submission. PUBLIC only allows market data access. If your orders are rejected with an authorization error, check the permission set in your account declaration.

Not handling partial fills.

A market order for 1.0 BTC may fill as 0.3 + 0.7 across multiple trades. Your strategy must handle partial_filled as a distinct outcome and track cumulative fill quantity.

Assuming order acceptance means execution.

accepted means the venue acknowledged the order; it does not mean the order filled. Orders can rest on the book and fill seconds or minutes later, or be cancelled without ever filling.

Deploying without a rollback version.

If your only published version has a bug, you cannot roll back — you must fix forward. Always keep at least one known-good version registered on Forge.

Next steps