MultiVM Token Standard
Understanding token representation in Injective's multi-VM architecture
Last updated
Understanding token representation in Injective's multi-VM architecture
Last updated
MTS (MultiVM Token Standard) ensures that every token on Injective—whether deployed using Cosmos modules or via the Ethereum Virtual Machine (EVM)—has one canonical balance and identity. This unified approach prevents fragmentation and eliminates the need for bridging or wrapping tokens, thereby enabling seamless interoperability and unified liquidity for decentralized finance (DeFi) and dApp interactions.
Seamless Interoperability: Tokens remain consistent across Cosmos and EVM environments.
Unified Liquidity: A single source of truth avoids liquidity fragmentation.
Enhanced Developer Experience: Standard tools like Hardhat, Foundry, and MetaMask work out of the box.
Security & Efficiency: All token state is maintained centrally in the bank module, ensuring robust security.
The system comprises two main components:
:
Developed in Go, this precompile is embedded directly in the Injective EVM.
It provides a Solidity interface that proxies ERC20 operations—such as mint, burn, and transfer—to the bank module.
:
This module maps native bank denoms (e.g., INJ, IBC tokens, Peggy assets) to an ERC20 contract within the EVM.
It deploys MTS-compliant ERC20 contracts that always reflect the canonical token balance as maintained by the bank module.
Start with the provided Solidity templates, such as BankERC20.sol, MintBurnBankERC20.sol, or FixedSupplyBankERC20.sol.
Deploy your MTS token contract on the Injective EVM network.
The contract automatically interacts with the Bank Precompile to update the canonical state.
Injective’s EVM is integrated directly into the Cosmos-based chain.
EVM smart contracts, when using MTS, perform operations that reflect immediately on native modules (such as the exchange, staking, and governance modules).
Bridging Alternatives: While many blockchains require separate bridge operations (lock, mint, unlock), MTS avoids these steps by natively synchronizing states.
MTS contracts maintain standard ERC20 functionalities such as allowances (approve/transferFrom).
Note that while the allowance mechanism is maintained within the EVM contract for convenience, the ultimate balance is managed by the bank module, preserving integrity.
Gas fees are paid in INJ. While MTS operations via the EVM introduce an abstraction layer that may slightly increase gas usage compared to native transactions, the overall cost remains lower than comparable operations on Ethereum.
The gas model is designed to reflect a balance between EVM-style opcode costs and native module interactions.
Advanced security guidelines and best practices for smart contract development are provided in our security section and external resources.
ℹ️ Note:
To prevent denom spam, deploying an ERC20 contract via the ERC20 module is a payable operation and requires a deployment fee of 1 INJ. Make sure your ERC20 contract deployment transaction includes this amount, or the operation will be rejected.
:
:
provided within the Injective binary are compatible with Ethereum, ensuring smooth developer integration.
IBC Compatibility: Existing native tokens (e.g., those created via a or pegged via Peggy) are accessible from the EVM once an MTS pairing is established.
The , as the single source of truth, underpins MTS’s security by ensuring that token balances are consistent and verifiable.
The use of prevents common pitfalls like state desynchronization, ensuring that all operations—no matter where initiated—update the same canonical ledger.
← Previous
Precompiles
