Can Hand Histories Prove a Poker Shuffle Is Fair?

No. Hand histories cannot prove that a poker shuffle is fair. A complete, prospectively defined sample can test whether one chosen feature of the deals is compatible with one precise model. An unusual result can flag that model for investigation. An ordinary result means only that this test did not detect its chosen kind of departure; it does not validate the random-number generator, source code, deployed app, or operator.

This article turns that boundary into a usable workflow. The lab checks one observable—the hero’s pocket-pair count—using an equal-tail exact binomial rule fixed before the data are inspected. It also reports detection power, because a test that rarely catches a meaningful deviation should not be treated as reassuring.

Scope and disclosure: GTO Solutions AS publishes this site and Felted. Felted appears only as a clearly labeled example of a single-deal verification claim from its current US App Store listing. The lab is an independent editorial teaching tool, not a Felted feature, regulator test, certification, operator audit, or accusation tool. It evaluates no private or live product data.

“Fair Shuffle” Is More Than One Frequency

A pocket-pair count concerns distribution. Fair operation asks more. The UK Gambling Commission’s RTS 7 separates agreement with theoretical probabilities from unpredictability, sound seeding, unbiased scaling or mapping, and the absence of adaptive behavior. It also requires the implemented game to follow its described rules.

GLI-19 v3.0 makes the same separation operational. Sections 3.2.1–3.3.2 call for review of randomness, scaling, and shuffling code; suitable tests of final outcomes; checks of distribution and independence; and resistance to cryptographic attacks. Sections 4.5–4.6 then address how the game uses and displays those outcomes. A player’s hand histories expose only a narrow slice of that stack.

The Commission’s separate RNG testing procedure shows how much broader third-party work is: documentation and public-weakness research, source-code review, raw RNG output, scaled or shuffled-deck data, mapping, a live-like environment, versions, digital signatures, and a stated test scope. A player-side frequency table is not a substitute for that process.

That is why “my cards look normal” and “the shuffle is fair” are not equivalent statements. A malicious or defective process could preserve the overall pocket-pair rate while changing who receives which pair, correlating deals over time, weakening unpredictability, or conditioning outcomes on an untested variable. Conversely, a fair process will sometimes produce streaks that look remarkable after the fact.

Predeclare the Question Before Counting

A useful outcome check begins with a small test contract. Write it down before opening the sample:

1. Population: for example, every completed deal in one account’s exported hold’em histories over a fixed date window.
2. Inclusion rule: every consecutive deal in which the hero received two hole cards, whether the hand was folded or played.
3. Observable: “the two hero cards share a rank,” with 22 through AA all counted.
4. Sample size and stopping rule: a fixed number of eligible deals, not “stop when the graph looks strange.”
5. Number of checks: every outcome feature that will be tested, so the false-flag budget can cover the whole planned family.
6. Decision rule: exact lower and upper cutoffs calculated in advance.

If the export contains only voluntarily played hands, big pots, showdowns, bad beats, or hands selected for review, it cannot support this test. Strategy filters select on the cards and actions themselves. The resulting pair rate answers a different question about the filter, not the deal stream.

Keep the unit of analysis fixed too. Do not count several seats from the same deal as independent trials, or pool standard hold’em with Short Deck, Omaha, exposed-card conditioning, or materially different export rules. Those designs need different probability models.

Why the Null Pocket-Pair Rate Is 1 in 17

There are C(52,2) = 1,326 unordered two-card combinations. For each of 13 ranks there are C(4,2) = 6 suit pairs, so pocket pairs occupy 13 × 6 = 78 combinations. Under independent uniform 52-card shuffles:

p₀ = 78 / 1,326 = 1 / 17 ≈ 5.882%

For n eligible deals, the count X follows a binomial model, X ~ Binomial(n, 1/17), only if the declared sampling and independence assumptions hold. The model already accounts for drawing two cards without replacement within a deal; independence is an additional assumption between deals.

Exact Cutoffs—and the Power to Catch a Departure

