| Admission | Permission to start one protected upstream request in a scheduled lane instead of returning another throttle response. It is not a guarantee that the complete response body reaches the client. |
| Admission chain security | The exact-payment boundary published as payment.admissionChainSecurity. In the deployed synchronous profile, two independent RPC providers agree on the Base safe block number and hash, then prove the settlement and minimum depth inside that boundary. Base safe is not irreversible. |
| Binding | The client proof-key thumbprint and exact request context a v2 credential is tied to. |
| Discovery | The v2 Worker's /.well-known/x429.json document. It is capability metadata, not an independent trust root. |
| Free path | Redemption during the signed admission window without an upgrade proof. |
llms.txt | A concise text file that tells agents how to interpret the site and protocol. |
| MCP | Model Context Protocol. MCP servers are good pilot candidates because they are agent-facing and often experience bursty tool traffic. |
| Nonce | The single-use value that prevents replay. |
| Priority | An earlier admission class offered at a price. |
| Execution identity | Durable ownership recorded before an admitted request reaches the fixed upstream. It may release if dispatch never starts; once fetch starts it is terminally consumed even without a response, or remains fenced until bounded consumed-state recovery if finalization fails. |
| Origin assertion | A short-lived Worker signature over the exact upstream request context, receipt digest, and one-time nonce. |
| Payment intent | The global durable binding between one award, EIP-3009 authorization, payer, economics, and settlement state. |
| Payment resume | The original client's signed, no-wallet recovery call after a payment intent is confirmed. It uses the stored award and settlement idempotency key, accepts no new payment signature, and returns the current capacity-backed permit. |
| Reconciliation | Authenticated operator resolution of an indeterminate settlement using matching evidence from two configured RPC URLs. A lost transaction hash can use bounded finalized AuthorizationUsed discovery, followed by mandatory normal verification. Operators must select independently administered providers; URL inequality alone does not prove independence. |
| Recovery slot | One otherwise unused future paid slot outside auction target windows, assigned when a confirmed payment can no longer safely use its original slot. It preserves configured paid capacity. |
| Resource | The configured public origin plus pathname in v2. The method selects a separate coordinator; query values do not partition capacity. |
| Scheduling horizon | The hard X429_MAX_FUTURE_WINDOWS bound for reservations, auction targets, and recovery search. Exact config must leave enough room for interval rounding and settlement lead; exhausted paid targets return auction_horizon_full. |
| Slot | The window from notBefore to notAfter. |
| Ticket breach | A valid ticket presented in-window fails to admit. This should be treated as severe. |
| x402 | The implemented v2 exact-payment rail. x429 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE with EIP-3009. |