# NERO 402 Glossary > Ground-truth definitions of NERO 402, x402, and account-abstraction terms for LLMs and agents. This glossary is the authoritative source for what each technical term means in NERO 402. Machine-readable forms: [https://docs.x402.nerochain.io/glossary.json](https://docs.x402.nerochain.io/glossary.json) (schema.org DefinedTermSet) and the MCP `define_term` tool. Source docs: https://docs.x402.nerochain.io/docs. ## aa-native scheme The settlement scheme NERO 402 contributes, in which an ERC-4337 smart-contract wallet pays by signing a UserOperation whose callData invokes an on-chain SettlementContract. It works with any standard ERC-20 and is gas-sponsored by a paymaster, so the payer needs no native token. _Also: aa-native, AA-native._ See: [The aa-native scheme](https://docs.x402.nerochain.io/docs/core-concepts/aa-native-scheme) ## Agent An autonomous client — a script, LLM agent, or browser tab — that pays for API calls. Integrates with @nerochain/x402-client (the fetch wrapper) and @nerochain/x402-aa (the paymaster-sponsored signer). See: [Quickstart for agents](https://docs.x402.nerochain.io/docs/getting-started/agents) ## Bundler An ERC-4337 service that packages UserOperations and submits them to the EntryPoint on chain. NERO 402's facilitator submits aa-native settlements through the NERO bundler. ## CAIP-2 network id A chain-identifier format used as the network field in x402 payloads, e.g. eip155:1689 for NERO mainnet and eip155:689 for testnet. The wire format treats the network as opaque. _Also: CAIP-2, network._ See: [Networks](https://docs.x402.nerochain.io/docs/core-concepts/networks) ## DEMO-USDT A public-mint ERC-20 on NERO testnet (0x9a2eabdecda3eae051bca75fbe71a3dbdb35f9d4) used as a self-faucet settlement asset, so agents can run the full aa-native flow on testnet without real funds. See: [Networks](https://docs.x402.nerochain.io/docs/core-concepts/networks) ## EIP-3009 An ERC-20 extension (transferWithAuthorization) that lets an EOA authorize a token transfer by signature. The exact scheme depends on it; most tokens such as USDT do not implement it, which is the gap aa-native closes. _Also: transferWithAuthorization._ ## EntryPoint The singleton ERC-4337 contract that validates and executes UserOperations. NERO uses EntryPoint v0.6 at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 on both mainnet and testnet. See: [Networks](https://docs.x402.nerochain.io/docs/core-concepts/networks) ## EOA Externally Owned Account: a wallet controlled directly by a private key. The exact scheme requires an EOA that can sign EIP-3009; aa-native does not. _Also: externally owned account._ ## ERC-4337 The Ethereum account-abstraction standard that lets smart-contract wallets initiate transactions via UserOperations routed through an EntryPoint and bundler, instead of EOA-signed transactions. NERO Chain runs ERC-4337 v0.6. _Also: account abstraction, 4337._ See: [Wallet](https://docs.x402.nerochain.io/docs/core-concepts/wallet) ## exact scheme The upstream x402 settlement scheme in which an EOA signs an EIP-3009 transferWithAuthorization, settled directly against the token contract. Only EOAs and EIP-3009 tokens can use it. NERO 402's facilitator also supports exact for interoperability with unmodified upstream clients. _Also: exact._ See: [Upstream interop](https://docs.x402.nerochain.io/docs/guides/upstream-interop) ## Facilitator A service that verifies and settles x402 payments on behalf of merchants. NERO 402's reference facilitator exposes GET /supported, POST /verify, and POST /settle, and speaks both aa-native and exact. Agents never call it directly; merchant middleware does. See: [Facilitator](https://docs.x402.nerochain.io/docs/core-concepts/facilitator) ## HTTP 402 The HTTP 402 Payment Required status code. x402 uses it to signal that a request must be paid for before the resource is returned, carrying the terms in a PAYMENT-REQUIRED header. _Also: 402, Payment Required._ See: [HTTP 402](https://docs.x402.nerochain.io/docs/core-concepts/http-402) ## Idempotency (clientNonce) Deduplication of retried payments via the x402 extensions (e.g. a clientNonce) so a repeated request does not double-settle. Provided by @nerochain/x402-extensions. _Also: clientNonce._ See: [x402-extensions](https://docs.x402.nerochain.io/docs/sdk/x402-extensions) ## Merchant The party operating a paid HTTP endpoint that returns 402 to unpaid callers and receives settlement transfers. Integrates with @nerochain/x402-server middleware (Express, Hono, Fastify, Next.js). See: [Quickstart for merchants](https://docs.x402.nerochain.io/docs/getting-started/merchants) ## Paymaster An ERC-4337 contract that sponsors gas for a UserOperation so its sender pays no native token. In NERO 402 the paymaster lets an agent's wallet pay APIs while holding only the settlement stablecoin. A NERO Paymaster API key is obtained from the AA Platform dashboard. See: [Paymaster](https://docs.x402.nerochain.io/docs/core-concepts/paymaster) ## paymasterAndData The field of an ERC-4337 v0.6 UserOperation that encodes paymaster sponsorship as a single bytes value. v0.7 splits it into separate fields; the NERO SDK targets v0.6, so v0.7-shaped UserOperations are rejected. ## PAYMENT-REQUIRED The HTTP response header a merchant returns with a 402, carrying base64url-encoded paymentRequirements: scheme, network, amount, asset, and payTo. It is the discovery signal of the x402 flow. ## PAYMENT-RESPONSE The HTTP response header a merchant returns on success, carrying the settlement receipt including the on-chain transactionHash, payer, amount, and asset. ## PAYMENT-SIGNATURE The HTTP request header a client sends on retry, carrying the base64url-encoded signed payment payload (for aa-native, the signed UserOperation). It is the credential that authorizes the payment. See: [Authentication](https://docs.x402.nerochain.io/auth.md) ## Replay protection Prevention of a payment settling twice. NERO 402 uses an authoritative on-chain isSettled[settlementKey] check keyed by (payer, merchant, token, amount, requestHash), plus an off-chain in-flight registry that rejects duplicates earlier to save a bundler round-trip. _Also: settlement key, isSettled._ ## requestHash A hash binding a payment to a specific request. It is part of the settlement key used for on-chain replay protection and is echoed back in the settlement receipt. ## Session keys A pattern that grants an agent a scoped, chain-enforced spending key with caps (per-call and total limits) instead of full wallet authority — the recommended control for serious autonomous-spending deployments. _Also: session key._ See: [Session keys](https://docs.x402.nerochain.io/docs/advanced/session-keys) ## settlementCallSpec The object in an aa-native payload declaring merchant, token, amount, and requestHash. The facilitator decodes the signed UserOperation's callData and asserts it resolves to exactly this settle(...) call, preventing a wallet from signing something other than what it claims. ## SettlementContract The on-chain contract (UUPS-upgradeable, owner-allowlisted, replay-protected) that executes aa-native settlements. settle(merchant, token, amount, requestHash) runs IERC20.transferFrom from the payer's wallet to the merchant and records the settlement key. _Also: settlement contract._ See: [Settlement contract](https://docs.x402.nerochain.io/docs/core-concepts/settlement-contract) ## SimpleAccount / SimpleAccountFactory The canonical ERC-4337 account contract and its deterministic factory used to derive an agent's smart-contract-wallet address from its signing key. The address is known before deployment; the wallet deploys itself on its first sponsored UserOperation. _Also: SimpleAccount, SimpleAccountFactory._ ## Smart-contract wallet (SCW) A wallet implemented as a smart contract (an ERC-4337 account) rather than a key-controlled EOA. On NERO Chain every wallet is an SCW, which is why the EOA-only exact scheme is unusable there and aa-native exists. _Also: SCW, smart account._ See: [Wallet](https://docs.x402.nerochain.io/docs/core-concepts/wallet) ## Type-0 paymaster sponsorship NERO's full-sponsorship paymaster mode in which the agent's wallet spends zero native gas on a paid call, including its own first-time deployment. _Also: type 0._ See: [Paymaster](https://docs.x402.nerochain.io/docs/core-concepts/paymaster) ## UserOperation The ERC-4337 pseudo-transaction object a smart-contract wallet signs. In aa-native, its callData decodes to SettlementContract.settle(...), and the facilitator asserts that decoding matches the declared settlementCallSpec before submitting it. _Also: UserOp._ See: [The aa-native scheme](https://docs.x402.nerochain.io/docs/core-concepts/aa-native-scheme) ## Wire format (envelope) The canonical x402 V2 payload shape: x402Version, accepted (the requirements), payload (scheme-specific inner data), and extensions. NERO 402 keeps it identical to upstream; only the inner payload differs by scheme. _Also: envelope._ See: [Wire format](https://docs.x402.nerochain.io/docs/reference/wire-format) ## x402 An HTTP-native payment protocol built on the 402 Payment Required status code. A server answers 402 with payment terms; the client pays and retries with a signed payment payload; the server returns the content plus a receipt. NERO 402 implements x402 V2. See: [HTTP 402](https://docs.x402.nerochain.io/docs/core-concepts/http-402) ## x402 V2 Version 2 of the x402 protocol and its wire envelope (@x402/core@2.11.0). NERO 402 uses the canonical V2 envelope unchanged; only the inner payload differs per scheme, so upstream V2 clients interoperate. _Also: x402Version 2, @x402/core._ See: [Wire format](https://docs.x402.nerochain.io/docs/reference/wire-format)