The published rule is a central, equal-tail exact binomial test. With one planned test and a 5% family error budget, each tail receives 2.5%. The lower cutoff is the largest count whose cumulative null probability is at most 2.5%; the upper cutoff is the smallest count whose upper-tail probability is at most 2.5%. Because counts are discrete, the two tails usually total less than 5%.

The 8% column is a constructed sensitivity question: if the true pocket-pair rate were 8%, how often would this fixed two-sided rule flag? It is not an estimate about any poker product. At 250 deals, the rule would catch that planted departure only about 27% of the time. Even an in-range result is weak reassurance at that sample size. At 1,000 deals, power rises to about 74%; misses remain possible.

Choose that sensitivity target before seeing the observed count. Setting the hypothetical rate equal to an interesting observed rate and then describing the output as prospective power reverses the workflow.

The browser lab also reports a 95% Wilson interval as a descriptive range and an equal-tail p-value multiplied by the number of planned checks. The cutoffs—not an after-the-fact p-value hunt—are the primary rule. Probability-ordered “exact binomial” tests used by some software packages can produce different boundary counts, so the public bundle names and reproduces the equal-tail convention rather than relying on an ambiguous label.

The p-value is calculated under the null model. It is not the probability that the shuffle is fair, nor is 1 − p the probability that it is unfair.

Four Ways a Plausible Calculation Becomes Invalid

1. Searching until something looks rare

Testing pairs, aces, suited cards, each rank, each seat, weekday, session length, winning hands, and dozens of other summaries creates many opportunities for a small p-value. If 20 independent checks each use 5%, the chance of at least one false flag would be about 1 − 0.95²⁰ = 64%. The lab uses the simple Bonferroni safeguard: with m planned checks, each tail receives 0.05 / (2m). It is conservative, but transparent.

For example, 80 pairs in 1,000 deals flags when five tests were planned: the adjusted central p-value is about 0.0386 and the upper cutoff is 80. With ten planned tests, the same count does not flag: the adjusted p-value is about 0.0772 and the upper cutoff is 82. Choosing five only after seeing 80 would invalidate the comparison.

2. Looking repeatedly and stopping on a flag

Checking at 200, 300, 400, and every later deal is not the same as one test at the final sample size. Repeated looks spend more false-flag probability. A fixed stopping rule avoids that problem; a valid sequential design needs its own error accounting.

3. Keeping only memorable or playable hands

A sample of hands you opened, reached showdown with, tagged, or remembered is conditioned on decisions and outcomes. Pocket pairs are more likely than average hands to survive several of those filters. No exact arithmetic can repair an inclusion rule that depends on the event being counted.

4. Treating one account’s view as the whole deck

Hero cards do not reveal the hidden deck order, every opponent card, burns, mucked cards, entropy inputs, or the code-to-card mapping. A clean pocket-pair result can coexist with faults this statistic has no power to see. Expand the claim only when the evidence also expands.

Three Layers of Evidence Answer Different Questions

A cryptographic commitment is especially easy to overstate. Committing to hidden information before disclosure can make later substitution detectable, and revealing enough information can let someone reproduce a particular deal. That does not automatically show the seed was unpredictable, the shuffle mapping was unbiased, the committed software is the software that ran, or the operator could not choose among candidate seeds before committing.

Statistical testing is also deliberately bounded. NIST SP 800-22 Rev. 1a describes statistical tests as a useful first step for generator output while warning that no test suite can certify suitability or replace cryptanalysis. It addresses binary generator output, not a recipe for feeding encoded poker histories into a “NIST test” and declaring the deals certified.

Where Felted’s Offline Verification Fits

The current US App Store listing for Felted says offline hands use a Fisher–Yates shuffle and directs readers to an in-game “Fair Deal” panel after the latest completed offline hand. That places a claim about a particular finished deal in the first evidence layer. Whether a concrete protocol supplies prior commitment and reproducible disclosure still has to be established from the protocol itself, not inferred from the feature name.

