AI Payment Infrastructure & Crypto Market Making Glossary

An open standard for programmatic, pay-per-request HTTP payments. The server returns HTTP 402 with pricing metadata; the client signs a payment authorization and retries. No accounts, no API keys, no subscriptions — just per-call settlement on-chain or via a facilitator.

See also: AI Agent Payment Infrastructure, x402 vs AMP vs MPP, Beyond the Wallet: policy-controlled x402 payments

A persistent payment-channel protocol for agent payments. The agent deposits funds once, then issues many signed off-chain headers, with periodic on-chain settlement. Optimized for high-volume agents that would otherwise generate thousands of micro-transactions; for 1,000 calls, x402 needs ~1,000 on-chain transactions, AMP needs about 3.

See also: AMP deep dive: channels, state, settlement, Building payment channels with AMP

A higher-level routing layer for agent payments designed to interoperate with multiple rails (e.g. Tempo, Stripe). Sits above per-request protocols like x402 to handle cross-rail settlement, pricing aggregation, and provider selection.

See also: Machine-to-machine payments with x402 and MPP

The HTTP status code reserved in the 1996 spec for "future use" and unused for nearly thirty years. Now repurposed by x402 as the trigger that initiates a programmatic payment handshake between an agent and an API.

An Ethereum token authorization pattern that lets a payer sign a transfer off-chain and let another party submit it on-chain. In agent-payment systems, EIP-3009 is useful because the agent can authorize an exact USDC payment without managing gas in the moment of the API call.

See also: x402 vs AMP vs MPP

An open protocol for connecting LLMs and AI agents to external tools and data through a uniform tool-calling interface. QBT Labs ships OpenMM — an MCP server that exposes market making and trading workflows to agents — as the operating-vertical proof point that infrastructure for agent commerce works under load.

See also: What is an MCP server for crypto trading?, Trading Agents

A keypair (and supporting infrastructure) an autonomous agent uses to sign payments. Distinct from a human wallet because it operates without UI confirmation. Production agent wallets enforce policy at the signer, isolate keys in a separate process, and emit receipts for every signed action.

See also: Beyond the Wallet: policy-controlled agent payments

The component that decides whether an agent is allowed to pay before any signature is produced. Enforces per-transaction caps, daily limits, address allowlists, chain restrictions, and time-of-day rules. Without a policy engine, "give the agent a wallet" is a blank cheque.

See also: Beyond the Wallet: policy-controlled agent payments, AI Agent Payment Infrastructure

Hard ceilings on what the agent can sign for, expressed as caps per transaction, per recipient, per day, or per category. Enforced server-side at the signer, not client-side at the agent runtime. Spend limits are how product teams turn an unbounded LLM into a bounded financial actor.

See also: AI Agent Payment Infrastructure

A durable record of what an agent paid, why it paid, who received the payment, what chain or channel settled it, and what request or resource the payment unlocked. Agent-payment receipts need stable IDs, timestamps, signer address, recipient, asset, amount, status, and settlement reference so finance and compliance teams can audit autonomous spend.

See also: After the signature: receipts, settlement, and audit

Separating the process that holds payment keys from the agent runtime that decides what to do next. The agent proposes a payment; the isolated signer checks policy and produces or rejects the signature. This reduces blast radius if prompts, tools, or model output are compromised.

See also: Beyond the Wallet: policy-controlled agent payments

In x402 flows, an optional third-party service that verifies payment authorizations and handles on-chain settlement on behalf of resource servers. Facilitators let API providers accept programmatic payments without running their own chain integrations or custody.

See also: x402 vs AMP vs MPP

Finalizing a payment by writing it to a chain — or recording it for later batch settlement. In x402, settlement is per request. In AMP, settlement is periodic: many off-chain micropayments collapse into one on-chain transaction. The right choice depends on payment volume, recipient count, and fee tolerance.

See also: AMP deep dive: channels, state, settlement

