Crypto Wallets (or Accounts) can be created and represented in unique ways on different blockchains. For developers who interface with account types on Areon, e.g. during wallet integration on their dApp frontend, it is therefore important to understand that accounts on Areon are implemented to be compatible with EVM addresses.
To create one account you can either create a private key, a keystore file (a private key protected by a password), or a mnemonic phrase (a string of words that can access multiple private keys).
Aside from having different security features, the biggest difference between each of these is that a private key or keystore file only creates one account. Creating a mnemonic phrase gives you control of many accounts, all accessible with that same phrase.
Blockchains like Areon, support creating accounts with mnemonic phrases, otherwise known as hierarchical deterministic key generation (opens in a new tab) (HD keys). This allows the user to create accounts on multiple blockchains without having to manage multiple secrets.
HD keys generate addresses by taking the mnemonic phrase and combining it with a piece of information called a derivation path (opens in a new tab). Blockchains can differ in which derivation path they support. To access all accounts from an mnemonic phrase on a blockchain, it is therefore important to use that blockchain's specific derivation path.
The terms "account" and "address" are often used interchangeably to describe crypto wallets. In Areon, an account designates a pair of public key (PubKey) and private key (PrivKey). The derivation path defines what the private key, public key, and address would be.
The PrivKey is used to generate digital signatures to prove that an address associated with the PrivKey approved of a given message. The proof is performed by applying a cryptographic scheme to the PrivKey, known as Elliptic Curve Digital Signature Algorithm (ECDSA), to generate a PubKey that is compared with the address in the message.
Areon defines its own custom Account type to implement a HD wallet that is compatible with Ethereum type addresses. It uses Ethereum's ECDSA secp256k1 curve for keys (eth_secp265k1) and satisfies the EIP84 for full BIP44 paths. This cryptographic curve is not to be confused with Bitcoin's ECDSA secp256k1 curve.
The root HD path for Areon-based accounts is
m/44'/60'/0'/0. Areon uses the Coin type 60 to support Ethereum type accounts.
The custom Areon EthAccount satisfies the
AccountI interface from the Areon auth module and includes additional fields that are required for Ethereum type addresses:
BIP-0173 (opens in a new tab) defines a new format for segregated witness output addresses that contains a human-readable part that identifies the Bech32 usage. Areon uses the following HRP (human readable prefix) as the base HRP:
There are 3 main types of HRP for the addresses available by default on Areon:
- Addresses and Keys for accounts, which identify users (e.g. the sender of a
message). They are derived using the
- Addresses and Keys for validator operators, which the operators of validators. They are derived using the
- Addresses and Keys for consensus nodes, which identify the validator nodes participating in consensus. They are derived using the
|Address bech32 Prefix||Pubkey bech32 Prefix||Curve||Address Byte Length||Pubkey Byte Length|
EthAccount can be represented in both Bech32 (opens in a new tab)
(areon...) and hex
(0x...) formats for Ethereum's Web3 tooling compatibility.
The Bech32 format is the default format for SDK queries and transactions through CLI and REST clients. The hex format on the other hand, is the Ethereum
- Address (Bech32):
- Address (EIP55HEX):