Trading and automation
Follow execution state, not just request acceptance.
Each wallet has its own worker process, intent journal, protections, and copy settings. Full-wallet sizing follows equity and available-funds constraints; concurrent copied entries share the budget.
Copying currently follows filled leader positions. It does not copy pending leader orders. A copied fill can differ in time and price from its leader.
Orders and exits
A completed REST command means the worker returned an answer. It does not mean the venue filled a trade. Check pending orders, account snapshots, and intent history for actual execution.
Stop-loss and profit-protection checks run in the worker. Queueing, gaps, liquidity, liquidations, or failed cancellations can produce a different realized result from the current PnL estimate.
Retries
Every trading REST request requires an Idempotency-Key. Save that key with your strategy decision and reuse it with exactly the same payload after a transport failure. An unknown command is not safe to replay with a new key: inspect the worker's journal and exchange state first.
The database command journal and protocol intent journal are distinct. The former tracks request handling; the latter tracks trading outcomes. Unknown API command records are not automatically retried.
Worker lifecycle
Stopping or restarting a worker interrupts automation and clears the in-memory signer. During a platform restart, automation pauses briefly and then resumes for wallets with unattended signing. There is no automatic key recovery.