Ethereum's great strength is that anything can be built as a contract. Its great weakness is that everything has to be. Account abstraction is a contract standard (ERC-4337) that every wallet must integrate separately; royalties are a hint (ERC-2981) that marketplaces may ignore; MEV protection is an off-chain relay market. EmpoorioChain's position is that when the chain itself can enforce a rule better than a contract can, it should — and Frontier remains available for everything else.
Here are eight of those rules, each with the Ethereum standard it corresponds to and the pallet that implements it natively.
1. Account abstraction — ERC-4337 → pallet-account-abstraction + pallet-paymaster
User operations, bundlers and session keys are runtime concepts. A paymaster can sponsor a user's fees under policies validated at the entry point — whitelisted accounts, per-transaction limits, allowed pallets — so a new Eoonia user's first actions can be gasless without the paymaster being drainable. Because it is a pallet, every wallet and every indexer understands it without a per-app integration.
2. Permit approvals — ERC-2612 → pallet-permit
Signed allowances with nonce and deadline validation, for any native asset, not only tokens whose contract happened to implement the standard.
3. Token-bound accounts — ERC-6551 → pallet-nft-wallet
An NFT can own things. On Ethereum that requires a registry contract and a proxy per token. Here the NFT's identity is an L1 account boundary: the runtime knows that assets held by an NFT's wallet move when the NFT moves.
4. Blob data availability — EIP-4844 → pallet-blob-storage + pallet-storage-oracle
Large data is committed on chain and stored off chain in the storage market; the oracle verifies availability. This is what lets EmpoorioChain act as a settlement and data-availability layer for rollups without depending on an external DA network.
5. MEV protection — PBS/relay patterns → pallet-mev-protection
Commit-reveal ordering, private order flow and fair queues at the protocol level. On Ethereum this lives in an out-of-protocol relay market; here a DEX trade can opt into protected ordering that every block author must honour.
6. NFT royalties — ERC-2981 → pallet-nft-royalties + pallet-music-nft
Collection- and token-level royalty rules that the runtime enforces on transfer, not a metadata field a marketplace can skip. This is the mechanism EidoOS and the Creator Studio rely on for creator payouts.
7. Flash loans — ERC-3156 → pallet-flashloan
Native liquidity pools with fee accounting, atomic within a single extrinsic, without a contract needing to hold the pool.
8. Permissioned and regulated assets — ERC-3643 / ERC-1400 → pallet-compliance + pallet-identity-ssi + pallet-emp-rwa + pallet-sanctions
Transfer restrictions, identity requirements (through KryptoOS DIDs and credentials) and sanctions screening enforced chain-wide. A real-world-asset token cannot be moved to an address that fails the rule, regardless of which app initiated the transfer.
The rule behind the list
The engineering docs state when a native pallet is preferred: when protocol-level storage is safer than contract storage; when runtime events are easier for indexers than fragmented contract events; when fees, deposits or slashing must be enforced by the L1; when governance or compliance must be chain-wide; and when SDK users should not need Solidity or ABIs. Conversely, Frontier is the right door when a project must migrate Solidity with minimal changes, when MetaMask support is required, or when existing Ethereum tooling is simply the fastest path.
The full mapping — including EIP-155, EIP-1559, ERC-20/721/1155, ERC-4626, EIP-712, ERC-5192 and ERC-4907 — is maintained in the EIP_COVERAGE.md document in the chain repository. Every pallet in this list is wired into the live runtime; what remains uneven is how much of each is exercised by real traffic on a testnet that only recently started carrying signed transactions at all. That is the honest state, and it is the reason the next posts in this series are about measurement rather than features.
Based on EIP_COVERAGE.md and ARCHITECTURE.md.