Tower
Rush payout maths and RTP across configurations

At 97% RTP, the theoretical gross return is 97% of the amount wagered, not 97% of your original deposit paid back on demand. Turnover adds the stakes of settled rounds. Reusing a balance for another round adds to turnover again, even when you have made no additional deposit.

For readers in Pakistan, PKR makes the cost comparison concrete. At a fixed turnover of PKR 35,000, the selected configuration has expected gross returns of PKR 33,950 and an expected net result of −PKR 1,050. That is an expectation across the model, not a scheduled charge or a prediction of your next session.

The difference is 0.8 percentage points of RTP and PKR 280 in expected losses. Relative to the lower-return configuration's PKR 1,330 expected loss, that is a reduction of about 21.0526%. The percentage-point change and the relative reduction describe different quantities. Neither means that every player loses that amount.

Use expected gross = turnover × RTP and expected net = expected gross − turnover, with RTP expressed as a decimal in the calculation. A positive result from one run does not replace either formula. Nor does a loss create an entitlement to a later compensating win.

A search for “tower rush rtp” can return several percentages because the original game has source-specific configurations and published ranges. These values should remain attached to their respective product cards or rules profiles; combining their endpoints would create a new range with no single configuration behind it.

The provider and operator integration determine the configuration. Changing the amount in Bet does not select a different RTP, and the configuration does not switch inside an accepted round. When a round ends, the tower and its current multiplier reset. There is no accumulating RTP counter that fills up until a payout becomes due.

The original is a Galaxsys game. Tower Rush 2 is a separate product. So is Tower Rush Branded. Their controls and figures do not supply rules for the original merely because the titles share words.

A “tower rush payout calculation” starts with the accepted stake and ends with a settled gross amount. Gross is the full game payout, including the stake component when returned through a winning settlement. Net is the difference between that payout and the original stake. A refund follows a separate accounting path.

The original round uses one initial stake, followed by Build decisions and a manual Cashout or a fall. A further Build continues the same round. It does not create another initial debit. Cashout settles the game result to your playing balance; it is not a request to withdraw PKR through an operator's cashier.

The PKR profile allows stakes from PKR 27.00 to PKR 36,000.00 in PKR 0.50 steps. Its gross cap is PKR 3,150,000.00 per round. The FUN demo has its own stake grid and cap, despite both selected profiles having 97% RTP. FUN is a virtual unit, not a PKR credit.

Intermediate floor multipliers are multiplied before final rounding. Apply the payout cap to the raw result, then round the monetary gross half-up to the nearest 0.01 currency unit. The half-rupee stake step and the one-paisa settlement precision serve different purposes; a valid stake need not produce a payout ending in .00 or .50.

In the demo cap example, a raw result of 12,875 FUN becomes 10,000 FUN. The remaining 2,875 FUN is not credited. This is a restriction on the full payout of that round, not a limit on an external withdrawal application or on the sum of several separate rounds.

A cash cap is not a universal maximum multiplier. Dividing 10,000 FUN by the maximum demo stake of 100 FUN gives 100×, but that ratio changes with the stake. In the PKR profile, PKR 3,150,000 divided by PKR 36,000 is 87.5×. These are effective payout ceilings for those stake amounts, not promises that you can reach those results.

Maximum Win does not create Auto Cashout. The interface warns that continuing cannot increase the payout beyond the cap and can still lose the accumulated amount, subject to any Frozen protection. Check that warning before treating a large displayed multiplier as an amount already secured.

I checked the following outcomes in the FUN demo on my Google Pixel 10a running Android 16. Each row has one starting debit. The differences show why you should reconcile the final payout with the stake instead of counting every floor animation as a separate bet or every displayed protection amount as another credit.

Temple multiplies the amount already accumulated. In the recorded case, the stake had reached 1.8× before the wheel supplied 2×, so the final factor was 3.6×. Multiplying only the starting stake by the wheel's 2× would omit the existing accumulation and understate the payout.

Triple Build works through multiplication too: 1.2 × 1.25 × 2 equals 3. The recorded 16 FUN stake therefore returned 48 FUN. The added floors did not cause three extra stake deductions. For the full feature sequence, see the bonus-floor explanations.

Frozen needs a different check. In my successful continuation, 27.50 FUN was protected before the final payout reached 68.75 FUN. The protected amount was included in that final gross. Adding the two would wrongly report 96.25 FUN. When the separate 12.50 FUN round fell after protection, the protected 31.25 FUN was the amount actually paid.

Read the settled history alongside the balance movement: a protected minimum, a running total and the final credited gross can describe stages of the same money, so several positive amounts on the screen should not automatically be added as separate credits.

