See how accounts differ when building on Ethereum and EmpoorioChain.
Table of Contents
Both Ethereum and EmpoorioChain are account-based chains, but they structure accounts very differently. Ethereum ties execution logic and storage together inside a contract account; EmpoorioChain, as a Substrate chain, keeps a single global account model (AccountId32) and stores most application state inside pallets rather than per-contract storage.
In Ethereum, an 'account' refers to an entity that owns Ether and can send transactions. It includes addresses necessary for deposits and withdrawals and is categorized as follows:
A key difference between EOA and CA in Ethereum is that EOA, not being a smart contract, typically does not have its own storage.
An Externally Owned Account (EOA) is an account with a private key; possessing a private key means controlling access to funds or contracts.
Addresses are 20-byte, 0x-prefixed values derived from the account's public key.
| Field | Description |
address | An account's 20-byte 0x-prefixed address |
balance | The amount of ETH (in wei) an address owns |
nonce | A counter of transactions sent from the account, preventing replay |
code hash | Hash of the deployed bytecode, for contract accounts |
storage hash (storage root) | Root of the account's Merkle Patricia Trie storage |
A Contract Account holds smart contract bytecode that an EOA cannot hold. It has no private key — it is controlled entirely by its own code, which executes inside the EVM whenever a transaction targets it.
Because a Contract Account cannot sign, it cannot originate a transaction on its own. This is the root cause of the account-abstraction problem ERC-4337 addresses on Ethereum.
EmpoorioChain, built on Substrate, identifies every account by an AccountId32 — a 32-byte public key, normally displayed in SS58 format (a base58-encoded address with a network-specific prefix and checksum, similar in spirit to Bitcoin's Base58Check but distinct from Ethereum's 0x hex addresses). There is no separate EOA/contract-account split at the account-type level.
State is not stored inside per-account contract storage the way it is on Ethereum. Instead, each pallet (a native runtime module, see the Smart Contracts page) owns its own storage items — balances, assets, NFTs, governance proposals, and so on — keyed by AccountId32 where relevant. EmpoorioChain also ships an EVM compatibility pallet, so 0x-style H160 addresses exist too, but only within that EVM execution environment (registered EVM chain ID 2026), mapped back to a native AccountId32.
| Field | Description |
AccountId32 | The account's 32-byte public key, shown in SS58 format |
data.free / data.reserved | Free and reserved DMS balance, tracked by the balances pallet — the rough equivalent of balance |
nonce | Transaction counter, same purpose as Ethereum's nonce |
| [no single equivalent] | Executable logic lives in pallets compiled into the runtime, not in per-account code |
| Existential Deposit (ED) | The minimum balance an account must hold to exist in state — accounts below it are reaped, conceptually similar to Ethereum's storage-cost tradeoffs but enforced differently |
Because pallets are compiled into the runtime rather than deployed per application, there is no equivalent of 'deploying a new contract account' for ordinary app logic on EmpoorioChain. Adding new on-chain behavior means adding or extending a pallet through a runtime upgrade (governed on-chain), or — for teams that want a familiar per-app deployment workflow — deploying Solidity to EmpoorioChain's built-in EVM pallet instead.
In practice, EmpoorioChain accounts split along a different axis than Ethereum's EOA/CA split:
EmpoorioChain calls a runtime module a 'pallet', not a 'contract' — the terminology intentionally signals that it is compiled into the chain, not deployed to it.
| Ethereum's Account | EmpoorioChain's Account |
address (20-byte, 0x-prefixed) | AccountId32 (32-byte, SS58-encoded) |
balance | balances pallet: data.free / data.reserved |
nonce | nonce |
code hash + storage hash | [no equivalent] — logic and most state live in pallets, not per-account |
| [no equivalent] | Existential Deposit (ED) |
| Contract Account (CA) | EVM pallet account (H160), mapped to an AccountId32 |
| EOA (Externally Owned Account, Wallet) | -> AccountId32 | Signs extrinsics with sr25519/ed25519. |
| CA (Contract Account) | -> Pallet, or EVM pallet H160 account | Pallets are compiled into the runtime, not deployed per app. |
Ethereum has long explored account abstraction. Because EOAs and CAs are strictly separated, and CAs cannot sign or originate transactions, every action must ultimately be initiated by an EOA paying gas — which constrains multisig wallets, session keys, sponsored transactions, and social recovery.
ERC-4337 relaxes this by letting a smart-contract wallet originate a transaction-like 'UserOperation' through a separate mempool and bundler/EntryPoint contract, without changing the base protocol:
The tradeoff is architectural: ERC-4337 is implemented as a standard layered on top of Ethereum, using an alternate mempool, bundlers, and an EntryPoint contract that every smart-contract wallet must integrate with.
It solves a real, protocol-level limitation of the EOA/CA split — a limitation that does not exist in EmpoorioChain's account model in the first place (see below).
In summary, account abstraction targets benefits like:
EmpoorioChain addresses fee sponsorship and flexible authorization natively rather than through a standard bolted on top. pallet-paymaster lets a third party sponsor transaction fees, and pallet-account-abstraction provides programmable authorization for native accounts, without a separate mempool, bundler, or EntryPoint contract. Solidity contracts deployed to EmpoorioChain's EVM pallet can still adopt ERC-4337 the normal Ethereum way if a team wants that specific integration path, but pallet users do not need to.
EVM TO EMPOORIOCHAIN
