Bech32m

Overview

Bech32m was standardized in BIP 350 after analysis showed that the original Bech32 checksum had an undesirable property for witness versions beyond version 0. The modified format keeps the same overall layout and alphabet but changes the checksum constant. This small change creates a distinct validation rule.

In Bitcoin, witness version 0 programs continue to use Bech32, while witness version 1 through 16 programs use Bech32m. The best-known version 1 use is Taproot. A decoder must first identify and verify the encoding, then check that the checksum variant matches the decoded witness version and program requirements.

A Bech32m address may look almost identical to a Bech32 address because both use a human-readable prefix, separator, lowercase-friendly alphabet, data characters, and a six-character checksum. Appearance therefore cannot determine which rule applies. Protocol-aware validation is required before a wallet creates a transaction output.

Compatibility matters operationally. A service that only understands Bech32 version 0 may reject a valid Taproot destination, while poorly designed software might accept the string but build an incorrect output. Payment providers should test support through the complete transaction workflow, not only through a superficial Checksum check.

Bech32m improves error detection for its intended witness versions, but it remains an address representation rather than an identity guarantee. Users must still confirm the recipient and network. Applications should not convert between Bech32 and Bech32m because the checksum choice carries witness-version meaning, not a cosmetic preference.

Testing should include official valid and invalid vectors, mixed-case rejection, network prefixes, and witness-program lengths. A parser that verifies only the checksum can still accept a structurally inappropriate witness program. End-to-end tests should confirm that the wallet builds the correct script output and later recognizes the resulting transaction.