Transactions

Metal accepts replay-protected legacy (0x00), EIP-2930 (0x01), EIP-1559 (0x02), EIP-4844 blob (0x03), and MIP20 (0x7f) transaction envelopes.

Envelope matrix

Type	Envelope	Gas token	Authorization list	Status
`0x00`	Replay-protected legacy	Chain default	No	Accepted
`0x01`	EIP-2930	Chain default	No	Accepted
`0x02`	EIP-1559	Chain default	No	Accepted
`0x03`	EIP-4844 blob	Chain default	No	Accepted with an EIP-7594 sidecar
`0x04`	EIP-7702 SetCode	Native Ethereum semantics	Yes	Rejected
`0x7e`	Scheduled system transaction	Scheduler escrow	No	Produced by block execution; rejected at admission
`0x7f`	MIP20	Signer-selected MIP20	Optional	Accepted

Standard Ethereum envelopes pay gas in the chain’s default MIP20 token. Use them with existing Ethereum tooling when the default token is suitable. Use the 0x7f envelope when the signer must choose another allowlisted MIP20 gas token or include an EIP-7702 authorization. A 0x7e transaction is one due entry of the Scheduler predeploy at 0x00000000000000000000000000000000000000fe, run by block execution at the head of the block; RPC renders it as an EIP-1559-shaped transaction from that address with a zero signature, to the entry’s call target, or to the Scheduler itself with the ABI-encoded calls when the entry makes several. See Scheduled Transactions. Standard blob transactions require an EIP-7594 network sidecar and submission through a validator RPC endpoint. They pay execution gas and a separate blob fee in the default MIP20 token. See Blob Transactions and Sidecars for the network form and retention rules.

Metal does not accept Ethereum’s native 0x04 SetCode transaction envelope. It supports an EIP-7702 authorization only when that authorization is carried inside a signed Metal 0x7f envelope.

Asset standards inside a transaction

The envelope defines the signer, gas payment, authorization list, and outer EVM call. The called contract defines the asset state transition and policy checks.

Standard	Role during execution	How an application submits it
MIP20	Moves transparent balances and supplies Metal gas tokens	Call the asset from any accepted envelope. Use `0x7f` when the signer selects a gas token or includes an EIP-7702 authorization
MIP410	Shields MIP20 value, verifies shielded payments, and unshields value	Submit the contract call and proof data in any accepted envelope

MIP410 operations use the accepted outer envelopes. The signer pays gas with the default MIP20 token or the token selected by a 0x7f envelope.

Admission rules

Before a transaction enters the pool, Metal checks:

the signature and recovered sender;
an EIP-155 chain ID that matches the network;
a supported envelope type;
tx.value == 0;
an allowlisted MIP20 gas token;
the fee floor and maximum fee bound;
a gas limit no greater than 100,000,000;
sufficient balance for maximum gas cost and recognized same-token debits; and
transaction-pool nonce and replacement rules.

Blob admission also verifies the EIP-7594 sidecar, its KZG commitments and cell proofs, and a positive blob-fee bid within the fee cap. Affordability includes blobGasUsed × maxFeePerBlobGas in addition to maximum execution gas cost. An admitted transaction can still revert during EVM execution. Admission proves that the envelope and current affordability are valid, not that the contract call will succeed.

MIP20 envelope fields

Fields appear below in their RLP encoding order.

Field	Type	Description
`chain_id`	`uint64`	Chain identifier. Testnet: `63825`
`nonce`	`uint64`	Sender’s transaction count (include pending)
`max_priority_fee_per_gas`	`uint128`	Priority fee per gas unit, in MIP20 token base units
`max_fee_per_gas`	`uint128`	Maximum fee per gas unit. On the testnet, set equal to the priority fee (`block.basefee == 0`)
`gas_limit`	`uint64`	Maximum gas to consume
`to`	`address` or empty	Target contract or recipient. An empty destination encodes contract creation
`value`	`uint256`	Must be `0`. Non-zero value is rejected at admission
`input`	`bytes`	ABI-encoded calldata
`access_list`	`[]`	Standard EIP-2930 access list. Usually empty
`authorization_list`	`[]`	Optional EIP-7702 smart-account authorizations
`gas_token`	`address`	MIP20 token address used to pay gas