A stateful payment arrangement where funds are locked once and many signed updates move value off-chain before final settlement. Channels are attractive for high-frequency agent/API relationships because they reduce on-chain transactions, latency, and per-call gas costs.

See also: AMP deep dive: channels, state, settlement

An API that charges for each successful request rather than through monthly subscriptions or prepaid credits. For AI agents, pay-per-request pricing maps cleanly to tool calls: the agent sees a price, checks budget, signs authorization, receives the resource, and records the receipt.

See also: How API providers can monetize AI agents

Continuously quoting bids and asks on crypto exchanges so buyers and sellers can trade with lower friction. A crypto market maker manages inventory, spread, exchange connectivity, latency, and risk across venues. For QBT Labs, market making is also the production workload that validates agent payment and trading infrastructure.

See also: Market Making, What is market making?

Supplying executable buy and sell orders so a market has enough depth for traders to enter and exit positions. Good liquidity provision narrows spreads, reduces slippage, and makes token markets more reliable for users and exchanges.

See also: How to choose a crypto market maker

The difference between the highest price someone is willing to pay (bid) and the lowest price someone is willing to sell (ask). Narrower spreads usually mean better liquidity and lower trading cost; wider spreads often signal risk, low depth, or poor market-maker coverage.

See also: Inside the market making stack

The amount of buy and sell liquidity available at each price level around the mid-price. Deep order books can absorb larger trades with less price movement; shallow books cause larger slippage and worse execution quality.

See also: Anatomy of a market maker

The difference between the expected trade price and the price actually received. Slippage increases when order books are thin, volatility is high, or trade size is large relative to available liquidity. Market makers reduce slippage by keeping depth near the quoted price.

Market making on centralized exchanges such as MEXC, Gate.io, Bitget, Kraken, Binance, or Coinbase. CEX market makers manage API keys, order throttles, inventory across venues, exchange outages, fee tiers, and exchange-specific microstructure.

See also: Multi-exchange market making

Liquidity provision on decentralized exchanges, usually through AMMs or concentrated-liquidity pools rather than central limit order books. DEX market making emphasizes capital efficiency, impermanent loss, on-chain execution costs, and pool range management.

See also: DeFi trading bot architecture lessons

An automated market maker (AMM) prices trades from liquidity-pool math. A professional market maker actively quotes orders, manages inventory, and adjusts spreads based on risk, volatility, and venue data. Both provide liquidity, but their mechanics, risks, and optimization levers are different.

Liquidity visible and executable directly on a blockchain through DEX pools, RFQ systems, or on-chain order books. On-chain liquidity is transparent and composable, but it can be constrained by block times, gas fees, MEV, and capital efficiency.

The risk a market maker takes by holding assets while prices move. If a market maker accumulates too much inventory on one side, adverse price moves can erase spread revenue. Inventory controls, hedging, and venue rebalancing keep this risk bounded.

See also: Crypto market making pricing guide

Payments denominated in stablecoins (USDC, USDT, and similar) at small per-call values — fractions of a cent up to a few dollars. The economic foundation of pay-per-request APIs and agent commerce; volatile native tokens make per-call pricing impractical for buyer and seller.

Payments where neither side is a human at a checkout flow. An AI agent paying an API. A trading bot paying for market data. A workflow paying another workflow. Required when humans aren't in the loop and traditional billing primitives — invoices, subscriptions, manual approvals — don't apply.

See also: AI Agent Payment Infrastructure, AI agents and the payment bottleneck

Charging for API access. Traditional model: subscriptions and API keys for human-managed accounts. Agent-native model: pay-per-request via x402, channels via AMP, with metering, receipts, and abuse controls. The agent-native model unlocks long-tail, low-volume, high-value access that subscription pricing can't reach.

See also: x402 vs AMP vs MPP

The likelihood that answer engines such as ChatGPT, Perplexity, Claude, and Gemini understand, retrieve, and cite a page when users ask about a topic. Definition-rich glossary pages help AI visibility because they expose concise answers, entity relationships, internal links, and structured `DefinedTerm` schema.