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 solo or LIVE round, 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 detail matters and it is the most common reason a hand-check fails. Hash the string, not the decoded bytes.
If that hash equals the commit that was published before the round, the operator was bound. If it does not, stop: nothing further is worth checking, and you have found something worth reporting.
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 solo or LIVE round the message is your client seed and the round nonce joined by a colon, as text: for example, player-m35kue:41.
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 runs two fairness schemes, and checking a round against the wrong one will make an honest round look rigged. If the round has two client seeds and a match identifier, it is a PvP duel and the construction 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 use 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 binding 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.
Verification is a narrow guarantee, precisely stated. That narrowness is what makes it worth anything: a claim that covered everything would be a claim you could not check.