---
title: Bech32 Address
tags: discussion
---

# Bech32 Address

The checksummed base32 format "Bech32" (see [BIP-0173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)):
- **guarantees** error detection for up to 4 wrong characters
- **guarantees** error correction/localization for up to 2 wrong characters
- for up to 7 wrong random characters, there is a chance of < 1 per billion that it will go undetected

Even though the chosen code performs reasonably well up to 1023 characters, other designs are preferable for lengths above 89 characters (excluding the separator).

| HRP | Separator | Data | Checksum |
| ------ | --------- | ------------------------------- | ------------ |
| `iota` | `1` | ≤ 79 base32 digits or ≤ 49 byte | 6 characters |
| `iot` | `1` | ≤ 80 base32 digits or ≤ 50 byte | 6 characters |
| `io` | `1` | ≤ 81 base32 digits or ≤ 50 byte | 6 characters |

## IOTA address

| HRP | Version | Hash |
| ------ | ---------------------------- | ------------------------------------ |
| `iota` | `WOTS` or `Ed25519` (1 byte) | t5b1 encoded W-OTS address (49 byte) |
| `iota` | `WOTS` or `Ed25519` (1 byte) | Keccak-384 hash (48 byte) |
| `iot` | `WOTS` or `Ed25519` (1 byte) | t5b1 encoded W-OTS address (49 byte) |

### Examples

| Version | Address |
| ---------- | -------------------------------------------------------------------------------------------- |
| Trytes | `EQSAUZXULTTYZCLNJNTXQTQHOMOFZERHTCGTXOLTVAHKSA9OGAZDEKECURBRIXIJWNPFCQIOVFVVXJVD9DGCJRJTHZ` |
| Keccak-384 | `iota1qqp0ny6fljh6lhm4ztmav48u8mvkuf86fuqqt5yun25hecf2wuu3uwxzqe9m9t5wqul08u9ylcqr8rqeyhqa2` |
| t5b1 | `iot1qr4r3j4wamzu8ltdp6y7xtysj77vqtwua3q23hx9zmrmcqfdpd4muv25jwctsmxlh5g60w8s6k4x7gsq28c8da` |
| Ed25519 | `iota1qy84dkjj6ugcheyc98d6dvgf2szjkzr7yyma8vje5neng0h5ggpxgz88uep` |

### <span style="font-variant:small-caps;">Kerl</span>(I)
*Input:* a 243-trit string $I=(i_0,\dots, i_{242})$
*Output:* a 243-trit string

- $i_{242} \gets 0$
- $v \gets \sum_{k=0}^{242} i_k\cdot 3^k$
- $B_{in} \gets$ $v$ encoded as an `int384` (384-bit signed integer in big-endian two’s complement representation)
- $B_{out} \gets \operatorname{Keccak-384}(B_{in})$
- find $o_0,\dots, o_{242}$, such that $B_{out} = \sum_{k=0}^{242} o_k\cdot 3^k$
- <span style="font-variant:small-caps;">Return</span> $(o_0,\dots,o_{240},o_{241},0)$

## t5b1 vs Keccak-384

### Keccak-384
- Using the Keccak-384 hash is more space efficient (48-byte vs 49-byte).
- It allows the use of `iota` and `tiot` ad HRP.
- Every possible 48-byte value represents a potential W-OTS address
- During validation, it saves the expensive 384-bit→`BigInteger`→243-trit step
- If trits are required, an additional 384-bit→`BigInteger`→243-trit is necessary

### t5b1
- Works for any 243-trit input, not only Kerl hashes (e.g. Curl)
- Requires extra checks to prevent malleability: 0-trit padding must be enforced (how is this currently done)
- Requires extra syntax checks: not all 49-byte values encode valid ternary data
- Forces us to use 3-char HRP
- More consistent with our existing library interfaces as it returns ternary data