Account Model
20-byte addresses, EIP-55 checksums, and two account types — familiar shape, different cryptography underneath.
TL;DR. Aevum uses an Ethereum-shaped account model: 20-byte hex addresses with EIP-55 checksums, externally-owned accounts controlled by Dilithium3 keypairs, and contract accounts controlled by JavaScript — both with a balance and a nonce.
Aevum uses an account-based model, deliberately close to Ethereum's shape. Addresses are 20 bytes, shown as hex with an EIP-55 checksum. There are two account types — externally-owned accounts, controlled by a Dilithium3 keypair, and contracts, controlled by JavaScript code — and both hold a balance and a nonce.
Address format
An address is 20 bytes, displayed as 40 lowercase hex digits with an EIP-55-style mixed-case checksum on top — for example, 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B. Wallets that ignore the checksum just accept the lowercase form; wallets that enforce it use the case pattern to catch transcription mistakes.
Address derivation
The Dilithium3 (ML-DSA-65) public key — about 1.9KB — gets hashed with BLAKE3, and the first 20 bytes become the address. Ethereum does something similar with keccak256(pubkey)[12:32] — same byte length, different hash function and slice position, which means addresses aren't cross-chain compatible by coincidence.
Contract addresses derive the same way, from BLAKE3 of the deployer's address combined with the deployment nonce, truncated to 20 bytes. That means a contract's address is computable before it's deployed.
EOA vs contract
Externally-owned accounts hold AEV, sign transactions with a Dilithium3 keypair, and have no code. The Aevum Wallet extension or CLI manage these for you.
Contract accounts hold AEV, contain JavaScript source, and maintain their own storage. They can't initiate a transaction on their own — they only respond to calls from an EOA or another contract via async message-passing. The source is retrievable on-chain through eth_getCode.
From the outside, both look the same: a 20-byte address with a balance. Explorers tell them apart by checking whether getCode returns anything.
Nonces
Every EOA tracks a nonce — a sequential counter, incremented once per transaction. Each signed transaction carries the sender's current nonce, and the chain rejects a transaction if the nonce is below the account's current value (a replay) or too far ahead of it (a sequence gap past the mempool depth).
Sending several transactions quickly from one account means either incrementing the nonce strictly in sequence yourself, or letting your wallet manage it.
Balances
Balances are denominated in wei — 10⁻¹⁸ AEV — the same scheme as Ether. Every balance and transaction amount is a 256-bit integer; there's no fractional wei. 1 AEV equals 10¹⁸ wei, and the SDK's parseAev and formatAev handle the conversion for you.
No HD derivation in v1
Ethereum wallets use BIP-32 HD derivation over secp256k1 to generate many accounts from one seed. There's no production-ready BIP-32 equivalent for Dilithium3 post-quantum keypairs yet.
In v1, every account is an independent keypair. The Aevum Wallet, Operator, and CLI support multiple accounts in one vault by holding several separate Dilithium3 secret keys, all encrypted under the same master password, with a recovery phrase for backup.