Nexus Paper Trading and Sandbox vs Live Broker: What Each Mode Means

The Nexus mode map in plain language

• Backtest or simulation: Nexus replays a strategy against historical inputs and produces simulated trades and metrics. It does not submit those trades to a broker.
• Preview: Nexus calculates or displays a proposed structure, risk estimate, margin view, or execution plan without treating that view alone as permission to place an order.
• Index F&O scalper Paper Mode: Nexus autopilot runs the full live decision pipeline for the scalper path but simulates the fill at the live price instead of contacting the broker. No order reaches the broker while Paper Mode is on.
• Stock/F&O live operation: a connected supported broker can receive user-authorized order requests after the applicable data, margin, exposure, duplicate, strategy, and account checks pass. This is the only route for manual, semi-auto, and non-scalper autopilot deployment — none of them have a paper fallback.
• Delta Demo/Testnet: the separate crypto workflow routes to Delta Exchange’s demo/testnet environment when that environment and matching credentials are selected.
• Delta Live India: the crypto workflow uses the live India environment and requires explicit live arming and confirmation in addition to its risk checks.

Indian stock and F&O deployment has no general paper fallback

The current broker settings flow for supported Indian stock and F&O brokers connects live credentials and saves the connection as non-sandbox. Simulator and legacy demo tokens are rejected. Manual orders, signal deployment, semi-auto deployment, and autopilot all require a valid broker session before they can use the execution path.

The one exception is the index F&O scalper autopilot path, which can be armed with Paper Mode instead of live execution. Paper Mode still requires a connected broker session and still runs the full live decision pipeline (research, gates, sizing) — it only substitutes a simulated fill at the live price for the final broker order. It does not extend to manual orders, semi-auto deployment, structure/basket deploys, or non-scalper autopilot; those routes still reach the broker whenever their checks pass.

If a broker rejects an order, Nexus does not silently create a simulated open trade to make the workflow look successful. The cockpit surfaces the broker validation or status message, and the rejected deployment is not converted into paper tracking. This prevents a local imaginary position from drifting away from the actual account.

Nexus contains broker-specific technical support for fields and endpoints that can distinguish sandbox traffic, but that does not mean the public stock/F&O connection workflow offers a complete sandbox account. The user-facing connection form currently selects live operation, and broker adapters differ in what they can quote, place, stream, or reconcile.

A backtest is research, not a rehearsal with guaranteed live results

The F&O backtest screen explicitly labels its output as a simulation. It reports simulated return, simulated entries, and a simulated execution ledger derived from the selected historical assumptions. Re-running that analysis changes research output; it does not place an order.

Backtests can help compare rules, inspect drawdown, and expose how a strategy behaved under the available data. They cannot reproduce every live spread, queue position, partial fill, outage, broker rule, margin change, or market impact. Historical simulation also cannot establish the probability of a future profit.

A preview is narrower still. A candidate, proposed multi-leg structure, estimated loss, or margin calculation can be useful before execution, but it is not broker acceptance. The order lifecycle begins only when an authorized execution request passes the live gates and reaches the broker adapter.

• Use simulated return to evaluate assumptions, not to set an expected account return.
• Read the simulated ledger for entry and exit logic, not as evidence of exchange fills.
• Recheck current quotes, spreads, expiry, lot size, available margin, and risk controls before any live deployment.
• Expect the live result to differ because execution conditions and broker responses exist outside the historical replay.

Nexus Paper Mode simulates fills for the index F&O scalper autopilot path

The cockpit Paper Mode toggle starts off for each session and is not restored as a permanent preference. When enabled and the loop is armed for the index F&O scalper path, every entry runs through the same live gates (safety checks, duplicate protection, exposure limits, sizing) that a real deploy would, but the resulting fill is simulated at the live market price instead of being sent to the broker.

A simulated position is then tracked with the same stop-loss, take-profit, and trailing logic as a real one, marked to live prices, and closed locally when its exit condition is hit — again, with no broker order placed. Paper trades are tagged in the ledger and excluded from real-money realized profit, daily loss-limit, and daily profit-target calculations, so they cannot trigger a real-money safety lock or be mistaken for real performance.

Paper Mode is scoped to the index F&O scalper autopilot path only. Manual orders, semi-auto deployment, structure/basket deploys, and non-scalper autopilot are unaffected by the toggle and still route to the live broker whenever their checks pass.

