Betkyo's JavaScript verifier rounds a hash exactly once to match its Kotlin server bit for bit

Count the roundings on each path. The high piece is four bytes, 32 bits, which a double holds exactly. The low piece is three bytes in the 56-bit function and four in the 64-bit one, also exact. Dividing each by 2^32, 2^56 or 2^64 shifts an exponent and leaves the significand alone, so it is exact for doubles ^[8]. One IEEE addition then collapses the value to 53 bits. The comment in _shared/rng.ts reads: "hi/2^32 and lo/2^56 are both exact dyadic doubles, so the one IEEE addition rounds the 56-bit value exactly once" ^[9].

The naive path is worth counting too. Accumulating one byte at a time, six bytes give at most 48 significant bits, which a double holds exactly; the seventh step lifts the value to 56 bits and rounds once ^[20]. By that count the seven-byte loop rounds as often as Kotlin's single conversion does. The eighth byte brings the second rounding, and u64, the eight-byte function, is the one every seed-pair original imports ^[10]. The obvious recipe has another rounding in it: the post describes reading bytes as an integer and dividing by the largest possible value ^[17], and 2^56 - 1 is not a power of two ^[22].

The window where any of this changes an outcome is narrow. Doubles just below 1 are spaced 2^-53 apart, so a one-bit disagreement moves 37x by at most 37 * 2^-53, about 4 x 10^-15, and floor(37x) changes only when an integer falls in that gap: about one round in 2 x 10^14 ^[21]. A defect at that rate does not come out of QA. In the source's own example, the last bit decides whether 36.9999999999999 floors to 36 or 37 ^[16].

Crash does not build a double at all. Its crash point is the bustabit formula, floor((100 * 2^52 - h) / (2^52 - h)), with h the leading 52 bits of the hash ^[12], and the post says that division sits on exactly the kind of boundary where a double can be off by one ^[24]. So the browser computes it with arbitrary-precision integers, the way the server does ^[13]. The comment in the source gives the reason in one line: a floating-point approximation "would disagree with integer division at floor boundaries and make the verifier reject good rounds" ^[14].

Two conditions have to hold for this to be your problem. A second implementation must re-derive the outcome from the same input, and the map from number to outcome must floor or index into a table. A verifier that only re-hashes a seed chain and compares digests never builds the double, so the rounding count does not reach it. The account is the site's own, read from its engine source ^[23], and it describes the affected rounds only as "a small fraction of perfectly honest rounds" ^[15].