Casino Games

Mechanism. Server seed is silently chosen per account. High-balance or +EV accounts get seeds that produce early-bust multipliers; recreational players get juicy rounds visible in chat.

Red flag. Watch published-hash rotation. If hashes change at suspicious moments (after a deposit, after a withdrawal request), the operator is selecting seeds at runtime.

Mechanism. Operator adds 200–500 ms server-side processing delay during high multipliers, so your "cash out at 5×" lands at 4.7× — past the curve and inside the bust window.

Red flag. Compare displayed multiplier to cash-out confirmation. A consistent gap on big multipliers is intentional friction, not network jitter.

Mechanism. Animated multiplier on screen is not the bound-to-result HMAC value — it slows down near your target to fake-look like the curve. Real outcome decided server-side from a different stream.

Red flag. Verify a few rounds against your own HMAC computation. Visible multiplier must match the formula floor((100·e − h)/(e − h))/100 exactly.

Mechanism. Game uses h % N for the instant-bust check, with N chosen so low h values bust more often. Drains beginners who always cash out at low targets.

Red flag. Track frequency of 1.00× rounds. If it materially exceeds 1/N for the stated house edge, the algorithm is biased.

Mechanism. Server processes high-bet cashouts last during high multipliers, so by the time your bet is matched, the round has busted. Smaller bets clear first.

Red flag. Time your own cashout, then cross-reference with the round-history feed. A delay correlated with bet size is foul play.

Mechanism. Operator publishes a server-seed HASH up-front but, after rotation, reveals a different seed than what was committed to. The hash never gets reverified by 99% of players.

Red flag. Always SHA-256 the revealed seed yourself and compare to the previously-published hash. Mismatch = the seed was swapped.

Mechanism. Multiplier shown as 2.00× but actual win-chance derived from 50.001% → 1.9999× internally, rounding-down the payout silently.

Red flag. Multiply your bet × displayed multiplier yourself. Operator payout should match to the cent — long-run any discrepancy is theft.

Mechanism. Operator's in-app "verify" button uses a simpler formula than the production round generator. Round looks fair against the verifier but isn't.

