Legend of the Nile God Trails and cluster evidence guide

Legend of the Nile is documented by Betsoft as live from 11 December 2017. Its public specification gives a six-by-six grid, cluster pays, 95.63% RTP, high volatility and a 34.32% hit rate. Winning groups explode and replacement symbols drop into the empty positions.

The distinctive part is a trio of God Trails. Isis and Anubis accumulate from wins involving their symbols and retain progress between sessions. Ra also advances from Ra wins, but Betsoft says the Ra meter returns to zero after every spin. Treating all three meters as persistent would therefore misrepresent the rules.

Verified game record

Field	Official value	Evidence needed from the live build
Listed launch	11 December 2017	Build or rules version
Grid	6 × 6	Visible cell arrangement
Win method	Cluster pays	Minimum cluster and adjacency rule
Reaction	Winning symbols explode	Maximum or natural cascade end
RTP	95.63%	Active configuration value
Volatility	High	Current label
Hit rate	34.32%	Definition used by this build
Persistent meters	Isis and Anubis	Saved progress after re-entry
Per-spin meter	Ra	Reset point and award thresholds

Identify the correct configuration

Open Help and capture the game name, Betsoft, RTP, grid, cluster rule, stake, currency and version indicator. The official product page establishes the provider’s published model, but it does not establish the exact build in an operator lobby.

If the loaded RTP differs from 95.63%, retain both values with their sources. Do not describe a mismatch as an error until the operator’s rules and configuration are checked; providers can support more than one approved setup.

The product page does not confirm access in New Zealand or at 22Bet. A reader must find the title in an eligible authenticated account. The commercial links on this page lead to a sponsored destination, not to an embedded Legend of the Nile demo.

Cluster wins on a 6x6 grid

The provider confirms cluster pays but does not publish the full adjacency and award table in its searchable page text. The active Help file should state the minimum group size, whether diagonal neighbours count and how a cluster’s value is calculated.

Number rows from top to bottom and columns from left to right. For an observed win, list every coordinate in the cluster. A screenshot alone can hide whether two nearby groups share an allowed edge, so a coordinate record makes the claim reproducible.

Do not call every touching set a win. Some cluster engines require horizontal or vertical contact and exclude diagonals. The exact rule belongs to the paytable, not to a generic explanation of cluster slots.

Exploding wins and replacement sequence

Betsoft states that triggering symbols explode and new symbols drop into their places. Record the initial grid as step zero, then save each subsequent grid until no further award appears.

For every step, capture the winning cluster, its credit, removed cells and incoming symbols. Use a separate running total rather than reading only the final celebration screen. This reveals whether multiple clusters were evaluated together or sequentially.

An exploding sequence is not automatically a multiplier ladder. The official page confirms replacement chances but does not say that a rising multiplier applies. Add a multiplier column only if the current Help file documents one.

The Isis Trail

Every winning combination of Isis symbols contributes to the Isis Trail and its free-spin stake amount. Betsoft says the trail retains its fill level between game sessions. Save the meter before the spin, the number of qualifying Isis symbols, the new meter and any change in accumulated stake.

Progress and stake are related but not identical fields. A trail may advance by one unit while its stored free-spin stake changes according to the wager attached to the qualifying win. Preserve both values exactly as displayed.

When Isis Free Spins begin, record the awarded count and the stake used for every spin. The provider says each feature spin uses the stake matching the amount accumulated before the trigger. Compare the displayed feature stake with the saved trail total rather than assuming it equals the most recent base wager.

The Anubis Trail

Anubis wins fill a separate trail and contribute to their own free-spin stake. Its progress also survives between sessions according to Betsoft. Build a ledger independent from Isis even when both gods appear in the same cascade.

Use one row per exploding-win step because an Anubis cluster can occur after replacements rather than on the first grid. Note the qualifying symbols, credit, meter increment and accumulated feature stake.

At the trigger, preserve the before-and-after meter states and the free-spin rules displayed. Do not import Isis feature behaviour into Anubis merely because both trails persist. The official overview groups them at a high level, while the live paytable should define each award.

The Ra Trail resets differently

