pub const POLYMOD_INIT: u128 = 0x23181b3;Expand description
Constellation-internal initial residue that mk-codec’s ms32_polymod and
ms32_long_polymod seed before processing any input — shared byte-for-byte
with md1 (md-codec’s bch::POLYMOD_INIT).
This value (0x23181b3) IS codex32/BIP-93’s published ms32_polymod
initial residue verbatim: the reference ms32_polymod seeds its accumulator
with exactly this constant, and GEN_REGULAR / GEN_LONG are BIP-93’s
ms32 / ms32_long generators term for term. (It is not bech32/BIP-173’s
init 1; that init belongs to a different code. An earlier note here
claiming this was “deliberately NOT codex32’s init” and that “the BIP-93
reference ms32_polymod starts from 1, not 0x23181b3” was wrong.)
md1 and mk1 seed this init literally. ms1 (ms-codec) uses the
mathematically equivalent formulation — codex32’s literal 1 init with
an hrp_expand("ms") prepend — because 0x23181b3 is exactly the fold of
hrp_expand("ms") from 1; a raw constant-diff against ms-codec’s
POLYMOD_INIT = 0x1 is therefore NOT a discrepancy. Sharing this init with
md1 is harmless: each of mk1’s regular + long codes is self-contained (the
same init seeds both checksum-create and verify), so the init’s contribution
cancels and a valid codeword’s residue equals its per-HRP target at every
length, for any fixed init. Domain separation is carried by the per-HRP
target constants (MK_REGULAR_CONST / MK_LONG_CONST) + the HRP — never by
this init. The reverted ms-codec
v0.2.1 bug was a non-codex32 init paired with an empirically-miscalibrated
target diverging from codex32 across lengths, not this value being
intrinsically length-variant; see
mnemonic-secret/design/BUG_decode_with_correction_length_divergence.md.