Tower Rush RTP and payout maths through a BDT session

Tower Rush Demo

Which RTP applies to the game you open?

The applicable RTP belongs to the particular game configuration: a headline range does not assign its highest value to every operator. Tower Rush RTP and payout maths therefore depend on the rules of the version you open, its currency and its payout limit. The original Galaxsys game has several distinct published records.

These ranges retain their own lower and upper endpoints; averaging them would produce a number that describes none of these records. The provider listing, demo rules and operator configuration are different levels of information. The operator integration selects the monetary configuration. You control the accepted stake and the Build or Cashout decision; these controls do not select a new RTP. Accumulating turnover in the tested session did not trigger an automatic switch to another return setting.

Tower Rush 2 and Tower Rush Branded are separate products, so the original's figures do not automatically apply to them.

For readers in Bangladesh, BDT examples make the money arithmetic directly readable. FUN remains a separate demo unit, however, and neither its balance nor its payout cap converts into taka when you enter a monetary session.

Tower Rush RTP and payout maths from stake to settlement

A settled payout is the gross amount credited for a tower, while the net result subtracts that tower's accepted stake. The distinction matters from the first floor: a successful placement can have a coefficient below ×1, so receiving money through Cashout does not necessarily mean making a profit.

Multiply the coefficients, then apply the limit

Ordinary successful floors multiply the amount already accumulated. For a stake S and successive coefficients m₁, m₂ and onward, the uncapped amount is S × m₁ × m₂ × … . Adding the coefficients would calculate a different result. Cashout settles the applicable accumulated amount when the server accepts it.

In my official mobile demo, a 100 FUN stake followed by ×1.6 and ×1.45 paid 232 FUN after Cashout: 100 × 1.6 × 1.45 = 232. That tower's net result was +132 FUN. Another 100 FUN tower settled at ×0.45, paying 45 FUN and losing 55 FUN overall. Two successive coefficients below one also compound: my ×0.4 followed by ×0.95 produced ×0.38, a 38 FUN payout from a 100 FUN stake. The later successful floor reduced the accumulated payout.

A rising count of placed floors therefore does not imply that the amount available to cash out rises at every step.

For the tested BDT configuration, calculate the completed floor product, apply the 160,000 BDT cap, then round the result down to the nearest 0.01 BDT. Its ordinary cashout formula is:

Gross payout = floor(min(S × product of floor coefficients, 160,000) × 100) ÷ 100 BDT

Here, “floor” means rounding down mathematically. The rule applies to the final amount; repeatedly rounding intermediate displayed coefficients can introduce a different total. Use the settled monetary amount when reconciling your history. The round rules explain the Build and Cashout sequence in more detail.

An absolute cap changes its multiple with the stake

The official demo caps one tower's payout at 10,000 FUN across its 1–100 FUN stake range. Dividing that cap by the chosen stake gives the corresponding maximum payout-to-stake ratio. The frequently quoted ×100 describes the ratio at the maximum demo stake; it is not a universal multiple for every stake.

A raw accumulated amount of 12,600 FUN is capped at 10,000 FUN. The demo permits further building after the cap notification, but the payable ceiling stays fixed. A subsequent collapse without Frozen protection can still settle at zero. Reaching the ceiling and receiving the settled payout are separate events.

The 160,000 BDT limit belongs to one tower in my 1win configuration. It is not a daily withdrawal allowance or the size of a deposit. The highest payout I actually recorded in that session was 950 BDT, well below the ceiling.

Special floors change settlement within the same paid tower

Frozen Floor protects an accumulated amount without creating a second independent payout. In my 100 FUN example, freezing 500 FUN and then collapsing produced one 500 FUN gross payment, for +400 FUN net. In the higher-cashout example, a later 1,000 FUN settlement replaced that lower protected outcome. It did not pay 1,000 plus another 500.

Temple and Triple Build also belong to the existing paid cycle. In my Temple example, the current 150 FUN amount multiplied by ×1.5 became a single 225 FUN settlement. In the Triple Build example, 120 × 1 × 1.5 × 2 became 360 FUN after one initial 100 FUN debit. Those extra floors were not three extra paid bets.

For a session calculation, count the final credit once and keep the original stake as the cost of that tower. This prevents both overstating payouts and inflating the number of rounds. The bonus-floor explanations cover the individual triggers and restrictions.

What my 13 BDT towers actually returned

I completed 13 paid towers at 380 BDT each through the 1win Android launcher on a Xiaomi 15 Ultra in Bangladesh.

I used the original Galaxsys game, cash funds and manual Build/Cashout, without activating a welcome bonus. The session ran for 582 seconds from the first accepted stake to the final settlement.

Observed return uses total gross payouts divided by total accepted stakes: 5,149 ÷ 4,940 × 100 = 104.2308%. My starting cash balance was 3,040 BDT; after the towers it was 3,249 BDT. The reconciliation is 3,040 − 4,940 + 5,149 = 3,249 BDT. The initial deposit funded play, but it was not the turnover denominator.

