What Matters
Before an AI trading agent moves from paper trading to real money, verify what it can access, how its limits are enforced and what happens when execution becomes uncertain. Profitable simulations cannot answer those questions. These ten checks turn a promising demo into an evidence review, with any failed or untested control blocking progression.
The previous guide, 10 Safest Ways to Experiment With an AI Trading Agent You Found on YouTube or TikTok, explained how to begin cautiously. This follow-up addresses the next decision: what must you verify before enabling live order permissions?
DN Paper-to-Live Gate
Mark Pass only when you have current evidence for the exact account, software version and configuration under review. A vendor promise or a setting you have never tested remains Unknown. Run failure tests in a simulator or controlled environment; do not deliberately create losses or duplicate live orders.
This tool records your assessment. It does not connect to an exchange, receive credentials or verify your answers. Selections stay on this page and reset when it reloads. Export your record before leaving.
A dated source/version record that matches the paper-tested build.
Permission settings independently inspected for the exact account and key.
Recorded attempts to exceed each applicable limit, including rejection, delayed execution and fallback behavior.
A reconciled paper ledger, assumptions and adverse-cost examples; no profitability guarantee.
A dated stale-data and disconnection test with the observed stop behavior.
An ambiguous-result test that creates no unintended duplicate exposure.
A reconciliation record showing correct remaining quantity and exposure under partial execution.
A tested stop/cancel procedure plus a named person and plan for residual positions.
A revocation test and a secret-handling record without secret values.
A dated review record for the specific configuration. The checklist itself never authorizes live trading.
Incomplete: evidence needed
0 passed · 0 failed · 10 unknown
Resolve every failed and unknown check before the review can be completed.
Completion counts are not a safety score. Ten passes still require a separate human decision and do not establish profitability.
Show unresolved checks and required evidence
- Verify the source and exact version: A dated source/version record that matches the paper-tested build.
- Isolate credentials and remove unnecessary permissions: Permission settings independently inspected for the exact account and key.
- Enforce limits outside the agent: Recorded attempts to exceed each applicable limit, including rejection, delayed execution and fallback behavior.
- Reconcile realistic paper results after costs: A reconciled paper ledger, assumptions and adverse-cost examples; no profitability guarantee.
- Stop on stale, missing or inconsistent data: A dated stale-data and disconnection test with the observed stop behavior.
- Reconcile an unknown order result before retrying: An ambiguous-result test that creates no unintended duplicate exposure.
- Reconcile partial fills and outstanding exposure: A reconciliation record showing correct remaining quantity and exposure under partial execution.
- Test an independent stop and inspect residual positions: A tested stop/cancel procedure plus a named person and plan for residual positions.
- Protect secrets and test revocation: A revocation test and a secret-handling record without secret values.
- Document the evidence and obtain human review: A dated review record for the specific configuration. The checklist itself never authorizes live trading.
Interactive calculation requires JavaScript. The ten checks and evidence requirements remain available above; manually treat every Fail or Unknown as unresolved.
The ten checks before paper becomes live
A useful test leaves a record of the input, expected behavior, actual behavior, date and software version. Keep secrets out of that record. If you cannot reproduce a result or explain the control that produced it, leave the check unresolved.
1. Verify the source and freeze the tested version
Record the official publisher, product or repository, release version, model configuration, dependencies and execution service. For an open-source agent, identify the exact commit and installation instructions you actually used. For a hosted product, record the relevant settings and the vendor’s explanation of update behavior.
The model is only part of the system. A strategy can change when a prompt, plugin, data source, credential scope or automatic update changes. DN’s proposed test is to restart the same recorded configuration and confirm that it uses the expected markets, account and execution rules. Unexplained changes remain a blocker.
2. Isolate the account and verify every API permission
Identify the account, subaccount or portfolio that the agent can reach. Verify its actual permissions against a short list of required actions. A system that only needs to observe balances should not inherit order authority; a trading workflow usually has no reason to inherit withdrawal authority.
Coinbase Advanced Trade separates account and order reads under view, order creation and cancellation under trade, and portfolio fund movements under transfer. Kraken recommends minimum permissions and separate credentials appropriate to the application. These are product-specific controls, so inspect the settings on the exact account you intend to use. [3] [8]
Use supported network restrictions and verify their behavior without exposing credentials. Confirm that unrelated savings, transfer paths and automatic funding features are outside the intended boundary. Trade-only access can still lose money through bad trades; removing withdrawals does not make the account safe.
3. Test limits the agent cannot rewrite
Write down the permitted markets, order size, total open exposure, leverage policy, outstanding-order count and request rate. Enforce applicable limits in a trusted execution layer or venue setting the agent cannot change. A prompt saying “never exceed this amount” is a request to the model, not independent enforcement.
In a controlled test, ask for an order above the limit, an unapproved market and a burst of repeated entries. Check that the boundary rejects them. Include existing positions and unfilled orders when measuring exposure, and test concurrent requests so each one cannot independently consume the same remaining allowance.
A loss-trigger rule also needs a failure plan. Kraken documents that a stop-loss can become a market order, attract taker fees and execute beyond its trigger price. A configured stop therefore cannot be treated as a guaranteed maximum loss. [9]
4. Reconcile the paper ledger and its cost assumptions
Use individual intended orders, simulated fills, cancellations and rejected orders to rebuild the result. Include entry and exit fees, spread or execution shortfall, funding or borrowing where relevant, and operating costs. Avoid subtracting the same cost twice when a simulator already includes it.
Alpaca explicitly describes simulated fills and lists market impact, latency-related slippage and queue position among the effects its paper environment does not account for. A successful simulation consequently does not establish the price or quantity a live market would offer. [6]
Illustrative arithmetic: 100 round trips with $100 notional on each entry and exit create $20,000 of total traded notional. At an assumed combined fee and execution cost of 10 basis points per side, that costs $20. Adding $15 of software costs turns $30 of gross paper profit into a $5 net loss. These are teaching assumptions, not quoted platform fees or expected returns.
5. Verify that stale data blocks new exposure
Define what “fresh enough” means for the strategy before testing it. Record market-data timestamps, account-state timestamps and any sequence checks required by the feed. There is no universal freshness threshold that makes every strategy safe.
In simulation, freeze the price feed, drop a connection, replay an old update and provide inconsistent account data. The proposed DN pass condition is that the system blocks new risk when required state cannot be trusted, alerts the operator and follows a documented recovery process. It should not keep trading merely because the model can still produce confident commentary.
Handle protective actions separately. A stale market feed should not blindly trigger a blanket cancellation that removes protection from existing exposure. Specify which actions can continue, which must stop and who handles the unresolved state.
6. Reconcile an uncertain order before retrying
A lost response is one of the easiest ways for automation to create unintended exposure. Binance Spot documents that a processing timeout can leave execution unknown and directs clients to check the user data stream or query the order’s status. The order may already exist. [1]
Save the trading intent and supported client identifier before transmission. Simulate a response being lost after submission, then verify that the agent checks authoritative orders, fills and account state before another economic action. If reconciliation is unavailable, keep the intent unresolved and block additional conflicting exposure.
| Product | Documented behavior | What your test must establish |
|---|---|---|
| Binance Spot | newClientOrderId is unique among open orders; a reused ID can be accepted after the prior order fills. [2] |
Do not treat ID reuse as permanent duplicate protection. Reconcile filled orders too. |
| Coinbase Advanced Trade | A nonunique client_order_id returns the corresponding order instead of creating another. [4] |
Preserve the original ID and verify the returned order, status and fills. |
7. Rebuild exposure after partial fills and restarts
A submitted order, a partially filled order and a completed trade are different states. Test a partially filled buy, a cancellation racing with a fill, a rejected replacement and a restart between execution and local bookkeeping.
The system should reconstruct filled quantity, remaining quantity, average execution price, fees and open exposure from authoritative records before calculating its next allowed action. Include manual account changes and more than one bot if the account permits them.
For example, requesting ten units and filling four does not leave the system with either zero or ten units. A replacement or exit sized from either assumption can create an operational error. The precise correction depends on the venue and account type, so test the actual supported order semantics.
8. Rehearse stopping, cancelling and handling what remains
Document three separate actions: stop new entries, cancel appropriate outstanding orders and handle existing exposure. Keep an independent operator path available when the agent’s interface or host fails.
3Commas’ DCA documentation distinguishes stopping new entries from leaving current trades open or closing them. Kraken Spot’s dead man’s switch cancels orders when its timer expires and then needs rearming; it does not promise to close holdings or make the account flat. [10] [7]
Inspect cancellation scope before relying on it. Binance Spot’s documented cancel-all endpoint is specific to a symbol. Also identify whether a cancellation removes protective orders that still matter to an open position. After the procedure, inspect actual order and exposure state rather than trusting a “stopped” badge. [2]
9. Protect credentials and test revocation
Keep exchange secrets and wallet recovery material out of model prompts, chat histories, screenshots, code repositories and ordinary logs. Use an appropriate secret store. Review what a hosted bot receives and how its access can be removed. Kraken’s security guidance supports minimum permissions, secure storage and deleting unused keys. [8]
Rehearse revocation using a dedicated disposable test credential. Verify that it can no longer authorize requests, then confirm that the agent stays blocked rather than silently switching to another credential. If a key has been exposed, revocation and incident review are different tasks from simply changing the model prompt.
For on-chain agents, exchange API restrictions are not a substitute for wallet-specific signing and approval controls. Review token allowances, permitted contracts, session-key limits and revocation separately. Never import a primary savings wallet into an unfamiliar demo.
10. Review the evidence and write the restart rule
A responsible person should review the exact build, account boundary, unresolved risks, monitoring coverage and recovery procedure. A solo trader can be that person, but should make this a separate deliberate decision rather than let the agent approve its own escalation.
Document what invalidates the review: a software update, new model or prompt, changed credential, new market, higher leverage, more funding, a failed control or unexplained account state. Re-test the affected controls and their dependencies before a restart.
There is no universal number of paper trades or profitable days that proves readiness. Different strategies encounter different failure modes. Passing this operational checklist also does not establish a statistical trading edge, suitability for your circumstances or a reason to leave simulation.
What your test environment can actually prove
Match the test to the question. The following documentation was available when reviewed; these are capability examples, not platform rankings or authenticated execution tests.
| Environment | Useful evidence | Evidence it does not provide |
|---|---|---|
| Coinbase Advanced Trade sandbox | Parsing documented mock responses and supported error variations. | It is static and unauthenticated. Success does not validate live credentials, market interaction or realistic fills. [5] |
| Alpaca paper trading | Simulated order/account workflows using the environment’s data and fill assumptions. | Actual market impact, latency slippage, queue position or another venue’s execution. [6] |
| Binance Spot test-order endpoint | Validation of the submitted order request. | The test order is not sent to the matching engine, so it cannot establish a fill or a profitable outcome. [2] |
| Your controlled failure harness | Reproducing missing data, ambiguous responses, partial fills and process interruption. | Real-market realism unless your mocks and assumptions are independently justified. This is a proposed DN test method. |
Methodology, original dataset and limits
DN selected ten operational controls spanning software provenance, access, independent enforcement, cost reconciliation, data quality, order ambiguity, exposure, shutdown, secrets and human review. They are an editorial framework derived from documented product behavior and explicit failure-test reasoning. They are not a regulator’s certification or a statistically calibrated model.
Rule: any Fail produces a blocked result. With no failures but at least one Unknown, the result remains incomplete. Ten Pass entries produce “Checklist complete for review.” There are no weights, safety percentages or automatic authorizations. All entries begin Unknown, and missing or invalid values are treated as Unknown.
The dataset consists of the ten visible control names and their evidence requirements. JSON and CSV exports reproduce your recorded states and the interpretation. They do not contain exchange credentials or independently verified test results. The tool makes no network requests; normal site services remain governed by the site’s policies.
A checklist can miss failures, and documentation can change. Market gaps, venue failure, compromised infrastructure, incorrect implementation and human mistakes remain possible. We deliberately do not set a universal account size, daily-loss percentage, paper-test duration or minimum return. Those would require facts this review does not possess.
Choose the next test your evidence supports
Use the AI trading demo-account guide to compare simulation options, the withdrawal-permission guide to examine access boundaries, and DN Pathfinder to find the relevant research for your workflow.
Disclosure: this article provides educational operational analysis, not personal investment advice or an endorsement of any trading system. Some linked DN comparison pages contain disclosed affiliate relationships. The official-documentation links below are research sources; buying a product does not improve your checklist result.
Frequently asked questions
How long should I paper trade before using real money?
There is no universal number of days or trades. A test should cover the strategy’s relevant conditions and operational failures, with reconciled records. Time in simulation and profitability alone do not prove the controls work.
Is an AI trading bot safe if withdrawals are disabled?
Removing withdrawal permission reduces one capability. Trade-enabled access can still lose money through poor trades, excessive exposure or misuse. Check account isolation, permissions, independent limits and recovery separately.
Does a sandbox prove that live trading will work?
Only the capabilities that the environment actually exercises. Coinbase Advanced Trade’s sandbox uses static, unauthenticated responses, while paper environments simulate execution. Neither proves all production behavior or future returns.
What should a bot do when an order times out?
Treat the outcome as unresolved until authoritative order, fill and account records establish what happened. Preserve supported identifiers and avoid blindly placing another economic order. Venue rules differ.
Does stopping the bot close every trade?
Not necessarily. Stopping new entries, cancelling outstanding orders, handling filled positions and revoking credentials are separate actions. Rehearse their scope and inspect the final account state.
What does passing all ten checks mean?
It means you recorded Pass for each control and the checklist is complete for human review. DN has not verified those answers. It is not a safety certificate, a profitability assessment or permission to trade live.
Primary sources
- Binance Spot REST API: general information. Timeouts, unknown execution status and request handling.
- Binance Spot REST API: trading endpoints. Client order IDs, validation-only orders and symbol-specific cancellation.
- Coinbase Advanced Trade: scopes and permissions. View, trade and transfer permissions.
- Coinbase Advanced Trade: create order. Documented duplicate client-order-ID behavior.
- Coinbase Advanced Trade: sandbox. Static, unauthenticated mock responses and supported test errors.
- Alpaca: paper trading. Simulated fills and omitted live-execution effects.
- Kraken Spot: cancel all orders after a timeout. Dead man’s switch scope, expiry and rearming.
- Kraken: API key security. Minimal permissions, credential handling and unused keys.
- Kraken: stop-loss orders. Market-order execution, taker fees and independent stop orders.
- 3Commas: DCA bot operation and setup. Stopping entries versus leaving or closing current trades.
Freshness and corrections
v1.0 · 1 November 2026: initial ten-control framework, documentation review and local checklist/export tests. Recheck the cited product documentation before applying a control. Send corrections with the affected claim, source and date to press@decentralised.news.
