Concepts

Accounts and keys

An EAV7 address is not a truncated public key: it is a checksummed digest derived from TWO keys. Getting that straight removes half of the integration mistakes.

Format

How an address is assembled

Thirty-four characters with a checksum that turns a typo into a rejection instead of lost funds.

E7 A4B2C7D1E0F39A5B6C8D1E2F 9F21
│  │                        │
│  │                        └─ 4 hex de checksum: SHA3-256("EAV7-ADDR:" + corpo)
│  └─ 28 hex MAIÚSCULOS: 14 bytes do SHA3-256 do material da chave
└─ prefixo fixo do endereço (a HASH usa minúscula — não normalize os dois juntos)

34 caracteres no total.

Prefix: E7It belongs to the address. Hashes use the same prefix in LOWERCASE.
Length: 342 prefix + 28 body + 4 checksum.
Checksum: SHA3-256("EAV7-ADDR:" + corpo)The domain keeps this digest from colliding with any other SHA3 use in the protocol.

Case is not cosmetic

Addresses are UPPERCASE hex; hashes are lowercase. A client that normalizes both to the same case rejects valid addresses — and checksum validation catches it immediately.

Signing

Two keys, one account

The eav7-hybrid-1 scheme requires both signatures on every transaction. The classical one protects today; the post-quantum one protects the history against a future adversary.

secp256k1: publicKey · signatureThe classical curve, the same one Bitcoin and Ethereum use.
ML-DSA-44: pqPublicKey · pqSignatureLattice-based post-quantum signature (ML-DSA-44, FIPS 204).
Address: address_from_public_keys(ecdsa, pq)Derived from both public keys. The `from` field is not supplied: it is recomputed during verification.

You reimplement none of this

The SDK uses the same implementation the node uses to validate. A transaction built by the SDK and one built by the node are byte-for-byte identical.

Nonce

nonce and nextNonce

The nonce orders a sender's transactions and blocks replay. The API returns both numbers because they answer different questions.

curl -s https://eavscan.com/address/E7A4B2…9F21 \
  -H 'Accept: application/json'

{
  "balance": "12500000",
  "staked": "1000000000",
  "nonce": 41,
  "nextNonce": 42,
  "energy": 8000,
  "feeExempt": true,
  "isValidator": false,
  "unbonding": [],
  "tokens": []
}

nonce: The highest nonce this account has consumed in a block.
nextNonce: The next usable one, already counting this sender's mempool entries. This is the one to use.
MAX_FUTURE_NONCE_GAP: 64A nonce beyond confirmed + 64 is rejected: a gap that never executes is mempool litter.

Two writes in a row collide

Asking the node for nextNonce on every send is right for a single transaction and wrong for a burst: the second read returns the same number if the first has not reached the mempool yet. Use Remetente, which reserves locally.

EAVM

The 0x world and the native account

Every 0x account has a corresponding native account, and the balance is the same object. There is no value bridge between the two sides because there are not two sides.

0x ↔ E7

# regra padrão: qualquer 0x deriva uma conta nativa
0x71C7…9f21  ──►  E7 = derive("EAV7-EAVM:0x71c7…9f21")

# rota reservada: um E7 literal viaja dentro de um endereço de 20 bytes
0xe7000000 + 32 hex minúsculos  ──►  E7 + os mesmos 32 hex em MAIÚSCULA

# o saldo do mundo 0x É o da conta nativa correspondente — um ledger só

eavmToE7: derive("EAV7-EAVM:" + addr0x)Default rule: deterministic derivation under its own domain, with no extra state.
decodeE7Dest: 0xe7000000…Reserved route: a literal E7 address fits inside 20 EVM bytes, checksum included.
Unified ledger: The 0x world's balance IS the corresponding native account's balance. Value enters, circulates and leaves without getting stuck on either side.

Response

The fields of /address/:end

Monetary values come back as integer strings in e7. Formatting is your presentation layer's problem.

Field	Meaning
`balance`	Liquid balance in e7, available to spend.
`staked`	Weight locked in consensus. Not spendable while locked.
`nonce`	Highest nonce already consumed in a block.
`nextNonce`	Next nonce to use, aware of the mempool.
`gb`	GB · Free Signature quota: weighted bytes for the day ({max, available, used}).
`energy`	Energy available right now, with regeneration already applied (legacy pre-GB).
`feeExempt`	True once stake reaches FEE_EXEMPT_STAKE.
`isValidator`	True when the account is in the active set.
`unbonding`	UNSTAKE tranches waiting to mature, with the release height.
`claimableVoterReward`	Voter reward accrued and not yet claimed.
`tokens`	EAV20 token balances held by this account.

Where to go next