A void returns the original stake without recording game winnings. My demo session included an 18.00 FUN debit followed by an 18.00 FUN refund. Its net effect was zero. For the session's settled-game return, both the void stake and its refund were excluded, rather than counting the refund as a winning payout.

A rejected request is different: a below-minimum stake was refused before acceptance and caused no debit. Pending is also different. It describes an intermediate state and cannot be classified as a loss simply because the result has not yet appeared. Acceptance, settlement and cancellation need separate entries.

After returning from the background, I read one settlement for the previously accepted 21.00 FUN stake: gross 37.80 FUN, net +16.80 FUN. Reopening the screen did not create a second credit. The server result, rather than repeated animation or another screen refresh, determines the accounting.

The demo session returned 652.00 FUN on 363.00 FUN of settled turnover, an observed return of 179.614325%. That describes this particular sample. It does not change the configured 97% RTP, certify a long-run return or establish the chance of success on the next Build.

I started with 2,200.00 FUN and finished with 2,489.00 FUN after 25 accepted cycles. One was void, leaving 24 settled rounds for the statistical denominator. The session lasted 27 minutes. All pending obligations had been resolved by the final balance, so the total was not hiding an unfinished bet.

The balance reconciles as 2,200 − 381 + 18 + 652 = 2,489 FUN. Here, 381 FUN is the sum of all initial debits and 18 FUN is the void refund. Equivalently, subtracting only settled turnover gives 2,200 − 363 + 652 = 2,489 FUN. Both routes produce the same +289 FUN net result.

A payout is not necessarily a profit. The two break-even rounds returned exactly their stakes and therefore increased the positive-gross count without increasing the profitable-round count. Likewise, a frequency counts events, whereas observed return weights their monetary sizes. The two measures answer different questions.

The mean of individual gross-to-stake ratios was 1.935417. Total gross divided by total settled turnover was 1.796143. These differ because stakes varied: an unweighted mean gives each round equal influence, while the turnover-based ratio gives more influence to larger stakes. Use the latter when asking what proportion of the wagered FUN returned.

For comparison, applying 97% to that same fixed 363 FUN turnover gives theoretical gross of 352.11 FUN and net of −10.89 FUN. The observed +289 FUN is a sample outcome, not a new configuration parameter. Keeping both figures visible makes the distinction between expectation and experience explicit.

The largest recorded payout was 68.75 FUN, but the path to the final balance included a maximum drawdown of 61.50 FUN and three consecutive rounds with zero gross. A positive ending balance therefore did not mean a steadily rising balance or the absence of losing stretches.

The sample variance of net outcomes was 421.548406 FUN², using a denominator of 23. Standard deviation was 20.531644 FUN. Variance is expressed in squared units; standard deviation returns to FUN. Both describe the spread of this sequence, not a guaranteed range for a later session.

For the proportion of rounds with positive gross, the 95% Wilson interval was 59.529547% to 90.755175%, based on 19 successes among 24 settled rounds. It is an interval for that event proportion under the calculation, not an interval for RTP, profit probability or the return on your next PKR stake.

Starting a fresh demo reset my 2,489.00 FUN balance to 2,200.00 FUN. The −289.00 FUN adjustment was a reset, not another losing round. It belongs outside game-performance statistics. A public player feed also cannot replace your own complete settled history: displayed entries and selected wins have a different scope.

RTP alone supplies neither a floor-success probability nor Temple's sector probabilities: even though the wheel contains ten sectors with repeated multipliers and Frozen, counting equal-looking sectors does not establish equal probabilities.

The separate two-outcome risk illustration uses a 0.485 probability of a 2× gross return and 0.515 of zero, which produces 97% expected return. Those inputs belong to that illustrative model. They do not reconstruct Tower Rush's floor mathematics, and should not be used as its next-floor odds.

Arithmetic reconciliation and cryptographic verification are also separate tasks. Matching your stake, payout and balance confirms the accounting relationship; it is not a full replay of the commitment and digest mechanism. The result-verification guide explains that distinction, while risk management addresses spending decisions.

Treat the 97% configuration as a theoretical cost parameter, keep PKR separate from FUN, and read gross, net and refunds as different entries. The cap and rounding explain the credited amount; the short journal illustrates accounting and variation without proving long-run RTP.

1. Open Rules and check the exact game, mode, stake grid and gross cap.
2. Read the accepted stake and settled payout in your own history.
3. Separate any void refund or demo reset before calculating return.
4. Use the round rules when you need to distinguish Build, Cashout and the next round.