@piprail/sdk 2.13.0 → 2.14.0

package/dist/index.d.ts

@@ -1,5 +1,5 @@
-import { C as Caip2, X as X402AcceptEntry, x as X402AnyAccept, z as X402ExactAcceptEntry, d as ExactPaymentPayloadAny, p as SignedReceipt, w as VerifyResult, G as X402UptoAcceptEntry, n as Permit2UptoPaymentPayload, v as SpendSummary, y as X402Challenge, D as X402Receipt, S as SettleOutcome, u as SpendStore, s as SpendLedger, t as SpendRecord, o as PipRailReceipt, V as VerifyErrorCode, a as AssetId, A as AddressId, P as PaidReceipt } from './ledger-mF_SoiDB.js';
-export { E as EXT_OFFER_RECEIPT, b as ExactAuthorizationWire, c as ExactPaymentPayload, H as HEADER_REQUIRED, e as HEADER_RESPONSE, f as HEADER_RESPONSE_V1, g as HEADER_SIGNATURE, h as HEADER_SIGNATURE_V1, i as ParsedExactPayment, j as ParsedUptoPayment, k as Permit2Authorization, l as Permit2PaymentPayload, m as Permit2UptoAuthorization, q as SpendAssetTotal, r as SpendDenomTotal, B as X402PaymentSignature, F as X402ResourceObject, I as buildChallengeHeader, J as buildExactSignatureHeader, K as buildReceiptExtension, L as buildReceiptHeader, M as buildSignatureHeader, N as buildUptoSignatureHeader, O as decodeBase64Json, Q as memorySpendStore, R as parseChallenge, T as parseExactObject, U as parseExactPaymentHeader, W as parseReceipt, Y as parseReceiptExtension, Z as parseSettleResponse, _ as parseSignatureHeader, $ as parseSignatureObject, a0 as parseUptoObject, a1 as parseUptoPaymentHeader, a2 as pickAccept } from './ledger-mF_SoiDB.js';
+import { C as Caip2, X as X402AcceptEntry, y as X402AnyAccept, B as X402ExactAcceptEntry, e as ExactPaymentPayloadAny, q as SignedReceipt, x as VerifyResult, I as X402UptoAcceptEntry, o as Permit2UptoPaymentPayload, w as SpendSummary, z as X402Challenge, F as X402Receipt, S as SettleOutcome, v as SpendStore, t as SpendLedger, u as SpendRecord, p as PipRailReceipt, V as VerifyErrorCode, a as AssetId, A as AddressId, P as PaidReceipt } from './ledger-uFtXlIHY.js';
+export { E as EXT_OFFER_RECEIPT, b as EXT_PAYMENT_IDENTIFIER, c as ExactAuthorizationWire, d as ExactPaymentPayload, H as HEADER_REQUIRED, f as HEADER_RESPONSE, g as HEADER_RESPONSE_V1, h as HEADER_SIGNATURE, i as HEADER_SIGNATURE_V1, j as ParsedExactPayment, k as ParsedUptoPayment, l as Permit2Authorization, m as Permit2PaymentPayload, n as Permit2UptoAuthorization, r as SpendAssetTotal, s as SpendDenomTotal, D as X402PaymentSignature, G as X402ResourceObject, J as buildChallengeHeader, K as buildExactSignatureHeader, L as buildPaymentIdentifierAdvertisement, M as buildReceiptExtension, N as buildReceiptHeader, O as buildSignatureHeader, Q as buildUptoSignatureHeader, R as decodeBase64Json, T as memorySpendStore, U as parseChallenge, W as parseExactObject, Y as parseExactPaymentHeader, Z as parseReceipt, _ as parseReceiptExtension, $ as parseSettleResponse, a0 as parseSignatureHeader, a1 as parseSignatureObject, a2 as parseUptoObject, a3 as parseUptoPaymentHeader, a4 as pickAccept, a5 as readPaymentIdentifier } from './ledger-uFtXlIHY.js';
 import * as viem_zksync from 'viem/zksync';
 import * as abitype from 'abitype';
 import * as viem_chains from 'viem/chains';
