@haven_ai/sdk 0.3.0-alpha.0 → 0.5.0-alpha.1

package/dist/base64-BUMXmruY.d.cts

@@ -0,0 +1,2731 @@
+import { PaymentRequirements } from 'x402/types';
+import { Hex, Address } from 'viem';
+
+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>;
+    /**
+     * `<package>/<version>` naming the published package that embeds this
+     * client, sent on every Haven API request as `X-Haven-Client` (#3303) so the
+     * backend can tell an outdated client what to run. Defaults to
+     * `@haven_ai/sdk/<this SDK's version>`. It cannot be set through
+     * `defaultHeaders` — the transport writes it last.
+     */
+    clientIdentity?: 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 funding tx (account → delegate EOA) 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). The backend spec makes it
+     * required; the legacy AllowanceModule reading — absent = raw ECDSA over
+     * `hash` — is retired (#2850), and the SDK client refuses an absent scheme.
+     * 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: {
+        /**
+         * The PAYER account (the user's smart account). Not to be confused with
+         * `account`, which on the funding shapes holds the DELEGATE account
+         * address.
+         */
+        payer_account?: 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 payload (`signData`, account → 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 payload + 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 payload to sign with the delegate key (account → 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.
+     *
+     * Absent ⇒ the retired version-1 bare-hash context. Since #3272 the backend
+     * never emits one (`signX402ExpectedContext` requires this field) and
+     * `@haven_ai/signer` refuses it with its version-mismatch refusal; the field
+     * stays optional here only because the type also describes older payloads.
+     */
+    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 {
+    /**
+     * 2 = carries `typedDataHash` (delegation rail, #1138). 3 = additionally binds
+     * the payer identity (#1690). 1 (hash-only, retired Safe rail) is never
+     * emitted since #3272 and the signer refuses it.
+     *
+     * 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;
+    /** #3097: `resourceUrl` (the merchant's declaration) is not `request.url` (what was quoted). */
+    resourceUrlDiffersFromRequest: boolean;
+    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;
+    /** The agent's Haven account (smart account) address. */
+    accountAddress: string;
+    delegateAddress: string;
+    chainId: number;
+    /**
+     * Which on-chain policy primitive gates this agent's spend (#1306): the
+     * legacy Safe AllowanceModule (retired — no account can enter it since
+     * #1984, and it cannot spend since #1986) 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;
+    /**
+     * #3128: human-readable `onchain.remaining`, e.g. "4.96 USDC" — the SAME
+     * string {@link HavenAgentAllowanceSummary.remainingDisplay} carries for
+     * this allowance, computed by one function from `onchain.remaining` and
+     * the token's decimals, so the two reads cannot disagree. Additive; the
+     * wire carries no display form (it is derived client-side).
+     */
+    remainingDisplay: string;
+    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;
+    accountAddress: 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';
+}
+/**
+ * #3126 — the answer to "is there money actually HELD behind my budget?",
+ * asked as a sufficiency signal rather than a balance.
+ *
+ * Every other agent-readable figure in this package describes SPEND
+ * AUTHORITY — what the agent is PERMITTED to move this period
+ * ({@link HavenAllowanceSummary}). This shape answers the different question
+ * of whether the account HOLDS funds behind that authority, and deliberately
+ * answers it as `covered: boolean | null`, never as a figure: a constrained
+ * actor has no business reading the treasury total, and the boolean answers
+ * the only decision an agent has (attempt the payment, or tell the user
+ * funds are missing).
+ *
+ * The naming keeps the two concepts apart (the #3126 binding constraint):
+ * `budgetRemainingAtomic` is AUTHORITY — the same value
+ * {@link HavenAllowanceSummary} reports per token as `onchain.remaining` —
+ * while `covered` speaks only of HELD funds. Nothing here is named like the
+ * authority fields (`remaining`, `available`); nothing here returns a
+ * balance.
+ *
+ * `covered: null` means the chain read FAILED — unverifiable, never a
+ * guess. The same honesty rule `x402-funding-leg.ts`'s `delegateCanFund`
+ * established (#1521): treat null as "we do not know", not as "funded" or
+ * as absence; `coverageError` carries why.
+ */
+interface HavenBalanceCoverage {
+    /**
+     * true: the chain reports the agent's account holds at least
+     * `checkedAmountAtomic` of the token. false: the chain read succeeded and
+     * reports LESS — tell the user funds are missing rather than retrying.
+     * null: the chain read failed — unverifiable, never treated as absence.
+     */
+    covered: boolean | null;
+    /** Present only when `covered` is null: why the chain read could not answer. */
+    coverageError?: string;
+    chainId: number;
+    tokenAddress: string;
+    tokenSymbol: string;
+    /** The amount the coverage question was asked about, in atomic units. */
+    checkedAmountAtomic: string;
+    /**
+     * Context, AUTHORITY not holdings: the agent's remaining spend authority
+     * for the requested token, in atomic units — the same derivation
+     * {@link HavenAllowanceSummary} reports (`onchain.remaining`; the #1090
+     * derivation, the #1145 enforcer read). Zero when no active budget row
+     * names the token. Compare it with `covered`, never instead of it.
+     */
+    budgetRemainingAtomic: string;
+    /**
+     * Provenance of `budgetRemainingAtomic` (#1319, same semantics as
+     * {@link HavenAllowance.onchain.remainingIsFromChain}): true when the
+     * budget figure came from a live enforcer read, false when it fell back
+     * to the configured budget. Absent when no budget row existed for the
+     * token (nothing was read).
+     */
+    budgetRemainingIsFromChain?: boolean;
+}
+/**
+ * Affirmative spend-readiness for the authenticated agent, derived from the raw
+ * agent status plus the remaining spend authority the backend reports per rail
+ * (the active budget delegation on the delegation rail — #1135; the retired
+ * AllowanceModule rail used an on-chain allowance instead):
+ * - `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 retired
+ *                     AllowanceModule rail the payment was 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.
+ *
+ * #3128: a deliberately DIFFERENT view of the same allowance as
+ * {@link HavenAllowance} — flat, no `onchain` block, no spent/nonce/reset-time
+ * detail — but never a disjoint one: every field here is present on or
+ * derived from the {@link HavenAllowance} with the same `id`, and
+ * `remainingAtomic` / `remainingDisplay` equal that allowance's
+ * `onchain.remaining` / `remainingDisplay` byte for byte (pinned by test). A
+ * client that wants the id AND a display amount can therefore use either
+ * read alone.
+ */
+interface HavenAgentAllowanceSummary {
+    /** #3128: the {@link HavenAllowance.id} this row summarises. */
+    id: string;
+    tokenSymbol: string;
+    /** #3128: the {@link HavenAllowance.tokenAddress}. */
+    tokenAddress: 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[];
+}
+/**
+ * #2960 — one party vocabulary for "who paid" a Haven payment, additive
+ * alongside every existing lone `payer*`/`*Address` field (same discipline
+ * as the #2907 `safe`/`account` dual-emit, except these four are DISTINCT
+ * addresses, not same-value twins of one old field).
+ */
+interface PaymentParties {
+    treasuryAccount: string | null;
+    delegate: string | null;
+    delegateAccount: string | null;
+    merchant: string | null;
+}
+/** @internal wire shape of {@link PaymentParties}. */
+interface RawPaymentParties {
+    treasury_account: string | null;
+    delegate: string | null;
+    delegate_account: string | null;
+    merchant: string | null;
+}
+/**
+ * #3132 (owner decision 3 on #3130): what population a list row came from and
+ * what narrowed it, as two values. Receipts are `{ source: 'agent', filter:
+ * null }` — this agent's evidence rows only, no query-time narrowing. The
+ * wallet feed (`GET /transactions`, the CLI's `activity list`) is
+ * `source: 'wallet'` with `filter: 'agent'` when `agentId` narrows it, and it
+ * is a DIFFERENT population (explorer window plus synthesized intents; sweeps
+ * and funding legs included), never this view. A receipt read is not a
+ * transaction-history read.
+ */
+interface HavenListScope {
+    source: 'wallet' | 'agent';
+    filter: 'agent' | 'account' | 'account+agent' | null;
+}
+interface HavenPaymentReceipt {
+    id: string;
+    /** #3132: present when the backend states it (absent on an older backend). */
+    scope?: HavenListScope;
+    paymentId: string;
+    paymentIntentId?: string | null;
+    approvalRequestId?: string | null;
+    /**
+     * #3134: the payment protocol this receipt settled on — one of the
+     * evidence-eligible rails (`x402`, `mpp_demo`, `mpp_crypto`, `spt`) — under the
+     * name the transactions feed uses for the same concept. Distinct from
+     * `scope.source`, which names the LIST population (#3132) — the transaction
+     * row carries the same two. Same name, narrower domain: never `'direct'`
+     * here — the feed's SQL default for an intent that names no protocol has no
+     * receipt analogue, because no protocol means no evidence row.
+     */
+    source: string;
+    /** @deprecated (#3134) twin of {@link source}; removed once all three release clocks have moved — see `mapPaymentReceipt`. */
+    rail: string;
+    /**
+     * #3134: the evidence row's recorded proof status, under the transactions
+     * feed's name. Same name, different nullability: `string` here because a
+     * receipt IS the evidence row, `string | null` on the feed, where a row may
+     * LEFT JOIN to none (#3132) — do not share a non-null-asserting helper.
+     */
+    paymentProofStatus: string;
+    /** @deprecated (#3134) twin of {@link paymentProofStatus}; removed once all three release clocks have moved — see `mapPaymentReceipt`. */
+    proofStatus: string;
+    /**
+     * @deprecated (#2998) meaning depends on the settlement scheme — the
+     * account → delegate funding transaction on eip3009, the (only) settlement
+     * transaction on erc7710. Prefer {@link fundingTxHash} / {@link settlementTxHash}, which
+     * name which is which.
+     */
+    txHash: string;
+    /** The account → delegate funding transaction, relayed by Haven (#2998); null on erc7710 (no funding leg) and on retired mpp-rail rows. */
+    fundingTxHash: string | null;
+    /**
+     * The delegate → merchant settlement transaction (#2998). Trust level differs
+     * by scheme: on erc7710 it is `txHash` itself and Haven VERIFIED it on-chain
+     * before the receipt existed; on eip3009 it is the merchant's claim as relayed
+     * (PAYMENT-RESPONSE), NOT verified on-chain by Haven — cite it as such.
+     */
+    settlementTxHash: string | null;
+    chainId: number;
+    /** #3134: the paid resource, under the transactions feed's protocol-prefixed name (`string | null` there; a receipt always has one). */
+    x402ResourceUrl: string;
+    /** @deprecated (#3134) twin of {@link x402ResourceUrl}; removed once all three release clocks have moved — see `mapPaymentReceipt`. */
+    resourceUrl: string;
+    /** #3134: the merchant paid, under the transactions feed's protocol-prefixed name. */
+    x402MerchantAddress: string | null;
+    /** @deprecated (#3134) twin of {@link x402MerchantAddress}; removed once all three release clocks have moved — see `mapPaymentReceipt`. */
+    merchantAddress: string | null;
+    payerAddress: string;
+    /** #2960: additive alongside `payerAddress` above (`parties.treasury_account` only). */
+    parties?: PaymentParties;
+    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;
+    /**
+     * #3125 — the merchant's `PAYMENT-RESPONSE` object relayed VERBATIM:
+     * opaque, unvalidated, unverified, MERCHANT-CONTROLLED third-party data.
+     * Haven neither authors nor verifies anything inside it, including
+     * `protocolReceiptPayload.payer` —
+     * that `payer` is the merchant's claim, NOT Haven's record, and is not
+     * {@link payerAddress} (Haven's own, authoritative; field observation
+     * 2026-09-18: the two held different addresses on every row read). For who
+     * paid, read `parties` ({@link PaymentParties}) — `treasuryAccount`,
+     * `delegate`, `delegateAccount`, `merchant` are Haven-derived and
+     * authoritative; anything inside this object is not.
+     *
+     * Deliberately NOT namespaced or key-prefixed on the wire (#3125): the
+     * relay must stay the merchant's object verbatim (its `transaction` key
+     * feeds `settlementTxHash`), and prefixing the envelope could not prefix
+     * the merchant-controlled keys inside it — the `payer` collision lives
+     * there, so provenance is made legible at the read surfaces instead (this
+     * comment and the tool descriptions).
+     */
+    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 agent's Haven account. */
+'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 agent's Haven account) */
+    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 account 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.
+     *
+     * #2914: the account-vocabulary spelling, and the only one — the
+     * pre-#2907 `fund_safe_or_raise_allowance` wire value (and the
+     * `AgentPaymentNextActionAccountAlias` seam #2908 added to bridge it) are
+     * retired along with the rest of the #2908 compatibility window.
+     */
+    readonly FundAccountOrRaiseAllowance: "fund_account_or_raise_allowance";
+    /**
+     * The delegate wallet may hold funds that were sent from the agent's Haven
+     * account but never settled to the merchant. The wallet owner should initiate
+     * a sweep to return those funds to that account.
+     */
+    readonly SweepStrandedFunds: "sweep_stranded_funds";
+    /**
+     * #2970: a `submitted` erc7710 x402 intent whose settlement window has
+     * passed with no on-chain settlement evidence Haven could verify. Distinct
+     * from {@link CheckStatusLater}, which this REPLACES once the window is
+     * past — but it is not futile: Haven's settlement sweep (120s tick) scans
+     * each candidate over its own window plus a 120s clock-skew allowance, so
+     * it can still attribute the settlement for a short while after this value
+     * first appears. Poll {@link CheckStatusLater}'s tool
+     * (`haven_get_payment_status`) once more, roughly two minutes later; if it
+     * still shows no evidence, tell the user the goods were delivered but
+     * Haven holds no verified settlement evidence for this payment. If the
+     * agent holds the merchant's real settlement transaction hash (from
+     * `PAYMENT-RESPONSE`'s `transaction` field, or a prior settle/complete
+     * result's `settlement_tx_hash`), report it with the hosted
+     * `haven_report_settlement_evidence` tool instead of waiting —
+     * `haven_report_x402_outcome` takes no hash and refuses a non-`confirmed`
+     * intent.
+     */
+    readonly AwaitingSettlementEvidence: "awaiting_settlement_evidence";
+};
+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 merchant rejected the paid retry. On eip3009 the funding leg had succeeded (sweep);
+     *  on erc7710 there is no funding leg — nothing to sweep, follow the message (#2983). */
+    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
+     *  may still settle late, so the guidance is verify-then-act. On eip3009
+     *  the funding leg had succeeded (verify-then-sweep); on erc7710 there is
+     *  no funding leg — nothing to sweep, follow the message (#3000). */
+    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";
+    /**
+     * #2979: the merchant answered a `tools/call` probe with its own
+     * machine-readable "cannot settle right now" refusal (HTTP 503,
+     * `{ error: 'merchant_not_ready', reason_code, ... }`) instead of a 402
+     * challenge — e.g. its settlement wallet is out of gas. No 402 was ever
+     * issued and no payment was created; this is honest and (per
+     * `retry_after_s`, when present) usually transient, unlike a permanent
+     * endpoint miss.
+     */
+    readonly MerchantNotReady: "MERCHANT_NOT_READY";
+};
+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 account, redeemed through the agent's budget delegation. */
+    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_account_or_raise_allowance" | "sweep_stranded_funds" | "awaiting_settlement_evidence")[];
+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" | "MERCHANT_NOT_READY")[];
+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";
+    /**
+     * #2991: the quote tools' `expected_settlement_scheme` prediction of what
+     * `haven_prepare_catalog_purchase` / `haven_pay_mcp_tool` will actually
+     * select could not be computed — the agent's execution rail could not be
+     * read from Haven, so `expected_settlement_scheme` is `null` rather than a
+     * guess. `accepted_scheme` (the merchant's offer) is unaffected.
+     */
+    readonly X402SchemeUnknown: "X402_SCHEME_UNKNOWN";
+    /**
+     * #2968: the merchant answered 200 and handed over goods, but Haven holds NO
+     * on-chain evidence that the payment moved. `settled: false` beside this code
+     * is not a failure — it is the absence of proof, and the two must travel
+     * together so an agent can tell "the user has the goods" apart from "the
+     * money moved". Carries the intent's `expires_at`: after that instant the
+     * settlement can no longer land at all.
+     */
+    readonly SettlementUnconfirmed: "SETTLEMENT_UNCONFIRMED";
+};
+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 {
+    /** From `AgentPaymentNextAction`. */
+    next_action: AgentPaymentNextAction;
+    /**
+     * Claude-family namespaced tool name for the next call
+     * (`mcp__<server>__<tool>`), when one exists.
+     *
+     * **Namespaced with the DEFAULT server names**, which is the most the hosted
+     * server can know: local server names are the client's own config and never
+     * reach Haven. Two runtimes are already not the default — Codex names servers
+     * by config key (`haven`, `haven_signer`), and a connector run with
+     * `--name <slug>` wires `haven-<slug>` / `haven-signer-<slug>` (#1694). On
+     * either, this field and `next_tool_server` name a server the client does not
+     * have. Prefer {@link AgentNextStep.next_tool_server_role} plus
+     * {@link AgentNextStep.next_tool_name} whenever your servers are not the
+     * default pair; see #2550.
+     */
+    next_tool?: string;
+    /**
+     * The server half of `next_tool`, unprefixed — `haven` or `haven-signer`.
+     * Carries the same default-name caveat as `next_tool` (#1588, #2550).
+     */
+    next_tool_server?: string;
+    /** The bare tool name, callable on whichever server plays the role below. */
+    next_tool_name?: string;
+    /**
+     * Which of the CLIENT'S OWN servers to call (#2550). Runtime-neutral, and
+     * the field to resolve against when your server names are not the defaults —
+     * it names a role rather than a name the hosted server had to guess.
+     */
+    next_tool_server_role?: 'hosted' | 'signer';
+    /** Small literal arguments for next_tool. Bulky fields are referenced by reason. */
+    next_arguments?: Record<string, unknown>;
+    /**
+     * #3101 (epic #3105, decision 3): present exactly when `next_tool` is
+     * absent — why no tool is named (the payment id is unknown, nothing is left
+     * to do, the arguments could not be built). `next_tool` is never null.
+     */
+    next_tool_omitted_reason?: string;
+    /** 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;
+    /** #2960: additive alongside `payerAddress` above (`parties.delegate` only). */
+    parties?: PaymentParties;
+    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 for the listing; the catalog refresh probe still
+     * checks the endpoint, see `verifiedPayable`). `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 — the one ownership claim. See the epic's trust claim (never merchant honesty or quality). */
+    domainVerified: boolean;
+    /**
+     * True when Haven watched this endpoint answer a live quote (#2978): the
+     * directory probe for `ingestion` rows, the periodic catalog refresh probe
+     * for `operator` rows (`status === 'active'` with `verifiedAt` set). False
+     * for a degraded row of either source. `discoverTools({ verified:
+     * 'verified' })` filters on this field, not on `source`.
+     */
+    verifiedPayable: boolean;
+    /**
+     * The merchant this entry belongs to (#3078). OPTIONAL on purpose: an
+     * installed SDK may face a backend that predates the merchant layer, and
+     * `discoverTools` must keep working against it — the field is absent, not
+     * null, in that case.
+     */
+    merchant?: HavenCatalogMerchant;
+}
+/** A catalog entry's merchant as the wire carries it (#3078). */
+interface HavenCatalogMerchant {
+    id: string;
+    slug: string;
+    name: string;
+    /** `coming_soon` never reaches an entry in practice (a prospect has no offers). */
+    listingStatus: 'live' | 'coming_soon';
+    /** Haven-run test content: the demo store and the stranded-funds fixture. */
+    isTestMerchant: boolean;
+}
+/**
+ * #3128: one page of receipts. `total` is the count Haven holds for the
+ * agent (an empty page with `total: 0` means no receipt exists — there is no
+ * indexing delay behind this list); `hasMore` says the page was cut at the
+ * limit; `nextCursor` is fed back as `cursor` for the next page. Against a
+ * backend older than #3128 the three are `null` — "unknown", never a
+ * fabricated 0 / false.
+ */
+interface HavenPaymentReceiptsPage {
+    receipts: HavenPaymentReceipt[];
+    total: number | null;
+    hasMore: boolean | null;
+    nextCursor: string | null;
+}
+/** @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";
+    /**
+     * #2979: `body` is the merchant's own JSON, when the non-402 response
+     * carried one — e.g. the demo merchant's `/mcp` readiness gate answers
+     * `503 { error: 'merchant_not_ready', reason_code, ... }`. Optional and
+     * best-effort: a non-JSON or unreadable body leaves this `undefined`, same
+     * as before this field existed. Consumers key on it (not on the message
+     * string) to distinguish an honest, machine-readable merchant refusal from
+     * a genuine "this is not the x402 endpoint" miss, which otherwise look
+     * identical — both are just "some non-402 status".
+     */
+    constructor(message: string, statusCode: number, body?: unknown);
+}
+/**
+ * #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);
+}
+/**
+ * #2972: `MerchantCompletion.reportSettlementEvidence` /
+ * `HavenClient.reportSettlementEvidence` refuse a `0x00…00` settlement hash
+ * BEFORE any network call — see `isZeroSettlementTxHash`. That marker is
+ * never a real transaction (the demo merchant's own "delivered, not settled"
+ * value), so posting it to `POST /machine-payments/evidence` could only ever
+ * come back refused, at the cost of a real round trip. A typed error rather
+ * than a `HavenApiError`-shaped 400: no request was ever attempted, so there
+ * is no HTTP status or response body to carry.
+ */
+declare class HavenZeroSettlementHashError extends HavenError {
+    constructor(paymentId: 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;
+    /** The agent's Haven account 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;
+
+/**
+ * Client identity on Haven API requests (#3303, epic #3302).
+ *
+ * Every published Haven client names itself with one header,
+ * `X-Haven-Client: <package>/<version>`, so the backend can tell an outdated
+ * client what to run — a `client_update` hint on its responses, or, only below
+ * a minimum the deployment has explicitly set, a 426 `client_outdated` refusal
+ * at the payment-initiating routes (the signer: at sign-context). The backend's
+ * table and decision live in `@haven_ai/core`'s `client-compat.ts`; this module
+ * is the client half and deliberately holds no thresholds.
+ *
+ * Deliberately free of any other SDK import so `@haven_ai/sdk/edge` (the
+ * signer's ethers-free entry) can re-export it.
+ */
+/**
+ * This SDK's own version. Owned by `scripts/release-bump.mjs`, which rewrites
+ * it with the package version on every release — never hand-edit it.
+ */
+declare const SDK_VERSION = "0.5.0-alpha.1";
+/** The request header every published Haven client sends. */
+declare const HAVEN_CLIENT_HEADER = "X-Haven-Client";
+/** `<package>/<version>` — the value of {@link HAVEN_CLIENT_HEADER}. */
+declare function havenClientIdentity(pkg: string, version: string): string;
+/** What a bare SDK embedder sends when it names no package of its own. */
+declare const SDK_CLIENT_IDENTITY: string;
+/**
+ * The `client_update` object the backend attaches to a response when this
+ * client is behind (`required: false`) or below a set minimum
+ * (`required: true`). Every field is the backend's; the SDK never computes one.
+ */
+interface HavenClientUpdate {
+    package: string;
+    current: string;
+    recommended: string | null;
+    min_version: string | null;
+    required: boolean;
+    upgrade_command: string;
+    notes_url: string | null;
+}
+/** Narrow an unknown response field to a {@link HavenClientUpdate}, or undefined. */
+declare function readClientUpdate(value: unknown): HavenClientUpdate | undefined;
+
+/**
+ * #3101 (epic #3105, slice 2/5): the typed next-step builder.
+ *
+ * Every hosted payment tool ends by naming the agent's next tool and its
+ * arguments (#1308). Until this module, the tool was a free string and the
+ * arguments a `Record<string, unknown>`, so nothing tied the keys to the tool
+ * named beside them — three sites handed `{ payment_id: null }` to a tool
+ * whose `payment_id` is a required string, and the compiler could not see it.
+ *
+ * The builder is generic over a TARGET MAP the caller supplies: bare tool
+ * name → { role, validate }. It is deliberately schema-library-agnostic (the
+ * SDK carries no zod): the hosted server derives each target's argument type
+ * from its own zod shape and passes a `validate` closure; this module only
+ * needs to know the role (to render `mcp__<server>__<tool>`) and how to say
+ * whether arguments parse. Keyed on the bare name + role (decision 1) so the
+ * namespaced string is rendered in exactly one place and the runtime-neutral
+ * `next_tool_server` / `next_tool_name` / `next_tool_server_role` fields are
+ * derived from the same input rather than parsed back out of a literal.
+ *
+ * Decisions 3 and 8: `nextTool` is REQUIRED on the input and may be `null` —
+ * a site that forgets it is a compile error; a site with no next tool says
+ * why, and the wire omits `next_tool` and carries `next_tool_omitted_reason`.
+ * `next_tool` is never null on the wire.
+ */
+type NextToolServerRole = 'hosted' | 'signer';
+/** The DEFAULT server name each role is wired under (#1588, #2550). */
+declare const NEXT_TOOL_SERVER_NAMES: Record<NextToolServerRole, string>;
+/** Default server name → role. An unknown server yields no role rather than a guess (#2550). */
+declare const NEXT_TOOL_SERVER_ROLES: Record<string, NextToolServerRole>;
+/** Renders the Claude-family namespaced tool name — the one string clients have followed since #1308. */
+declare function renderNextTool(role: NextToolServerRole, name: string): string;
+/** Parses a namespaced literal back into its parts; `role` is absent for an unknown server. */
+declare function parseNextTool(literal: string): {
+    server: string;
+    name: string;
+    role?: NextToolServerRole;
+} | null;
+/**
+ * One target the builder may hand off to. `TArgs` is the argument type the
+ * caller derived from the tool's declared schema; `validate` is the runtime
+ * twin of that type and returns `null` when the arguments parse, else why not.
+ */
+interface NextStepTarget<TArgs> {
+    role: NextToolServerRole;
+    validate: (input: unknown) => string | null;
+    /** Phantom carrier for the argument type; never read at runtime. */
+    readonly _args?: TArgs;
+}
+type NextStepTargets = Record<string, NextStepTarget<unknown>>;
+/** The argument type a target carries. */
+type NextStepArguments<Targets extends NextStepTargets, T extends keyof Targets> = Targets[T] extends NextStepTarget<infer A> ? A : never;
+/**
+ * The handoff half of a next step: a registered tool with arguments that
+ * tool accepts, or no tool with the reason. A discriminated union over the
+ * target map's keys, so a wrong key, a missing required key, an unregistered
+ * tool name and an omitted `nextTool` are each a compile error at the site.
+ */
+type NextStepHandoff<Targets extends NextStepTargets> = {
+    [T in keyof Targets & string]: {
+        nextTool: T;
+        nextArguments: NextStepArguments<Targets, T>;
+    };
+}[keyof Targets & string] | {
+    nextTool: null;
+    nextToolOmittedReason: string;
+};
+type NextStepInput<Targets extends NextStepTargets> = NextStepHandoff<Targets> & {
+    nextAction: AgentPaymentNextAction;
+    safeToContinue: boolean;
+    reason: string;
+};
+/** The wire shape: `AgentNextStep` (its `next_tool` family) — never a null `next_tool`. */
+type NextStep = AgentNextStep;
+/**
+ * Per-`next_action` default tool (decision 9): the tool a site names unless it
+ * has a reason to override. Only actions with ONE sensible target are listed;
+ * `retry_original_x402_request` is absent because its only live emitter names
+ * no tool on purpose (the agent's own HTTP retry); `sign_and_submit_payment`
+ * is absent because the signer tool
+ * depends on the settlement scheme (`haven_sign` for erc7710 delegations,
+ * `haven_sign_x402` for the EIP-3009 bridge) and a wrong default there would be
+ * worse than none.
+ */
+declare const DEFAULT_NEXT_TOOL_BY_ACTION: {
+    readonly check_status_later: "haven_get_payment_status";
+    readonly sweep_stranded_funds: "haven_sweep_delegate";
+};
+declare function defaultNextToolFor(action: AgentPaymentNextAction): string | undefined;
+/**
+ * Builds a `nextStep` function bound to a target map. The returned function
+ * renders the wire fields from the bare name + role, and re-validates the
+ * arguments at runtime: on a mismatch it FAILS SAFE — omits the tool and says
+ * why in `next_tool_omitted_reason` — rather than throwing out of a handler
+ * that has already moved money. The compile-time twin makes that branch
+ * unreachable from typed sites; it exists for callers that bypass the types.
+ */
+declare function createNextStepBuilder<Targets extends NextStepTargets>(targets: Targets): (input: NextStepInput<Targets>) => NextStep;
+
+/**
+ * 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 = "alpha";
+/** 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). This cap applies only to the signed authorization, never to the
+ * advertised requirements echoed in `accepted`. A merchant requiring more
+ * than the bounded lifetime can still reject at verification; preserving its
+ * offer does not widen Haven's signing policy.
+ */
+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 two-leg bridge the account→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;
+
+/**
+ * #3271: the integrity check every client runs before signing a direct
+ * delegation-rail payment's typed data.
+ *
+ * A direct payment (`POST /payments`, surfaced as `haven_send` / `haven_pay`)
+ * is signed as the HybridDeleGator's EIP-712 `PackedUserOperation`, and Haven
+ * returns two things for it: that typed data, and `payload_hash` — the
+ * ERC-4337 v0.7 UserOperation hash of the same operation. Nothing used to tie
+ * the two together at signing time. The typed data is multi-KB and reaches the
+ * signer through a language model when it is relayed by hand, so one corrupted
+ * character produced a valid-looking signature over the wrong digest, and the
+ * first sign of it was `AA24 signature error` from the bundler (#3271,
+ * reproduced on dev 2026-09-24).
+ *
+ * This recomputes the v0.7 hash from the typed data's own message and domain
+ * and refuses unless it equals `payload_hash`, and it pins the parts of the
+ * typed data the hash does NOT cover (domain name/version/verifyingContract,
+ * the field list, the EntryPoint). It is a CORRUPTION check: the caller supplies
+ * both values, so it proves they describe the same operation, never that Haven
+ * prepared it. Provenance is the byte-free sign context (`payment_id`); what a
+ * delegate key will sign at all is `assertBoundDirectPaymentUserOp`
+ * (`direct-payment-guard.ts`, #3272 / #3283), which every caller of this check
+ * — `HavenClient.signForData` and the signer's `haven_sign` — runs next.
+ *
+ * Pure viem, no ethers: `@haven_ai/sdk/edge` re-exports it for the edge signer,
+ * and `edge-imports.test.ts` pins that graph.
+ */
+/** Version of the direct-payment sign context (`GET /payments/:id/sign-context`). */
+declare const DIRECT_SIGN_CONTEXT_VERSION = 1;
+/** The ERC-4337 v0.7 EntryPoint — the only one the delegation rail submits to. */
+declare const ENTRY_POINT_V07 = "0x0000000071727De22E5E9d8BAf0edAc6f37da032";
+/**
+ * The HybridDeleGator EIP-712 domain constants and the `PackedUserOperation`
+ * field list, vendored from `@metamask/smart-accounts-kit`
+ * (`contracts.HybridDeleGator.constants`, `SIGNABLE_USER_OP_TYPED_DATA`) so the
+ * published packages need no runtime dependency on the kit. Pinned equal to the
+ * kit's values by `userop-binding.test.ts`.
+ */
+declare const HYBRID_DELEGATOR_DOMAIN_NAME = "HybridDeleGator";
+declare const HYBRID_DELEGATOR_DOMAIN_VERSION = "1";
+declare const PACKED_USER_OPERATION_FIELDS: ReadonlyArray<{
+    name: string;
+    type: string;
+}>;
+/** Refusal raised when UserOperation typed data (a direct payment, or the SDK's x402 funding leg) does not match its `payload_hash`. */
+declare class HavenUserOpBindingError extends HavenError {
+    constructor(message: string);
+}
+/** True when the typed data is a `PackedUserOperation` (the direct-payment shape). */
+declare function isPackedUserOperationTypedData(value: unknown): boolean;
+/**
+ * Compute the ERC-4337 v0.7 UserOperation hash from a HybridDeleGator
+ * `PackedUserOperation` typed-data object — the value Haven returns as
+ * `payload_hash` for a direct payment (`getUserOperationHash`, entryPoint 0.7).
+ */
+declare function packedUserOperationHash(typedData: unknown): Hex;
+/**
+ * Refuse (throw `HavenUserOpBindingError`) unless this `PackedUserOperation`
+ * typed data is the operation `payloadHash` names, in the HybridDeleGator
+ * domain of its own sender, against the v0.7 EntryPoint. Returns the
+ * recomputed hash.
+ */
+declare function assertUserOpTypedDataBinding(typedData: unknown, payloadHash: string): Hex;
+
+/**
+ * The counterfactual HybridDeleGator account address for an owner EOA (#3272).
+ *
+ * `haven_sign`'s unbound branch (`@haven_ai/signer`'s `tools.ts`) and, since
+ * #3283, `HavenClient.signForData` (`direct-payment-guard.ts`) sign a
+ * `PackedUserOperation`
+ * only when its `sender` (== `domain.verifyingContract`) is THIS SIGNER'S OWN
+ * delegate account — never any other HybridDeleGator, and never a third
+ * party's. Haven provisions that account counterfactually at signup (#970):
+ * it may have zero on-chain transactions, so the signer must be able to
+ * compute its address OFFLINE, from nothing but the delegate key's own
+ * address.
+ *
+ * This is exactly what `@metamask/smart-accounts-kit`'s
+ * `getCounterfactualAccountData` computes for
+ * `implementation: 'Hybrid'`, `deployParams: [owner, [], [], []]` (no passkey
+ * co-owners — the only shape Haven's signup flow provisions), `deploySalt:
+ * '0x'`: CREATE2 of an `ERC1967Proxy(HybridDeleGatorImpl, initialize(owner,
+ * [], [], []))` behind the `SimpleFactory`.
+ *
+ * VENDORED, NOT IMPORTED. `@metamask/smart-accounts-kit` is a devDependency
+ * only (see `package.json`) — this package installs on users' machines and
+ * must not carry it at runtime. The constants below (the factory and
+ * implementation addresses, the `ERC1967Proxy` bytecode) are copied from the
+ * kit's pinned environment / `@metamask/delegation-abis`' bytecode export,
+ * exactly like `settlement-child.ts` vendors the DelegationManager and caveat
+ * enforcer addresses for the same reason. Cross-checked against the kit by
+ * `packages/signer/src/delegate-account.pins.test.ts`, including against the real, on-chain
+ * `direct-payment-userop.json` fixture.
+ */
+
+/**
+ * SimpleFactory — deterministically deployed, so Base and Base Sepolia share
+ * the address (matches `packages/backend/src/rails/delegation-contracts.ts`'s
+ * `simpleFactory` pin for both chains).
+ */
+declare const SIMPLE_FACTORY_ADDRESS: Address;
+/**
+ * HybridDeleGator implementation — matches `delegation-contracts.ts`'s
+ * `hybridDeleGatorImpl` pin for both chains.
+ */
+declare const HYBRID_DELEGATOR_IMPLEMENTATION: Address;
+/**
+ * Derive the counterfactual HybridDeleGator account address for `owner`, with
+ * no passkey co-owners — the only shape Haven's signup flow provisions
+ * (#970). Pure and offline: no RPC call, no dependency on the account having
+ * been deployed. Verified byte-for-byte against
+ * `@metamask/smart-accounts-kit`'s `getCounterfactualAccountData` by
+ * `packages/signer/src/delegate-account.pins.test.ts`, including against a real Base Sepolia payload served by the dev backend
+ * (`direct-payment-userop.json`).
+ */
+declare function deriveDelegateAccountAddress(owner: Address): Address;
+
+/**
+ * Independent verification of an erc7710 x402 settlement child (#1455).
+ *
+ * Moved from `@haven_ai/signer` into the SDK by #3283 (epic #3284) so the
+ * signer and `HavenClient.signForData` run ONE verifier. The signer checks the
+ * child against the Haven-signed expected context; the SDK checks it against
+ * the merchant's own 402, which Haven does not produce.
+ *
+ * WHY THIS EXISTS. `assertExpectedBinding` proves Haven *declared* a payload:
+ * the expected context is signed by `HAVEN_X402_BINDING_SIGNER` and commits to
+ * the digest of the exact bytes being signed. That is a real property, and it
+ * is not this one. It says nothing about what the payload MEANS.
+ *
+ * A backend that declared `merchantTo = the real merchant` while pinning a
+ * different payee in the child's `AllowedCalldata` caveat would produce a
+ * perfectly consistent pair: the declaration binds the digest, the digest is
+ * the child's, and the child pays someone else. The signature is the authority
+ * here — the merchant's facilitator redeems it and pulls from the treasury — so
+ * the signer has to re-derive the meaning locally or it is a pass-through with
+ * extra steps.
+ *
+ * ADDRESSES ARE PINNED HERE ON PURPOSE. Reading the enforcer map from Haven
+ * would make the check circular: an attacker who can pick which contract counts
+ * as "the payee enforcer" can satisfy any comparison. Taking
+ * `@metamask/smart-accounts-kit` as a runtime dependency was the other option
+ * and was rejected — this package installs on users' machines. The constants
+ * below are snapshot-pinned and cross-checked against the kit by a test
+ * (`packages/signer/src/settlement-child.pins.test.ts`), the same pattern
+ * `packages/core/src/chains.ts` uses against its registry.
+ *
+ * EXTRA CAVEATS ARE ALLOWED, and that is deliberate — verified, not assumed
+ * (#1455 review challenged it directly).
+ *
+ * `DelegationManager.redeemDelegations` loops every caveat of every delegation
+ * and calls `beforeHook` on each, with no break and no try/catch: a single
+ * revert aborts the whole redemption, and nothing lets one caveat cause another
+ * to be skipped. Top-level caveats are therefore strictly AND-ed, so one this
+ * file does not recognise can only add a constraint, never remove one.
+ *
+ * The specific challenge was `LogicalOrWrapperEnforcer`, whose terms encode
+ * several caveat GROUPS and whose own security notice warns that "the redeemer
+ * can select the least restrictive group, bypassing stricter requirements in
+ * other groups". That warning is about groups INSIDE the wrapper — it binds
+ * whoever authors wrapper terms. The wrapper is itself one caveat among the
+ * delegation's, so it is AND-ed with the four required below and cannot unlock
+ * them.
+ *
+ * The shape that WOULD be dangerous is the inverse: a required caveat hidden
+ * inside a wrapper group instead of sitting at top level, where the redeemer
+ * could select a group that omits it. This file scans top-level caveats and
+ * refuses on absence, so that child is refused for lacking the caveat — which
+ * is the correct outcome and is pinned by a test.
+ */
+/** DelegationManager, the EIP-712 `verifyingContract` for a delegation. */
+declare const DELEGATION_MANAGER = "0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3";
+/**
+ * Caveat enforcers, by role. Deterministically deployed, so Base and Base
+ * Sepolia share addresses — verified for both chains by the pin test.
+ */
+declare const CAVEAT_ENFORCERS: {
+    readonly erc20TransferAmount: "0xf100b0819427117EcF76Ed94B358B1A5b5C6D2Fc";
+    readonly allowedCalldata: "0xc2b0d624c1c4319760C96503BA27C347F3260f55";
+    readonly timestamp: "0x1046bb45C8d673d4ea75321280DB34899413c069";
+    readonly redeemer: "0xE144b0b2618071B4E56f746313528a669c7E65c5";
+};
+/** The backend's own ceiling (`MAX_SETTLEMENT_WINDOW_SECONDS`), enforced again here. */
+declare const MAX_SETTLEMENT_WINDOW_SECONDS = 600;
+interface SettlementChildTypedData {
+    domain: {
+        name?: string;
+        version?: string;
+        chainId?: number | string;
+        verifyingContract?: string;
+    };
+    types: Record<string, unknown>;
+    primaryType: string;
+    message: Record<string, unknown>;
+}
+/** True when this typed data is a delegation — the shape that must never be signed unbound. */
+declare function isSettlementChildTypedData(value: unknown): value is SettlementChildTypedData;
+/**
+ * Map an x402 network string to a chain id. Local on purpose (#1455 review):
+ * the chain must come from Haven's SIGNED `network` field, never from the
+ * payload under verification — see `verifySettlementChild`.
+ */
+declare function chainIdForNetwork(network: string | undefined): number | undefined;
+interface SettlementChildExpectation {
+    merchantTo: string;
+    amount: string;
+    asset: string;
+    /**
+     * Derived from the expected context's SIGNED `network`, never from
+     * `typedData.domain.chainId`. Comparing the payload's own claim against
+     * itself is a check that cannot fail — which is exactly what shipped in the
+     * first draft of this file's call site, and what the review caught.
+     */
+    chainId: number;
+    /** ISO timestamp; the child must not outlive it. */
+    expiresAt?: string;
+    /**
+     * #3283 / #3281 criterion 8: the signer's OWN derived delegate account.
+     * When set, the child's `delegator` must be exactly this account — the
+     * child is a re-delegation of this agent's budget, never a grant from some
+     * other account the key happens to control.
+     */
+    delegatorAccount?: string;
+    /**
+     * #3283: the facilitator addresses the merchant's 402 advertised
+     * (`extra.facilitatorAddresses`). When non-empty, the child must carry a
+     * `RedeemerEnforcer` caveat pinning exactly this set — otherwise the child
+     * is a bearer instrument any party could redeem within its bounds.
+     */
+    redeemers?: readonly string[];
+}
+/** `@metamask/delegation-core`'s `ROOT_AUTHORITY` — a delegation chained to nothing. */
+declare const ROOT_AUTHORITY: string;
+/**
+ * Verify a settlement child implements what the expected context declares.
+ * Throws `HavenSigningError` on any disagreement; returns nothing on success.
+ *
+ * `now` is injectable so the expiry checks are testable without faking clocks.
+ */
+declare function verifySettlementChild(typedData: SettlementChildTypedData, expected: SettlementChildExpectation, now?: number): void;
+
+/** Wire code for a typed-data payload outside the signable allowlist. */
+declare const TYPED_DATA_NOT_ALLOWED: "TYPED_DATA_NOT_ALLOWED";
+/**
+ * A typed-data payload was refused before signing because it is not a shape
+ * a delegate key may sign. Nothing was signed. `@haven_ai/signer` subclasses
+ * this to attach its MCP next step; the `code` is the same on both.
+ */
+declare class HavenTypedDataRefusedError extends HavenSigningError {
+    readonly code: typeof TYPED_DATA_NOT_ALLOWED;
+    constructor(message: string);
+}
+/**
+ * Chains the delegation rail has PINNED delegation contracts for
+ * (`packages/backend/src/rails/delegation-contracts.ts`) — the only chains a
+ * direct-payment UserOp may be scoped to. Gnosis (100) has no pinned
+ * DelegationManager/enforcer set, so it is deliberately excluded even though
+ * the delegate account itself could exist there.
+ */
+declare const DIRECT_PAYMENT_CHAIN_IDS: ReadonlySet<number>;
+/** The DeleGator's single-execution `execute((address,uint256,bytes))` — selector `0x5c1c6dcd`. */
+declare const EXECUTE_ABI: readonly [{
+    readonly type: "function";
+    readonly name: "execute";
+    readonly inputs: readonly [{
+        readonly name: "_execution";
+        readonly type: "tuple";
+        readonly components: readonly [{
+            readonly name: "target";
+            readonly type: "address";
+        }, {
+            readonly name: "value";
+            readonly type: "uint256";
+        }, {
+            readonly name: "callData";
+            readonly type: "bytes";
+        }];
+    }];
+    readonly outputs: readonly [];
+    readonly stateMutability: "payable";
+}];
+/**
+ * The content + provenance allowlist (#3272 criteria 1–2). Call ONLY after
+ * `assertUserOpTypedDataBinding` has already proven `typedData` is a
+ * well-formed `PackedUserOperation` matching its own hash — this function
+ * trusts `typedData.domain`/`message` are shaped correctly and checks only
+ * what they SAY. Throws `HavenTypedDataRefusedError` (never returns) on any
+ * disagreement.
+ */
+declare function assertBoundDirectPaymentUserOp(typedData: Record<string, unknown>, delegateAddress: string): void;
+
+/**
+ * The settlement-child half of the same surface (#3283): verify an erc7710
+ * child against `expectation` (from somewhere Haven did not write — the
+ * merchant's 402 in the SDK, the Haven-signed expected context in the
+ * signer), AND that it is re-delegated from this key's OWN account. Throws
+ * `HavenTypedDataRefusedError` (code `TYPED_DATA_NOT_ALLOWED`) on any
+ * disagreement.
+ */
+declare function assertOwnSettlementChild(typedData: unknown, expectation: SettlementChildExpectation, delegateAddress: string): void;
+/**
+ * #3281 (epic #3284, criterion 5): pin WHERE an x402 EIP-3009 funding leg's
+ * redemption sends the money. The funding leg is always
+ * `transfer(<delegate EOA>, <amount>)` of the quoted token
+ * (`delegation-authorize.ts` → `prepareDelegationPayment(agent, token,
+ * payTo = the delegate EOA, amountRaw)`), so the single execution must be
+ * exactly `encodePacked(asset, 0, transfer(delegateAddress, amount))`.
+ *
+ * `delegateAddress` is the signer's OWN key address — local, not from Haven —
+ * so even a compromised binding key can at most move budget into the agent's
+ * own EOA (the hot-delegate residual the sweep returns), never to an attacker.
+ * `asset` and `amount` come from the Haven-signed expected context and keep
+ * the leg consistent with what Haven declared.
+ *
+ * Call ONLY after `assertBoundDirectPaymentUserOp` has passed on the same
+ * typed data (it proves the `execute` → `redeemDelegations` shape this reads).
+ * Throws `HavenTypedDataRefusedError` on any disagreement.
+ */
+declare function assertFundingLegPaysDelegate(typedData: Record<string, unknown>, expected: {
+    delegateAddress: string;
+    asset: string;
+    amount: string;
+}): void;
+
+/**
+ * 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;
+
+export { AgentPaymentRailSchema as $, type AgentPaymentWarning as A, type X402ResumeState as B, type X402McpTransport as C, type X402MerchantCallContext as D, HavenError as E, AGENT_PAYMENT_FAILURE_CODE_VALUES as F, AGENT_PAYMENT_NEXT_ACTION_VALUES as G, type HavenClientConfig as H, AGENT_PAYMENT_PHASE_VALUES as I, AGENT_PAYMENT_RAIL_VALUES as J, type AgentNextStep as K, type AgentPaymentEnumSchema as L, AgentPaymentFailureCode as M, AgentPaymentFailureCodeDescriptions as N, AgentPaymentFailureCodeSchema as O, type PaymentRequest as P, AgentPaymentNextAction as Q, type RawPaymentParties as R, type SweepResult as S, AgentPaymentNextActionDescriptions as T, AgentPaymentNextActionSchema as U, AgentPaymentPhase as V, AgentPaymentPhaseDescriptions as W, type X402PaymentRequired as X, AgentPaymentPhaseSchema as Y, AgentPaymentRail as Z, AgentPaymentRailDescriptions as _, type HavenClientUpdate as a, type UnsupportedNodeVersionMessageOptions as a$, type AgentPaymentSummary as a0, AgentPaymentWarningCode as a1, type AgentPurchaseSummary as a2, CONNECTOR_PACKAGE_NAME as a3, type CatalogSubmissionAccepted as a4, DEFAULT_CONFIRMATION_TIMEOUT_MS as a5, DEFAULT_NEXT_TOOL_BY_ACTION as a6, DIRECT_SIGN_CONTEXT_VERSION as a7, ENTRY_POINT_V07 as a8, ERC7710_ASSET_TRANSFER_METHOD as a9, type NextStepTarget as aA, type NextStepTargets as aB, type NextToolServerRole as aC, PACKED_USER_OPERATION_FIELDS as aD, type PaymentFee as aE, type PaymentNextAction as aF, type PaymentPhase as aG, type PaymentStatus as aH, ROOT_AUTHORITY as aI, SDK_CLIENT_IDENTITY as aJ, SDK_VERSION as aK, SIGNER_UPDATE_FALLBACK as aL, SWEEP_BASE_CHAIN_ID as aM, SWEEP_BASE_SEPOLIA_CHAIN_ID as aN, SWEEP_BASE_SEPOLIA_USDC_ADDRESS as aO, SWEEP_BASE_USDC_ADDRESS as aP, type SettlementChildExpectation as aQ, SignerRefusalCode as aR, type SweepConfirmation as aS, type SweepEip712Domain as aT, type SweepEntry as aU, type SweepExpectedAuth as aV, type SweepPreparation as aW, type SweepSubmitResult as aX, type SweepTypedData as aY, TRANSFER_WITH_AUTHORIZATION_TYPES as aZ, TYPED_DATA_NOT_ALLOWED as a_, HAVEN_CLIENT_HEADER as aa, HAVEN_CONNECTOR_CHANNEL as ab, HAVEN_MINIMUM_NODE_VERSION as ac, HYBRID_DELEGATOR_DOMAIN_NAME as ad, HYBRID_DELEGATOR_DOMAIN_VERSION as ae, type HavenAgentAllowanceSummary as af, type HavenAgentReadiness as ag, type HavenAllowance as ah, HavenApiError as ai, type HavenCatalogMerchant as aj, type HavenListScope as ak, HavenPaymentStateError as al, HavenSigningError as am, HavenTimeoutError as an, HavenTypedDataRefusedError as ao, HavenUnsupportedSignerVersionError as ap, HavenUserOpBindingError as aq, HavenZeroSettlementHashError as ar, type MachinePaymentRail as as, MerchantTimeoutError as at, NEXT_TOOL_SERVER_NAMES as au, NEXT_TOOL_SERVER_ROLES as av, type NextStep as aw, type NextStepArguments as ax, type NextStepHandoff as ay, type NextStepInput as az, type PaymentResult as b, DELEGATION_MANAGER as b$, X402AlreadySettledError as b0, type X402ExpectedAuth as b1, type X402ExpectedContext as b2, type X402PaymentHeaderContext as b3, X402PaymentHeaderValidationError as b4, type X402PaymentOption as b5, type X402RequestSnapshot as b6, type X402SchemeSelection as b7, X402UnexpectedStatusError as b8, X402_LEGACY_PAYMENT_HEADER_NAME as b9, isSupportedNodeVersion as bA, isSweepableChain as bB, normalizePaymentRequired as bC, packedUserOperationHash as bD, parseNextTool as bE, parsePaymentRequired as bF, parsePaymentRequiredResponse as bG, readClientUpdate as bH, renderNextTool as bI, resolveConnectorChannel as bJ, resolveTokenFromAddress as bK, selectErc7710PaymentOption as bL, selectPaymentOption as bM, selectStandardPaymentOption as bN, selectX402SettlementScheme as bO, signerUpdateFallback as bP, sweepUsdcAddress as bQ, sweepUsdcDomain as bR, toStandardPaymentRequirements as bS, unsupportedNodeVersionMessage as bT, validateStandardX402PaymentHeader as bU, verifySettlementChild as bV, x402AssetTransferMethod as bW, x402AuthorizationAmount as bX, x402FacilitatorAddresses as bY, x402V2PaymentEnvelope as bZ, CAVEAT_ENFORCERS as b_, X402_MAX_AUTHORIZATION_WINDOW_SECONDS as ba, X402_PAYMENT_HEADER_NAME as bb, X402_PAYMENT_HEADER_NAMES_SENT as bc, X402_PAYMENT_REQUIRED_HEADER_NAME as bd, X402_PAYMENT_RESPONSE_HEADER_NAME as be, X402_SETTLEMENT_FORWARD_MARGIN_SECONDS as bf, assertBoundDirectPaymentUserOp as bg, assertUserOpTypedDataBinding as bh, buildSweepAuthorizationMessage as bi, buildSweepTypedData as bj, buildX402ExpectedMessage as bk, compareNodeVersions as bl, connectorRerunCommand as bm, connectorSpec as bn, createNextStepBuilder as bo, decodeBase64Json as bp, decodeBase64Utf8 as bq, defaultNextToolFor as br, deriveDelegateAccountAddress as bs, encodeBase64Json as bt, encodeBase64Utf8 as bu, encodePaymentProof as bv, havenClientIdentity as bw, isConnectorChannel as bx, isErc7710Option as by, isPackedUserOperationTypedData as bz, type PaymentIntent as c, DIRECT_PAYMENT_CHAIN_IDS as c0, EXECUTE_ABI as c1, HYBRID_DELEGATOR_IMPLEMENTATION as c2, MAX_SETTLEMENT_WINDOW_SECONDS as c3, SIMPLE_FACTORY_ADDRESS as c4, type SettlementChildTypedData as c5, assertFundingLegPaysDelegate as c6, assertOwnSettlementChild as c7, chainIdForNetwork as c8, isSettlementChildTypedData as c9, type X402AuthorizationOptions as d, type X402Intent as e, type PaymentStatusResult as f, type HavenAgent as g, type HavenAgentSummary as h, type SweepPrepareResponse as i, type SweepAuthorization as j, type SweepSubmitResponse as k, type HavenAllowanceSummary as l, type HavenBalanceCoverage as m, type PostPurchaseAllowanceSummary as n, type HavenCatalogEntry as o, type HavenCatalogSubmission as p, type HavenPaymentReceipt as q, type HavenPaymentReceiptsPage as r, type PaymentResumeState as s, type X402Receipt as t, type X402Quote as u, type X402Erc7710Settlement as v, type X402McpCallContext as w, type SignData as x, type ResumeAuthorizedX402Input as y, type ResumeX402PaymentInput as z };