How to Verify a Blinko Round by Hand
A step-by-step check of a settled round using nothing but SHA-256 and HMAC-SHA-256.
What a fairness proof has to establish
There are two claims worth checking after a round, and they are separate. The first is that the operator committed to the outcome before play began, so it could not have been chosen once the round was underway. The second is that the outcome you were shown is the one that commitment produces.
A proof that only demonstrates the second is worthless: anyone can publish a seed after the fact and compute a matching result from it. The commitment is the load-bearing part, because it is the thing that existed before either player acted.
Everything below uses SHA-256 and HMAC-SHA-256. Both are in the standard library of every mainstream language, and the full construction is on the fairness page, and neither requires trusting any code we wrote.
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 blast point in degrees 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. Compare it against the value the round reported.
A worked example
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 4.77 degrees, which is what the round reported.
That is the entire proof. Two hashes, one division, one formula — or paste the values into the verifier and let your browser do it.
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.
The blast-point formula itself is the same in both schemes, expressed in hundredths of a degree in the duel version. The difference is entirely in how the inputs are bound together.
What verification does not prove
A successful check tells you the blast point was fixed in advance and honestly derived. It tells you nothing about network conditions. If your connection was slower than your opponent's, that affected when your passes registered, and no amount of hash checking will show it.
It also does not cover DEMO mode, which runs locally against a bot and creates no server proof, because there is no money outcome to prove.
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.