TL;DR - A friend lost about
$7.3M of his own money across 62 bets over 15–16 May 2026 (61 losses, ~$10.5M wagered) on a
private, account-gated build of winna.com's "Slide," internally "slide-vip." The
public Slide is genuinely provably fair. The private build he was moved onto had
neither anti-grinding safeguard. This post is about one narrow, checkable point: that build was marketed as provably fair, but it only ever satisfied the
verification half of provable fairness and none of the
commitment half. I am
not making an accusation of misconduct and I am
not claiming any specific spin was hand-picked. I am separating what is provable from what is not, and everything below is checkable with no account.
1. Lead with the objection, because it is the whole game: "the revealed seeds reproduce the results, so it's provably fair."This is the sentence that ends most PF disputes, and it is exactly backwards, so let me kill it before anything else.
"Provably fair" is
two obligations, not one:
- Commitment - the outcome is bound before you bet to entropy the operator cannot control or reselect.
- Verification - after the bet, the revealed server seed reproduces the result.
Reproducing a result from a revealed seed only demonstrates
verification. Here is the part people skip. Consider two operators:
- Fair operator: generates a random server seed, publishes its hash, and is stuck with whatever result it produces against entropy it cannot control.
- Grinding operator: against a known, fixed client seed, computes the result for server seed #1, #2, #3… offline, keeps rolling until one lands where it wants, then publishes that seed's hash.
When the server seed is later revealed and recomputed,
both operators' seeds reproduce their results perfectly. HMAC is deterministic - of course the number verifies. Reproduction is the one thing a fair game and a ground game
always share; it is the property that can never tell them apart. A revealed seed verifying is not evidence of fairness. It is evidence the arithmetic is deterministic, which it is in both worlds.
What separates the two is on the
commitment side, and a fair game needs
both of these on every bet - not one or the other (thanks to a PF engineer who pushed me to state this precisely):
- (1) A server-side commitment made before the client seed is known - the operator publishes hash(serverSeed), or locks its server seeds into a pre-committed hash-chain, before it can see the client seed for that round.
- (2) A client seed the operator cannot control or predict - in a player-facing "limbo" model this is the player's own client seed, which the player can change; in a crash model it is a then-unmined future block.
Neither half alone is enough, and this is the part people get wrong:
- A committed server seed with an operator-chosen client seed → the operator just grinds the client seed instead. Broken.
- An uncontrollable client seed with a freely-invented server seed → the operator waits until the client seed is known, then grinds the server seed. Broken.
The whole protection is
ordering: the operator is forced to lock one side
before it can see or influence the other. Take that away on either side and the "commitment" is theatre.
This build broke
both. And note what its client seed actually was: not the player's, not a future block, but a fixed
already-public 2023 Bitcoin block the operator itself chose. In a limbo model the client seed is supposed to be the
player's changeable seed - here the operator substituted its own known value for exactly the input that is meant to stop grinding. Because it knew that value at all times,
any per-bet "hash(serverSeed) published before the bet" was generated
after the operator could already compute the outcome - so it committed nothing. A pre-bet hash of a seed you chose against a fully-known input proves only that the seed was not
swapped after the bet; it says nothing about whether it was
selected before. That is why the binding entropy has to be genuinely outside the operator's reach on one side while it commits the other - and here it was on neither.
2. The mechanism - the result collapses to a pure function of the one value the operator generatesThe operator confirmed the
structure of the model in writing: a per-bet "limbo" calculation, a fresh hashed server seed each bet,
nonce pegged to 0, and a fixed client seed the player could not change. Written out:
result = max(1, floor((0.98 / float) * 100) / 100)
float = HMAC-SHA256(serverSeed, "{clientSeed}:0:0"), first 4 bytes,
read as a fraction in [0,1):
float = b0/256 + b1/256^2 + b2/256^3 + b3/256^4
Two things stated precisely, so no one can claim I retrofitted anything:
- The 0.98 edge is a derived-and-corroborated finding, not a constant the operator handed me. The code the operator actually supplied uses 0.99 - which does not reproduce the charged multipliers. The same code at 0.98 reproduces all three revealed rounds exactly (2.38x / 2.33x / 2.69x), and the operator separately stated in writing that the VIP ran "a 98% RTP setting." Crucially, nothing in the argument depends on the exact edge: at 0.99, 0.98, or any value, the result is still a pure deterministic function of the operator's server seed, so the grinding capability is identical.
- float is normalized to [0,1). Read the 4 bytes as a raw integer and you get result = 1 for every bet; read them as the fraction above and it reproduces by hand. This is what verify_slide.js does.
Now line the inputs up against the two safeguards:
- Client seed - fixed to Bitcoin block 779588, mined 2023-03-06: public and immutable for more than three years before these bets. This is wrong in two distinct ways. First, a client seed the operator picks from the past commits nothing - there is no future uncertainty to bind it. Second, this was a limbo model, where the client seed is supposed to be the player's own changeable seed; the operator replaced that with a value it chose. So the one input meant to be outside the operator's control was fully inside it. The operator conceded the standard in writing - that a correct PF "would always be having the client seed customizable" - and the VIP's was not.
- Nonce - pegged to 0. This is not an independent accusation; it matters only in combination. With no per-bet counter walking the input forward, every one of the 62 rounds required its own freshly generated server seed - i.e. maximum selection freedom, and the only value the nonce-0 result of each seed ever depended on was that seed. (It also means an "our sims show that seed pair sat right at expected RTP across the nonce range" defence is beside the point: nonce was 0, so only the single nonce-0 result of each seed was ever served. RTP is a population average, not a per-round guarantee, and it cannot distinguish a fair run from a selected one.)
- Server-seed commitment - the three revealed server seeds chain to no published commitment. I searched 11,000,000 iterations in both byte encodings and hit nothing. Safeguard (b) fails.
On that 11M number, so it is not mistaken for absence-of-evidence hand-waving: chaining is a
design property, not a sampled quantity. If a committed chain existed,
any one revealed seed would locate its position in it - exactly as each public-Slide seed does (see §3). The operator's own public chain terminates at round-number depth (bet 80030 at depth 80030), so 11M iterations is well over 100x the operator's own chain scale; a private ~62-bet game would link within tens. Three independent seeds failing to link in either encoding already rules a chain out - and the operator has never asserted a commitment exists or produced one.
Put the three together: fixed public client seed + nonce 0 means the result is a pure deterministic function of one value the operator alone generates, the server seed, with no committed chain constraining which seed it serves. That is the "grinding operator" configuration from §1, exactly. The operator was in a position to roll server seeds offline against the known client seed until one landed where it wanted, then publish that seed's hash. The hash verifies. The result reproduces. Both halves "check out." That is
capability - it is not proof it was used. Keep reading for why the capability is not merely theoretical.
3. The same operator builds PF correctly - right next to thisThis is what makes the point precise rather than hand-wavy, and it is the backbone of the whole argument.
The
public Slide - the one anyone can play - is genuinely provably fair. Its client seed is a
then-unmined future Bitcoin block, and it ships with a published committed hash-chain terminating at
890cb303…, where the server seed of bet 80030 reaches that terminal hash in exactly 80030 SHA-256 iterations. That is
both halves, done to textbook: a commitment locked in before the client seed existed, and a client seed the operator could not have known when it committed. It verifies.
So this is not an operator that does not understand provable fairness. It ships both halves in its own public product. The private slide-vip build the player was placed on had neither. I want the scope to be unmistakable: everything
before the private build (the public/provider-era Slide he won on) and everything
after it (the public Slide, later reseeded) was and is genuinely provably fair.
Only the private slide-vip build is challenged. The argument is not "they don't get PF." It is the opposite.
4. Three engines behind one identical-looking game - verify with no accountSame display name, same thumbnail, three different backend engines:
slide,
slide-vip, and
tequ_slider. Which one an account gets is a per-account flag in winna's own shipped front-end (choceXCL.chunk.js):
isSlideVipEnabled ... launchGameId: i && o ? f["slide-vip"] : e
You can confirm which engine served any round yourself, no login required:
https://api2.winna.com/v2/bet/info?id=<betId>
- A disputed round - fdcedeb7-c2ab-4300-9e31-214978632a4f - returns "slide-vip".
- A 14 May round the player won on - a13cfccc-4e9e-4dca-acd8-815b02e5e3b8 - returns "tequ_slider", a different engine.
I am claiming only what that second call proves: it is a
different engine identifier than slide-vip. I am not asserting anything about tequ_slider's internals. That one fact is enough, because it refutes the operator's final-response claim that "the identical VIP Slide configuration" applied to his winning play too. It did not - the winning play ran on a different engine; the losing session ran on the safeguard-free one. The API says so, to anyone, with no account.
5. Timeline - motive and opportunity, and nothing beyond thatRead this strictly as
capability + motive + opportunity. It does
not prove any outcome was selected. It establishes that the party with the capability to select outcomes undetectably also had a fresh, direct financial reason to be in that position, and the access, inside a ~72-hour window.
- Until ~14 May a third-party bankroll provider carried the downside risk on the Slide. While that held, a large player loss was mostly someone else's money, and the operator had little to gain from one.
- 14 May the player's winning run ended that arrangement. From then the operator was on its own book - so a large player loss would now be the operator's own retained gain rather than shared. The incentive inverted.
- 14 May, 21:30 UTC, that same night: the owner writes "ok good new slide almost live."
- Earlier that day a $77,777 public-Slide bet was rejected (16:54 UTC) - on the fair build - and the player was moved onto a private, high-limit build.
- 15 May, 01:26 UTC: the owner posts a Slide-specific cashback boost naming the player - "cashback reset for [the player] … extra 5% for slide for next 24 hours" - confirmed by staff a minute later. The first disputed bet followed at 01:38:33 UTC, and all 62 disputed bets came after that message. The build being promoted to him, by name, minutes before he played, was the one that lacked both safeguards.
- 15–16 May: 62 bets, 61 losses, ~$10.5M wagered. His targets sat at 3.5x–4x throughout, all short.
- The slide-vip build was removed shortly after; its bet pages now error.
- 18 May - two days after the session - the operator published a reseeding of the public Slide. I draw no inference from the timing; I note only that it demonstrates the operator can and does perform a committed reseed on demand, which reinforces §3: it knows how to do this correctly.
- Fairness data was requested 13 June and produced slowly; server seeds for only 3 of the 62 rounds were ever produced. The operator's account of the model shifted over time before settling on the per-bet hashed-seed model above.
(Clocks: bets are UTC straight from the API; chat is UTC+2, converted. The offset is not assumed - it is pinned by the player's own messages reacting in real time to the API-timestamped bet burst.)The loss framing, precisely:
$7.3M of the player's own money - $6.35M of it deposited
during the session, the remainder pre-existing balance. The $10.5M is
turnover (the sum of the bets, re-wagered), not net loss. I am deliberately making
no on-chain or money-movement claim of any kind - that attribution is unconfirmed and I am not putting a half-backed chain claim in front of this board. Omitted on purpose.
In one line, strictly as the motive-and-opportunity picture rather than evidence any outcome was chosen: the arrangement under which a third party covered the downside ended; the operator launched its own Slide the same night; the fair public bet the player tried was rejected; a private, high-limit build that
lacked both safeguards was provisioned to his account; he was promoted onto it by name minutes before the first bet; and the resulting loss fell to the operator's own book - all inside roughly 72 hours.
6. What is and is not claimed- Claimed: the slide-vip build was marketed as provably fair; with a fixed, already-public 2023 client seed, nonce 0, and no pre-committed server-seed chain, it satisfied only the verification half of PF and none of the commitment half - including against per-round hash-reveal, which does not bind when the client seed is public and fixed. In that configuration the operator was in a position to select outcomes undetectably by grinding server seeds offline against the known client seed. The timeline shows the motive and the opportunity.
- NOT claimed: that any specific spin was hand-picked to lose. I cannot prove that from the outside and I am not asserting it. Proving or excluding it requires the operator's internal server-generation logs, which only a regulator can compel.
- Kept clean: the public/provider-era Slide (where the player won) and the reseeded public Slide are not challenged and are genuinely provably fair. Only the private slide-vip build is. The whole case rests on the operator knowing how to build PF correctly - and this one build not having it.
The ask is narrow and falsifiable: produce a valid pre-bet commitment that
predates the client seed (or binds to a client seed the player could reset
after the commitment) and that the three revealed slide-vip server seeds verify against - plus the server-generation logs. A bundle of per-round hashes published after a public 2023 client seed was already fixed does not meet this, for the reason in §1. Absent such a commitment, the "provably fair" label does not hold for this build. Reproducing the results from the revealed seeds does not rebut any of this - it is consistent with both a fair game and a ground one.
7. Verify it yourself - no account needed- Which engine served a round: https://api2.winna.com/v2/bet/info?id=<betId> - disputed fdcedeb7-c2ab-4300-9e31-214978632a4f → "slide-vip"; the 14 May won round a13cfccc-4e9e-4dca-acd8-815b02e5e3b8 → "tequ_slider".
- The client seed: Bitcoin block 779588 was mined 2023-03-06 - public, unchangeable, three years before the game.
- The public chain is real: terminal hash 890cb303… is reached from bet 80030's server seed in exactly 80030 SHA-256 hashes.
- The disputed seeds commit to nothing: the 3 revealed server seeds chain to no published commitment within 11,000,000 iterations, both encodings.
- Reproduce all of it: clone and run node verify_slide.js - it reproduces the disputed results from the revealed seeds (remember float is normalized to [0,1)), verifies the public chain terminates at 890cb303… at the right hash count, and shows the disputed seeds chain to nothing.
Repo (all code + data, self-check everything):
https://github.com/Sejezebbe/winna-slide-caseX thread:
https://x.com/xxxmourn/status/2079872982080479397Status: a formal complaint has been filed with the operator's licensing regulator.Tear it apart - every number and endpoint above is checkable without an account, and I would rather be corrected than wrong.
