Sizing a session bankroll for a progression

Most losing sessions are not caused by a bad strategy. They are caused by a good-enough strategy run on a bankroll too small to survive its ordinary bad patch — which means the session ends at the worst possible moment, on a rule nobody chose in advance.

This is the arithmetic for choosing that number deliberately.

Start from the deepest run, not the average

The intuitive approach is to bring "enough for a decent session" and adjust as you go. The problem is that a progression's requirement is not smooth: it is nearly flat most of the time and then vertical, and the vertical part is what ends you.

For an even-money bet on a single-zero wheel, the chance of losing is 19/37 per spin. Consecutive losses compound quickly:

The right-hand column is the whole problem. Every two steps of depth roughly quadruples the money required while only cutting the frequency by about four. You are buying protection at exactly the rate it costs — which is the house edge asserting itself again.

"Rare" is per sequence, not per session

A one-in-207 event sounds like something that will not happen to you. Over a session it happens routinely, because you are not running one sequence — you are running dozens or hundreds.

The chance of hitting at least one 8-loss run over N sequences:

Check the table limit before anything else

There is no point sizing a bankroll for a depth the table will not let you reach. The limit, not your money, usually sets the ceiling.

On a table with a 5 unit minimum and a 500 unit maximum, a doubling ladder runs:

Step:   1    2    3    4    5    6    7     8
Bet:    5   10   20   40   80  160  320   640  <- refused

Seven steps. The eighth bet is over the limit, so the sequence cannot be completed, and the recovery you were relying on simply is not available. Your effective maximum depth is:

depth = floor( log2( table_max / min_bet ) ) + 1
      = floor( log2( 500 / 5 ) ) + 1
      = floor( 6.64 ) + 1  =  7 steps

Raising the base bet makes this worse, not better: at a 10 unit base on the same table you get six steps, and at 25 you get four. A bigger base unit buys a shallower ladder. This is the trade almost nobody makes consciously.

Sizing, in four steps

Work backwards from the constraint rather than forwards from a comfortable-sounding number.

1. Read the deepest run out of the backtest. Not the average, not the median — the worst one in the sample. Call it D steps.
2. Confirm the table allows D steps at your intended base unit, using the formula above. If it does not, either lower the base unit or accept a shallower ladder and re-test.
3. Compute the units at risk for a completed D-step ladder. For doubling that is 2^D - 1; for gentler progressions read it straight off the backtest's peak requirement.
4. Bring a multiple of that, not exactly that. Covering the worst historical run exactly means a coin-flip on whether the next one is worse. Two to three times the deepest observed requirement is a reasonable working margin.

A worked example. A backtest over 100,000 spins shows a deepest run of 7 steps, needing 127 units at peak. The table allows 7 steps at a 5 unit base. So:

Units at peak       127
Base unit             5
Cash at peak        635
Working bankroll   1,270 to 1,905   (2x to 3x)

If that number is uncomfortable, the honest response is to lower the base unit or choose a shallower strategy — not to bring less and hope. Bringing half of it does not halve the risk; it converts a manageable drawdown into a stop-out.

Set the stop-loss where it can still do something

A stop-loss placed below the deepest run your strategy needs will fire during a recovery, locking in the largest loss the ladder can produce. That is the worst of both designs: you take the deep drawdown and then leave before the recovery that justified it.

Either set the stop-loss outside the ladder's full requirement, so it only triggers on genuinely abnormal sessions, or accept that you are running a shallower strategy than you think and reconfigure it properly.

The same applies to take-profit. A progression grinds out small wins; a take-profit set at 200 units on a strategy that earns 1 unit per sequence is asking for 200 successful sequences without a single deep run, which the table above says is not going to happen.

Let the software hold the line

Everything above is arithmetic you can do on paper. The hard part was never the arithmetic — it is holding to it at eleven o'clock when you are down and the ladder is one step from coming good.

This is the single most useful thing VIPER does for you, and we would rank it above every strategy in the platform. Bankroll protection is automated discipline: the numbers you set while you were calm get enforced whether or not you still agree with them.

• Set the bankroll and base unit at session setup, and your staking follows from the maths rather than from how the last twenty minutes went.
• The stop-loss fires by itself at the number you chose, not at the number you can talk yourself into.
• The take-profit fires by itself too, so leaving while ahead stops being a feeling you have to summon and becomes something that just happens.
• The session is tracked as it runs — balance, high and low, consecutive losses, where the ladder currently sits — so the position you are in is on screen instead of in your head.
• Every spin, recommendation and decision is recorded, which means the next time you size a bankroll you can work from what actually happened rather than what you remember.

The wheel does not care about any of this. Your bankroll does, and it is the only part of the evening you genuinely control.

What to carry away

• Bankroll follows from the deepest run, not from the average or the win rate.
• Table limits usually bind before money does, and a larger base unit makes the ladder shallower.
• A one-in-207 run is a near-certainty across a few hundred sequences. Size for it as an expected event.
• Set stop-loss and take-profit levels that are consistent with the ladder, or they will fire at the worst possible moment.

Every number here comes out of a backtest before it costs anything, which is the entire argument for running one. If you have not yet, how to read a backtest covers what to look at, and the short session explains why the drawdown — not the win rate — is the figure that decides how a session goes.

— Team Viper