Tokens on EmpoorioChain are managed by native FRAME pallets compiled directly into the runtime binary, not by permissionless on-chain programs a developer deploys themselves. There is no equivalent of deploying your own "token program" — you call the extrinsics exposed by whichever pallet matches the kind of token you need.
EmpoorioChain does not have a account/program-style permissionless program deployment model for native pallets. Adding genuinely new token logic at the pallet level requires a governed runtime upgrade. What follows below is about using the token pallets that are already compiled into the runtime today — which covers the overwhelming majority of real use cases (issuing an asset, minting an NFT collection, running a permissioned RWA token) without writing any new runtime code.
If you specifically want a per-application, permissionlessly-deployed token
contract (the closest thing to what another chain's token program gives you),
the closest equivalent is deploying a standard ERC-20 or ERC-721 Solidity
contract through EmpoorioChain's EVM-compatible layer (pallet-evm /
pallet-ethereum), using ordinary tooling like Hardhat, Foundry, or
ethers.js/viem pointed at the chain's Ethereum-JSON-RPC endpoint. That path
is real and shipped today.
Fungible tokens
See Fungible Tokens. Backed by pallet-emp-assets
(runtime index 23) — general create/mint/burn/transfer/freeze-style asset
management.
NFTs
See NFTs. Backed by pallet-uniques (runtime index
24) for standard NFT collections, and pallet-emp-nft (runtime index 53) for
additional NFT logic used by Eoonia Wallet.
RWA / permissioned tokens
See RWA & Permissioned Tokens. Backed by
pallet-emp-rwa (runtime index 54) for compliance-gated tokens representing
real-world assets.
Confidential transfers & data extensions
See Extensions. Covers pallet-privacy
(runtime index 17) for ZK-based confidential transfers and GDPR-style consent
management, and pallet-sbt (runtime index 66) for non-transferable /
soulbound tokens.
Exact extrinsic names and parameters below are described at a general,
capability level. Verify exact call signatures against live chain metadata
(e.g. api.rpc.state.getMetadata() via @polkadot/api, or your SDK's
generated bindings) before writing production code — some of these pallets
are wired into the runtime under aliases to upstream Substrate crates rather
than the exact custom crate documented in the project's internal pallet
inventory, so a hand-copied extrinsic list risks being stale or wrong.
Is this page helpful?