What HypeDrop actually publishes
A common claim in reviews of HypeDrop is that it exposes a server-seed hash but stops short of documenting its algorithm. That is not accurate. HypeDrop publishes the actual JavaScript for its game modes, which is more than most platforms in this space provide and more than enough to reproduce a result independently.
We have confirmed three of those modes against HypeDrop's own published values:
| Mode | Confirmed against | Value |
|---|---|---|
| Unboxing | HypeDrop's example seeds, run in Node | roll 19,569,993 |
| Battle | HypeDrop's published vector | roll 35,864,249 |
| Upgrade | HypeDrop's published vector | 88.02 |
The Deal mode uses the same engine as unboxing with a different prefix, but we have not yet reproduced a real Deal result, so it stays marked as awaiting confirmation rather than verified. We do not describe a mode as checkable until our implementation has actually reproduced one.
The quirk that breaks most verifiers
HypeDrop's engine does something genuinely unusual, and it is the reason a general-purpose provably fair calculator will not work here.
combined = GAME-serverSeed-clientSeed-nonce (hyphen separators)
HMAC-SHA256( key = combined, message = EMPTY )
|
v
first 13 hex characters of the digest
|
v
( value / 2^52 ) x maxSpin, rounded down = your roll
The message is empty
Read that first line carefully. The combined string is used as the HMAC key, and the message is empty. HypeDrop's published code creates the HMAC with the seed string and then never calls update() on it, so nothing is ever fed in as the message.
This is not the same as taking a plain SHA-256 of the combined string, and it is not the usual arrangement where the server seed keys an HMAC over the client seed and nonce. Both of those produce completely different digests. Almost every verifier written for other platforms gets this wrong on HypeDrop data, returns a number that looks perfectly plausible, and gives you a mismatch you cannot explain.
The prefix is literal
The GAME prefix at the front is literal: BOXES for unboxing, PVP_BOX for battles, DEAL for deals. Using the wrong prefix is the second most common cause of a failed check.
| Mode | Prefix | Multiplier | Status here |
|---|---|---|---|
| Unboxing | BOXES | 99,999,999 | Verified, roll 19,569,993 |
| Battle | PVP_BOX | 100,000,000 | Verified, roll 35,864,249 |
| Upgrade | Not applicable | Separate engine | Verified, 88.02 |
| Deal | DEAL | 100,000,000 | Awaiting confirmation |
Unboxing and battles are not interchangeable
The two verified modes share an engine but not their parameters.
Unboxing uses a maximum spin of 99,999,999. Battles use 100,000,000. The difference is a single unit, and because the final step multiplies by that value and rounds down, using the wrong one shifts your roll by a small amount that is nowhere near obvious. A result computed with the battle parameters against an unboxing pull will look almost right and be wrong.
Battles also swap what goes into the nonce position: HypeDrop uses the PvP bet ID rather than an incrementing play count. The verifier above handles that automatically once you select the battle mode.
Upgrades work differently again
The upgrade mode does not use the combined-seed engine at all. It runs HMAC-SHA512 keyed with the server seed over a message built from your client seed, the nonce and an iteration counter, then reads the digest in five-character chunks, skipping any chunk that lands at or above 1,000,000, and reduces the first accepted chunk to a value from 0 to 9,999. That value displays as a percentage, which is why HypeDrop's published example reads 88.02 rather than 8802.
The nonce for upgrades starts at 0, not 1. That differs from the unboxing modes and is worth checking first if an upgrade will not reproduce.
The 2022 cutoff matters
HypeDrop changed its random number generation on 19 October 2022. Anything played before that date, and specifically PvP rounds before round 86,238,174, ran on older code that this tool does not implement.
If you are checking something old and it will not reproduce, the cutoff is the likely reason rather than any error on your part or HypeDrop's. We have chosen not to implement the legacy path because we cannot confirm it against a real published result, and an unverified implementation would be worse than none.
What a passing check settles
A match here proves the specific result you are checking came from values fixed before you played, and that HypeDrop did not change it afterwards. Given how unusual its engine is, reproducing a HypeDrop roll independently is a meaningful confirmation rather than a formality.
It settles nothing else. It says nothing about the odds attached to a box, whether a withdrawal completes, or how the business behaves. Fair math and a trustworthy operator are separate things, and we are deliberate about what verification cannot prove.