AlgoScan

The previous proof forgot that the stored f128 exponent includes the mantissa normalization offset: v = M*2^exp with M in [2^127,2^128) means exp is about log2(v)-127, so (1-p)^money at the extreme representable probability (1-p just above 2^-64) needs a stored exponent near -64*money-127, not -64*(money-1). At money = 2^57-1, admitted by the old bound, that is about -2^63-63 and wraps int64: empirically, newBinomialF128(2^64-2, 2^64-1, 2^57-1) produces pmf(0) with exponent +9223372036854775745. Intermediate a.exp+b.exp sums inside mul reach about -64*money-256 and wrap slightly earlier still.

At 2^56 every stored exponent and intermediate stays within ~2^62+2^8, a factor-of-two margin. The doc also overstated the headroom: the bound sits ~7x (about 2.8 bits) above the 10^16 microalgo supply, not 8 bits; the tripwire test now requires 2 bits and states the actual figure, and the rapid divisor band reads the constant instead of a literal.

The money < 2^57 validity bound was prose describing undefined behavior, protected only by economic invariants living in go-algorand. Export it as a constant instead of enforcing it at runtime: below the bound every exponent in the walk fits int64 even at the most extreme representable probability (1-p >= 2^-64 gives |exp| <= 64*(money-1) < 2^63), and it keeps ~8 bits of headroom over the 10^16 microalgo supply. Consumers assert their supply invariants against the constant in their own test suites -- go-algorand will read it and fail if vFuture/vcurrent consensus parameters could exceed it -- so a future economics change fails loudly in a test rather than silently misrounding consensus. TestSelectF128MaxMoneyHeadroom is the local tripwire.

rapid generates fresh values across the full input space every run, with explicit magnitude-band guidance layered on its boundary bias, complementing go fuzzing's corpus mutation, which dwells near seed values: the divU shallow-quotient misrounding survived ~30M fuzz execs but rapid found and minimized it within its first hundred generated cases (a={2^63+1,0}, u=2^64-1). TestRapidF128Ops mirrors FuzzF128Ops over the primitives; TestRapidSelectF128VsOracle mirrors FuzzSelectF128 end to end, drawing digests both uniformly and from the near-maximum regime. Both run 100 cases per ordinary go test invocation; raise with -rapid.checks for long runs.

divU folded the division remainder's sticky marker into the last quotient digit. For deep quotients that digit sits safely below the round bit, but once the divisor exceeds ~2^62 the quotient has at most 129 significant bits and the marker lands at the round bit (corrupting ties) or inside the mantissa (off by an ulp about half the time). The sortition walk cannot reach the broken region -- its divisor is the step index, bounded by money, ~2^53 at the supply -- but the round-to-nearest-even contract claimed by the doc was false there. Compute a 256-bit quotient instead: two full fraction digits keep the round bit inside computed digits for every divisor, and the remainder only ever contributes to sticky. norm192 and shl192 lose their last caller and are removed.

This survived ~30M FuzzF128Ops execs because go's mutator explores integers locally around corpus values and the seeds had u=7 and u=1: planted next to a u~2^63 seed, the fuzzer failed on the seed itself. Add two large-divisor seeds and TestDivUVsBig, a 2M-case differential test against big.Float with log-spread divisor magnitudes.

The exponent was a platform-sized int, which is 32 bits on 386/arm. No reachable input wraps it -- consensus parameters keep every exponent in the low thousands, and even the unfiltered fuzz domain stays near 2*10^5 -- but that made the cross-GOARCH bit-identity guarantee depend on magnitudes staying small rather than on the type. Also restructure add's alignment check to compare exponents in int64 BEFORE converting to a uint shift count: uint is likewise 32-bit on those platforms, and the naive type swap would leave a truncation that could alias a huge exponent difference to a small shift.

Replace the unreachable-tail wording with the accepted probabilistic bound and its no-grinding assumption. Pin current go-algorand committee behavior at the base minimum, payout eligibility landmarks, mainnet supply ceiling, and original report while showing that Boost terminates at finite double-CDF boundaries.

