HypeDrop calls your seeds something else
The first obstacle on HypeDrop is vocabulary. Its fairness page explains the system through a Rock, Paper, Scissors analogy and names the three inputs accordingly:
| What this site calls it | What HypeDrop calls it | Where it comes from |
|---|---|---|
| Client seed | Your Hand | Your browser, editable before you open |
| Server seed | Our Hand | HypeDrop, hashed before, revealed after |
| Nonce | Play Count | Starts at 1 and rises by one per game |
Only in the verification paragraph further down does the page write "Play Count"/nonce and connect the two vocabularies. A reader who has learned the standard terms elsewhere can look at the right screen and not recognise it.
The Play Count detail is worth reading twice, because HypeDrop states it plainly and not every platform does: it counts games you have played, starting at one. Upgrades and raffles start theirs at zero instead.
The quirk that breaks a general-purpose calculator
HypeDrop's engine does one thing almost no other platform does, and it is the reason a verifier built for another site will not work here.
combined = GAME-serverSeed-clientSeed-nonce (hyphens, prefix literal)
HMAC-SHA256( key = combined , message = EMPTY )
|
v
first 13 hex characters of the digest, as an integer
|
v
( value / 2^52 ) x maxSpin, rounded down = your roll
Read the second line carefully. The combined string is the key, and nothing is ever passed as the message. HypeDrop's published code creates the HMAC with that string and then never calls update() on it, so the message stays empty.
This is not a plain SHA-256 of the combined string, and it is not the ordinary arrangement where the server seed keys an HMAC over the client seed and nonce. Both of those produce entirely different digests. A calculator written for another platform does not fail loudly on HypeDrop data. It returns a number in the right range that is simply not your roll.
The prefix is literal
The GAME element at the front is a literal string: BOXES for unboxing, PVP_BOX for battles, DEAL for deals. HypeDrop's own code comments say the prefix exists so that two modes cannot accidentally share a seed and produce the same result twice. Using the wrong one is the second most common cause of a failed check.
Two numbers for one roll space
HypeDrop's Unboxing tab states that "there are 100,000,000 potential roll numbers to land on". The code block immediately below it reads maxSpin = 99999999, which is 99,999,999 outcomes.
Both sentences are live operator statements on the same page and they cannot both be true. This site follows the code, because code is what the site runs, and the same rule resolved a similar conflict on CSGOEmpire. It is worth stating rather than quietly fixing, because the discrepancy is not cosmetic: the final step multiplies by that number and rounds down, so the two values do not produce the same roll.
Battles make it concrete. Unboxing and deals scale to 99,999,999 and battles scale to 100,000,000, one apart, in HypeDrop's own code for its own modes.
| 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 | none | separate engine | Verified, 88.02 |
| Deal | DEAL | 99,999,999, then shown divided by 1,000,000 | Awaiting confirmation |
| Raffle | none | the ticket count | Not implemented |
A roll computed with battle parameters against an unboxing pull lands close to the right answer and is wrong. That gap is small enough to look like a rounding error and is not one.
Which figures HypeDrop actually states
Four of HypeDrop's code blocks ship example seeds. Two of them also state what those seeds should produce.
The battle script carries the comment it will output Roll value: 35864249, and the upgrade script carries Roll value: 88.02 (Raw value: 8802). Both reproduce here. Those are operator-stated outcomes, which is the strongest form of confirmation available without an account: they prove our implementation agrees with the operator's own answer, not merely with the operator's source code.
The unboxing and raffle scripts state no expected output. So 19,569,993 is a figure this site computed by running HypeDrop's published unboxing code on the seeds it publishes, not one HypeDrop quotes. The registry said otherwise until 20 September 2026 and has been corrected. It is a small difference. It is recorded anyway, because a page that overstates its own evidence is in no position to grade anyone else's disclosure, and this one does that further down.
Battles commit to a block that has not been mined
Battle rounds need a shared input that no player and no operator can know in advance. HypeDrop takes its from the EOS blockchain, committing to a specific future block and using that block's hash once it is mined.
The sequence is the part that does the work. Every player's server seed is committed as a SHA-256 hash when they join. Every bet, and therefore every nonce, is locked before the block exists. Only then does the hash appear. HypeDrop's own wording is that the nonces "are all published and committed to before the EOS Hash is known to us".
One practical detail the code makes plain and the prose does not: in the battle script the EOS hash occupies the client seed position. The per-player server seed stays in the server seed position, and the nonce is the PvP bet ID, a number that increments across the whole site rather than across your account. All three live in the Provably Fair dialog on the Battle Duel page.
The battle script, as it reads in October 2026, adds one step before the ID goes in. A function called deriveNonce passes any bet ID from 0 to 2,147,483,647 through unchanged, and replaces anything larger with a number taken from the SHA-256 hash of that ID. For every ID up to that ceiling the result is identical to using the ID directly. HypeDrop does not say when the step was added, and the verifier above follows the current code.
The old code is still published, and dated
HypeDrop has changed its random number generation twice, and it published both boundaries:
| Changed | Applies to rounds before | Old code |
|---|---|---|
| 19 October 2022 | PvP Round ID #86,238,174 | Linked and runnable |
| 28 September 2021, 10:57 PM UTC | PvP Round ID #15,829,596 | Linked and runnable |
That is the standard worth naming, because most of the field does not meet it. Clash.gg and RustClash changed their case algorithm and published no date, no round ID and no cutoff, which leaves their older rounds unverifiable by anyone. HypeDrop tells you which era your round belongs to and hands you the code for it.
The verifier above implements the current algorithm only. For an older round, the honest route is HypeDrop's own linked previous version rather than anything here.
Upgrades and raffles run different arithmetic
The upgrade mode leaves the combined-seed engine behind entirely. It runs HMAC-SHA512 keyed with the server seed over a message built from the client seed, the nonce and an iteration counter, then reads the digest in five-character chunks, skips any chunk landing 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 the published example reads 88.02 rather than 8802. Its nonce starts at 0.
The Upgrade prose describes the same step differently, saying a chunk is skipped when it lands "above 10,000". The code below it skips at 1,000,000. It is the same kind of disagreement as the roll count, and the same rule applies: the code is what runs.
Raffles reuse the unboxing arithmetic with one substitution: the fixed multiplier becomes the raffle's ticket count, so the roll space changes with the draw. The verifier above does not implement it, and a raffle result is outside what this page covers.
Where the check stops
HypeDrop publishes a drop table for every box, listing each item and its probability to two decimal places, before you spend anything. What it does not publish is the ticket range each of those items occupies.
So the roll is the end of the check here. You can prove your number was fixed before you opened and was not altered afterwards. Confirming that the number then mapped to the item you received would need the ranges, and they are not public.
What a passing check settles
A match proves the result came from values committed before you played, and that nobody changed it after the fact. On an engine this unusual, reproducing a HypeDrop roll independently is a real confirmation rather than a formality.
It settles nothing further. Not the odds attached to a box, not whether a withdrawal completes, not how the business behaves when something goes wrong. HypeDrop's public record, including its 2024 closure and relaunch and what its reviewers report now, is a separate question handled on is HypeDrop legit. Fair math and a trustworthy operator are different claims, and we keep what verification cannot prove as a standing page to hold the two apart.