Demo mode is where a workflow earns the right to be examined.

A demo result is not evidence that a strategy will make money. It is a safer place to inspect how the product behaves when an order is prepared, rejected, changed or closed.

1. Start with the connection boundary

Use the narrowest API access available for the workflow being tested. Confirm which account the key reaches, whether it can trade, and how access can be removed. A key that works is not automatically a key that has the right scope.

2. Make the limits visible

Before any order simulation, set a position cap, daily loss boundary, leverage rule and maximum number of actions. The useful test is not only whether the system can enter a trade; it is whether it refuses one when a stated control is reached.

3. Review ordinary and awkward paths

Test a normal order, an edited order, a cancellation, an interrupted connection and a request that violates a rule. Record what the operator sees at each step. A clear decision trail matters when a surprising result needs to be understood later.

4. Compare the record, not just the result

Keep the symbol, setup, size, timing, fee assumptions, rule state and reason for each decision together. Demo activity can hide execution differences from live markets, but a reviewable record still exposes unclear logic and missing controls.

Where Qantova fits

Qantova is designed as a desktop workspace for structured Binance Futures workflows: visible rules, decision review and operator control. It is software information only, not a signal service, investment advice or a claim about future performance.

Explore the product workflow → · More Qantova Journal guides →