Addresses

Babylon addresses are Bech32m encoded.
Examples of such addresses include:

• resource_rdx123456789aaaaaaaaaaaaaaa580632205aaaaaaaaaaaaaaaaradxrd
• package_tdx_24_1qyqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqsc8dfjn
• account_tdx_c_1pzg7l46zndnsluatt7dvyvvjuynzal3wa8rylqggh8xs2er2em
• epochmanager_tdx_b_1qsqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq90hq99

The Toolkit can generate virtual account addresses for you from a Ed25519 or Secp256k1 public key, so you shouldn’t need to implement Bech32m encoding/decoding yourself.

Address display

When displaying entity addresses for users in limited space, developers should abbreviate them in a consistent way.

The Radix standard is to abbreviate using the first 4 and last 6 characters separated by an ellipsis (4…​6) - and this format will be what the user expects from their wallet. The full address should be expandable, and visible on hover, and have a button to easily copy the address.

For example, a friendly list of resources for a user might show something like this:

Dallas Mavericks Tickets (reso…​8acdfi)

More details can be found on our docs site here.

Address content

The addresses start with a prefix called a “HRP”. The address format more specifically is the concatenation of these sub-parts:

• HRP:
  • Entity Type Prefix. The prefix to use can be derived from the address itself. Some common examples include:
    • account_ for account addresses
    • resource_ for fungible and non-fungible resources (assets), including XRD
    • package_ for Dapp code
    • component_ for instantiated Dapps
  • Network Prefix:
    • rdx for mainnet
    • tdx_<hex_id>_ for test nets
    • sim for the Radix Engine simulator
• The character “1” acts as a separator in the Bech32m format.
• Address - this is Bech32m encoding of the 30 address bytes - the underlying bytes consist of:
  • 1 byte: for the “Entity Type”
    • This gives more information about the type of entity. EG a Secp256k1 virtual account will have a different entity type id byte than a Ed25519 virtual account.
  • 29 other bytes, forming the core of the address:
    • For most addresses, this is generated by the engine to be a UUID.
    • For virtual account and identity addresses, this is 29 characters from the hash of the public key which will be used to set-up the initial owner of the account when it is automatically instantiated on first interaction. Once instantiated, the account’s access might be changed, and so the public key may no longer provide access to the account in future. Note this differs from Olympia, where the full 33 bytes of the public key was used.
    • For some system addresses created in genesis, a fixed address is used.
• Checksum:
  • The last 6 characters of a Bech32m address are a checksum