A chain's state is its memory: every balance, every NFT, every DID, every open order. How that state is modelled decides what the chain can do cheaply and what it cannot do at all. This post describes EmpoorioChain's state model and one rule that changed how the whole runtime is written.
Accounts
A native EmpoorioChain account is an AccountId32 — 32 bytes, typically the public key of an sr25519 or ed25519 keypair. In human form it is encoded as SS58 with prefix 2026, so every EmpoorioChain address is visually distinct from addresses on other Substrate chains.
Balances are u128 with 18 decimals for DMS. There is no separate "lamport" or "wei" name for the smallest unit in user-facing documentation; the SDKs and Eoonia format from base units to DMS at the edge.
One account, two views
EmpoorioChain runs Frontier, so it also has H160 Ethereum-style addresses. The mapping is deterministic: an EVM address corresponds to a native account derived from it, and native pallets can hold and move funds on behalf of EVM contracts. Eoonia Wallet exposes both views of the same underlying identity and lets a user move DMS between the native and EVM sides without a bridge — it is the same ledger. The chain id is 2026 on the EVM side and the SS58 prefix is 2026 on the native side; that coincidence is intentional.
Storage
Every pallet declares its storage items — maps, values, double maps — and those items are what a node persists in its database as a Merkle-Patricia trie. State reads and writes are what a transaction's weight charges for: the fee model prices bytes written and proof size, not only computation.
Two pallets exist specifically to keep the state healthy over years:
pallet-state-rentcharges for storage held by inactive accounts and reclaims it, so that the base fee per byte written can stay flat instead of rising as the trie grows.pallet-blob-storagekeeps large data (media, AI model shards, rollup data) out of the state trie: the chain stores a commitment, availability is verified through the storage oracle, and the bytes live in the storage market that Ouranoos and the node operators serve.
The bounded-state rule
Substrate lets a pallet declare a storage item as unbounded — a vector that can grow without limit. It is convenient during development and dangerous in production, because an unbounded item can make block import time grow without limit too, and a single hostile transaction can bloat it.
In runtime 215 EmpoorioChain adopted the rule that every storage item is bounded (BoundedVec, BoundedBTreeMap, explicit maxima), and audited the runtime for exceptions. The audit found something worth writing down: the obvious check — grepping for without_storage_info — misses items marked with #[pallet::unbounded], which is a per-item escape hatch rather than a per-pallet one. The audit had to look for both. That lesson is now part of the review checklist for every new pallet.
Why this is the opposite of "scale the state horizontally"
Some chains answer state growth by sharding it across machines. EmpoorioChain's answer is to keep the consensus-critical state small and bounded, charge rent for what lingers, push bulk data to a market that is paid to hold it, and let light clients verify inclusion with BEEFY/MMR proofs. A validator should be able to run on modest hardware for years. The reference machine for weight measurement is a 4-vCPU, 7 GB EPYC instance — and even that is a floor the team has not yet been able to benchmark against in a rented environment, which the docs record rather than hide.
Based on ARCHITECTURE.md, FEE_MODEL_AND_LOW_COST_STRATEGY.md, RED.json and the runtime 215 bounded-state audit.