Every win made from Ra symbols fills the Trail of Ra, and larger Ra participation accelerates it. Unlike the other two trails, the Ra meter returns to zero after every spin. Here “spin” should be checked against the complete exploding sequence: determine whether the meter survives cascades within one paid round and resets only after settlement.

Betsoft lists possible Ra outcomes including additional free spins, an award of 400 times total stake and a progressive jackpot. These are possible thresholds, not a prediction that any session will reach them.

Capture the Ra meter after each cascade and immediately after the round ends. This establishes when the reset occurs. Never carry its displayed progress into a new session ledger as though it were saved value.

Simultaneous gods in one chain

A cascade sequence may contain qualifying wins for more than one god. Record each trail change at the exact step where it occurs. If Isis and Ra clusters clear together, retain separate entries linked to the same grid identifier.

Watch how the interface orders animations. Animation order does not necessarily equal settlement priority, so compare the meter totals before and after the complete step. The account history may show only the monetary award, making screenshots of the meters especially useful.

If a trail triggers while replacements could still fall, document whether the cascade completes first or the feature starts immediately. The public product text does not specify that edge case.

Persistent progress across sessions

To verify persistence without unnecessary wagering, note the Isis and Anubis values at a natural stopping point, exit normally and reopen once. Match the account, title and version before comparing values.

Do not use another user’s screenshot or another operator as proof. Persistence can depend on the account record and build. If progress disappears, save timestamps and contact support with the title and round IDs rather than trying to recreate the meter through additional play.

Ra provides a useful contrast: its meter is designed to reset after each spin, so a zero value on return is not evidence of lost persistent progress.

Progressive jackpot wording

Betsoft identifies a progressive jackpot as one possible Ra Trail result. A progressive amount changes over time and may belong to a network, operator or currency presentation. Quote a figure only with a timestamp, currency and on-screen source.

Do not convert the displayed amount into New Zealand dollars unless the game itself uses NZD or a clearly dated conversion is supplied. A decorative jackpot banner is not the same as a confirmed payable amount.

The 400× total-stake outcome is a separate listed possibility. Do not merge it with the progressive value or present it as a maximum-win specification for the whole game.

RTP, hit rate and high volatility

The 95.63% RTP describes theoretical long-run return for the listed configuration. It cannot predict what one cluster chain, trail cycle or session will return.

The 34.32% hit rate does not mean 34.32% profitable spins. A hit can be smaller than the wager, and a provider may count cascades or feature events according to its own method. Use the live definition if one is shown.

High volatility signals that results may be uneven relative to lower-volatility designs. Persistent meters can make progress visible, but they do not make future outcomes certain. A partly filled trail should not override a pre-set spending limit.

Mobile checks

On a phone, verify that all 36 cells remain distinguishable and that the three meters can be opened or viewed without covering the grid. Check whether trail values use colour alone; labels or icons should also identify the relevant god.

During an exploding sequence, confirm that the interface preserves the step total and does not obscure replacement cells with animation. Test the Help panel in portrait orientation and ensure cluster rules, RTP and feature stake wording remain readable.

If the connection drops during a cascade or trail trigger, reopen via the account lobby. Compare the restored grid, trail values and transaction history with the saved pre-interruption state before initiating another round.

Evidence checklist

• Match Legend of the Nile and Betsoft in Help.
• Compare the active RTP with 95.63%.
• Save the cluster-size and adjacency rules.
• Number every 6x6 coordinate consistently.
• Record each exploding-win grid and credit.
• Maintain separate Isis, Anubis and Ra ledgers.
• Verify Isis and Anubis persistence after one re-entry.
• Observe the Ra reset point within a complete round.
• Save the feature stake used when a trail completes.
• Date any progressive jackpot display.

Confirmed facts and unresolved fields

Betsoft confirms the date, 6x6 layout, cluster pays, exploding wins, RTP, volatility, hit rate, three named trails, persistent Isis and Anubis progress, per-spin Ra reset and the possible Ra awards described above.

The public page does not fully expose the paytable, minimum cluster size, diagonal rule, exact trail thresholds, free-spin counts, feature-stake formula detail, maximum award, stake range, current jackpot value, alternative configurations or territorial availability. Those fields remain live checks.

Reader fit

Legend of the Nile is most useful to analyse for readers who enjoy stateful mechanics and are willing to keep three distinct records. Its official rules make the central differences visible, but the interface still needs to be checked for thresholds and stake calculations.

