Summary
There is no single "deploy a program" flow on EmpoorioChain. Native pallet logic reaches the chain through a governed runtime upgrade. Solidity contracts deploy permissionlessly through the EVM pallet, the normal Ethereum way. ink!/WASM contract deployment does not currently work, despite the dependency existing in the source tree.
Path 1: governed runtime upgrades (native pallets)
Adding or changing native functionality means adding to or modifying a
pallet in the runtime's Rust source, then shipping the result as a new
compiled WASM runtime blob. That blob is proposed through EmpoorioChain's
on-chain governance process; once approved, it activates for every account
on the network simultaneously via system.setCode (or the scheduled
equivalent), without anyone redeploying anything per application.
This is a fundamentally different security and operations model from Ethereum's or other chains' "anyone can deploy new code at any time": adding new on-chain logic on EmpoorioChain requires governance approval, not just a signed transaction and a fee.
Most application developers never need to go through this path. Calling an existing pallet's dispatchable functions through the SDK or CLI covers the large majority of what an app needs to do on-chain.
Path 2: Solidity via the EVM pallet
For a permissionless, per-app deployment workflow closer to Ethereum's,
EmpoorioChain's built-in EVM compatibility pallet (pallet-evm +
pallet-ethereum, part of the Frontier stack, compiled in by default) lets
you deploy Solidity contracts using standard Ethereum tooling — Hardhat,
Foundry, ethers.js/viem — pointed at EmpoorioChain's EVM-JSON-RPC endpoint,
the same way you would on any EVM-compatible chain. Contracts deployed this
way follow the familiar Ethereum immutable-unless-proxied model.
contract Counter {int private count = 0;function incrementCounter() public {count += 1;}function getCount() public view returns (int) {return count;}}
What doesn't work yet: ink!/WASM contracts
EmpoorioChain's runtime declares pallet-contracts as a dependency behind a
vm-wasm feature flag that is on by default in the workspace configuration.
This can look like ink!/WASM smart contracts are supported. They are not,
as of this writing:
- There is no
Contracts:entry in the compiledconstruct_runtime!block, and noimpl pallet_contracts::Config for Runtimeanywhere in the runtime source. - The runtime ships a custom WASM VM adapter whose own methods return an explicit "not supported" error for contract load, instantiate, and execute calls — the project's own source comments confirm this adapter does not execute WASM contract bytecode. (An earlier version of this adapter had a real bug where it silently reported success for every WASM contract call without executing anything or charging gas; that bug was fixed as part of a security remediation pass, and the adapter now correctly fails instead of faking success.)
Until pallet-contracts is actually wired into the compiled runtime with a
real configuration, treat any claim of working ink!/WASM contract deployment
on EmpoorioChain as false, regardless of what the dependency list in
Cargo.toml suggests.
Summary
| Native pallets | EVM pallet (Solidity) | ink!/WASM | |
|---|---|---|---|
| Deployment model | Governed runtime upgrade | Permissionless, standard Ethereum tooling | Not currently working |
| Who can add logic | Requires governance approval | Anyone | — |
| Typical developer workflow | Call existing pallets' dispatchable functions | Deploy and call contracts via Hardhat/Foundry/ethers.js | — |
Is this page helpful?


