How to Test a Trading Strategy on WEEX Demo Before Going Live

The reliable way to test a trading strategy is in three stages that each remove a different kind of self-deception: a backtest to check the idea has ever worked, a forward test on the WEEX demo account to check it works on prices you have not seen yet, and a small capped live pilot to check it survives real fills. Manual traders run stage two in the demo terminal. Developers run it against WEEX's futures API, which exposes simulated endpoints such as POST /capi/v3/sim/order and GET /capi/v3/sim/balance that behave like the live ones but settle in demo SUSDT. This article sets out what to measure at each stage, the specific ways the demo flatters a strategy, and a promotion rule that is based on process metrics rather than a lucky month.

Stage one: Backtest, and what a backtest cannot tell you

A backtest answers one question: has this rule set produced positive expectancy on historical data? It cannot tell you whether it will next month, and it systematically overstates results for three reasons that matter more in crypto perpetuals than in most markets.

Fees and funding are underestimated or omitted. A strategy that trades ten times a day on a perpetual pays taker fees and funding every eight hours, and a backtest that ignores either can turn a losing system into an apparently profitable one.

Fills are assumed at the candle close or the signal price. Live, a market order on an altcoin perpetual fills across several levels of the book; a limit order may never fill at all on the trades that would have been winners.

Lookahead and overfitting creep in. Any parameter you tuned to the historical data will look better on that data than on the future.

So the backtest's job is to reject bad ideas cheaply, not to approve good ones. A strategy that fails a backtest with realistic fees is done. A strategy that passes has earned a forward test, nothing more.

Stage two: Forward test on WEEX demo, manually or through the sim API

Forward testing means running the strategy on live prices with simulated money, in real time, with no ability to peek ahead. The WEEX demo account is built for this: the same terminal, the same live price and funding feed, a 50,000 USDT starting balance in SUSDT, and 5,000 USDT top-ups available when the balance drops below 5,000 with a 72-hour cooldown between requests.

For a discretionary strategy, forward-test by hand in the demo terminal. Take every signal your rules produce, at the size your rules dictate, and log each trade before you know the outcome: setup, entry, stop, target, size, and the reason. The discipline of logging before the result is what makes the data usable.

For an automated strategy, point the bot at the simulated endpoints in WEEX's futures API. As of September 2026 the documented demo endpoints include:

• POST /capi/v3/sim/order to place an order (TRADE permission, requires symbol such as BTCSUSDT, side, positionSide, type, quantity, a newClientOrderId, and for limit orders price and timeInForce of GTC, IOC, or FOK; optional tpTriggerPrice and slTriggerPrice with a working type of CONTRACT_PRICE or MARK_PRICE).
• GET /capi/v3/sim/balance to read the demo account balance, available balance, frozen amount, and unrealised PnL (USER_DATA permission, IP weight 5).
• Demo equivalents for all positions and order history.

The endpoints use the same authentication headers as live (ACCESS-KEY, ACCESS-SIGN, ACCESS-TIMESTAMP, ACCESS-PASSPHRASE), the same HMAC SHA256 and Base64 signing scheme, and the same 30-second timestamp tolerance. That is the point: your bot's authentication, error handling, and order-management code is exercised for real, while the money is not. Because the live path is /capi/v3/order and the demo path is /capi/v3/sim/order, keep the base path in configuration, not scattered through the code, so that promotion to live is a one-line change you can review.

Two API details are worth building in during the forward test rather than discovering live. First, newClientOrderId is your idempotency key; generate it deterministically per signal so that a retried request after a timeout cannot double-fill. Second, respect the rate-limit headers. Order endpoints are limited per account, and the demo response exposes counters such as X-ORDER-COUNT-10S and X-ORDER-COUNT-1M; a bot that ignores them will meet HTTP 429 and a 10-second ban at the worst possible moment live.

What to measure during the forward test

P&L is the least useful number a forward test produces, because a few weeks of results on one market regime are dominated by luck. Measure the process instead.

• Sample size: at least 30 to 50 completed trades, or the statistics are noise. For a low-frequency swing system that may mean months; there is no shortcut.
• Expectancy in R: average result per trade expressed in multiples of the risk unit. A system with 0.3R expectancy over 50 trades is more informative than one showing +18% over 12 trades.
• Maximum drawdown in R and its duration. Decide in advance the drawdown at which you would stop; if the forward test hits it, the strategy failed, whatever the final P&L.
• Signal adherence: the percentage of signals actually taken as specified. Anything under roughly 90% means you are testing a different strategy from the one you wrote down.
• Fill divergence: the difference between the price your rules assumed and the price the demo actually filled. It is a lower bound on live slippage.
• For bots: error rate by type (authentication, rate limit, rejected parameters), reconnect behaviour, and whether the bot's own position ledger matched the exchange's positions endpoint at every check.

