Tower Rush fairness: result verification and payout calculation

How to use Key, Salt and Hash Code

In the edition described, a shield icon opens verification. Key and Salt are taken from the relevant interface, and Hash Code is then compared in the verification tool. Use data for the specific selected result and the appropriate tool, maintaining the relationship between the fields.

Preparation and comparison

1. Open the completed result you want to check and confirm the game's name.
2. Open the verification interface through the shield icon.
3. Copy Key and Salt from the fields belonging to that result.
4. Use the verification tool provided for this edition.
5. Compare Hash Code and the tool's output with the result you selected.

   

6. Separately reconcile the stake, credit and balance under the monetary settlement rules.

Do not substitute values from an adjacent round.

Copy without changing any characters. Manually shortening a string, mixing fields from two results or applying another game's procedure breaks the necessary connection to the result; if there is a mismatch, check these conditions first rather than drawing a conclusion from one number. A field name does not define a universal calculation recipe. Key, Salt and Hash Code relate to the applicable edition, while another product's specific seed, nonce, serialisation and digest conversion may work differently. The shared term Provably Fair does not make every implementation identical.

Why the Dragon Tower procedure cannot be used

Dragon Tower by Stake Originals has its own cryptographic procedure, which does not become a Tower Rush procedure simply because of the word Tower; similarly, Aviator instructions do not describe Galaxsys's original individual round.

If the tool checks different parameters or the product name does not match, return to verification for the selected edition. Do not create a random seed and present an example calculated from it as a reproduction of a real round: such an example does not prove a connection to your outcome. A full comparison cannot be reduced to a visually similar rounded multiplier. A matching displayed 1.5× helps interpret a payout, but does not itself link the prior commitment, exact inputs and final result of one cryptographic procedure.

How to reconcile a payout without replacing the cryptographic test

Reconcile the credit using the initial stake, accepted multiplier, bonus states, cap and balance movements: this reproducible arithmetic reveals double-counting or mixed amounts while leaving Key/Salt/Hash Code comparison as a separate task.

Gross credit and net result

With a stake of 10 FUN and an accepted Cashout at 1.5×, the gross credit is 15 FUN and the net result is 5 FUN. The initial stake is deducted first, followed by the credit; calling all 15 FUN profit would ignore the original cost.

I reconciled this exact sequence: one debit of 10 FUN and one gross credit of 15 FUN. The check connects the stake, multiplier and final balance. It is not a claim of a new cryptographic experiment and does not turn demo units into real bank income. Separate gross and net even when exactly the stake is returned. A credit of 10 FUN after a stake of 10 FUN gives net 0, not a profit of 10 FUN. A positive payout and a profitable round are different categories; this distinction matters when reading overall statistics.

Frozen Floor and the absence of double credit

Frozen Floor protects the locked amount but does not add it again to a higher successful exit. Starting with 10 FUN, protection at 2× and a later Cashout at 5×, I received a gross credit of 50 FUN and a net result of 40 FUN. A total of 70 FUN here would be double-counting: the protected 20 FUN is not a separate extra reward on top of the 50 FUN result. Protection defines the lower retained result in the relevant state, while a successful exit above it completes the same round with one larger payout.

If a fall had occurred instead of an exit after the same protection, the calculated alternative would be 20 FUN gross and 10 FUN net. This is a hypothetical explanation of the rule, not another round played by the author; the actual credit and alternative scenario cannot be added together.

Temple, Triple and the credit limit

Temple applies the segment multiplier to the amount already accumulated. With 15 FUN and a 3× segment, the result is 45 FUN. Having ten segments does not mean each necessarily has a 10% probability: repeated labels and outcome probabilities describe different wheel characteristics. In the Triple example, the initial 10 FUN is multiplied successively by 1.2, 1.25 and 1.6. The result is 24 FUN, with a net result of 14 FUN. Three extra floors do not mean three new initial stakes of 10 FUN and do not justify tripling turnover.

For an uncapped result of 11,250 FUN, the demo cap leaves a gross credit of 10,000 FUN. The Maximum Win warning therefore marks the result limit and does not allow payouts to grow indefinitely by continuing to build.

The balance as a cross-check

The completed demo log contained 17 accepted cycles, including one void, and 16 settled without cancellation. Initial debits totalled 127.50 FUN, the refund was 7.50 FUN, comparable betting turnover was 120 FUN, and gross game payouts were 187 FUN. Starting with 1,000 FUN, the final balance is 1,067 FUN: 1,000 − 127.50 + 7.50 + 187. The net result of +67 FUN is also obtained as 187 − 120. The two matching calculations show that the voided stake refund has not been counted as an extra win.

I then opened a new demo session with 1,000 FUN. The difference from the previous 1,067 FUN belongs to the demo balance reset, not another loss. Without separating sessions, this change in starting balance could easily be mistaken for incorrect game settlement.

Accepted, pending and voided rounds

Read the history by round status: before server acceptance, submission is not yet a debit; after acceptance, a temporary disconnection is not yet a loss; and void means cancellation with a refund, not an ordinary positive payout.

In the original round with a stake of 10 FUN, server acceptance followed 240 milliseconds after Build was sent. Pressing again before the response did not create a second bet. Animation cannot be the sole reference for when a monetary commitment is accepted. I returned to the game after 45 seconds in the background: the previous 10 FUN stake remained a single stake, and the 15 FUN result remained a single credit. While settlement was pending, it was tracked separately; after recovery, no new bet was needed to “close” the previous one.

In the event of a hardware or software malfunction, the applicable rules provide for voiding the relevant bets and payouts and returning the stake. In a separate void episode, 7.50 FUN was returned, restoring the balance without increasing profit; this refund is excluded from the 187 FUN in game payouts. If the connection is not restored within an hour after acceptance, the rules describe completion after an hour of inactivity, with recorded winnings credited. This is a state-handling rule, not a promise of guaranteed profit from disconnecting; the result already belongs to a server-side round.

When investigating an issue, retain the relevant round ID, amount, status and movements in your own balance. Other players' public feed does not replace this record. Restore the existing event's history first, then raise a query about it without creating repeated risk through a new bet.

What successful verification does not prove

Verifying a completed result cannot predict the next floor or guarantee profit when a bet is repeated, turn a short sequence into mathematical proof of RTP, or establish the speed of an operator's external withdrawals.

In the demo log, 9 of 16 settled cycles had a positive credit, while 8 of 16 were profitable. The sample's monetary return was 187 / 120 × 100 = 155.8333%. This describes a short log, not a new game RTP or a promise that the next player will receive that percentage.

For a configuration with RTP of 97%, the house edge is 3%, but this is not the probability of falling on any chosen floor. The RTP and mathematics analysis separates expected results from event frequency; one quantity cannot be substituted for the other. Licensing and bank transfers fall outside game-result verification. For a player in India, a correct hash does not replace operator terms, territorial restrictions or cashier requirements; these questions are addressed in the legal section.

Promises of signals and “knowing the next floor” should be assessed separately from Provable Fairness itself. The presence of a verification interface does not confirm such promises; these claims are examined on the predictor page.

Practical conclusion

Use Key, Salt and Hash Code only for the appropriate result in the original Tower Rush, and check monetary arithmetic separately. The history of acceptance, recovery and voids helps explain the balance; successful reconciliation does not predict the future or guarantee an external payout.

This approach keeps each conclusion verifiable: the PF interface concerns the result, gross/net concerns the credit, and the cashier concerns withdrawal. The general methodology explains the separation of sources, the author's episodes and calculations; the home page connects them with the game's other characteristics.