A cBot can keep producing the same signals after a symbol changes while sending different orders—or no order at all. The honest test is to snapshot the new contract, rerun the strategy through its boundaries, and compare the complete order path with the old one.
Profit is the last thing to inspect. A symbol specification is part of the execution environment: it governs what volume, price increments and protective-order distances the platform will accept. If that environment changes, an unchanged algorithm has entered a different test.
What a symbol specification can alter
A symbol specification is the collection of trading constraints and conversion details attached to an instrument. In cTrader, the Symbol API exposes, among other fields, the minimum, maximum and incremental trade volume, tick size, pip size, and methods for converting and normalising volume. The platform's own Symbol reference documents those fields and methods.
That matters because a cBot usually turns a signal into an executable request through several assumptions. A change at any of these points can alter the path:
| Contract field or rule | What can change in the cBot run | Test that exposes it |
|---|---|---|
| Minimum volume or volume step | A calculated order can become too small or land between valid increments | Test volumes just below, at and just above each boundary |
| Maximum volume | Scaling or recovery logic can request an invalid size | Force the sizing path toward the cap and record the result |
| Pip size or tick size | Price rounding and stop calculations can no longer mean what the code assumed | Compare submitted prices and protective distances before and after |
| Stop-loss or take-profit distance | A valid signal can become an invalid protective order | Place orders at the exact minimum distance and one increment either side |
| Commission, swap or margin terms | The same sequence can have a different equity and capacity path | Re-run with the dated conditions and inspect the ledger |
The point is not that every field will change at once. It is that a backtest based on a remembered contract is not evidence about the contract now attached to the account.
Save a contract snapshot before touching the full backtest
Start with a dated record, not a screenshot of the equity curve. Export or write down the symbol name, account type, server or broker context, the fields the cBot uses, and the cost and margin conditions relevant to the test. Keep the old and new records together.
Then identify dependencies in the code. Search for fixed lot sizes, multipliers, conversions between lots and units, hard-coded pip values, rounding, and price-distance calculations. cTrader documents QuantityToVolumeInUnits, NormalizeVolumeInUnits, PipSize and TickSize; its advanced cBot operations guide also shows that algos work in volume units by default and converts lots explicitly.
This review often finds the uncomfortable case: the strategy reads the live Symbol object in one place but carries an old assumption in another. A volume can be normalised correctly yet a stop can still be calculated from an unsuitable fixed increment. The code need not be wrong for the original symbol to be wrong for the revised one.
Use boundary tests before historical performance tests
A long backtest is poor at explaining one rejected order. Begin with small, adversarial cases where the expected outcome is visible.
Test the sizing boundaries
Feed the sizing routine inputs that produce a requested volume just under the minimum, exactly at the minimum, one step above it, and just below and above the maximum. Log the requested volume, the normalised volume, and whether the trade request was accepted. Do not silently treat a rounded-down order as equivalent: it may carry less risk or skip a trade altogether.
Test the price boundaries
Build cases where the calculated stop loss or take profit sits at the permitted distance, then move it by one valid price increment in each direction. Record the submitted price, the platform response and the final attached protection. cTrader's Open API symbol model identifies minimum stop-loss and take-profit distances as symbol fields, and documents that their unit can be a price-distance type. That is a reason to inspect the current definition, not guess from a forex example.
Test the account path
Run a short controlled sequence with the changed conditions: entries, modifications, partial exits and any restart logic the cBot uses. Compare more than final net profit. Compare timestamps, requested and filled volume, rejection or error messages, protective prices, commissions or financing where applicable, and the resulting balance and equity path.
This is particularly important for a prop-firm account. A missed entry can change later exposure; a smaller normalised order can change realised loss; a rejected protective order is a risk-control defect, not a cosmetic difference. The relevant firm and broker remain the authority for their current conditions, so retain the source record used for the run.
Decide whether historical results are still comparable
There are three honest outcomes after the boundary tests.
| Result | What it means | How to report it |
|---|---|---|
| Order path matches | The tested changes did not alter the recorded cases | State the snapshot and cases tested; do not claim future parity |
| Orders differ but remain valid | The strategy is now running under different execution assumptions | Re-run the historical test and show the changed assumptions |
| Orders are rejected or protection differs | The old result is not a valid description of the revised contract | Fix or constrain the code, then test again before comparing performance |
Do not decide this from a similar-looking curve. Two reports can end at comparable balances while hiding different exposure, skipped trades or protection. The order log is the evidence; the final number is only a summary.
What realbacktesting makes visible
realbacktesting is a trading-software studio for cTrader that treats a result as something a trader should be able to inspect and challenge. Its published methodology sets out the data, execution, cost and validation assumptions behind a run. The funding model keeps account constraints in view instead of reducing the exercise to a headline return.
That is the useful standard here. A test after a symbol change should identify the contract used, exercise the vulnerable order boundaries, and preserve the comparison. It is not a promise that the next live order will fill the same way. Markets, liquidity and broker conditions can still differ. It is evidence that the code survived the conditions you actually checked.
For adjacent execution work, see how to backtest pending orders in cTrader and how to audit margin in a cTrader backtest.
Frequently asked
Does changing a symbol specification require a new backtest?
It requires a new validation of the order path. If the changed field affects volume, price increments, order-distance rules, costs or account capacity, rerun the relevant historical test under the recorded conditions rather than assuming the old report still applies.
Is normalising volume enough after a symbol change?
No. Volume normalisation can make an order valid, but it can also change its size and risk. Test volume boundaries alongside price rounding, protective-order distances and the account-level effects of altered fills.
Can a similar equity curve prove the cBot is unaffected?
No. A similar curve does not prove that the cBot placed the same orders, attached the same protection or kept the same exposure. Compare the event and order logs before using the curve as a summary.
The stubborn takeaway
When the contract changes, the old equity curve is history—not a certificate that the next order still makes sense.