@piprail/sdk 2.2.0 → 2.4.0

package/dist/index.d.cts

@@ -88,8 +88,14 @@ interface X402ExactAcceptEntry {
          *  `spender` is the canonical x402ExactPermit2Proxy and whose `witness.to` binds the
          *  recipient. **Solana (SVM): `'svm'`** — the payer partial-signs an SPL
          *  `TransferChecked` transaction whose fee payer is the merchant (`feePayer` below),
-         *  and the gate co-signs as fee payer + broadcasts. PipRail self-settles ALL. */
-        assetTransferMethod: 'eip3009' | 'permit2' | 'svm';
+         *  and the gate co-signs as fee payer + broadcasts. **Algorand: `'algorand'`** — the payer
+         *  signs an ASA `axfer` to `payTo` at fee 0, atomically grouped with a 0-ALGO `pay` from
+         *  the `feePayer` that pools the group fee (per `scheme_exact_algo.md`); the gate (or a
+         *  keyless facilitator) signs that fee txn + submits. **Aptos: `'aptos'`** — the payer signs a
+         *  fee-payer (sponsored) `primary_fungible_store::transfer` to `payTo` (per
+         *  `scheme_exact_aptos.md`); the gate (or a keyless facilitator) adds the fee-payer signature
+         *  + submits, paying gas. PipRail self-settles ALL. */
+        assetTransferMethod: 'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos';
         /** 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
@@ -97,11 +103,12 @@ interface X402ExactAcceptEntry {
         name?: string;
         /** EIP-712 domain version of the token (USDC: "2"). OPTIONAL (see `name`); read/re-derived on-chain. */
         version?: string;
-        /** **SVM only** — the merchant's fee-payer (sponsor) public key (base58), per the
-         *  x402 `exact` SVM scheme. The buyer compiles the transaction with this account as
-         *  the fee payer (so the buyer spends zero SOL on the network fee), leaving its
-         *  signature slot empty; the gate fills it and broadcasts. Distinct from `payTo` —
-         *  the fee payer must never appear in any instruction's accounts (a MUST-rule). */
+        /** **SVM / Algorand / Aptos** — the fee-payer (gas sponsor) address. The buyer builds the
+         *  transaction with this account as the gas payer (so the buyer spends ZERO native coin),
+         *  leaving its signature for whoever sponsors; the gate (self mode) or a keyless facilitator
+         *  fills it and submits. On **SVM** it must differ from `payTo` (the fee payer must never
+         *  appear in an instruction — a MUST-rule); on **Algorand/Aptos** the fee txn/signature is
+         *  separate from the transfer, so `feePayer === payTo` is allowed. */
         feePayer?: string;
         /** **SVM only, OPTIONAL** — a ≤256-byte reconciliation memo the buyer attaches to the
          *  transaction (the SVM scheme's optional `extra.memo`). */
@@ -216,9 +223,41 @@ interface Permit2PaymentPayload {
 interface ExactSvmPaymentPayload {
     transaction: string;
 }
+/**
+ * The `payload` a client sends for the **Algorand `exact`** variant, per
+ * `scheme_exact_algo.md`: an atomically-grouped set of base64-encoded msgpack transactions,
+ * and the index within it of the transaction that pays the resource server. The buyer's ASA
+ * `axfer` (to `payTo`, fee 0) is SIGNED; a 0-ALGO `pay` from the `feePayer` that pools the
+ * group fee is left UNSIGNED for whoever sponsors (the gate's relayer in self mode, or a
+ * keyless facilitator). The group itself IS the proof — there's no separate authorization
+ * object (the Algorand analogue of EIP-3009's `authorization` / SVM's `transaction`).
+ */
+interface ExactAlgorandPaymentPayload {
+    /** Index into `paymentGroup` of the txn that pays the resource server (the buyer's `axfer`). */
+    paymentIndex: number;
+    /** The atomic group: each element is a base64-encoded, msgpack-encoded (signed or unsigned)
+     *  Algorand transaction. ≤ 16 elements (the protocol's atomic-group cap). */
+    paymentGroup: string[];
+}
+/**
+ * The `payload` a client sends for the **Aptos `exact`** variant, per `scheme_exact_aptos.md`:
+ * a fee-payer (sponsored, AIP-39) `primary_fungible_store::transfer`. `transaction` is the base64
+ * BCS-serialized `SimpleTransaction` (raw tx + the bound `feePayerAddress`); `senderAuth` is the
+ * base64 BCS-serialized buyer (sender) authenticator. The buyer leaves the fee-payer signature for
+ * whoever sponsors (the gate's relayer in self mode, or a keyless facilitator), who adds it +
+ * submits. The (tx + sender authenticator) IS the proof — there's no separate `authorization`
+ * object (the Aptos analogue of EIP-3009's `authorization` / SVM's `transaction`). The two-field
+ * shape (a `senderAuth` alongside `transaction`) also distinguishes it from the SVM payload.
+ */
+interface ExactAptosPaymentPayload {
+    /** Base64 BCS-serialized `SimpleTransaction` (raw transaction + the bound `feePayerAddress`). */
+    transaction: string;
+    /** Base64 BCS-serialized buyer (sender) `AccountAuthenticator`. */
+    senderAuth: string;
+}
 /** Any `exact`-rail payload shape — EIP-3009 (`authorization`), Permit2 (`permit2Authorization`),
- *  or SVM (`transaction`). */
-type ExactPaymentPayloadAny = ExactPaymentPayload | Permit2PaymentPayload | ExactSvmPaymentPayload;
+ *  SVM (`transaction`), Algorand (`paymentGroup`), or Aptos (`transaction` + `senderAuth`). */
+type ExactPaymentPayloadAny = ExactPaymentPayload | Permit2PaymentPayload | ExactSvmPaymentPayload | ExactAlgorandPaymentPayload | ExactAptosPaymentPayload;
 interface ParsedExactBase {
     x402Version: number;
     /** The client's claimed network (slug or CAIP-2) — for matching, not trust. */
@@ -236,7 +275,9 @@ interface ParsedExactBase {
  * re-derives every verified field from its own trusted rail. A discriminated union on
  * `method`, so narrowing on `method` narrows `payload`: `'eip3009'` → {@link ExactPaymentPayload}
  * (`authorization`), `'permit2'` → {@link Permit2PaymentPayload} (`permit2Authorization`),
- * `'svm'` → {@link ExactSvmPaymentPayload} (`transaction`).
+ * `'svm'` → {@link ExactSvmPaymentPayload} (`transaction`), `'algorand'` →
+ * {@link ExactAlgorandPaymentPayload} (`paymentGroup`); `'aptos'` →
+ * {@link ExactAptosPaymentPayload} (`transaction` + `senderAuth`).
  */
 type ParsedExactPayment = (ParsedExactBase & {
     method: 'eip3009';
@@ -247,6 +288,12 @@ type ParsedExactPayment = (ParsedExactBase & {
 }) | (ParsedExactBase & {
     method: 'svm';
     payload: ExactSvmPaymentPayload;
+}) | (ParsedExactBase & {
+    method: 'algorand';
+    payload: ExactAlgorandPaymentPayload;
+}) | (ParsedExactBase & {
+    method: 'aptos';
+    payload: ExactAptosPaymentPayload;
 });
 interface X402Receipt {
     scheme: 'onchain-proof' | 'exact';
@@ -4266,9 +4313,10 @@ interface DiscoverySigner {
  * chain-agnostic — it never names a family, it just merges `extra`.
  */
 interface ExactRailInfo {
-    method: 'eip3009' | 'permit2' | 'svm';
+    method: 'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos';
     /** Family-specific `extra` keys merged into the exact accept (e.g. `{ name, version }`
-     *  for EVM EIP-3009, `{ feePayer, tokenProgram }` for Solana). */
+     *  for EVM EIP-3009, `{ feePayer, tokenProgram }` for Solana, `{ feePayer }` for
+     *  Algorand/Aptos). */
     extra?: Record<string, unknown>;
 }
 /**
@@ -4349,7 +4397,7 @@ interface ResolvedNetwork {
         reason?: RecipientReason;
     }>;
     /**
-     * OPTIONAL (EVM EIP-3009/Permit2 + Solana SVM) — the BUYER counterpart to {@link settleExactSelf}.
+     * OPTIONAL (EVM EIP-3009/Permit2 + Solana SVM + Algorand + Aptos) — 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
@@ -4404,7 +4452,7 @@ interface ResolvedNetwork {
      * (the merchant's own bound self-settle wallet, in self mode); `feePayer` takes precedence.
      * RPC-read (EVM reads the token's EIP-712 domain; Solana reads the mint's token program); MAY
      * throw a typed config error for an explicitly-requested-but-unsupported method (EVM does). A
-     * family that omits this method offers no `exact` rail (today: every non-EVM, non-Solana family).
+     * family that omits this method offers no `exact` rail (today: every family except EVM, Solana, Algorand, and Aptos).
      */
     resolveExactRail?(input: {
         asset: string;
@@ -4438,10 +4486,12 @@ interface ResolvedNetwork {
      */
     exactPermit2Supported?(): boolean;
     /**
-     * OPTIONAL (EVM-only today) — verify a standard x402 `exact` (EIP-3009) payment
-     * locally, then SELF-SETTLE it by broadcasting `transferWithAuthorization` from the
-     * merchant's own `relayer` wallet (the merchant pays gas to receive; the signature
-     * binds `to`, so no redirect risk). RETURNS a `VerifyResult`:
+     * OPTIONAL (EVM EIP-3009/Permit2 + Solana SVM + Algorand + Aptos) — verify a standard x402 `exact`
+     * payment locally, then SELF-SETTLE it by broadcasting from the merchant's own `relayer`
+     * wallet (the merchant pays the network fee to receive; EVM broadcasts
+     * `transferWithAuthorization`, Solana co-signs the fee payer, Algorand signs the pooled fee
+     * txn + submits the group, Aptos adds the fee-payer signature + submits — the transfer
+     * binds `payTo`, so no redirect risk). RETURNS a `VerifyResult`:
      *   - `{ ok:false, error }` for a CLIENT-fixable fault (bad signature, expired,
      *     wrong recipient/amount, used nonce, simulation revert) → gate replies 402;
      *   - `{ ok:true, receipt }` once the settle tx is mined.
@@ -4930,7 +4980,7 @@ interface SpendSummary {
 }
 
 /** The payment schemes a client can settle: PipRail's native `onchain-proof` (the
- *  default) and the standard x402 `exact` rail (EVM EIP-3009/Permit2 + Solana SVM, opt-in). */
+ *  default) and the standard x402 `exact` rail (EVM EIP-3009/Permit2 + Solana SVM + Algorand, 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). */
@@ -5485,7 +5535,7 @@ 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).
+     *   with `schemes: ['onchain-proof', 'exact']` (EVM EIP-3009/Permit2 + Solana SVM + Algorand).
      */
     discover(opts?: DiscoverOptions): Promise<DiscoveredResource[]>;
     /**
@@ -5902,7 +5952,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 two 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, and the on-chain method (EIP-3009 / Permit2 / SVM) is picked automatically.\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 scheme is OPT-IN by the operator (MCP: PIPRAIL_SCHEMES=onchain-proof,exact);\nyou can't enable it yourself, but you can report when a 402 needs it (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\n(network, asset), plus your spend so far. Read-only; moves no funds. Use it in\nMode 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- Spend caps are PER (network, asset). There is no single cross-token dollar cap \u2014\n  budgets aren't summed across tokens (no price oracle).\n- Spend totals and the time envelope live IN-MEMORY for THIS process; they reset on restart\n  (a convenience, not a durable ledger).\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 two 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.\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 scheme is OPT-IN by the operator (MCP: PIPRAIL_SCHEMES=onchain-proof,exact);\nyou can't enable it yourself, but you can report when a 402 needs it (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\n(network, asset), plus your spend so far. Read-only; moves no funds. Use it in\nMode 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- Spend caps are PER (network, asset). There is no single cross-token dollar cap \u2014\n  budgets aren't summed across tokens (no price oracle).\n- Spend totals and the time envelope live IN-MEMORY for THIS process; they reset on restart\n  (a convenience, not a durable ledger).\n";
 /** Returns {@link PIPRAIL_AGENT_GUIDE} (a parity accessor for callers that prefer a function). */
 declare function agentGuide(): string;
 
@@ -6370,7 +6420,11 @@ interface AcceptOption {
  *     relayer key needed. (EVM facilitators are also the path onto Coinbase's Bazaar directory.)
  */
 interface ExactRailOption {
-    settle: 'self' | {
+    /** How the gate settles an inbound `exact` payment. `'self'` = your own `relayer` broadcasts
+     *  (you pay gas). `'keyless'` = auto-pick a known KEYLESS facilitator for the chain (it sponsors
+     *  gas — zero-config; the same resolution as the top-level `exact: true` shorthand). `{ facilitator }`
+     *  = a specific facilitator you name — pin this in production rather than relying on the auto-pick. */
+    settle: 'self' | 'keyless' | {
         facilitator: string;
         authHeaders?: () => Promise<Record<string, string>>;
         /** Solana only — the facilitator's fee-payer pubkey, if you'd rather set it than have the
@@ -6462,9 +6516,17 @@ interface RequirePaymentOptions {
     /**
      * ALSO advertise a standard x402 `exact` rail so any standard x402 client can pay this
      * gate — opt-in, EVM (EIP-3009/Permit2) + Solana (SVM). See {@link ExactRailOption}.
-     * Omit to keep the gate exactly as today (`onchain-proof` only).
+     * Shorthand **`exact: true`** === `{ settle: 'keyless' }`: the gate auto-picks a known KEYLESS
+     * facilitator for each offered chain (from `KNOWN_FACILITATORS`), so neither buyer nor merchant
+     * pays gas, zero-config. It is a SOFT, best-effort flag — a chain with no available keyless
+     * facilitator DEGRADES GRACEFULLY to the always-present `onchain-proof` rail (the buyer pays gas,
+     * the only option left when no facilitator can sponsor) with a LOUD warning; it never bricks the
+     * gate. For guaranteed gasless, pin `settle: { facilitator }` (recommended in production) or
+     * self-settle `settle: 'self'`; an EXPLICIT `settle` that can't carry exact throws loudly (a config
+     * error you should fix). `false`/omitted keeps the gate exactly as today (`onchain-proof` only —
+     * byte-identical).
      */
-    exact?: ExactRailOption;
+    exact?: boolean | ExactRailOption;
     /**
      * Make this gate's 402 self-describing for the open indexes — **x402scan REQUIRES
      * an input schema or it won't list the resource.** Set `true` for a no-input GET,
@@ -6697,7 +6759,7 @@ interface KnownFacilitator {
     /** The x402 schemes it settles (today only `exact`). */
     schemes: ReadonlyArray<'exact'>;
     /** The exact transfer methods it can settle on this network. */
-    settles: ReadonlyArray<'eip3009' | 'permit2' | 'svm'>;
+    settles: ReadonlyArray<'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos'>;
     /** A short human note (who it is / caveat). */
     note?: string;
 }
@@ -6718,7 +6780,7 @@ declare function knownFacilitatorsFor(network: Caip2): ReadonlyArray<KnownFacili
  * specific transfer `method`). Returns `undefined` when none is known — the `exact: true`
  * shorthand branches on that to throw a coverage-specific guidance error.
  */
-declare function firstKeylessFacilitator(network: Caip2, method?: 'eip3009' | 'permit2' | 'svm'): KnownFacilitator | undefined;
+declare function firstKeylessFacilitator(network: Caip2, method?: 'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos'): KnownFacilitator | undefined;
 
 /**
  * Reliable receipt delivery — the durable webhook a stateless gate can't be.

package/dist/index.d.ts

@@ -88,8 +88,14 @@ interface X402ExactAcceptEntry {
          *  `spender` is the canonical x402ExactPermit2Proxy and whose `witness.to` binds the
          *  recipient. **Solana (SVM): `'svm'`** — the payer partial-signs an SPL
          *  `TransferChecked` transaction whose fee payer is the merchant (`feePayer` below),
-         *  and the gate co-signs as fee payer + broadcasts. PipRail self-settles ALL. */
-        assetTransferMethod: 'eip3009' | 'permit2' | 'svm';
+         *  and the gate co-signs as fee payer + broadcasts. **Algorand: `'algorand'`** — the payer
+         *  signs an ASA `axfer` to `payTo` at fee 0, atomically grouped with a 0-ALGO `pay` from
+         *  the `feePayer` that pools the group fee (per `scheme_exact_algo.md`); the gate (or a
+         *  keyless facilitator) signs that fee txn + submits. **Aptos: `'aptos'`** — the payer signs a
+         *  fee-payer (sponsored) `primary_fungible_store::transfer` to `payTo` (per
+         *  `scheme_exact_aptos.md`); the gate (or a keyless facilitator) adds the fee-payer signature
+         *  + submits, paying gas. PipRail self-settles ALL. */
+        assetTransferMethod: 'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos';
         /** 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
@@ -97,11 +103,12 @@ interface X402ExactAcceptEntry {
         name?: string;
         /** EIP-712 domain version of the token (USDC: "2"). OPTIONAL (see `name`); read/re-derived on-chain. */
         version?: string;
-        /** **SVM only** — the merchant's fee-payer (sponsor) public key (base58), per the
-         *  x402 `exact` SVM scheme. The buyer compiles the transaction with this account as
-         *  the fee payer (so the buyer spends zero SOL on the network fee), leaving its
-         *  signature slot empty; the gate fills it and broadcasts. Distinct from `payTo` —
-         *  the fee payer must never appear in any instruction's accounts (a MUST-rule). */
+        /** **SVM / Algorand / Aptos** — the fee-payer (gas sponsor) address. The buyer builds the
+         *  transaction with this account as the gas payer (so the buyer spends ZERO native coin),
+         *  leaving its signature for whoever sponsors; the gate (self mode) or a keyless facilitator
+         *  fills it and submits. On **SVM** it must differ from `payTo` (the fee payer must never
+         *  appear in an instruction — a MUST-rule); on **Algorand/Aptos** the fee txn/signature is
+         *  separate from the transfer, so `feePayer === payTo` is allowed. */
         feePayer?: string;
         /** **SVM only, OPTIONAL** — a ≤256-byte reconciliation memo the buyer attaches to the
          *  transaction (the SVM scheme's optional `extra.memo`). */
@@ -216,9 +223,41 @@ interface Permit2PaymentPayload {
 interface ExactSvmPaymentPayload {
     transaction: string;
 }
+/**
+ * The `payload` a client sends for the **Algorand `exact`** variant, per
+ * `scheme_exact_algo.md`: an atomically-grouped set of base64-encoded msgpack transactions,
+ * and the index within it of the transaction that pays the resource server. The buyer's ASA
+ * `axfer` (to `payTo`, fee 0) is SIGNED; a 0-ALGO `pay` from the `feePayer` that pools the
+ * group fee is left UNSIGNED for whoever sponsors (the gate's relayer in self mode, or a
+ * keyless facilitator). The group itself IS the proof — there's no separate authorization
+ * object (the Algorand analogue of EIP-3009's `authorization` / SVM's `transaction`).
+ */
+interface ExactAlgorandPaymentPayload {
+    /** Index into `paymentGroup` of the txn that pays the resource server (the buyer's `axfer`). */
+    paymentIndex: number;
+    /** The atomic group: each element is a base64-encoded, msgpack-encoded (signed or unsigned)
+     *  Algorand transaction. ≤ 16 elements (the protocol's atomic-group cap). */
+    paymentGroup: string[];
+}
+/**
+ * The `payload` a client sends for the **Aptos `exact`** variant, per `scheme_exact_aptos.md`:
+ * a fee-payer (sponsored, AIP-39) `primary_fungible_store::transfer`. `transaction` is the base64
+ * BCS-serialized `SimpleTransaction` (raw tx + the bound `feePayerAddress`); `senderAuth` is the
+ * base64 BCS-serialized buyer (sender) authenticator. The buyer leaves the fee-payer signature for
+ * whoever sponsors (the gate's relayer in self mode, or a keyless facilitator), who adds it +
+ * submits. The (tx + sender authenticator) IS the proof — there's no separate `authorization`
+ * object (the Aptos analogue of EIP-3009's `authorization` / SVM's `transaction`). The two-field
+ * shape (a `senderAuth` alongside `transaction`) also distinguishes it from the SVM payload.
+ */
+interface ExactAptosPaymentPayload {
+    /** Base64 BCS-serialized `SimpleTransaction` (raw transaction + the bound `feePayerAddress`). */
+    transaction: string;
+    /** Base64 BCS-serialized buyer (sender) `AccountAuthenticator`. */
+    senderAuth: string;
+}
 /** Any `exact`-rail payload shape — EIP-3009 (`authorization`), Permit2 (`permit2Authorization`),
- *  or SVM (`transaction`). */
-type ExactPaymentPayloadAny = ExactPaymentPayload | Permit2PaymentPayload | ExactSvmPaymentPayload;
+ *  SVM (`transaction`), Algorand (`paymentGroup`), or Aptos (`transaction` + `senderAuth`). */
+type ExactPaymentPayloadAny = ExactPaymentPayload | Permit2PaymentPayload | ExactSvmPaymentPayload | ExactAlgorandPaymentPayload | ExactAptosPaymentPayload;
 interface ParsedExactBase {
     x402Version: number;
     /** The client's claimed network (slug or CAIP-2) — for matching, not trust. */
@@ -236,7 +275,9 @@ interface ParsedExactBase {
  * re-derives every verified field from its own trusted rail. A discriminated union on
  * `method`, so narrowing on `method` narrows `payload`: `'eip3009'` → {@link ExactPaymentPayload}
  * (`authorization`), `'permit2'` → {@link Permit2PaymentPayload} (`permit2Authorization`),
- * `'svm'` → {@link ExactSvmPaymentPayload} (`transaction`).
+ * `'svm'` → {@link ExactSvmPaymentPayload} (`transaction`), `'algorand'` →
+ * {@link ExactAlgorandPaymentPayload} (`paymentGroup`); `'aptos'` →
+ * {@link ExactAptosPaymentPayload} (`transaction` + `senderAuth`).
  */
 type ParsedExactPayment = (ParsedExactBase & {
     method: 'eip3009';
@@ -247,6 +288,12 @@ type ParsedExactPayment = (ParsedExactBase & {
 }) | (ParsedExactBase & {
     method: 'svm';
     payload: ExactSvmPaymentPayload;
+}) | (ParsedExactBase & {
+    method: 'algorand';
+    payload: ExactAlgorandPaymentPayload;
+}) | (ParsedExactBase & {
+    method: 'aptos';
+    payload: ExactAptosPaymentPayload;
 });
 interface X402Receipt {
     scheme: 'onchain-proof' | 'exact';
@@ -4266,9 +4313,10 @@ interface DiscoverySigner {
  * chain-agnostic — it never names a family, it just merges `extra`.
  */
 interface ExactRailInfo {
-    method: 'eip3009' | 'permit2' | 'svm';
+    method: 'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos';
     /** Family-specific `extra` keys merged into the exact accept (e.g. `{ name, version }`
-     *  for EVM EIP-3009, `{ feePayer, tokenProgram }` for Solana). */
+     *  for EVM EIP-3009, `{ feePayer, tokenProgram }` for Solana, `{ feePayer }` for
+     *  Algorand/Aptos). */
     extra?: Record<string, unknown>;
 }
 /**
@@ -4349,7 +4397,7 @@ interface ResolvedNetwork {
         reason?: RecipientReason;
     }>;
     /**
-     * OPTIONAL (EVM EIP-3009/Permit2 + Solana SVM) — the BUYER counterpart to {@link settleExactSelf}.
+     * OPTIONAL (EVM EIP-3009/Permit2 + Solana SVM + Algorand + Aptos) — 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
@@ -4404,7 +4452,7 @@ interface ResolvedNetwork {
      * (the merchant's own bound self-settle wallet, in self mode); `feePayer` takes precedence.
      * RPC-read (EVM reads the token's EIP-712 domain; Solana reads the mint's token program); MAY
      * throw a typed config error for an explicitly-requested-but-unsupported method (EVM does). A
-     * family that omits this method offers no `exact` rail (today: every non-EVM, non-Solana family).
+     * family that omits this method offers no `exact` rail (today: every family except EVM, Solana, Algorand, and Aptos).
      */
     resolveExactRail?(input: {
         asset: string;
@@ -4438,10 +4486,12 @@ interface ResolvedNetwork {
      */
     exactPermit2Supported?(): boolean;
     /**
-     * OPTIONAL (EVM-only today) — verify a standard x402 `exact` (EIP-3009) payment
-     * locally, then SELF-SETTLE it by broadcasting `transferWithAuthorization` from the
-     * merchant's own `relayer` wallet (the merchant pays gas to receive; the signature
-     * binds `to`, so no redirect risk). RETURNS a `VerifyResult`:
+     * OPTIONAL (EVM EIP-3009/Permit2 + Solana SVM + Algorand + Aptos) — verify a standard x402 `exact`
+     * payment locally, then SELF-SETTLE it by broadcasting from the merchant's own `relayer`
+     * wallet (the merchant pays the network fee to receive; EVM broadcasts
+     * `transferWithAuthorization`, Solana co-signs the fee payer, Algorand signs the pooled fee
+     * txn + submits the group, Aptos adds the fee-payer signature + submits — the transfer
+     * binds `payTo`, so no redirect risk). RETURNS a `VerifyResult`:
      *   - `{ ok:false, error }` for a CLIENT-fixable fault (bad signature, expired,
      *     wrong recipient/amount, used nonce, simulation revert) → gate replies 402;
      *   - `{ ok:true, receipt }` once the settle tx is mined.
@@ -4930,7 +4980,7 @@ interface SpendSummary {
 }
 
 /** The payment schemes a client can settle: PipRail's native `onchain-proof` (the
- *  default) and the standard x402 `exact` rail (EVM EIP-3009/Permit2 + Solana SVM, opt-in). */
+ *  default) and the standard x402 `exact` rail (EVM EIP-3009/Permit2 + Solana SVM + Algorand, 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). */
@@ -5485,7 +5535,7 @@ 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).
+     *   with `schemes: ['onchain-proof', 'exact']` (EVM EIP-3009/Permit2 + Solana SVM + Algorand).
      */
     discover(opts?: DiscoverOptions): Promise<DiscoveredResource[]>;
     /**
@@ -5902,7 +5952,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 two 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, and the on-chain method (EIP-3009 / Permit2 / SVM) is picked automatically.\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 scheme is OPT-IN by the operator (MCP: PIPRAIL_SCHEMES=onchain-proof,exact);\nyou can't enable it yourself, but you can report when a 402 needs it (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\n(network, asset), plus your spend so far. Read-only; moves no funds. Use it in\nMode 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- Spend caps are PER (network, asset). There is no single cross-token dollar cap \u2014\n  budgets aren't summed across tokens (no price oracle).\n- Spend totals and the time envelope live IN-MEMORY for THIS process; they reset on restart\n  (a convenience, not a durable ledger).\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 two 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.\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 scheme is OPT-IN by the operator (MCP: PIPRAIL_SCHEMES=onchain-proof,exact);\nyou can't enable it yourself, but you can report when a 402 needs it (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\n(network, asset), plus your spend so far. Read-only; moves no funds. Use it in\nMode 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- Spend caps are PER (network, asset). There is no single cross-token dollar cap \u2014\n  budgets aren't summed across tokens (no price oracle).\n- Spend totals and the time envelope live IN-MEMORY for THIS process; they reset on restart\n  (a convenience, not a durable ledger).\n";
 /** Returns {@link PIPRAIL_AGENT_GUIDE} (a parity accessor for callers that prefer a function). */
 declare function agentGuide(): string;
 
@@ -6370,7 +6420,11 @@ interface AcceptOption {
  *     relayer key needed. (EVM facilitators are also the path onto Coinbase's Bazaar directory.)
  */
 interface ExactRailOption {
-    settle: 'self' | {
+    /** How the gate settles an inbound `exact` payment. `'self'` = your own `relayer` broadcasts
+     *  (you pay gas). `'keyless'` = auto-pick a known KEYLESS facilitator for the chain (it sponsors
+     *  gas — zero-config; the same resolution as the top-level `exact: true` shorthand). `{ facilitator }`
+     *  = a specific facilitator you name — pin this in production rather than relying on the auto-pick. */
+    settle: 'self' | 'keyless' | {
         facilitator: string;
         authHeaders?: () => Promise<Record<string, string>>;
         /** Solana only — the facilitator's fee-payer pubkey, if you'd rather set it than have the
@@ -6462,9 +6516,17 @@ interface RequirePaymentOptions {
     /**
      * ALSO advertise a standard x402 `exact` rail so any standard x402 client can pay this
      * gate — opt-in, EVM (EIP-3009/Permit2) + Solana (SVM). See {@link ExactRailOption}.
-     * Omit to keep the gate exactly as today (`onchain-proof` only).
+     * Shorthand **`exact: true`** === `{ settle: 'keyless' }`: the gate auto-picks a known KEYLESS
+     * facilitator for each offered chain (from `KNOWN_FACILITATORS`), so neither buyer nor merchant
+     * pays gas, zero-config. It is a SOFT, best-effort flag — a chain with no available keyless
+     * facilitator DEGRADES GRACEFULLY to the always-present `onchain-proof` rail (the buyer pays gas,
+     * the only option left when no facilitator can sponsor) with a LOUD warning; it never bricks the
+     * gate. For guaranteed gasless, pin `settle: { facilitator }` (recommended in production) or
+     * self-settle `settle: 'self'`; an EXPLICIT `settle` that can't carry exact throws loudly (a config
+     * error you should fix). `false`/omitted keeps the gate exactly as today (`onchain-proof` only —
+     * byte-identical).
      */
-    exact?: ExactRailOption;
+    exact?: boolean | ExactRailOption;
     /**
      * Make this gate's 402 self-describing for the open indexes — **x402scan REQUIRES
      * an input schema or it won't list the resource.** Set `true` for a no-input GET,
@@ -6697,7 +6759,7 @@ interface KnownFacilitator {
     /** The x402 schemes it settles (today only `exact`). */
     schemes: ReadonlyArray<'exact'>;
     /** The exact transfer methods it can settle on this network. */
-    settles: ReadonlyArray<'eip3009' | 'permit2' | 'svm'>;
+    settles: ReadonlyArray<'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos'>;
     /** A short human note (who it is / caveat). */
     note?: string;
 }
@@ -6718,7 +6780,7 @@ declare function knownFacilitatorsFor(network: Caip2): ReadonlyArray<KnownFacili
  * specific transfer `method`). Returns `undefined` when none is known — the `exact: true`
  * shorthand branches on that to throw a coverage-specific guidance error.
  */
-declare function firstKeylessFacilitator(network: Caip2, method?: 'eip3009' | 'permit2' | 'svm'): KnownFacilitator | undefined;
+declare function firstKeylessFacilitator(network: Caip2, method?: 'eip3009' | 'permit2' | 'svm' | 'algorand' | 'aptos'): KnownFacilitator | undefined;
 
 /**
  * Reliable receipt delivery — the durable webhook a stateless gate can't be.