Native Asset Pallets
Instead of deploying a new contract per token, EmpoorioChain registers each fungible asset as an entry in pallet-emp-assets, a single audited runtime module shared by every token on the chain. Confidential transfers are handled by a separate module, pallet-privacy, which is currently going through a security hardening pass — see the FAQ below for its current status before building on it.
pallet-emp-assets is a confirmed, live runtime module with 24 extrinsics. Dig into the ERC-20-to-pallet migration guide for the technical explanation, storage layout, and how it compares to per-token contracts.
Register a new asset ID in pallet-emp-assets and your stablecoin inherits the same audited mint, transfer, and balance logic every other asset on EmpoorioChain uses — no new contract to write or audit per token.
pallet-emp-assets stores basic metadata (name, symbol, decimals) directly in its own storage per asset ID, set at registration time through a dedicated extrinsic — no separate metadata contract to deploy or keep in sync.
EmpoorioChain's compliance suite includes pallet-emp-rwa, a native pallet for permissioned, real-world-asset-style tokens that sits alongside pallet-emp-assets — eligibility, freezing, and forced-transfer logic are enforced by the runtime itself for any asset registered under it, rather than by ad-hoc per-token contract code.
pallet-privacy is EmpoorioChain's ZK-based module for masking transfer amounts while preserving auditability. It is currently undergoing a security hardening pass following a recent testnet incident, so treat confidential-transfer guarantees as in-progress rather than a finished production claim until that work lands — check the current pallet reference for its live status before relying on it.
Want to build? Get in touch.
Frequently Asked Questions
pallet-emp-assets is the native runtime module EmpoorioChain uses for fungible tokens — a confirmed, live pallet exposing 24 extrinsics. Instead of deploying a new contract per token, you register a new asset ID in this pallet's own storage map, the same way pallet-uniques manages every NFT collection. There is no separate contract address to deploy, because the logic already lives in the pallet.
On Ethereum, each token is its own independently deployed and audited contract, uniquely identified by its contract address. On EmpoorioChain, every fungible asset is an entry in pallet-emp-assets' storage, identified by an asset ID rather than a contract address — the pallet's logic ships once with the runtime instead of once per deployed token.
ERC-20 (one contract per token)
pallet-emp-assets (one pallet, many assets)
Assets registered in pallet-emp-assets are native to the Substrate side of the runtime. Bridging them into the EVM compatibility layer — or into Eoonia Wallet's cross-chain flows — goes through EmpoorioChain's own bridge/precompile interface rather than a standard ERC-20 ABI. Check the current EmpoorioChain SDK/pallet reference for the exact interface, since implementation details can evolve.
pallet-emp-assets is confirmed live on testnet with 24 extrinsics. pallet-privacy is currently going through a security hardening pass after a testnet incident — we are not claiming a completed third-party audit for it here. Check the EmpoorioChain developer docs for the current, up-to-date status before relying on either pallet in production.
EmpoorioChain's own native asset, DMS, runs through the same runtime primitives. Additional stablecoin or real-world-asset issuance on pallet-emp-assets / pallet-emp-rwa will be announced here as issuers go live on mainnet — we're not listing third-party issuers we can't confirm.
That's the intent, but since pallet-privacy is mid-hardening, combined flows should be treated as in-progress. Track the EmpoorioChain runtime repository for the current state of that integration rather than assuming it's finished.
pallet-emp-assets and its 24 extrinsics are live and usable on testnet today. pallet-privacy's confidential-transfer functionality exists but is going through a security hardening pass following a recent testnet incident — treat it as not yet production-hardened until that work is complete and documented.
Yes — pallet logic and per-asset permissions are governed on-chain. Updating the rules that apply to a registered asset goes through EmpoorioChain's governance process rather than a code redeploy, since the logic lives in the shared pallet rather than in per-token contract code.
The intent behind pallet-privacy is to mask transfer amounts and balances using ZK proofs while preserving an auditor's ability to verify compliance. Because the pallet is currently being hardened after a testnet incident, treat the exact guarantees as provisional — verify the current spec in the developer docs rather than assuming the design described here is final.
The design intent is to let an issuer-designated auditor key view transfer amounts without exposing them publicly. Exact key-management details are part of what's being reviewed during the current hardening pass, so check the pallet reference for the current implementation before depending on specific cryptographic guarantees.
Start with the EVM-to-EmpoorioChain migration guide for pallet-emp-assets, which covers the extrinsic and storage-item model in detail.