It is not evidence that this article tested Felted, and the listing does not turn the pocket-pair lab into a certification of its shuffle. We do not generalize the offline description to online play, attest to an installed binary, or claim regulatory or laboratory approval. The ownership disclosure matters precisely because readers should know when an example comes from the same publisher.

How to Read a Flag—or a Non-Flag

If the count flags, preserve the data and investigate the pipeline before naming a cause. Confirm that histories are complete, duplicates are removed, game and deck rules are consistent, the hero actually received two cards in every included record, and the sample window and tests match the predeclared plan. Then reproduce the calculation independently. A persistent anomaly can justify asking the operator or an appropriate regulator for a scoped review; the count alone cannot establish manipulation.

If the count does not flag, report the result with its power and scope. A defensible sentence is: “In 1,000 prospectively included deals, 59 pocket pairs fell inside the predeclared 45–74 non-flag region; this rule had about 74% power against a planted 8% pair rate.” An indefensible sentence is: “The shuffle passed and is fair.”

That reporting habit also helps in ordinary poker analysis. It separates the question chosen before seeing results from the story invented afterward—the same discipline that improves a result-blind hand-review process. For the probability foundation beneath combinations and ranges, see the poker equity explainer.

Download and Reproduce the Evidence Lab

The public bundle contains eight exact sample-size rows, the null model and assumptions, two planted alternatives, source and limitation notes, and an independent Python verifier. No random simulation is used: every cutoff and power value is calculated from the binomial probability mass.

• Model, cutoffs, power, sources, and limitations (JSON)
• Published reference rows (CSV)
• Independent standard-library verifier (Python)
• Method, command, and scope note

Place the four files in one folder and run python poker-shuffle-evidence-verifier.py. The verifier reconstructs the exact distribution and cutoffs independently of the browser component, recomputes power at 4% and 8%, and checks CSV/JSON agreement.

Poker Shuffle Evidence FAQ

How many poker hands are enough to prove an RNG fair?

No finite hand-history count proves an RNG fair. Sample size should instead be chosen for power against a specific, predeclared departure, alongside evidence about design, implementation, and operation.

Does a rare streak prove the deal was rigged?

No. A streak chosen because it looked surprising has a selection problem. Define an event and stopping rule first, then account for every planned test.

Does passing the pocket-pair test validate every card frequency?

No. It checks one compressed count. Rank frequencies, suits, seats, boards, serial dependence, mapping, and unpredictability require different evidence.

Can a deal commitment replace statistical testing?

No. A well-designed commitment can protect the integrity of disclosed data for a particular deal. Population behavior and implementation assurance remain separate questions.

Sources and Methodology

Standards, product wording, and public calculations were checked on September 3, 2026. The article uses the standards as a taxonomy of evidence; it does not claim that they certify this lab or any named product.

• UK Gambling Commission, RTS 7 – Generation of random outcomes, last updated May 7, 2024. Used for separate requirements covering distribution, unpredictability, seeding, mapping, non-adaptive behavior, and implementation according to game rules.
• UK Gambling Commission, Testing strategy: Procedure for testing, last updated September 13, 2024. Used to contrast a player-side statistic with third-party review of documentation, source, raw RNG output, shuffled-deck data, mapping, versions, signatures, and deployment context.
• National Institute of Standards and Technology, SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications, April 2010, with NIST’s April 19, 2022 revision planning note. Used for the limit that statistical tests cannot certify suitability or replace cryptanalysis.
• Gaming Laboratories International, GLI-19: Standards for Interactive Gaming Systems, Version 3.0, July 17, 2020, §§3.2.1–3.3.2 and 4.5–4.6. Used to distinguish source review, outcome analysis, distribution, independence, cryptographic strength, mapping, and game operation. GLI-19 is a technical standard; citing it is not a certification claim.
• Apple App Store, Felted – Texas Holdem Poker, US listing. Used only for the narrow current description of its shuffle wording and Fair Deal panel for a completed offline hand. GTO Solutions AS publishes both Felted and this site.
• GTO Gecko, pocket-pair power model, reference rows, independent verifier, and method note. Generated and checked September 3, 2026.