How a PackDraw pull is actually decided
Three values decide every pack you open, and two of them are fixed before you click.
The server seed is PackDraw's secret, generated ahead of time and shown to you only as a fingerprint, which locks PackDraw into a value it cannot change afterwards. The client seed is yours, visible and editable, and it exists so PackDraw cannot pick a server seed aimed at you specifically. The nonce counts up by one per open, so one pair of seeds produces a different result every time.
That much is standard. What matters for actually checking a pull is the exact way PackDraw combines them, because that part is not standard at all.
The formula, precisely
PackDraw joins the three values with colons and hashes the result:
clientSeed:serverSeed:nonce
|
v
SHA-512 (plain hash, not HMAC)
|
v
128-character digest read as one very large number
|
v
( digest mod 1,000,000 ) + 1 = your ticket, 1 to 1,000,000
Four details in there are easy to get wrong, and each one silently changes the answer rather than producing an obvious error.
| Detail | What most sites do | What PackDraw does |
|---|---|---|
| Hash function | HMAC-SHA256 or HMAC-SHA512, keyed | Plain SHA-512, no key at all |
| Seed order | Server seed first | Client seed first |
| Digest used | First 8 or 13 hex characters | All 128 |
| Commitment hash | SHA-256, 64 characters | SHA-512, 128 characters |
It is a plain hash, not an HMAC
PackDraw skips the keyed step other sites rely on. Most provably fair sites use HMAC-SHA256 or HMAC-SHA512, which take a key and a message as separate inputs. PackDraw does not. It concatenates everything into one string and hashes it once.
The client seed comes first
This is the single most common reason a PackDraw check appears to fail. Hashing is order-sensitive, so clientSeed:serverSeed:nonce and serverSeed:clientSeed:nonce produce completely unrelated digests. A verifier written for a site that orders it the other way will return a plausible-looking ticket that is simply wrong. LuxDrop is the clearest example: same SHA-512, same colon separator, opposite order.
The whole digest is used
Many sites slice off the first 8 or 13 characters of the hash and convert only those. PackDraw converts all 128 hex characters into a single integer before taking the remainder.
The commitment uses SHA-512 too
The fingerprint runs twice the length you may expect. It is a SHA-512 hash of the server seed, not the SHA-256 that most sites use. If you check the commitment with SHA-256 it will never match, even when everything is correct. Count the characters: 128 means SHA-512, 64 means SHA-256.
From ticket to item
The ticket on its own is just a number between 1 and 1,000,000. Each item in a pack holds a contiguous block of those numbers, sized to its stated chance, and whichever block contains your ticket is what you pulled. An item with a 0.5% chance holds 5,000 of the million tickets.
This is the part that makes the check meaningful rather than academic. Reproducing the ticket proves the number was fixed in advance. Seeing which range it lands in proves the number maps to the item you were actually given, and PackDraw states those ranges are shown in the pack details, which is more than most platforms here publish at all.
Where your seeds live, and when the secret half appears
Everything a check needs sits in your PackDraw account profile. The server seed hash is there before you buy, and the client seed, server seed and nonce for any completed open or battle are in your pack purchase history or battle history.
The timing is the part worth getting right, because it is unusual and this page had it wrong until 20 September 2026.
On most platforms the unhashed server seed appears only when you rotate your seeds, so checking a pull means first retiring the seed pair it belongs to. PackDraw states that it exposes the unhashed server seed once your purchase completes. A pull is therefore checkable immediately, and a pull from months ago is as checkable as this morning's, provided its history entry is still there.
What does not change is the direction. The check only ever looks backwards, at values already revealed. Anything offering to predict your next pull is working from a number that does not exist yet.
Battles work differently
No single player's input can decide a shared outcome, so battles borrow their randomness from somewhere public. PackDraw swaps your client seed for the hash of a future EOS blockchain block.
The reasoning is sound. In a battle there is more than one player, so no single person's client seed can be the fair input. A block that has not been mined yet is a value nobody at the table can know or influence, including PackDraw. Once the block exists, anyone can look it up on a public EOS explorer and confirm the same value went into the result.
Jackpot battles publish the draw but not the ranges
Jackpot battles take a different route again: SHA-256 of the winning round's EOS block hash, reduced against the battle's total ticket count, with each player holding a contiguous range sized to their share of the round.
PackDraw publishes that code too, and reading it closely shows what it can and cannot settle. The published function takes the ticket ranges as an argument. It draws the winning number and finds which range contains it, so it proves the draw was honest; it cannot show how the ranges themselves were built. PackDraw also names an optional "upside down" weighting that changes how shares become ranges, without specifying it anywhere. So the half of a jackpot most likely to be disputed is the half the published code assumes rather than computes.
We have implemented the draw and not confirmed it against a real jackpot result, so it sits at "awaiting confirmation" rather than verified. We do not call a game checkable until our implementation has reproduced a real one.
The Draw game contradicts itself
PackDraw's fairness page documents a fourth mode, Draw, in a single paragraph, and that paragraph does not agree with itself.
It states that each result is generated from your client seed, the hashed server seed, and a nonce. Every other mode on the page, and all of the published code, uses the unhashed seed. Then the same paragraph closes by saying the unhashed server seed is revealed after the game so you can confirm each result from the original inputs, which only works if the unhashed seed was the original input.
One of those two sentences is wrong and nothing on the page says which. Everything else about Draw is specified more precisely than most platforms manage: the nonce is derived as the round index times the line count plus the line position, the ticket space is the same 1 to 1,000,000, and a flip counts as a win when the ticket falls at or below the survival chance scaled to that space.
That precision is the reason the contradiction is worth naming rather than guessing past. Two readings of one paragraph produce two different digests, and picking one would mean shipping a verifier that is confidently wrong half the time. Draw is not implemented above, and it will not be until PackDraw says which seed it means.
Where our confirmation actually comes from
PackDraw publishes no worked example, no "here are the inputs and here is the answer" pair. That is a real gap in its documentation, and it means the usual way of confirming a verifier is unavailable.
What PackDraw does publish is better in one respect: the verbatim JavaScript its own site runs. On 22 July 2026 we took that code from the fairness page, ran it independently in Node with no connection to our own implementation, and compared the output. The two agree ticket for ticket, including on tickets 268,760 and 122,022.
That confirms our implementation matches PackDraw's stated algorithm exactly. It is one step short of a full end-to-end confirmation, which would need a real pack's revealed seeds and the item the site actually handed over. If you have one, running it through the verifier above would close that last gap, and we would say so on this page.
What the public record says
PackDraw's Trustpilot profile carries 472 reviews averaging 3.3 out of 5 as of October 2026, and the distribution is polarised rather than middling: 61% five stars, 31% one star, few in between. The recurring complaints are about payments rather than results, with failed cryptocurrency deposits the theme BetterChecked's July 2026 test review picks out.
None of that is something a fairness check can speak to, and it is a different question from the one this page answers. We keep the two apart deliberately: is PackDraw legit covers the operating record, the complaint pattern and what the reviews actually describe. This page covers whether the number was honest.
What a passing check does and does not settle
A green result on this page means one specific thing: the pack you are checking was produced by values committed before you clicked, and PackDraw did not alter it afterwards. That is a real guarantee and most sites in this space cannot offer it.
It is also a narrow one. It says nothing about whether the odds attached to an item are generous, whether a withdrawal will arrive, whether support will answer, or whether the business behind the site is sound. Those are separate questions with separate evidence, and a verifier is the wrong instrument for all of them. We keep what verification cannot prove as a permanent page for exactly that reason.