MultiVM Token Standard

​

What is MultiVM Token Standard (MTS)?

MTS (MultiVM Token Standard) ensures that every token on Injective, whether created through native modules on the execution layer or deployed on the Ethereum Virtual Machine (EVM), can have one canonical balance and identity. This prevents fragmentation and removes the need to bridge or wrap a token to move it between execution environments, giving DeFi protocols and dApps a single pool of liquidity to work against. This page is the entry point for MTS on both sides of the stack. It covers the model and the four ways a token comes into existence, then points to the native or EVM reference for the details.

​

The Model: One Balance, Two Views

The native bank module is the single source of truth for balances and total supply. An MTS ERC20 contract holds no balances of its own. It is a view that reads and writes bank state through the Bank precompile at 0x0000000000000000000000000000000000000064. The consequence that matters: a native bank send and an ERC20 transfer on the EVM move the same balance. There is no reconciliation step and no wrapped representation. A contract only participates in MTS if it routes balance, supply and transfer operations through the precompile. A stock ERC20 that keeps balances in its own EVM storage is a normal EVM token, invisible to the bank module and outside MTS.

​

Why is MTS Important?

• Seamless Interoperability: Tokens remain consistent across native modules and the EVM.
• 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.

​

Four Token Origins

There are four possible origins for an MTS token, each belonging to a different denom family. There are distinct differences with respect to the metadat authority, and whether an explicit ERC20 pairing step is required. The first three create a bank denom first and then optionally project it into the EVM. The fourth starts in the EVM and the bank denom follows from the contract address. In all four cases once paired, the balance lives in the bank module.

​

Which path applies to you

• Launching a token that does not exist anywhere yet, and you want native admin control over supply and metadata: TokenFactory.
• Bringing an existing Ethereum ERC20 across: Peggy.
• Bringing a token from another IBC chain: IBC.
• Building EVM-first, with the token’s authority living in Solidity: Injective EVM.

​

Creating an MTS token on the EVM

1. Start from a template: BankERC20.sol (abstract base), MintBurnBankERC20.sol (owner can mint and burn), or FixedSupplyBankERC20.sol (no owner, fixed supply).
2. Deploy on the Injective EVM. The contract interacts with the Bank precompile, and its first mint creates the erc20:0x... denom.

​

Pairing an existing denom

Submit MsgCreateTokenPair for the bank denom. Leave the ERC20 address empty to have the chain deploy a template, or, for TokenFactory denoms only, supply your own contract address. Custom contracts carry requirements that are easy to miss, including an empty-metadata constructor and a separate native authorization for minting and burning. Those are documented in full on the ERC20 Module page, which is the reference for everything pairing-related.

​

Interoperability and Cross-Chain Integration

​

Native Interoperability

Injective’s EVM is integrated directly into the chain.

• EVM smart contracts, when using MTS, perform operations that reflect immediately on native modules such as exchange, staking, and governance.
• JSON-RPC endpoints provided within the Injective binary are compatible with Ethereum.

​

Cross-Chain Operations

• IBC Compatibility: Existing native tokens (created via TokenFactory or pegged via Peggy) are accessible from the EVM once an MTS pairing is established.
• Bridging Alternatives: While many blockchains require separate bridge operations (lock, mint, unlock), MTS avoids these steps by natively synchronizing states.

​

Allowances & Extended ERC20 Functions

• MTS contracts maintain standard ERC20 functionality such as allowances (approve/transferFrom).
• The allowance mechanism lives in EVM contract storage for convenience, while the underlying balance is managed by the bank module.

​

Performance, Gas, and Security Considerations

​

Gas Costs and Efficiency

• Gas fees are paid in INJ. MTS operations via the EVM introduce an abstraction layer that may slightly increase gas usage compared to native transactions, but the overall cost remains lower than comparable operations on Ethereum.

​

Security

• The bank module, as the single source of truth, underpins MTS’s security by ensuring that token balances are consistent and verifiable.
• The use of precompiles prevents state desynchronization, so every operation updates the same canonical ledger regardless of where it was initiated.

​

Reference