Skip to main content
MIP20 is Metal’s canonical fungible, balance-based token interface. A MIP20 token represents an economic asset through public balances held by EVM addresses. It supports ERC-20 transfers and allowances, ERC-3009 transfer authorizations, and funds reserved in MIP20 holds. Metal can also charge transaction fees from the same MIP20 balance. Send and Receive Policies explains the rules governing incoming payments and outgoing spending.

​
Balances belong to addresses

Each MIP20 balance belongs to an EVM address and is visible in public state. That address may be controlled by a signing key or by a smart contract. In either case, balanceOf(address) returns its spendable balance. Funds reserved in MIP20 holds move to escrow at the token contract and remain attributed to the owner through heldTotalOf(address).

​
What makes a token MIP20

Metal recognizes a token as MIP20 when its address appears in the MIP20Factory.isMIP20 mapping. The MIP20 allowlist gives transaction admission and execution a common way to identify tokens whose balance storage supports protocol gas accounting. Factory deployment is permissionless. Calling MIP20Factory.deployMIP20 creates a MetalToken and adds its address to the MIP20 allowlist in the same transaction. There is no separate registration or approval step. Metal also starts with fixed-supply MIP20 gas tokens included in genesis. Their code and initial state are inserted directly, and their addresses are already present in the MIP20 allowlist. Application-created MIP20 tokens use factory deployment instead. An application can deploy another ERC-20 contract, but Metal does not treat it as MIP20. It cannot pay gas because the execution layer cannot rely on its storage layout. The MIP20 allowlist establishes protocol compatibility. It makes no claim about an asset’s issuer, reserves, redemption terms, or legal status.

​
Supply authority

The MIP20 deployer becomes the token owner of a factory-deployed MetalToken. The initial holder is a separate constructor choice and need not be the token owner. The token owner can mint additional units, burn tokens from its own balance and transfer ownership. MIP20 imposes no supply cap or asset-governance process. The owner and any system controlling it therefore form part of the asset’s trust boundary. Genesis gas tokens use the base fixed-supply MIP20 implementation without the MetalToken ownership, public mint, or public burn functions.

​
Gas-token eligibility

Metal has no native gas asset. Standard Ethereum envelopes pay with the default gas token, while a Metal 0x7f envelope selects a MIP20 token. In both cases, the transaction signer pays from its spendable balance in that token. The execution layer debits and refunds the balance by reading and writing the mandated MIP20 balance slot directly. Gas accounting bypasses contract calls, allowances, receive policy, and token transfer events. The final fee moves from the signer to the block’s fee recipient without changing the token’s total supply. See Fees for admission, pricing, refund, and validator-credit behavior. The exact factory, storage, and contract surfaces are in the MIP20 reference.

​
Relationship to MIP410

MIP20 holds the public asset balance that backs MIP410 notes. Shielding moves MIP20 value into the MIP410 shielded pool, and unshielding releases it to a public destination subject to receive policy. Private ownership inside the pool is represented by shielded notes rather than MIP20 balances at each note holder’s address.