@piprail/sdk 1.13.0 → 1.14.0

package/dist/index.d.ts

@@ -84,10 +84,13 @@ interface X402ExactAcceptEntry {
     extra: {
         /** The exact-EVM transfer method. PipRail self-settles EIP-3009 today. */
         assetTransferMethod: 'eip3009';
-        /** EIP-712 domain name of the token (USDC: "USD Coin"; EURC: "EURC"). Read on-chain. */
-        name: string;
-        /** EIP-712 domain version of the token (USDC/EURC: "2"). Read on-chain. */
-        version: string;
+        /** EIP-712 domain name of the token. OPTIONAL per the exact-EVM scheme (only
+         *  `assetTransferMethod` is required) — a foreign rail may omit it. NEVER assumed
+         *  from the symbol (USDC's on-chain name() is "USD Coin", not "USDC"); a PipRail gate
+         *  READS it on-chain, and the PipRail buyer RE-DERIVES it on-chain and ignores this. */
+        name?: string;
+        /** EIP-712 domain version of the token (USDC: "2"). OPTIONAL (see `name`); read/re-derived on-chain. */
+        version?: string;
         /** Confirmations the gate waits for before granting access — mirrors the gate's
          *  `minConfirmations`, so the exact rail honours the same reorg safety as onchain-proof.
          *  A PipRail convenience (standard clients ignore unknown keys). */
@@ -221,13 +224,54 @@ declare const HEADER_RESPONSE_V1 = "x-payment-response";
 declare function buildChallengeHeader(challenge: X402Challenge): string;
 declare function buildReceiptHeader(receipt: X402Receipt): string;
 declare function buildSignatureHeader(signature: X402PaymentSignature): string;
+/**
+ * Build the v2 PAYMENT-SIGNATURE header value for a standard x402 `exact` payment:
+ * base64 of `{ x402Version: 2, accepted, payload }`. `accepted` is the chosen rail
+ * echoed back VERBATIM from the challenge's `accepts[]` (preserving any extra keys a
+ * facilitator needs); `payload` is the EIP-3009 `{ signature, authorization }` the
+ * buyer's EVM driver produced. Chain-agnostic (pure JSON/base64) — the driver owns
+ * the signing, this only frames it for the wire. Round-trips through
+ * {@link parseExactPaymentHeader}. (The `onchain-proof` counterpart is
+ * {@link buildSignatureHeader}; the v1 flat-shape utility is `encodeXPaymentHeader`.)
+ */
+declare function buildExactSignatureHeader(input: {
+    accepted: X402ExactAcceptEntry;
+    payload: ExactPaymentPayload;
+}): string;
 /**
  * Parse the PAYMENT-REQUIRED challenge from a 402 response. Prefers the
  * `payment-required` header, falls back to the JSON body.
  */
 declare function parseChallenge(response: Response): Promise<X402Challenge | null>;
-/** Parse the PAYMENT-RESPONSE receipt header on a 200 settlement. */
+/** Parse the PAYMENT-RESPONSE receipt header on a 200 settlement. Reads the v2
+ *  `payment-response` header, falling back to the v1 `x-payment-response` a foreign
+ *  server may set. Returns a fully-formed {@link X402Receipt} only (a bare foreign
+ *  exact SettleResponse without a `payer` is read by {@link parseSettleResponse}). */
 declare function parseReceipt(response: Response): X402Receipt | null;
+/**
+ * A standard x402 SettleResponse as the BUYER reads it off a settled (non-402)
+ * response. The `success` flag is authoritative: `false` is an EXPLICIT facilitator/
+ * server REJECTION (the buyer must NOT record a spend), `true` is an affirmative
+ * settlement. `transaction` is the on-chain settle tx the facilitator broadcast.
+ */
+interface SettleOutcome {
+    success: boolean;
+    transaction?: string;
+    network?: string;
+    payer?: string;
+    errorReason?: string;
+}
+/**
+ * Read a standard x402 SettleResponse for the BUYER, from the v2 `payment-response`
+ * header (or the v1 `x-payment-response` fallback). Returns `null` when neither
+ * header is present, unparseable, or carries no boolean `success` — i.e. when the
+ * server served the resource WITHOUT echoing a settle result, which the exact buyer
+ * treats as an affirmative 2xx settlement (receipt-less). When a body IS present with
+ * a boolean `success`, that flag is returned verbatim: ONLY an explicit
+ * `success: false` is a rejection. Used by the exact pay path to tell a real
+ * settlement from a phantom one (never record a spend on `success:false`).
+ */
+declare function parseSettleResponse(response: Response): SettleOutcome | null;
 /** Parse a PAYMENT-SIGNATURE header value (server side). */
 declare function parseSignatureHeader(value: string): X402PaymentSignature | null;
 /**
@@ -347,6 +391,11 @@ declare const CHAINS: {
                 decimals: number;
                 symbol: string;
             };
+            EURC: {
+                address: "0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c";
+                decimals: number;
+                symbol: string;
+            };
         };
     };
     base: {
@@ -561,7 +610,7 @@ declare const CHAINS: {
                         value: bigint;
                         yParity: number;
                         accessList: viem.AccessList;
-                        authorizationList?: undefined | undefined;
+                        authorizationList? /** EVM chain id, e.g. 5000 for Mantle. */: undefined | undefined;
                         blobVersionedHashes?: undefined | undefined;
                         chainId: number;
                         type: "eip1559";
@@ -570,7 +619,7 @@ declare const CHAINS: {
                         maxFeePerGas: bigint;
                         maxPriorityFeePerGas: bigint;
                         isSystemTx?: undefined | undefined;
-                        mint?: undefined | undefined;
+                        mint? /** Known tokens on this chain (empty for unknown custom chains). */: undefined | undefined;
                         sourceHash?: undefined | undefined;
                     } | {
                         blockHash: `0x${string}` | null;
@@ -682,6 +731,11 @@ declare const CHAINS: {
                 decimals: number;
                 symbol: string;
             };
+            EURC: {
+                address: "0x60a3E35Cc302bFA44Cb288Bc5a4F316Fdb1adb42";
+                decimals: number;
+                symbol: string;
+            };
         };
     };
     arbitrum: {
@@ -965,7 +1019,7 @@ declare const CHAINS: {
                         maxPriorityFeePerGas: bigint;
                         isSystemTx?: undefined | undefined;
                         mint?: undefined | undefined;
-                        sourceHash?: undefined | undefined;
+                        sourceHash? /** Known tokens on this chain (empty for unknown custom chains). */: undefined | undefined;
                     } | {
                         blockHash: `0x${string}` | null;
                         blockNumber: bigint | null;
@@ -1264,6 +1318,11 @@ declare const CHAINS: {
                 decimals: number;
                 symbol: string;
             };
+            EURC: {
+                address: "0xC891EB4cbdEFf6e073e859e987815Ed1505c2ACD";
+                decimals: number;
+                symbol: string;
+            };
         };
     };
     mantle: {
@@ -4118,9 +4177,11 @@ interface ResolvedNetwork {
      * never throws for a transient RPC issue — it falls back to a 'heuristic'
      * constant. `opts.from` (the payer's address) sharpens chains whose fee
      * depends on the sender (notably Tron energy); omit it for a typical estimate.
-     * Payer-side + informational — the gate never calls this.
+     * Payer-side + informational — the gate never calls this. Accepts either rail
+     * shape ({@link X402AnyAccept}): a standard `exact` rail estimates the BUYER's gas
+     * as ~0 (the server/facilitator broadcasts the signed authorization).
      */
-    estimateCost(accept: X402AcceptEntry, opts?: {
+    estimateCost(accept: X402AnyAccept, opts?: {
         from?: string;
     }): Promise<CostEstimate>;
     /**
@@ -4148,6 +4209,32 @@ interface ResolvedNetwork {
         ready: boolean | 'n/a' | 'unknown';
         reason?: RecipientReason;
     }>;
+    /**
+     * OPTIONAL (EVM + EIP-3009 only) — the BUYER counterpart to {@link settleExactSelf}.
+     * Build + EIP-712-sign an EIP-3009 `transferWithAuthorization` for a standard x402
+     * `exact` rail, so a PipRail agent can PAY any standard x402 server (not just PipRail's
+     * own `onchain-proof` gates). The client frames the returned `payload` + `accepted` echo
+     * into the `PAYMENT-SIGNATURE` header and re-requests; the server / merchant-chosen
+     * facilitator BROADCASTS the authorization (the buyer never broadcasts and spends ~0 gas).
+     *
+     * Re-derives the token's EIP-712 domain ON-CHAIN (never trusts the server-supplied
+     * `extra.{name,version}`), generates a CSPRNG 32-byte nonce + current unix time
+     * internally, and signs through the wallet client (bring-your-own JsonRpcAccount safe).
+     * THROWS a typed `PipRailError` (`UnsupportedSchemeError`) when the asset isn't EIP-3009
+     * (USDT/native/plain ERC-20) or the signer is a contract / EIP-1271 / EIP-7702 account.
+     *
+     * The third optional `exact` method (after {@link exactDomain}/{@link settleExactSelf});
+     * optional `?` is the gather gate — non-EVM families omit it, so an `exact` rail is never
+     * gathered/paid on those chains. Returns the signed payload, the chosen-rail echo (the
+     * server's RAW rail, verbatim, so a facilitator's extra keys survive), the payer address,
+     * and the nonce (for the client's spend record + a re-present-the-same-auth retry).
+     */
+    payExact?(wallet: WalletHandle, accept: X402ExactAcceptEntry): Promise<{
+        payload: ExactPaymentPayload;
+        accepted: X402ExactAcceptEntry;
+        payerFrom: string;
+        nonce: string;
+    }>;
     /**
      * OPTIONAL — a DISCOVERY signer for the bound wallet: its public address plus a
      * message signer, used only for ownership proofs + SIWX index registration,
@@ -4169,7 +4256,8 @@ interface ResolvedNetwork {
      * `null` when the asset is NOT an EIP-3009 token (no `transferWithAuthorization` —
      * e.g. USDT, native coin, or a plain ERC-20), so the gate can refuse to advertise a
      * standard `exact` rail for it. Never derived from the symbol (USDC's domain name is
-     * "USD Coin", not "USDC"; EURC's is "EURC"). Called once at exact-rail resolution
+     * "USD Coin", not "USDC"; EURC's is "Euro Coin" on Ethereum/Avalanche but "EURC" on Base —
+     * which is exactly why it must be READ, never assumed). Called once at exact-rail resolution
      * (cached by the gate). RPC-read; may throw on a transient read (the gate surfaces a
      * clear config error). The first of two optional server methods for the `exact` rail.
      */
@@ -4504,11 +4592,15 @@ interface SpendSummary {
     records: SpendRecord[];
 }
 
+/** The payment schemes a client can settle: PipRail's native `onchain-proof` (the
+ *  default) and the standard x402 `exact` rail (EVM + EIP-3009 only, opt-in). */
+type PaymentScheme = 'onchain-proof' | 'exact';
+
 /** Observability events. `ref` is the proof — a chain-specific id (EVM tx hash, Solana signature, TON locator, Stellar tx hash). */
 type PipRailEvent = {
     kind: 'payment-required';
     challenge: X402Challenge;
-    accept: X402AcceptEntry;
+    accept: X402AnyAccept;
 } | {
     kind: 'payment-broadcast';
     ref: string;
@@ -4528,9 +4620,18 @@ type PipRailEvent = {
     kind: 'payment-unconfirmed';
     ref: string;
     reason: string;
-} | {
+}
+/**
+ * The payment settled. `receipt` is PipRail's rich {@link X402Receipt} when the
+ * server returns one (its own gate, or a facilitator that echoes the full shape);
+ * `settle` is the standard x402 SettleResponse (`{ success, transaction, … }`) on
+ * conformant third-party-facilitator interop, where the lean SettleResponse has no
+ * rich receipt — read `settle.transaction` for the on-chain settle tx there.
+ */
+ | {
     kind: 'payment-settled';
     receipt: X402Receipt | null;
+    settle?: SettleOutcome;
 } | {
     kind: 'payment-failed';
     reason: string;
@@ -4627,8 +4728,9 @@ type PayBlocker = 'INSUFFICIENT_TOKEN' | 'INSUFFICIENT_GAS' | 'RECIPIENT_NOT_REA
 type PayWarning = 'SYMBOL_MISMATCH' | 'BALANCE_UNREADABLE' | 'RECIPIENT_READINESS_UNKNOWN' | 'GAS_HEURISTIC' | 'THIN_GAS_MARGIN';
 /** One offered rail, fully analysed against the bound wallet's own holdings. */
 interface PayOption {
-    /** The rail this analyses (one entry from the 402's accepts[]). */
-    accept: X402AcceptEntry;
+    /** The rail this analyses (one entry from the 402's accepts[]) — an
+     *  `onchain-proof` rail or, when `schemes` enables it, a standard `exact` rail. */
+    accept: X402AnyAccept;
     /** The priced requirement — TRUE decimals/symbol + the policy verdict. */
     quote: PipRailQuote;
     /** Estimated native-coin gas to send it (cost.basis surfaced). */
@@ -4725,6 +4827,24 @@ interface PipRailClientOptions {
      * per call with `fetch(url, { autoRoute: true })`.
      */
     autoRoute?: boolean;
+    /**
+     * Which payment SCHEMES this client may settle. Default **`['onchain-proof']`**
+     * (defaults never change): the zero-config client pays only PipRail's native
+     * backendless rail, exactly as before. Add `'exact'` to ALSO pay standard x402
+     * `exact` rails — letting the agent pay ANY standard x402 server (the dominant
+     * `exact`-on-Base-via-CDP web), not just PipRail's own gates:
+     *
+     *   new PipRailClient({ chain: 'base', wallet, schemes: ['onchain-proof', 'exact'] })
+     *
+     * `exact` is **EVM + EIP-3009 only** (USDC/EURC); it's silently ignored on a
+     * non-EVM chain, for USDT/native, or for a token the SDK can't price — those keep
+     * `onchain-proof`. The agent signs an EIP-3009 authorization with its OWN wallet
+     * and the server / merchant-chosen facilitator broadcasts it (the buyer pays ~0
+     * gas; PipRail hosts/settles nothing). The same `policy` + `onBeforePay` gate it
+     * BEFORE signing. **Verify against your target facilitator before production.**
+     * Override per call with `fetch(url, { schemes })`.
+     */
+    schemes?: PaymentScheme[];
     /** Logger hook. Default no-op. */
     onEvent?: (event: PipRailEvent) => void;
 }
@@ -4791,6 +4911,9 @@ declare class PipRailClient {
     private safeEmit;
     /** Auto-mount the chain's driver, resolve the network, and bind the wallet — once. */
     private ensure;
+    /** Resolve the effective scheme set: a per-call override, else the constructor's
+     *  `schemes`, else the `onchain-proof`-only default. */
+    private resolveSchemes;
     /** GET that auto-handles 402. Pass a full URL to any x402-gated endpoint. */
     get(url: string, init?: RequestInit): Promise<Response>;
     /**
@@ -4869,8 +4992,8 @@ declare class PipRailClient {
      * - A resource just listed via {@link register} may not appear yet — 402 Index reviews
      *   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
-     *   only `onchain-proof` rails directly (pay `exact` resources with the experimental
-     *   `drivers/evm/exact.ts`).
+     *   `onchain-proof` rails by default, and standard `exact` rails too once you opt in
+     *   with `schemes: ['onchain-proof', 'exact']` (EVM + EIP-3009 — USDC/EURC).
      */
     discover(opts?: DiscoverOptions): Promise<DiscoveredResource[]>;
     /**
@@ -4937,17 +5060,21 @@ declare class PipRailClient {
      * twice (once to fetch the 402, once with the proof attached). One-shot
      * streams throw `NonReplayableBodyError`.
      */
-    fetch(url: string, init?: RequestInit): Promise<Response>;
+    fetch(url: string, init?: RequestInit & {
+        autoRoute?: boolean;
+        schemes?: PaymentScheme[];
+    }): Promise<Response>;
     /**
      * From a confirmed-402 response: parse the challenge, mount + bind the
      * network, pick the accept the client can pay, and build its quote. Shared by
      * `quote()` (read-only) and `fetch()` (which then authorises + pays).
      */
     private resolveChallenge;
-    /** The candidate accepts this client could pay: our scheme, on the bound network.
-     *  A dual-advertised challenge may also carry standard `exact` rails — the PipRail
-     *  client ignores those (it pays the backendless `onchain-proof` rail); the type
-     *  predicate narrows the `X402AnyAccept` union to the rails we settle. */
+    /** The candidate accepts this client could pay, on the bound network. Always the
+     *  backendless `onchain-proof` rails; PLUS standard `exact` rails when `schemes`
+     *  enables them AND the driver can settle them (EVM `payExact` + a recognised
+     *  EIP-3009 token). `onchain-proof` is gathered FIRST so default selection is
+     *  unchanged when `exact` is off. */
     private gatherCandidates;
     /** Build the full {@link PaymentPlan} from an already-parsed challenge + bound
      *  net/wallet. Shared by `planPayment` (read-only) and `fetch`'s autoRoute. */
@@ -4965,6 +5092,24 @@ declare class PipRailClient {
     private recordSpend;
     private payAndConfirm;
     private retryWithProof;
+    /**
+     * Pay a standard x402 `exact` rail — a SEPARATE, fundamentally more conservative
+     * path than {@link retryWithProof}. The buyer SIGNS an EIP-3009 authorization ONCE
+     * (the driver's `payExact`) and the server / merchant-chosen facilitator BROADCASTS
+     * it synchronously, so a blind re-POST of a still-in-flight authorization could
+     * double-BROADCAST it. Hence, unlike the onchain-proof loop:
+     *
+     *   • sign exactly once — reuse the SAME header on every retry, never re-sign;
+     *   • retry ONLY an explicit 402 (a definitive pre-broadcast rejection), bounded
+     *     well under `maxTimeoutSeconds` so the loop can't outlive the authorization;
+     *   • a post-POST transport error/timeout → {@link PaymentTimeoutError} carrying the
+     *     nonce (the facilitator MAY have settled — verify on-chain, NEVER re-pay);
+     *   • a 5xx → return as-is (server settle failure; the authorization stays valid +
+     *     its nonce unused) — no settled event, no spend;
+     *   • a 200 whose SettleResponse says `success:false` → a rejection, NEVER a spend;
+     *   • the spend is recorded EXACTLY ONCE, on an affirmative settlement only.
+     */
+    private payExactRail;
 }
 /**
  * Plan a payment ACROSS several single-chain clients — the cross-chain brain.
@@ -5614,7 +5759,14 @@ declare class PaymentTimeoutError extends PipRailError {
  */
 declare class MaxRetriesExceededError extends PipRailError {
     readonly code = "MAX_RETRIES_EXCEEDED";
-    /** The already-broadcast proof ref — recover with it, don't re-pay. */
+    /**
+     * 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.
+     */
     readonly ref?: string;
     constructor(message: string, options?: ErrorOptions & {
         ref?: string;
@@ -5667,6 +5819,22 @@ declare class InvalidEnvelopeError extends PipRailError {
 declare class NoCompatibleAcceptError extends PipRailError {
     readonly code = "NO_COMPATIBLE_ACCEPT";
 }
+/**
+ * The client was asked to pay a SCHEME the bound chain family/asset/signer can't
+ * settle, and no fallback rail was offered. Specifically: a standard `exact` rail
+ * on a non-EVM family (only EVM ships the buyer `payExact`); an `exact` rail for a
+ * token that isn't EIP-3009 (USDT needs Permit2, native isn't exact-payable, a
+ * plain ERC-20 has no `transferWithAuthorization`); or an `exact` rail whose signer
+ * is a contract / EIP-1271 / EIP-7702-delegated account (no recoverable ECDSA sig).
+ *
+ * Distinct from {@link NoCompatibleAcceptError} (no rail for the network at all)
+ * and {@link WrongFamilyError} (the wallet/payTo/token was given in another
+ * family's shape). The fix is usually "enable/keep an `onchain-proof` rail" or
+ * "pay with a supported chain/token". Thrown by the client / the EVM driver.
+ */
+declare class UnsupportedSchemeError extends PipRailError {
+    readonly code = "UNSUPPORTED_SCHEME";
+}
 /** init.body was provided but isn't replayable (e.g. a one-shot ReadableStream). */
 declare class NonReplayableBodyError extends PipRailError {
     readonly code = "NON_REPLAYABLE_BODY";
@@ -5717,10 +5885,12 @@ declare class UnsupportedNetworkError extends PipRailError {
  * x402 `exact` interop, in BOTH directions, EVM + EIP-3009 only, on the existing
  * `viem` peer (no new dep):
  *
- *   • BUYER side (client) — parse an `exact` requirement, build + EIP-712-sign the
- *     EIP-3009 authorization, encode the `X-PAYMENT` header. Deterministic,
- *     unit-testable; NOT wired into `PipRailClient.fetch`'s default (see
- *     `.claude/plans/agent-readiness/04-universal-exact.md`).
+ *   • BUYER side (client) — {@link payExactEvm} re-derives the token's EIP-712 domain
+ *     ON-CHAIN, signs the EIP-3009 authorization, and is wired into `PipRailClient`'s
+ *     pay path via the EVM driver's `payExact` SPI (OPT-IN through `schemes: ['exact']`;
+ *     the default is unchanged). The lower-level `buildExactAuthorization` /
+ *     `encodeXPaymentHeader` codecs remain for hand-rolled/v1 clients. See
+ *     `.claude/plans/exact-client/IMPLEMENTATION.md`.
  *
  *   • SELLER side (gate) — {@link readExactDomain} (read the token's true EIP-712
  *     domain so the gate can advertise + verify it) and {@link verifyAndSettleExactEvm}
@@ -5812,6 +5982,13 @@ interface BuildExactParams {
  * Build + EIP-712-sign an EIP-3009 `transferWithAuthorization` for an `exact`
  * requirement. Returns the authorization and its signature; pass both to
  * {@link encodeXPaymentHeader} to produce the `X-PAYMENT` header value.
+ *
+ * @deprecated Low-level primitive — prefer {@link payExactEvm}, which the client's
+ * `payExact` SPI uses. This helper TRUSTS the server-supplied `accept.extra.{name,
+ * version}` for the EIP-712 domain (a lying/absent value yields a silently-invalid
+ * signature) and calls `account.signTypedData` directly (which is `undefined` on a
+ * bring-your-own JsonRpcAccount). `payExactEvm` re-derives the domain on-chain and
+ * signs via the wallet client. Kept exported as a deterministic test/codec building block.
  */
 declare function buildExactAuthorization(params: BuildExactParams): Promise<{
     authorization: ExactAuthorization;
@@ -5938,13 +6115,14 @@ declare const eip3009Abi: readonly [{
  * plain ERC-20), so the gate refuses to advertise a standard `exact` rail for it.
  *
  * The name is NEVER assumed from the symbol: canonical USDC's domain name is
- * "USD Coin" (not "USDC"), EURC's is "EURC". `eip712Domain()` (EIP-5267) reverts
- * on these proxies, so we read `name()`+`version()` and probe `authorizationState`
- * to confirm EIP-3009 support.
+ * "USD Coin" (not "USDC"), and EURC's is "Euro Coin" on Ethereum/Avalanche but "EURC"
+ * on Base — proof that only the on-chain read is authoritative. `eip712Domain()`
+ * (EIP-5267) reverts on these proxies, so we read `name()`+`version()` and probe
+ * `authorizationState` to confirm EIP-3009 support.
  */
 declare function readExactDomain(publicClient: PublicClient, asset: string): Promise<{
     name: string;
     version: string;
 } | null>;
 
-export { type AcceptOption, type AddressId, type AgentTool, type AlgorandToken, type AptosToken, type AssetId, type BazaarExtension, type BuildExactParams, CHAINS, type Caip2, type ChainFamily, type ChainInput, type ChainName, type ChainPreset, type ChainSelector, type ConfirmInfo, ConfirmationTimeoutError, type CostEstimate, DIRECTORY_INFO, type DirectoryInfo, type DiscoverOptions, type DiscoveredRail, type DiscoveredResource, type DiscoveryDescriptor, type DiscoverySigner, type DiscoverySource, type DomainClaim, type DomainVerification, EIP3009_TYPES, EXACT_NETWORK_SLUGS, type EvmToken, type ExactAccept, type ExactAuthorization, type ExactAuthorizationWire, type ExactPaymentPayload, type ExactRailOption, type ExpressLikeMiddleware, type ExpressLikeNext, type ExpressLikeRequest, type ExpressLikeResponse, type FacilitatorConfig, type FacilitatorPaymentRequirements, GENERATOR, HEADER_REQUIRED, HEADER_RESPONSE, HEADER_RESPONSE_V1, HEADER_SIGNATURE, HEADER_SIGNATURE_V1, InsufficientFundsError, InvalidEnvelopeError, type ListingVisibility, type ManifestInput, MaxRetriesExceededError, MissingDriverError, type NearToken, NoCompatibleAcceptError, NonReplayableBodyError, type OpenApiDocument, type OpenApiOperation, type ParsedExactPayment, type PayBlocker, type PayOption, type PayWarning, PaymentDeclinedError, type PaymentDriver, type PaymentGate, type PaymentIntent, type PaymentPlan, type PaymentPolicy, type PaymentRail, PaymentTimeoutError, PipRailClient, type PipRailClientOptions, type PipRailCostQuote, PipRailError, type PipRailEvent, type PipRailQuote, type PolicyDecision, RecipientNotReadyError, type RecipientReason, type RegisterInput, type RegisterOptions, type RegisterOutcome, type RequirePaymentOptions, type ResolveOptions, type ResolvedChain, type ResolvedNetwork, type ResolvedToken, type ResourceDescription, type SearchOpenIndexesOptions, type SettleViaFacilitatorInput, SettlementError, type SolanaToken, type SpendAssetTotal, type SpendRecord, type SpendSummary, type StellarToken, type SuiToken, type TokenInfo, type TokenInput, type TonToken, type ToolAnnotations, type TronToken, UnknownTokenError, UnsupportedNetworkError, type VerifyErrorCode, type VerifyPaymentResult, type VerifyResult, type WalletBalance, type WalletHandle, type WalletInput, type WellKnownX402, WrongChainError, WrongFamilyError, type X402AcceptEntry, type X402AnyAccept, type X402Challenge, type X402DnsRecord, type X402ExactAcceptEntry, type X402InvalidBody, type X402PaymentSignature, type X402Receipt, type X402ResourceObject, type XrplToken, buildBazaarExtension, buildChallengeHeader, buildExactAuthorization, buildOpenApi, buildReceiptHeader, buildSignatureHeader, buildWellKnownX402, buildX402DnsTxt, chainIdForExactNetwork, claim402IndexDomain, createPaymentGate, decorateOutcome, eip3009Abi, encodeXPaymentHeader, evaluatePolicy, getDirectoryInfo, normalizeNetwork, parseChallenge, parseExactPaymentHeader, parseExactRequirements, parseReceipt, parseSignatureHeader, paymentTools, pickAccept, planAcross, readExactDomain, register402Index, registerDriver, registerX402Scan, requirePayment, resolveChain, searchOpenIndexes, settleViaFacilitator, toInsufficientFundsError, toInvalidBody, verify402IndexDomain };
+export { type AcceptOption, type AddressId, type AgentTool, type AlgorandToken, type AptosToken, type AssetId, type BazaarExtension, type BuildExactParams, CHAINS, type Caip2, type ChainFamily, type ChainInput, type ChainName, type ChainPreset, type ChainSelector, type ConfirmInfo, ConfirmationTimeoutError, type CostEstimate, DIRECTORY_INFO, type DirectoryInfo, type DiscoverOptions, type DiscoveredRail, type DiscoveredResource, type DiscoveryDescriptor, type DiscoverySigner, type DiscoverySource, type DomainClaim, type DomainVerification, EIP3009_TYPES, EXACT_NETWORK_SLUGS, type EvmToken, type ExactAccept, type ExactAuthorization, type ExactAuthorizationWire, type ExactPaymentPayload, type ExactRailOption, type ExpressLikeMiddleware, type ExpressLikeNext, type ExpressLikeRequest, type ExpressLikeResponse, type FacilitatorConfig, type FacilitatorPaymentRequirements, GENERATOR, HEADER_REQUIRED, HEADER_RESPONSE, HEADER_RESPONSE_V1, HEADER_SIGNATURE, HEADER_SIGNATURE_V1, InsufficientFundsError, InvalidEnvelopeError, type ListingVisibility, type ManifestInput, MaxRetriesExceededError, MissingDriverError, type NearToken, NoCompatibleAcceptError, NonReplayableBodyError, type OpenApiDocument, type OpenApiOperation, type ParsedExactPayment, type PayBlocker, type PayOption, type PayWarning, PaymentDeclinedError, type PaymentDriver, type PaymentGate, type PaymentIntent, type PaymentPlan, type PaymentPolicy, type PaymentRail, type PaymentScheme, PaymentTimeoutError, PipRailClient, type PipRailClientOptions, type PipRailCostQuote, PipRailError, type PipRailEvent, type PipRailQuote, type PolicyDecision, RecipientNotReadyError, type RecipientReason, type RegisterInput, type RegisterOptions, type RegisterOutcome, type RequirePaymentOptions, type ResolveOptions, type ResolvedChain, type ResolvedNetwork, type ResolvedToken, type ResourceDescription, type SearchOpenIndexesOptions, type SettleOutcome, type SettleViaFacilitatorInput, SettlementError, type SolanaToken, type SpendAssetTotal, type SpendRecord, type SpendSummary, type StellarToken, type SuiToken, type TokenInfo, type TokenInput, type TonToken, type ToolAnnotations, type TronToken, UnknownTokenError, UnsupportedNetworkError, UnsupportedSchemeError, type VerifyErrorCode, type VerifyPaymentResult, type VerifyResult, type WalletBalance, type WalletHandle, type WalletInput, type WellKnownX402, WrongChainError, WrongFamilyError, type X402AcceptEntry, type X402AnyAccept, type X402Challenge, type X402DnsRecord, type X402ExactAcceptEntry, type X402InvalidBody, type X402PaymentSignature, type X402Receipt, type X402ResourceObject, type XrplToken, buildBazaarExtension, buildChallengeHeader, buildExactAuthorization, buildExactSignatureHeader, buildOpenApi, buildReceiptHeader, buildSignatureHeader, buildWellKnownX402, buildX402DnsTxt, chainIdForExactNetwork, claim402IndexDomain, createPaymentGate, decorateOutcome, eip3009Abi, encodeXPaymentHeader, evaluatePolicy, getDirectoryInfo, normalizeNetwork, parseChallenge, parseExactPaymentHeader, parseExactRequirements, parseReceipt, parseSettleResponse, parseSignatureHeader, paymentTools, pickAccept, planAcross, readExactDomain, register402Index, registerDriver, registerX402Scan, requirePayment, resolveChain, searchOpenIndexes, settleViaFacilitator, toInsufficientFundsError, toInvalidBody, verify402IndexDomain };