Account Model

TL;DR

Asentum uses an account model (not UTXO), same shape as Ethereum. Addresses are 20 bytes, rendered as 0x-prefixed hex with an EIP-55 mixed-case checksum. Two kinds of accounts exist: externally-owned accounts (EOAs, controlled by a Dilithium3 keypair) and contracts (controlled by deployed JavaScript code). Every account has a balance and a nonce.

Address format

Addresses are 20 bytes, presented as 40 lowercase hex characters with an EIP-55 mixed-case checksum overlaid on top. Example:

0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B

A wallet that ignores the checksum accepts the all-lowercase form. A wallet that honors it verifies the mixed-case digest and rejects addresses where the case doesn't match — which catches most transcription errors.

Address derivation

address = BLAKE3(pubkey)[0:20]

The pubkey is a Dilithium3 (ML-DSA-65) public key — around 1.9 KB. We hash with BLAKE3 and take the first 20 bytes. Ethereum uses keccak256(pubkey)[12:32] — same 20-byte size, different hash, different slice. Addresses are not interoperable across chains.

Contract addresses are derived differently — they are the BLAKE3 hash of the deployer's address plus the deployment nonce, truncated to 20 bytes. This is deterministic: you can compute a contract's address before deploy.

EOA vs contract

• Externally-owned account (EOA) — holds ASE, signs transactions with a Dilithium3 keypair. No code. This is what a wallet like the Asentum Wallet extension or the CLI manages for you.
• Contract account — holds ASE, has code (JavaScript source), has storage. Cannot initiate transactions, but can be called by EOAs or by other contracts via async message-passing. Source is stored on-chain and accessible via eth_getCode.

From outside, they look the same — both are 20-byte addresses with balances. The explorer distinguishes them by whether getCode returns a non-empty body.

Nonces

Every EOA has a nonce — a sequential transaction counter. Every signed transaction includes the sender's current nonce. The chain rejects a tx if:

• The tx nonce is lower than the account's current nonce (already used → replay attempt).
• The tx nonce is higher than current nonce + mempool depth (skips in the sequence).

Nonces are what make transactions replay-safe. If you need to submit multiple txs quickly from one account, either queue them with strictly increasing nonces or let your wallet manage them.

Balances

Balances are stored in wei — 10^-18 ASE. Every balance and every value in a transaction is a 256-bit integer. There are no fractional wei.

1 ASE = 10¹⁸ wei. Same denomination as Ether. Use parseAse / formatAse from the SDK to convert.

No HD derivation in v1

Ethereum wallets use BIP-32 HD derivation over secp256k1 to generate arbitrary numbers of accounts from a single seed. This does not yet exist for post-quantum keypairs — there is no production-ready BIP-32 equivalent for Dilithium3.

In v1 we treat each account as an independent keypair. The Asentum Wallet, Operator, and CLI all support multiple accounts inside one vault by storing independent Dilithium3 secret keys, each encrypted under the same master password. For backup, see Recovery Phrases.