This is an evidence guide, not a promise of access or profit. Persistent progress can encourage longer sessions, so adults should set time and money boundaries before watching the trails advance.

Editorial conclusion

Trail-state audit table

Use one row per cascade step, not merely one row per paid spin. Suggested columns are round ID, cascade number, winning god symbol, cluster size, cash award, trail before, trail after, accumulated feature stake before and accumulated feature stake after. Keep a separate table for each god.

At the end of the paid round, add a state snapshot containing all three meters. The Ra value should then be compared with the next round’s opening state to test the provider’s reset statement. Isis and Anubis values should be compared after one normal exit and re-entry.

If the interface expresses progress as a graphic rather than a number, record the visible segment count and attach a screenshot. Do not estimate a percentage from the apparent length of an animated bar unless the rules define equal segments.

Feature-stake accounting

Betsoft’s public wording makes accumulated stake important for Isis and Anubis free spins. A credible review must distinguish the paid stake on the trigger round, the amount stored along the trail and the stake used within the awarded feature.

Create three fields rather than one generic “bet” column. If the trail accumulates contributions from rounds placed at different stakes, record each increment. At the trigger, compare the feature display with the saved total and note any rounding or denomination conversion.

Do not call the stored amount a withdrawable balance. It is part of the feature’s calculation unless the active rules say otherwise. Likewise, visible trail progress is not money already credited to the account.

Cluster-chain example without invented payouts

Suppose an initial Isis cluster clears, replacements create an Anubis cluster, and a final drop contains a Ra cluster. The correct record contains three grids and three trail updates linked to one paid round. It does not collapse the chain into “all gods advanced together.”

The example should leave award values blank until the live paytable supplies them. Its purpose is to demonstrate event order: initial state, first removal, first replacement, second removal and final settlement. This order matters when a trail completes partway through the chain.

If two qualifying clusters exist on the same grid, note whether the game removes them simultaneously. Use the interface and Help rather than imposing a sequential model that the game does not use.

Session-boundary risks

Persistent meters can create the impression that leaving would waste prior activity. Betsoft explicitly says Isis and Anubis progress survives between sessions, so a reader should not feel compelled to continue solely to preserve the visible fill level.

Verify persistence once, document it, and then treat the saved meter as future feature state rather than recoverable money. The next outcome remains random, and completing a trail can still produce a feature result below the amount spent while advancing it.

Set a stopping time independently from the three meters. Ra will reset by design, while the other two should remain stored in the documented version; neither behaviour justifies exceeding a personal limit.

The game’s identity comes from three meters that share a theme but not a lifecycle. Isis and Anubis preserve progress; Ra builds and resets inside a spin. A credible review must preserve that difference and show how exploding clusters feed each record.

Once the live Help file supplies cluster thresholds and trail awards, a coordinate log and meter ledger can reconstruct the experience without leaning on promotional language.

FAQ

What RTP does Betsoft publish for Legend of the Nile?

The official product page lists 95.63% for its documented version.

Which trails persist between sessions?

Betsoft says the Isis and Anubis trails retain their fill levels between game sessions.

Does the Ra Trail persist?

No. The studio states that the Ra meter returns to zero after every spin.

How are wins formed?

The title uses cluster pays on a 6x6 grid, followed by exploding symbols and replacements.

Is a current progressive amount confirmed here?

No. Any displayed amount must be recorded with its currency, source and timestamp in the live game.

Sources

• Betsoft, Legend of the Nile, official product page, checked 9 October 2026.
• Betsoft, Walk with the Gods in Legend of the Nile, official release article, checked 9 October 2026.

How to verify the version you can actually open

A provider page proves that a title exists and describes the supplier's intended rules. It does not prove that a casino accepts players in New Zealand, that the title is enabled for a particular account, or that the highest published RTP is the version in the lobby. Treat availability, operator eligibility and product configuration as three separate checks.

Start with identity, then configuration

Open the game only through the authenticated casino lobby. The information or help panel should identify Betsoft, the exact title and the active mathematical return. Compare the reel or grid layout, paylines or cluster rules, named features and symbol behaviour with the official product material. Similar artwork or a matching title is not enough when the help file is missing or inconsistent.