pmf(0) = (1-p)^money amplifies the 2^-129 rounding of 1-p by up to the trial count, and pmf(0) scales every PMF term, so the accumulated CDF settles at a plateau that can sit ~money*2^-129 below 1 (~2^-78 at supply-sized money). A digest ratio between the plateau and 1.0 (e.g. 2^256-1-2^176, ratio ~1-2^-80, with money == total == 2e15) sits above every boundary without rounding to 1.0, and the walk previously ground through all 2e15 no-op iterations -- hours of CPU on the consensus path -- before returning money.

Detect the freeze instead: once an add cannot move cum while pmf strictly shrank, no later term can move it either (the rounded step factor is < 1 and only decreases; round-to-nearest is monotone), so the walk returns money immediately -- the identical result the plain walk reaches, in O(binomial tail) time. FuzzSelectF128 continuously validates the short-circuit against the oracle's full walk, and TestSelectF128FrozenTailReturnsMoney pins the supply-sized case for both the 2^-80 digest and ratio exactly 1.0.

The count in the stuck sliver stays DEFINED as money: reaching it requires a VRF hash within ~2^-78 of the maximum, which cannot be ground for, so the 192-bit-pmf(0) variant that would return the exact binomial-tail crossing there (parked on sortition-f128-pmf192) is not worth its added audit surface under current consensus parameters. Documented in the SelectF128 tail-edge note.

build(deps-dev): update @typescript-eslint/parser requirement from ^8.64.0 to ^8.65.0

build(deps-dev): update @typescript-eslint/eslint-plugin requirement from ^8.63.0 to ^8.65.0

Raising 1-p to the money-th power amplifies the base's single 2^-129 rounding by the trial count, so for supply-sized money (~2^51) pmf(0) -- a common factor of every PMF term -- carried ~2^-78 of error and the accumulated CDF plateaued that far below 1. A valid digest with ratio above the plateau (e.g. 2^256-1-2^176, ratio ~1-2^-80, with money == total == 2e15) then sat above every boundary: the walk ground through all 2e15 no-op iterations (hours) and returned money where the exact crossing is j=1913. The band of such digests was ~money*2^-129, 2^51 times the documented 2^-129 edge; the differential fuzz could not see it because the oracle computed the identical plateau.

Fix in two parts. pmf(0) is now computed by a minimal 192-bit-mantissa float (f192: quotient, multiply, power, one rounding to f128) whose 64 guard bits absorb the amplification (money*2^-193 < 2^-129); the oracle mirrors it at prec 192. And the walk now detects a frozen CDF -- an add that cannot move cum while pmf strictly shrinks proves no later term can either -- and returns money immediately, the same result as the plain walk without the up-to-money no-op iterations.

The plateau now sits within ~(walk length)*2^-129 of 1, so the residual stuck band is ~2^-116 and returns money instantly. New coverage: TestF192PowVsBig and FuzzF192Pow (f192 vs 192-bit big.Float, incl. supply-sized exponents), TestSelectF128LargeMoneyTail (the 2^-80 digest now yields 1913, matching an independent 512-bit computation), and TestSelectF128FrozenPlateauReturnsMoney (derives a digest inside the stuck band from the observed plateau and requires an immediate money return). The more accurate pmf(0) moved the hair-trigger ratio==1.0 pins: the money=1954 early stop is now j=4 (was 3) and its fall-through twin is total=...960 (was ...000); the all-0xff digest at money == total == supply now stops at j=2012. BenchmarkSelectF128: 272ns/op (was 170ns; the 192-bit power costs ~100ns), still 1 alloc and faster than the 355ns cgo/Boost path.

The compressed 'as large as money vs. a few' read as a typo (money is the parameter, not a quantity of currency). Spell it out: at a near-maximum digest one implementation may stop within a few steps of the binomial tail while the other returns the full trial count money.