Programs

EmpoorioChain does not have an equivalent of other chains' permissionless, per-account on-chain program deployment model. Instead, on-chain logic is added and used in two different ways, and it's important to know which one you're dealing with.

Native pallets: compiled in, not deployed

Most of EmpoorioChain's functionality — fungible assets, NFTs, governance, DeFi primitives, storage markets, AI-related functionality, and well over a hundred other domains — ships as pallets: Rust modules compiled directly into the runtime binary and assembled at compile time via construct_runtime!. A pallet defines its own storage items, events, errors, and dispatchable calls (the pallet equivalent of a smart contract's public functions).

For an app developer, this means the overwhelmingly common workflow on EmpoorioChain is calling the dispatchable functions of an existing pallet — transfer an asset, mint an NFT, open a governance proposal, submit a storage deal — via extrinsics, not writing and deploying new on-chain code. New pallet logic (or a change to an existing pallet) requires a governed runtime upgrade: a new WASM runtime blob approved through the chain's governance process and activated for every account on the network simultaneously.

The EVM pallet: permissionless Solidity deployment

For teams that specifically want an Ethereum-style, permissionless per-app deployment workflow, EmpoorioChain ships a built-in EVM compatibility pallet (pallet-evm + pallet-ethereum, part of the Frontier stack, compiled in by default). Solidity contracts can be deployed and called through it using standard Ethereum tooling — Hardhat, Foundry, ethers.js/viem — pointed at EmpoorioChain's EVM-JSON-RPC endpoint. This is the closest thing EmpoorioChain has to other chains' "anyone can deploy a program" model, and it's real and shipped, not aspirational.

ink!/WASM contracts: not currently working

EmpoorioChain's dependency tree includes pallet-contracts (the Substrate/ink! smart-contract pallet) behind a vm-wasm feature flag that is on by default — which can give the impression that ink!/WASM contract deployment is supported. It is not. There is no Contracts entry in the compiled runtime and no Config implementation for the pallet. A runtime WASM VM adapter exists, but its own source comments confirm it does not execute WASM contract bytecode. Do not rely on ink! contract deployment until this is explicitly wired in and documented as working.