How the WEEX demo flatters a strategy, and how to correct for it

Every simulator is kinder than the market. The demo's specific kindnesses are predictable, and each has a correction.

Demo fills do not consume liquidity. On BTC and ETH perpetuals the distortion is small; on thin altcoin pairs it is large. Correction: restrict the forward test to pairs with depth appropriate to your live size, or subtract a slippage haircut per trade based on the live order book at the time of the signal.

Stop-losses fill at the trigger. In a real cascade, a stop-market order fills wherever liquidity is. Correction: model stops as filling one or two ticks worse than trigger on majors and materially worse on altcoins, and use mark-price triggers where the strategy allows.

The 50,000 USDT balance is unrealistic for most traders. Correction: trade the demo down to your intended live balance and size from that figure, so leverage and position size are what they will actually be.

There is no emotional cost. No correction exists; this is what stage three is for.

Stage three: The capped live pilot and the promotion rule

Promotion to live should be triggered by the forward-test metrics, not by a good week. A defensible rule: at least 50 forward-test trades, positive expectancy in R, drawdown inside the pre-set limit, signal adherence above 90%, and for bots a clean error log over the final two weeks.

The live pilot then runs with a hard cap. Fund only what you can lose in full without consequence, size positions at a fraction of the forward-test size, and use lower leverage than the demo. For a bot, this is where the base path changes from /sim/ to live, and where the API key changes from whatever you used in testing to a dedicated, IP-bound, Futures/Contract-scoped key created for this strategy alone. Keep the demo bot running in parallel; a live-versus-demo divergence in fills or PnL is the cleanest measurement of real-world friction you will ever get.

Scale up only after the pilot reproduces the forward-test expectancy, allowing for the slippage you now measure directly. If it does not, the strategy did not fail in the pilot; it failed in the forward test, and the pilot caught it cheaply.

What experienced operators watch

The failure mode that ends most systematic traders is not a bad strategy. It is a good forward test followed by a live deployment at full size with a key that has more scope than it needs, on a server whose clock drifts, with no kill switch. The demo account and the sim API exist to burn those problems off before money is involved. Use them for the boring things: authentication, idempotency, rate-limit handling, reconnects, and position reconciliation. The strategy edge, if it exists, will still be there afterwards.

FAQ

1. Can I test a trading strategy on WEEX without real money?

Yes. The WEEX demo account provides 50,000 USDT of simulated funds for futures, and the futures API exposes simulated endpoints under /capi/v3/sim/ for automated testing.

2. Do the WEEX demo API endpoints use the same authentication as live?

Yes. The same ACCESS-KEY, ACCESS-SIGN, ACCESS-TIMESTAMP, and ACCESS-PASSPHRASE headers, HMAC SHA256 signing, and 30-second timestamp window apply.

3. How many trades do I need before trusting a forward test?

At least 30 to 50 completed trades measured in R. Fewer than that, the result is dominated by the market regime rather than the strategy.

4. Why do demo results look better than live results?

Demo fills do not consume liquidity, stops fill at trigger, the balance is larger than most live accounts, and there is no emotional cost. Each inflates results, especially on illiquid pairs.

5. What API permission does the demo order endpoint need?

The documented POST /capi/v3/sim/order endpoint requires TRADE permission; the balance endpoint requires USER_DATA. Use a dedicated key for testing and a separate, IP-bound key for live.

6. Should I keep the demo running after going live?

Yes. Running the same strategy on demo and live in parallel gives a direct measurement of slippage and execution friction.

Risk Warning

Leveraged futures trading can result in the rapid loss of your entire margin, and a strategy that performs well in backtests and demo forward tests can lose money live because of slippage, liquidity gaps, fees, funding, and execution errors that simulations cannot reproduce. Automated strategies add operational risk: a bug, a clock drift, a rate-limit ban, or a misconfigured API key can place unintended orders that cannot be reversed. Cryptocurrency prices are volatile and you may lose part or all of any capital you commit. WEEX demo and API features are described as of September 2026 and may change; nothing here is investment advice.