"Which VMs does it support?" is the first question a contract developer asks. EmpoorioChain's answer is short and worth stating precisely, because an older engineering document described a multi-VM engine that does not match what runs.
What runs
1. The runtime itself. EmpoorioChain's primary execution environment is not a virtual machine for user code; it is the FRAME runtime — 140 pallets compiled to WebAssembly and executed by the node's Wasm engine. Users do not deploy code here; they call functions the runtime already provides. This is where account abstraction, escrow, the DEX, NFTs, identity, compliance and the AI oracle live. It is the environment the ecosystem prefers, and the architecture document says when: whenever the chain can enforce a rule better than a contract could.
2. The EVM, through Frontier. pallet-evm, pallet-ethereum, pallet-base-fee, pallet-dynamic-fee, pallet-evm-chain-id (indexes 10–14). Solidity contracts deploy unmodified on chain id 2026; standard Ethereum JSON-RPC; EIP-1559 fees; precompiles 0x01–0x09 plus the ecosystem's 0xAA (AI oracle), 0x72 (ERC-721 view of native NFTs) and 0x1155 (multi-token view of native assets). Accepting real wallet transactions since runtime 211; gas 1 gwei since 220.
What does not run
Wasm smart contracts (ink!). pallet-contracts is declared as a dependency but is not in construct_runtime! and has no Config implementation. A feature flag named vm-wasm in the default build gives a false impression of support. The developer documentation says so plainly: Solidity through Frontier is the contract path. Whether to wire pallet-contracts or remove the dependency is an open decision, and the "wire it or retire it" rule applies.
Any other VM. No Move, no BPF-style bytecode VM, no CosmWasm. An earlier architecture document described "an abstract VM engine able to run multiple virtual environments"; that describes an intent, and this post describes the runtime.
Why native-first changes the question
On a chain whose value proposition is the rules live in the chain, adding VMs is not obviously good. Every additional VM is another place a rule can be reimplemented inconsistently, another audit surface, another set of tooling to keep in sync with runtime upgrades. The ecosystem's answer to "can I write a contract that does X?" is usually "the runtime already does X; call it" — through Polkadot.js, the SDKs, or from Solidity via a precompile.
The EVM is kept because the population of Solidity developers and tools is the largest in the industry and migration matters. A second contract VM would need a reason of that size.
For developers deciding
| You have… | Use |
|---|---|
| Solidity contracts, Ethereum tooling, MetaMask users | Frontier EVM on chain id 2026 |
| A need for protocol-level enforcement (compliance, royalties, sponsored fees, MEV protection) | Native pallets via SDK or Polkadot.js |
| ink! or other Wasm contracts | Not supported today |
| Both | One ledger — call pallets from the client, keep the contract small, reach native assets via 0x72/0x1155 |
Based on ARCHITECTURE.md, 02_CORE_SYSTEMS/EVM_AND_L2.md, PALLET_REFERENCE.md and the September 2026 documentation audit (pallet-contracts finding).