Account Types

No account-type split for executable code

On account/program chains, an account's executable flag determines whether it holds program bytecode or user data. On Ethereum, an account is either an Externally Owned Account (has a private key, no code) or a Contract Account (has code, no private key). EmpoorioChain's native account model has no equivalent split. Every AccountId32 is the same kind of account at the type level — it can sign extrinsics and hold a DMS balance, and any application state it's associated with lives in a pallet's own storage items, not inside the account itself.

This is a direct consequence of how EmpoorioChain adds functionality: most of it ships as pallets — Rust modules compiled directly into the runtime binary — rather than as separate programs deployed to individual accounts. See Programs for how that works and how it compares to Ethereum's and other chains' deployed-program models.

Native accounts (AccountId32)

Native accounts hold DMS and pallet-tracked assets, and sign extrinsics with sr25519, ed25519, or ecdsa keys. This is the closest EmpoorioChain equivalent to another chain's system account or an Ethereum EOA — every wallet on the network is a native account, and the fee payer on a transaction must be one.

Genesis and system accounts (the treasury, the AI reward pool, the faucet) are also just AccountId32 constants declared in the runtime — there is no separate "system account" type, only ordinary AccountId32 accounts used for specific purposes by convention.

EVM pallet accounts (H160)

Solidity contracts and EVM-style accounts deployed through the built-in EVM pallet use 20-byte H160 addresses, matching Ethereum tooling expectations. Every H160 address maps to a native AccountId32 under the hood (see Account Structure). Within the EVM pallet's execution environment, the familiar Ethereum EOA/contract-account distinction does apply, because that's the model Frontier (EmpoorioChain's EVM compatibility layer) reproduces for Solidity compatibility — it just sits on top of the native account model rather than replacing it.

Where state actually lives

Because pallets are compiled into the runtime rather than deployed per account, most application state lives in pallet storage items — storage maps and values a pallet defines for itself (balances, NFT ownership, governance proposals, storage-market deals, and so on), often keyed by AccountId32 where relevant. This is a meaningfully different mental model from "fetch an account and read its data field": to read a token balance, for example, you query the assets pallet's storage for a given (asset_id, AccountId32) pair rather than fetching a single account object that itself contains the balance.