How to move from simulation to a controlled first live run

1. Finish the research pass: Run the relevant backtest, inspect its assumptions and drawdown, and identify what the simulation does not model. Do not convert a strong historical result into a profit expectation.
2. Choose the execution boundary: For Indian stocks and F&O, assume Deploy and Ignite can reach the live broker. For Delta crypto, verify whether the selected environment says Demo/Testnet or Live India.
3. Connect and verify the account: Use Settings to authenticate the intended supported broker. Confirm the broker name, session state, account identity, balance or margin view, and any required network policy before proceeding.
4. Read the cockpit readiness state: Check market-session status, feed freshness, selected symbol, current price, broker health, risk controls, deploy-block reasons, and whether another position or loop is already active.
5. Select the smallest appropriate route: For the index F&O scalper autopilot path, consider arming with Paper Mode first to watch simulated entries and exits before risking capital. For every other route, keep the capital allocation and strategy scope conservative since no paper fallback exists there.
6. Authorize one workflow deliberately: Choose manual, semi-auto, or autopilot execution with the understanding that passing checks can produce a real order. Avoid repeated clicks while a broker acknowledgement is pending.
7. Verify broker acknowledgement: Confirm the order ID, status, quantity, product, price, and fill in Nexus, then compare the broker order book and positions. A submitted request is not the same as a completed fill.
8. Monitor the complete lifecycle: Watch protective orders, open positions, exits, alerts, and reconciliation. After closure, compare the realized result with the broker record and investigate any suspect or imported ledger classification.

What happens when live state and the cockpit disagree

A broker can reject an order for session, instrument, quantity, price, margin, exchange, network-policy, or account reasons even after Nexus has prepared a valid plan. The safe response is to read the returned reason and inspect the broker account, not to submit the same intent repeatedly.

Nexus reconciles its ledger with broker positions and order updates. An unmatched broker position can appear as imported activity for visibility, while a Nexus-originated position can be recovered when the available broker metadata supports that classification. Imported broker trades are not automatically treated as Nexus-owned positions.

Network interruptions create uncertainty in both directions: the web app may miss a broker update, and a timed-out request can require careful verification before any retry. Never infer “no order” solely from a slow screen. Check the broker order book and positions first.

• Rejected in the cockpit: read the broker message and correct the cause before another attempt.
• Submitted but not filled: monitor the pending order; do not count it as an open fill.
• Visible at the broker but missing locally: refresh and allow reconciliation, while managing urgent risk from the broker account.
• Visible locally but absent at the broker: treat the local record as unconfirmed until broker state resolves it.
• Exit requested: confirm the exit order and the resulting flat position at the broker.

Delta Demo/Testnet is a separate crypto environment

Nexus isolates the Delta Exchange crypto connection from Indian stock and F&O brokers. The crypto settings distinguish Demo/Testnet from Live India, use different API hosts, and require credentials that belong to the selected environment.

Demo/Testnet is not the same as Nexus generating a local paper fill. The crypto execution route submits through the connected Delta demo/testnet environment and records the resulting test-environment lifecycle. Availability, symbols, prices, balances, and behavior are therefore governed by that environment.

Live India uses a distinct route. In addition to the crypto risk governor, live execution requires an explicit, short-lived server-side arm for the chosen symbol and mode plus live confirmation. A demo result does not guarantee that a live order will be accepted or filled the same way.

Limitations and safety rules for every mode

Nexus is software, not a broker or custodian. Funds and securities remain with the connected broker, and users authorize trading activity through the selected workflow. The broker and exchange determine final order acceptance and fills.

Trading and derivatives involve substantial risk. Use simulation to understand rules, controlled live sizing to limit the first operational step, and broker verification to establish what actually happened.

• Simulation quality is limited by its data, costs, assumptions, and modeled execution.
• A sandbox or testnet can differ from production in liquidity, supported endpoints, market data, margin behavior, and order-state timing.
• Restricted live sizing reduces exposure but does not eliminate loss, slippage, rejection, gap, outage, or partial-fill risk.
• A healthy connection does not prove that a specific order filled; verify order and position state.
• A broker rejection is not permission to weaken controls or retry repeatedly.
• Signals, model scores, backtests, and demo outcomes are not guarantees of execution or return.

Frequently asked questions