@@ -4622,10 +4622,12 @@ declare class MaxRetriesExceededError extends PipRailError {
     /**
      * The proof ref — recover with it, don't re-pay. Its meaning depends on the
      * scheme: for `onchain-proof` it's the already-broadcast transaction ref
-     * (re-verify or re-submit it). For a standard `exact` rail it's the EIP-3009
-     * authorization NONCE (a `0x…` 32-byte value, NOT a tx hash) — re-PRESENT the
-     * same signed authorization, never re-sign a fresh nonce; check the token's
-     * `authorizationState(from, nonce)` before assuming it didn't settle.
+     * (re-verify or re-submit it). For a standard `exact` rail it's the authorization's
+     * single-use marker (NOT a tx hash) — re-PRESENT the same signed authorization, never
+     * re-sign a fresh nonce, and verify it on-chain before assuming it didn't settle. On
+     * EVM that marker is the EIP-3009 NONCE (a `0x…` value), checked via the token's
+     * `authorizationState(from, nonce)`; the non-EVM `exact` rails key off their own marker
+     * (Solana tx signature, Algorand group id, Aptos account sequence number, NEAR access-key nonce).
      */
     readonly ref?: string;
     constructor(message: string, options?: ErrorOptions & {
@@ -4990,8 +4992,8 @@ interface PolicyContext {
 declare function evaluatePolicy(intent: PaymentIntent, policy: PaymentPolicy | undefined, spentForAssetBase: bigint, ctx?: PolicyContext): PolicyDecision;
 
 /** The payment schemes a client can settle: PipRail's native `onchain-proof` (the
- *  default), the standard x402 `exact` rail (EVM EIP-3009/Permit2 + Solana SVM + Algorand,
- *  opt-in), and the standard x402 `upto` (metered) rail (EVM-Permit2, opt-in). */
+ *  default), the standard x402 `exact` rail (EVM EIP-3009/Permit2 + Solana SVM + Algorand
+ *  + Aptos + NEAR, opt-in), and the standard x402 `upto` (metered) rail (EVM-Permit2, opt-in). */
 type PaymentScheme = 'onchain-proof' | 'exact' | 'upto';
 
 /** Observability events. `ref` is the proof — a chain-specific id (EVM tx hash, Solana signature, TON locator, Stellar tx hash). */
@@ -5780,7 +5782,8 @@ declare class PipRailClient {
      *   before publishing, so retry with a brief backoff if a fresh listing is missing.
      * - Results are cross-scheme (mostly the mainstream `exact` scheme); `fetch()` pays
      *   `onchain-proof` rails by default, and standard `exact` rails too once you opt in
-     *   with `schemes: ['onchain-proof', 'exact']` (EVM EIP-3009/Permit2 + Solana SVM + Algorand).
+     *   with `schemes: ['onchain-proof', 'exact']` (EVM EIP-3009/Permit2 + Solana SVM + Algorand
+     *   + Aptos + NEAR).
      */
     discover(opts?: DiscoverOptions): Promise<DiscoveredResource[]>;
     /**
@@ -6275,7 +6278,7 @@ declare function describeChallenge(challenge: X402Challenge): string;
  * literally, so a wrong name or order actively misleads. A test pins the load-
  * bearing phrases.
  */
-declare const PIPRAIL_AGENT_GUIDE = "# Paying with PipRail \u2014 the agent contract\n\nYou can pay for x402 \"402 Payment Required\" resources autonomously. Money moves\nstraight from your wallet to the server; PipRail custodies nothing. Follow this.\n\n## Landing cold \u2014 read the self-description\nEvery PipRail 402 self-describes. Read challenge.extensions.piprail for { name, what, pay[]\n(each rail's how-to-pay), sdk.install, mcp, docs } \u2014 never guess what an endpoint is. If your\ntooling can't pay a rail (e.g. a stock x402 client can't pay the onchain-proof scheme), the\nblock says how: install @piprail/sdk (npm i @piprail/sdk) or run the MCP (npx -y @piprail/mcp)\nand pay with the tools below.\n\n## The loop: quote \u2192 plan \u2192 pay\n1. piprail_quote_payment(url) \u2014 PRICE it. Returns the amount, token, chain, and\n   whether it is within your spend policy. No funds move. Use it to decide if a\n   resource is worth buying.\n2. piprail_plan_payment(url) \u2014 can I afford it NOW? Reads your balance, native gas,\n   and recipient-readiness across every rail, and returns { payable, best,\n   fundingHint, session? }. If payable is false, do NOT attempt the payment \u2014\n   fundingHint says exactly what to fix.\n3. piprail_pay_request(url, method?, body?) \u2014 PAY (only if the plan was payable)\n   and return the result.\nAlways plan before you pay so you never commit to a payment you cannot finish.\n\n## Gasless \u2014 the exact rail (zero gas for you)\nA 402 may offer up to three rails; you don't choose per payment \u2014 the client does, automatically:\n- onchain-proof (PipRail's default): you broadcast the payment yourself and pay the network gas\n  (the native coin \u2014 ETH/SOL/\u2026). Works on every chain.\n- exact (the ratified x402 rail, opt-in): you only SIGN; the server \u2014 or a facilitator it chose\n  (e.g. PayAI) \u2014 broadcasts it, so you pay ZERO gas (you need only the token, no native coin). It\n  works on EVM, Solana + Algorand, and the on-chain method (EIP-3009 / Permit2 / SVM / Algorand\n  fee-pooled group) is picked automatically.\n- upto (the metered/variable x402 rail, opt-in, EVM): the amount you see is a MAXIMUM \u2014 you sign\n  a ceiling, the server meters real usage and settles the ACTUAL (<= the max). BUDGET AGAINST THE MAX:\n  the plan/policy treat the ceiling as the spend (a server may charge up to it), so a payable plan\n  means the MAX fits your budget; the settled actual is recorded for reconciliation.\nWhen the exact scheme is enabled AND balance-aware routing is on, paying picks the cheapest\nsettleable rail \u2014 i.e. the gasless exact one. Nothing changes in your loop: quote \u2192 plan \u2192 pay is\nidentical. The exact/upto schemes are OPT-IN by the operator (MCP: PIPRAIL_SCHEMES=onchain-proof,exact,upto);\nyou can't enable them yourself, but you can report when a 402 needs one (see UNSUPPORTED_SCHEME below).\n\n## Reading a refusal \u2014 never crash, never double-spend\nA failed pay returns a STRUCTURED object, never a thrown error you must catch:\n  { ok:false, code, reason, explain, ref?, reasonCode?, declined? }\nBranch on `code` (always reliable). Key cases:\n- declined:true with reasonCode:'SESSION_EXPIRED' \u2014 your time budget is over. This\n  is TERMINAL: STOP. Do not retry ANY payment this process; it cannot be undone\n  without a restart / a longer TTL.\n- declined:true with reasonCode:'APPROVAL' \u2014 a human (or hook) declined this\n  payment. Terminal for this pay: do NOT auto-retry \u2014 they said no, or no one\n  answered.\n- declined:true with reasonCode:'OUTSIDE_WINDOW' \u2014 your rolling rate-limit is\n  exhausted. Wait for it to free, then retry; do not raise the amount.\n- declined:true with reasonCode:'POLICY' or 'BUDGET' \u2014 a spend cap or allowlist\n  refused it. Don't retry the same payment; pick a cheaper/allowed one.\n- code:'INSUFFICIENT_FUNDS' \u2014 top up the wallet (token and/or native gas), retry.\n- code:'PAYMENT_TIMEOUT' / 'MAX_RETRIES_EXCEEDED' / 'CONFIRMATION_TIMEOUT' \u2014 the\n  payment may ALREADY be on-chain. Recover using the proof on `.ref` (re-verify\n  or re-submit it); never re-pay \u2014 a fresh payment would double-spend. On a gasless\n  exact rail `.ref` is the authorization NONCE, not a tx hash: re-present the SAME\n  signed authorization, never sign a fresh one (that would risk a double-spend).\n- code:'NO_COMPATIBLE_ACCEPT' / 'UNSUPPORTED_SCHEME' \u2014 the 402 isn't payable on\n  your chain/scheme; `explain` says whether it's the wrong chain or a scheme to enable.\n  If it's a standard x402 server offering an exact rail, that's a config fix the operator makes\n  once (enable the exact scheme); report it, don't retry the same call blindly.\n\n## Knowing your leash \u2014 call piprail_budget\npiprail_budget tells you how much budget and time you have left: per (network,\nasset) remaining, the cross-token GRAND TOTAL per denomination (e.g. how much\nUSD you can still spend across every stablecoin and chain), the payment-count\nleash, the session time envelope, your spend so far, and the configured policy\nread back. Read-only; moves no funds. Use it in Mode A to self-check before paying.\n\n## Two modes\n- Mode A (headless, default): you run FREE inside a pre-set budget + time\n  envelope. The policy IS the consent \u2014 there is no per-payment prompt. Stay\n  inside it; piprail_budget shows what's left.\n- Mode B (supervised): the host may ask a human to approve each payment. A\n  decline/cancel/timeout comes back as declined:true (reasonCode:'APPROVAL') \u2014\n  do NOT retry it as if it were a transient error.\n\n## Hard facts\n- Per-payment + per-(network, asset) caps always apply. A cross-token GRAND TOTAL per\n  denomination (maxTotalPerDenom, e.g. \"$20 across every USD stablecoin + chain\") is\n  OPTIONAL \u2014 it sums tokens declared as one unit, each 1:1; it is NOT a price oracle and\n  never prices a volatile native coin. Payment-COUNT caps (maxPayments / per-window) also\n  span every chain + token.\n- The time envelope lives IN-MEMORY for THIS process (resets on restart). The money + count\n  totals also reset on restart UNLESS a durable spend store is configured \u2014 then they resume.\n- A refusal arrives as declined:true with a reasonCode; 'BUDGET' covers the lifetime, denom,\n  and count caps; 'OUTSIDE_WINDOW' covers both the rolling money and rolling count windows.\n";
+declare const PIPRAIL_AGENT_GUIDE = "# Paying with PipRail \u2014 the agent contract\n\nYou can pay for x402 \"402 Payment Required\" resources autonomously. Money moves\nstraight from your wallet to the server; PipRail custodies nothing. Follow this.\n\n## Landing cold \u2014 read the self-description\nEvery PipRail 402 self-describes. Read challenge.extensions.piprail for { name, what, pay[]\n(each rail's how-to-pay), sdk.install, mcp, docs } \u2014 never guess what an endpoint is. If your\ntooling can't pay a rail (e.g. a stock x402 client can't pay the onchain-proof scheme), the\nblock says how: install @piprail/sdk (npm i @piprail/sdk) or run the MCP (npx -y @piprail/mcp)\nand pay with the tools below.\n\n## The loop: quote \u2192 plan \u2192 pay\n1. piprail_quote_payment(url) \u2014 PRICE it. Returns the amount, token, chain, and\n   whether it is within your spend policy. No funds move. Use it to decide if a\n   resource is worth buying.\n2. piprail_plan_payment(url) \u2014 can I afford it NOW? Reads your balance, native gas,\n   and recipient-readiness across every rail, and returns { payable, best,\n   fundingHint, session? }. If payable is false, do NOT attempt the payment \u2014\n   fundingHint says exactly what to fix.\n3. piprail_pay_request(url, method?, body?) \u2014 PAY (only if the plan was payable)\n   and return the result.\nAlways plan before you pay so you never commit to a payment you cannot finish.\n\n## Gasless \u2014 the exact rail (zero gas for you)\nA 402 may offer up to three rails; you don't choose per payment \u2014 the client does, automatically:\n- onchain-proof (PipRail's default): you broadcast the payment yourself and pay the network gas\n  (the native coin \u2014 ETH/SOL/\u2026). Works on every chain.\n- exact (the ratified x402 rail, opt-in): you only SIGN; the server \u2014 or a facilitator it chose\n  (e.g. PayAI) \u2014 broadcasts it, so you pay ZERO gas (you need only the token, no native coin). It\n  works on EVM, Solana, Algorand, Aptos + NEAR, and the on-chain method (EIP-3009 / Permit2 / SVM /\n  Algorand fee-pooled group / Aptos fee-payer / NEAR SignedDelegateAction) is picked automatically.\n- upto (the metered/variable x402 rail, opt-in, EVM): the amount you see is a MAXIMUM \u2014 you sign\n  a ceiling, the server meters real usage and settles the ACTUAL (<= the max). BUDGET AGAINST THE MAX:\n  the plan/policy treat the ceiling as the spend (a server may charge up to it), so a payable plan\n  means the MAX fits your budget; the settled actual is recorded for reconciliation.\nWhen the exact scheme is enabled AND balance-aware routing is on, paying picks the cheapest\nsettleable rail \u2014 i.e. the gasless exact one. Nothing changes in your loop: quote \u2192 plan \u2192 pay is\nidentical. The exact/upto schemes are OPT-IN by the operator (MCP: PIPRAIL_SCHEMES=onchain-proof,exact,upto);\nyou can't enable them yourself, but you can report when a 402 needs one (see UNSUPPORTED_SCHEME below).\n\n## Reading a refusal \u2014 never crash, never double-spend\nA failed pay returns a STRUCTURED object, never a thrown error you must catch:\n  { ok:false, code, reason, explain, ref?, reasonCode?, declined? }\nBranch on `code` (always reliable). Key cases:\n- declined:true with reasonCode:'SESSION_EXPIRED' \u2014 your time budget is over. This\n  is TERMINAL: STOP. Do not retry ANY payment this process; it cannot be undone\n  without a restart / a longer TTL.\n- declined:true with reasonCode:'APPROVAL' \u2014 a human (or hook) declined this\n  payment. Terminal for this pay: do NOT auto-retry \u2014 they said no, or no one\n  answered.\n- declined:true with reasonCode:'OUTSIDE_WINDOW' \u2014 your rolling rate-limit is\n  exhausted. Wait for it to free, then retry; do not raise the amount.\n- declined:true with reasonCode:'POLICY' or 'BUDGET' \u2014 a spend cap or allowlist\n  refused it. Don't retry the same payment; pick a cheaper/allowed one.\n- code:'INSUFFICIENT_FUNDS' \u2014 top up the wallet (token and/or native gas), retry.\n- code:'PAYMENT_TIMEOUT' / 'MAX_RETRIES_EXCEEDED' / 'CONFIRMATION_TIMEOUT' \u2014 the\n  payment may ALREADY be on-chain. Recover using the proof on `.ref` (re-verify\n  or re-submit it); never re-pay \u2014 a fresh payment would double-spend. On a gasless\n  exact rail `.ref` is the authorization NONCE, not a tx hash: re-present the SAME\n  signed authorization, never sign a fresh one (that would risk a double-spend).\n- code:'NO_COMPATIBLE_ACCEPT' / 'UNSUPPORTED_SCHEME' \u2014 the 402 isn't payable on\n  your chain/scheme; `explain` says whether it's the wrong chain or a scheme to enable.\n  If it's a standard x402 server offering an exact rail, that's a config fix the operator makes\n  once (enable the exact scheme); report it, don't retry the same call blindly.\n\n## Knowing your leash \u2014 call piprail_budget\npiprail_budget tells you how much budget and time you have left: per (network,\nasset) remaining, the cross-token GRAND TOTAL per denomination (e.g. how much\nUSD you can still spend across every stablecoin and chain), the payment-count\nleash, the session time envelope, your spend so far, and the configured policy\nread back. Read-only; moves no funds. Use it in Mode A to self-check before paying.\n\n## Two modes\n- Mode A (headless, default): you run FREE inside a pre-set budget + time\n  envelope. The policy IS the consent \u2014 there is no per-payment prompt. Stay\n  inside it; piprail_budget shows what's left.\n- Mode B (supervised): the host may ask a human to approve each payment. A\n  decline/cancel/timeout comes back as declined:true (reasonCode:'APPROVAL') \u2014\n  do NOT retry it as if it were a transient error.\n\n## Hard facts\n- Per-payment + per-(network, asset) caps always apply. A cross-token GRAND TOTAL per\n  denomination (maxTotalPerDenom, e.g. \"$20 across every USD stablecoin + chain\") is\n  OPTIONAL \u2014 it sums tokens declared as one unit, each 1:1; it is NOT a price oracle and\n  never prices a volatile native coin. Payment-COUNT caps (maxPayments / per-window) also\n  span every chain + token.\n- The time envelope lives IN-MEMORY for THIS process (resets on restart). The money + count\n  totals also reset on restart UNLESS a durable spend store is configured \u2014 then they resume.\n- A refusal arrives as declined:true with a reasonCode; 'BUDGET' covers the lifetime, denom,\n  and count caps; 'OUTSIDE_WINDOW' covers both the rolling money and rolling count windows.\n";
 /** Returns {@link PIPRAIL_AGENT_GUIDE} (a parity accessor for callers that prefer a function). */
 declare function agentGuide(): string;
 
@@ -6435,6 +6438,17 @@ interface SelfDescription {
  * `accepts[]`. PURE — every rail is derived from data the gate already has (no new
  * data, no I/O). `instruction` is the optional one-line human summary the gate computes
  * via `describeChallenge` (in `render.ts`) and passes in.
+ *
+ * INVARIANT — this block emits NO per-response DYNAMIC field (no nonce, timestamp, or
+ * other per-call value). It is long-lived, static metadata: brand-string constants plus
+ * values derived from the (static) resolved `accepts[]`. This matters for the x402
+ * `dynamicInfoFields` mechanism (x402-foundation #2655): an official client that
+ * echo-validates `extensions` does a SUBSET check — an UNDECLARED field that changes per
+ * response would trip `extension_echo_mismatch` and false-reject the buyer. If you EVER
+ * add a per-call value to this block, you MUST either (1) keep it out, or (2) declare it
+ * in a `dynamicInfoFields` list the echo check honours. See
+ * `.claude/plans/x402-maxout/05-additive-conformance.md` §4.3 — and the regression guard
+ * in `test/selfdescribe.test.ts` that fails the day a dynamic field appears here.
  */
 declare function buildSelfDescription(input: {
     accepts: X402AnyAccept[];
@@ -6616,6 +6630,50 @@ interface WellKnownX402 {
     resources: string[];
     ownershipProofs?: string[];
 }
+/**
+ * The official `/.well-known/x402.json` discovery manifest (x402-foundation PR #2646,
+ * "Well known x402 discovery" — **DO NOT MERGE YET / for discussion**). A RICHER origin
+ * file than the legacy {@link WellKnownX402}: per-item resource metadata + the resolved
+ * `accepts` + a lifted input/output contract. PipRail emits this as a SECOND,
+ * forward-compatible artifact — {@link buildWellKnownX402} (the x402scan legacy file) is
+ * left untouched, so nothing is pinned to an unstable spec. The merchant hosts the result
+ * at `<origin>/.well-known/x402.json`.
+ */
+interface WellKnownX402Manifest {
+    x402Version: 2;
+    /** Unix timestamp (seconds) the manifest was generated. */
+    lastUpdated: number;
+    items: WellKnownX402Item[];
+}
+/** One resource in a {@link WellKnownX402Manifest}. The live 402 stays authoritative —
+ *  `accepts` here is advisory, nonce-free discovery metadata. */
+interface WellKnownX402Item {
+    resource: {
+        url: string;
+        description?: string;
+        mimeType?: string;
+        serviceName?: string;
+        tags?: string[];
+    };
+    /** The transport the resource is paid over. PipRail emits `'http'` today. */
+    type: 'http' | 'mcp';
+    /** The payment options the gate offers (its resolved rails, nonce-free). */
+    accepts: PaymentRail[];
+    /** How to call the resource (lifted from the route config). */
+    input?: {
+        method: string;
+        routeTemplate?: string;
+        pathParams?: Record<string, unknown>;
+        queryParams?: Record<string, unknown>;
+    };
+    /** Output hint for a richer listing. */
+    output?: {
+        mimeType?: string;
+        example?: unknown;
+    };
+    /** Capability hints (extension keys) the resource requires, when any. */
+    requires?: string[];
+}
 /**
  * Describes a resource's INPUT for discovery. The open indexes that REQUIRE an
  * input schema (x402scan rejects a listing without one) read this from a
@@ -6682,6 +6740,18 @@ declare function buildOpenApi(input: ManifestInput): OpenApiDocument;
  * `/openapi.json` is the primary doc; this is a compatibility breadcrumb.
  */
 declare function buildWellKnownX402(input: ManifestInput): WellKnownX402;
+/**
+ * Build the official `/.well-known/x402.json` manifest (x402-foundation PR #2646 shape) — a
+ * SECOND, richer discovery file beside the legacy {@link buildWellKnownX402}. Forward-compatible
+ * by design: it emits only the fields the proposal defines, tolerates the spec adding more, and
+ * pins nothing (the PR is explicitly pre-merge), so when #2646 stabilises only this one emitter
+ * (and the docs recommendation) move — no default ever changed. `lastUpdated` defaults to now
+ * (Unix seconds); pass it explicitly for a deterministic file. PURE — no network, no chain
+ * library, fully deterministic given its args. The merchant hosts the result; PipRail serves nothing.
+ */
+declare function buildWellKnownX402Manifest(input: ManifestInput & {
+    lastUpdated?: number;
+}): WellKnownX402Manifest;
 /**
  * Build the `_x402` DNS TXT record (experimental draft) that POINTS at a
  * discovery doc. `host` is the exact host the agent talks to (no inheritance);
@@ -6981,6 +7051,19 @@ interface RequirePaymentOptions {
      * byte-identical default of before this feature). See {@link buildSelfDescription}.
      */
     selfDescribe?: boolean;
+    /**
+     * Advertise + honor the standard x402 **`payment-identifier`** extension — an OPTIONAL
+     * idempotency `id` (16–128 chars `[A-Za-z0-9_-]`) the client attaches to its payload at
+     * `extensions['payment-identifier'].info.id`. When on, the gate advertises the extension on
+     * every 402 and, on submission, **dedupes the id on its existing used-proof set** (namespaced
+     * `pid:<id>`): a reused id bound to a different/already-settled payment is rejected
+     * (`tx_already_used`), a malformed id is re-challenged (`signature_invalid`), and the id is
+     * echoed back on the settled `PAYMENT-RESPONSE`. The id is ADDITIVE to — never a replacement
+     * for — the proof-set replay protection (a payment with no id is protected exactly as today).
+     * **Default off** (the challenge + verdict are byte-identical). Backendless: the dedupe rides
+     * the same in-memory / pluggable `isUsed`/`markUsed` store as a tx ref — no new state.
+     */
+    paymentIdentifier?: boolean;
     /**
      * Emit a **verifiable receipt** on every settled payment — a self-contained
      * {@link PipRailReceipt} that the buyer keeps and **anyone** re-verifies against the
@@ -7306,7 +7389,11 @@ interface DeliverReceiptOptions {
     url: string;
     /**
      * Shared secret. When set, the raw JSON body is signed HMAC-SHA256 and sent as
-     * `<signatureHeader>: sha256=<hex>` so the receiver can verify authenticity.
+     * `<signatureHeader>: sha256=<hex>` so the receiver can verify authenticity. Signing uses Web
+     * Crypto (`crypto.subtle`) — always present on the supported runtimes (Node ≥ 20, modern
+     * browsers). On a runtime that lacks it the body is sent **unsigned, with no signature header**,
+     * so a receiver must treat a *missing* signature as unauthenticated (reject it), never silently
+     * accept an unsigned body.
      */
     secret?: string;
     /** Extra retry attempts after the first send (default 5 → up to 6 POSTs total). */
@@ -8127,4 +8214,186 @@ interface A2APaymentHandler {
  */
 declare function createA2APaymentHandler(options: A2APaymentHandlerOptions): A2APaymentHandler;
 
-export { type A2AArtifact, type A2AExtensionDeclaration, type A2AMessage, type A2AMetadata, type A2APart, type A2APaymentHandler, type A2APaymentHandlerOptions, type A2APaymentStatus, type A2ATask, type A2ATaskRecord, type A2ATaskState, type A2ATaskStore, A2A_ERROR_KEY, A2A_EXTENSIONS_HEADER, A2A_PAYLOAD_KEY, A2A_RECEIPTS_KEY, A2A_REQUIRED_KEY, A2A_STATUS_KEY, A2A_X402_EXTENSION_URI_V01, A2A_X402_EXTENSION_URI_V02, type AcceptOption, AddressId, type AgentTool, type AlgorandToken, type AptosToken, AssetId, BRAND, BUILTIN_DENOMS, type BazaarExtension, type BuildExactParams, CHAINS, Caip2, type ChainFamily, type ChainInput, type ChainName, type ChainPreset, type ChainSelector, type ChallengeTriage, type ChallengeVerdict, type ConfirmInfo, ConfirmationTimeoutError, type CostEstimate, type CountStatus, DENOM_PRECISION, DIRECTORY_INFO, type DeclineReasonCode, type DeliverAttempt, type DeliverReceiptOptions, type DeliverResult, type DenomRemaining, type DirectoryInfo, type DiscoverOptions, type DiscoveredRail, type DiscoveredResource, type DiscoveryDescriptor, type DiscoverySigner, type DiscoverySort, type DiscoverySource, type DomainClaim, type DomainVerification, EIP3009_TYPES, EXACT_NETWORK_SLUGS, type EvmToken, type ExactAccept, type ExactAuthorization, ExactPaymentPayloadAny, type ExactRailOption, type ExpressLikeMiddleware, type ExpressLikeNext, type ExpressLikeRequest, type ExpressLikeResponse, type FacilitatorConfig, type FacilitatorPaymentRequirements, type FacilitatorSupportedKind, type FailedPayment, GENERATOR, InsufficientFundsError, InvalidEnvelopeError, KNOWN_FACILITATORS, type KnownFacilitator, type ListingVisibility, type ManifestInput, MaxRetriesExceededError, MissingDriverError, MultiChainPayer, type MultiChainPayerOptions, type NearToken, NoCompatibleAcceptError, NonReplayableBodyError, type OpenApiDocument, type OpenApiOperation, PERMIT2_ADDRESS, PERMIT2_PROXY_CHAIN_IDS, PERMIT2_UPTO_WITNESS_TYPES, PERMIT2_WITNESS_TYPES, PIPRAIL_AGENT_GUIDE, POWERED_BY, PaidReceipt, type PayBlocker, type PayOption, type PayWarning, type PayingClient, PaymentDeclinedError, type PaymentDriver, type PaymentGate, type PaymentIntent, type PaymentPlan, type PaymentPolicy, type PaymentRail, type PaymentScheme, PaymentTimeoutError, Permit2UptoPaymentPayload, PipRailClient, type PipRailClientOptions, type PipRailCostQuote, PipRailError, type PipRailEvent, type PipRailQuote, PipRailReceipt, type PolicyDecision, type PolicyDenyCode, REGISTER_ATTRIBUTION, type ReceiptInput, type ReceiptOption, type ReceiptVerification, RecipientNotReadyError, type RecipientReason, type RegisterInput, type RegisterOptions, type RegisterOutcome, type RequirePaymentOptions, type ResolveOptions, type ResolvedChain, type ResolvedNetwork, type ResolvedToken, type ResourceDescription, type SearchOpenIndexesOptions, type SelfDescribeEndpoint, type SelfDescribeRail, type SelfDescription, type SessionBudget, SettleOutcome, type SettleViaFacilitatorInput, SettlementError, SignedReceipt, type SolanaToken, SpendLedger, SpendRecord, type SpendRemaining, SpendStore, SpendSummary, type StellarToken, type SuiToken, type TokenInfo, type TokenInput, type TonToken, type ToolAnnotations, type TronToken, UPTO_PROXY_CHAIN_IDS, UnknownTokenError, UnsupportedNetworkError, UnsupportedSchemeError, type UptoRailOption, VERIFY_CODE_TO_A2A_ERROR, VerifyErrorCode, type VerifyPaymentResult, VerifyResult, type WalletBalance, type WalletHandle, type WalletInput, WalletRequiredError, type WellKnownX402, WrongChainError, WrongFamilyError, X402AcceptEntry, X402AnyAccept, X402Challenge, type X402DnsRecord, X402ExactAcceptEntry, type X402InvalidBody, X402Receipt, X402UptoAcceptEntry, X402_EXACT_PERMIT2_PROXY, X402_UPTO_PERMIT2_PROXY, type XrplToken, agentGuide, appendAttribution, appendKeywords, buildBazaarExtension, buildEndpointInfo, buildExactAuthorization, buildOpenApi, buildSelfDescription, buildWellKnownX402, buildX402DnsTxt, chainIdForExactNetwork, claim402IndexDomain, classifyChallenge, createA2APaymentHandler, createPaymentGate, decorateOutcome, deliverReceipt, denomOf, describeChallenge, discoveryHeaders, eip3009Abi, encodeXPaymentHeader, evaluatePolicy, explainDecline, facilitatorCoverage, fetchAcross, firstKeylessFacilitator, formatSpendReport, fromA2APaymentPayload, fromA2APaymentRequired, getDirectoryInfo, isPermit2ProxyChain, isUptoProxyChain, knownFacilitatorsFor, normalizeNetwork, parseExactRequirements, parseFacilitatorSupported, paymentTools, planAcross, rankResources, readExactDomain, register402Index, registerDriver, registerX402Scan, renderLandingPage, requirePayment, resolveChain, scoreResource, searchOpenIndexes, settleViaFacilitator, summarizePlan, toA2AErrorCode, toA2APaymentFailed, toA2APaymentReceipts, toA2APaymentRequired, toInsufficientFundsError, toInvalidBody, verify402IndexDomain };
+/**
+ * Minimal, DUCK-TYPED MCP message shapes — the structural surface the PipRail MCP transport
+ * reads/writes, and NOTHING more. Like `a2a-types.ts`, these declare only the fields the adapter
+ * touches, so any MCP runtime's objects (the `@modelcontextprotocol/sdk` low-level `Server`, a
+ * hand-rolled tool handler) satisfy them structurally — **with ZERO `@modelcontextprotocol/sdk`
+ * dependency** (the SDK transport stays chain- AND runtime-agnostic; the `@piprail/mcp` wiring may
+ * use the real MCP types).
+ *
+ * x402-over-MCP carries PipRail's EXISTING `X402Challenge` / PaymentPayload / `SettleOutcome`
+ * envelopes over MCP **tool calls**: a 402 challenge as an `isError` tool result (the
+ * PaymentRequired in `structuredContent` AND a byte-equal `content[0].text`), the payment under
+ * the call's `params._meta["x402/payment"]`, the settlement under the result's
+ * `_meta["x402/payment-response"]`. Verified against the x402-foundation
+ * `specs/transports-v2/mcp.md` binding.
+ */
+
+/** The `_meta` key strings — EXACTLY as the spec defines them (a SLASH, not a dot — distinct from
+ *  A2A's `x402.payment.*` dotted keys). Exported so the conformance test pins them. */
+declare const MCP_PAYMENT_META_KEY = "x402/payment";
+declare const MCP_PAYMENT_RESPONSE_META_KEY = "x402/payment-response";
+/** A single MCP content block (only the text block the binding uses). */
+interface McpContentBlock {
+    type: 'text' | string;
+    text?: string;
+    [extra: string]: unknown;
+}
+/** An inbound tool-call's params — only the fields the seller reads. `_meta["x402/payment"]`
+ *  carries the raw PaymentPayload object (fed straight to `gate.verifyObject`). */
+interface McpToolCallParams {
+    name?: string;
+    arguments?: Record<string, unknown>;
+    _meta?: {
+        'x402/payment'?: unknown;
+        [extra: string]: unknown;
+    };
+    [extra: string]: unknown;
+}
+/** A tool result — the seller produces it; the buyer reads it. The 402 challenge is an `isError`
+ *  result with `structuredContent` + a byte-equal `content[0].text`; a settlement carries
+ *  `_meta["x402/payment-response"]`. */
+interface McpToolResult {
+    content: McpContentBlock[];
+    isError?: boolean;
+    structuredContent?: Record<string, unknown>;
+    _meta?: {
+        'x402/payment-response'?: SettleOutcome;
+        [extra: string]: unknown;
+    };
+    [extra: string]: unknown;
+}
+/** The PaymentPayload value carried under `params._meta["x402/payment"]` (raw JSON, not base64) —
+ *  `{ x402Version, resource?, accepted, payload }`, where `accepted` is the chosen `accepts[]`
+ *  entry and `payload` is the scheme payload (both consumed by `gate.verifyObject`). */
+interface McpPaymentMeta {
+    x402Version: number;
+    resource?: {
+        url: string;
+        description?: string;
+        mimeType?: string;
+    };
+    accepted: unknown;
+    payload: unknown;
+}
+
+/**
+ * x402-over-MCP — the third official x402 transport (after HTTP and A2A), carrying PipRail's
+ * EXISTING x402 envelopes over MCP **tool calls** instead of HTTP headers or A2A task metadata:
+ *
+ *   - a 402 challenge is an `isError` tool result with the `X402Challenge` (the spec's
+ *     PaymentRequired) in `structuredContent` AND a byte-equal `content[0].text`;
+ *   - the payment rides in the call's `params._meta["x402/payment"]`;
+ *   - the settlement rides in the result's `_meta["x402/payment-response"]`.
+ *
+ * It is the conspicuous missing twin of the A2A transport. A thin re-keying of the SDK's verify
+ * onto the MCP message shape — the SELLER calls the EXISTING `gate.verifyObject` (shared replay
+ * set, re-derive-every-field-from-the-trusted-accept), so this transport writes NO crypto and
+ * touches NO driver: every family rides it for free, exactly as over HTTP/A2A.
+ *
+ * PURE protocol layer (STANDARDS §1): imports only `server.ts`/`x402.ts`/`errors.ts` + the
+ * duck-typed `./mcp-types.js` + the A2A error map — ZERO chain libs, ZERO `@modelcontextprotocol/sdk`.
+ *
+ * Scope: this ships the SELLER (`createMcpPaymentTool`) + the full pure codec + the buyer-side
+ * READ/FRAME helpers (`fromMcpPaymentRequired` / `fromMcpPaymentResponse` / `buildMcpPaymentMeta`).
+ * A buyer pays the challenge via the existing policy-gated client/gate machinery and frames the
+ * result with `buildMcpPaymentMeta`; a fully-automatic `McpPayer` (driving the client pay path) is
+ * a documented fast-follow, exactly as A2A shipped seller-first.
+ */
+
+/**
+ * Build the 402 challenge tool result: `isError: true` + the `X402Challenge` in
+ * `structuredContent` AND a **byte-equal** `content[0].text` (`text === JSON.stringify(challenge)`
+ * — the spec requires the two to match; a divergence is a silent interop break, guarded by the
+ * conformance test). PipRail's `X402Challenge` IS the spec's PaymentRequired object — no transform.
+ */
+declare function toMcpPaymentRequired(challenge: X402Challenge): McpToolResult;
+/**
+ * Build the settled tool result: the tool's REAL output in `content` + the settlement under
+ * `_meta["x402/payment-response"]`, projected to EXACTLY the spec's 4 fields
+ * `{ success, transaction, network, payer }` (the richer {@link X402Receipt} is never leaked verbatim).
+ */
+declare function toMcpPaymentResponse(content: McpContentBlock[], receipt: X402Receipt): McpToolResult;
+/**
+ * Read the inbound RAW payment-payload object out of a tool call's `params._meta["x402/payment"]`.
+ * The value is `{ x402Version, resource?, accepted, payload }`; `gate.verifyObject` reads
+ * `accepted`/`payload` and ignores the extra `resource` sibling — so it's handed in as-is. Returns
+ * `null` when there's no payment (→ the seller emits a fresh 402 challenge).
+ */
+declare function fromMcpPayment(params: McpToolCallParams): unknown | null;
+/**
+ * Read the `X402Challenge` (PaymentRequired) back out of an `isError` tool result — the BUYER side.
+ * Reads `structuredContent` first; falls back to parsing `content[0].text`. Returns `null` when the
+ * result is not a 402 (a plain tool failure, or a success) so a buyer never mistakes a non-402
+ * `isError` for a payment request.
+ */
+declare function fromMcpPaymentRequired(result: McpToolResult): X402Challenge | null;
+/** Is this tool result a 402 challenge (an `isError` result carrying a parseable PaymentRequired)? */
+declare function isMcpPaymentRequired(result: McpToolResult): boolean;
+/**
+ * Read the settlement {@link SettleOutcome} back out of a settled tool result's
+ * `_meta["x402/payment-response"]` — the BUYER side. Returns `null` when absent. The buyer records
+ * the spend only on `success: true` (the existing `parseSettleResponse` rule).
+ */
+declare function fromMcpPaymentResponse(result: McpToolResult): SettleOutcome | null;
+/**
+ * Frame an already-produced payment (the SAME `{ accepted, payload }` a PipRail buyer builds for
+ * HTTP/A2A, after paying through the policy-gated client/gate machinery) into the
+ * `_meta["x402/payment"]` entry to attach to the RETRY tool call's `params._meta`. Pure codec — it
+ * mints no signature and grants no spend authority; the buyer signs/broadcasts via the existing
+ * client, then frames the result here for the MCP carrier.
+ */
+declare function buildMcpPaymentMeta(input: {
+    accepted: unknown;
+    payload: unknown;
+    resource?: {
+        url: string;
+        description?: string;
+        mimeType?: string;
+    };
+    x402Version?: number;
+}): {
+    'x402/payment': McpPaymentMeta;
+};
+/** Options for {@link createMcpPaymentTool}. */
+interface McpPaymentToolOptions extends Partial<RequirePaymentOptions> {
+    /**
+     * Pass the SAME {@link PaymentGate} the HTTP/A2A paths use → ONE shared replay set
+     * (`localUsed` / injected `isUsed`/`markUsed`), so a proof settled over one transport and
+     * replayed over MCP is caught once. If omitted, a fresh gate is built from the inline gate
+     * config (`chain`/`token`/`amount`/`payTo`/…) on these same options.
+     */
+    gate?: PaymentGate;
+    /** Produce the tool's REAL output AFTER a verified settle — the merchant's own work. */
+    fulfill: (ctx: {
+        receipt: X402Receipt;
+        params: McpToolCallParams;
+    }) => Promise<McpContentBlock[]> | McpContentBlock[];
+    /** Resource URL stamped into the challenge (cosmetic; MCP tools have no inherent URL). */
+    resourceUrl?: string;
+}
+/** A paid MCP tool — turns one inbound tool call into the next tool result. */
+interface McpPaymentTool {
+    /**
+     * Process one inbound tool call → the next tool result:
+     *   - no `_meta` payment        → `isError` + a PaymentRequired challenge
+     *   - payment, verified+settled → the `fulfill` output + `_meta` payment-response
+     *   - settled but `fulfill` threw → STILL a `_meta` payment-response (success) + an error note in
+     *                                   content — never a re-challenge (the proof already settled; B7)
+     *   - payment, rejected/malformed → `isError` + a FRESH re-challenge PaymentRequired (retry)
+     *   - settle threw (relayer)     → `isError` + "settlement failed" (onchain-proof fallback noted)
+     */
+    handleToolCall(params: McpToolCallParams): Promise<McpToolResult>;
+    /** The underlying gate (the shared replay set lives here). */
+    readonly gate: PaymentGate;
+}
+/**
+ * Wrap an x402 {@link PaymentGate} as a paid MCP tool — the MCP analogue of `requirePayment` /
+ * `createA2APaymentHandler`. All verify/settle/replay is the gate's `verifyObject` (the same seam
+ * A2A uses): the trusted-accept re-derivation, the bounded replay set, self/facilitator settlement
+ * — none of it is re-implemented here. Backendless: the merchant self-verifies and self-settles.
+ */
+declare function createMcpPaymentTool(options: McpPaymentToolOptions): McpPaymentTool;
+
+export { type A2AArtifact, type A2AExtensionDeclaration, type A2AMessage, type A2AMetadata, type A2APart, type A2APaymentHandler, type A2APaymentHandlerOptions, type A2APaymentStatus, type A2ATask, type A2ATaskRecord, type A2ATaskState, type A2ATaskStore, A2A_ERROR_KEY, A2A_EXTENSIONS_HEADER, A2A_PAYLOAD_KEY, A2A_RECEIPTS_KEY, A2A_REQUIRED_KEY, A2A_STATUS_KEY, A2A_X402_EXTENSION_URI_V01, A2A_X402_EXTENSION_URI_V02, type AcceptOption, AddressId, type AgentTool, type AlgorandToken, type AptosToken, AssetId, BRAND, BUILTIN_DENOMS, type BazaarExtension, type BuildExactParams, CHAINS, Caip2, type ChainFamily, type ChainInput, type ChainName, type ChainPreset, type ChainSelector, type ChallengeTriage, type ChallengeVerdict, type ConfirmInfo, ConfirmationTimeoutError, type CostEstimate, type CountStatus, DENOM_PRECISION, DIRECTORY_INFO, type DeclineReasonCode, type DeliverAttempt, type DeliverReceiptOptions, type DeliverResult, type DenomRemaining, type DirectoryInfo, type DiscoverOptions, type DiscoveredRail, type DiscoveredResource, type DiscoveryDescriptor, type DiscoverySigner, type DiscoverySort, type DiscoverySource, type DomainClaim, type DomainVerification, EIP3009_TYPES, EXACT_NETWORK_SLUGS, type EvmToken, type ExactAccept, type ExactAuthorization, ExactPaymentPayloadAny, type ExactRailOption, type ExpressLikeMiddleware, type ExpressLikeNext, type ExpressLikeRequest, type ExpressLikeResponse, type FacilitatorConfig, type FacilitatorPaymentRequirements, type FacilitatorSupportedKind, type FailedPayment, GENERATOR, InsufficientFundsError, InvalidEnvelopeError, KNOWN_FACILITATORS, type KnownFacilitator, type ListingVisibility, MCP_PAYMENT_META_KEY, MCP_PAYMENT_RESPONSE_META_KEY, type ManifestInput, MaxRetriesExceededError, type McpContentBlock, type McpPaymentMeta, type McpPaymentTool, type McpPaymentToolOptions, type McpToolCallParams, type McpToolResult, MissingDriverError, MultiChainPayer, type MultiChainPayerOptions, type NearToken, NoCompatibleAcceptError, NonReplayableBodyError, type OpenApiDocument, type OpenApiOperation, PERMIT2_ADDRESS, PERMIT2_PROXY_CHAIN_IDS, PERMIT2_UPTO_WITNESS_TYPES, PERMIT2_WITNESS_TYPES, PIPRAIL_AGENT_GUIDE, POWERED_BY, PaidReceipt, type PayBlocker, type PayOption, type PayWarning, type PayingClient, PaymentDeclinedError, type PaymentDriver, type PaymentGate, type PaymentIntent, type PaymentPlan, type PaymentPolicy, type PaymentRail, type PaymentScheme, PaymentTimeoutError, Permit2UptoPaymentPayload, PipRailClient, type PipRailClientOptions, type PipRailCostQuote, PipRailError, type PipRailEvent, type PipRailQuote, PipRailReceipt, type PolicyDecision, type PolicyDenyCode, REGISTER_ATTRIBUTION, type ReceiptInput, type ReceiptOption, type ReceiptVerification, RecipientNotReadyError, type RecipientReason, type RegisterInput, type RegisterOptions, type RegisterOutcome, type RequirePaymentOptions, type ResolveOptions, type ResolvedChain, type ResolvedNetwork, type ResolvedToken, type ResourceDescription, type SearchOpenIndexesOptions, type SelfDescribeEndpoint, type SelfDescribeRail, type SelfDescription, type SessionBudget, SettleOutcome, type SettleViaFacilitatorInput, SettlementError, SignedReceipt, type SolanaToken, SpendLedger, SpendRecord, type SpendRemaining, SpendStore, SpendSummary, type StellarToken, type SuiToken, type TokenInfo, type TokenInput, type TonToken, type ToolAnnotations, type TronToken, UPTO_PROXY_CHAIN_IDS, UnknownTokenError, UnsupportedNetworkError, UnsupportedSchemeError, type UptoRailOption, VERIFY_CODE_TO_A2A_ERROR, VerifyErrorCode, type VerifyPaymentResult, VerifyResult, type WalletBalance, type WalletHandle, type WalletInput, WalletRequiredError, type WellKnownX402, type WellKnownX402Item, type WellKnownX402Manifest, WrongChainError, WrongFamilyError, X402AcceptEntry, X402AnyAccept, X402Challenge, type X402DnsRecord, X402ExactAcceptEntry, type X402InvalidBody, X402Receipt, X402UptoAcceptEntry, X402_EXACT_PERMIT2_PROXY, X402_UPTO_PERMIT2_PROXY, type XrplToken, agentGuide, appendAttribution, appendKeywords, buildBazaarExtension, buildEndpointInfo, buildExactAuthorization, buildMcpPaymentMeta, buildOpenApi, buildSelfDescription, buildWellKnownX402, buildWellKnownX402Manifest, buildX402DnsTxt, chainIdForExactNetwork, claim402IndexDomain, classifyChallenge, createA2APaymentHandler, createMcpPaymentTool, createPaymentGate, decorateOutcome, deliverReceipt, denomOf, describeChallenge, discoveryHeaders, eip3009Abi, encodeXPaymentHeader, evaluatePolicy, explainDecline, facilitatorCoverage, fetchAcross, firstKeylessFacilitator, formatSpendReport, fromA2APaymentPayload, fromA2APaymentRequired, fromMcpPayment, fromMcpPaymentRequired, fromMcpPaymentResponse, getDirectoryInfo, isMcpPaymentRequired, isPermit2ProxyChain, isUptoProxyChain, knownFacilitatorsFor, normalizeNetwork, parseExactRequirements, parseFacilitatorSupported, paymentTools, planAcross, rankResources, readExactDomain, register402Index, registerDriver, registerX402Scan, renderLandingPage, requirePayment, resolveChain, scoreResource, searchOpenIndexes, settleViaFacilitator, summarizePlan, toA2AErrorCode, toA2APaymentFailed, toA2APaymentReceipts, toA2APaymentRequired, toInsufficientFundsError, toInvalidBody, toMcpPaymentRequired, toMcpPaymentResponse, verify402IndexDomain };