Tower Rush fairness from round hash to payout

What Tower Rush fairness covers

Tower Rush fairness involves both generating a result and checking how it was produced. Galaxsys says the original game uses a random number generator (RNG) and offers Provable Fairness. The verification procedure uses the inputs and published records for a specific round after play.

The first piece of evidence is the commitment published before the server accepts the stake. Think of it as a fingerprint for data fixed in advance. Once the corresponding input is disclosed, you can apply the version's commitment algorithm and compare the result with the value published before acceptance. The timing matters. A value first presented after settlement gives you a hash to compare but cannot establish that the same commitment was in place before the server accepted the stake.

The final digest answers a different question about Tower Rush fairness. It is computed from the exact bytes encoding the round's fixed inputs. To connect the digest to the floor event shown in play, apply the version's rule for extracting a number from the digest, then its rule for mapping that number to a game result. The game rules for Build and Cashout explain how a recorded floor event affects the amount in play.

Where to find Key, Salt and Hash Code

Open the shield panel in the original game's interface to reach the hash check. Key, Salt and Hash Code are interface labels. Use the protocol for your version to identify what each value represents and where it belongs in the calculation.

1. Open the shield panel. Keep the round ID from the game history with the values you copy.
2. Copy the full Key and Salt as displayed. Preserve their order and exact characters when entering them into the checker reached from the panel.
3. Compare the checker output with the displayed Hash Code. For the separate full-digest check, use the complete digest for the same round ID.

An exact match at this stage tells you that the checker produced the displayed hash from the inputs it took. For a complete check, establish the earlier commitment and reproduce the outcome separately. If you are looking at a different client, start by checking which game is the Galaxsys original.

How to reproduce a round from its inputs

To verify a Tower Rush result, follow the protocol for the exact round and version. A verification record needs to preserve both when the inputs were fixed and how the calculation turned them into an outcome. The round ID connects those records to the result in history.

1. Recreate the commitment. Check that the recorded publication precedes server acceptance. Use the applicable commitment algorithm and the input it commits to. Compare the full recalculated value with the one published before the server accepted the stake.
2. Rebuild the round input. Check when the complete inputs were fixed. Assemble the values in protocol order and encode them exactly. Field order, a separator and a trailing space all affect the bytes fed into the calculation.
3. Recompute the digest. Use the final digest algorithm defined for the round's version. Compare the full output to the one tied to that round ID. An algorithm used by a different game can produce a perfectly valid hash of its own input while answering a different question.
4. Replay the outcome mapping. Extract the number as the protocol specifies, then apply the mapping for that version. Compare the resulting game event with the recorded event before applying the payout rules.

A match on the commitment checks that the revealed input agrees with the commitment published before server acceptance. A match on the final digest checks the calculation from the fixed inputs. A match on the mapped outcome links that calculation to play. None of those comparisons measures how often the generator produces each kind of event over many rounds. Galaxsys and the game's origin identify the provider and product to which the mechanism belongs.

How to check what the round paid

Start with the accepted stake, the recorded floor events or Cashout, the round status and the cap for that configuration. Gross is the game's final payout before subtracting the stake. Net accounts for the stake and any refund. The credit that follows an ordinary Cashout and the refund that reverses a void serve different purposes, even when the balance moves by the same amount.

FUN demo balance and payouts

On a Samsung Galaxy S25 FE, I logged 24 accepted Build cycles in a FUN demo session. Of those, 23 settled and one was voided. The initial 750.00 FUN balance moved through 254.00 FUN in stake debits, a 4.00 FUN technical refund and 283.44 FUN in payouts to close at 783.44 FUN. Comparable turnover was 250.00 FUN after excluding the void, and the session net was +33.44 FUN. The balance reconciles using those movements alone.

I recorded a positive payout in 13 of the 23 settled rounds, while 12 finished with a profit. The difference was a Cashout that returned exactly the stake. A positive credit can therefore belong to a break-even round, and the void belongs outside both counts.

The demo returned 113.376% of comparable turnover in that session. That percentage describes the stakes and payouts in the session. The demo profile uses 97% RTP as its theoretical benchmark for repeated play. A session above that figure can occur with correctly calculated payouts and says little about how the next round will end. The RTP and payout maths explain the difference between these denominators.

FUN and EUR settlement cases

The table compares FUN payouts and refunds, a separate EUR cap calculation and checks on acceptance or settlement status. Read the cap, rounding and final status within the stated case.

Frozen Floor locks the accumulated amount as protection. In the demo I recorded a 12.50 FUN stake that reached a protected 2.5× before a fall. It paid 31.25 FUN gross, for a net gain of 18.75 FUN. If a subsequent successful floor instead leads to Cashout, the resulting gross already includes the protected amount. Adding the protection again would count part of the same payout twice.

Temple Floor applies a multiplier when the wheel lands on a multiplier sector. The Frozen sector protects the current amount instead. For Triple Build, the extra floor multipliers also belong to the same accepted stake. In one demo cycle I logged three multipliers of 1.2×, 1.25× and 2× on a 3.50 FUN stake. Their product was 3×, for a single gross payout of 10.50 FUN. By contrast, the EUR cap example shows why a displayed 64× raw result and a paid 50× can both be correct. The cap limits the amount credited. Automatic settlement at the cap is a separate rule.

Which record to use after a disconnect

Use the original round ID and the server's acceptance and settlement records. I logged a demo round in which a 4.00 FUN stake took the balance to 759.90 FUN before a technical void. The full refund restored it to 763.90 FUN and the round contributed zero net. In an accepted round with a confirmed payout, reopening history should instead bring back that settlement.

1. Open History and find the original round. If you only have the request ID, use it to trace whether the server accepted the Build.
2. Check the debit first, then look for the final status and either the payout or the refund. A pending entry is an open obligation until the record shows how it closed.
3. Compare the final credit with the balance change for that round. Use the same round ID when you reopen history so that you can distinguish the existing settlement from a new wager.

An accepted round closes after an hour of inactivity if the connection never returns. A recorded win goes to the game balance automatically, so the round history is the record to check.

If the hash comparisons agree and a balance still looks wrong, the stake, credits and final status are the records to reconcile. An in-game Cashout settles the game cycle. Withdrawal from a cashier is a separate transaction.

What a hash check means in France

For readers in France, a matching hash concerns the game record. Authorisation to offer a product is a separate question for the Autorité nationale des jeux (ANJ). The ten operator profiles considered here offer no authorised real-money route for the original game in France. Betclic France's approved categories are sports betting, horse-race betting and poker.

Use the FUN demo if you want to inspect the game without a monetary stake. Keep an example denominated in euros in its accounting context. A B2B supply licence concerns the supplier's activity in the stated jurisdiction, while the relevant French operator and category are listed in the ANJ register of authorised operators.

What to check first

Pick the record that answers your question. For the game result, check the commitment published before acceptance, the full digest and mapped outcome for the same round. For the payout, start with the stake, credited amount and final status. The methodology for checking game records explains how those forms of evidence are kept separate.

FAQ