How round verification works
Check the calculation behind a round’s blast point and first holder. Before play, save the hash of the server’s secret value, or seed. After the round, use the revealed data to check that hash and repeat the calculation.
A worked hash-chain example
Follow the calculation from the revealed seed to a blast point of 477°. This is a hash-chain example, not a proof of a USDT duel.
chain 3ea188595c9e41c0 · index 1
1 · The commitment to compare
87a1ced498db265b07a34da90df08d088a74ee429dc2a041aef50c8cef827c94
SHA-256 of the revealed seed matches this commitment. To check that a seed was not substituted after play, compare it with a commitment you independently saved before the round.
2 · Revealed after the round
53c095ce747f1b473b564bbf66df4be4e069d93f10405f6ed11f03e4e973af41
3 · Client seed and nonce
player-m35kue · nonce 41
The client seed and round counter, or nonce, complete the inputs needed to calculate the blast point.
4 · The blast point
477° Verified
Where blast points land
Low blast points are more common than high ones. These figures are calculated from the hash-chain formula, not measured from past games.
- Median
- 375°
- Mean
- 721°
- Minimum possible
- 280°
- Reach the 10000° cap
- 0.97%
Choose the scheme for your round
Use the fields in your round’s proof to identify the scheme. Practice and older hash-chain records use one client seed. Server PvP uses two. LIVE shows server PvP duels.
Hash chain — Practice and legacy records
Seeds are generated as a chain in advance, each one hashing to the entry before it. Your round takes one seed, your client seed and a nonce. SHA-256 is taken over the seed’s hex text.
commit = SHA-256(hex text of serverSeed)
digest = HMAC-SHA-256(serverSeed, "clientSeed:nonce")
u = first 52 bits of digest / 2^52
B = 2.80 + 0.95 / (1 − u) − 0.95, capped at 100
heat° = round(B × 100)B is the dimensionless internal value. Arena heat is B × 100: for example, B = 4.77 means 477°.
Fairness v3 — PvP duels
Both players contribute a seed, and the blast point and first holder are derived under separate HMAC domains so neither reveals the other. SHA-256 is taken over the raw 32 seed bytes.
commit = SHA-256(raw 32-byte serverSeed)
entropy = SHA-256("blinko.fairness.v3" || 0x00 || … || hostSeed || guestSeed)
blast = HMAC-SHA-256(serverSeed, "blinko.explosion.v3" || 0x00 || entropy)
holder = HMAC-SHA-256(serverSeed, "blinko.holder.v3" || 0x00 || entropy)What this proof does not cover
A matching calculation does not independently verify every pass, the winner or payment. It cannot establish when the hash was published unless you saved it before play. Connection quality still affects the game. Practice runs locally without money, so its check is not proof of a cash duel.
Common questions
What is committed before a Blinko round starts?
The commitment is a SHA-256 hash of the server seed, not a hash of the blast point. After the reveal, compare that seed with the commitment you saved before play and reproduce the threshold from the round inputs. Pass decisions do not enter this calculation.
How do I verify a Blinko round myself?
Save the pre-round commitment, then enter it and the revealed inputs on the verify page using the matching scheme. The calculation runs in your browser without sending those inputs to Blinko. For an independent check, reproduce the published algorithm with a separate SHA-256 and HMAC-SHA-256 implementation.
Why does Blinko use two fairness schemes?
Practice and legacy hash-chain records use one client seed and a nonce. Server PvP proofs use both players’ seeds and match identifiers. Current LIVE shows genuine PvP duels, not a separate hash-chain game. Use the scheme matching the proof fields; the seed encodings and derivations differ.
What does provably fair not prove?
Matching inputs and calculations do not establish when a hash was published unless you saved it before play. A seed-and-threshold check does not audit every match event, establish the winner, equalize network latency or prove payment. Practice checks are not server-match proofs.