@haven_ai/sdk 0.1.27-alpha.0 → 0.1.28-alpha.0

package/dist/index.d.cts

@@ -1356,32 +1356,31 @@ declare function buildSweepTypedData(auth: SweepAuthorization): SweepTypedData;
 declare function buildSweepAuthorizationMessage(auth: SweepAuthorization): string;
 
 declare class HavenClient {
-    private readonly apiKey;
     private readonly delegateKey;
-    private readonly baseUrl;
+    private readonly havenApi;
+    private readonly accountReads;
+    private readonly delegateSweep;
     private readonly x402Wallet;
-    private readonly requestTimeout;
-    private readonly merchantTimeout;
+    private readonly merchantTransport;
     private readonly confirmationTimeout;
     private readonly pollingInterval;
     private readonly chainRpcs;
     private readonly inFlightX402;
-    private readonly x402ReceiptCache;
     /**
-     * Setup-time headers configured via `HavenClientConfig.defaultHeaders`.
-     * Read-only after construction — use `withRequestContext` for per-call
-     * scoping so concurrent requests don't race on shared mutable state.
+     * The EIP-3009 funding-leg lifecycle (#1618). The facade holds a reference
+     * and delegates; it does not reimplement any of it.
      */
-    private readonly defaultHeaders;
+    private readonly fundingLeg;
     /**
-     * Async-local store for per-request context (currently: extra headers).
-     * Each `withRequestContext` invocation produces an isolated store, so
-     * overlapping async work — like two MCP tool dispatches in flight at
-     * the same time — see their own headers without stepping on each other.
+     * The erc7710 direct-settlement lifecycle (#1619). Separate from the funding
+     * leg on purpose: this scheme has no funding leg to share.
      */
-    private readonly requestContext;
-    /** Monotonic JSON-RPC id source for the MCP `initialize` handshake. */
-    private mcpRequestId;
+    private readonly erc7710;
+    /**
+     * Merchant delivery and the evidence trail behind it (#1620). Scheme-neutral
+     * on purpose — both settlement schemes finish through the same door.
+     */
+    private readonly merchantCompletion;
     /** Delegate address derived from the private key (if provided) */
     readonly delegateAddress: string | undefined;
     constructor(config: HavenClientConfig);
@@ -1474,8 +1473,6 @@ declare class HavenClient {
      * Get the agent identity tied to this API key.
      */
     getAgent(): Promise<HavenAgent>;
-    private agentInFlight;
-    private fetchAgent;
     /**
      * One-shot "am I ready?" bootstrap: identity + live spend authority + a
      * readiness signal, in a single call. Folds {@link getAgent} and
@@ -1546,7 +1543,6 @@ declare class HavenClient {
     getPostPurchaseAllowanceSummary(paymentId: string): Promise<{
         allowance: PostPurchaseAllowanceSummary | null;
         warnings: AgentPaymentWarning[];
-        /** Same authenticated payment-state read used to resolve the settled token. */
         payment: PaymentStatusResult | null;
     }>;
     /**
@@ -1647,35 +1643,16 @@ declare class HavenClient {
      * Pay a previously inspected x402 quote and retry the exact captured request.
      */
     payX402Quote(quote: X402Quote, options?: X402AuthorizationOptions): Promise<Response>;
-    private authorizeStandardX402;
     /**
      * Pay a merchant through **erc7710 direct settlement** (#1454, epic #1450).
      *
-     * The whole point of this path is what it does NOT do. There is no funding
-     * leg: the merchant redeems a delegation chain and pulls from the treasury
-     * directly, so the delegate EOA never holds the money, no sweep can strand
-     * it, and the #713 reconciliation class does not apply. It is also why this
-     * method is SMALLER than the 3009 path — the backend assembles the merchant
-     * `X-PAYMENT` header in `assembleSettlementPayload`, so the SDK builds no
-     * header locally.
-     *
-     *     authorize (payTo = the MERCHANT) → sign the child → settle → header
+     * **Nothing has settled when this returns** — that is why it does not return
+     * an `X402Receipt`; the caller still has to retry the merchant with the
+     * header. **MCP callers must pass `options.resourceUrl`**, because an in-band
+     * MCP 402 challenge frequently carries no `resource` object at all.
      *
-     * The caller then retries the merchant with that header. **Nothing has
-     * settled when this returns** — that is why it does not return an
-     * `X402Receipt`.
-     *
-     * Requires a delegation-rail account. The backend enforces that
-     * (`validateGenericSchemeRail`), and so does this method, before building a
-     * request the backend would only reject: an error a client can explain is
-     * worth more than a 400 it has to decode.
-     *
-     * **MCP callers must pass `options.resourceUrl`.** An in-band MCP 402
-     * challenge frequently carries no `resource` object at all, so
-     * `paymentRequired.resource?.url` is undefined and the backend answers
-     * "Valid url is required". The QA scenario this path was ported from falls
-     * back to the request URL for exactly that reason — the SDK cannot, because
-     * it never saw the request. Pass it.
+     * Both caveats, and why this scheme has no funding leg, are explained where
+     * the lifecycle lives: `x402-erc7710.ts` (#1619).
      */
     settleX402Erc7710(paymentRequired: X402PaymentRequired, options?: {
         resourceUrl?: string;
@@ -1686,30 +1663,21 @@ declare class HavenClient {
      *
      * Split out because the hosted topology cannot use `settleX402Erc7710()`:
      * that method signs in-process with `delegateKey`, and hosted Haven does not
-     * have one and must not. The hosted MCP server drives these two halves with
-     * the LOCAL signer in between, so the key stays where it belongs and the
-     * request shaping stays in one place rather than being reimplemented.
+     * have one and must not.
      */
     prepareX402Erc7710(paymentRequired: X402PaymentRequired, options?: {
         resourceUrl?: string;
         /**
-         * The account's rail, when the caller has ALREADY read it from
-         * `GET /machine-payments/agent` — passing it skips a duplicate fetch
-         * (#1456: the hosted tool reads the agent for the delegate address
-         * anyway, and #1348 pins that path to exactly one agent round-trip).
-         *
-         * This is an optimisation, not a trust boundary: omit it and the rail is
-         * read here, and either way the backend independently refuses erc7710
-         * from a non-delegation account (`validateGenericSchemeRail`). A caller
-         * that asserted the wrong rail would build a request the backend rejects.
+         * The account's rail, when the caller has ALREADY read it — passing it
+         * skips a duplicate fetch (#1456). An optimisation, not a trust
+         * boundary: the backend independently refuses erc7710 from a
+         * non-delegation account (`validateGenericSchemeRail`).
          */
         delegationRail?: boolean;
         /**
          * #1547: the merchant MCP-tool call this authorization was quoted
          * against, persisted so the settle leg can rehydrate it by payment_id
-         * (#1307) — the same option `createX402Intent` already carries. Without
-         * it an erc7710 settle needs merchant_url/tool_name/arguments
-         * re-threaded, which the guided catalog path (#1305) exists to remove.
+         * (#1307).
          */
         mcpCallContext?: X402McpCallContext;
     }): Promise<{
@@ -1721,9 +1689,8 @@ declare class HavenClient {
      * The SETTLE half (#1456): exchange the signed child for the merchant header.
      *
      * The SDK builds no header on this path — the backend assembles the MetaMask
-     * erc7710 payload in `assembleSettlementPayload`. Whoever produced the
-     * signature (an in-process delegate key, or the local edge signer over the
-     * hosted boundary) is irrelevant here.
+     * erc7710 payload. Whoever produced the signature (an in-process delegate
+     * key, or the local edge signer over the hosted boundary) is irrelevant.
      */
     submitX402Erc7710(paymentId: string, signature: string): Promise<string>;
     resumeAuthorizedX402(input: ResumeAuthorizedX402Input): Promise<X402Receipt>;
@@ -1752,45 +1719,6 @@ declare class HavenClient {
      * Requires `delegateKey` to be set in the client config.
      */
     fetch(url: string, init?: RequestInit, options?: X402AuthorizationOptions): Promise<Response>;
-    /**
-     * Run the MCP `initialize` handshake against a Streamable-HTTP endpoint and
-     * return the `mcp-session-id` the server assigns.
-     *
-     * Returns `undefined` whenever the endpoint is not actually an MCP server —
-     * a transport/HTTP error, a missing session id, or a JSON-RPC error in the
-     * handshake response — so the caller can fall back to plain x402.
-     */
-    private mcpInitialize;
-    /**
-     * Send the MCP `notifications/initialized` notification that completes the
-     * lifecycle handshake. Best-effort: the session is already established, so a
-     * failed notification must not abort the payment.
-     */
-    private mcpNotifyInitialized;
-    /** Read a single JSON-RPC message from an MCP response (JSON or SSE body). */
-    private readMcpMessage;
-    /** Add the MCP transport headers (session id + SSE Accept) to a request. */
-    private withMcpHeaders;
-    /**
-     * Collapse an MCP SSE response into a plain JSON response carrying the
-     * JSON-RPC `result`, so callers of `fetch()` never see raw SSE framing.
-     * Non-SSE responses pass through untouched.
-     */
-    private surfaceMcpResult;
-    private retryX402Request;
-    /**
-     * #956: capture the merchant's OWN receipt when the paid response carries
-     * one, and report it to Haven so the reporting feed can attach it next to
-     * the Haven-generated payment evidence (#498). Two supported signals on the
-     * paid response:
-     *
-     *   x-receipt-json: base64-encoded JSON receipt document (inline)
-     *   x-receipt-url:  https URL to the receipt document (reference)
-     *
-     * Strictly best-effort: absence is the normal case, and no failure here may
-     * ever affect the completed payment — the response is already paid for.
-     */
-    private reportMerchantReceipt;
     /**
      * Deliver an already-signed x402 payment header to the merchant and return
      * the merchant's response. Used by the hosted MCP server to complete the
@@ -1814,7 +1742,7 @@ declare class HavenClient {
      * and before delivering the X-PAYMENT header, so the merchant's
      * balanceOf(delegate) / transferWithAuthorization verification sees the funded
      * balance — otherwise it rejects with "Payment verification failed". The
-     * SDK's local path already does this (see authorizeStandardX402); the hosted
+     * SDK's local path already does this (see `X402FundingLeg.authorize`); the hosted
      * split flow regressed when the 5→3 collapse removed the incidental
      * inter-call latency that used to mask it.
      *
@@ -1863,16 +1791,6 @@ declare class HavenClient {
      * fallback (re-send the full context explicitly).
      */
     getX402MerchantCallContext(paymentId: string): Promise<X402MerchantCallContext>;
-    private resolveX402MerchantCompletionContext;
-    private resolveX402WalletForMerchantCall;
-    private assertCanResumeX402;
-    private mapX402ReceiptFromAuthorization;
-    private mapX402ReceiptFromStatus;
-    private buildX402Receipt;
-    private createStandardX402Header;
-    private cacheX402Receipt;
-    private recordMerchantRetryRejected;
-    private reportMachinePaymentEvidence;
     /**
      * Wait for a funding tx to be mined with ≥1 confirmation before the
      * merchant retry, eliminating the race where the merchant's
@@ -1882,39 +1800,7 @@ declare class HavenClient {
      * backend has already confirmed on-chain submission and callers accept the
      * small propagation window as a trade-off for not configuring an RPC URL.
      */
-    private waitForFundingTx;
-    /**
-     * Can the delegate EOA still fund an authorization for `amountAtomic`?
-     *
-     * #1521: the only question that separates a legitimate resume (funding
-     * confirmed, merchant never paid — the delegate still holds the money) from
-     * a replayed settled payment (funding confirmed, merchant paid, delegate
-     * spent). The intent's own `status: 'confirmed'` is identical in both.
-     *
-     * The balance is asked of the CHAIN rather than of Haven's bookkeeping on
-     * purpose: the merchant-settlement evidence record is written by this SDK
-     * *after* the merchant call, so a client that dies between the two leaves
-     * the backend believing the merchant was never paid — the exact case the
-     * discriminator has to get right. The chain cannot be behind in that way.
-     *
-     * Returns `null` — never a guess — when `chainRpcs` has no entry for the
-     * chain or the read fails. Callers must treat that as "unverifiable", not
-     * as "funded".
-     */
-    private delegateCanFund;
     private throwIfNonSignableAuthorizationState;
-    private throwPaymentStateError;
-    private paymentStateFromRaw;
-    private x402PayerAddress;
-    private snapshotX402Request;
-    private snapshotRequestBody;
-    private requestInitFromSnapshot;
-    private withX402Wallet;
-    private buildX402Quote;
-    private detectX402McpTransport;
-    private buildX402ResumeState;
-    private attachResumeState;
-    private attachX402ResumeState;
     /**
      * Execute a tool call by name and input.
      *
@@ -1928,24 +1814,8 @@ declare class HavenClient {
      * ```
      */
     executeTool(toolName: string, input: Record<string, unknown>): Promise<Record<string, unknown>>;
-    private toolX402PaymentRequired;
-    private x402ToolReceipt;
-    private toolError;
     private post;
     private get;
-    /**
-     * #1300: every MERCHANT-facing fetch goes through here. Haven API calls
-     * have always been bounded (request() below); the merchant probes/retries
-     * called globalThis.fetch bare, so a slow-loris merchant could hold a tool
-     * call open forever. A caller-supplied signal still applies (combined via
-     * AbortSignal.any); a timeout abort surfaces as a clear HavenApiError 504
-     * naming the URL rather than a bare AbortError.
-     */
-    private merchantFetch;
-    private request;
-    private mapPaymentResult;
-    private mapPaymentStatusResult;
-    private mapPaymentReceipt;
 }
 
 /**

package/dist/index.d.ts

@@ -1356,32 +1356,31 @@ declare function buildSweepTypedData(auth: SweepAuthorization): SweepTypedData;
 declare function buildSweepAuthorizationMessage(auth: SweepAuthorization): string;
 
 declare class HavenClient {
-    private readonly apiKey;
     private readonly delegateKey;
-    private readonly baseUrl;
+    private readonly havenApi;
+    private readonly accountReads;
+    private readonly delegateSweep;
     private readonly x402Wallet;
-    private readonly requestTimeout;
-    private readonly merchantTimeout;
+    private readonly merchantTransport;
     private readonly confirmationTimeout;
     private readonly pollingInterval;
     private readonly chainRpcs;
     private readonly inFlightX402;
-    private readonly x402ReceiptCache;
     /**
-     * Setup-time headers configured via `HavenClientConfig.defaultHeaders`.
-     * Read-only after construction — use `withRequestContext` for per-call
-     * scoping so concurrent requests don't race on shared mutable state.
+     * The EIP-3009 funding-leg lifecycle (#1618). The facade holds a reference
+     * and delegates; it does not reimplement any of it.
      */
-    private readonly defaultHeaders;
+    private readonly fundingLeg;
     /**
-     * Async-local store for per-request context (currently: extra headers).
-     * Each `withRequestContext` invocation produces an isolated store, so
-     * overlapping async work — like two MCP tool dispatches in flight at
-     * the same time — see their own headers without stepping on each other.
+     * The erc7710 direct-settlement lifecycle (#1619). Separate from the funding
+     * leg on purpose: this scheme has no funding leg to share.
      */
-    private readonly requestContext;
-    /** Monotonic JSON-RPC id source for the MCP `initialize` handshake. */
-    private mcpRequestId;
+    private readonly erc7710;
+    /**
+     * Merchant delivery and the evidence trail behind it (#1620). Scheme-neutral
+     * on purpose — both settlement schemes finish through the same door.
+     */
+    private readonly merchantCompletion;
     /** Delegate address derived from the private key (if provided) */
     readonly delegateAddress: string | undefined;
     constructor(config: HavenClientConfig);
@@ -1474,8 +1473,6 @@ declare class HavenClient {
      * Get the agent identity tied to this API key.
      */
     getAgent(): Promise<HavenAgent>;
-    private agentInFlight;
-    private fetchAgent;
     /**
      * One-shot "am I ready?" bootstrap: identity + live spend authority + a
      * readiness signal, in a single call. Folds {@link getAgent} and
@@ -1546,7 +1543,6 @@ declare class HavenClient {
     getPostPurchaseAllowanceSummary(paymentId: string): Promise<{
         allowance: PostPurchaseAllowanceSummary | null;
         warnings: AgentPaymentWarning[];
-        /** Same authenticated payment-state read used to resolve the settled token. */
         payment: PaymentStatusResult | null;
     }>;
     /**
@@ -1647,35 +1643,16 @@ declare class HavenClient {
      * Pay a previously inspected x402 quote and retry the exact captured request.
      */
     payX402Quote(quote: X402Quote, options?: X402AuthorizationOptions): Promise<Response>;
-    private authorizeStandardX402;
     /**
      * Pay a merchant through **erc7710 direct settlement** (#1454, epic #1450).
      *
-     * The whole point of this path is what it does NOT do. There is no funding
-     * leg: the merchant redeems a delegation chain and pulls from the treasury
-     * directly, so the delegate EOA never holds the money, no sweep can strand
-     * it, and the #713 reconciliation class does not apply. It is also why this
-     * method is SMALLER than the 3009 path — the backend assembles the merchant
-     * `X-PAYMENT` header in `assembleSettlementPayload`, so the SDK builds no
-     * header locally.
-     *
-     *     authorize (payTo = the MERCHANT) → sign the child → settle → header
+     * **Nothing has settled when this returns** — that is why it does not return
+     * an `X402Receipt`; the caller still has to retry the merchant with the
+     * header. **MCP callers must pass `options.resourceUrl`**, because an in-band
+     * MCP 402 challenge frequently carries no `resource` object at all.
      *
-     * The caller then retries the merchant with that header. **Nothing has
-     * settled when this returns** — that is why it does not return an
-     * `X402Receipt`.
-     *
-     * Requires a delegation-rail account. The backend enforces that
-     * (`validateGenericSchemeRail`), and so does this method, before building a
-     * request the backend would only reject: an error a client can explain is
-     * worth more than a 400 it has to decode.
-     *
-     * **MCP callers must pass `options.resourceUrl`.** An in-band MCP 402
-     * challenge frequently carries no `resource` object at all, so
-     * `paymentRequired.resource?.url` is undefined and the backend answers
-     * "Valid url is required". The QA scenario this path was ported from falls
-     * back to the request URL for exactly that reason — the SDK cannot, because
-     * it never saw the request. Pass it.
+     * Both caveats, and why this scheme has no funding leg, are explained where
+     * the lifecycle lives: `x402-erc7710.ts` (#1619).
      */
     settleX402Erc7710(paymentRequired: X402PaymentRequired, options?: {
         resourceUrl?: string;
@@ -1686,30 +1663,21 @@ declare class HavenClient {
      *
      * Split out because the hosted topology cannot use `settleX402Erc7710()`:
      * that method signs in-process with `delegateKey`, and hosted Haven does not
-     * have one and must not. The hosted MCP server drives these two halves with
-     * the LOCAL signer in between, so the key stays where it belongs and the
-     * request shaping stays in one place rather than being reimplemented.
+     * have one and must not.
      */
     prepareX402Erc7710(paymentRequired: X402PaymentRequired, options?: {
         resourceUrl?: string;
         /**
-         * The account's rail, when the caller has ALREADY read it from
-         * `GET /machine-payments/agent` — passing it skips a duplicate fetch
-         * (#1456: the hosted tool reads the agent for the delegate address
-         * anyway, and #1348 pins that path to exactly one agent round-trip).
-         *
-         * This is an optimisation, not a trust boundary: omit it and the rail is
-         * read here, and either way the backend independently refuses erc7710
-         * from a non-delegation account (`validateGenericSchemeRail`). A caller
-         * that asserted the wrong rail would build a request the backend rejects.
+         * The account's rail, when the caller has ALREADY read it — passing it
+         * skips a duplicate fetch (#1456). An optimisation, not a trust
+         * boundary: the backend independently refuses erc7710 from a
+         * non-delegation account (`validateGenericSchemeRail`).
          */
         delegationRail?: boolean;
         /**
          * #1547: the merchant MCP-tool call this authorization was quoted
          * against, persisted so the settle leg can rehydrate it by payment_id
-         * (#1307) — the same option `createX402Intent` already carries. Without
-         * it an erc7710 settle needs merchant_url/tool_name/arguments
-         * re-threaded, which the guided catalog path (#1305) exists to remove.
+         * (#1307).
          */
         mcpCallContext?: X402McpCallContext;
     }): Promise<{
@@ -1721,9 +1689,8 @@ declare class HavenClient {
      * The SETTLE half (#1456): exchange the signed child for the merchant header.
      *
      * The SDK builds no header on this path — the backend assembles the MetaMask
-     * erc7710 payload in `assembleSettlementPayload`. Whoever produced the
-     * signature (an in-process delegate key, or the local edge signer over the
-     * hosted boundary) is irrelevant here.
+     * erc7710 payload. Whoever produced the signature (an in-process delegate
+     * key, or the local edge signer over the hosted boundary) is irrelevant.
      */
     submitX402Erc7710(paymentId: string, signature: string): Promise<string>;
     resumeAuthorizedX402(input: ResumeAuthorizedX402Input): Promise<X402Receipt>;
@@ -1752,45 +1719,6 @@ declare class HavenClient {
      * Requires `delegateKey` to be set in the client config.
      */
     fetch(url: string, init?: RequestInit, options?: X402AuthorizationOptions): Promise<Response>;
-    /**
-     * Run the MCP `initialize` handshake against a Streamable-HTTP endpoint and
-     * return the `mcp-session-id` the server assigns.
-     *
-     * Returns `undefined` whenever the endpoint is not actually an MCP server —
-     * a transport/HTTP error, a missing session id, or a JSON-RPC error in the
-     * handshake response — so the caller can fall back to plain x402.
-     */
-    private mcpInitialize;
-    /**
-     * Send the MCP `notifications/initialized` notification that completes the
-     * lifecycle handshake. Best-effort: the session is already established, so a
-     * failed notification must not abort the payment.
-     */
-    private mcpNotifyInitialized;
-    /** Read a single JSON-RPC message from an MCP response (JSON or SSE body). */
-    private readMcpMessage;
-    /** Add the MCP transport headers (session id + SSE Accept) to a request. */
-    private withMcpHeaders;
-    /**
-     * Collapse an MCP SSE response into a plain JSON response carrying the
-     * JSON-RPC `result`, so callers of `fetch()` never see raw SSE framing.
-     * Non-SSE responses pass through untouched.
-     */
-    private surfaceMcpResult;
-    private retryX402Request;
-    /**
-     * #956: capture the merchant's OWN receipt when the paid response carries
-     * one, and report it to Haven so the reporting feed can attach it next to
-     * the Haven-generated payment evidence (#498). Two supported signals on the
-     * paid response:
-     *
-     *   x-receipt-json: base64-encoded JSON receipt document (inline)
-     *   x-receipt-url:  https URL to the receipt document (reference)
-     *
-     * Strictly best-effort: absence is the normal case, and no failure here may
-     * ever affect the completed payment — the response is already paid for.
-     */
-    private reportMerchantReceipt;
     /**
      * Deliver an already-signed x402 payment header to the merchant and return
      * the merchant's response. Used by the hosted MCP server to complete the
@@ -1814,7 +1742,7 @@ declare class HavenClient {
      * and before delivering the X-PAYMENT header, so the merchant's
      * balanceOf(delegate) / transferWithAuthorization verification sees the funded
      * balance — otherwise it rejects with "Payment verification failed". The
-     * SDK's local path already does this (see authorizeStandardX402); the hosted
+     * SDK's local path already does this (see `X402FundingLeg.authorize`); the hosted
      * split flow regressed when the 5→3 collapse removed the incidental
      * inter-call latency that used to mask it.
      *
@@ -1863,16 +1791,6 @@ declare class HavenClient {
      * fallback (re-send the full context explicitly).
      */
     getX402MerchantCallContext(paymentId: string): Promise<X402MerchantCallContext>;
-    private resolveX402MerchantCompletionContext;
-    private resolveX402WalletForMerchantCall;
-    private assertCanResumeX402;
-    private mapX402ReceiptFromAuthorization;
-    private mapX402ReceiptFromStatus;
-    private buildX402Receipt;
-    private createStandardX402Header;
-    private cacheX402Receipt;
-    private recordMerchantRetryRejected;
-    private reportMachinePaymentEvidence;
     /**
      * Wait for a funding tx to be mined with ≥1 confirmation before the
      * merchant retry, eliminating the race where the merchant's
@@ -1882,39 +1800,7 @@ declare class HavenClient {
      * backend has already confirmed on-chain submission and callers accept the
      * small propagation window as a trade-off for not configuring an RPC URL.
      */
-    private waitForFundingTx;
-    /**
-     * Can the delegate EOA still fund an authorization for `amountAtomic`?
-     *
-     * #1521: the only question that separates a legitimate resume (funding
-     * confirmed, merchant never paid — the delegate still holds the money) from
-     * a replayed settled payment (funding confirmed, merchant paid, delegate
-     * spent). The intent's own `status: 'confirmed'` is identical in both.
-     *
-     * The balance is asked of the CHAIN rather than of Haven's bookkeeping on
-     * purpose: the merchant-settlement evidence record is written by this SDK
-     * *after* the merchant call, so a client that dies between the two leaves
-     * the backend believing the merchant was never paid — the exact case the
-     * discriminator has to get right. The chain cannot be behind in that way.
-     *
-     * Returns `null` — never a guess — when `chainRpcs` has no entry for the
-     * chain or the read fails. Callers must treat that as "unverifiable", not
-     * as "funded".
-     */
-    private delegateCanFund;
     private throwIfNonSignableAuthorizationState;
-    private throwPaymentStateError;
-    private paymentStateFromRaw;
-    private x402PayerAddress;
-    private snapshotX402Request;
-    private snapshotRequestBody;
-    private requestInitFromSnapshot;
-    private withX402Wallet;
-    private buildX402Quote;
-    private detectX402McpTransport;
-    private buildX402ResumeState;
-    private attachResumeState;
-    private attachX402ResumeState;
     /**
      * Execute a tool call by name and input.
      *
@@ -1928,24 +1814,8 @@ declare class HavenClient {
      * ```
      */
     executeTool(toolName: string, input: Record<string, unknown>): Promise<Record<string, unknown>>;
-    private toolX402PaymentRequired;
-    private x402ToolReceipt;
-    private toolError;
     private post;
     private get;
-    /**
-     * #1300: every MERCHANT-facing fetch goes through here. Haven API calls
-     * have always been bounded (request() below); the merchant probes/retries
-     * called globalThis.fetch bare, so a slow-loris merchant could hold a tool
-     * call open forever. A caller-supplied signal still applies (combined via
-     * AbortSignal.any); a timeout abort surfaces as a clear HavenApiError 504
-     * naming the URL rather than a bare AbortError.
-     */
-    private merchantFetch;
-    private request;
-    private mapPaymentResult;
-    private mapPaymentStatusResult;
-    private mapPaymentReceipt;
 }
 
 /**