value must be 0. Metal has no native gas asset. Any transaction with tx.value != 0 is rejected at the mempool admission gate.

How gas payment works

Admission requires the signer to cover max_fee_per_gas × gas_limit from the identity-keyed MIP20 balance. Before executing the transaction body, the Metal EVM debits min(max_fee_per_gas, max_priority_fee_per_gas) × gas_limit. A 0x7f transaction names that token in gas_token; a standard Ethereum transaction uses the chain’s default gas token. After execution, Metal refunds the unused portion and leaves block.coinbase with the fee for gas consumed. The execution layer updates MIP20 storage directly without an approve or transferFrom call. Contract reverts roll back application state while the signer still pays for consumed gas. A blob transaction also pays its full blob fee, which is not refunded.

The signer must hold enough gas_token for the maximum gas cost plus any recognized same-token debit. Both amounts use _balances[signer].

max_fee_per_gas must be at most 1_000_000_000_000 base units. Because block.basefee == 0, the effective gas price is min(max_fee_per_gas, max_priority_fee_per_gas) and must be at least 1.

Optional authorization list

An ordinary EOA does not need an authorization_list to send MIP20 tokens. Include one only when the account is opting into or changing a smart-account implementation. The MIP20 EIP-712 signature binds the authorization-list hash. Each authorization’s chainId must equal Metal’s chain ID; chain-agnostic (chainId = 0) authorizations are rejected. The authorization and the selected MIP20 gas token therefore share one signed Metal transaction. Clients should not translate the request into a standalone 0x04 envelope, because native 0x04 admission is rejected.

EIP-712 signing

The 0x7f envelope is signed as EIP-712 typed data, not a raw RLP transaction. The typed data domain uses the MIP20Factory address as the verifying contract:

Domain name: "Metal"
Domain version: "1"
Verifying contract: 0x0000000000000000000000000000000000000f4C (MIP20Factory)
Chain ID: matches chain_id field

Use the SDKs rather than building this by hand:

import { sendMip20Call } from "@metalntwx/metal-ts";

const txHash = await sendMip20Call({
  walletClient,    // viem WalletClient with a connected account
  publicClient,    // viem PublicClient connected to Metal RPC
  to: contractAddress,
  data: "0x...",   // ABI-encoded calldata
  gasToken: usdTokenAddress,
  gasFallback: 200_000n,  // gas limit if estimation fails
});

Testnet defaults

Setting	Value
Chain ID	`63825`
RPC URL	`https://rpc-testnet.metalntwx.com/v1/<endpoint-id>`
Default gas token	`*USDZ` (`0x000000000000000000000000000000000000B5D5`)
`max_priority_fee_per_gas`	`1`
`max_fee_per_gas`	`1`

Get your endpoint ID from the Metal console. See RPC endpoint setup for the setup steps.

Fees

Follow the MIP20 debit, refund, and validator reward.

TypeScript SDK

Build and submit 0x7f transactions with the Metal SDK.

Network fundamentals

Assets and payments

Privacy

Compliance

Contracts and automation

Data and signatures

Interoperability

Envelope matrix

Asset standards inside a transaction

Admission rules

MIP20 envelope fields

How gas payment works

Optional authorization list

EIP-712 signing

Testnet defaults

Fees

TypeScript SDK

​Envelope matrix

​Asset standards inside a transaction

​Admission rules

​MIP20 envelope fields

​How gas payment works

​Optional authorization list

​EIP-712 signing

​Testnet defaults

Fees

TypeScript SDK

Envelope matrix

Asset standards inside a transaction

Admission rules

MIP20 envelope fields

How gas payment works

Optional authorization list

EIP-712 signing

Testnet defaults