A crypto exchange testnet checks behavior in a separate exchange environment; Live trading can change a real account. A passing testnet run can support claims about the requests and recovery paths actually tested. It cannot establish production permissions, real-market execution quality or future profitability. Before switching, verify credentials, endpoints, account identity, product support and order state independently.
“Tested successfully” is incomplete evidence. What was tested: the strategy rule, the API signature, cancellation after a disconnect, or the ability to display a balance? Each answers a different question. Moving to Live requires identifying the questions that the earlier environment could not answer.
Use this article to write an acceptance record for a connection, rather than to choose a strategy. The examples are original hypothetical tests, not observations from a live KLINEO account.
Three environments that should not share one label
A local or application-level simulation can model a workflow without sending its orders to a real exchange account. An exchange testnet accepts supported API requests in a venue's separate testing system. Live uses the intended production service and account, where accepted orders can create financial exposure.
KLINEO's Virtual, testnet and Live guide describes its product-specific boundaries. Virtual uses simulated funds; DCA Virtual execution uses the Binance testnet path. That does not create a sandbox for every exchange. The current KuCoin connection is Live only, and some other venue or product paths have separate limitations.
Avoid assuming that every venue uses “demo” and “testnet” interchangeably. Bybit documents a Demo Trading service with a distinct account and its own supported API subset. Binance separately documents Spot Demo Mode and Spot Testnet. Those provider distinctions do not establish that KLINEO integrates with every service described. Bybit Demo Trading, Binance Spot Demo Mode.
An exchange logo proves neither environment support nor execution readiness. Record the exact service, market and account type being tested.
Write the claim before running the test
Suppose the intended claim is “the connection can recover the final state of an order after losing a response.” A successful balance request does not test that claim. A test that submits an order, deliberately loses observation and then recovers its identified status is closer, within the environment used.
This distinction produces a more useful test plan:
| Proposed claim | Evidence needed in the chosen environment | What remains unproven for Live |
|---|---|---|
| Credentials identify the intended account | Supported authenticated account read and identity comparison | Production credential permissions and eligibility |
| Order parameters pass current rules | Current symbol metadata and a supported validation or test action | Future rule changes and actual fills |
| An accepted order can be tracked | Persisted client and exchange identifiers plus status observations | Production stream reliability and latency |
| Missing responses do not cause duplicate orders | Recovery test using the original order identity | Behavior during every possible production failure |
| Stop controls have understood effects | Observe local scheduling and exchange-held work separately | Guaranteed immediate liquidation or cancellation |
Keep the claim narrow enough to falsify. “The bot is safe” has no clear pass condition. “The recovery path found the original order without submitting a second one” describes an observable outcome.
The order timeout article provides the account-state reasoning behind the recovery row. It is useful in testing because a simulator can otherwise conceal the uncertainty that a real network creates.
A fictional acceptance run, including a deliberate failure
Consider a hypothetical spot connection. The operator plans to test one supported order path in an exchange test environment. The symbol, price and quantities below are invented; they are not recommended trade settings.
The first run requests 0.24 units at a limit price of 50 quote units. The gross limit notional is 0.24 × 50 = 12.00 quote units. That arithmetic only checks the intended request; whether it meets a venue's rules depends on the test environment's current filters.
The operator records the request's identity before submission, then simulates losing the response. The recovery process queries the original order and discovers a partial fill of 0.09 units with 0.15 remaining. The two quantities sum to the requested 0.24. The operator deliberately cancels the remainder and records the final cumulative fill.
A second run changes the requested quantity to a deliberately invalid step for that test symbol. The expected outcome is a specific rejection with no assumed fill. The operator confirms the account state rather than treating any visible error message as sufficient proof.
The acceptance note records:
- The test environment, account label and instrument metadata observation time.
- The intended 12.00 gross notional, before fees or any actual fills.
- The original order identifiers and the 0.09/0.15 observation.
- The final order state after the deliberate cancellation attempt.
- The invalid-quantity rejection and the subsequent account-state check.
- Any behavior the test harness could not simulate.
There is no profit result in this record. Its value is demonstrating two operational paths and their limitations. If the environment resets before records are preserved, the missing history must be acknowledged rather than reconstructed from memory.
Binance Spot Testnet documents virtual balances and periodic resets that remove order data. That makes retaining a non-secret local test record important; a long-lived test key does not imply the associated test account history is permanent. Binance Spot Testnet general information.
Why simulated fills cannot price production risk
A test environment can use different participants, liquidity and operational conditions from a real market. Even when an endpoint or order rule is similar, the economic outcome can differ. A fill at the requested price in a test does not measure production slippage, queue position, spread or the market impact of your size.
An application simulation introduces its own assumptions. Does it fill a limit order merely because a candle touches the price? Does it model the order arriving after the signal? Can it represent partial fills, rejected cancels and missing data? Those choices can matter more than whether the equity chart looks smooth.
The backtest evidence guide shows how identical price bars can support incompatible assumed outcomes. A connection acceptance test should not borrow a backtest's profitability result as evidence about production order handling.
Also distinguish a strategy rule from an exchange constraint. A quantity can be sensible under a capital plan and still fail a minimum-notional or quantity-step rule. Use the order minimums worksheet when checking how a small configured budget becomes an executable order.
Make the Live transition a separate authorization
A mode switch should not be treated as a cosmetic preference. It changes which account can be affected. Start with the intended venue, supported account type, product, instrument and production credential. Review permission and IP settings again, even if the testing credential worked.
Confirm that the account contains only the capital and collateral you intend to expose. That is a planning decision, not a guaranteed loss cap. A derivatives account can have different collateral relationships, liquidation rules and obligations from a simple cash spot example.
Next, inspect existing Live orders and positions. Switching the visible KLINEO workspace to Virtual does not close real positions or revoke production credentials. An old production order can coexist with a new test result. Each environment needs its own state record.
Use a supported read-only verification first. Record what succeeded and when, then complete the product's actual readiness checks. Do not infer Live support from generic provider documentation or reuse a credential in an endpoint for a different environment. The API connection policy lists current product constraints and the required credential forms.
What should stay in the acceptance record?
Retain enough detail for a later failure to be comparable with the test. That includes the application version or review date, environment, account label, instrument, order type, input values, expected behavior and observed result. Keep secrets, signed URLs and private account dumps out of shared reports.
Include negative tests that matter to the task: an invalid size, a stale timestamp in a controlled environment, a stream interruption, or a stopped workflow with an exchange-held order. Do not intentionally damage a Live connection or create an unauthorized order to satisfy a checklist. Test only supported actions in the appropriate environment.
A useful unresolved-items section might say “production IP restrictions not yet verified” or “this venue's demo stream does not support the required event.” Those statements guide the next decision. Replacing them with “all tests passed” hides the exact reasons not to proceed.
Finally, define what would invalidate the acceptance record. Credential replacement, an account-type change, a new order path or altered exchange rules may require another review. The connection-health article explains why a past success is evidence with a timestamp, not a permanent property of the connection.
Editorial method: Prepared with AI assistance on 20 October 2026 using official exchange environment documentation and KLINEO's public mode and connection guides. The acceptance run is fictional; its notional and quantity sums were checked independently. No live order, testnet performance measurement or customer result is claimed.