When the supplier publishes several RTP values, report all of them as configurations. Do not assume the highest option is deployed. RTP is a theoretical long-run measure across a very large number of rounds; it is not a refund rate for one player and cannot predict the next result. Volatility is different: it describes how unevenly results are distributed on the provider's scale.

Read stake controls as money, not interface decoration

Provider sheets often quote a reference range in euros. That range does not establish New Zealand-dollar support or the limits in a specific account. Before a paid round, identify the total amount that will leave the balance. If the interface separates denomination, coins and lines, verify the combined total. If Extra Bet is active, calculate its full cost before pressing spin.

Feature-buy prices are multiples of the current bet, not promised returns. A 100x purchase at a $1 stake costs $100; at a $2 stake it costs $200. Availability can vary by market and some mathematical configurations may not support the control. If the live help does not explain the price, delivered feature and active RTP, leave the option unused.

Keep simulation figures in their proper scope

A game sheet may publish a maximum result observed in a large simulation. That is not automatically the contractual maximum payout and never describes a likely session. Preserve the provider's wording, sample size and configuration. Check the live rules for a binding cap and the operator terms for any separate payout limit. Do not turn an extreme result into a promotional headline.

Audit a disputed round

If an animation freezes or a connection drops, do not repeat the wager immediately. Reopen the game through the authenticated lobby and inspect round history. Record the time, total stake, balance movement and round identifier. The result can be settled by the gaming system even when the device never displays the final animation. Send evidence through verified operator support; never disclose a password, recovery phrase or one-time code.

Read the paytable as a calculation document

The paytable should explain what creates a win, which symbols substitute, where special symbols can land and how multiple awards combine. For line games, confirm direction and active paylines. For cluster games, confirm adjacency, minimum group size and the order of collection. For respins, identify what remains locked, what resets the counter and what ends the feature. A graphic effect can illustrate those rules but cannot replace them.

Separate addition from multiplication. Several prize values may be added before a multiplier applies, while reel-specific multipliers can sometimes multiply together only when each reel participates in the same win. Reconstruct one low-stake result from game history. If the arithmetic cannot be matched to the help file, stop and ask the operator rather than guessing.

Do not confuse hit frequency with a profitable round

Provider sheets can publish hit frequency or category probabilities. A hit simply means a round returned a qualifying amount; it can be smaller than the stake. “Big”, “Mega” or “Epic” thresholds are provider reporting categories, not promises. They are useful for comparing mathematical versions only when definitions and samples are the same.

Random outcomes do not become due after a long gap. A feature that appeared repeatedly in a demo or marketing clip has no obligation to repeat in a funded session. Previous rounds do not create a debt from the next random result.

Confirm market and device behaviour independently

A title can exist in the supplier catalogue while an operator disables it for a territory, currency, device or bonus. Language localisation is not evidence of legal availability. Confirm the operator's identity, accepted countries and current lobby separately from the provider review.

On mobile, verify that balance, total bet, feature state and help remain visible without overlap. On desktop, check that browser zoom does not hide a purchase control or change the apparent denomination. Mathematical configuration should not change merely because the screen changes; if the help shows another RTP, treat it as a different deployment and record it.

Keep a compact evidence record

For any fact used in a review, save the title, provider, official URL, document date when available, access date and exact territorial scope. For a live session, add the operator domain, Game ID, RTP, currency and a non-sensitive screenshot of the help panel. This makes later corrections possible when a supplier updates a sheet or an operator changes configuration.

Missing information should remain missing. Do not estimate an RTP from results, convert a euro reference range into an operator's NZD limit, or treat another casino's configuration as evidence. A transparent “not confirmed” is more useful than a precise-looking number without the correct source.

Use limits that survive the feature design

Collection meters, expanding grids, sticky symbols and near misses can make a session feel unfinished. Unless the rules explicitly preserve progress, the visible state has no value after the round or feature ends. Set a money limit and time limit before launch, count feature buys immediately, and stop at the limit even when a meter appears close to an upgrade.

No random game is an income plan. Do not borrow, use essential funds or raise the stake to recover a loss. If play stops feeling recreational, use timeout, deposit-limit or self-exclusion tools and consult the site's responsible gambling guide.