Nine towers paid something, seven produced a profit and one broke even. Tower 1 illustrates the remaining distinction: its 190 BDT payment was positive, but it recovered only half the stake. Counting every cashout as a win would obscure that loss. Tower 12 contained the session's single natural bonus event, a Temple multiplier before settlement.

The recorded payout frequency was 9/13, or 69.2308%; the profitable-tower frequency was 7/13, or 53.8462%. The bonus-event frequency was 1/13, or 7.6923%. These describe different events in this particular session. None replaces the configuration's theoretical RTP.

The session also had a 532 BDT maximum drawdown between settled balances, even though it finished ahead. Its sample standard deviation of per-tower net results was about 340.05 BDT. Those statistics describe fluctuation inside this short ledger, rather than a universal volatility rating for every configuration or stake.

What 96.69% means for a fixed turnover

At a theoretical RTP of 96.69%, a fixed 4,940 BDT turnover gives an expected gross payout of 4,776.49 BDT and an expected net loss of 163.51 BDT, rounded to two decimal places. The house-edge fraction is 1 − 0.9669 = 0.0331, or 3.31% of turnover in this calculation. Use expected gross = turnover × RTP and expected net = turnover × (RTP − 1), expressing RTP as a decimal. Here the arithmetic is 4,940 × 0.9669 = 4,776.486 BDT before presentation rounding.

Expectation is an average implied by the theoretical rate for the stated turnover, not a scheduled payout to one account.

My actual +209 BDT outcome and the theoretical −163.51 BDT expectation answer different questions. The first records completed play. The second describes a calculation with turnover fixed at 4,940 BDT. It does not reclassify my result, establish a personal entitlement or imply that later towers must remove the difference.

Turnover can exceed the initial funds because money returned from one tower can be staked again. Equally, two sessions funded with the same deposit can generate different turnover. A comparison of theoretical costs therefore needs an equal wagering amount, not merely equal starting balances.

This calculation holds turnover fixed and excludes bonuses, payment fees and stopping rules. Scenario A has 83 BDT less expected loss, a reduction of 21.6710% relative to B's 383 BDT. The RTP difference is 0.83 percentage points. Those are three ways of describing the comparison, with different units and denominators; none promises an 83 BDT profit.

If stopping decisions make turnover variable, preserve each session's actual turnover as an observation. Simply inserting the turnover from a selected successful session into the fixed-turnover formula does not establish the conditional expected result of that selected session. The risk and strategy analysis develops that distinction.

Why a payout frequency cannot stand in for RTP

RTP weights monetary outcomes by their probabilities; payout frequency counts how often the selected event occurs. A payment equal to the stake, a payment below the stake and a large profit all enter the “gross above zero” count once, despite having very different effects on the balance.

An illustrative two-outcome model makes the distinction precise. Give a payment of twice the stake probability 0.485, and a zero payment probability 0.515. Its theoretical return is 2 × 0.485 = 0.97, or 97%, while its payout frequency is 48.5%. This is a separate control model, not a probability formula for a Tower Rush floor.

Under an independent, identically distributed Bernoulli assumption, the 95% Wilson interval for the BDT session's 7 profitable towers out of 13 is approximately 29.14–76.79%.

That interval estimates the profitable-tower proportion under the stated assumption; it is not an interval around the game's RTP.

My four-tower FUN demo finished with 315 FUN returned from 400 FUN staked, an observed return of 78.75%. It had three paying towers but only one profitable tower. Comparing this outcome with the positive BDT session demonstrates why a short realised return and a configured theoretical percentage must retain separate labels.

Check a session without mixing balances

A clean session calculation starts with accepted, settled towers in one currency. Use your own History entries and count each completed tower once; floor animations and other players' entries do not add to your sample.

1. Open the rules and note the original game's configuration, RTP, stake currency and per-tower cap.
2. Record each accepted stake and its final gross payout, including a protected Frozen payment once.
3. Add the stakes for turnover and the gross credits for returned funds. Divide returned funds by turnover to calculate observed return.
4. Subtract turnover from gross payouts for the net gaming result. Reconcile deposits, external withdrawals, refunds and demo resets separately.

In my demo, the balance moved from 100,000 to 99,915 FUN, then a new independent session restored 100,000 FUN. That 85 FUN reset adjustment was not another game payout. Likewise, a returned void stake reverses an annulled wager rather than creating profit from a settled tower.

Putting the numbers to use

Tower Rush RTP and payout maths are most useful when configuration, gross return and net result stay separate. The 96.69% BDT rate describes theoretical return. The 104.2308% result describes my 13 towers. The 160,000 BDT limit describes one tower's ceiling. For a Bangladesh reader checking taka-denominated play, those labels matter more than a single headline percentage.

Read the methodology for how rules, observations and calculations are kept separate. For the distinct question of checking a completed game result, continue to fairness and verification.

Frequently asked questions