Why Blinko Runs Two Fairness Schemes
Identify the scheme from your proof fields and use the matching seed encoding and calculation.
One player or two
A fairness check must match the inputs and algorithm used by the round. Blinko retains a one-client-seed hash-chain verifier and a two-client-seed PvP verifier. Similar-looking seed values do not make those constructions interchangeable.
Practice runs locally against AI without money. Its calculation check can include a public hash-chain link when one is present, but it does not prove server match events. Legacy hash-chain records also use the one-client-seed construction. Current LIVE instead shows genuine server PvP duels.
In a PvP duel the server commits to a seed and both players contribute their own inputs. The derivation binds these values to one match and round. It fixes the hidden threshold and initial holder from those inputs, not the eventual winner: accepted passes still affect who holds the charge.
The hash chain, for Practice and legacy records
The operator generates a long sequence of seeds in advance, where each entry is the hash of the next. Publishing the first entry commits to the entire sequence, because producing any different continuation would require finding a hash collision.
Rounds consume the chain in order. The commit for a round is the previously revealed entry; after the round, the seed behind it is disclosed, and hashing that seed reproduces the commit. The chain moves one step forward.
The chain binds future server seeds, not every future match outcome. Your client seed and a nonce also enter the threshold derivation. A recorded chain anchor lets you check subsequent links; a seed and matching hash first seen after play do not establish when the commitment was published.
Commit-reveal with two contributors, for duels
Before a duel, the server commits to a seed and both players submit independent random values. These inputs determine the blast point and first holder, not the eventual winner. If either player’s contribution is missing, the round is cancelled instead of using incomplete inputs.
The derivation, explained on the fairness page, includes the match identifier, round identifier, generation counter and round nonce alongside both client seeds. A fixed byte format ties the calculation to that particular round and prevents ambiguous input ordering.
The blast point and first holder are calculated with different HMAC labels using the same combined input. These separate labels distinguish the two purposes. To reproduce the values, keep each label, seed encoding and byte order exactly as published.
Text and bytes produce different hashes
Both schemes commit with SHA-256, and they hash different things.
The chain hashes the seed as text — the 64-character hexadecimal string, encoded as UTF-8. The duel scheme hashes the raw 32 bytes that string represents. These produce entirely different digests from what looks like the same value.
If you check a hash-chain record using the PvP construction, the commitment will not match even when the supplied values are consistent. This is an easy way for a hand-check to go wrong. Select the scheme from the fields in the proof, not from the page where you watched the round.
Telling them apart
A chain round has a chain identifier, a chain index, one client seed and a nonce. A duel has a match identifier, a round identifier, two client seeds, a generation counter and a round nonce.
Both schemes target the same blast-point distribution and arena heat range. Their input encoding and rounding steps must still be reproduced exactly for that scheme. Matching a seed and threshold checks the calculation; it does not independently audit every pass, network delay or money outcome.
Read next
Common questions
Why does Blinko use two different 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 real PvP duels, not a separate hash-chain game. Choose the verifier scheme from the proof fields: the seed encodings and derivations differ.