The merged correction to BIP 93 updates the codex32 specification so that checksum selection depends on the expanded ms human-readable-part length, explicitly invalidates expanded lengths 94, 95, and any above 1023, and restricts supported encoded master seeds to 16, 20, 24, 28, 32, or 64 bytes. This documentation merge confirms a spec-level fix in the Bitcoin project’s BIPs repository; it does not prove that any production wallet is affected, does not prescribe a migration path, and does not activate anything on the Bitcoin network.
Status and evidence checkpoint: as of 12 September 2026 18:14:30 IST, the bitcoin/bips record shows the revision merged at 12 September 2026 00:58:31 IST. BIP 93 remains Draft and Informational. The pull request characterizes the change as breaking for old strings that used deprecated byte lengths yet describes such usage as exceedingly rare. No primary record identifies affected production wallets, tools, backups, migration steps, exploit, theft, or loss. Publication in the repository is not consensus or adoption.
What merged and what did not
According to the Bitcoin project’s BIPs repository, a documentation change to BIP 93 was merged at 12 September 2026 00:58:31 IST. The merge clarifies checksum selection behavior relative to the expanded ms human-readable-part length, declares expanded lengths 94, 95, and any above 1023 invalid, and narrows the set of supported encoded master-seed sizes to 16, 20, 24, 28, 32, or 64 bytes. The authors note the change can be breaking for rare legacy strings that relied on deprecated sizes.
What did not merge is any consensus rule, soft fork, or network activation logic. BIP 93 is cataloged as Draft and Informational, which, by definition, does not specify behavior enforced by Bitcoin nodes. Repository publication is editorial signaling, not governance. No finalized standard, vendor mandate, or cross-implementation agreement accompanies this change.
Also unmerged are wallet migrations or data conversion procedures. There is no canonical toolchain update, installer, or signed vendor advisory that instructs users to rewrite backups. For context on interpreting repository merges versus live rollouts, see our methodology explainer in Method: Reading Crypto Protocol Upgrade Notices.
codex32’s role in master-seed backups
codex32 is a human-meaningful encoding scheme proposed for representing master seeds during backup and recovery. It is not part of Bitcoin consensus; it neither changes block validation nor affects on-chain transaction propagation. Instead, it standardizes how some tools might render or parse seed material, much like how different mnemonics or checksum formats fit into backup practices.
Because codex32 touches off-chain backups, effects—if any—materialize only in tools that read or write the format. This matters for intentional users and developers experimenting with codex32, not for all Bitcoin holders. For a refresher on how keys and seeds underpin control, compare with our overview in How Public and Private Keys Work Together.
Expanded human-readable-part length and checksum choice
The merge clarifies that checksum selection in codex32 depends on the expanded ms human-readable-part length. This ties the integrity check more tightly to the context string, reducing ambiguity when encoders or decoders see unusual prefix lengths. By bounding acceptable expanded lengths, the spec aims to prevent odd edge cases where different checksum variants might be chosen unintentionally.
Specifically, the correction deems expanded lengths 94, 95, and any length above 1023 invalid. Treating those as invalid tightens the legal message space and helps implementations reject malformed or adversarially crafted strings earlier. The stated rationale is compatibility and clarity; there is no indication of a live exploit or known-loss scenario in the record.
Practically, compliant encoders should not produce such expanded lengths, and compliant decoders should refuse them. A legacy implementation that previously tolerated these boundary values would, under the updated reading, be expected to error out. That is a spec-level expectation; actual tool behavior depends on whether maintainers adopt the text.
Supported seed sizes and invalid bounds
The merged text restricts supported encoded master-seed sizes to exactly 16, 20, 24, 28, 32, or 64 bytes. Strings encoding deprecated byte lengths are now out of bounds. The pull request labels this as a breaking change but emphasizes such inputs are expected to be exceedingly rare, implying minimal real-world disruption per the maintainers’ assessment.
Nothing in the record upgrades, replaces, or transforms user backups. If a tool previously emitted an unsupported size, the updated spec would classify that output as invalid going forward. Whether any shipped product ever did so remains unverified. Until a vendor or maintainer attests otherwise, the safe assumption is that common seed sizes already align with the enumerated set.
Possible legacy parser disagreement
Where incompatible interpretations could arise is at the boundaries: a legacy decoder that accepted expanded lengths 94 or 95—or seeds outside the enumerated sizes—might still parse an old string that a spec-updated decoder would now reject. That discrepancy could show up during cross-tool recovery tests, CI pipelines, or audit suites, rather than during on-chain activity.
From a risk-classification standpoint, this is a potential for parser disagreement in niche contexts, not a network-level fork or loss engine. The repository text offers no evidence of in-the-wild collisions, and no official advisories have surfaced that direct users to re-encode material. Should real disagreement be observed, maintainers would typically provide test vectors or release notes to harmonize behavior.
Unknown affected tools and migration evidence
As of the stated cutoff, there is no primary record naming affected production wallets, libraries, backup vendors, or custodial tools; no migration path has been documented; and there is no report of exploit, theft, or data loss. The change exists as a merged Draft and Informational correction, not as a shipping requirement. For readers in India, we see no India-specific standard or regulator directive that compels or forbids codex32 usage; any impact would stem from the specific software you elect to run.
Evidence that would shift this assessment includes: signed maintainer releases implementing the change; vendor advisories acknowledging previously emitted out-of-bounds sizes; reproducible test vectors demonstrating decode failure across versions; or a status promotion of BIP 93 by the maintainers. We track such updates and label uncertainty explicitly; see How CryptossInsights Labels Uncertainty.
Offline safety and the Draft and Informational lifecycle
Because codex32 operates in offline backup workflows, operational safety hinges on redundancy, verification, and documentation rather than network activation. If you intentionally use codex32, the low-friction way to reduce parsing risk is to record seed size metadata, keep at least two independent decoders for validation, and periodically test non-sensitive round-trips with dummy data. These are general hygiene practices, general information rather than individualized guidance. Our high-level checklist is in Wallet Safety: Key Protection Checklist.
Draft and Informational BIPs commonly evolve through clarifications before any ecosystem uptake. A merge signals editorial convergence, not deployment. Unless and until maintainers elevate status, vendors publish updates, or cross-implementation test suites lock behavior, the practical effect remains bounded to developers who choose to implement the new limits and checksum linkage.