Abstract
This Proposal details the bech32 address standard adopted by the IC.
Motivation
Account-ID is widely used in IC, in dfx ledger
and NNS wallet
. The Account-ID uses 64 length hexidecimal string as identifier, calculated by DER-Publickey ,SHA256, and with crc32 checksum. Users use it to transfer ICPs/Tokens from one to another. Major exchanges and IC’s wallets/ledger use it.
However, this format of Account-ID is widely used in various projects, eg NEAR protocol. Although IC uses principal and specific string (\x0Aaccount-id
) to identify, the address is not human-readable to human users. Any tokens mistakenly sent to the wrong network/blockchain therefore would have led to an irreversible loss of the tokens. This is because the private key(phrases/seed) corresponding to an address on IC’s does not correspond to the same private key on other blockchain, due to the difference of the underlying hash function used.
Hence, this Proposal proposes that DFINITY’s adopt a variation of the bech32 format on the wallets/SDKs level to prevent users from sending tokens from their wallets/exchanges (i.e., Binance) to a mainnet IC address and vice versa. The proposed change will be of cosmetic in nature and will only impact wallets and SDKs. It will only be visible to end-users and no change is required at the core-protocol layer.
Specification
Please refer to bip-0173
for more details of the bech32
technical specification.
A IC’s bech32
checksummed address consists of the following parts:
Human-readable prefix | Separator |
bech32 formatted address |
Checksum | |
---|---|---|---|---|
Example 1 | icp |
1 |
0yg27sw98nwmxxrz7razcvwt6kxmjezajrlmsaw840yvj |
pdfpsm |
Example 2 | icp |
1 |
58gkn9x77r4usmdxtlrnhy27aypsk7stkh49rkh7hlz7k |
8t72zv |
Example 3 | icp |
1 |
xz7nt4vv3k2fakyfetm6p6qyaymnta742qdyh4fyq799y |
7m8vq5 |
Rationale
Bech32 address format
Other address format such as base32
were explored. However, bech32
address format turns out to be a better fit since:
- its human-readable prefix explicitly conveys that the address is a IC address,
- it prevents confusion with other blockchain’s address format, eg. NEAR protocol.
-
Bech32
is widely used across wallets and exchanges
Backward Compatibility
This Proposal is backward compatible as the required changes are only at the wallet and the SDKs levels. There is no change required at the core protocol layer.
Test Cases
TBD
Implementations
TBD
Sample sanity implementation
TBD
Explorer
TBD
References
TBD