The API is a durable contract
A trading system should depend on Novrinex concepts rather than the details of any underlying execution venue. Markets, portfolios, orders, positions, fills, capabilities, and errors retain stable Novrinex identifiers even when infrastructure changes.
Read the capability document for a market before constructing an order. It describes supported order types, quantity increments, price increments, leverage limits, schedules, and settlement behavior. Store the capability revision with the decision that produced an order so a later audit can reconstruct what the system knew.
Choose the right automation model
A bot follows deterministic rules. An agent may interpret broader context and propose actions. An execution system coordinates signals, risk, orders, state recovery, and operations. These can share the same API, but they should not share unrestricted authority.
For higher-judgment agents, separate proposal from execution. Let the agent produce a structured order proposal, apply deterministic policy checks, and require human approval when a proposal crosses a configured threshold.
- Use a bot for narrow, repeatable logic with measurable inputs.
- Use an agent for research or proposals, not unconstrained signing authority.
- Use a dedicated service account and policy for each production strategy.
- Keep private wallet keys outside strategy code and source control.
Begin with the sandbox
The sandbox is designed for repeatable testing. Seeded market data, controllable time, deterministic fills, disconnects, stale prices, partial fills, and rejection scenarios let a strategy exercise failure paths before it reaches a shared environment.
A useful test suite covers more than profitable examples. It should prove how the system behaves when an order is rejected, an acknowledgement is delayed, a stream disconnects, a webhook is delivered twice, a price becomes stale, or an earlier request has an unknown outcome.
Move to testnet deliberately
Testnet introduces real network timing, authentication, persistent state, and asynchronous events without authorizing live funds. Create a test service account, attach a restrictive policy, issue a narrowly scoped test key, and begin with read-only calls.
Before sending orders, retrieve the portfolio and market capability revision, preview the order, and establish a dead-man lease. Every write request needs a unique idempotency key that is reused only when retrying the exact same command.
- Record request IDs, client order IDs, and Novrinex order IDs.
- Treat timeouts as unknown until state has been reconciled.
- Resume event streams from the last durable sequence.
- Verify webhook signatures against the raw request body.
Make risk policy independent of strategy logic
Strategy code answers what it wants to do. Policy answers what it is allowed to do. Keeping those decisions separate prevents a software defect or unexpected model output from silently widening authority.
A practical policy restricts markets, order types, maximum notional, reduce-only behavior, approval thresholds, and the required dead-man timeout. Conservative limits should be enforced by the platform as well as inside the client.
Reconcile state instead of assuming success
An HTTP acknowledgement is not the final source of truth for an economic action. The connection can fail after the platform accepted a command but before the client received the response. Retrying with the same idempotency key safely retrieves or continues the original command.
Use ordered events for fast local state, then compare open orders, positions, fills, and balances with periodic REST snapshots. If the event sequence contains a gap, pause new risk, recover from the last sequence, and rebuild the local view before continuing.
Operate the system, not only the strategy
Production readiness includes credential rotation, alert routing, latency and error monitoring, an emergency stop, incident ownership, and a documented recovery process. Signed webhooks can notify downstream services, but consumers must tolerate retries and duplicate delivery.
Keep logs useful without recording secrets. Store identifiers, timing, policy decisions, and normalized error codes. Never log full API keys, webhook secrets, wallet signatures, or sensitive account payloads.
- Alert when the event stream is stale or sequence recovery fails.
- Alert on repeated policy rejections and unknown command outcomes.
- Revoke a suspected credential before investigating its strategy.
- Test cancel-only and global-disable procedures before live access.
Live trading is a separate approval boundary
Passing sandbox and testnet tests does not automatically make a system ready for live funds. Live automation requires an approved account, jurisdiction and provider eligibility, an active mandatory policy, conservative limits, a dead-man switch, and Novrinex operational approval.
Begin with a small market allowlist and low notional. Expand only after execution state reconciles reliably, emergency controls meet their targets, and observed behavior remains inside the documented policy.
Automation increases the cost of ambiguous state
A manual trader can pause when an order response looks unusual. An automated client may repeat the action and multiply the error. Production systems therefore need idempotent requests, durable client order identifiers, explicit timeouts, and reconciliation against authoritative order and position state.3
Risk limits should be enforced independently of strategy signals. Useful controls include maximum notional, maximum open orders, per-market limits, daily loss boundaries, stale-data rejection, and a kill switch that can cancel exposure without waiting for the strategy process.12
A minimum operating loop
A robust loop reads current account state, validates data freshness, computes intent, checks risk policy, submits once, records the request, and reconciles the result. It should assume that networks fail between submission and acknowledgement, leaving the outcome uncertain until the venue confirms it.3
- Use testnet and tiny deterministic cases first
- Persist every client order identifier
- Reconcile fills before placing dependent orders
- Alert on stale data and state disagreement
- Practice credential revocation and emergency cancellation