Glossary

Ground-truth definitions of the terms NERO 402 uses across x402 payments and ERC-4337 account abstraction. This page is the authoritative source for what each term means. Machine-readable forms: glossary.json (schema.org DefinedTermSet), glossary.md, and the MCP define_term tool.

aa-native scheme

Also: aa-native, AA-native

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.See: The 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
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

Also: CAIP-2, network

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.See: 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
EIP-3009

Also: transferWithAuthorization

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

Also: externally owned account

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.
ERC-4337

Also: account abstraction, 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.See: Wallet
exact scheme

Also: exact

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.See: 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
HTTP 402

Also: 402, Payment Required

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.See: HTTP 402
Idempotency (clientNonce)

Also: 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.See: 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
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
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
Replay protection

Also: settlement key, isSettled

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

Also: session key

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.See: 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

Also: settlement contract

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.See: Settlement contract
SimpleAccount / SimpleAccountFactory

Also: 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.
Smart-contract wallet (SCW)

Also: SCW, smart account

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.See: Wallet
Type-0 paymaster sponsorship

Also: type 0

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.See: Paymaster
UserOperation

Also: UserOp

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.See: The aa-native scheme
Wire format (envelope)

Also: 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.See: 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
x402 V2

Also: x402Version 2, @x402/core

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.See: Wire format