How to Verify a Blinko Round by Hand
Check a round's seed commitment and blast threshold step by step with SHA-256 and HMAC-SHA-256.
What a fairness proof has to establish
There are two checks to keep separate. First, the revealed server seed must match a commitment you recorded before play. Second, the disclosed inputs must reproduce the derived threshold and, for a PvP duel, the initial holder. These are checks of random inputs and their derivation, not a complete audit of the match winner.
A matching calculation alone cannot establish when a commitment was published: anyone can present a seed and matching hash after the fact. Keep the original pre-round commitment. If all values come from a post-round response, you can check internal consistency, but not independently establish the pre-round publication time.
Everything below uses SHA-256 and HMAC-SHA-256, available in standard cryptographic libraries. The fairness overview explains the approach; the exact PvP construction is set out below. You can reproduce it independently without our verifier.
Step one: the commitment
Before a round, the server publishes a commit value. After the round it reveals the server seed behind it. Your first check is that hashing the revealed seed reproduces the published commit.
For a hash-chain record, the seed is hashed as text — that is, the 64-character hexadecimal string itself, encoded as UTF-8, not the 32 bytes it represents. This applies to the one-client-seed construction used by Practice and legacy records, not current LIVE PvP proofs. For this scheme, hash the string, not the decoded bytes.
Compare the result with the commitment you saved before the round. If it differs, first check the scheme, encoding and round identifiers. If the inputs are correct, save them with the round ID and contact support. Do not include passwords, one-time codes or private wallet keys.
Step two: the blast point
The blast point is derived by taking an HMAC-SHA-256 with the server seed as the key. For a hash-chain record, both the key and message use text: the message is the client seed and round nonce joined by a colon, for example player-m35kue:41. The PvP construction is described separately below.
Take the first 13 hexadecimal characters of the resulting digest and read them as an integer. That is 52 bits. Divide it by 2 to the power of 52 to get a value u between 0 and 1.
The dimensionless internal value B is then 2.80 + 0.95 / (1 − u) − 0.95, rounded to two decimal places, held to a floor of 2.80 and a cap of 100.00. Arena heat is B multiplied by 100 and rounded to an integer. Compare B with the proof's B field, or the resulting heat with the arena's degree readout.
A worked hash-chain example, not a USDT duel proof
Chain 3ea188595c9e41c0, index 1. The published commit is 87a1ced498db265b07a34da90df08d088a74ee429dc2a041aef50c8cef827c94. The revealed server seed is 53c095ce747f1b473b564bbf66df4be4e069d93f10405f6ed11f03e4e973af41. The client seed is player-m35kue and the nonce is 41.
Hash the server seed as text and you get the commit above. Take HMAC-SHA-256 with that seed as key over the message player-m35kue:41, read the first 13 hex characters as a 52-bit integer, and run it through the formula. The result is B = 4.77, equivalent to 477 heat degrees, which is what the round reported.
That reproduces the sample's commitment and threshold. It does not establish when the sample commitment was published. Paste the values into the verifier to compare the calculation, selecting the hash-chain scheme rather than the PvP scheme.
PvP duels use a different construction
Blinko uses two fairness schemes. A mismatch can result from selecting the wrong one, so identify the scheme before calculating. If the proof has two client seeds and a match identifier, use the PvP construction, which differs in three ways.
The commitment hashes the raw 32 bytes of the seed rather than its hexadecimal text. The entropy is built from a canonical byte string that binds the match identifier, the round identifier, two counters and both players' seeds. And the blast point and the first holder are derived under separate HMAC domain tags, so that neither value reveals anything about the other.
Both schemes follow the same blast-point curve. The duel version derives the integer thresholdCent directly: it is the arena heat in degrees, or B multiplied by 100. The input format and exact arithmetic differ, so use the published implementation for your proof type.
Exact PvP derivation
Build context by concatenating these bytes in order: UTF-8 of blinko.fairness.v3; one zero byte 0x00; the 32-byte SHA-256 digest of UTF-8 matchId; the 32-byte SHA-256 digest of UTF-8 roundId; generation encoded as an unsigned 64-bit big-endian integer; roundNonce encoded the same way; hex-decoded hostClientSeed; then hex-decoded guestClientSeed. Do not insert other separators. Calculate entropy = SHA-256(context).
For both HMACs, the key is the hex-decoded serverSeed. The threshold message is UTF-8 of blinko.explosion.v3, one 0x00 byte and the 32 entropy bytes. The holder message is UTF-8 of blinko.holder.v3, one 0x00 byte and the same entropy bytes. Calculate HMAC-SHA-256 for each message. The domain strings are literal algorithm inputs, including their punctuation and version digit.
Read the first 13 hex characters of the threshold digest as integer x. With exact integer arithmetic, set E = 2^52, d = E − x and variable = floor((95 × E + floor(d/2))/d). Then thresholdCent = min(10000, max(280, 185 + variable)) and B = thresholdCent/100. The low bit of the first byte of the holder digest selects the initial holder: 0 means host, 1 means guest. Compare these values with the proof fields, not the approximate end time of an on-screen animation.
What verification does not prove
A successful calculation confirms that the disclosed inputs produce the published values. Together with a commitment independently recorded before play, it lets you check that the seed was not substituted afterwards. It does not measure latency: clock sync and early pass scheduling reduce some network disadvantages, but do not eliminate every timing difference.
Practice runs locally against an AI opponent with no stake. Its round check can reproduce a seed commitment and blast-point calculation, including a public hash-chain link when present. That is not a server-match proof: it does not attest to authoritative match events or a money outcome.
Record which values matched, which scheme you used, and whether the commitment was saved before play. This gives you a check you can repeat and a clear record to share with support if needed.
Read next
- Why Blinko runs two fairness schemes
- Check a round in your browser
- How provably fair verification works
Common questions
How do I verify a Blinko round without trusting the site?
Save the commitment before play, then recompute the revealed seed’s SHA-256 hash and the round’s HMAC-SHA-256 derivation using the correct scheme. You can do this independently with a cryptographic library. Values obtained only after the round establish internal consistency, not when the commitment was published or who won.