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

# Glossary

> Definitions for Metal transaction, asset, policy, finality, settlement, and agent payment terminology

Use this glossary for Metal-specific terminology. Continue to the linked
protocol and interface pages at the end when you need exact behavior.

## Accounts and assets

| Term | Meaning |
| - | - |
| **Default gas token** | The MIP20 token used to pay fees for standard Ethereum transaction envelopes. On the public testnet this is `*USDZ`. |
| **Gas token** | An allowlisted MIP20 selected to pay a transaction's execution fee. The `0x7f` envelope carries this selection explicitly. |
| **Onchain identity** | An EVM address that holds MIP20 balances. It can be an externally owned account (EOA) or a smart contract's address. The integrating organization chooses which addresses it uses and how it controls them. |
| **MIP20** | Metal's balance-based payment token standard. MIP20 tokens support ERC-20 transfers, signed transfer authorizations, holds, receive-policy screening, and gas payment. Their addresses appear in `MIP20Factory.isMIP20`. |

## Transactions and finality

| Term | Meaning |
| - | - |
| **Admission** | Checks performed before a transaction enters the pool, including signature, chain ID, envelope, value, gas token, fee, affordability, and nonce rules. Admission does not guarantee successful EVM execution. |
| **Envelope** | The signed transaction encoding submitted to `eth_sendRawTransaction`. Metal accepts replay-protected legacy, EIP-2930, EIP-1559, and `0x7f` envelopes. |
| **Finalized head** | The most recent block committed by Simplex consensus and exposed to the execution engine as finalized. |
| **MIP20 envelope (`0x7f`)** | Metal's EIP-712-signed transaction type for selecting an allowlisted MIP20 gas token and optionally carrying an authorization list. |
| **Pending nonce** | The next account nonce after counting both included and currently pooled transactions. Read it with `eth_getTransactionCount(address, "pending")`. |
| **Simplex** | The BFT consensus protocol Metal validators use to propose, certify, and finalize blocks. |
| **Standard envelope** | A replay-protected legacy, EIP-2930, or EIP-1559 transaction. On Metal it pays gas in the default MIP20 token. |

## Policy

| Term | Meaning |
| - | - |
| **Policy primitive** | A reusable check that an institution configures or combines into a policy, such as a sender list, token filter, amount limit, or signature check. |
| **Policy contract** | A smart contract that evaluates and enforces send or receive policy for MIP20 payments. |
| **Send policy** | An institution's rules for outgoing payments, such as spending limits, permitted recipients, and required approvals. |
| **Send policy contract** | Checks send policy before an outgoing transfer is authorized or made. The checks may run in the contract holding funds or in a separate rules contract it calls. |
| **Receive policy** | An account's configured rules for incoming MIP20 credits, covering senders, tokens, amounts, and per-sender totals or frequency. |
| **Receive policy contract** | The `ReceivePolicy` contract that stores receive rules per account. MIP20 calls it before crediting incoming funds. |
| **Refusal mode** | Determines whether a refused ordinary transfer reverts or credits quarantine. Refused mints, MIP20 hold captures, and payouts from a token's own balance always quarantine. |
| **Quarantine receipt** | A record of refused funds held by `ReceivePolicy`, containing the nonce, token, originator, receiver, authority, and amount. It is emitted by `Quarantined` and supplied to `claim` for recovery. |
| **Recovery authority** | The address authorized to release a quarantine receipt's funds. Each receipt records this authority when created, with a recipient fallback for an originator that later has contract code other than an EIP-7702 delegation. |
| **Outgoing control** | A send policy rule enforced through every path that can spend funds or authorize spending. |
| **Explicit payment call** | A call to a policy or routing contract that checks rules and makes the required token transfers in one transaction. |
| **Policy decision** | A result from the integrating organization or its provider that application code authenticates and binds to an exact operation. |

See [Send and Receive Policies](https://docs.metalntwx.com/learn/mip20/handlers-and-policy.md) for how policy
contracts govern a transfer, and [Receive Policy](https://docs.metalntwx.com/reference/compliance/receive-policy.md)
for the receive rules, refusal outcomes, and recovery interface.

## Settlement

| Term | Meaning |
| - | - |
| **Atomic rollback** | A revert that undoes the enclosing call's token movements, application state, nested calls, allowance or authorization consumption, quarantine receipts, and events. A reverted transaction still pays execution fees. Quarantine alone does not cause rollback. |
| **Net position** | A participant's final debit or credit after offsetting the legs in a signed settlement batch. |
| **Settlement coordinator** | An application contract that authorizes and executes agreed obligations, potentially as net MIP20 movements. Metal does not bundle a settlement coordinator. |

## Agents

| Term | Meaning |
| - | - |
| **Metal account** | A smart account the Metal account factory deploys, controlled by its owners, keys or passkeys, as many as its threshold needs. The account an agent pays from under spending limits. |
| **Mandate** | Limits an account's owner records on its Metal account so that an agent can pay from it: the payees, the most per payment, the total, the number of payments, and an expiry. Metal refuses any payment outside them. |
| **Credential** | The file that states a mandate's limits. The owner issues it. The agent signs each payment with the mandate key it names, and anyone holding it and the issuer's public key can verify the payments made under it. It holds no secret. |
| **Mandate key** | The P-256 key an agent signs with under a mandate. The credential format requires that curve. `credential create` writes it beside the credential, which names only its public half. It is separate from the agent's own key. |
| **Bind** | The owner's transaction that records a mandate on its Metal account: the credential's hash, its limits and payees, the mandate key, and the key that issued the credential. Signed by the account's owners. From then on the account accepts the mandate key's payments within those limits, until the owner replaces or revokes the mandate. |
| **Signed order** | The agent's signature over the order it buys, which a seller may require with the payment as proof of what was agreed. |
| **Payout** | A transfer under a mandate to an address it allows, with no seller and no `402`. |
| **Clearing** | Payments against a token deposit using the `bajillion` x402 scheme. The sender signs cumulative payments with a P-256 key and the service returns signed receipts as preconfirmations. Validators certify epoch results, which can finalize after their challenge deadlines. See [Offer Pay-per-Call Clearing](https://docs.metalntwx.com/agents/clearing.md). |
| **Clearing service** | The service that acknowledges Clearing payments with signed receipts and, with its validators, certifies each epoch's totals on chain. |
| **Deposit** | Tokens a payer places in a Clearing contract under its Clearing key. One deposit pays any seller offering that deployment. |
| **Debit** | A payer's signed cumulative payment total, increased by each payment's price and acknowledged by the Clearing service. |
| **Receipt** | The Clearing service's signature over a payment it recorded, used as preconfirmation evidence. |
| **Epoch** | One interval of Clearing settlement. Certified totals can finalize after the challenge deadline. Withdrawals wait for the required epoch to finalize. |

## Continue reading

> [card] [Transactions](https://docs.metalntwx.com/reference/network-fundamentals/transactions.md)
>
> Review envelope fields and admission rules.

> [card] [MIP20](https://docs.metalntwx.com/learn/mip20/token-and-account-model.md)
>
> Understand balance-based assets, gas, and account balances.

> [card] [Settlement and finality](https://docs.metalntwx.com/reference/network-fundamentals/settlement.md)
>
> Review payment completion conditions and finality checks.

> [card] [x402 on Metal](https://docs.metalntwx.com/agents/x402-on-metal.md)
>
> How agents pay sellers, and the two schemes.


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