Red flag. Use a third-party verifier (this site's dice verifier at /tools/dice-verifier/) not the operator's. Same inputs must produce same output across implementations.

Mechanism. When auto-roll trends positive for the player, the operator slows ticks down by 1–2 seconds, making players give up before reaching profit target.

Red flag. A "Run 1000" that takes 4 minutes one session and 12 the next, despite same volume, is suspect.

Mechanism. Server rotates the seed mid-session without notifying you, breaking the hash-chain audit window. Past rounds appear unverifiable.

Red flag. The "previous server seed" should be reachable for every nonce range you played. Gaps = silent rotation.

Mechanism. Roll computed from `int(bytes) % 10000` with k-bit domain not divisible by 10000. Low rolls (0.00–0.50) appear ~0.1% more often.

Red flag. Run the Kolmogorov-Smirnov test (at /tools/kolmogorov-smirnov-test/) over a few thousand of your rolls. p < 0.01 = bias material enough to act on.

Mechanism. True multiplier is 12.4827× but operator displays "12.48×" and pays 12.48 — a 0.06% skim on every win, compounding across sessions.

Red flag. Re-derive multiplier from (server, client, nonce). Operator must pay to at least 2 decimal places of the true value.

Mechanism. Player targets 100×, round generates 99.97× → instant loss. Operator may "snap to integer" multipliers downward only.

Red flag. Always compute the result yourself for big multipliers. Even single bits of rounding favor the house.

Mechanism. Players with positive long-term EV (e.g. consistent winners) get seeds that produce more sub-1.5× rounds. Identifies +EV players, then bleeds them slowly.

Red flag. Compare your hit-rate at a given target to the theoretical (1 − HE)/target. Long-running negative variance ≠ bad luck.

Mechanism. Layout is not committed at round start. Each click re-rolls the mine map with a higher mine-density bias as your multiplier rises.

Red flag. Stake-style PF commits the FULL Fisher-Yates shuffle at round start. If the operator can't reveal all mine positions after a single click, they're cheating.

Mechanism. To feel generous, the first click is forced safe — but the next mine is moved closer to your likely-next click. Net EV worse than advertised.

Red flag. In a proper PF Mines, the first click can land on a mine. If you've never busted on click 1 in dozens of rounds, the layout is biased.

Mechanism. When current multiplier approaches your displayed cashout target, the button becomes unresponsive for 300ms. You either accept staler value or wait into a mine.

Red flag. Click-to-confirm timing must be deterministic. Variability tied to multiplier value = intentional friction.

Mechanism. Displayed multiplier for "3 mines, 5 safe" is 2.5× but actual payout 2.45×. Sub-cent skim per click multiplies over a session.

Red flag. Compute m(M, r) = (1 − HE) · C(25, r)/C(25 − M, r) yourself for your config. Operator must match to 4 decimal places.

Mechanism. Auto-cashout triggers fire AFTER the next reveal — if that reveal is a mine, you lose even though you "cashed out".

Red flag. Order of operations must be: cashout request → operator confirms → bet closed → THEN you can reveal more. Any race condition is house-favorable by design.

Mechanism. Operator decides the bucket up-front, then animates a "convincing" path to it. The visual path you watched is fake — bets are bound to the final bucket only.

Red flag. Each row should consume exactly one HMAC bit/byte deterministically. Replay the bytes and trace L/R yourself — visual must match.

Mechanism. Before the drop, a "hot" bucket is highlighted to tempt you to bet bigger. The highlight is randomized, not predictive.

Red flag. Hot buckets that "happen" to land on your bigger bets disproportionately are statistical fingerprints of rigging.

Mechanism. Same risk profile shows different multipliers session-to-session. Heavy session = lower multipliers; cold session = higher (to keep you hooked).

Red flag. Screenshot the payout table at start of session. Compare to end. Any change = silent recalibration.

Mechanism. Animation uses a "ball" that visibly drifts toward outer (low-mult) buckets in slow-motion replay. The float-determined path is honest; the WEIGHTING ad displayed differs.

Red flag. Same algorithm describes ball physics — there should be no operator parameter "weight" or "elasticity" that the player can't see.

Mechanism. Wheel animation lands on a generous segment, then "shifts" 1–2 segments inward to the actual result. Implied as "natural deceleration".

Red flag. Compute the segment yourself from floor(U · N). The wheel must rest with the pointer ON that exact segment, not its neighbours.

Mechanism. Big-multiplier segments are visually larger than their share. 9.9× segment renders 1.5× wider than other slots — player feels it's "achievable" but probability is 1/N.

Red flag. Count segments on the wheel image carefully. Equal pixel widths or it's manipulating perceived probability.

Mechanism. During an auto-spin streak, operator changes risk profile mid-stream — same wheel image but different multipliers internally.

Red flag. Risk profile must be a committed parameter for the round, visible in PF data. Any "drift" between rounds = manipulation.

Mechanism. Outcome is locked the moment you place your chips. The horizontal strip animation is purely decorative — the operator already knows where it stops.

Red flag. Provably-fair: server-seed hash visible BEFORE bet. After rotation, operator must reveal the seed and you re-derive the result. If not possible: cosmetic-PF, not real.

Mechanism. On CSGO-skin sites, bot accounts pile fake bets onto the colour that will lose, making it look like "real" players bet on red 3× more than green. Adds illusion of fairness.

Red flag. Verify bettor IDs aren't pseudo-randomized refresh tokens. If "winning" outcomes always match low-volume colour, something is upstream.

Mechanism. Site lets you deposit skins at $X market value but credits $0.7X. House edge becomes 30% just at deposit, before the wheel ever spins.

Red flag. Always check deposit credit vs. spot Steam market price. Discrepancies > 10% = operator skim.

Mechanism. Green pays 14× — but on big bets, operator silently caps "max payout per round" so a $100 bet on green winning pays $500 (5×) instead of $1400.

Red flag. Read the cap policy BEFORE betting big on green. If the cap kicks in at exactly your bet level, the operator engineered it.

Mechanism. Operator publishes a server-seed hash daily, but never rotates / reveals — so no past round is ever verifiable. The "PF" is just a static decoration.

Red flag. A real PF operator publishes hashes that ARE eventually revealed. Hash that's "always pending verification" = no PF at all.

Mechanism. Auto-pick or "lucky numbers" feature recommends numbers that are statistically LESS likely to draw — but feels personalised.

Red flag. Pick your own numbers. Compare the operator's suggestions over 100 rounds — if their suggestion hit-rate is below 1/40 per number, the recommender is anti-player.

Mechanism. After a player hits a 10/10 jackpot, the operator quietly reduces the 10/10 multiplier by 20–40% for future rounds without notifying.

Red flag. Screenshot the pay table at session start. Compare end-of-session. Any change without announcement = breach of terms.

Mechanism. If the 20 drawn numbers would produce a 9/10 or 10/10 hit, the draw is silently re-rolled to a worse outcome (no PF commit at start of round).

Red flag. PF round commits the full draw at start. Operator must reveal all 20 in the same nonce — no second roll allowed.

Mechanism. Tie cards (push) are weighted higher than 1/13 — operator wants you to "guess again" because each push slightly drains your edge and morale.

Red flag. Track push rate over 200+ rounds. Expected 1/13 ≈ 7.7%. Significantly higher = deck-weighting.

Mechanism. After ~10 correct guesses, operator displays multiplier 50× but caps cashout at 30× silently. Players don't notice until withdrawal.

Red flag. Read cashout terms before chasing long streaks. The displayed multiplier MUST be the actual payout.

Mechanism. Some operators use the same HMAC float for both "current card" and "next card" — guessing higher/lower is then non-trivial to lose.

Red flag. Each card must use a NEW float from the stream (different cursor). If your "next card" rank is deterministic given current card, the RNG is broken.