We read the JavaScript three crypto casinos ship to your browser and recomputed the house edge from their own game specifications. Duel: a 91-step staircase. Rainbet: geo-blocks drawn in the browser. Gamdom: 0.99% on roulette, up to 1.25% on HiLo.
A provably fair game cannot hide its odds, but it can change them. Seed verification proves a round was not altered after you played it. It says nothing about the price of playing, because the price sits in the multiplier, and the multiplier is set by a house edge the operator picks.
So we read the operator’s own dice client. The hook builds an API client on api/v2/dice and fetches config; that endpoint is public and needs no account. What comes back is a table of 122 win-chance brackets, each holding up to 91 bet tiers, each tier carrying its own house edge. The values run from 0.1% to 1.0% — the same game, the same chance of winning, priced ten times apart.
The client selects a bracket by win chance, then a tier inside it by stake, and reads house_edge from that tier. When nothing matches it falls back to 0.001. The payout follows directly: multiplier = (1 − house_edge) / win probability.
Nothing about this is hidden in the sense of being encrypted or obfuscated. It is simply not stated anywhere a player would look, and the numbers are not shipped in the page — they are fetched, which means they can change without any visible update to the site.
The operator describes this as an edge based on the size of your bet. Computed across all 122 brackets, the first tier boundary corresponds to a potential profit of roughly $25,000 — median $24,996, range $24,722 to $25,008 — regardless of the win chance chosen.
That is why a $461 bet at a 1.81% win chance and a $24,072 bet at a 49.01% win chance cross the same line. Both stand to win about $25,000. The edge then climbs through 91 steps and tops out near $250,000 of potential profit.
Capping exposure rather than capping customers is a defensible way to run a book, and we say so on the page. The gap worth reporting is between the mechanism and the sentence describing it.
The payout tables for Plinko, Keno and Mines are not in the bundle at all. The client requests them. The same scaling_edge structure appears in the Keno, Mines and Plinko hooks, and Cross Road carries a house_edge_multiplier, so the pattern is not specific to dice.
One observation we deliberately did not turn into a claim: round results carry both multiplier and no_house_edge_multiplier, and the client renders the second when present. The likely reading is that it picks whichever applied to that round. We did not confirm it, so that is all we say about it.
The second operator we read does not expose a game configuration endpoint we could reach, so this section is narrower: it describes what the shipped bundle does, not what a server returned. Rainbet is a Next.js application, and the hook that handles geography sits in the same chunk that exports fetchPublicIP. It requests v1/public/ip and branches on a conditions field that takes the values restricted and blocked.
Both verdicts are handled in the browser after the page has already loaded. A restricted visitor gets a modal with a close handler that writes their country into the ignore-restrictions key in localStorage; on the next visit a guard sees the stored country and returns before the modal is ever built. A blocked visitor gets the same modal without the close handler. The check is a user-interface layer, not an access control at the edge — which is a statement about where the check runs, and not a claim about deposits, wagers or withdrawals, none of which we tested.
The whole branch is wrapped in one condition: if the visitor is not a bot. Bot status is decided by matching the user agent against a pattern covering googlebot, googleother, google-extended, apis-google, feedfetcher-google, google-read-aloud, chrome-lighthouse, bingbot, yahoo slurp, duckduckbot, baiduspider, yandexbot, sogou, exabot, facebot and ia_archiver. When the pattern matches, no modal and no popup is created and the page renders as though no restriction existed.
We are not alleging cloaking, and we think the likely reason is mundane: a modal in server-rendered HTML would harm indexing. The observable consequence is still worth writing down. The version of Rainbet that search engines index and cache is the unrestricted one, and the restriction notice is absent from everything a crawler stores. The same crawler test appears elsewhere in the bundle, skipping the support chat widget and hiding a sign-in prompt.
Rainbet describes its Originals as provably fair in-house games including Plinko, Mines and Dice. They are not served from the main origin. The bundle references dedicated services at originals.rainbet.com, crash.rainbet.com, roulette.rainbet.com and case-battles.rainbet.com.
As with the first operator, no payout table and no house-edge figure ships in the browser bundle. The numbers live server-side. That means they can be changed without deploying a new front end, and that no visitor can audit them from the client alone. This is the finding that repeats across both casinos we have read, and it is the reason the provably fair badge answers a narrower question than most players assume.
The third casino in this series is the one that made the series worth writing. At Duel and Rainbet the payout maths was not in the browser at all - the client asked a server for it, so nobody outside the company could audit it. Gamdom ships the whole specification in the game bundle: how the deck is built, what counts as a win, how profit is derived from win chance, the salt that seeds the outcome mapping, and the committed game hash. We reimplemented it and recomputed the house edge independently.
The payout functions read, verbatim: for HiLo, profit = floor(100 x (0.99 / win chance - 1)) / 100; for roulette, profit = (101 - 1 - slots) / slots. The 0.99 is a 1% house edge written in as a constant. The roulette formula does not state an edge at all - it derives one from the shape of the wheel.
The wheel has 101 slots: 0 green, 1 to 50 red, 51 to 100 black. Red and black each win 50 of 101 and pay even money, returning 100/101. Green wins 1 of 101 and pays 99 to 1, returning 100/101. The house edge is 1/101 = 0.9901% and it is identical on all three bets.
That is worth stating plainly because it is better than the operator claims for itself - its own configuration rounds the figure to 1% - and because the physical game it is named after is not so even-handed. European roulette charges 2.7027%, American roulette 5.2632%, and on an American wheel the five-number bet is worse than every other bet on the same layout. Here there is no such trap.
HiLo uses an 800-card deck: 33 copies of each of 12 ranks in two colours, plus 8 jokers, where a joker wins only the joker bet. Every fixed bet - red, black, 2-9, JQKA, KA, A, joker - lands on exactly 1.0000%. That is not luck. The deck is sized so that 0.99 divided by each win chance falls on a clean two-decimal number, which is why the deck has 800 cards rather than 52. It is deliberate and it is good engineering.
The hi and lo bets are the exception, because their win chance depends on the card already showing. When 0.99 / p - 1 is not already a two-decimal number, the floor operation cuts the remainder, and it always cuts the same way. Betting hi after a 6 wins 57.75% of the time; the exact profit is 0.7143 and the client pays 0.71, which is a house edge of 1.2475% - a quarter more than the formula states. Six of the 22 playable hi/lo positions exceed 1%, four of them at 1.2475% and two at 1.0825%.
This is a rounding artefact rather than a hidden fee, and the sums involved are fractions of a percent. We report it because it is measurable, because it always resolves in the same direction, and because being measurable is the entire point of publishing a specification.
Each game carries a published salt and a committed game hash over a chain of one million rounds. We checked both salts against a public block explorer. The HiLo salt is the hash of Bitcoin block 496369, mined on 27 November 2017; the roulette salt is block 453235, mined on 16 February 2017. Anyone can confirm that in a single request, and using a block hash means the constant is public rather than something the operator invented.
What it does not prove: both blocks predate the chain in use, so the salt is a fixed public constant rather than a commitment to a value nobody could know in advance. The security of the scheme rests on the game hash - the chain terminator - having been published before play began. The client shows the hash but cannot show when it was first published, and we did not attempt to establish that.
Gamdom markets a zero house edge mode, and our register carries 100% RTP entries because of it. The client configuration shows the mode is bounded: capped at $1,000 a bet, with HiLo restricted to between $0.10 and $10. Alongside those caps sits a per-game table of house edge percentages - 1% for most originals, 0.57% for blackjack, 2% for towers.
That makes our own register wrong. We were describing a capped promotional mode as though it were a property of the base game. Those entries are being requalified, and the figures on this page are what the base games actually charge. We put this in the same document as everything else because a page that audits other people and not itself is not an audit.
Three operators, and different evidence for each. The staircase numbers come from a single casino’s dice configuration, read on 16 August 2026 from a public endpoint. The Rainbet section rests on static analysis of shipped code only: its API sits behind a bot challenge, and working around bot protection is outside what we are willing to do, so we describe what the code does rather than what a server answered. The Gamdom figures are the strongest of the three, because they are not reported values at all - we reimplemented the published specification and recomputed them, and anyone can repeat that.
It is a snapshot of a server-controlled table, so it can differ tomorrow. It is also not an accusation: an edge that scales with exposure is ordinary risk management. And nothing was wagered to produce it — a public endpoint, one GET request, no account.
Our register carries 25 in-house game entries declaring 100% RTP, meaning zero house edge, across three operators. This research is what that claim looks like when you follow it into the code: real, and bounded by a staircase nobody publishes.
Auditing those declarations also turned up 58 entries of our own where RTP and house edge had been stored in the wrong fields, leaving games listed as returning 2% to the player. We corrected them, and we mention it here because a research page that only audits other people is not an audit.
No. Provably fair proves that a specific round was generated from a seed pair committed before you played, so the operator could not change the outcome after the fact. It says nothing about the house edge applied to the payout, which is a separate number the operator chooses and can vary.
It is neither illegal nor rare in crypto casinos, and it has a rational purpose: it limits how much the operator can lose on a single round. What makes it worth documenting is that the scale is not published, so a player cannot tell which edge they are paying.
Request the game configuration endpoint the client uses and read the scaling_edge object. It is a plain GET, needs no account, and returns the full table of brackets and tiers. The exact URL and command are on this page.
We only report operators whose code we have read ourselves, and there are three on this page so far. Two of them keep the payout maths off the client entirely, so it can change without any visible update and no visitor can audit it. The third publishes the whole specification, which is why its section contains computed figures rather than quoted ones. Whether the specific staircase exists elsewhere we do not know and will not guess.
Not by itself. Skipping a modal for crawlers is a common engineering choice, because an overlay in server-rendered HTML damages indexing. We describe the effect without assigning intent: the indexed copy of the site does not contain the country restriction that a person in that country would see.
Of the three we have measured, Gamdom roulette at 0.9901% on every bet is the lowest figure we could verify ourselves, and Gamdom HiLo is exactly 1% on its fixed bets. We cannot rank the other two against it, because their payout tables are not published - that is the point of the comparison, not an omission from it.
A restriction enforced in client-side code is by definition under the client’s control, and one of the two verdicts is explicitly dismissible and remembered in localStorage. We did not test any bypass and do not publish one. Where a check runs is also not the same question as what the operator enforces on deposits, wagers or withdrawals, which we did not examine.