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). This is the canonical account type across the whole runtime.
Account Structure
AccountId32 and SS58 addresses, the EVM H160-via-hash-mapping layer, and the Existential Deposit.
Account Types
Native accounts vs. EVM pallet accounts, and why EmpoorioChain doesn't split accounts into EOA/contract-account the way Ethereum does.
Key facts
- One canonical account type: There is no separate EOA/contract-account split at the account-type level. A single AccountId32 model covers wallets, and most application state lives in pallet storage rather than per-account contract storage.
- EVM addresses are a secondary, derived layer: Solidity contracts and
EVM-style accounts on the built-in EVM pallet use 20-byte H160 addresses,
each mapped to a native AccountId32 through a one-way Blake2-256 hash
(
pallet_evm::HashedAddressMapping<BlakeTwo256>) — not a truncated or reversible 1:1 mapping. - Existential Deposit (ED): accounts must hold a minimum DMS balance to exist in state. Accounts that fall below it are reaped. This is conceptually similar to Ethereum's storage-cost tradeoffs but enforced differently — there is no per-byte "rent" the way earlier other chains docs described.
- No permissionless per-account contract deployment: unlike Ethereum, creating a new "contract account" for ordinary application logic isn't how EmpoorioChain works. New on-chain behavior is added by extending a pallet through a governed runtime upgrade, or by deploying Solidity to the EVM pallet (see Programs).
For the full Ethereum-to-EmpoorioChain account comparison, including a field-by-field table, see EVM to EmpoorioChain: Accounts on empoorio.org.
Is this page helpful?