An address is used to identify private key holders when transferring value. Most addressing systems follow this pattern;
- Users control private keys
- Addresses are used to identify private key owners without exposing the private key itself
- Addresses are derived from public keys
- Using a signature signed from the private key and the message the private key signed, the public key can be recovered
- The address generation function changes from Virtual Machine to Virtual Machine.
Avalanche is not prescriptive about addressing schemes. Each Virtual Machine (VM) may select its own addressing scheme.
- Follows the Ethereum VM addressing system.
- Uses a secp256k1 public/private keypair.
- Uses the 64-byte address; a hashing function called keccak256 is applied to the byte array. The resulting hash is truncated to the first 20 bytes. The address string is represented as a hexadecimal value, always prefixed with “0x”.
- Uses a binary 20-byte array for the raw address.
- Obtains the 33-byte public key of the Secp256k1 keypair.
- This public key is hashed once using SHA256. The resultant hash is then hashed again using RIPEMD160, producing a byte array of length 20.
There are conventions in Avalanche for distributing readable addresses. All addresses are Bech32 encoded. By convention, the blockchainID for the address is prepended to the address in the format chainID-address. Aliases for chainID may be used as well. Example:
- P-Chain Address
- C-Chain Address
- X-Chain Address
- Same address on a different chain:
- Same address, using the chainID instead of the chain alias:
In our Bech32 standard, there are pre-defined HRPs for our addresses:
- NetworkID 1: avax
- NetworkID 2: cascade
- NetworkID 3: denali
- NetworkID 4: everest
- NetworkID 5: fuji
- NetworkID 12345: local
- Other NetworkIDs: custom