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. It is generated ahead of time and you only ever see a fingerprint of it up front, so PackDraw is locked into a value it cannot change afterwards without the fingerprint no longer matching. The client seed is yours, visible and editable in your account, and it exists so PackDraw cannot pick a server seed that targets a specific bad outcome at you. The nonce is a counter that goes up by one with each open, so the same 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
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 you see before you buy 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.
Battles work differently
For multiplayer battles 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 use 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 range proportional to their share of the round. We have implemented that path but have not yet confirmed it against a real jackpot result, so it sits at "awaiting confirmation" in the table above rather than verified. We do not describe a game as checkable until our implementation has reproduced a real one.
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 community reports
PackDraw's public reception is genuinely split rather than uniformly good or bad. Its Trustpilot profile carries roughly 385 reviews averaging 3.8 out of 5, but the distribution is polarised: about 68% leave five stars and about 25% leave one, with comparatively few in between. Recurring themes in the negative reviews, as summarised in BetterChecked's July 2026 test review, include failed cryptocurrency deposits and friction around payment handling.
Those are reported user experiences, not things we have tested or verified, and they sit outside what any fairness check can speak to. We include them because a split like that is a fact worth knowing before you deposit, and because pretending a 3.8 average is a clean bill of health would be dishonest.
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.