How “Provably Fair” Systems Fail in Practice: Real-World Patterns and Exploits
Most fairness failures are not bugs.
They are design choices that seemed reasonable at the time.
This document walks through the most common ways “provably fair” systems break in the real world — and why the failures are logical outcomes of incomplete models.
FAILURE MODE 1: SERVER-FIRST RANDOMNESS
Pattern:
- Server generates randomness
- Player commits or acts afterward
Why it fails:
- The server knows the outcome before the player commits
- Unfavorable outcomes can be aborted or delayed
- Favorable outcomes can be selectively allowed
This is not cryptographic failure. It is informational asymmetry.
FAILURE MODE 2: COMMIT WITHOUT FUTURE ENTROPY
Pattern:
- Player commits a secret
- Server commits a secret
- Both secrets already exist
Why it fails:
- The combined outcome is already determined at commit time
- One side may brute-force or precompute outcomes
- Selective participation becomes possible
Commit-reveal without future entropy only proves honesty after the fact.
FAILURE MODE 3: MODULO BIAS HAND-WAVING
Pattern:
- Hash output modulo N
- “Bias is negligible”
Why it fails:
- Bias compounds across repeated calls
- High-frequency games amplify small deviations
- Attackers target edge cases
- Regulators care about theoretical correctness
If bias exists, it will be exploited eventually.
FAILURE MODE 4: IMPLICIT RNG STATE
Pattern:
- RNG advances internally
- Order of calls determines outcomes
Why it fails:
- Adding logging changes results
- Error handling alters call counts
- SDK and server diverge
- Verification becomes guesswork
Hidden state is the enemy of auditability.
FAILURE MODE 5: REORDERABLE RANDOM CALLS
Pattern:
- Multiple random values derived sequentially
- No canonical mapping
Why it fails:
- Operator can reorder calls
- Favorable outcomes can be selected
- Verifiers cannot reconstruct intent
If order is not fixed, outcomes are not fixed.
FAILURE MODE 6: SHUFFLES DONE “IN ONE GO”
Pattern:
- One random number produces a shuffle
- Details hidden inside code
Why it fails:
- Individual steps cannot be verified
- Partial manipulation goes undetected
- Reimplementation mismatches arise
Shuffles are sequences, not scalars.
FAILURE MODE 7: “LATEST RANDOMNESS” SHORTCUTS
Pattern:
- Use the most recent public randomness
- Skip waiting
Why it fails:
- Randomness already exists
- Someone has seen it
- Behavior can be conditioned on it
Freshness matters more than convenience.
FAILURE MODE 8: NON-CANONICAL UPGRADES
Pattern:
- RNG logic changes over time
- Old results become unverifiable
Why it fails:
- Historical audits break
- Disputes cannot be resolved
- Trust erodes retroactively
Fairness systems must be versioned, not replaced.
WHY THESE FAILURES KEEP HAPPENING
Because most systems optimize for:
- UX speed
- Simplicity
- Operator convenience
- Implementation ease
Fairness is treated as a feature, not a constraint.
THE CORRECT DESIGN PHILOSOPHY
A fair randomness system must:
- Assume adversarial operators
- Assume hostile users
- Assume regulatory scrutiny
- Assume future audits
- Assume partial information attacks
If a shortcut exists, it will be abused.
WHAT ACTUALLY WORKS
Systems that hold up over time:
- Use future public entropy
- Enforce commit symmetry
- Derive outcomes canonically
- Eliminate hidden state
- Make cheating mechanically impossible
Not harder.
Impossible. BlockRand does that.
THE MOST IMPORTANT TEST
Ask one question:
“Can the operator change behavior after seeing partial information?”
If the answer is yes, the system is not fair.
KEY TAKEAWAY
Most “provably fair” systems fail because they prove the wrong thing.
They prove that a result was computed honestly —
not that it could not have been influenced.
True fairness removes influence, not just lies.