A blockchain is a state machine: a set of rules that turns the previous state plus a block into the next state. On most chains those rules live in the node software, and changing them means convincing every operator to download a new binary before a flag day — a hard fork. On EmpoorioChain the rules live in the state: the runtime is a WebAssembly blob stored on chain, and upgrading it is a transaction.
This post is about how that works, the policy that governs it, and the day it was used for real.
The runtime as data
Nodes contain a Wasm executor. When they import a block, they execute the runtime stored at :code in the state — not the one compiled into the node binary (which is only a fallback). A runtime upgrade is a call that replaces :code. From the next block, every node applies the new rules, automatically, in lockstep, with no coordination beyond the chain itself.
Each runtime carries a version. Two fields matter to clients:
spec_version— increments on every upgrade. The live network is at 220.transaction_version— increments only when the format of transactions changes. Currently 6.
Both are signed into every transaction, so a wallet built for an old runtime fails safely instead of doing something unexpected. A practical corollary that surprised more than one integrator: the runtime metadata changes in every upgrade, because the version is part of it. Clients must refresh metadata after each upgrade, not only when calls change.
The upgrade policy
Upgrades are classified, and each class carries a minimum timelock and mandatory evidence:
| Class | Use | Minimum timelock (testnet) | Evidence |
|---|---|---|---|
normal | Improvements with no economic change, no critical migration, no new privileges | 7,200 blocks (~12 h) | Reproducible build, metadata diff, runtime tests |
security | Vulnerability patches, PQC, permissions, wallet signing, bridge, RPC or consensus | 28,800 blocks (~48 h) | All of the above plus an updated threat model and security approval |
economic | Fees, paymaster, staking, treasury, tokenomics, slashing, rewards | 28,800 blocks | Economic simulation, fee impact analysis, migration dry-run |
emergency | Active incident or imminent loss | 1,200 blocks (~2 h) | Justification, blast radius, rollback plan, mandatory post-mortem |
Every upgrade publishes a JSON manifest: runtime hash, spec versions before and after, metadata hashes before and after with a diff summary, whether it migrates storage, the try-runtime report and dry-run hash if it does, the rollback plan and the approvals. EmpooScan indexes the proposal, the hash, the timelock and the ETA; Eoonia queries governance and warns users before they sign anything sensitive during a security or economic upgrade window.
The principles above the table: confirmed history is never rewritten; every change is traceable by hash, version and proposal; nothing economic or security-related executes without a timelock and reproducible evidence; storage migrations are tested with try-runtime first; emergency upgrades shorten the timelock but never skip the audit trail.
The day it became real
Until September 2026 the testnet had never been upgraded in place — every runtime change had shipped by relaunching from genesis. On 4 September 2026 runtime 208 was applied to the live chain as its first real upgrade, and the genesis hash (0xe973931e…eae7aa) has been stable since. Between then and 14 September the network moved through 211, 213, 215, 217, 218, 219 and 220, each with its manifest. Among them:
- 211 made the EVM accept self-contained Ethereum transactions — MetaMask and Hardhat can now send to the chain.
- 213 moved storage billing from whole gigabytes to bytes.
- 215 enforced the bounded-state rule across the runtime.
- 220 set EVM gas to 1 gwei, wired the DEX treasury and saw the first real swap and the first DID registered on the network.
The upgrade path is also how a lesson from those weeks was learned: a post_upgrade check must verify that its own migration applied, not assert facts about the world ("this storage is empty") that the migration did not control. Four such checks were rewritten.
Mainnet gate
Mainnet stays blocked until the same flow has been rehearsed on the testnet with at least one normal upgrade, one with a storage migration, one economic upgrade and one emergency drill with rollback. The first two have now happened. The state machine changes its rules in public, on a schedule, with receipts.
Based on RUNTIME_UPGRADE_POLICY.md, RED.json and the runtime upgrade records for 208–220.