@haven_ai/sdk 0.0.0-dev.202609031523.fd49e1a

package/dist/index.d.cts

@@ -0,0 +1,2808 @@
+import { PaymentRequirements } from 'x402/types';
+
+/**
+ * Verifiable payment receipts.
+ *
+ * A self-contained proof bundle for a settled Haven payment that anyone can
+ * verify **independently of Haven**. The anchor is the agent delegate's
+ * signature over the on-chain transfer hash: recover the signer and confirm it
+ * is the agent's delegate, and you have cryptographic proof the agent authorised
+ * exactly this transfer — no need to trust Haven's backend. The on-chain
+ * `txHash` is the settlement source of truth (verify on any explorer).
+ *
+ * This lives in the SDK so agents and users can verify receipts client-side
+ * with zero Haven trust.
+ */
+declare const RECEIPT_VERSION = "haven-receipt-1";
+interface PaymentReceipt {
+    version: typeof RECEIPT_VERSION;
+    paymentId: string;
+    payment: {
+        token: string;
+        tokenAddress: string;
+        amount: string;
+        amountSek: string | null;
+        recipient: string;
+        safe: string;
+        chainId: number;
+        settledAt: string | null;
+        resourceUrl: string | null;
+    };
+    /** The agent's cryptographic authorisation — what makes the receipt verifiable. */
+    authorization: {
+        delegate: string;
+        signHash: string;
+        signature: string | null;
+    };
+    onChain: {
+        txHash: string | null;
+        chainId: number;
+    };
+}
+type ReceiptVerification = {
+    verified: true;
+    recoveredSigner: string;
+} | {
+    verified: false;
+    reason: 'missing_signature' | 'bad_signature' | 'signer_mismatch';
+    recoveredSigner?: string;
+};
+/**
+ * Verify a receipt independently: recover the signer from the authorisation and
+ * confirm it is the agent's delegate. Pure — `recover` is injectable but
+ * defaults to standard ECDSA recovery, so this runs anywhere (no Haven backend).
+ */
+declare function verifyPaymentReceipt(receipt: PaymentReceipt, recover?: (hash: string, signature: string) => string): ReceiptVerification;
+
+interface HavenClientConfig {
+    /** Haven API key (sk_agent_xxx) */
+    apiKey: string;
+    /** Agent's delegate EOA private key. If provided, the SDK handles signing automatically. */
+    delegateKey?: string;
+    /** Haven API base URL (default: http://localhost:3001) */
+    baseUrl?: string;
+    /** Optional wallet identity to send as the x402-wallet header. */
+    x402Wallet?: string;
+    /** Timeout in ms for individual HTTP requests (default: 30000) */
+    requestTimeout?: number;
+    /** Timeout (ms) for MERCHANT-facing requests — x402/MPP probes, MCP
+     *  handshakes, paid retries. Separate from requestTimeout (Haven API):
+     *  merchants may settle on-chain synchronously, so the default is
+     *  deliberately generous. #1300. */
+    merchantTimeout?: number;
+    /** Timeout in ms when polling for tx confirmation (default: 90000) */
+    confirmationTimeout?: number;
+    /** Polling interval in ms when waiting for confirmation (default: 3000) */
+    pollingInterval?: number;
+    /**
+     * Extra headers to attach to every request to the Haven API.
+     *
+     * Used by the MCP server to tag requests with `X-Haven-MCP-Tool: <name>`
+     * so the backend can record an audit-log entry per tool invocation. Has
+     * no effect on outbound merchant requests (x402 / MPP) — those are
+     * standard HTTP and never carry Haven-internal headers.
+     */
+    defaultHeaders?: Record<string, string>;
+    /**
+     * JSON-RPC RPC URLs keyed by EIP-155 chain ID.
+     *
+     * When provided for a chain, the SDK waits for ≥1 on-chain confirmation of
+     * the AllowanceModule funding tx before retrying the merchant. This prevents
+     * the race where the merchant's `balanceOf(delegate)` call runs before the
+     * funding block has propagated to the merchant's RPC node.
+     *
+     * Without this option the SDK proceeds as soon as Haven's backend confirms
+     * submission (backward-compatible default). Set it to a reliable RPC
+     * endpoint (e.g. Alchemy / Infura) for production usage.
+     *
+     * @example { 8453: 'https://mainnet.base.org' }
+     */
+    chainRpcs?: Record<number, string>;
+}
+interface PaymentRequest {
+    /** Token symbol: "EURe", "USDC.e", or "xDAI" */
+    token: string;
+    /** Amount as a decimal string, e.g. "5.00" */
+    amount: string;
+    /** Recipient Ethereum address (0x...) */
+    to: string;
+    /**
+     * Optional dedupe key (#1207): a retried request with the same key returns
+     * the FIRST request's result instead of minting a second transfer or a
+     * second approval. Same contract as /machine-payments/send. Max 128 chars.
+     */
+    idempotencyKey?: string;
+}
+interface SignData {
+    /** The hash to sign (keccak256, 0x-prefixed) */
+    hash: string;
+    /**
+     * Delegation rail: 'eip712_userop' (funding redemption) or
+     * 'eip712_delegation' (erc7710 settlement child). Absent = legacy
+     * AllowanceModule (raw ECDSA over `hash`). The session rail's
+     * 'eip191_userop' is retired (#834).
+     *
+     * When present, `hash` is NOT what gets signed — `typed_data` is (#1138).
+     */
+    signature_scheme?: 'eip712_userop' | 'eip712_delegation';
+    /**
+     * EIP-712 payload the account validates, signed VERBATIM (#829). Present
+     * whenever `signature_scheme` is — never reconstruct it from `components`.
+     */
+    typed_data?: {
+        domain: Record<string, unknown>;
+        types: Record<string, unknown>;
+        primaryType: string;
+        message: Record<string, unknown>;
+    };
+    /** Breakdown of values that were hashed — useful for debugging */
+    components: {
+        safe: string;
+        token: string;
+        to: string;
+        amount: string;
+        payment_token: string;
+        payment: string;
+        nonce: number;
+    };
+    /** Human-readable signing instructions */
+    instructions: string;
+}
+interface PaymentIntent {
+    /** Unique payment ID */
+    paymentId: string;
+    /** Current status */
+    status: 'pending_signature';
+    /** ISO 8601 expiry timestamp */
+    expiresAt: string;
+    /** Data needed to sign the payment */
+    signData: SignData;
+}
+type PaymentStatus = 'pending_signature' | 'submitted' | 'confirmed' | 'pending_approval' | 'approved' | 'proposed' | 'executed' | 'rejected' | 'expired' | 'failed';
+interface PaymentResult {
+    /** Unique payment ID */
+    paymentId: string;
+    /** Final status */
+    status: PaymentStatus;
+    /** Token that was sent */
+    token: string;
+    /** Amount that was sent (human-readable) */
+    amount: string;
+    /** Recipient address */
+    to: string;
+    /** On-chain transaction hash (present when confirmed) */
+    txHash: string | null;
+    /** Error message (present when failed) */
+    errorMessage: string | null;
+    /** Block explorer URL for the transaction (chain-dependent) */
+    explorerUrl: string | null;
+    /** ISO 8601 timestamps */
+    createdAt: string;
+    signedAt: string | null;
+    submittedAt: string | null;
+    confirmedAt: string | null;
+    expiresAt: string;
+    /**
+     * Platform fee surfaced on the result so it's never silently collected. Dark
+     * today (`amount` "0", `applied` false); always present so it's visible the
+     * moment fees go live.
+     */
+    fee?: PaymentFee | null;
+}
+/** The Haven platform fee applied to a payment (#386). */
+interface PaymentFee {
+    /** Human-readable fee amount ("0" while the fee module is dark). */
+    amount: string;
+    /** Token the fee is denominated in. */
+    token: string;
+    /** Fee as basis points of gross (0 while dark). */
+    basisPoints: number;
+    /** True when a non-zero fee was actually applied. */
+    applied: boolean;
+}
+/** Payment requirements from an HTTP 402 response (x402 protocol). */
+interface X402PaymentRequired {
+    x402Version: number;
+    resource: {
+        url: string;
+        description?: string;
+        mimeType?: string;
+        [key: string]: unknown;
+    };
+    accepts: X402PaymentOption[];
+    error?: string;
+    extensions?: Record<string, unknown>;
+}
+/** A single payment option from x402 PaymentRequired. */
+interface X402PaymentOption {
+    scheme: string;
+    network: string;
+    amount: string;
+    maxAmountRequired?: string;
+    resource?: string;
+    description?: string;
+    mimeType?: string;
+    asset: string;
+    payTo: string;
+    maxTimeoutSeconds: number;
+    /**
+     * Merchant-supplied scheme metadata. Two keys are load-bearing for Haven
+     * (#1453), both from MetaMask's erc7710 x402 shape:
+     *
+     *   assetTransferMethod  — 'erc7710' marks this entry as settleable by
+     *                          redeeming a delegation chain. Absent/other means
+     *                          the standard EIP-3009 authorization.
+     *   facilitatorAddresses — who may redeem it, pinned into the settlement
+     *                          child's redeemer caveat (#1058).
+     *
+     * Left as an open record on purpose: the field is the merchant's, and
+     * narrowing it to Haven's two keys would silently drop everything else a
+     * merchant sends. Read it through `x402AssetTransferMethod` /
+     * `x402FacilitatorAddresses` rather than indexing it raw.
+     */
+    extra?: Record<string, unknown>;
+}
+/** Receipt returned after a successful x402 payment. */
+interface X402Receipt {
+    success: boolean;
+    paymentId: string;
+    txHash: string;
+    token: string;
+    amount: string;
+    to: string;
+    resourceUrl: string;
+    explorerUrl: string;
+    accepted?: X402PaymentOption;
+    paymentHeader?: string;
+    merchantTo?: string | null;
+    payer?: string;
+    chainId?: number;
+    haven?: {
+        paymentId: string;
+        fundingTxHash: string;
+        fundingExplorerUrl: string;
+    };
+    merchant?: {
+        payTo: string | null;
+        settlementTxHash?: string | null;
+        settlementExplorerUrl?: string | null;
+    };
+    x402?: {
+        amount: string;
+        token: string;
+        network: string;
+        asset: string;
+        resource: string;
+    };
+}
+interface X402AuthorizationOptions {
+    /** Stable caller-supplied key for this user intent. Prevents duplicate approvals across fresh 402 quotes. */
+    idempotencyKey?: string;
+    /**
+     * #1307: the merchant MCP-tool call context this quote was made against
+     * (merchant_url, tool_name, arguments, mcp_transport). Persisted on the
+     * intent so `getX402MerchantCallContext` can rehydrate it by payment_id at
+     * settle/complete time instead of the caller re-threading it. Optional —
+     * omit for a non-MCP-tool x402 merchant (plain HTTP resource).
+     */
+    mcpCallContext?: X402McpCallContext;
+    /**
+     * #1348: the agent's delegate address, when the caller already resolved it
+     * from `getAgent()` in this same flow — skips `createX402Intent`'s internal
+     * agent fetch (one full round trip on every guided purchase). Staleness
+     * caveat (#1358 review): the backend derives the funding shape by comparing
+     * `payTo` to the CURRENT delegate address, so a value made stale by a
+     * delegate rotation mid-flow is not always a clean failure — a pinned-budget
+     * agent gets a 403, but an open-budget delegation agent would route to the
+     * settlement shape with the stale address. The window is one tool call
+     * (previously sub-millisecond, now the merchant-quote duration), never
+     * externally suppliable; server-truth hardening is tracked in #1360. Only
+     * pass an address fetched in THIS flow; omit to keep the self-contained
+     * fetch.
+     */
+    delegateAddress?: string;
+}
+/**
+ * Keyless x402 construct result.
+ *
+ * Returned by `createX402Intent` — the non-custodial half of an x402 payment.
+ * It carries the unsigned funding hash (`signData.hash`, Safe → delegate EOA)
+ * plus everything the *edge* needs to build and sign the EIP-3009 merchant
+ * header itself. The construct path never signs; both delegate signatures
+ * (funding hash + merchant header) happen on the machine that holds the key.
+ */
+interface X402Intent {
+    /** Haven payment id for the funding transfer. */
+    paymentId: string;
+    /** Stable key used to create or refresh this x402 funding intent. */
+    idempotencyKey: string;
+    status: 'pending_signature';
+    /** ISO 8601 expiry of the funding intent, if returned. */
+    expiresAt?: string;
+    /** The unsigned funding hash to sign with the delegate key (Safe → delegate EOA). */
+    signData: SignData;
+    /** The selected x402 option — the edge needs this to build the EIP-3009 header. */
+    accepted: X402PaymentOption;
+    /** Resource URL the 402 came from. */
+    resourceUrl: string;
+    /** Merchant payTo address (the final recipient of the EIP-3009 transfer). */
+    merchantTo: string;
+    /** Atomic amount the edge signer must authorize in the merchant header. */
+    amountAtomic: string;
+    /** Token contract the merchant header must pay. */
+    asset: string;
+    /** x402 network the merchant header must use. */
+    network: string;
+    /** Haven-authenticated binding over the x402 expected context. */
+    expectedAuth: X402ExpectedAuth;
+    /**
+     * #1690: the payer identity Haven bound into the expected context (v3),
+     * relayed VERBATIM to the signer's wire shape. Absent until the backend
+     * flips X402_EMIT_PAYER_CONTEXT.
+     */
+    payerDelegate?: string;
+    payerAgentId?: string;
+    /**
+     * EIP-712 digest of `signData.typed_data`, present on the delegation rail
+     * (#1138). The edge signer needs it to reconstruct the v2 expected-context
+     * message that Haven signed.
+     */
+    expectedTypedDataHash?: string;
+    /** Delegate EOA the funding transfer tops up (the x402 payer). */
+    fundingTo: string;
+}
+interface X402ExpectedContext {
+    paymentId: string;
+    payloadHash: string;
+    resourceUrl: string;
+    merchantTo: string;
+    amount: string;
+    asset: string;
+    network: string;
+    /** Optional ISO expiry for the funding/quote window. When present, it is bound into the Haven-authenticated context. */
+    expiresAt?: string;
+    /**
+     * EIP-712 digest of the typed data the account actually validates
+     * (delegation rail, #1138). Present ⇒ the context is **version 2** and the
+     * signer must sign that typed data, never `payloadHash`.
+     *
+     * On the delegation rail `payloadHash` is the bare ERC-4337 UserOp hash,
+     * which is NOT what the account validates — binding it alone would leave the
+     * edge signer unable to verify the payload it is being asked to sign. Binding
+     * this digest makes Haven's declaration cover the real payload.
+     */
+    typedDataHash?: string;
+    /**
+     * The DELEGATE ADDRESS this quote was created for (#1690). Present ⇒ the
+     * context is **version 3** and the signer refuses to sign when this is not
+     * its own delegate — the guard that turns "quote as agent A, sign as agent
+     * B" from an on-chain revert three layers later into a named refusal.
+     * Inside the Haven-signed message on purpose: outside it, it is forgeable.
+     */
+    payerDelegate?: string;
+    /** The paying agent's id, for the refusal message's diagnosis (#1690). */
+    payerAgentId?: string;
+}
+interface X402ExpectedAuth {
+    /**
+     * 1 = hash-only (legacy rail). 2 = carries `typedDataHash` (delegation rail,
+     * #1138).
+     *
+     * Deliberately `number`, not a literal union (#1143). This is an **inbound**
+     * value: a signer parses a context Haven produced, and a signer older than the
+     * backend will legitimately receive a version it does not know. A closed union
+     * makes that state unrepresentable, which pushed the rejection down to the
+     * schema boundary and produced a raw validation error naming neither the cause
+     * nor the fix. The supported set lives in the signer
+     * (`SUPPORTED_X402_EXPECTED_VERSIONS`), which fails closed on anything outside
+     * it with an actionable message.
+     */
+    version: number;
+    message: string;
+    signature: string;
+    signer: string;
+}
+/** Serializable HTTP request state for retrying the same x402 merchant request. */
+interface X402RequestSnapshot {
+    url: string;
+    method: string;
+    headers: [string, string][];
+    body?: string;
+}
+interface X402McpTransport {
+    handshakeRequired: boolean;
+    source: 'path' | 'bazaar';
+}
+/**
+ * #1307: the merchant MCP-tool call an x402 quote was made against — carried
+ * through `createX402Intent`'s options so Haven can persist it for the
+ * settle-leg rehydration handoff (`getX402MerchantCallContext`). Convenience
+ * metadata for retrying the merchant's OWN JSON-RPC call, never payment
+ * authority.
+ */
+interface X402McpCallContext {
+    merchantUrl: string;
+    toolName: string;
+    arguments?: Record<string, unknown>;
+    mcpTransport?: X402McpTransport;
+}
+/**
+ * Response shape of `getX402MerchantCallContext` — the stored merchant call
+ * context for a payment_id, rehydrated instead of re-threaded (#1307).
+ */
+interface X402MerchantCallContext {
+    paymentId: string;
+    merchantUrl: string;
+    toolName: string;
+    arguments: Record<string, unknown>;
+    mcpTransport?: X402McpTransport;
+}
+/** Quote parsed from an HTTP 402 response without creating a Haven payment. */
+interface X402Quote {
+    rail: 'x402';
+    idempotencyKey: string;
+    paymentRequired: X402PaymentRequired;
+    accepted: X402PaymentOption;
+    /**
+     * #2054: which selector produced `accepted`, and therefore which entry every
+     * amount on this quote describes. `'standard'` is the untagged,
+     * EIP-3009-settleable entry; `'erc7710'` means the merchant advertises NO
+     * standard entry, so the quote describes its erc7710 one — settleable only
+     * from a delegation-rail account, a fact the quote layer cannot see (the
+     * rail is a property of the ACCOUNT, not of the 402). This field is
+     * descriptive: the actual settlement scheme is still chosen later, with the
+     * rail in hand, by `selectX402SettlementScheme`.
+     */
+    acceptedScheme: 'standard' | 'erc7710';
+    request: X402RequestSnapshot;
+    mcpTransport?: X402McpTransport;
+    resourceUrl: string;
+    description: string | null;
+    mimeType: string | null;
+    amountAtomic: string;
+    amount: string;
+    token: string;
+    /**
+     * #1351: decimals for `asset` on `network`, resolved from the SAME
+     * address→token binding that produced `token` — the quote's own authority on
+     * how many atomic units one human unit is. `null` when the merchant's asset
+     * is not a token Haven recognises on that network, in which case `token` is
+     * an unverified fallback label and NO human→atomic conversion is safe.
+     * Consumers converting a human-denominated figure (a user-intent spending
+     * cap) MUST fail closed on `null` rather than assume 6.
+     */
+    decimals: number | null;
+    asset: string;
+    network: string;
+    chainId: number | null;
+    merchantAddress: string;
+    maxTimeoutSeconds: number;
+}
+/** State bundle an agent can persist while waiting for manual x402 approval. */
+interface X402ResumeState {
+    rail: 'x402';
+    paymentId: string;
+    idempotencyKey: string;
+    paymentRequired: X402PaymentRequired;
+    accepted: X402PaymentOption;
+    url: string;
+    request?: X402RequestSnapshot;
+    resourceUrl: string;
+    description: string | null;
+    amountAtomic: string;
+    amount: string;
+    token: string;
+    asset: string;
+    network: string;
+    chainId: number | null;
+    merchantAddress: string;
+}
+type PaymentResumeState = X402ResumeState;
+interface ResumeAuthorizedX402Input extends X402AuthorizationOptions {
+    /** Payment or approval request ID returned by authorizeX402 / haven.fetch. */
+    paymentId: string;
+    /** Original or freshly parsed x402 requirements for the merchant retry. */
+    paymentRequired: X402PaymentRequired;
+}
+interface ResumeX402PaymentInput extends X402AuthorizationOptions {
+    /** Payment or approval request ID returned by authorizeX402 / haven.fetch. */
+    paymentId: string;
+    /** Original paid URL. If paymentRequired is omitted, Haven will call it once to re-read the 402 challenge. */
+    url: string;
+    /** Original fetch options. Reused for the 402 probe and final merchant retry. */
+    init?: RequestInit;
+    /** Serializable original request captured by quoteX402() / pending approval errors. */
+    request?: X402RequestSnapshot;
+    /** Original or freshly parsed x402 requirements. Supplying this avoids an extra merchant 402 probe. */
+    paymentRequired?: X402PaymentRequired;
+}
+type MachinePaymentRail = 'x402' | 'mpp_demo' | 'mpp_crypto' | 'stripe_deposit' | 'spt';
+interface HavenAgent {
+    id: string;
+    name: string;
+    status: string;
+    safeAddress: string;
+    delegateAddress: string;
+    chainId: number;
+    /**
+     * Which on-chain policy primitive gates this agent's spend (#1306): the
+     * legacy Safe AllowanceModule (import-only accounts) or the delegation
+     * rail's active budget delegations (#1090). Read-only reporting — the
+     * on-chain state is the actual gate either way, this only says which
+     * mechanism a caller should read/derive from.
+     */
+    executionRail: 'legacy' | 'delegation';
+}
+interface HavenAllowance {
+    id: string;
+    tokenAddress: string;
+    tokenSymbol: string;
+    configuredAmount: string;
+    resetPeriodMin: number;
+    onchain: {
+        amount: string;
+        spent: string;
+        remaining: string;
+        effectiveSpent: string;
+        resetTimeMin: number;
+        lastResetMin: number;
+        nonce: number;
+        isResetPending: boolean;
+        /**
+         * Delegation rail only (#1319, provenance for #1145's fallback): true
+         * when `remaining` came from a live on-chain enforcer read, false when
+         * the read failed and `remaining` is the fallback full configured
+         * budget. Undefined on the legacy AllowanceModule rail, which has no
+         * fallback concept. Reporting only — the on-chain policy remains the
+         * actual spend gate either way.
+         */
+        remainingIsFromChain?: boolean;
+    };
+}
+interface HavenAllowanceSummary {
+    agentId: string;
+    safeAddress: string;
+    delegateAddress: string;
+    chainId: number;
+    allowances: HavenAllowance[];
+}
+/**
+ * Post-purchase allowance/budget summary attached to a settled x402 payment
+ * (#1310). Read-only reporting — the on-chain policy remains the actual
+ * spend gate either way, this only says what is left after the purchase.
+ *
+ * Deliberately the SAME rail-labeled field spelling as #1306's
+ * catalog-purchase preflight `allowance` block (never a new spelling),
+ * minus the preflight-only `sufficient` field: post-purchase reporting
+ * answers "what is left", not "was this purchase covered". Read through the
+ * exact same source as {@link HavenAllowanceSummary} / `haven_get_allowances`
+ * (`GET /machine-payments/allowances`; delegation-rail values are the #1090
+ * `deriveDelegationBudgets`-backed enforcer read, never `agent_allowances`),
+ * so this can never disagree with `haven_get_allowances` for the same
+ * fixture.
+ */
+interface PostPurchaseAllowanceSummary {
+    /** Which on-chain policy primitive gates this agent's spend (#1306 labeling). */
+    rail: 'legacy' | 'delegation';
+    /** Remaining atomic units, read through the same source as {@link HavenAllowance.onchain.remaining}. */
+    remaining_atomic: string;
+    /** Human-readable remaining, e.g. "4.96 USDC". Omitted when the token's decimals are unknown. */
+    remaining_display?: string;
+    token_symbol?: string;
+    token_address?: string;
+    /** Minutes — mirrors {@link HavenAllowance.resetPeriodMin} / the delegation's period. */
+    reset_period?: number;
+    source: 'allowance_module' | 'active_delegations';
+}
+/**
+ * Affirmative spend-readiness for the authenticated agent, derived from the raw
+ * agent status plus the remaining spend authority the backend reports per rail
+ * (the on-chain AllowanceModule on the legacy rail; the active budget
+ * delegation on the delegation rail — #1135):
+ * - `ready`         — active and at least one token has remaining spend authority.
+ * - `needs_approval`— active but no remaining spend authority to auto-spend.
+ *                     The over-budget outcome differs by rail: on the legacy
+ *                     AllowanceModule rail the payment is queued for the wallet
+ *                     owner to approve in Haven; on the delegation rail there is
+ *                     NO approval queue — an over-budget redemption reverts
+ *                     on-chain, so the owner must grant or raise the budget in
+ *                     Haven before the agent can pay.
+ * - `revoked`       — the agent's status is not `active`; nothing auto-executes.
+ *
+ * Note: a hard-paused/disabled credential is rejected by the API before this
+ * call returns, so it surfaces as an API error rather than `revoked`. `revoked`
+ * is reached when the request authenticates but the agent status is non-active.
+ *
+ * Wallet token balance is intentionally NOT folded in here: the on-chain
+ * remaining allowance is the gate Haven enforces, and insufficient wallet
+ * funding surfaces at pay time as INSUFFICIENT_FUNDS.
+ */
+type HavenAgentReadiness = 'ready' | 'needs_approval' | 'revoked';
+/** Compact, agent-facing per-token spend authority for the bootstrap summary. */
+interface HavenAgentAllowanceSummary {
+    tokenSymbol: string;
+    /** Live on-chain remaining allowance in atomic units. */
+    remainingAtomic: string;
+    /** Human-readable remaining, e.g. "4.96 USDC". */
+    remainingDisplay: string;
+    /** Configured allowance amount (atomic) the owner granted. */
+    configuredAmount: string;
+    resetPeriodMin: number;
+    isResetPending: boolean;
+}
+/**
+ * One-shot "am I ready?" bootstrap: identity + live spend authority + a
+ * readiness signal, so an agent can answer "who am I and can I pay right now"
+ * from a single call at session start. Superset of {@link HavenAgent}.
+ */
+interface HavenAgentSummary extends HavenAgent {
+    /**
+     * @deprecated Use {@link HavenAgentSummary.spend_authority_readiness} —
+     * same value, honest name. This signal covers hosted identity + on-chain
+     * spend authority ONLY; it says nothing about the LOCAL signer, which the
+     * hosted side cannot see (verify via a signer tool or connect --doctor).
+     * Kept as an alias; removal earliest after the next release train (#1590).
+     */
+    readiness: HavenAgentReadiness;
+    /**
+     * Spend-authority readiness: hosted identity + on-chain remaining spend
+     * authority. Deliberately named for what it covers — the LOCAL signer's
+     * availability is NOT included and must be verified separately (a signer
+     * tool call, or the connector's `--doctor`, whose exact command this build
+     * renders from `HAVEN_CONNECTOR_CHANNEL` — see `connector-channel.ts`).
+     */
+    spend_authority_readiness: HavenAgentReadiness;
+    allowances: HavenAgentAllowanceSummary[];
+}
+interface HavenPaymentReceipt {
+    id: string;
+    paymentId: string;
+    paymentIntentId?: string | null;
+    approvalRequestId?: string | null;
+    rail: string;
+    proofStatus: string;
+    txHash: string;
+    chainId: number;
+    resourceUrl: string;
+    merchantAddress: string | null;
+    payerAddress: string;
+    settlementAddress: string;
+    tokenSymbol: string;
+    tokenAddress: string;
+    amountRaw: string;
+    amount: string;
+    challengeId: string | null;
+    idempotencyKey: string | null;
+    challengePayload?: Record<string, unknown> | null;
+    selectedPayment?: Record<string, unknown> | null;
+    paymentProofHeaderName: string | null;
+    protocolReceiptHeaderName: string | null;
+    protocolReceiptPayload?: Record<string, unknown> | null;
+    merchantStatus: number | null;
+    confirmedAt: string | null;
+    createdAt: string;
+    updatedAt: string;
+}
+/**
+ * How long this SDK waits for an on-chain confirmation before it stops
+ * waiting (#1756).
+ *
+ * Lives here rather than in `client.ts` so the payment-confirmation poller
+ * and the delegate sweep share ONE number instead of forking it. The SDK's
+ * other chain waits are already bounded (`waitForFundingTx` at 30 s), so a
+ * fourth independently chosen literal is exactly the drift this constant
+ * exists to prevent.
+ */
+declare const DEFAULT_CONFIRMATION_TIMEOUT_MS = 90000;
+/**
+ * Whether a sweep transfer was observed to confirm (#1756).
+ *
+ * The distinction is the point: `unconfirmed` means the transfer was
+ * BROADCAST and may still land, which is neither success nor failure. It must
+ * never be collapsed into either — reporting a still-pending transaction as
+ * done, or as failed, are the same defect in opposite directions.
+ */
+type SweepConfirmation = 
+/** A receipt was observed. The funds are in the Safe. */
+'confirmed'
+/**
+ * Broadcast, but no receipt within `DEFAULT_CONFIRMATION_TIMEOUT_MS` (or the
+ * node returned no receipt). The transaction is still in the mempool and may
+ * mine at any time. `txHash` is the broadcast hash — check it on the
+ * explorer before re-running the sweep, and expect a re-run to find nothing
+ * stranded if it has since landed.
+ */
+ | 'unconfirmed';
+/** One transferred asset in a delegate sweep. */
+interface SweepEntry {
+    /** 'USDC' or 'ETH' */
+    asset: string;
+    /** Human-readable amount swept (e.g. "0.12") */
+    amount: string;
+    /** Atomic amount swept */
+    amountAtomic: string;
+    /**
+     * Transaction hash of the sweep transfer.
+     *
+     * The RECEIPT hash when `confirmation` is `confirmed`; the BROADCAST hash
+     * when it is `unconfirmed` — which is the whole reason the sweep returns
+     * instead of throwing on a deadline, since this hash is the only thing that
+     * lets a user recover the transfer by hand (#1756).
+     */
+    txHash: string;
+    /** Block explorer URL for the tx */
+    explorerUrl: string;
+    /**
+     * Did this transfer confirm on-chain within the deadline? (#1756)
+     *
+     * `unconfirmed` entries have MOVED NOTHING YET and may still move. Do not
+     * report a sweep as complete without checking this on every entry.
+     */
+    confirmation: SweepConfirmation;
+}
+/** Result of a `sweepDelegate()` call. */
+interface SweepResult {
+    /** Address funds were swept FROM */
+    fromAddress: string;
+    /** Address funds were swept TO (always the originating Safe) */
+    toAddress: string;
+    /** Chain the sweep occurred on */
+    chainId: number;
+    /** One entry per transferred asset. Empty when nothing was stranded. */
+    transfers: SweepEntry[];
+    /**
+     * True when ANY entry is `unconfirmed` — i.e. the sweep broadcast something
+     * it could not confirm within the deadline (#1756).
+     *
+     * Derived from `transfers`, and present anyway because the consumer most
+     * likely to misread this result is an LLM reading the JSON of the
+     * `haven_sweep_delegate` tool, which will otherwise see a populated
+     * `transfers` array and report the money as recovered.
+     */
+    unconfirmed: boolean;
+}
+type PaymentStateKind = 'payment_intent' | 'approval_request';
+interface AgentPaymentEnumSchema {
+    type: 'string';
+    enum: readonly string[];
+    description: string;
+    'x-enumDescriptions': Record<string, string>;
+}
+declare const AgentPaymentPhase: {
+    /** The agent must sign and submit the prepared payment before Haven can relay it. */
+    readonly AgentSignatureRequired: "agent_signature_required";
+    /** Haven has received the signed payment and the agent should poll for confirmation. */
+    readonly PaymentSubmitted: "payment_submitted";
+    /** The direct payment is confirmed; the agent does not need to do more for this payment id. */
+    readonly PaymentConfirmed: "payment_confirmed";
+    /**
+     * #2115: RETIRED wire value — no live rail produces it. It described the
+     * Safe rail's approval queue, which no longer exists. Kept so a stored value
+     * still typechecks; see `AgentPaymentPhaseDescriptions` below for the
+     * agent-visible wording, which this comment used to contradict.
+     */
+    readonly UserApprovalRequired: "user_approval_required";
+    /** #2115: RETIRED wire value — no live rail produces it. Stop and tell the user. */
+    readonly UserExecutionRequired: "user_execution_required";
+    /** #2115: RETIRED wire value — no live rail produces it. Stop and tell the user. */
+    readonly WaitingForAdditionalApprovals: "waiting_for_additional_approvals";
+    /** The Haven funding leg was sent; the agent can continue the merchant/protocol leg. */
+    readonly FundingSent: "funding_sent";
+    /** The payment was rejected and cannot proceed; the agent should stop and tell the user. */
+    readonly Rejected: "rejected";
+    /** The payment expired before completion. */
+    readonly Expired: "expired";
+    /** Haven could not complete the payment; the agent should stop and surface the failure. */
+    readonly Failed: "failed";
+    /**
+     * Pre-flight check determined the delegate's existing balance plus the
+     * remaining on-chain budget cannot cover the requested amount, so no
+     * payment intent was created. The account must be funded or the agent's
+     * budget raised before retrying — #2115: the old wording contrasted this
+     * with `UserApprovalRequired` as if that were a live alternative, and named
+     * the retired rail's Safe and per-token allowance as the fix.
+     */
+    readonly InsufficientFunds: "insufficient_funds";
+    /**
+     * Haven's funding leg (account → delegate, the #946 EIP-3009 bridge)
+     * confirmed on-chain, but the merchant rejected the x402 retry. The delegate
+     * wallet may hold stranded USDC that was never settled to the merchant. The
+     * agent should stop, tell the user, and wait for the sweep flow to reclaim
+     * the funds.
+     */
+    readonly FundedButUnsettled: "funded_but_unsettled";
+};
+type AgentPaymentPhase = (typeof AgentPaymentPhase)[keyof typeof AgentPaymentPhase];
+declare const AgentPaymentNextAction: {
+    /** Sign with the delegate key and submit the payment to Haven. */
+    readonly SignAndSubmitPayment: "sign_and_submit_payment";
+    /** Poll getPaymentStatus later using this payment id. */
+    readonly CheckStatusLater: "check_status_later";
+    /** No further agent action is required for this payment id. */
+    readonly None: "none";
+    /**
+     * #2115: RETIRED wire value — no live rail produces it and nothing maps to
+     * it. Stop and tell the user rather than polling; no approval will arrive.
+     */
+    readonly WaitForUserApproval: "wait_for_user_approval";
+    /** #2115: RETIRED wire value — no live rail produces it. Stop and tell the user rather than polling. */
+    readonly WaitForUserToCompletePayment: "wait_for_user_to_complete_payment";
+    /** Resume this payment id and retry the original x402 request with the merchant payment header. */
+    readonly RetryOriginalX402Request: "retry_original_x402_request";
+    /** Stop retrying this payment and tell the user what happened. */
+    readonly StopAndTellUser: "stop_and_tell_user";
+    /** Ask again only if the user still wants the payment after expiry. */
+    readonly RequestAgainIfUserStillWantsIt: "request_again_if_user_still_wants_it";
+    /** #1307: retry the SAME tool call, supplying the explicit context fields the server could not rehydrate. */
+    readonly RetryWithExplicitContext: "retry_with_explicit_context";
+    /**
+     * The x402 funding/quote window expired. Re-quote the same logical merchant
+     * operation with the same idempotency key to stay double-charge-safe.
+     */
+    readonly PaymentWindowExpired: "payment_window_expired";
+    /**
+     * Stop and tell the user that the originating Safe needs to be funded or
+     * the agent's per-token allowance needs to be raised before the payment
+     * can succeed. A user approval will not fix this state on its own.
+     */
+    readonly FundSafeOrRaiseAllowance: "fund_safe_or_raise_allowance";
+    /**
+     * The delegate wallet may hold funds that were sent from the Safe but never
+     * settled to the merchant. The wallet owner should initiate a sweep to
+     * return those funds to the originating Safe.
+     */
+    readonly SweepStrandedFunds: "sweep_stranded_funds";
+};
+type AgentPaymentNextAction = (typeof AgentPaymentNextAction)[keyof typeof AgentPaymentNextAction];
+declare const AgentPaymentFailureCode: {
+    /** A merchant-authoritative x402 price exceeds the caller's pre-funding max_amount cap. */
+    readonly PriceExceedsMax: "PRICE_EXCEEDS_MAX";
+    /** The x402 funding/quote window expired before the signer or hosted settle step could finish. */
+    readonly PaymentWindowExpired: "PAYMENT_WINDOW_EXPIRED";
+    /** The Haven funding leg succeeded, but the merchant rejected the paid retry. */
+    readonly MerchantRejectedAfterFunding: "MERCHANT_REJECTED_AFTER_FUNDING";
+    /** #1300 review: funding is on-chain but the merchant never ANSWERED the
+     *  paid retry within the timeout. NOT proof of rejection — the merchant
+     *  holds a valid EIP-3009 authorization and may still settle late, so the
+     *  guidance is verify-then-sweep, never blind sweep. */
+    readonly MerchantUnresponsiveAfterFunding: "MERCHANT_UNRESPONSIVE_AFTER_FUNDING";
+    /**
+     * #1307: the caller omitted merchant_url/tool_name (asking Haven to
+     * rehydrate the stored MCP merchant-call context by payment_id), but no
+     * usable context was stored for this intent — either it was never an
+     * MCP-tool quote, or the stored context is incomplete. The fallback is
+     * mechanical: re-send merchant_url, tool_name, arguments, and
+     * mcp_transport explicitly (the version-skew path).
+     */
+    readonly MerchantCallContextUnavailable: "MERCHANT_CALL_CONTEXT_UNAVAILABLE";
+    /**
+     * #1351: the caller supplied BOTH the atomic `max_amount` and the
+     * human-denominated `max_amount_human` cap for one purchase. Haven refuses
+     * to guess which the user meant — the two differ by a factor of 10^decimals,
+     * so picking wrong is exactly the silent-overspend this cap exists to
+     * prevent. Rejected before any merchant probe, funding intent, or signature.
+     */
+    readonly AmbiguousMaxAmount: "AMBIGUOUS_MAX_AMOUNT";
+    /**
+     * #1351: a human-denominated cap was supplied, but it cannot be converted to
+     * atomic units against THIS quote — either the quote's asset has no known
+     * decimals on its network, or the cap carries more fraction digits than the
+     * asset can represent (truncating it would silently change the user's cap).
+     * The fallback is the exact atomic `max_amount`.
+     */
+    readonly MaxAmountUnconvertible: "MAX_AMOUNT_UNCONVERTIBLE";
+};
+type AgentPaymentFailureCode = (typeof AgentPaymentFailureCode)[keyof typeof AgentPaymentFailureCode];
+/**
+ * Stable rail identifier carried on Haven agent payment responses and resume
+ * state.
+ *
+ * Two layers of vocabulary share this enum because both reach the wire:
+ *
+ *   - **Categorical rails** identify the rail family and are used as the
+ *     `PaymentResumeState` discriminator: `direct`, `x402` (`mpp` remains a
+ *     valid categorical VALUE on historical status reads, but #1328 retired
+ *     the `MppResumeState` variant that used to carry it — the mpp_demo
+ *     client resume flow no longer exists).
+ *   - **Granular rails** identify the specific protocol the backend persists
+ *     and returns on response bodies: `mpp_demo`, `mpp_crypto`,
+ *     `stripe_deposit`, `spt`. `x402` doubles as both categorical and
+ *     granular.
+ *
+ * Consumers reading the top-level `rail` field on a payment status response
+ * should treat any `mpp*` value as the MPP family — this still applies to
+ * historical `mpp_demo` rows, which remain readable.
+ */
+declare const AgentPaymentRail: {
+    /** Standard Haven payment from the user's Safe through an approved delegate allowance. */
+    readonly Direct: "direct";
+    /** x402 HTTP 402 payment flow with a Haven funding leg and merchant retry leg. */
+    readonly X402: "x402";
+    /** Machine Payment Protocol family — categorical value used as a resume-state discriminator. */
+    readonly Mpp: "mpp";
+    /** Haven internal MPP demo rail. Not for production traffic. */
+    readonly MppDemo: "mpp_demo";
+    /** Crypto-settled MPP rail. */
+    readonly MppCrypto: "mpp_crypto";
+    /** Stripe-deposit-backed MPP rail. */
+    readonly StripeDeposit: "stripe_deposit";
+    /** Stripe Payment Token MPP rail. */
+    readonly Spt: "spt";
+};
+type AgentPaymentRail = (typeof AgentPaymentRail)[keyof typeof AgentPaymentRail];
+type PaymentPhase = AgentPaymentPhase;
+type PaymentNextAction = AgentPaymentNextAction;
+declare const AGENT_PAYMENT_PHASE_VALUES: ("rejected" | "expired" | "failed" | "agent_signature_required" | "payment_submitted" | "payment_confirmed" | "user_approval_required" | "user_execution_required" | "waiting_for_additional_approvals" | "funding_sent" | "insufficient_funds" | "funded_but_unsettled")[];
+declare const AGENT_PAYMENT_NEXT_ACTION_VALUES: ("sign_and_submit_payment" | "check_status_later" | "none" | "wait_for_user_approval" | "wait_for_user_to_complete_payment" | "retry_original_x402_request" | "stop_and_tell_user" | "request_again_if_user_still_wants_it" | "retry_with_explicit_context" | "payment_window_expired" | "fund_safe_or_raise_allowance" | "sweep_stranded_funds")[];
+declare const AGENT_PAYMENT_FAILURE_CODE_VALUES: ("PRICE_EXCEEDS_MAX" | "PAYMENT_WINDOW_EXPIRED" | "MERCHANT_REJECTED_AFTER_FUNDING" | "MERCHANT_UNRESPONSIVE_AFTER_FUNDING" | "MERCHANT_CALL_CONTEXT_UNAVAILABLE" | "AMBIGUOUS_MAX_AMOUNT" | "MAX_AMOUNT_UNCONVERTIBLE")[];
+declare const AGENT_PAYMENT_RAIL_VALUES: ("x402" | "mpp_demo" | "mpp_crypto" | "stripe_deposit" | "spt" | "direct" | "mpp")[];
+declare const AgentPaymentPhaseDescriptions: Record<AgentPaymentPhase, string>;
+declare const AgentPaymentNextActionDescriptions: Record<AgentPaymentNextAction, string>;
+declare const AgentPaymentFailureCodeDescriptions: Record<AgentPaymentFailureCode, string>;
+/**
+ * #1308: machine-readable warning codes carried in the `warnings` array on
+ * x402 MCP tool responses. Warnings are ADVISORY — they never replace a
+ * refusal, and existing failure codes stay authoritative for errors. The
+ * legacy `cap_warning` string field is kept for compatibility; the structured
+ * entry carries the same message under MISSING_MAX_AMOUNT.
+ */
+declare const AgentPaymentWarningCode: {
+    /** No max_amount cap was supplied — the live quoted price was accepted as-is. */
+    readonly MissingMaxAmount: "MISSING_MAX_AMOUNT";
+    /** The signing window closes soon; sign promptly or re-quote with the same idempotency key. */
+    readonly QuoteExpiresSoon: "QUOTE_EXPIRES_SOON";
+    /** The merchant URL was resolved via discovery — pass the RESOLVED url forward. */
+    readonly MerchantUrlDiscovered: "MERCHANT_URL_DISCOVERED";
+    /**
+     * #1306: the catalog's last-verified price_atomic differs from the LIVE
+     * merchant quote for a guided catalog purchase. The catalog price is only
+     * ever indicative; the live quote in the same response is authoritative.
+     */
+    readonly CatalogPriceDiffers: "CATALOG_PRICE_DIFFERS";
+    /**
+     * #1306: the rail-aware allowance/budget pre-check could not be read (RPC
+     * failure, etc). `sufficient` is reported as null rather than a fabricated
+     * true/false — the on-chain policy remains the actual gate either way.
+     */
+    readonly AllowanceCheckUnavailable: "ALLOWANCE_CHECK_UNAVAILABLE";
+    /**
+     * #1319: the delegation-rail read itself SUCCEEDED, but the remaining
+     * figure it returned is the #1145 fallback (the full configured budget)
+     * rather than a live ERC20PeriodTransferEnforcer read — `sufficient` is a
+     * real true/false, just computed from an optimistic number. Distinct from
+     * {@link AgentPaymentWarningCode.AllowanceCheckUnavailable}, which fires
+     * when the read failed outright and `sufficient` degrades to null. The
+     * on-chain policy re-checks at redemption either way; this only says the
+     * guidance shown here may be optimistic.
+     */
+    readonly AllowanceReadOptimistic: "ALLOWANCE_READ_OPTIMISTIC";
+};
+type AgentPaymentWarningCode = (typeof AgentPaymentWarningCode)[keyof typeof AgentPaymentWarningCode];
+interface AgentPaymentWarning {
+    code: AgentPaymentWarningCode;
+    message: string;
+}
+/**
+ * #1308: the structured next-step contract on x402 MCP tool responses. It
+ * EXTENDS the existing taxonomy — `next_action` values come from
+ * AgentPaymentNextAction, never a parallel vocabulary. `next_arguments`
+ * carries the small, literally-usable arguments; bulky pass-through fields
+ * (payment_required) are named in `reason` and taken from the SAME response.
+ */
+interface AgentNextStep {
+    next_action: AgentPaymentNextAction;
+    /** Fully-qualified tool name for the next call, when one exists. */
+    next_tool?: string;
+    /** Small literal arguments for next_tool. Bulky fields are referenced by reason. */
+    next_arguments?: Record<string, unknown>;
+    /** False when the agent should stop and involve the user before continuing. */
+    safe_to_continue: boolean;
+    reason: string;
+}
+/**
+ * #1349: compact, Haven-generated reporting evidence for a completed x402
+ * merchant purchase. `status`, money fields, merchant endpoint/address, and
+ * funding transaction come from Haven payment state; `product` and
+ * `invoice_id` are optional merchant-supplied display metadata. The raw
+ * merchant result remains separate evidence and MUST NOT be used to infer
+ * settlement status.
+ */
+interface AgentPurchaseSummary {
+    /** Set only after Haven has completed the funding and merchant-settlement flow. */
+    status: 'settled';
+    product: string | null;
+    amount: string | null;
+    amount_atomic: string | null;
+    asset: string | null;
+    network: string | null;
+    merchant: {
+        address: string | null;
+        resource_url: string | null;
+    };
+    /** Merchant-supplied identifier, or null when the merchant did not supply one. */
+    invoice_id: string | null;
+    funding_tx_hash: string | null;
+    /** Optional merchant receipt reference parsed from PAYMENT-RESPONSE; not Haven settlement proof. */
+    settlement_tx_hash: string | null;
+    /** Same read-only allowance block returned at the top level, or null when unavailable. */
+    allowance: PostPurchaseAllowanceSummary | null;
+}
+/** #1308: compact reporting summary — what the agent tells the user. */
+interface AgentPaymentSummary {
+    payment_id: string;
+    status: string;
+    amount?: string;
+    amount_atomic?: string;
+    token?: string;
+    network?: string;
+    expires_at?: string;
+    product?: string;
+    /**
+     * Default reporting contract for a successful `haven_settle_mcp_tool` call.
+     * The merchant's raw `result` remains available separately as advanced
+     * evidence; do not parse it to determine whether a payment settled.
+     */
+    purchase_summary?: AgentPurchaseSummary;
+}
+declare const AgentPaymentRailDescriptions: Record<AgentPaymentRail, string>;
+declare const AgentPaymentPhaseSchema: AgentPaymentEnumSchema;
+declare const AgentPaymentNextActionSchema: AgentPaymentEnumSchema;
+declare const AgentPaymentFailureCodeSchema: AgentPaymentEnumSchema;
+declare const AgentPaymentRailSchema: AgentPaymentEnumSchema;
+interface PaymentStatusResult {
+    paymentId: string;
+    kind: PaymentStateKind;
+    rail: string;
+    status: PaymentStatus | string;
+    phase: PaymentPhase;
+    nextAction: PaymentNextAction;
+    amount: string;
+    token: string;
+    resourceUrl: string | null;
+    merchantAddress: string | null;
+    /** Delegate EOA captured on the payment intent when it was created. */
+    payerAddress?: string | null;
+    txHash: string | null;
+    expiresAt: string;
+    chainId: number;
+    message: string;
+    /** Platform fee surfaced so it's never silently collected (#386). */
+    fee?: PaymentFee | null;
+    amountAtomic?: string | null;
+    asset?: string | null;
+    network?: string | null;
+    description?: string | null;
+    idempotencyKey?: string | null;
+    x402?: {
+        amountAtomic: string | null;
+        asset: string | null;
+        network: string | null;
+        resourceUrl: string | null;
+        merchantAddress: string | null;
+        description: string | null;
+        idempotencyKey: string | null;
+    };
+    mpp?: {
+        amountAtomic: string | null;
+        asset: string | null;
+        network: string | null;
+        resourceUrl: string | null;
+        merchantAddress: string | null;
+        description: string | null;
+        idempotencyKey: string | null;
+        challengeId: string | null;
+    };
+}
+/**
+ * Result of an erc7710 direct settlement (#1454).
+ *
+ * Deliberately NOT an `X402Receipt`. A 3009 receipt describes a completed
+ * two-leg payment — funding tx included — whereas here nothing has settled yet
+ * when this returns: the merchant redeems the delegation chain when the caller
+ * retries with the header. Reusing the receipt type would let a caller read
+ * `txHash` as "paid" on a payment that has not moved a cent.
+ */
+interface X402Erc7710Settlement {
+    paymentId: string;
+    /**
+     * Pass verbatim as the `PAYMENT-SIGNATURE` header on the merchant retry —
+     * that name ALONE. erc7710 is always x402 v2, and this header carries the
+     * delegation chain, so also sending the legacy `X-PAYMENT` overflows the
+     * merchant's header limit (HTTP 431, #2341).
+     */
+    paymentHeader: string;
+    /** The merchant address the child delegation is pinned to. */
+    merchantPayTo: string;
+    amountAtomic: string;
+    asset: string;
+    network: string;
+    /** Facilitators the child is redeemable by, when the merchant advertised any. */
+    facilitatorAddresses: string[] | null;
+}
+/** @internal */
+/** One payable service in Haven's merchant catalog (epic #1717). */
+interface HavenCatalogEntry {
+    id: string;
+    name: string;
+    description: string;
+    category: string;
+    resourceUrl: string;
+    rail: 'x402' | 'mpp';
+    protocol: 'http' | 'mcp';
+    toolName: string | null;
+    toolArguments: Record<string, unknown> | null;
+    priceDisplay: string | null;
+    priceAtomic: string | null;
+    asset: string | null;
+    network: string | null;
+    status: 'active' | 'degraded' | 'delisted';
+    verifiedAt: string | null;
+    /**
+     * Where the entry came from. `operator` = curated in migrations/scripts
+     * (the operator vouches; no verification badges). `ingestion` = submitted
+     * through the Verified Payable Directory and passed domain-ownership proof
+     * plus the read-only quote probe.
+     */
+    source: 'operator' | 'ingestion';
+    /** True only for `ingestion` entries. See the epic's trust claim (never merchant honesty or quality). */
+    domainVerified: boolean;
+    verifiedPayable: boolean;
+}
+/** @internal */
+/** Wire shape of POST /catalog/submit (#1717, #1716). */
+interface CatalogSubmissionAccepted {
+    id: string;
+    verify_token: string;
+    status: 'submitted' | 'ownership_verified' | 'verified_payable';
+}
+/** @internal Client-facing submission handle. */
+interface HavenCatalogSubmission {
+    id: string;
+    verifyToken: string;
+    status: 'submitted' | 'ownership_verified' | 'verified_payable';
+}
+declare class HavenError extends Error {
+    readonly code: string;
+    readonly statusCode?: number | undefined;
+    readonly paymentId?: string | undefined;
+    constructor(message: string, code: string, statusCode?: number | undefined, paymentId?: string | undefined);
+}
+declare class HavenApiError extends HavenError {
+    readonly body?: unknown | undefined;
+    constructor(message: string, statusCode: number, body?: unknown | undefined, paymentId?: string);
+}
+/**
+ * #1300: quoteX402 hit a URL that answered something other than 402 — the
+ * typed form of "this is not the x402 endpoint". Exists so consumers (the
+ * hosted MCP's #1271 discovery trigger) can key on a class instead of
+ * message text.
+ */
+/**
+ * #1300: a merchant-facing fetch hit the client-side merchantTimeout. Typed
+ * so consumers can distinguish "merchant never answered" from a real HTTP
+ * error response — the funded-retry path routes this to verify-then-sweep
+ * guidance instead of a bare 504.
+ */
+declare class MerchantTimeoutError extends HavenApiError {
+    readonly merchantErrorCode: "merchant_timeout";
+    constructor(message: string);
+}
+declare class X402UnexpectedStatusError extends HavenApiError {
+    readonly x402ErrorCode: "unexpected_non_402_status";
+    constructor(message: string, statusCode: number);
+}
+/**
+ * #1521: the idempotency key resolved to a payment that has already settled,
+ * and the delegate can no longer fund a fresh authorization for it.
+ *
+ * This is the typed form of "you already bought this". It exists because the
+ * alternative was indefensible: the SDK used to mint a new EIP-3009
+ * authorization against the spent delegate and hand it back paired with the
+ * ORIGINAL payment's `txHash`, so the caller learned what had happened only
+ * from a merchant-side balance error that reads identically to a broken
+ * payment rail.
+ *
+ * `receipt` is the ORIGINAL payment — a real receipt for real settled funds,
+ * deliberately carrying no `paymentHeader`, because any header minted here
+ * would be exactly the unfundable artifact this error replaces.
+ */
+declare class X402AlreadySettledError extends HavenApiError {
+    readonly receipt: X402Receipt;
+    /**
+     * `settled` — the delegate was checked on-chain and cannot fund a fresh
+     * authorization, so this payment demonstrably completed.
+     * `unverifiable` — no `chainRpcs` entry for the chain, so fundability
+     * could not be established either way. Same refusal, weaker claim; say
+     * which, rather than assert what was not checked.
+     */
+    readonly basis: 'settled' | 'unverifiable';
+    readonly x402ErrorCode: "already_settled";
+    constructor(message: string, receipt: X402Receipt, 
+    /**
+     * `settled` — the delegate was checked on-chain and cannot fund a fresh
+     * authorization, so this payment demonstrably completed.
+     * `unverifiable` — no `chainRpcs` entry for the chain, so fundability
+     * could not be established either way. Same refusal, weaker claim; say
+     * which, rather than assert what was not checked.
+     */
+    basis: 'settled' | 'unverifiable');
+}
+declare class HavenPaymentStateError extends HavenApiError {
+    readonly state: PaymentStatusResult;
+    resumeState?: X402ResumeState;
+    constructor(message: string, statusCode: number, state: PaymentStatusResult, body?: unknown);
+    get status(): string;
+    get phase(): PaymentPhase;
+    get nextAction(): PaymentNextAction;
+}
+declare class HavenSigningError extends HavenError {
+    constructor(message: string);
+}
+/**
+ * Refusal codes the local signer returns when it does not recognise the
+ * VERSION of a Haven-signed binding it was asked to sign (#1309). Distinct
+ * from `AgentPaymentFailureCode`: these describe a **signer capability**
+ * problem (this install cannot evaluate what Haven sent), not a payment-domain
+ * outcome, and they never reach the backend's REST/OpenAPI surface — only the
+ * local signer's own MCP tool responses (`haven_sign` / `haven_sign_x402` /
+ * `haven_sign_sweep_delegate`). That is also why this pair does not go through
+ * the `AgentPaymentFailureCode` four-gate (sdk → backend mirror → spec →
+ * api-types): there is no backend mirror to keep in sync with.
+ */
+declare const SignerRefusalCode: {
+    /** `SUPPORTED_X402_EXPECTED_VERSIONS` in `@haven_ai/signer` does not include the received version. */
+    readonly UnsupportedExpectedContextVersion: "UNSUPPORTED_EXPECTED_CONTEXT_VERSION";
+    /** `SUPPORTED_SWEEP_BINDING_VERSIONS` in `@haven_ai/signer` does not include the received version. */
+    readonly UnsupportedSweepBindingVersion: "UNSUPPORTED_SWEEP_BINDING_VERSION";
+};
+type SignerRefusalCode = (typeof SignerRefusalCode)[keyof typeof SignerRefusalCode];
+/**
+ * Canonical recovery guidance for a stale local signer (#1309) — the ONE
+ * string both the signer's structured refusal (`fallback` field, carried by
+ * `HavenUnsupportedSignerVersionError`) and the hosted quote's advisory
+ * `signer_compatibility.fallback` (#1155) render, so an agent that meets
+ * either surface is told the identical fix. A second hand-maintained copy of
+ * this sentence is exactly how the two surfaces could start disagreeing about
+ * what to do.
+ */
+declare function signerUpdateFallback(channel?: string): string;
+/**
+ * The same sentence rendered for THIS build's channel (#2423). Every existing
+ * consumer keeps importing this constant and keeps getting a string; the only
+ * thing that moved is that `alpha` is no longer typed into it.
+ *
+ * The hosted MCP server is the one caller that does NOT use this constant: it
+ * is deployed rather than published, so it renders `signerUpdateFallback()`
+ * with the channel its own environment names.
+ */
+declare const SIGNER_UPDATE_FALLBACK: string;
+/**
+ * Thrown by the local signer when a Haven-signed binding (x402 expected
+ * context or sweep authorization) carries a version outside what this signer
+ * install enforces (#1143, structured as #1309). Machine-readable: `code`,
+ * `supportedVersions`, and `receivedVersion` are DERIVED from the signer's own
+ * `SUPPORTED_X402_EXPECTED_VERSIONS` / `SUPPORTED_SWEEP_BINDING_VERSIONS`
+ * constants at the throw site, never a second literal — see
+ * `assertSupportedBindingVersion` in `@haven_ai/signer`.
+ *
+ * This narrows HOW the refusal is reported. It does not weaken it: nothing is
+ * signed either way, and the version stays inside the Haven-signed binding
+ * message (callers must not "fix" a mismatch by rewriting it).
+ */
+declare class HavenUnsupportedSignerVersionError extends HavenError {
+    readonly supportedVersions: readonly number[];
+    readonly receivedVersion: number;
+    readonly fallback: string;
+    constructor(message: string, code: SignerRefusalCode, supportedVersions: readonly number[], receivedVersion: number, fallback: string);
+}
+declare class HavenTimeoutError extends HavenError {
+    constructor(paymentId: string);
+}
+
+/**
+ * Gasless delegate-sweep primitives — the single source of truth shared by the
+ * edge signer (which signs) and the Haven backend (which relays).
+ *
+ * A stranded delegate EOA holds USDC but no ETH, so a raw ERC-20 transfer can't
+ * pay for its own gas. Instead the delegate signs an *off-chain* EIP-3009
+ * `TransferWithAuthorization` and the Haven relayer submits it on-chain and pays
+ * gas. The relayer is only a gas payer: it holds no allowance and is never a
+ * spender, so a relayer compromise cannot move user funds.
+ *
+ * Framework-neutral on purpose: `buildSweepTypedData` returns a plain
+ * `{ domain, types, primaryType, message }` that both viem
+ * (`signTypedData`/`recoverTypedDataAddress`) and ethers v6
+ * (`signTypedData`/`verifyTypedData`) accept, so the signer (viem) and backend
+ * (ethers) stay in lockstep without sharing a crypto library.
+ */
+/** Base mainnet. The only chain Haven sweeps today. */
+declare const SWEEP_BASE_CHAIN_ID = 8453;
+/** Base Sepolia testnet — used by the dev environment / QA harness. */
+declare const SWEEP_BASE_SEPOLIA_CHAIN_ID = 84532;
+/** Canonical Circle USDC on Base (FiatTokenV2_2). */
+declare const SWEEP_BASE_USDC_ADDRESS = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913";
+/** Circle's canonical Base Sepolia testnet USDC. */
+declare const SWEEP_BASE_SEPOLIA_USDC_ADDRESS = "0x036CbD53842c5426634e7929541eC2318f3dCF7e";
+/** True when the gasless sweep supports a chain (its USDC domain + address are known). */
+declare function isSweepableChain(chainId: number): boolean;
+/** EIP-712 `TransferWithAuthorization` struct, per EIP-3009. */
+declare const TRANSFER_WITH_AUTHORIZATION_TYPES: {
+    readonly TransferWithAuthorization: readonly [{
+        readonly name: "from";
+        readonly type: "address";
+    }, {
+        readonly name: "to";
+        readonly type: "address";
+    }, {
+        readonly name: "value";
+        readonly type: "uint256";
+    }, {
+        readonly name: "validAfter";
+        readonly type: "uint256";
+    }, {
+        readonly name: "validBefore";
+        readonly type: "uint256";
+    }, {
+        readonly name: "nonce";
+        readonly type: "bytes32";
+    }];
+};
+interface SweepEip712Domain {
+    name: string;
+    version: string;
+    chainId: number;
+    verifyingContract: string;
+}
+/**
+ * A fully-specified EIP-3009 authorization. All amounts/times are decimal
+ * strings (JSON-safe) and `nonce` is a 0x-prefixed 32-byte hex value. `token`
+ * and `chainId` are carried explicitly so the signer can assert they are
+ * canonical before signing.
+ */
+interface SweepAuthorization {
+    /** Delegate EOA the funds are swept FROM. */
+    from: string;
+    /** Originating Safe the funds are swept TO. */
+    to: string;
+    /** Atomic USDC amount (decimal string). */
+    value: string;
+    /** Unix seconds the authorization becomes valid (decimal string, usually "0"). */
+    validAfter: string;
+    /** Unix seconds the authorization expires (decimal string). */
+    validBefore: string;
+    /** Random 0x-prefixed 32-byte hex nonce. */
+    nonce: string;
+    /** USDC contract address. */
+    token: string;
+    /** Chain id (8453 today). */
+    chainId: number;
+}
+/**
+ * Haven's signature over the sweep authorization context, signed with the same
+ * binding key the x402 expected-context uses. Lets the edge signer verify the
+ * authorization actually came from Haven (and wasn't crafted by a compromised
+ * hosted server pointing `to` at an attacker) before it signs.
+ */
+interface SweepExpectedAuth {
+    /**
+     * Currently always 1. Typed as `number` for the same reason as
+     * `X402ExpectedAuth.version` (#1143): it is inbound, so a stale signer must be
+     * able to *receive* an unknown version in order to report it. The signer's
+     * `SUPPORTED_SWEEP_BINDING_VERSIONS` is the authority on what it will sign.
+     */
+    version: number;
+    message: string;
+    signature: string;
+    signer: string;
+}
+/** What `POST /machine-payments/sweep/prepare` returns when funds are stranded. */
+interface SweepPreparation {
+    authorization: SweepAuthorization;
+    expectedAuth: SweepExpectedAuth;
+}
+/** Wire response from `POST /machine-payments/sweep/prepare` (snake_case). */
+interface SweepPrepareResponse {
+    /** Present and true when the delegate holds nothing to recover. */
+    nothing_stranded?: boolean;
+    /**
+     * Present and true when the stranded balance is below the sweep floor (#700):
+     * it is left on the delegate as dust rather than recovered, because the gas to
+     * sweep it would exceed its value. `min_usdc` carries the configured floor. No
+     * `authorization` is built.
+     */
+    below_min?: boolean;
+    min_usdc?: string;
+    /** The authorization to sign — absent when nothing is stranded or below the floor. */
+    authorization?: SweepAuthorization;
+    /** Haven's binding over the authorization — absent when nothing is stranded. */
+    expected_auth?: SweepExpectedAuth;
+    asset?: string;
+    amount?: string;
+    amount_atomic?: string;
+    chain_id: number;
+    sign_instructions?: string;
+    message?: string;
+}
+/** Wire response from `POST /machine-payments/sweep/submit` (snake_case). */
+interface SweepSubmitResponse {
+    tx_hash: string;
+    asset: string;
+    amount: string;
+    amount_atomic: string;
+    from_address: string;
+    to_address: string;
+    chain_id: number;
+    explorer_url: string;
+    idempotent_replay?: boolean;
+}
+/** Result of a submitted gasless sweep. */
+interface SweepSubmitResult {
+    txHash: string;
+    amount: string;
+    amountAtomic: string;
+    asset: string;
+    fromAddress: string;
+    toAddress: string;
+    chainId: number;
+    explorerUrl: string;
+}
+interface SweepTypedData {
+    domain: SweepEip712Domain;
+    types: typeof TRANSFER_WITH_AUTHORIZATION_TYPES;
+    primaryType: 'TransferWithAuthorization';
+    message: {
+        from: string;
+        to: string;
+        value: bigint;
+        validAfter: bigint;
+        validBefore: bigint;
+        nonce: string;
+    };
+}
+/** Resolve the canonical USDC contract for a sweepable chain, or throw. */
+declare function sweepUsdcAddress(chainId: number): string;
+/** Resolve the USDC EIP-712 domain for a sweepable chain, or throw. */
+declare function sweepUsdcDomain(chainId: number): SweepEip712Domain;
+/**
+ * Build the EIP-712 typed data for an authorization, validating that the token
+ * and chain are canonical (the domain's `verifyingContract` must match the
+ * authorization's `token`). Returns bigint-valued fields so both viem and
+ * ethers v6 sign/recover identically.
+ */
+declare function buildSweepTypedData(auth: SweepAuthorization): SweepTypedData;
+/**
+ * Canonical, deterministic string the backend signs and the signer re-derives
+ * for the authorization binding. The `Haven sweep authorization v1` namespace
+ * (and `kind`) is distinct from the x402 expected-context namespace so an x402
+ * binding can never be replayed as a sweep authorization even though they share
+ * a signing key.
+ */
+declare function buildSweepAuthorizationMessage(auth: SweepAuthorization): string;
+
+/**
+ * Merchant delivery and the evidence trail behind it (#1620, epic #1613).
+ *
+ * Where `mcp-merchant-transport.ts` (#1616) owns the wire — timeouts,
+ * sessions, SSE framing — this module owns what has to be TRUE around a
+ * merchant call once a payment exists: which wallet the merchant should see,
+ * what the payment's live state permits, and what gets written down
+ * afterwards.
+ *
+ * The reporting is deliberately best-effort and deliberately asymmetric. A
+ * merchant that REJECTS a retry after Haven already moved money is a
+ * reconciliation event and is recorded as one; a merchant that accepts is
+ * evidence, plus its own receipt when it offers one. Neither write may ever
+ * change the caller-visible outcome — the resource is already paid for, and
+ * an exception thrown from bookkeeping would turn a completed payment into a
+ * reported failure. That is why every one of these swallows.
+ *
+ * Scheme-neutral by construction: it is handed a receipt or a payment id and
+ * never asks how the money moved, which is what lets the #1508 no-funding-leg
+ * path through the same door as the 3009 path.
+ *
+ * Internal to `HavenClient`. Exported for direct tests and composition only.
+ */
+/** #2292: what an agent says a merchant answered to a retry Haven did not make. */
+type X402MerchantOutcome = 'accepted' | 'rejected';
+/** #2292: what Haven wrote down for such a report. */
+interface X402MerchantOutcomeReport {
+    paymentId: string;
+    outcome: X402MerchantOutcome;
+    /** Haven's own funding tx for this payment — the anchor, never caller-supplied. */
+    txHash: string;
+    /** Haven's own recorded resource URL — likewise never caller-supplied. */
+    resourceUrl: string;
+    recorded: 'reconciliation_event' | 'evidence';
+}
+
+declare class HavenClient {
+    private readonly delegateKey;
+    private readonly havenApi;
+    private readonly accountReads;
+    private readonly delegateSweep;
+    private readonly x402Wallet;
+    private readonly merchantTransport;
+    private readonly confirmationTimeout;
+    private readonly pollingInterval;
+    private readonly chainRpcs;
+    private readonly inFlightX402;
+    /**
+     * The EIP-3009 funding-leg lifecycle (#1618). The facade holds a reference
+     * and delegates; it does not reimplement any of it.
+     */
+    private readonly fundingLeg;
+    /**
+     * The erc7710 direct-settlement lifecycle (#1619). Separate from the funding
+     * leg on purpose: this scheme has no funding leg to share.
+     */
+    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);
+    /**
+     * Run `fn` with extra Haven-API headers scoped to the async work it
+     * performs. Used by the MCP server to tag every Haven API request that
+     * a single tool dispatch makes with `X-Haven-MCP-Tool: <name>` so the
+     * backend can write an audit-log row attributing the call.
+     *
+     * The headers are held in an `AsyncLocalStorage` so overlapping
+     * dispatches do not leak headers into each other's requests. The store
+     * inherits across `await` boundaries, so any Haven API call made while
+     * `fn` is awaiting will pick up the right headers.
+     *
+     * Has no effect on outbound merchant requests (x402 / MPP) — those
+     * never go through the internal `request<T>` path that reads the
+     * context.
+     */
+    withRequestContext<T>(headers: Record<string, string>, fn: () => Promise<T>): Promise<T>;
+    /**
+     * Send a payment in one call.
+     *
+     * Creates the intent, signs the hash, submits the signature,
+     * and polls until confirmed (or throws on failure/timeout).
+     *
+     * Requires `delegateKey` to be set in the client config.
+     */
+    pay(request: PaymentRequest): Promise<PaymentResult>;
+    /**
+     * Step 1: Create a payment intent.
+     *
+     * Returns the intent with the hash to sign.
+     */
+    createIntent(request: PaymentRequest): Promise<PaymentIntent>;
+    /**
+     * Keyless x402 construct.
+     *
+     * The non-custodial half of an x402 payment: posts the funding request to
+     * `/x402` and returns the unsigned funding hash plus the data the caller
+     * needs to build and sign the EIP-3009 merchant header itself. Crucially it
+     * does **not** sign — neither the funding hash nor the merchant header — so
+     * it works without a `delegateKey`. Both delegate signatures happen on the
+     * machine that holds the key (the edge); the hosted MCP server relays only.
+     *
+     * Use this from the hosted, keyless server. The all-in-one `authorizeX402`
+     * remains for local clients that hold the key.
+     *
+     * Throws (via the shared payment-state path) when the amount exceeds the
+     * on-chain allowance — there is nothing to sign until the user approves.
+     */
+    createX402Intent(paymentRequired: X402PaymentRequired, options?: X402AuthorizationOptions): Promise<X402Intent>;
+    /**
+     * Step 2: Sign a hash with the delegate key.
+     *
+     * Returns the 65-byte signature (0x-prefixed).
+     * Requires `delegateKey` to be set in the client config.
+     */
+    sign(hash: string): string;
+    /**
+     * Sign a payment's `sign_data` with the correct scheme for its rail.
+     *
+     * Dispatching on the server-provided scheme means a caller never has to
+     * know which rail an account is on; an unknown scheme is a hard error,
+     * never a guessed signature. The session rail's 'eip191_userop' is retired
+     * (#834) — the backend refuses those intents with HTTP 410 before any
+     * sign_data reaches a client, so encountering it here is a hard error too.
+     */
+    private signForData;
+    /**
+     * Step 3: Submit a signature to execute the payment.
+     *
+     * The signature can come from `client.sign()` or from external signing.
+     */
+    submitSignature(paymentId: string, signature: string): Promise<{
+        status: string;
+        txHash?: string;
+    }>;
+    /**
+     * Get the current status of a payment.
+     */
+    getPayment(paymentId: string): Promise<PaymentResult>;
+    /**
+     * Get agent-actionable status for a payment intent or approval request.
+     *
+     * Use this for IDs returned by agent tools and machine-payment/x402 flows.
+     * `getPayment()` remains available for payment-intent-only integrations.
+     */
+    getPaymentStatus(paymentId: string): Promise<PaymentStatusResult>;
+    /**
+     * Get the agent identity tied to this API key.
+     */
+    getAgent(): Promise<HavenAgent>;
+    /**
+     * One-shot "am I ready?" bootstrap: identity + live spend authority + a
+     * readiness signal, in a single call. Folds {@link getAgent} and
+     * {@link getAllowances} together and derives a {@link HavenAgentReadiness}
+     * so an agent can answer "who am I and can I pay right now" at session start
+     * without two round trips and manual assembly.
+     */
+    getAgentSummary(): Promise<HavenAgentSummary>;
+    /**
+     * Sweep stranded USDC and ETH from the delegate EOA back to the originating Safe.
+     *
+     * The delegate key held by this client signs and submits the transfer transactions
+     * directly — Haven's backend never handles the key or constructs signed txs
+     * (CASP/MiCA Red Line #2). Funds always go to the Safe linked to this agent.
+     *
+     * Requires `chainRpcs` to be set for the agent's chain in `HavenClientConfig`.
+     */
+    sweepDelegate(): Promise<SweepResult>;
+    /**
+     * Hosted (keyless) split-signer sweep — step 1 of 2.
+     *
+     * Asks the backend to build a gasless EIP-3009 sweep authorization for the
+     * delegate's stranded USDC. Returns `nothing_stranded` when the delegate is
+     * empty, otherwise an `authorization` + Haven `expected_auth` to hand to the
+     * edge signer's `haven_sign_sweep_delegate`. No key is required on this client.
+     */
+    prepareSweep(): Promise<SweepPrepareResponse>;
+    /**
+     * Hosted (keyless) split-signer sweep — step 2 of 2.
+     *
+     * Relays the delegate-signed authorization. The Haven relayer submits the
+     * on-chain `transferWithAuthorization` and pays gas; this client never holds
+     * the key.
+     */
+    submitSweep(authorization: SweepAuthorization, signature: string): Promise<SweepSubmitResponse>;
+    /**
+     * Get configured and on-chain allowances for the authenticated agent.
+     */
+    getAllowances(): Promise<HavenAllowanceSummary>;
+    /**
+     * Post-purchase allowance/budget summary for a settled payment (#1310).
+     *
+     * Reuses the EXACT rail-aware read path {@link getAllowances} / #1306's
+     * catalog-purchase preflight `allowance` block use — `GET
+     * /machine-payments/allowances`, with delegation-rail values coming from
+     * the #1090 `deriveDelegationBudgets`-backed enforcer read, never
+     * `agent_allowances` — so this can never disagree with
+     * {@link getAllowances} for the same fixture. The settled token is
+     * resolved from {@link getPaymentStatus} so callers pass only
+     * `paymentId`, never a second haven_get_agent-style round trip.
+     *
+     * NEVER throws: any failed read (status lookup, agent lookup, or the
+     * allowance/budget lookup itself) degrades to `{ allowance: null,
+     * warnings: [ALLOWANCE_CHECK_UNAVAILABLE] }` rather than converting a
+     * successful settlement into a failure — the on-chain policy remains the
+     * actual spend gate regardless of whether this report can be produced.
+     *
+     * Freshness caveat (#1319): the delegation rail's on-chain enforcer read
+     * can silently fall back to the optimistic full period budget without
+     * throwing when the RPC read itself fails (#1145's fund-safe design,
+     * unchanged here). {@link getAllowances}'s `onchain.remainingIsFromChain`
+     * now carries that provenance on the wire, and the #1306 catalog-purchase
+     * preflight (`haven_prepare_catalog_purchase`) surfaces it as a warning —
+     * this summary does not (yet). `remaining_atomic` here reflects the last
+     * successful chain read, not a guaranteed-live one, and callers should not
+     * phrase it as guaranteed-fresh.
+     */
+    getPostPurchaseAllowanceSummary(paymentId: string): Promise<{
+        allowance: PostPurchaseAllowanceSummary | null;
+        warnings: AgentPaymentWarning[];
+        payment: PaymentStatusResult | null;
+    }>;
+    /**
+     * `haven_get_payment_status` convenience: fetch status and, for a
+     * genuinely SETTLED x402 payment, attach the same post-purchase
+     * allowance/budget summary a settle response carries.
+     *
+     * #1310/#1311 parity: this is the ONE home for logic that was duplicated
+     * verbatim in `packages/mcp-server/src/tools.ts` and `packages/mcp/src/tools.ts`
+     * (both hosted and local `haven_get_payment_status` handlers) — extracted
+     * here because both packages already depend on `@haven_ai/sdk` and call
+     * methods on a `HavenClient` instance, so this needed no new dependency
+     * edge. `funded_but_unsettled` is deliberately excluded: that phase means
+     * the merchant did NOT accept the retry. Every other phase/rail returns
+     * the status untouched.
+     */
+    getPaymentStatusWithPostPurchaseAllowance(paymentId: string): Promise<PaymentStatusResult & {
+        allowance?: PostPurchaseAllowanceSummary | null;
+        warnings?: AgentPaymentWarning[];
+    }>;
+    /**
+     * Discover payable services from Haven's merchant catalog (epic #1717).
+     *
+     * Read-only: returns catalog entries (price, rail, protocol) so an agent
+     * can choose a service and pay it with the regular payment tools in the
+     * same session. Never creates payments or signatures.
+     */
+    discoverTools(options?: {
+        category?: string;
+        search?: string;
+        rail?: 'x402' | 'mpp';
+        /**
+         * Filter on the entry's provenance (epic #1717): `'verified'` returns
+         * only self-submitted, domain-verified, probe-verified directory
+         * entries; `'operator'` only the operator-curated ones; `'any'` (the
+         * default) returns the merged listing.
+         */
+        verified?: 'any' | 'verified' | 'operator';
+    }): Promise<HavenCatalogEntry[]>;
+    /**
+     * Submit a merchant's payable (x402/MCP) endpoint to the Verified Payable
+     * Directory (epic #1717, #1716). Queue-only: writes a submission row and
+     * returns the id + verify_token. The request path makes no outbound
+     * request; domain-ownership proof and the read-only quote probe run later
+     * on the leader-locked monitor. Ownership proof is ALWAYS required before
+     * any listing — this method cannot skip it. `website` is a honeypot field
+     * that bots fill; leave it unset.
+     */
+    submitCatalogEntry(resourceUrl: string, options?: {
+        website?: string;
+    }): Promise<HavenCatalogSubmission>;
+    /**
+     * Fetch one submission's coarse status by id (epic #1717, #1716). Public
+     * and read-only. While the submission can still prove ownership the
+     * response carries the exact well-known / DNS-TXT `instructions`; the
+     * verify token is never returned here.
+     */
+    getCatalogSubmissionStatus(id: string): Promise<{
+        id: string;
+        status: 'submitted' | 'ownership_verified' | 'verified_payable' | 'failed' | 'delisted';
+        instructions?: {
+            expires_at: string;
+            well_known: {
+                url: string;
+                content: string;
+                instruction: string;
+            };
+            dns_txt: {
+                name: string;
+                value: string;
+                instruction: string;
+            };
+        } | null;
+    }>;
+    /**
+     * Fetch one curated catalog entry by id (#1306).
+     *
+     * Chain-scoped for free by the backend's SQL when the client is
+     * agent-authenticated (#1299): an unknown id and an id curated for a
+     * DIFFERENT chain than this agent's both 404 identically — this method does
+     * not (and must not) re-filter by chain in JS. Read-only, like
+     * {@link discoverTools}.
+     */
+    getCatalogEntry(id: string): Promise<HavenCatalogEntry>;
+    /**
+     * List recent machine-payment receipts/evidence for bookkeeping.
+     */
+    listReceipts(options?: {
+        limit?: number;
+    }): Promise<HavenPaymentReceipt[]>;
+    /**
+     * Fetch the verifiable receipt bundle for a settled payment and verify it
+     * locally. The server's own verification is ignored — the receipt is verified
+     * here (independently of Haven) by recovering the signer from the
+     * authorisation, so the result is trustworthy even if the backend lied.
+     */
+    getReceipt(paymentId: string): Promise<{
+        receipt: PaymentReceipt;
+        verification: ReceiptVerification;
+    }>;
+    /**
+     * Rehydrate the x402 resume-state bundle for a payment id (#1328: the MPP
+     * resume-state variant retired along with the rest of the mpp_demo surface).
+     *
+     * The server returns stored protocol context only. The client still signs the
+     * merchant proof locally when resumeX402Payment() runs.
+     */
+    getResumeState(paymentId: string): Promise<PaymentResumeState>;
+    /**
+     * Poll until a payment reaches a terminal status (confirmed, failed, expired).
+     */
+    waitForConfirmation(paymentId: string): Promise<PaymentResult>;
+    /**
+     * Authorize an x402 payment.
+     *
+     * Takes the parsed PaymentRequired from a 402 response, selects a compatible
+     * option, funds the delegate wallet through Haven, and returns the standard
+     * x402 header that the merchant can verify and settle.
+     *
+     * Requires `delegateKey` to be set in the client config.
+     */
+    authorizeX402(paymentRequired: X402PaymentRequired, options?: X402AuthorizationOptions): Promise<X402Receipt>;
+    /**
+     * Probe a paid endpoint and return its x402 quote without creating a Haven
+     * payment or approval request.
+     */
+    quoteX402(url: string, init?: RequestInit, options?: X402AuthorizationOptions): Promise<X402Quote>;
+    /**
+     * Probe an MCP tool for its x402 quote without creating a payment.
+     *
+     * Unlike the generic {@link quoteX402} helper, this completes the
+     * Streamable-HTTP MCP lifecycle before sending the unpaid `tools/call`.
+     * Hosted MCP uses this path while remaining keyless: it resolves only the
+     * agent's public delegate address for `x402-wallet`; signing remains local.
+     * It refuses before the quote when the merchant does not establish a session;
+     * callers that need a plain x402 endpoint must use {@link quoteX402}.
+     */
+    quoteMcpX402(url: string, init?: RequestInit, options?: X402AuthorizationOptions): Promise<X402Quote>;
+    /**
+     * Pay a previously inspected x402 quote and retry the exact captured request.
+     */
+    payX402Quote(quote: X402Quote, options?: X402AuthorizationOptions): Promise<Response>;
+    /**
+     * Pay a merchant through **erc7710 direct settlement** (#1454, epic #1450).
+     *
+     * **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.
+     *
+     * 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;
+    }): Promise<X402Erc7710Settlement>;
+    /**
+     * The AUTHORIZE half of erc7710 settlement (#1456): select the scheme, build
+     * the request, and return the child to be signed — without signing it.
+     *
+     * 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.
+     */
+    prepareX402Erc7710(paymentRequired: X402PaymentRequired, options?: {
+        resourceUrl?: string;
+        /**
+         * 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 a non-delegation account
+         * at the rail seam (the #1986 retired-rail 410, #2245).
+         */
+        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).
+         */
+        mcpCallContext?: X402McpCallContext;
+        /**
+         * #2041: replay key, as `createX402Intent` already takes one. Without it
+         * a retried authorize mints a second signable settlement child instead
+         * of replaying the first.
+         */
+        idempotencyKey?: string;
+    }): Promise<{
+        paymentId: string;
+        signData: SignData;
+        settlement: Omit<X402Erc7710Settlement, 'paymentHeader'>;
+    }>;
+    /**
+     * 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. 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>;
+    resumeX402Payment(input: ResumeX402PaymentInput | X402ResumeState): Promise<Response>;
+    /**
+     * Fetch wrapper that automatically handles HTTP 402 responses.
+     *
+     * Works like the standard `fetch()` but intercepts 402 responses,
+     * pays via x402 through Haven, and retries the request.
+     *
+     * ```ts
+     * const response = await haven.fetch('https://paid-api.com/data')
+     * const data = await response.json()
+     * ```
+     *
+     * **MCP-over-x402 auto-handshake (issue #315):** when the endpoint is
+     * MCP-shaped — the URL path ends in `/mcp`, or the 402 body carries a
+     * Coinbase Bazaar `extensions.bazaar` block — the SDK runs the MCP
+     * `initialize` handshake, threads the resulting `mcp-session-id`,
+     * `Accept: application/json, text/event-stream`, and `x402-wallet` headers
+     * through every request, and collapses SSE responses to the JSON-RPC
+     * `result`. The caller just passes `(url, { body })` and never sees the
+     * protocol plumbing. A non-MCP server (handshake error / no session id)
+     * falls back to standard x402 behaviour.
+     *
+     * Requires `delegateKey` to be set in the client config.
+     */
+    fetch(url: string, init?: RequestInit, options?: X402AuthorizationOptions): Promise<Response>;
+    /**
+     * 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
+     * merchant leg of an MCP tool payment after the edge signer has built the
+     * merchant payment header.
+     *
+     * Custody note: this never needs the delegate key. It relays a signed,
+     * amount/merchant/nonce-bound EIP-3009 authorization the edge signer already
+     * produced — the hosted server cannot mint or reuse signing authority.
+     *
+     * When the URL is MCP-shaped (`/mcp` path) or the quote-time transport context
+     * says the merchant was Bazaar-discoverable, runs a fresh `initialize`
+     * handshake (the quote-time session is gone once funding confirms; the x402
+     * challenge is stateless w.r.t. the MCP session, so a fresh session is
+     * accepted), threads the session + wallet headers, sets the x402 payment
+     * header under the names that scheme requires (#2341), and
+     * collapses an SSE JSON-RPC response to its `result`.
+     */
+    /**
+     * Wait for a payment's Safe→delegate funding tx to reach ≥1 on-chain
+     * confirmation. The hosted x402 completion path MUST call this after funding
+     * and before delivering the merchant 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 `X402FundingLeg.authorize`); the hosted
+     * split flow regressed when the 5→3 collapse removed the incidental
+     * inter-call latency that used to mask it.
+     *
+     * **NOT a no-op when the funding tx hash is absent** (#1508). The WAIT is
+     * skipped without a hash or a chain RPC, but the `GET /payments/:id` read
+     * below runs UNCONDITIONALLY — it is how the fallback hash and the chainId
+     * are obtained. That distinction is load-bearing: this method must never be
+     * called on a scheme with no funding leg, because the read itself fails once
+     * the intent reaches a status the backend maps to a non-2xx (`submitted` is a
+     * 409), turning a settled payment into a reported error. The previous wording
+     * here said "No-op when the funding tx hash ... is unavailable", and the
+     * hosted erc7710 path was written against that promise — see
+     * `deliverMerchantPayment`'s `noFundingLeg` option.
+     */
+    ensureFundingConfirmed(paymentId: string, fundingTxHash?: string): Promise<void>;
+    completeX402MerchantCall(input: {
+        url: string;
+        init?: RequestInit;
+        paymentId: string;
+        paymentHeader: string;
+        mcpTransport?: X402McpTransport;
+        /**
+         * #1508: the payment settles with NO funding leg (erc7710). This method was
+         * written for EIP-3009 and encodes that lifecycle in two places — the
+         * readiness gate wants `confirmed`, and a Haven funding tx hash is
+         * mandatory. Neither is reachable on a scheme where the MERCHANT redeems
+         * the delegation chain: the intent sits at `submitted` by design, and there
+         * is no Haven-submitted transaction at all. Set this to take the
+         * no-funding-leg path through both.
+         */
+        noFundingLeg?: boolean;
+    }): Promise<{
+        status: number;
+        ok: boolean;
+        body: unknown;
+        settlementTxHash?: string;
+    }>;
+    /**
+     * #2292: report the outcome of a merchant retry the AGENT performed.
+     *
+     * The hosted `haven_complete_mcp_tool` / `completeX402MerchantCall` path is
+     * for merchants Haven calls itself. On the plain-HTTP x402 path Haven never
+     * talks to the merchant, so the outcome of that retry had no way back —
+     * see `MerchantCompletion.reportMerchantOutcome` for what is verified about
+     * a caller-asserted report and what deliberately is not.
+     */
+    reportX402MerchantOutcome(input: {
+        paymentId: string;
+        outcome: X402MerchantOutcome;
+        merchantStatus: number;
+        merchantBody?: string;
+    }): Promise<X402MerchantOutcomeReport>;
+    /**
+     * GET /x402/:id/merchant-call-context — the settle-leg twin of #1263's
+     * sign-context fetch (#1307). Re-serves the stored merchant MCP-tool call
+     * context (merchant_url, tool_name, arguments, mcp_transport) recorded at
+     * quote time, so `haven_settle_mcp_tool` / `haven_complete_mcp_tool` can
+     * omit those fields and let Haven rehydrate them by payment_id instead of
+     * the caller re-threading them. Throws `HavenApiError` (404 unknown/foreign
+     * payment_id, 409 no stored context, 410 expired) — the caller decides the
+     * fallback (re-send the full context explicitly).
+     */
+    getX402MerchantCallContext(paymentId: string): Promise<X402MerchantCallContext>;
+    /**
+     * Wait for a funding tx to be mined with ≥1 confirmation before the
+     * merchant retry, eliminating the race where the merchant's
+     * `balanceOf(delegate)` runs before the funding block propagates.
+     *
+     * Skipped when `chainRpcs` does not include the chain; in that case Haven's
+     * 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 throwIfNonSignableAuthorizationState;
+    /**
+     * Execute a tool call by name and input.
+     *
+     * Designed to plug directly into agent tool-call handlers:
+     *
+     * ```ts
+     * if (block.type === 'tool_use') {
+     *   const result = await haven.executeTool(block.name, block.input)
+     *   // send result back to the model
+     * }
+     * ```
+     */
+    executeTool(toolName: string, input: Record<string, unknown>): Promise<Record<string, unknown>>;
+    private post;
+    private get;
+}
+
+/**
+ * Pre-built tool definitions for AI agent frameworks.
+ *
+ * These definitions describe Haven's direct SDK tool-calling surface in the
+ * formats expected by Claude (Anthropic) and OpenAI.
+ *
+ * The agent payment surface used by these tools is shared with the
+ * `@haven_ai/mcp` server — both consume `toolDescriptions` from
+ * `./tool-descriptions.ts`. Each consumer composes its own user-visible string
+ * from the same semantic fragments, so guidance lands in both surfaces at
+ * once and a downstream test asserts the shared summary appears in every
+ * consumer description.
+ *
+ * Usage with Claude:
+ *   const response = await anthropic.messages.create({
+ *     tools: havenTools.claude(),
+ *     ...
+ *   })
+ *
+ * Usage with OpenAI:
+ *   const response = await openai.chat.completions.create({
+ *     tools: havenTools.openai(),
+ *     ...
+ *   })
+ */
+interface ClaudeTool {
+    name: string;
+    description: string;
+    input_schema: {
+        type: 'object';
+        properties: Record<string, unknown>;
+        required: readonly string[];
+    };
+}
+declare function claudeTools(): ClaudeTool[];
+interface OpenAITool {
+    type: 'function';
+    function: {
+        name: string;
+        description: string;
+        parameters: {
+            type: 'object';
+            properties: Record<string, unknown>;
+            required: readonly string[];
+        };
+    };
+}
+declare function openaiTools(): OpenAITool[];
+declare const havenTools: {
+    /** Tool definitions in Anthropic/Claude format */
+    claude: typeof claudeTools;
+    /** Tool definitions in OpenAI function-calling format */
+    openai: typeof openaiTools;
+};
+
+/**
+ * Sign a hash using raw ECDSA (no Ethereum message prefix).
+ *
+ * This matches what Safe's AllowanceModule `checkSignature` expects —
+ * a direct ecrecover over the hash, NOT the "\x19Ethereum Signed Message" variant.
+ *
+ * Uses ethers.SigningKey.sign() instead of wallet.signMessage() to avoid the prefix.
+ */
+declare function signHash(privateKey: string, hash: string): string;
+/**
+ * Sign a delegation-rail payment (#829).
+ *
+ * The delegate SMART ACCOUNT validates an EIP-712 signature over the packed
+ * UserOperation — signing the bare 4337 hash would be rejected on-chain. The
+ * backend sends the exact typed data in `sign_data.typed_data`; we sign it
+ * verbatim and never reconstruct it (a second source of truth could drift
+ * from the account's own rules).
+ */
+interface Eip712TypedData {
+    domain: Record<string, unknown>;
+    types: Record<string, unknown>;
+    primaryType: string;
+    message: Record<string, unknown>;
+}
+declare function signUserOpTypedDataForDelegation(privateKey: string, typedData: Eip712TypedData): Promise<string>;
+/**
+ * Derive the Ethereum address from a private key.
+ */
+declare function addressFromKey(privateKey: string): string;
+/**
+ * Verify that a signature over a hash recovers to the expected address.
+ */
+declare function verifySignature(hash: string, signature: string, expectedAddress: string): boolean;
+
+/**
+ * Shared semantic descriptions for Haven agent payment tools.
+ *
+ * Two surfaces in this repo expose Haven as a tool: the Claude / OpenAI
+ * function-calling tool definitions in `tools.ts` (used for direct SDK
+ * integrations) and the MCP server in `packages/mcp` (used by any MCP-speaking
+ * agent runtime). The two surfaces use different tool *names* — the SDK's
+ * tools are tuned for tool-calling conventions (`make_payment`,
+ * `authorize_x402_payment`); the MCP tools follow the MCP `haven_*` naming
+ * (`haven_pay_x402_quote`).
+ *
+ * The underlying *operations* are the same, so the descriptive prose should
+ * live in one place. Both surfaces import from this module and compose their
+ * own tool descriptions from these semantic fragments. Drift is caught by
+ * tests asserting each consumer's description string contains the shared
+ * `summary` from this module.
+ */
+interface ToolDescription {
+    /** One-line summary of the operation. Used as the first sentence of every
+     * downstream description and as a stable substring for drift tests. */
+    summary: string;
+    /** Natural-language user intents that should make an agent prefer this
+     * tool over adjacent tools. Empty or omitted when the summary is enough. */
+    selectionGuidance?: string;
+    /** Concrete behaviour the tool performs end-to-end, including which
+     * non-custodial guarantee applies. */
+    behavior: string;
+    /** What the agent should do next on error / declined states.
+     * Empty string if not applicable. */
+    nextActionGuidance: string;
+}
+/**
+ * Build a single description string from the three fragments. Joined with
+ * spaces so consumers can split on the summary substring if they need to.
+ */
+declare function composeDescription(d: ToolDescription): string;
+declare const toolDescriptions: {
+    readonly quoteX402: {
+        readonly summary: "Inspect an HTTP 402 x402 paid resource without creating a Haven payment, signature, approval, or on-chain transaction.";
+        readonly behavior: "Probes the merchant directly and parses the 402 response. Pure read-only client behavior — Haven is not contacted.";
+        readonly nextActionGuidance: "On success the returned quote is the input to haven_pay_x402_quote. Do not call the merchant again — Haven re-uses the captured request when paying.";
+    };
+    readonly payX402: {
+        readonly summary: "Pay an inspected x402 quote. The delegate key signs locally; Haven only validates and relays signed, on-chain-constrained payment transactions.";
+        readonly selectionGuidance: "Do not use this for read-only allowance, budget, spend-limit, remaining-amount, reset-period, or what-can-I-spend questions; use the allowance lookup tool instead.";
+        readonly behavior: "Signs the payment locally and returns the merchant response. Settlement is either direct account-to-merchant with no funding leg, or a bridge that first redeems the agent's budget delegation to fund the delegate wallet for an EIP-3009 authorization. A payment outside the on-chain budget is declined before any money moves; nothing is queued for a human to approve later.";
+        readonly nextActionGuidance: string;
+    };
+    readonly payX402OneShot: {
+        readonly summary: "Fetch an x402 paid HTTP resource in a single call. Handles the full probe -> pay -> retry round trip and returns the merchant response.";
+        readonly selectionGuidance: "Prefer this over the quote+pay split when the agent just wants the paid resource and does not need to inspect the price first. If you already have a quote from haven_quote_x402, use haven_pay_x402_quote instead. Do not use for read-only allowance, budget, spend-limit, remaining-amount, reset-period, or what-can-I-spend questions; use the allowance lookup tool instead.";
+        readonly behavior: "Calls the URL, parses any HTTP 402 x402 challenge, signs the payment locally, then retries the original request with the signed payment header (sent under PAYMENT-SIGNATURE, plus the legacy X-PAYMENT on the EIP-3009 path only) and returns the merchant response. Settlement is either direct account-to-merchant with no funding leg, or a bridge that first redeems the agent's budget delegation to fund the delegate wallet for an EIP-3009 authorization. A payment outside the on-chain budget is declined before any money moves; nothing is queued for a human to approve later. If the resource returns a non-402 status, returns it unchanged without contacting Haven.";
+        readonly nextActionGuidance: string;
+    };
+    readonly resumeX402: {
+        readonly summary: "Resume an x402 payment whose Haven-side authorization already succeeded but whose merchant retry did not complete.";
+        readonly behavior: "Accepts either resume_state or payment_id, validates the original x402 details against the authorized Haven funding, and retries the merchant request with the signed payment header (sent under PAYMENT-SIGNATURE, plus the legacy X-PAYMENT on the EIP-3009 path only). No new Haven payment is created.";
+        readonly nextActionGuidance: string;
+    };
+    readonly getPaymentStatus: {
+        readonly summary: "Fetch structured Haven payment status, including phase and nextAction taxonomy for agent recovery.";
+        readonly behavior: "Accepts a payment intent id and returns the full state taxonomy (phase, nextAction, rail, amount, merchant, resource url, idempotency key, message).";
+        readonly nextActionGuidance: "";
+    };
+    readonly getResumeState: {
+        readonly summary: "Rehydrate stored x402 resume_state by payment_id.";
+        readonly behavior: "Returns the x402 context the agent originally received when the payment was authorized, reconstructed from Haven's database. This is context only; signing still happens locally when a resume tool is called.";
+        readonly nextActionGuidance: "";
+    };
+    readonly getAgent: {
+        readonly summary: "Return the authenticated agent identity AND its live spend authority in one call: Haven wallet, delegate, chain, raw status, spend_authority_readiness, and per-token remaining allowance (atomic + human-readable). The recommended first call in a new session to confirm who you are and whether Haven will let you spend right now.";
+        readonly selectionGuidance: "Use this as the one-shot orientation/bootstrap at the start of a session, or whenever you need to confirm identity together with whether the agent can spend right now. For a detailed per-token breakdown (configured vs spent vs reset window) use haven_get_allowances.";
+        readonly behavior: "Reads identity plus the live spend-authority snapshot in one shot — the agent's active on-chain budget delegation. spend_authority_readiness (readiness is a deprecated alias, same value) is \"ready\" when at least one token has remaining spend authority, \"needs_approval\" when the agent is active but has none, and \"revoked\" when the credential is not active. It covers hosted identity + on-chain spend authority ONLY — the hosted server cannot see the LOCAL signer, so \"ready\" does not mean the signer can start; verify the signer with a signer tool call or connect --doctor. An over-budget payment is declined before any money moves: there is no approval queue, so ask the owner to grant or raise the budget in Haven rather than waiting for an approval. allowances[] carries remainingAtomic and remainingDisplay per token. Identity fields (id, name, status, safeAddress, delegateAddress, chainId) are unchanged from before.";
+        readonly nextActionGuidance: "";
+    };
+    readonly getAllowances: {
+        readonly summary: "Return configured and on-chain allowance state for the authenticated agent. On-chain allowance is the real spend gate.";
+        readonly selectionGuidance: "Use this when the user asks about allowance, budget, spend limit, remaining amount, remaining allowance, remaining budget, daily limit, reset period, what can I spend, or what the agent can still spend.";
+        readonly behavior: "Returns the per-token spend authority for the account: the active budget delegation (remaining = the period budget, which re-arms natively at the period boundary). An over-budget payment is declined before any money moves; nothing queues. Configured amounts from Haven are returned alongside.";
+        readonly nextActionGuidance: "";
+    };
+    readonly listReceipts: {
+        readonly summary: "List recent machine-payment receipts and evidence for bookkeeping.";
+        readonly selectionGuidance: "Use this for transaction history, receipts, payment evidence, or bookkeeping; use the allowance tool instead for remaining allowance, budget, spend-limit, or what-can-I-spend questions.";
+        readonly behavior: "Returns the agent's recent machine-payment receipts ordered by recency. Proof header values are not returned.";
+        readonly nextActionGuidance: "";
+    };
+    readonly verifyReceipt: {
+        readonly summary: "Verify a payment receipt offline — confirm the agent authorised the transfer.";
+        readonly selectionGuidance: "Use this to check a receipt you already hold; it needs no network and does not trust Haven. Use the history tool to fetch receipts in the first place.";
+        readonly behavior: "Recovers the signer from the receipt authorisation and confirms it matches the agent delegate. Returns verified true/false with the recovered signer or a reason. Pure and local — no backend call.";
+        readonly nextActionGuidance: "";
+    };
+    readonly payMcpTool: {
+        readonly summary: "Call a named tool on an MCP merchant that requires an x402 payment, handling the full initialize → pay → retry round trip in one call.";
+        readonly selectionGuidance: string;
+        readonly behavior: string;
+        readonly nextActionGuidance: string;
+    };
+    readonly discoverTools: {
+        readonly summary: "Step 1 of a purchase: discover payable services from Haven's curated merchant catalog — names, prices, and which pay tool to use next.";
+        readonly selectionGuidance: string;
+        readonly behavior: string;
+        readonly nextActionGuidance: "Pick an entry and pay it with the tool named in suggested_tool, passing the entry's resource_url, tool_name, and tool_arguments for MCP merchants. Confirm the price from the live pay-tool result (not the catalog), and pass the user's cap as max_amount_human in whole tokens (\"no more than 1 USDC\" → max_amount_human: \"1\") — never convert it to atomic units by hand.";
+    };
+    readonly submitCatalogEntry: {
+        readonly summary: "Submit a merchant's payable (x402/MCP) endpoint to Haven's Verified Payable Directory for verification and listing.";
+        readonly selectionGuidance: string;
+        readonly behavior: string;
+        readonly nextActionGuidance: "Give the verify_token and the well-known instructions (from getCatalogSubmissionStatus) to the merchant so they can publish the proof line, then poll the submission status until it reaches verified_payable or failed.";
+    };
+    readonly sweep_delegate: {
+        readonly summary: "Sweep stranded USDC and/or ETH from the delegate wallet back to the originating Safe.";
+        readonly selectionGuidance: string;
+        readonly behavior: string;
+        readonly nextActionGuidance: string;
+    };
+    readonly send: {
+        readonly summary: "Send ETH or USDC directly from the agent's Haven wallet to a recipient address.";
+        readonly selectionGuidance: string;
+        readonly behavior: string;
+        readonly nextActionGuidance: string;
+    };
+};
+type SharedToolKey = keyof typeof toolDescriptions;
+
+/**
+ * The generic Haven payment skill — canonical copy.
+ *
+ * This SDK file is the single source of truth for the generic, secret-free
+ * skill content: no wallet address, no budget numbers, no per-agent values.
+ * The agent learns its live budget at runtime via the `haven_get_agent` /
+ * `haven_get_allowances` MCP tools, and can read identity + configured budget
+ * for fast first-turn orientation from the non-secret `agent.json` the
+ * connector writes (see `packages/connect/src/storage.ts`), so the same file
+ * works for every user. `packages/connect` imports this directly to
+ * auto-install the skill into runtime skills folders.
+ *
+ * `packages/frontend/src/lib/agent-skill-bundle.ts` keeps a deliberately
+ * decoupled inline copy (the download fallback): frontend has zero
+ * `@haven_ai/*` dependencies so it can deploy standalone on Vercel without an
+ * unpublished SDK export. A parity test in that package's test suite imports
+ * this canonical string and asserts byte-for-byte equality, so the two copies
+ * cannot drift.
+ */
+declare const HAVEN_SKILL_MD = "---\nname: haven-pay\ndescription: Pay for things from the user's Haven wallet within their agent rules. Use when the user asks to send, pay, tip, or transfer crypto \u2014 or when a request hits an HTTP 402 (x402) paywall.\n---\n\n# Haven: pay from a Haven wallet\n\nThis skill lets the agent make payments from the user's Haven wallet through\nthe Haven MCP tools. Every payment is checked against the agent's on-chain\nbudget before money moves; a payment above the remaining budget is declined \u2014\nnothing is paid past the rules the user set.\n\nHosted tools run in the `mcp__haven__` namespace. Local signing tools run in\nthe `mcp__haven-signer__` namespace and keep the delegate key on this machine.\nThat namespacing is Claude-family; other runtimes name the servers by their\nown config keys (Codex: `haven`, `haven_signer`). Tool results carry the\nexact next step (`next_action`, `next_tool`, `next_arguments`, plus the\nruntime-neutral `next_tool_server` + `next_tool_name` \u2014 the bare tool name\non that logical server, whatever your runtime calls it).\nFollow those fields first; the prose below is fallback and orientation, not\nthe source of truth.\n\n## When to use this skill\n\n- The user asks to send money, pay someone, tip, donate, or transfer tokens.\n- A request returns HTTP 402 (x402): use the Haven pay tools to settle it,\n  then retry the original request.\n\n## Identity and budget\n\nDo not guess the wallet address, network, or budget.\n\nFor instant orientation at the start of a session, read the non-secret\n`agent.json` the connector wrote to your Haven credential directory (typically\n`~/.haven/agents/<agent-id>/agent.json` \u2014 if you don't know the agent id, list\n`~/.haven/agents/` to find the folder). It\nholds your agent id, Haven wallet address, network, and *configured* per-token\nbudget, and contains no keys \u2014 the fastest way to answer \"who am I and what may\nI spend\" with no round trip. If that file is absent (some setups don't write\nit), use the tools below instead.\n\nBefore any payment, confirm the *live remaining* budget with the tools \u2014\n`agent.json` shows the configured budget, not what is left after recent\nspending:\n\n- `mcp__haven__haven_get_agent` \u2014 the recommended first call: identity\n  (wallet, network) plus `spend_authority_readiness` (`ready` / `needs_approval` /\n  `revoked`) and live remaining per-token allowance, in one shot. That signal\n  covers hosted identity and on-chain spend authority only \u2014 it cannot see the\n  local signer; the signer is verified by calling any signer tool.\n- `mcp__haven__haven_get_allowances` \u2014 detailed per-token breakdown\n  (configured, spent, reset window) when you need more than the summary.\n\nBudgets reset on a period the user chose. If a payment exceeds the remaining\nbudget it is declined before any money moves \u2014 tell the user; they can raise\nthe budget in the Haven dashboard, or wait for the period reset.\n\n## Paying\n\n**Catalog purchases \u2014 the primary path for MCP merchants:**\n\n1. `mcp__haven__haven_discover_tools` to find a payable service and its\n   `catalog_id`.\n2. If the user needs the live price before authorizing a cap, call\n   `mcp__haven__haven_quote_catalog_purchase` with `catalog_id`. It is\n   read-only and informational only: it never reserves a price or creates a\n   payment. Tell the user its `amount` / `amount_atomic`, then choose a cap.\n3. `mcp__haven__haven_prepare_catalog_purchase` with `catalog_id` and a\n   spending cap. A cap is REQUIRED on this tool and is best practice on every\n   paid call below too \u2014 it caps what the LIVE merchant quote may charge,\n   checked before any funding intent is created. Write it the way the user\n   said it: `max_amount_human` is whole tokens, so \"no more than 1 USDC\" is\n   `max_amount_human: \"1\"`. (`max_amount` is the atomic-unit form, where\n   \"1\" means 0.000001 USDC \u2014 do not convert by hand, and never send both.)\n4. Then FOLLOW THE RESPONSE'S GUIDANCE FIELDS: `next_action`, `next_tool`,\n   and `next_arguments` name the exact next call \u2014 act on those first; the\n   prose in this section is fallback and debugging detail. If the catalog\n   entry is missing or degraded, the response instead names\n   `mcp__haven__haven_pay_mcp_tool` (merchant URL, tool name, arguments) as\n   the manual fallback.\n\n**Signing:** `mcp__haven-signer__haven_sign_x402` with `payment_id` ONLY \u2014\nthe local signer fetches the exact signing bytes AND `payment_required`\nitself, so never relay `typed_data` or the 402 blob yourself. If the signer\nreports its fetched context carried no `payment_required` (older backend),\nre-call with `payment_required` added verbatim. Fallback for an older signer\nor backend: re-run the quote/prepare tool with the SAME `idempotency_key`\nplus `include_signing_payload=true`, then pass `payload_hash`,\n`x402_expected` (the nested `x402.expected` object), and\n`typed_data`/`typed_data_b64` through unchanged.\n\n**Settle:** `mcp__haven__haven_settle_mcp_tool` with `payment_id`,\n`signature`, and `payment_header` ONLY \u2014 Haven rehydrates the merchant call\ncontext (`merchant_url`, `tool_name`, `arguments`, `mcp_transport`)\nserver-side from `payment_id`. Pass those four fields explicitly only as a\nversion-skew fallback when Haven has no stored context for the id \u2014 both or\nnone together, never just one. If the settle result carries `settled: false`,\nfunding has not confirmed \u2014 follow the result's guidance fields and check\nstatus later, do not re-pay.\n\nStep-by-step alternative (also key-safe; for an older signer or backend, or\nwhen you already have a merchant URL and tool name instead of a\n`catalog_id`): if the user needs the live price before choosing a cap, first\ncall `mcp__haven__haven_quote_mcp_tool` with that merchant URL, tool name,\nand arguments. It is informational only; then call\n`mcp__haven__haven_pay_mcp_tool` with the same inputs and the explicit cap.\nThe paid call always obtains a fresh quote before it creates any intent. Then\ncontinue `mcp__haven__haven_pay_mcp_tool` \u2192\n`mcp__haven-signer__haven_sign` \u2192 `mcp__haven__haven_submit` \u2192\n`mcp__haven-signer__haven_x402_sign_header` \u2192\n`mcp__haven__haven_complete_mcp_tool`. Call that last step with\n`payment_id` and the signer's `payment_header` ONLY. It does not take\n`payment_required`: Haven rehydrates the merchant call context\n(`merchant_url`, `tool_name`, `arguments`, `mcp_transport`) and the\n402 server-side from `payment_id`, exactly as at settle. Pass that context\nexplicitly only as a version-skew fallback when Haven has no stored context\nfor the id \u2014 `merchant_url` and `tool_name` both or none together, never\njust one.\nThe returned `expires_at` is the signing window; if a tool returns\n`PAYMENT_WINDOW_EXPIRED`, re-run the same quote/prepare tool with the same\n`idempotency_key`. Do not call the merchant yourself \u2014 Haven completes the\nmerchant leg for you.\n\n**Direct transfer / non-MCP paywall:** `mcp__haven__haven_pay` with\n`to`, `amount`, and `token` for a plain transfer. For an arbitrary,\nnon-MCP x402 paywall: `mcp__haven__haven_quote_x402` to get a quote, then\n`mcp__haven__haven_pay_x402_quote` \u2014 follow the result's guidance fields\nfirst and sign in the local Haven signer. On THIS path Haven does not talk to\nthe merchant: `mcp__haven-signer__haven_sign_x402` returns both\n`signature` and `payment_header`; relay `signature` with\n`mcp__haven__haven_submit`, then retry the paywalled URL yourself with\n`payment_header`. Do not pass that call's `x402_binding` to\n`mcp__haven-signer__haven_x402_sign_header` \u2014 the one-shot already spent it\nbuilding the header, so the call can only refuse. Then tell Haven what the\nmerchant answered: `mcp__haven__haven_report_x402_outcome` with the\n`payment_id`, `outcome` (`\"accepted\"` for a 2xx, else `\"rejected\"`)\nand the `merchant_status` you got. Because Haven never contacted that\nmerchant, this is the only way it can learn the purchase failed \u2014 without it a\nfailed purchase reads as complete for fifteen minutes. (The SDK's own\n`haven_pay_x402` tool does perform the merchant retry itself; that tool is\nnot part of the hosted MCP surface.) If the process\ncrashes after payment, a later `mcp__haven__haven_get_payment_status` call\nmay report `nextAction: 'retry_original_x402_request'` \u2014 only then call\n`mcp__haven__haven_resume_x402_payment` with the preserved resume state or\npayment id, instead of paying again.\n\n**Catalog tool arguments:** when `haven_discover_tools` returns\n`tool_arguments`, pass that object unchanged as the pay tool's\n`arguments` field (for example\n`tool_arguments: { \"tier\": \"50gb\" }` -> `arguments: { \"tier\": \"50gb\" }`).\n\n**Prices:** show the user the live price from a read-only quote or the pay-tool\nresult, never a catalog price. `haven_discover_tools` prices are indicative\n(`price_is_indicative`) and can be stale. A read-only quote is informational\nonly and does not reserve a price; the later paid call re-quotes and enforces\nthe cap. The pay-tool result's `amount` / `amount_atomic` is the merchant's\nown quoted price for that call \u2014 a ceiling the merchant settles at or below \u2014\nso present it as the most the user will pay. It is a price, not an approval:\nthe payment goes through only if it also fits the cap you set and the on-chain\nbudget the user signed, which is enforced on-chain rather than by Haven.\n\n**Status:** `mcp__haven__haven_get_payment_status` with a `payment_id` to\ncheck on in-flight payments. Do not poll in a tight loop.\n\n## Declines and stop signals\n\n- A payment outside the agent's rules \u2014 above the remaining budget, wrong\n  recipient, or expired budget \u2014 is declined before any money moves. Nothing\n  is queued; tell the user, who can raise the budget in Haven.\n- `safe_to_continue: false` on a guidance block is a stop signal in\n  machine-readable form: stop and involve the user before calling anything\n  else for this payment.\n- Never ask the user for private keys. Signing happens only in the local Haven\n  signer; the hosted Haven tools never receive the signing key. If a tool\n  reports a missing or invalid credential, tell the user to re-run the Haven\n  setup command.\n\n## Failure handling\n\nHaven tool failures are shaped like `{ success: false, code, message, ... }`\nor older `{ error, status, details? }` responses. Branch on `code` when\npresent and surface `message` or `error` verbatim. Common cases:\n\n- `insufficient_funds`: the Haven wallet doesn't hold enough of that token.\n  Suggest the user add funds in the Haven dashboard.\n- `PRICE_EXCEEDS_MAX`: the live merchant price exceeded your cap. No funds\n  moved; ask the user before retrying with a higher one.\n- `AMBIGUOUS_MAX_AMOUNT`: you sent both `max_amount` and\n  `max_amount_human`. Nothing was contacted or spent \u2014 re-send with exactly\n  one (`max_amount_human` for a cap the user stated in tokens).\n- `MAX_AMOUNT_UNCONVERTIBLE`: `max_amount_human` does not fit this quote's\n  asset \u2014 unknown decimals, or more decimal places than the asset supports.\n  Round the cap, or send an exact atomic `max_amount`.\n- `PAYMENT_WINDOW_EXPIRED`: re-run the quote/prepare tool with the same\n  `idempotency_key`, then sign the fresh payload.\n- `MERCHANT_REJECTED_AFTER_FUNDING`: the merchant refused the paid retry.\n  Stop-and-sweep \u2014 stop retrying the merchant and use\n  `mcp__haven__haven_sweep_delegate` to recover stranded delegate funds.\n- `MERCHANT_UNRESPONSIVE_AFTER_FUNDING`: funding confirmed on-chain, but the\n  merchant never answered the paid retry. This is NOT proof of rejection \u2014 the\n  merchant may still settle late. Verify-then-sweep, never a blind sweep:\n  check `mcp__haven__haven_get_payment_status`, retry\n  `mcp__haven__haven_complete_mcp_tool` ONCE, and only sweep with\n  `mcp__haven__haven_sweep_delegate` if no settlement appears.\n- Budget exceeded: tell the user how much remains (from\n  `mcp__haven__haven_get_allowances`) and that they can raise the budget in\n  Haven.\n\n## Reporting after a purchase\n\nA settled `mcp__haven__haven_settle_mcp_tool` response carries\n`agent_summary.purchase_summary` and the remaining post-purchase allowance\nin `allowance` \u2014 report the product, Haven-derived payment/transaction\nfields, and what is left from those fields directly. `result` is optional\nraw merchant evidence; never use it to decide whether the purchase was paid.\nDo not call `haven_get_agent` or `haven_get_allowances` again just to\nreport a purchase you already made.\n\n## Revoke\n\nIf this agent's credential may have leaked, tell the user to pause or revoke\nthe agent in the Haven dashboard under Agents. New requests stop immediately\nfor that credential.\n";
+/** Directory name for the installed skill folder. */
+declare const SKILL_FOLDER_NAME = "haven-pay";
+/**
+ * The skill BODY — HAVEN_SKILL_MD with the YAML front-matter stripped.
+ *
+ * For runtimes whose instruction mechanism is a plain guidance file rather
+ * than a skills folder (Codex's global AGENTS.md, #1332), the front-matter is
+ * skill-registry metadata with no meaning and would render as a stray table.
+ * Derived mechanically from the canonical string above, never maintained by
+ * hand — the substance cannot fork per runtime.
+ */
+declare const HAVEN_SKILL_BODY_MD: string;
+
+/**
+ * The npm dist-tag the published Haven packages tell a user to re-run (#2423,
+ * slice 3 of epic #2420).
+ *
+ * ## Why a constant and not a literal
+ *
+ * Roughly a dozen user- and agent-facing strings across `@haven_ai/sdk`,
+ * `@haven_ai/signer`, `@haven_ai/connect` and the hosted MCP server say some
+ * form of "re-run `npx @haven_ai/connect@alpha`". Every one of them was a
+ * hard-coded literal, which is correct only for a build published under the
+ * `alpha` dist-tag. Once `dev`-branch snapshots publish under a `dev` tag
+ * (#2421), a snapshot build telling its tester to re-run `@alpha` would hand
+ * them the production connector — silently replacing the very build they are
+ * testing. So the tag becomes one build-time constant and every hint derives
+ * from it.
+ *
+ * ## Who writes it
+ *
+ * `scripts/release-bump.mjs` rewrites {@link HAVEN_CONNECTOR_CHANNEL} from the
+ * version it is bumping to, using exactly the rule `.github/workflows/publish.yml`
+ * uses to pick the `--tag` for that same version:
+ *
+ * | version | dist-tag / channel |
+ * |---|---|
+ * | `0.1.34-alpha.0` | `alpha` |
+ * | `0.0.0-dev.202609021200.abc1234` | `dev` |
+ * | `0.2.0` | `latest` |
+ *
+ * One rule, two consumers. `scripts/ci/connector-channel-agreement.test.mjs`
+ * executes the workflow's own shell and the bump script's own function over the
+ * same version table and fails if they ever disagree.
+ *
+ * ## Build-time here, run-time there
+ *
+ * A published tarball cannot read a deployment's environment, so for the
+ * published packages the channel is baked in at release time. A surface that is
+ * *deployed* rather than published has no release at which to bake anything in,
+ * so it reads the `HAVEN_CONNECTOR_CHANNEL` environment variable and falls back
+ * to this constant. Two surfaces do that: the hosted MCP server
+ * (`packages/mcp-server/src/connector-channel.ts`) and, since slice 2 (#2422),
+ * the backend's connector handout (`parseConnectorChannel` in
+ * `packages/backend/src/config.ts`). All three readers share one variable name,
+ * one default and one validation pattern, and that agreement is EXECUTED rather
+ * than asserted: `packages/backend/src/__tests__/connector-channel.test.ts`
+ * runs this module's `resolveConnectorChannel` and the backend's
+ * `parseConnectorChannel` over the same input table and fails if they ever
+ * diverge.
+ *
+ * **This says nothing about how any environment is configured.** Setting the
+ * variable anywhere is an operator action (epic #2420, operator step 3); no
+ * code here can observe it and none of this comment asserts it has happened.
+ */
+/** The published connector package. Never varies; only its tag does. */
+declare const CONNECTOR_PACKAGE_NAME = "@haven_ai/connect";
+/**
+ * The npm dist-tag this build's re-run hints name.
+ *
+ * **Do not hand-edit.** `scripts/release-bump.mjs` owns this literal the same
+ * way it owns `CONNECTOR_VERSION` and its siblings, and
+ * `scripts/release-bump.test.mjs` fails if the two drift.
+ */
+declare const HAVEN_CONNECTOR_CHANNEL = "dev";
+/** True when `value` is a well-formed dist-tag. */
+declare function isConnectorChannel(value: string): boolean;
+/**
+ * Resolve a channel from a deployment's `HAVEN_CONNECTOR_CHANNEL`.
+ *
+ * - unset, empty or whitespace ⇒ `fallback` (dashboards store a cleared
+ *   variable as `""`, and that must land on the production-safe value);
+ * - well-formed ⇒ itself;
+ * - anything else ⇒ **throws**. It does not quietly fall back: a typo such as
+ *   `dve` would then land on the production channel, and the environment would
+ *   look fixed while reproducing the exact defect this slice removes.
+ *
+ * Well-formed-but-wrong (`dve` again) is *not* caught here and cannot be — it
+ * fails later at `npx`, where the error names the package. Stated rather than
+ * implied.
+ */
+declare function resolveConnectorChannel(raw: string | undefined | null, fallback?: string): string;
+/** `@haven_ai/connect@<channel>` — the spec an `npx` invocation names. */
+declare function connectorSpec(channel?: string): string;
+/**
+ * The re-run command every hint embeds.
+ *
+ * `connectorRerunCommand()` → `npx @haven_ai/connect@alpha`
+ * `connectorRerunCommand('--doctor')` → `npx @haven_ai/connect@alpha --doctor`
+ *
+ * `args` is appended verbatim so each call site keeps its own flags and its own
+ * surrounding sentence. The wording of those sentences is deliberately NOT
+ * moved here: several are inside signer refusal messages that users and agents
+ * pattern-match on, and this change is meant to move the channel token and
+ * nothing else.
+ */
+declare function connectorRerunCommand(args?: string, options?: {
+    channel?: string;
+    npxFlags?: string;
+}): string;
+
+/**
+ * The Node.js floor Haven's published packages support (#1161).
+ *
+ * ## Why this lives in the SDK
+ *
+ * Three packages need to enforce the same floor — `connect` (at setup),
+ * `signer` and `mcp` (at startup) — and `@haven_ai/sdk` is the only dependency
+ * all three already share. A copy per package is how the floor drifted in the
+ * first place: `engines` said `>=24` everywhere while connect's runtime manifest
+ * enforced `20.0.0`, so a connect run on Node v23 passed the guard, installed
+ * the signer, and signed a real payment. Two numbers for one fact is one number
+ * too many.
+ *
+ * Each consumer still owns its own refusal — the error type, the exit code, the
+ * wording of "what to do next" — because a library must never terminate its
+ * host process. This module only answers *is this version supported* and *what
+ * should we tell the user*.
+ *
+ * ## Why a floor is enforced at all
+ *
+ * `engines` is advisory: npm emits `EBADENGINE` and installs anyway unless the
+ * user happens to have `engine-strict` set. For a normal library that is a
+ * reasonable default. For the **signer** it is not — it holds the delegate key
+ * and produces every payment signature, so a subtle runtime incompatibility
+ * shows up as a wrong or missing signature on a money path. "It seemed to work"
+ * is precisely the evidence that cannot be relied on there.
+ */
+/**
+ * The minimum supported Node.js version, as `major.minor.patch`.
+ *
+ * MUST equal the `engines.node` floor declared by every published Haven
+ * package. A guard test in each package asserts exactly that against its own
+ * `package.json`, so the two cannot drift again silently.
+ */
+declare const HAVEN_MINIMUM_NODE_VERSION = "22.0.0";
+/**
+ * Compare two Node versions. Negative when `left` is older.
+ *
+ * An unparseable version parses to `0.0.0` and therefore compares as older than
+ * any real floor — fail-closed. A version string Haven cannot read is not
+ * evidence of a supported runtime, and treating it as one would reopen exactly
+ * the hole this module closes.
+ */
+declare function compareNodeVersions(left: string, right: string): number;
+declare function isSupportedNodeVersion(nodeVersion?: string, minimumNodeVersion?: string): boolean;
+interface UnsupportedNodeVersionMessageOptions {
+    /**
+     * What is being refused, in the user's terms — "Haven setup", "The Haven
+     * signer". Leads the message so the reader knows what just stopped.
+     */
+    subject: string;
+    nodeVersion?: string;
+    minimumNodeVersion?: string;
+    /** Appended verbatim as the closing line. Used for the re-run instruction. */
+    retryHint?: string;
+}
+/**
+ * The refusal text.
+ *
+ * Names the detected version, the required version, and **how to fix it** — the
+ * previous message stopped after the two version numbers, which tells a user
+ * they are stuck without telling them how to get unstuck. The version-manager
+ * lines are the fix for nearly everyone; the closing caveat is there because the
+ * runtime that *spawns* the signer is frequently not the shell that was
+ * upgraded, and a desktop app can keep launching the old Node long after
+ * `node -v` in a terminal says otherwise.
+ */
+declare function unsupportedNodeVersionMessage(options: UnsupportedNodeVersionMessageOptions): string;
+
+/**
+ * x402 protocol support for the Haven SDK.
+ *
+ * Provides:
+ * - parsePaymentRequired() — extract payment requirements from a 402 response
+ * - parsePaymentRequiredResponse() — async parser with JSON body fallback
+ * - encodePaymentProof()   — encode a receipt as a PAYMENT-SIGNATURE header
+ *
+ * The main authorizeX402() and fetchWithPayment() are methods on HavenClient
+ * (see client.ts) since they need API access and signing.
+ */
+
+/**
+ * Persisted, agent-scoped facts used to preflight a signed standard x402
+ * payment header. This is an integrity comparison only: it never rebuilds,
+ * modifies, persists, or submits the supplied authorization.
+ */
+interface X402PaymentHeaderContext {
+    merchantTo: string;
+    amountAtomic: string;
+    asset: string;
+    network: string;
+    resourceUrl: string;
+    payer: string;
+    chainId: number;
+}
+/** A deliberately value-free refusal for untrusted payment-header input. */
+declare class X402PaymentHeaderValidationError extends Error {
+    constructor();
+}
+/**
+ * Upper bound on the MERCHANT-requested part of the EIP-3009 authorization
+ * window (#715, epic #713). The x402 library sets
+ * `validBefore = now + maxTimeoutSeconds` straight from the MERCHANT's 402
+ * challenge — without a cap, a malicious or sloppy merchant can request a
+ * year-long window and a leaked signed authorization stays spendable that
+ * whole time. 600 s is generous for any facilitator settle (typical is
+ * 30–60 s); we CLAMP rather than reject so payments keep flowing while
+ * exposure stays bounded. `validBefore` is a deadline, not a demand —
+ * settling earlier is always valid.
+ */
+declare const X402_MAX_AUTHORIZATION_WINDOW_SECONDS = 600;
+/**
+ * Forward margin ADDED on top of the (clamped) merchant timeout when the
+ * authorization is actually signed (#1256). The x402 verify rule requires
+ * `validBefore ≥ now + maxTimeoutSeconds` AT THE FACILITATOR — but the
+ * upstream library computes `validBefore = now + maxTimeoutSeconds` at
+ * SIGNING time, leaving zero forward margin. Haven's flow guarantees elapsed
+ * time between the two (the funding UserOp confirms before the merchant
+ * retry, ~1 min plus latency), so every purchase against a merchant whose
+ * `maxTimeoutSeconds` exceeded that latency failed structurally — measured
+ * live on Base mainnet: Anchor requires 300 s, and 226 s remained at verify.
+ *
+ * 300 s covers funding + retry latency with room to spare. The #715 exposure
+ * ceiling becomes clamped-timeout + margin ≤ 900 s total forward — a
+ * deliberate widening from 600 s, recorded on #1256: an authorization that
+ * cannot pass verify protects no one, and 900 s is still bounded by the same
+ * clamp discipline.
+ */
+declare const X402_SETTLEMENT_FORWARD_MARGIN_SECONDS = 300;
+declare function normalizePaymentRequired(value: unknown): X402PaymentRequired | null;
+/**
+ * The x402 wire header names, in one place (#2289).
+ *
+ * v2 renamed all three; v1's only name was `X-PAYMENT`, used in BOTH
+ * directions. Haven had adopted the v2 names for everything it *reads* and
+ * kept the v1 name for the one thing it *writes*, which is how a strict v2
+ * merchant came to never see a payment header at all.
+ *
+ * The 2026-08-31 owner decision was to send both outbound names on every
+ * retry rather than switch on `x402Version`: a v1 merchant ignores the name it
+ * does not know, a v2 merchant ignores the legacy one, and no version
+ * heuristic has to be right for a payment to land.
+ *
+ * **That is no longer unconditional (#2341).** It held while the cost of a
+ * spare header was zero, and on the EIP-3009 bridge it still is. On erc7710 it
+ * is not: that header carries a whole delegation chain, and duplicating it
+ * overflowed the merchant's header limit — HTTP 431, every erc7710 settlement
+ * refused. `x402PaymentHeaderNamesFor` below is the live rule; read it rather
+ * than this paragraph, which records why the simpler rule was right first.
+ */
+/** v2 client→server payment payload. The name a strict v2 merchant reads. */
+declare const X402_PAYMENT_HEADER_NAME = "PAYMENT-SIGNATURE";
+/** v1 client→server payment payload; still accepted by most v2 merchants. */
+declare const X402_LEGACY_PAYMENT_HEADER_NAME = "X-PAYMENT";
+/** v2 server→client payment requirements. */
+declare const X402_PAYMENT_REQUIRED_HEADER_NAME = "PAYMENT-REQUIRED";
+/** v2 server→client settlement receipt. */
+declare const X402_PAYMENT_RESPONSE_HEADER_NAME = "PAYMENT-RESPONSE";
+/**
+ * Both wire names, v2 first — the value an EIP-3009 retry actually sends.
+ *
+ * **Not the general answer any more (#2341), and not what a recorder should
+ * reach for.** This was the evidence record's `paymentProofHeaderName` while
+ * both names always went on the wire; erc7710 now sends one, so a recorder
+ * still reading this constant would log a legacy header that was never sent —
+ * exactly the drift the previous wording promised it prevented. Use
+ * `x402PaymentHeaderNamesSent(paymentHeader)`. Kept exported because it is a
+ * published surface and removing it would break consumers.
+ */
+declare const X402_PAYMENT_HEADER_NAMES_SENT = "PAYMENT-SIGNATURE, X-PAYMENT";
+/**
+ * The x402 v2 payment envelope: `{x402Version, resource?, accepted, payload,
+ * extensions?}` per the spec's PaymentPayload (§5.2.2).
+ *
+ * The `resource` and `extensions` echoes are the #2361 fix, and they are not
+ * optional politeness: the spec makes the extensions echo a MUST ("the client
+ * must include at least the info received"), and CoinGecko's facilitator was
+ * live-bisected rejecting the echo-less envelope with a bare 400 while
+ * accepting the identical signature and `accepted`/`payload` bytes with the
+ * echoes added (#2360, Base mainnet, 2026-09-01). Both objects are echoed
+ * VERBATIM from the merchant's 402 — never reconstructed — and omitted when
+ * the challenge carries none, which keeps the envelope byte-identical to the
+ * pre-#2361 shape for echo-less merchants (Ampersend and Soundside settled
+ * that shape live, so omission is the proven-compatible default).
+ *
+ * The `accepted` wrap itself is #303's shape and predates this helper — see
+ * the #300/#303 history before "fixing" it: scheme/network live INSIDE
+ * `accepted` in v2, never at the top level.
+ */
+declare function x402V2PaymentEnvelope(paymentRequired: Pick<X402PaymentRequired, 'x402Version' | 'resource' | 'extensions'>, accepted: X402PaymentOption, payload: unknown): Record<string, unknown>;
+/**
+ * Parse an HTTP 402 response into x402 PaymentRequired data.
+ *
+ * Supports:
+ * - v2: PAYMENT-REQUIRED header (base64 JSON)
+ * - v1 fallback: X-PAYMENT header or response body
+ */
+declare function parsePaymentRequired(response: Response): X402PaymentRequired;
+/**
+ * Parse an HTTP 402 response into x402 PaymentRequired data.
+ *
+ * Soundside and other Bazaar-style MCP endpoints return the PaymentRequired
+ * object in the JSON body, while older Haven demos and many x402 examples use
+ * base64 headers. This keeps the synchronous header parser intact and adds the
+ * body fallback needed for those endpoints.
+ */
+declare function parsePaymentRequiredResponse(response: Response): Promise<X402PaymentRequired>;
+/**
+ * Select the best payment option from the x402 accepts array.
+ *
+ * Preference order:
+ * 1. Option on a Haven-supported network with a known token
+ * 2. Any option on a Haven-supported network
+ * 3. null — no compatible option
+ */
+declare function selectPaymentOption(accepts: X402PaymentOption[]): X402PaymentOption | null;
+/** The `extra.assetTransferMethod` value that marks an erc7710-settleable entry. */
+declare const ERC7710_ASSET_TRANSFER_METHOD = "erc7710";
+/**
+ * Read `extra.assetTransferMethod` defensively. `extra` is the merchant's own
+ * object, so it is untrusted shape: anything that is not the exact string is
+ * treated as "not erc7710" rather than coerced.
+ */
+declare function x402AssetTransferMethod(option: X402PaymentOption): string | null;
+/** True when the merchant advertises this entry as erc7710-settleable. */
+declare function isErc7710Option(option: X402PaymentOption): boolean;
+/**
+ * The facilitator addresses a merchant advertises for an erc7710 entry, for
+ * the #1058 redeemer pin — or `null` when it pins nothing.
+ *
+ * **An EMPTY array is `null`, not `[]`.** The backend rejects an empty
+ * `redeemers` list with a 400 (`routes/x402.ts`), and the QA scenario already
+ * treats empty as absent. Returning `[]` here would hand callers a value that
+ * means "pin to nobody" — which is not a narrower pin, it is an unbuildable
+ * delegation.
+ *
+ * Malformed entries are DROPPED rather than failing the whole option, and that
+ * asymmetry is deliberate. A pin narrowed by a merchant's typo means the
+ * facilitator that actually tries to redeem is not on the list, so redemption
+ * reverts — and erc7710 has no funding leg, so nothing moved and nothing is
+ * stranded. Refusing the option outright would instead deny a payment the
+ * remaining valid facilitators could have settled. Losing the payment is the
+ * worse outcome, precisely because the failure this issue closes (#1453) is the
+ * one where funds move BEFORE the rejection.
+ */
+declare function x402FacilitatorAddresses(option: X402PaymentOption): string[] | null;
+/**
+ * Select an option that can be paid with the official x402 EIP-3009 exact
+ * scheme. Haven's older tx-hash proof path can describe more networks; the
+ * merchant-verified path currently needs Base USDC.
+ *
+ * **Skips erc7710-tagged entries (#1453).** It used to return the first
+ * positional match and never look at `extra.assetTransferMethod`, so a merchant
+ * that listed its erc7710 entry first made a Haven client echo that option
+ * while signing a standard EIP-3009 authorization. The merchant rejects the
+ * mismatch cleanly — but on the legacy two-leg the Safe→delegate funding
+ * transfer has already executed, so the visible result is a stranded delegate
+ * balance for the sweep to reclaim. Only our own demo merchant's ordering was
+ * holding that shut, and that pin binds our merchant, not the ones we do not
+ * control.
+ */
+declare function selectStandardPaymentOption(accepts: X402PaymentOption[]): X402PaymentOption | null;
+/**
+ * Select the erc7710-settleable option, if the merchant advertises one.
+ */
+declare function selectErc7710PaymentOption(accepts: X402PaymentOption[]): X402PaymentOption | null;
+/** What a settlement-scheme decision resolved to. */
+interface X402SchemeSelection {
+    scheme: 'erc7710' | 'eip3009';
+    option: X402PaymentOption;
+    /** Redeemer pin for the settlement child; only ever set on erc7710. */
+    facilitatorAddresses: string[] | null;
+}
+/**
+ * THE preference rule, in one place (#1450 owner decision, #1453).
+ *
+ *   Prefer erc7710 whenever the account is on the delegation rail and the
+ *   merchant advertises `extra.assetTransferMethod: "erc7710"`; fall back to
+ *   the EIP-3009 bridge otherwise.
+ *
+ * Both halves of that condition are required, and the rail half is the
+ * caller's to supply — the SDK cannot see which rail an account is on from a
+ * 402 response alone. A legacy AllowanceModule account passing
+ * `delegationRail: true` would select a scheme its account cannot settle; the
+ * backend refuses that at authorize with the #1986 retired-rail 410 (#2245 —
+ * previously a scheme-specific 400 that wrongly implied the legacy rail could
+ * still settle via EIP-3009), which is where a rail mismatch SHOULD fail,
+ * on-chain-adjacent rather than in a client that could be lying to itself.
+ *
+ * Returns `null` when neither scheme has a payable entry — the caller decides
+ * whether that is an error or a reason to look elsewhere.
+ */
+declare function selectX402SettlementScheme(accepts: X402PaymentOption[], opts: {
+    delegationRail: boolean;
+}): X402SchemeSelection | null;
+declare function x402AuthorizationAmount(option: X402PaymentOption): string;
+/**
+ * Canonical Haven-authenticated x402 expected context, recomputed byte-for-byte
+ * by the edge signer before it signs anything.
+ *
+ * **Two versions, and the version is derived — never passed in (#1138).**
+ * `typedDataHash` present ⇒ v2, absent ⇒ v1. A v1 message is byte-identical to
+ * what shipped before, so existing signers keep verifying legacy-rail bindings
+ * unchanged.
+ *
+ * The version lives in both the header line and the payload so neither can be
+ * reinterpreted as the other: a v2 context cannot be replayed as a v1 one that
+ * drops the typed-data commitment, and a v1 context cannot be presented as v2.
+ * That downgrade is exactly the attack the digest exists to stop — see
+ * `assertExpectedBinding` in `@haven_ai/signer`, which refuses to raw-sign a
+ * hash under a v2 binding and refuses to sign typed data without one.
+ */
+declare function buildX402ExpectedMessage(context: X402ExpectedContext): string;
+declare function toStandardPaymentRequirements(paymentRequired: X402PaymentRequired, option: X402PaymentOption): PaymentRequirements;
+/**
+ * Strictly validate an edge-signed EIP-3009 X-PAYMENT header against the
+ * persisted x402 intent context before a hosted relay can submit funding.
+ *
+ * The merchant/facilitator remains the final protocol verifier. This closes a
+ * separate hosted-relay integrity gap: malformed or context-mismatched input
+ * must never cause Haven to relay the funding signature first.
+ */
+declare function validateStandardX402PaymentHeader(paymentHeader: string, context: X402PaymentHeaderContext): Promise<void>;
+/**
+ * Encode a payment receipt as a base64 PAYMENT-SIGNATURE header value.
+ *
+ * This follows the x402 v2 protocol — the server's facilitator will
+ * verify the on-chain transaction referenced by tx_hash.
+ */
+declare function encodePaymentProof(receipt: {
+    txHash: string;
+    paymentId: string;
+    token: string;
+    amount: string;
+    to: string;
+    resourceUrl?: string;
+    accepted?: X402PaymentOption;
+    payer?: string;
+    chainId?: number;
+}): string;
+/**
+ * Resolve a token symbol from a contract address.
+ *
+ * Checks all supported chains. For chain-specific resolution,
+ * pass the optional `network` CAIP-2 string (e.g. "eip155:100").
+ */
+declare function resolveTokenFromAddress(address: string, network?: string): {
+    symbol: string;
+    decimals: number;
+} | null;
+
+/**
+ * Runtime-agnostic base64 helpers — the single source of truth for the wire
+ * encoding shared by the SDK and the edge signer (#325).
+ *
+ * Why this module exists: the SDK used `atob`/`btoa` (Web globals) while the
+ * signer used `Buffer` (Node-only). Both worked because both currently run in
+ * Node ≥ 16, but the duplication was a latent wire-incompatibility — and the
+ * signer is headed for non-Node runtimes (browsers, Cloudflare Workers) where
+ * `Buffer` does not exist (#314).
+ *
+ * Encoding contract:
+ * - Output is ALWAYS standard base64 (`+`, `/`, padded). The x402 protocol's
+ *   reference implementation validates headers against
+ *   `/^[A-Za-z0-9+/]*={0,2}$/` — URL-safe output would be rejected.
+ * - Decoding is tolerant: URL-safe input (`-`, `_`, unpadded) is normalized
+ *   before decoding, since third-party merchants are not guaranteed to be as
+ *   strict as the reference implementation.
+ * - UTF-8 throughout. Naive `btoa(JSON.stringify(...))` throws on any
+ *   non-Latin-1 character (e.g. a merchant description with an emoji or
+ *   non-ASCII name); these helpers route through TextEncoder/TextDecoder on
+ *   the Web path so multibyte characters round-trip identically on both
+ *   runtimes.
+ */
+/** Encode a UTF-8 string as standard base64. */
+declare function encodeBase64Utf8(value: string): string;
+/** Decode standard or URL-safe base64 to a UTF-8 string. */
+declare function decodeBase64Utf8(value: string): string;
+/** Encode a JSON-serializable value as a standard-base64 string. */
+declare function encodeBase64Json(value: unknown): string;
+/**
+ * Decode a base64 JSON payload.
+ *
+ * Pass a `label` to get a wrapped error message instead of the raw
+ * JSON/base64 error — call sites parsing untrusted merchant headers use this
+ * to produce actionable failures.
+ */
+declare function decodeBase64Json<T>(value: string, label?: string): T;
+
+/**
+ * #1271 / #1301: bounded same-origin merchant MCP endpoint discovery.
+ *
+ * An agent handed a BASE merchant URL previously had to hand-probe /, /mcp,
+ * /sse, … until something answered 402. The demo merchant (and the #1266
+ * contract) serves a machine-readable discovery document at
+ * `/.well-known/haven-demo-merchant` (also at `/`) naming `mcp_url`. This
+ * helper fetches ONLY those two fixed same-origin paths — no redirects
+ * (`redirect: 'error'`), a 5 s timeout, a 64 KB read cap — and accepts the
+ * document's `mcp_url` ONLY when it stays on the same origin as the input.
+ * Anything else returns null and the caller reports the original probe
+ * failure. Discovery finds endpoints; it carries no payment authority and an
+ * off-origin `mcp_url` is never even fetched — this must not grow into a
+ * general network scanner (SSRF bound, per the issue).
+ *
+ * Originally hosted-only (mcp-server, #1271). Moved here in #1301 so the
+ * local/self-signed MCP package (`@haven_ai/mcp`) can share the EXACT same
+ * bounded implementation instead of re-deriving discovery semantics —
+ * behavior is byte-identical to the pre-move mcp-server copy; the #1271
+ * contract tests in packages/mcp-server/src/tools.test.ts pass unmodified
+ * against this moved implementation.
+ */
+declare const MERCHANT_DISCOVERY_PATHS: readonly ["/.well-known/haven-demo-merchant", "/"];
+declare const DISCOVERY_MAX_BYTES: number;
+declare function discoverMerchantMcpUrl(inputUrl: string): Promise<string | null>;
+/** Trailing-slash/percent-case echoes compare equal; unparseable never does. */
+declare function sameUrl(a: string, b: string): boolean;
+
+export { AGENT_PAYMENT_FAILURE_CODE_VALUES, AGENT_PAYMENT_NEXT_ACTION_VALUES, AGENT_PAYMENT_PHASE_VALUES, AGENT_PAYMENT_RAIL_VALUES, type AgentNextStep, type AgentPaymentEnumSchema, AgentPaymentFailureCode, AgentPaymentFailureCodeDescriptions, AgentPaymentFailureCodeSchema, AgentPaymentNextAction, AgentPaymentNextActionDescriptions, AgentPaymentNextActionSchema, AgentPaymentPhase, AgentPaymentPhaseDescriptions, AgentPaymentPhaseSchema, AgentPaymentRail, AgentPaymentRailDescriptions, AgentPaymentRailSchema, type AgentPaymentSummary, type AgentPaymentWarning, AgentPaymentWarningCode, type AgentPurchaseSummary, CONNECTOR_PACKAGE_NAME, type CatalogSubmissionAccepted, type ClaudeTool, DEFAULT_CONFIRMATION_TIMEOUT_MS, DISCOVERY_MAX_BYTES, ERC7710_ASSET_TRANSFER_METHOD, HAVEN_CONNECTOR_CHANNEL, HAVEN_MINIMUM_NODE_VERSION, HAVEN_SKILL_BODY_MD, HAVEN_SKILL_MD, type HavenAgent, type HavenAgentAllowanceSummary, type HavenAgentReadiness, type HavenAgentSummary, type HavenAllowance, type HavenAllowanceSummary, HavenApiError, type HavenCatalogEntry, type HavenCatalogSubmission, HavenClient, type HavenClientConfig, HavenError, type HavenPaymentReceipt, HavenPaymentStateError, HavenSigningError, HavenTimeoutError, HavenUnsupportedSignerVersionError, MERCHANT_DISCOVERY_PATHS, type MachinePaymentRail, MerchantTimeoutError, type OpenAITool, type PaymentFee, type PaymentIntent, type PaymentNextAction, type PaymentPhase, type PaymentReceipt, type PaymentRequest, type PaymentResult, type PaymentResumeState, type PaymentStatus, type PaymentStatusResult, type PostPurchaseAllowanceSummary, RECEIPT_VERSION, type ReceiptVerification, type ResumeAuthorizedX402Input, type ResumeX402PaymentInput, SIGNER_UPDATE_FALLBACK, SKILL_FOLDER_NAME, SWEEP_BASE_CHAIN_ID, SWEEP_BASE_SEPOLIA_CHAIN_ID, SWEEP_BASE_SEPOLIA_USDC_ADDRESS, SWEEP_BASE_USDC_ADDRESS, type SharedToolKey, type SignData, SignerRefusalCode, type SweepAuthorization, type SweepConfirmation, type SweepEip712Domain, type SweepEntry, type SweepExpectedAuth, type SweepPreparation, type SweepPrepareResponse, type SweepResult, type SweepSubmitResponse, type SweepSubmitResult, type SweepTypedData, TRANSFER_WITH_AUTHORIZATION_TYPES, type ToolDescription, type UnsupportedNodeVersionMessageOptions, X402AlreadySettledError, type X402AuthorizationOptions, type X402Erc7710Settlement, type X402ExpectedAuth, type X402ExpectedContext, type X402Intent, type X402McpCallContext, type X402McpTransport, type X402MerchantCallContext, type X402MerchantOutcome, type X402MerchantOutcomeReport, type X402PaymentHeaderContext, X402PaymentHeaderValidationError, type X402PaymentOption, type X402PaymentRequired, type X402Quote, type X402Receipt, type X402RequestSnapshot, type X402ResumeState, type X402SchemeSelection, X402UnexpectedStatusError, X402_LEGACY_PAYMENT_HEADER_NAME, X402_MAX_AUTHORIZATION_WINDOW_SECONDS, X402_PAYMENT_HEADER_NAME, X402_PAYMENT_HEADER_NAMES_SENT, X402_PAYMENT_REQUIRED_HEADER_NAME, X402_PAYMENT_RESPONSE_HEADER_NAME, X402_SETTLEMENT_FORWARD_MARGIN_SECONDS, addressFromKey, buildSweepAuthorizationMessage, buildSweepTypedData, buildX402ExpectedMessage, compareNodeVersions, composeDescription, connectorRerunCommand, connectorSpec, decodeBase64Json, decodeBase64Utf8, discoverMerchantMcpUrl, encodeBase64Json, encodeBase64Utf8, encodePaymentProof, havenTools, isConnectorChannel, isErc7710Option, isSupportedNodeVersion, isSweepableChain, normalizePaymentRequired, parsePaymentRequired, parsePaymentRequiredResponse, resolveConnectorChannel, resolveTokenFromAddress, sameUrl, selectErc7710PaymentOption, selectPaymentOption, selectStandardPaymentOption, selectX402SettlementScheme, signHash, signUserOpTypedDataForDelegation, signerUpdateFallback, sweepUsdcAddress, sweepUsdcDomain, toStandardPaymentRequirements, toolDescriptions, unsupportedNodeVersionMessage, validateStandardX402PaymentHeader, verifyPaymentReceipt, verifySignature, x402AssetTransferMethod, x402AuthorizationAmount, x402FacilitatorAddresses, x402V2PaymentEnvelope };