Is a Candle to Candle Recovery Strategy Safe? What 8,999 Trades Showed

A candle to candle recovery strategy is not safe in the sense most people mean when they ask. The rule set (go long on a green close, short on a red close, exit after one candle, and after each losing candle step the next order size up a ladder until a win resets it) is a martingale-style progression dressed as a candle pattern. It does not change the probability of the next candle; it changes how much you have on the table when a losing streak arrives. The ladder can be built correctly, verified exhaustively and run without a single logic error, and the strategy can still have a profit factor under one, because the edge was never in the rules.

I know because I built one to a client's specification, verified the ladder on 8,999 out of 8,999 consecutive trade pairs, and reported the backtest plainly. This post explains what the strategy does, why the maths works against it, what a correct implementation looks like, and what I tell clients who want one. It is engineering and arithmetic, not financial advice; anyone who trades a ladder like this does so on their own account and at their own risk.

What is a candle to candle recovery strategy?

The version I was given, as a photographed sketch and one paragraph, was:

1. On each candle close, open a position in the direction of the candle's colour: long after green, short after red.
2. Hold for one candle. Exit at the next close, or earlier if an opposite-colour candle closes against you.
3. If the candle lost, the next order's quantity steps up to the next rung of a fixed ladder (for example one, two, four, eight lots).
4. On a winning candle, the quantity resets to the base rung.

Variants let the user define a loss by candle colour (the candle went against the position) or by realised profit and loss, and offer different recovery modes for how aggressively the ladder climbs. The intention is always the same: the eventual win is sized large enough to pay back the losses before it.

Why does the recovery ladder not create an edge?

Three pieces of arithmetic, none of them controversial:

• Candle colour has close to no memory on liquid markets at intraday timeframes. The next candle's direction is roughly a coin flip conditioned on the last one, minus costs. So each rung is an independent bet with slightly negative expectation after spread and commission.
• A ladder that doubles needs a win within a fixed number of steps or the account cannot fund the next rung. The probability of a streak of N losses is small for any single sequence, but across thousands of trades it is a certainty. On 8,999 trades a streak of ten against you is expected, not unlucky.
• Position limits and capital cap the ladder, so the strategy is effectively "collect many small wins, then take one loss the size of all of them combined, plus a bit". The profit factor reflects that: gross wins divided by gross losses lands near or below one once costs are included.

The ladder redistributes outcomes in time. It does not change their sum.

What does a correct implementation need to track?

Even a strategy with no edge deserves a correct build, because the client is paying for the rules as specified and because a buggy ladder hides the result. My Pine v6 implementation keeps its own state rather than trusting the tester's built-in position variables:

• Current rung and the quantity for the next order.
• Direction and entry bar of the open position.
• Loss basis setting: candle colour or realised profit and loss.
• Recovery mode: three variants of how the ladder advances.
• Counters for verification: total trades, one-candle holds, overlaps, same-bar close-and-re-enter events.

Orders are processed on bar close with no pyramiding, so there is exactly one position at a time and exits are unambiguous. Each order emits a JSON-shaped alert message carrying direction, quantity and rung so a downstream bridge can mirror it, and a diagnostics table on the chart shows the ladder state and the verification counters live.

How do you verify a ladder strategy is correct?

Sampling a few trades is not enough for a progression, because the bug you are looking for is a rung that fails to reset or advance once in a thousand. I verified exhaustively:

1. Export every trade from the tester's trade list.
2. For every consecutive pair of trades, check that the second trade's quantity equals the rung the first trade's outcome implies: advanced on a loss, reset on a win.
3. Check that every hold was exactly one candle unless an opposite close exited early.
4. Check that no two positions overlapped and that a same-bar close-and-re-enter produced two distinct trades.

Result: 8,999 of 8,999 pairs correct, all holds one candle, zero overlaps, same-bar re-entry working. The ladder was right. The strategy still showed a profit factor under one with default settings on Nifty 15-minute, which is exactly what the arithmetic predicts.

What should you do with the result?

Report it. The client received the verified strategy, the diagnostics, the alert payloads and a one-paragraph statement that the backtest with defaults had a profit factor below one and why a martingale-style ladder tends to produce that. One ambiguity in the sketch (an extra ladder step after a win that contradicted the written text) was implemented per the text and flagged as the single change to make if the drawing was the intent. That is what a client is owed: the thing they asked for, built correctly, with an honest reading of what it does.

If someone wants to keep exploring the idea, the honest directions are a hard cap on the ladder depth with the resulting loss accepted as the cost of the method, or replacing the colour signal with something that has measurable conditional edge and keeping flat sizing. Neither turns a ladder into a free lunch.

How I built this: the Candle-to-Candle Recovery Ladder Strategy

The Candle-to-Candle Recovery Ladder Strategy is the client build described above, in Pine v6 with an offline compile checker in the loop. The workflow was:

1. Translate the sketch and paragraph into an explicit rule list, and resolve the one contradiction per the written text with a flag.
2. Implement the state machine with its own bookkeeping, close-of-bar processing and no pyramiding; add the three recovery modes and the two loss bases as inputs.
3. Emit a JSON alert message per order and draw the diagnostics table.
4. Compile offline, push to the chart, and export the full trade list.
5. Verify every consecutive trade pair, hold length and overlap programmatically.
6. Report the verification counts and the profit factor under one to the client without softening it.

Design decisions: own state rather than tester state, exhaustive rather than sampled verification, alerts per order for automation, and a plain statement of the no-edge result. The outcome was a correct ladder, verified on 8,999 of 8,999 pairs, delivered with the truth attached. If you want to see how I treat strategies that do pass an honest filter, read how I avoid curve-fitting a Pine strategy, and for the question of whether any system is worth sizing up, the FVG and order-block regime strategy shows a filtered result with a holdout.

FAQ

Would a smaller ladder step make it safe?

A gentler ladder (adding one lot instead of doubling) lowers the size of the eventual large loss and extends how long you survive, but it does not change the expectation per trade. It is a slower path to the same place, with smaller swings on the way.

Does using realised profit and loss as the loss basis help?

It changes which candles count as losses (a candle that went against you but closed near entry might not trigger the ladder) and therefore how often the ladder advances. It is a legitimate variant and I implemented it; it does not create an edge either.

Can the alerts be used to run this live through a bridge?

Technically yes: each order emits a payload with direction, quantity and rung that any webhook bridge can consume. Whether to do so is a decision about risk, not engineering, and I would not recommend it on the evidence from this build.

Why build it at all if the maths says it loses?

Because the client asked for an honest implementation and an honest answer, and the only way to give the second is to do the first properly. A verified build that reports a profit factor under one is more useful than an opinion.

If you have a strategy idea you want built and verified honestly, tell me about it on the contact page.