> ## Documentation Index > Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt > Use this file to discover all available pages before exploring further. # EVM Compatibility and Gas > How Metal combines Ethereum tooling with MIP20 gas payment, priority-fee-only pricing, and millisecond blocks. Metal uses the Ethereum Virtual Machine (EVM) to run smart contracts. It keeps Ethereum's contract environment and familiar tools while adapting gas payment and block timing for Metal. ## Ethereum compatibility Metal uses Reth for its execution layer and Ethereum JSON-RPC, the interface wallets and applications use to communicate with a node. Developers can use Solidity, Foundry, Hardhat, viem, and ethers. Contracts retain Ethereum's account and storage model, and applications can read their events and transaction receipts through familiar interfaces. ## No native asset Metal has no native gas asset. MIP20 tokens pay transaction fees from the same balances used for payments, so a user can hold and spend a payment token without acquiring a separate native token for gas. A transaction's `value` field specifies an amount of native currency to transfer and must therefore be zero. Standard Ethereum envelopes encode transactions and their signatures but have no field for selecting a gas token. Metal uses the chain's default gas token for the standard envelopes it accepts, allowing existing tools to construct and sign transactions without changing their format. Wallets obtain the corresponding balance and fee information through Ethereum's existing RPC methods. Metal maps `eth_getBalance` to the EVM account's balance in the default gas token, while `eth_gasPrice` quotes gas in that token's smallest units. The [wallet-facing RPC table](https://docs.metalntwx.com/reference/json-rpc/overview.md#wallet-facing-overrides) lists the affected methods and their behavior. Explicit selection of another MIP20 token requires the Metal `0x7f` envelope and tools that understand how to encode and sign it. This envelope can also carry an authorization that lets an EVM account use a smart contract's code. The `MIP20Factory` contract deploys MIP20 tokens and records them in the MIP20 allowlist. This allowlist also includes the gas tokens configured when the chain starts. Their shared storage layout gives the execution layer a known location for each balance, allowing it to charge and refund fees directly. The allowlist does not assess the issuer's reserves or the token's economic value. ## Gas and transaction cost Gas measures the work required to execute a transaction. The gas limit bounds how much work that transaction can consume. The gas price specifies the amount paid per unit of gas, expressed in the gas token's smallest units. The signing account is the EVM account whose signature authorizes the transaction. During transaction admission, Metal checks that this account can afford the maximum gas cost before accepting the transaction into a node's transaction pool: ```text theme={null} maximum gas cost = gas limit × maximum fee per gas ``` When the signing account pays gas and transfers the same token, both amounts come from the same balance. When admission recognizes a direct MIP20 transfer, it checks the transfer amount together with the maximum gas cost. Spending within other contract calls is checked during execution. The fee for execution depends on the gas used and the price charged per unit of gas. A higher gas limit increases the balance required upfront, though it does not mean the transaction will consume that entire amount. ## Priority-fee-only pricing The execution base fee is the network-set part of the gas price. The priority fee is the amount the signing account offers per unit of gas to the fee recipient designated by the block. Burning the execution base fee would permanently reduce the supply of the gas token. Metal keeps fee payment from changing that supply by setting the execution base fee to zero and charging the transaction's priority fee. The effective gas price is the price actually charged per unit of gas after applying the transaction's fee limits: ```text theme={null} effective gas price = min(maximum fee per gas, maximum priority fee per gas) execution precharge = gas limit × effective gas price fee for execution = gas used × effective gas price ``` The execution precharge is the amount Metal debits before running contract code. Metal refunds the portion for unused gas in the gas token afterwards. A reverted transaction rolls back its contract state but still pays for the gas it used. Standard blob transactions carry additional data outside the transaction body and pay a separate [blob fee](https://docs.metalntwx.com/reference/network-fundamentals/blobs.md#fees). The blob fee is charged in full and is not included in the refund for unused execution gas. The block's fee recipient receives the fee directly in the gas token, with no conversion into another token. Fee payment therefore needs no exchange rate or token swap during execution. Using a stablecoin for gas also does not make every transaction cost the same. The fee depends on gas use and the chosen gas price. ## Fee payment The signing account pays the transaction fee. It can belong to the customer or to an institution that submits a transaction for a payment the customer has authorized. Separating payment authorization from submission lets the institution fund transaction fees on the customer's behalf. The execution layer charges the fee by updating the signing account's MIP20 balance in token storage. Fee debits, refunds, and credits to the block's fee recipient use this storage path without ERC-20 allowances, account payment calls, or receive-policy screening. A shielded payment's signing account and transaction fee remain public, even when its payment details are private. ## Millisecond blocks Metal supports sub-second blocks and records block time with millisecond precision. Solidity's `block.timestamp` retains Ethereum's resolution in whole seconds, so several consecutive blocks can expose the same timestamp to a contract. The RPC interface supplies the millisecond component separately. Block timing and finality describe different properties. Finality is reached when validators agree on a block through the consensus process described in [Architecture](https://docs.metalntwx.com/learn/architecture.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.