> ## 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.

# Ethereum Compatibility

> What Ethereum developers can reuse on Metal and what changes for assets, gas, policy, and finality

Metal runs the EVM and exposes Ethereum JSON-RPC, so developers can keep the
Solidity language, account model, and most of their existing tools. The main
differences come from Metal's payment model. Assets pay transaction fees,
native value is disabled, account policy can run during a transfer, and
consensus provides a precise finality signal.

## What remains unchanged

| Surface | Compatibility |
| - | - |
| Smart contracts | Solidity, ABI encoding, storage, events, calls and contract creation |
| Accounts | 20-byte EVM addresses and secp256k1 signatures |
| Tooling | Foundry, Hardhat, viem, and other standard EVM tools |
| Wallets | EIP-1193, chain add and switch requests, and EIP-712 signing |
| JSON-RPC | Standard methods for blocks, transactions, receipts, logs, calls, and gas estimates |
| Token calls | ERC-20-compatible balances, transfers, allowances, and events on MIP20 assets |

Metal targets the Osaka EVM revision.

## What changes

| Ethereum assumption | Metal behavior |
| - | - |
| ETH is the native asset | Metal has no native asset. Financial value moves through asset contracts |
| ETH pays transaction fees | An approved MIP20 asset pays the fee |
| `value` carries native currency | `value` must be `0` |
| An account balance means ETH | `eth_getBalance` reports the account's default MIP20 gas-token balance |
| Token policy lives around the transfer | MIP20 can invoke policy attached to the sending and receiving accounts during the transfer |
| Confirmation depth estimates settlement confidence | `consensus_status.finalized` identifies the finalized block |

Metal also adds a millisecond component to its block header. Solidity `block.timestamp` remains denominated in seconds.

## Transaction envelopes

| Type | On Metal | Gas token |
| - | - | - |
| Replay-protected legacy (`0x00`) | Supported | Default MIP20 |
| EIP-2930 (`0x01`) | Supported | Default MIP20 |
| EIP-1559 (`0x02`) | Supported | Default MIP20 |
| EIP-4844 blob (`0x03`) | Supported | Default MIP20 |
| EIP-7702 SetCode (`0x04`) | Not supported as an outer envelope | — |
| Metal MIP20 (`0x7f`) | Supported | Signer-selected approved MIP20 |

Metal configures MIP20 token as the network's default gas token. Standard
Ethereum transaction envelopes have no gas-token selection field, so their
fees are charged in that token. The signing account must hold enough of it
to pay gas. Use Metal's `0x7f` envelope when the signer needs to select
another approved MIP20 gas token. See
[EVM Compatibility and Gas](https://docs.metalntwx.com/learn/eth-and-gas.md#no-native-asset) for fee
accounting and wallet behavior.

On the Osaka network, blob transactions use EIP-7594 network sidecars. The
Metal `0x7f` envelope can carry an EIP-7702 authorization list even though
Metal does not accept the native `0x04` envelope.

For an exact asset balance, call that asset's `balanceOf`. Use
`eth_getBalance` only for the default gas-token balance exposed to Ethereum
wallets and transaction tooling.

Replace native-value patterns as follows:

| Ethereum pattern | Metal pattern |
| - | - |
| `payable` call with non-zero `msg.value` | MIP20 transfer, allowance flow, or contract call |
| Native balance display | `balanceOf` for each supported MIP20 asset |
| ETH gas warning | Default or selected MIP20 gas-token warning |
| Confirmation-depth settlement | Receipt plus finalized-head verification |

Read each asset's `decimals()` value rather than assuming that all MIP20 assets
use the same precision.

## Deterministic settlement

A successful receipt proves execution, while `consensus_status.finalized`
proves settlement. Systems that release funds or trigger another irreversible
action should wait until the transaction's block is at or below the finalized
head and confirm that the canonical block at the receipt's height has the
receipt's block hash. This establishes that the executed transaction belongs
to the finalized chain.

## Local and testnet development

Anvil and other local EVMs remain useful for contract logic, fuzzing, events,
and revert behavior. They do not reproduce Metal's MIP20 fee accounting,
`0x7f` admission and signing, policy-enabled account setup, custom RPC methods,
finality, or additive block-header fields.

Test those Metal-specific paths on the public testnet before deploying an
integration.

> [card] [Connect to testnet](https://docs.metalntwx.com/start/connect-to-testnet.md)
>
> Verify the public RPC with standard EVM tooling.

> [card] [Set up a project](https://docs.metalntwx.com/build/prepare/connect-to-metal.md)
>
> Configure a Solidity or TypeScript project for Metal.

> [card] [Transaction architecture](https://docs.metalntwx.com/reference/network-fundamentals/transactions.md)
>
> Review transaction envelopes and admission rules.

> [card] [Finality](https://docs.metalntwx.com/learn/architecture.md)
>
> How validators agree on a block and establish finality.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.