@haven_ai/sdk 0.6.0-alpha.0 → 0.8.0-alpha.0

package/dist/index.d.cts

@@ -1,20 +1,41 @@
-import { R as RawPaymentParties, H as HavenClientConfig, a as HavenClientUpdate, P as PaymentRequest, b as PaymentResult, c as PaymentIntent, X as X402PaymentRequired, d as X402AuthorizationOptions, e as X402Intent, f as PaymentStatusResult, g as HavenAgent, h as HavenAgentSummary, S as SweepResult, i as SweepPrepareResponse, j as SweepAuthorization, k as SweepSubmitResponse, l as HavenAllowanceSummary, m as HavenBalanceCoverage, n as PostPurchaseAllowanceSummary, A as AgentPaymentWarning, o as HavenCatalogEntry, p as HavenCatalogSubmission, q as HavenPaymentReceipt, r as HavenPaymentReceiptsPage, O as OpenTaskBudgetResult, s as HavenTaskBudget, T as TaskBudgetSignContext, t as SubmitTaskBudgetResult, C as CloseTaskBudgetResult, u as PaymentResumeState, v as X402Receipt, w as X402Quote, x as X402Erc7710Settlement, y as X402McpCallContext, z as SignData, B as ResumeAuthorizedX402Input, D as ResumeX402PaymentInput, E as X402ResumeState, F as X402McpTransport, G as X402MerchantCallContext, I as HavenError } from './base64-cD9kR4JL.cjs';
-export { J as AGENT_PAYMENT_FAILURE_CODE_VALUES, K as AGENT_PAYMENT_NEXT_ACTION_VALUES, L as AGENT_PAYMENT_PHASE_VALUES, M as AGENT_PAYMENT_RAIL_VALUES, N as AgentNextStep, Q as AgentPaymentEnumSchema, U as AgentPaymentFailureCode, V as AgentPaymentFailureCodeDescriptions, W as AgentPaymentFailureCodeSchema, Y as AgentPaymentNextAction, Z as AgentPaymentNextActionDescriptions, _ as AgentPaymentNextActionSchema, $ as AgentPaymentPhase, a0 as AgentPaymentPhaseDescriptions, a1 as AgentPaymentPhaseSchema, a2 as AgentPaymentRail, a3 as AgentPaymentRailDescriptions, a4 as AgentPaymentRailSchema, a5 as AgentPaymentSummary, a6 as AgentPaymentWarningCode, a7 as AgentPurchaseSummary, a8 as CONNECTOR_PACKAGE_NAME, a9 as CatalogSubmissionAccepted, aa as DEFAULT_CONFIRMATION_TIMEOUT_MS, ab as DEFAULT_NEXT_TOOL_BY_ACTION, ac as DIRECT_SIGN_CONTEXT_VERSION, ad as ENTRY_POINT_V07, ae as ERC7710_ASSET_TRANSFER_METHOD, af as HAVEN_CLIENT_HEADER, ag as HAVEN_CONNECTOR_CHANNEL, ah as HAVEN_MINIMUM_NODE_VERSION, ai as HYBRID_DELEGATOR_DOMAIN_NAME, aj as HYBRID_DELEGATOR_DOMAIN_VERSION, ak as HavenAgentAllowanceSummary, al as HavenAgentReadiness, am as HavenAllowance, an as HavenApiError, ao as HavenCatalogMerchant, ap as HavenListScope, aq as HavenPaymentStateError, ar as HavenSigningError, as as HavenTimeoutError, at as HavenTypedDataRefusedError, au as HavenUnsupportedSignerVersionError, av as HavenUserOpBindingError, aw as HavenZeroSettlementHashError, ax as MAX_TASK_BUDGET_TTL_SECONDS, ay as MachinePaymentRail, az as MerchantTimeoutError, aA as NEXT_TOOL_SERVER_NAMES, aB as NEXT_TOOL_SERVER_ROLES, aC as NextStep, aD as NextStepArguments, aE as NextStepHandoff, aF as NextStepInput, aG as NextStepTarget, aH as NextStepTargets, aI as NextToolServerRole, aJ as PACKED_USER_OPERATION_FIELDS, aK as PaymentFee, aL as PaymentNextAction, aM as PaymentPhase, aN as PaymentStatus, aO as ROOT_AUTHORITY, aP as SDK_CLIENT_IDENTITY, aQ as SDK_VERSION, aR as SIGNER_UPDATE_FALLBACK, aS as SWEEP_BASE_CHAIN_ID, aT as SWEEP_BASE_SEPOLIA_CHAIN_ID, aU as SWEEP_BASE_SEPOLIA_USDC_ADDRESS, aV as SWEEP_BASE_USDC_ADDRESS, aW as SettlementChildExpectation, aX as SignerRefusalCode, aY as SweepConfirmation, aZ as SweepEip712Domain, a_ as SweepEntry, a$ as SweepExpectedAuth, b0 as SweepPreparation, b1 as SweepSubmitResult, b2 as SweepTypedData, b3 as TRANSFER_WITH_AUTHORIZATION_TYPES, b4 as TYPED_DATA_NOT_ALLOWED, b5 as TaskBudgetCloseExpectation, b6 as TaskChildExpectation, b7 as TaskChildTypedData, b8 as UnsupportedNodeVersionMessageOptions, b9 as X402AlreadySettledError, ba as X402ExpectedAuth, bb as X402ExpectedContext, bc as X402PaymentHeaderContext, bd as X402PaymentHeaderValidationError, be as X402PaymentOption, bf as X402RequestSnapshot, bg as X402SchemeSelection, bh as X402UnexpectedStatusError, bi as X402_LEGACY_PAYMENT_HEADER_NAME, bj as X402_MAX_AUTHORIZATION_WINDOW_SECONDS, bk as X402_PAYMENT_HEADER_NAME, bl as X402_PAYMENT_HEADER_NAMES_SENT, bm as X402_PAYMENT_REQUIRED_HEADER_NAME, bn as X402_PAYMENT_RESPONSE_HEADER_NAME, bo as X402_SETTLEMENT_FORWARD_MARGIN_SECONDS, bp as assertBoundDirectPaymentUserOp, bq as assertOwnTaskBudgetCloseUserOp, br as assertOwnTaskChild, bs as assertUserOpTypedDataBinding, bt as buildSweepAuthorizationMessage, bu as buildSweepTypedData, bv as buildX402ExpectedMessage, bw as compareNodeVersions, bx as connectorRerunCommand, by as connectorSpec, bz as createNextStepBuilder, bA as decodeBase64Json, bB as decodeBase64Utf8, bC as defaultNextToolFor, bD as deriveDelegateAccountAddress, bE as encodeBase64Json, bF as encodeBase64Utf8, bG as encodePaymentProof, bH as hashDelegation, bI as havenClientIdentity, bJ as isConnectorChannel, bK as isErc7710Option, bL as isPackedUserOperationTypedData, bM as isSupportedNodeVersion, bN as isSweepableChain, bO as isTaskChildTypedData, bP as normalizePaymentRequired, bQ as packedUserOperationHash, bR as parseNextTool, bS as parsePaymentRequired, bT as parsePaymentRequiredResponse, bU as readClientUpdate, bV as renderNextTool, bW as resolveConnectorChannel, bX as resolveTokenFromAddress, bY as selectErc7710PaymentOption, bZ as selectPaymentOption, b_ as selectStandardPaymentOption, b$ as selectX402SettlementScheme, c0 as signerUpdateFallback, c1 as sweepUsdcAddress, c2 as sweepUsdcDomain, c3 as toStandardPaymentRequirements, c4 as unsupportedNodeVersionMessage, c5 as validateStandardX402PaymentHeader, c6 as verifySettlementChild, c7 as x402AssetTransferMethod, c8 as x402AuthorizationAmount, c9 as x402FacilitatorAddresses, ca as x402V2PaymentEnvelope } from './base64-cD9kR4JL.cjs';
+import { R as RawPaymentParties, H as HavenClientConfig, a as HavenClientUpdate, P as PaymentRequest, b as PaymentResult, c as PaymentIntent, X as X402PaymentRequired, d as X402AuthorizationOptions, e as X402Intent, f as PaymentStatusResult, g as HavenAgent, h as HavenAgentSummary, S as SweepResult, i as SweepPrepareResponse, j as SweepAuthorization, k as SweepSubmitResponse, l as HavenAllowanceSummary, m as HavenBalanceCoverage, B as BudgetPrecheckResult, n as PostPurchaseAllowanceSummary, A as AgentPaymentWarning, o as HavenCatalogEntry, p as HavenCatalogSubmission, q as HavenPaymentReceipt, r as HavenPaymentReceiptsPage, O as OpenTaskBudgetResult, s as HavenTaskBudget, T as TaskBudgetSignContext, t as SubmitTaskBudgetResult, C as CloseTaskBudgetResult, u as SubmitSubBudgetResult, v as HavenPendingSubBudgetSignature, w as CloseSubBudgetResult, x as PaymentResumeState, y as X402Receipt, z as X402Quote, D as X402Erc7710Settlement, E as X402McpCallContext, F as SignData, G as ResumeAuthorizedX402Input, I as ResumeX402PaymentInput, J as X402ResumeState, K as X402McpTransport, L as X402MerchantCallContext, M as HavenError } from './base64-znjJJQqu.cjs';
+export { N as AGENT_PAYMENT_FAILURE_CODE_VALUES, Q as AGENT_PAYMENT_NEXT_ACTION_VALUES, U as AGENT_PAYMENT_PHASE_VALUES, V as AGENT_PAYMENT_RAIL_VALUES, W as AgentNextStep, Y as AgentPaymentEnumSchema, Z as AgentPaymentFailureCode, _ as AgentPaymentFailureCodeDescriptions, $ as AgentPaymentFailureCodeSchema, a0 as AgentPaymentNextAction, a1 as AgentPaymentNextActionDescriptions, a2 as AgentPaymentNextActionSchema, a3 as AgentPaymentPhase, a4 as AgentPaymentPhaseDescriptions, a5 as AgentPaymentPhaseSchema, a6 as AgentPaymentRail, a7 as AgentPaymentRailDescriptions, a8 as AgentPaymentRailSchema, a9 as AgentPaymentSummary, aa as AgentPaymentWarningCode, ab as AgentPurchaseSummary, ac as CONNECTOR_PACKAGE_NAME, ad as CatalogSubmissionAccepted, ae as DEFAULT_CONFIRMATION_TIMEOUT_MS, af as DEFAULT_NEXT_TOOL_BY_ACTION, ag as DIRECT_SIGN_CONTEXT_VERSION, ah as ENTRY_POINT_V07, ai as ERC7710_ASSET_TRANSFER_METHOD, aj as HAVEN_CLIENT_HEADER, ak as HAVEN_CONNECTOR_CHANNEL, al as HAVEN_MINIMUM_NODE_VERSION, am as HYBRID_DELEGATOR_DOMAIN_NAME, an as HYBRID_DELEGATOR_DOMAIN_VERSION, ao as HavenAgentAllowanceSummary, ap as HavenAgentReadiness, aq as HavenAllowance, ar as HavenApiError, as as HavenCatalogMerchant, at as HavenListScope, au as HavenPaymentStateError, av as HavenSigningError, aw as HavenTimeoutError, ax as HavenTypedDataRefusedError, ay as HavenUnsupportedSignerVersionError, az as HavenUserOpBindingError, aA as HavenZeroSettlementHashError, aB as MAX_TASK_BUDGET_TTL_SECONDS, aC as MachinePaymentRail, aD as MerchantTimeoutError, aE as NEXT_TOOL_SERVER_NAMES, aF as NEXT_TOOL_SERVER_ROLES, aG as NextStep, aH as NextStepArguments, aI as NextStepHandoff, aJ as NextStepInput, aK as NextStepTarget, aL as NextStepTargets, aM as NextToolServerRole, aN as PACKED_USER_OPERATION_FIELDS, aO as PaymentFee, aP as PaymentNextAction, aQ as PaymentPhase, aR as PaymentStatus, aS as ROOT_AUTHORITY, aT as SDK_CLIENT_IDENTITY, aU as SDK_VERSION, aV as SIGNER_UPDATE_FALLBACK, aW as SWEEP_BASE_CHAIN_ID, aX as SWEEP_BASE_SEPOLIA_CHAIN_ID, aY as SWEEP_BASE_SEPOLIA_USDC_ADDRESS, aZ as SWEEP_BASE_USDC_ADDRESS, a_ as SettlementChildExpectation, a$ as SignerRefusalCode, b0 as SweepConfirmation, b1 as SweepEip712Domain, b2 as SweepEntry, b3 as SweepExpectedAuth, b4 as SweepPreparation, b5 as SweepSubmitResult, b6 as SweepTypedData, b7 as TASK_SIGN_CONTEXT_VERSION, b8 as TRANSFER_WITH_AUTHORIZATION_TYPES, b9 as TYPED_DATA_NOT_ALLOWED, ba as TaskBudgetCloseExpectation, bb as TaskChildExpectation, bc as TaskChildTypedData, bd as UnsupportedNodeVersionMessageOptions, be as X402AlreadySettledError, bf as X402Erc7710AlreadySettledError, bg as X402ExpectedAuth, bh as X402ExpectedContext, bi as X402PaymentHeaderContext, bj as X402PaymentHeaderValidationError, bk as X402PaymentOption, bl as X402RequestSnapshot, bm as X402SchemeSelection, bn as X402TaskBudgetMismatchError, bo as X402UnexpectedStatusError, bp as X402_LEGACY_PAYMENT_HEADER_NAME, bq as X402_MAX_AUTHORIZATION_WINDOW_SECONDS, br as X402_PAYMENT_HEADER_NAME, bs as X402_PAYMENT_HEADER_NAMES_SENT, bt as X402_PAYMENT_REQUIRED_HEADER_NAME, bu as X402_PAYMENT_RESPONSE_HEADER_NAME, bv as X402_SETTLEMENT_FORWARD_MARGIN_SECONDS, bw as assertBoundDirectPaymentUserOp, bx as assertOwnTaskBudgetCloseUserOp, by as assertOwnTaskChild, bz as assertUserOpTypedDataBinding, bA as buildSweepAuthorizationMessage, bB as buildSweepTypedData, bC as buildX402ExpectedMessage, bD as compareNodeVersions, bE as connectorRerunCommand, bF as connectorSpec, bG as connectorUpgradeCommand, bH as createNextStepBuilder, bI as decodeBase64Json, bJ as decodeBase64Utf8, bK as defaultNextToolFor, bL as deriveDelegateAccountAddress, bM as encodeBase64Json, bN as encodeBase64Utf8, bO as encodePaymentProof, bP as hashDelegation, bQ as havenClientIdentity, bR as isConnectorChannel, bS as isErc7710Option, bT as isPackedUserOperationTypedData, bU as isSupportedNodeVersion, bV as isSweepableChain, bW as isTaskChildTypedData, bX as normalizePaymentRequired, bY as packedUserOperationHash, bZ as parseNextTool, b_ as parsePaymentRequired, b$ as parsePaymentRequiredResponse, c0 as readClientUpdate, c1 as renderNextTool, c2 as resolveConnectorChannel, c3 as resolveTokenBySymbol, c4 as resolveTokenFromAddress, c5 as selectErc7710PaymentOption, c6 as selectPaymentOption, c7 as selectStandardPaymentOption, c8 as selectX402SettlementScheme, c9 as signerUpdateFallback, ca as sweepUsdcAddress, cb as sweepUsdcDomain, cc as toStandardPaymentRequirements, cd as unsupportedNodeVersionMessage, ce as validateStandardX402PaymentHeader, cf as verifySettlementChild, cg as x402AssetTransferMethod, ch as x402AuthorizationAmount, ci as x402FacilitatorAddresses, cj as x402V2PaymentEnvelope } from './base64-znjJJQqu.cjs';
 import 'x402/types';
 import 'viem';
 
 /**
  * Verifiable payment receipts.
  *
- * A self-contained proof bundle for a settled Haven payment that anyone can
- * verify **independently of Haven**. The anchor is the agent delegate's
- * signature over the on-chain transfer hash: recover the signer and confirm it
- * is the agent's delegate, and you have cryptographic proof the agent authorised
- * exactly this transfer — no need to trust Haven's backend. The on-chain
- * `txHash` is the settlement source of truth (verify on any explorer).
+ * A self-contained bundle for a settled Haven payment whose agent
+ * authorisation can be checked offline. What `verifyPaymentReceipt` proves is
+ * deliberately narrow: the `payment` block (amount, recipient) is
+ * Haven-asserted and is NOT bound by the signature, and `verified: true` never
+ * proves the payment settled on-chain — settlement stays an explorer check on
+ * `onChain.txHash` / `settlementTxHash`.
  *
- * This lives in the SDK so agents and users can verify receipts client-side
- * with zero Haven trust.
+ * What `verified: true` means, per scheme:
+ *
+ * - erc7710 (`authorization.signatureScheme: 'eip712_delegation'`): the bundle
+ *   carries the settlement child's EIP-712 struct hash as `signHash`. The
+ *   verifier rebuilds the digest the delegate actually signed —
+ *   `keccak256(0x1901 ‖ domainSeparator(DelegationManager, chainId) ‖ signHash)`
+ *   — from the DelegationManager address the SDK pins and the bundle's
+ *   `onChain.chainId`, never from a value the receipt itself vouches for.
+ *   `verified: true` means the delegate key signed that settlement delegation
+ *   (`verifiedOver: 'delegation_digest'`).
+ * - direct payments and the eip3009 funding leg
+ *   (`signatureScheme: 'eip712_userop'`) sign an ERC-4337 user operation the
+ *   bundle does not carry: they return `not_verifiable_offline` rather than a
+ *   false accusation.
+ * - retired-rail bundles (no scheme) carry a raw-signed `signHash`; the
+ *   verifier recovers over it directly, then over the delegation digest when
+ *   the chain allows rebuilding it.
+ *
+ * Anything that is not a signed bundle — including a `haven_list_receipts`
+ * history row, which carries no signature at all — returns
+ * `not_a_signed_receipt`. Verification never throws.
+ *
+ * This lives in the SDK so agents and users can verify receipts client-side.
  */
 declare const RECEIPT_VERSION = "haven-receipt-1";
 interface PaymentReceipt {
@@ -44,6 +65,17 @@ interface PaymentReceipt {
         delegate: string;
         signHash: string;
         signature: string | null;
+        /**
+         * #3418: which digest the delegate signed — selects what offline
+         * verification rebuilds. `'eip712_delegation'`: the settlement
+         * delegation's EIP-712 digest (erc7710). `'eip712_userop'`: an ERC-4337
+         * user-operation digest the bundle does not carry (direct payments, the
+         * eip3009 funding leg) — not verifiable offline. Absent on retired-rail
+         * bundles and on backends older than #3418, whose `signHash` was signed
+         * raw. The value is only a selector: a lying one cannot make a forged
+         * signature verify, because recovery must still return `delegate`.
+         */
+        signatureScheme?: 'eip712_delegation' | 'eip712_userop';
     };
     onChain: {
         txHash: string | null;
@@ -53,17 +85,27 @@ interface PaymentReceipt {
 type ReceiptVerification = {
     verified: true;
     recoveredSigner: string;
+    verifiedOver: 'sign_hash' | 'delegation_digest';
 } | {
     verified: false;
-    reason: 'missing_signature' | 'bad_signature' | 'signer_mismatch';
+    reason: 
+    /** #3418: the input is not a haven-receipt-1 bundle (a haven_list_receipts row, null, undefined, a non-object). */
+    'not_a_signed_receipt'
+    /** #3418: eip712_userop bundle; or a delegation bundle on a chain the SDK pins no DelegationManager for. */
+     | 'not_verifiable_offline' | 'missing_signature' | 'bad_signature' | 'signer_mismatch';
     recoveredSigner?: string;
 };
+type RecoverFn = (hash: string, signature: string) => string;
 /**
- * Verify a receipt independently: recover the signer from the authorisation and
- * confirm it is the agent's delegate. Pure — `recover` is injectable but
- * defaults to standard ECDSA recovery, so this runs anywhere (no Haven backend).
+ * Verify a receipt's agent authorisation offline: recover the signer and
+ * confirm it is the agent delegate, over whichever digest the bundle's scheme
+ * names (see the module doc for what that proves — and what it does not).
+ * Never throws: anything that is not a signed receipt — a
+ * `haven_list_receipts` history row, null, undefined, a non-object — returns
+ * `not_a_signed_receipt`. Pure — `recover` is injectable but defaults to
+ * standard ECDSA recovery, so this runs anywhere (no Haven backend).
  */
-declare function verifyPaymentReceipt(receipt: PaymentReceipt, recover?: (hash: string, signature: string) => string): ReceiptVerification;
+declare function verifyPaymentReceipt(receipt: unknown, recover?: RecoverFn): ReceiptVerification;
 
 /**
  * Merchant delivery and the evidence trail behind it (#1620, epic #1613).
@@ -112,6 +154,16 @@ interface X402MerchantOutcomeReport {
  * unknown payment id, or a transport failure with no HTTP status at all,
  * reported as `statusCode: 0`) — reporting the same hash again will not
  * change the answer.
+ *
+ * #3529: a `refused` outcome whose backend answered the #3475 evidence
+ * contract ALSO carries the backend's own `reason` — the verbatim sentence
+ * `attachEvidenceHandler` put in the 409/503 body. Present only on the
+ * eip3009 settlement-report refusal (`SettlementReportRefusal`); every other
+ * refusal and every pre-#3475 backend leave it absent, which is exactly the
+ * distinction the hosted tool needs: the reason-bearing refusal fires on a
+ * payment whose FUNDING is confirmed, never on one Haven could not confirm.
+ * Consumers must treat presence as the signal and absence as "unknown", not
+ * infer anything from `statusCode` or payment status.
  */
 type EvidenceReportOutcome = {
     outcome: 'confirmed';
@@ -121,6 +173,7 @@ type EvidenceReportOutcome = {
 } | {
     outcome: 'refused';
     statusCode: number;
+    reason?: string;
 };
 /**
  * #2970: a hash of the form `0x00…00` is never a real transaction — it is the
@@ -144,6 +197,15 @@ declare class HavenClient {
     private readonly pollingInterval;
     private readonly chainRpcs;
     private readonly inFlightX402;
+    /**
+     * #3392: the task budget each in-flight x402 entry was created under
+     * (`undefined` = none). A call joining an in-flight entry under a
+     * different budget is refused before any network call — never silently
+     * charged to another budget's payment.
+     */
+    private readonly inFlightX402TaskBudget;
+    /** #3330: the sub-budget each in-flight entry was created under, same pin as `inFlightX402TaskBudget`. */
+    private readonly inFlightX402SubBudget;
     /**
      * The EIP-3009 funding-leg lifecycle (#1618). The facade holds a reference
      * and delegates; it does not reimplement any of it.
@@ -330,6 +392,11 @@ declare class HavenClient {
      * degrade-to-warning path and the ledger row would still land while the
      * purchase proceeded.
      *
+     * #3518: without `merchantTo`, an agent whose budgets for the token are all
+     * merchant-locked gets 409 `budget_requires_recipient` (thrown, nothing
+     * recorded) naming the pins in `budget_recipient_addresses` — repeat the
+     * check with `merchantTo`.
+     *
      * camelCase body like the route family; the response mirrors the wire
      * (`sufficient`, `remaining_atomic`). `resourceUrl` is the merchant
      * resource being bought — the ledger dedupe window's discriminating
@@ -341,11 +408,16 @@ declare class HavenClient {
         amountAtomic: string;
         merchantTo?: string;
         resourceUrl?: string;
-    }): Promise<{
-        sufficient: boolean;
-        remaining_atomic: string;
-        remaining_is_from_chain?: boolean;
-    }>;
+        /**
+         * #3492/#3527: the x402 idempotency key of the quote this pre-check
+         * describes. When it resolves to an already-settled erc7710 OR eip3009
+         * replay of the SAME quote, the response answers sufficient (with
+         * `replay: true`) instead of comparing against the now-lower remaining
+         * budget — see `BudgetPrecheckRequest.idempotencyKey` in the OpenAPI
+         * spec. Omitted: unchanged behavior.
+         */
+        idempotencyKey?: string;
+    }): Promise<BudgetPrecheckResult>;
     /**
      * Post-purchase allowance/budget summary for a settled payment (#1310).
      *
@@ -472,10 +544,16 @@ declare class HavenClient {
     listReceipts(options?: {
         limit?: number;
     }): Promise<HavenPaymentReceipt[]>;
-    /** #3128: one page of receipts with `total`, `hasMore` and `nextCursor`. */
+    /**
+     * One page of receipts with `total`, `hasMore` and `nextCursor` (#3128).
+     * `compact: true` (#3423) drops each row's
+     * `challengePayload`, `selectedPayment` and `protocolReceiptPayload`; the
+     * default shape is unchanged.
+     */
     listReceiptsPage(options?: {
         limit?: number;
         cursor?: string;
+        compact?: boolean;
     }): Promise<HavenPaymentReceiptsPage>;
     /**
      * Fetch the verifiable receipt bundle for a settled payment and verify it
@@ -525,6 +603,29 @@ declare class HavenClient {
      * `submitTaskBudget`.
      */
     closeTaskBudget(id: string): Promise<CloseTaskBudgetResult>;
+    /**
+     * Submit the DELEGATING agent's signature for a sub-budget row: opens a
+     * `pending` row (the signature is over the child delegation the backend
+     * built — sign it with `haven_sign` and `sub_budget_id`) or relays the
+     * signed close of a `closing` row. The owner issues a sub-budget; this is
+     * how the agent completes it — no owner relay is needed. Returns
+     * `status: 'open'` or `'closed'`.
+     */
+    submitSubBudget(id: string, signature: string): Promise<SubmitSubBudgetResult>;
+    /**
+     * The sub-budget rows THIS agent must still sign as the delegating agent
+     * (pending an open signature, or closing a close signature) — the same
+     * list `getAgentSummary().pendingSubBudgetSignatures` carries, but a
+     * transport failure throws instead of reading as an empty list.
+     */
+    listPendingSubBudgetSignatures(): Promise<HavenPendingSubBudgetSignature[]>;
+    /**
+     * Close a sub-budget row (delegating agent only). A `pending` or expired row
+     * closes immediately; a live child returns `signData` for the on-chain
+     * revocation — sign it (`haven_sign` with `sub_budget_id`) and call
+     * `submitSubBudget`.
+     */
+    closeSubBudget(id: string): Promise<CloseSubBudgetResult>;
     /**
      * Rehydrate the x402 resume-state bundle for a payment id (#1328: the MPP
      * resume-state variant retired along with the rest of the mpp_demo surface).
@@ -616,6 +717,14 @@ declare class HavenClient {
          * `[settlement, task, budget]`.
          */
         taskBudgetId?: string;
+        /**
+         * #3330: build the settlement chain under this open sub-budget's grant
+         * instead of the agent's budget delegation directly —
+         * `[settlement, grant, parent-child, budget]`. Agent B pays through the
+         * sub-budget agent A granted it. Mutually exclusive with `taskBudgetId`
+         * (the backend refuses a body naming both).
+         */
+        subBudgetId?: string;
     }): Promise<{
         paymentId: string;
         signData: SignData;
@@ -752,6 +861,13 @@ declare class HavenClient {
      * `MerchantCompletion.reportSettlementEvidence` for the fail-closed
      * verification this posts into (`observeErc7710Settlement`) and the
      * client-side zero-hash refusal.
+     *
+     * #3475: also takes an eip3009 payment's merchant settlement (the
+     * `PAYMENT-RESPONSE.transaction` of a plain-HTTP merchant the agent retried
+     * itself). The payment is already confirmed by its funding transaction;
+     * Haven verifies the delegate → merchant transfer on-chain
+     * (`observeEip3009MerchantSettlement`) and records it beside the funding
+     * hash, so receipts name the merchant's settlement.
      */
     reportSettlementEvidence(paymentId: string, settlementTxHash: string): Promise<EvidenceReportOutcome>;
     /**
@@ -932,17 +1048,17 @@ declare const toolDescriptions: {
     readonly payX402OneShot: {
         readonly summary: "Fetch an x402 paid HTTP resource in a single call. Handles the full probe -> pay -> retry round trip and returns the merchant response.";
         readonly selectionGuidance: "Prefer this over the quote+pay split when the agent just wants the paid resource and does not need to inspect the price first. If you already have a quote from haven_quote_x402, use haven_pay_x402_quote instead. Do not use for read-only allowance, budget, spend-limit, remaining-amount, reset-period, or what-can-I-spend questions; use the allowance lookup tool instead.";
-        readonly behavior: "Calls the URL, parses any HTTP 402 x402 challenge (or, since #3118, a native-MCP payment-required tool result under HTTP 200), signs the payment locally, then retries the original request with the signed payment header (sent under PAYMENT-SIGNATURE, plus the legacy X-PAYMENT on the EIP-3009 path only) and returns the merchant response. Settlement is either direct account-to-merchant with no funding leg, or a bridge that first redeems the agent's budget delegation to fund the delegate wallet for an EIP-3009 authorization. A payment outside the on-chain budget is declined before any money moves; nothing is queued for a human to approve later. If the resource returns a non-402 status with no payment-required tool result, returns it unchanged without contacting Haven.";
+        readonly behavior: "Calls the URL, parses any HTTP 402 x402 challenge (or, since #3118, a native-MCP payment-required tool result under HTTP 200), signs the payment locally, then retries the original request with the signed payment header (sent under PAYMENT-SIGNATURE, plus the legacy X-PAYMENT on the EIP-3009 path only) and returns the merchant response. On the EIP-3009 path, when the owner opted this agent in, the same retry also carries the agent-signed buyer tax declaration in X-Tax-Declaration — signed by the same local delegate key, sent to the seller only, and omitted when the declaration is not available or on the direct-settlement (erc7710) scheme. Settlement is either direct account-to-merchant with no funding leg, or a bridge that first redeems the agent's budget delegation to fund the delegate wallet for an EIP-3009 authorization. A payment outside the on-chain budget is declined before any money moves; nothing is queued for a human to approve later. If the resource returns a non-402 status with no payment-required tool result, returns it unchanged without contacting Haven.";
         readonly nextActionGuidance: string;
     };
     readonly resumeX402: {
         readonly summary: "Resume an x402 payment whose Haven-side authorization already succeeded but whose merchant retry did not complete.";
-        readonly behavior: "Accepts either resume_state or payment_id, validates the x402 details against the authorized funding, and retries the merchant request with the signed payment header (PAYMENT-SIGNATURE, plus legacy X-PAYMENT on EIP-3009 only; also params._meta on an MCP tools/call body). No new Haven payment is created.";
+        readonly behavior: "Accepts either resume_state or payment_id, validates the x402 details against the authorized funding, and retries the merchant request with the signed payment header (PAYMENT-SIGNATURE, plus legacy X-PAYMENT on EIP-3009 only; also params._meta on an MCP tools/call body). On the EIP-3009 scheme the retry also carries the agent-signed buyer tax declaration in X-Tax-Declaration when the owner opted this agent in and the declaration is available — signed locally by the same delegate key, sent to the seller only. No new Haven payment is created.";
         readonly nextActionGuidance: string;
     };
     readonly getPaymentStatus: {
         readonly summary: "Fetch structured Haven payment status for agent recovery.";
-        readonly behavior: "State: phase, nextAction, rail, amount, merchant, resource, idempotency, message; parties: treasury/delegate/delegateAccount/merchant. awaiting_settlement_evidence: poll once, else unverified.";
+        readonly behavior: "State: phase, nextAction, rail, amount, merchant, resource, idempotency, message; delivered when the merchant answered; parties: treasury/delegate/delegateAccount/merchant. awaiting_settlement_evidence: poll once, else unverified. delivered_unverified: terminal, stop. For a settled x402 payment the allowance block reports remainingAtomic / remainingDisplay / resetPeriodMin / tokenSymbol / tokenAddress (the SAME names and values haven_get_agent reports) beside the deprecated snake_case spellings (remaining_atomic, remaining_display, token_symbol, token_address, reset_period), kept for a deprecation window.";
         readonly nextActionGuidance: "";
     };
     readonly getResumeState: {
@@ -953,13 +1069,13 @@ declare const toolDescriptions: {
     readonly getAgent: {
         readonly summary: "Return the authenticated agent identity AND its live spend authority in one call: Haven wallet, delegate, chain, raw status, spend_authority_readiness, per-token remaining allowance (atomic + human-readable). The recommended first call in a new session.";
         readonly selectionGuidance: "Use this as the session bootstrap, or to confirm identity together with whether the agent can spend right now. For per-token detail (configured vs spent vs reset window) use haven_get_allowances.";
-        readonly behavior: "Reads identity plus the live spend-authority snapshot — the active on-chain budget delegation. spend_authority_readiness (readiness is a deprecated alias, same value) is \"ready\" when at least one token has remaining spend authority, \"needs_approval\" when the agent is active but has none, and \"revoked\" when the credential is not active. It covers hosted identity + on-chain spend authority ONLY — the hosted server cannot see the LOCAL signer, so \"ready\" does not mean the signer can start; verify the signer with a signer tool call or connect --doctor. An over-budget payment is declined before any money moves; there is no approval queue — ask the owner to grant or raise the budget in Haven. allowances[] carries id, tokenAddress, remainingAtomic, remainingDisplay per token. Identity fields: id, name, status, accountAddress, delegateAddress, chainId.";
+        readonly behavior: "Reads identity plus the live spend-authority snapshot — the active on-chain budget delegation. spend_authority_readiness (readiness is a deprecated alias, same value) is \"ready\" when at least one token has remaining spend authority, \"needs_approval\" when the agent is active but has none, and \"revoked\" when the credential is not active. It covers hosted identity + on-chain spend authority ONLY — the hosted server cannot see the LOCAL signer, so \"ready\" does not mean the signer can start; verify the signer with a signer tool call or connect --doctor. An over-budget payment is declined before any money moves; there is no approval queue — ask the owner to grant or raise the budget in Haven. allowances[] carries id, tokenAddress, remainingAtomic, remainingDisplay per token. taskBudgets[] rows carry maxAtomic/maxDisplay plus spentAtomic/remainingAtomic/remainingDisplay — what the chain still allows that budget — and remainingIsFromChain: false marks a failed read (figures null, never the full cap); only live rows are listed (closed and expired omitted), each with its status (pending | open | closing) and isExpired, so a closing budget stays visible. pendingSubBudgetSignatures[] lists sub-budget rows awaiting YOUR signature, each with its haven_sign next step. Identity fields: id, name, status, accountAddress, delegateAddress, chainId.";
         readonly nextActionGuidance: "";
     };
     readonly getAllowances: {
         readonly summary: "Return configured and on-chain allowance state for the authenticated agent. On-chain allowance is the real spend gate.";
         readonly selectionGuidance: "Use this when the user asks about allowance, budget, spend limit, remaining amount, remaining allowance, remaining budget, daily limit, reset period, what can I spend, or what the agent can still spend. For whether the account actually HOLDS funds behind the budget use haven_check_funds.";
-        readonly behavior: "Returns the per-token spend authority for the account: the active budget delegation (remaining = the period budget, which re-arms natively at the period boundary), each with id, onchain.remaining, remainingDisplay. An over-budget payment is declined before any money moves; nothing queues. Configured amounts from Haven are returned alongside.";
+        readonly behavior: "Returns the per-token spend authority for the account: the active budget delegation (remaining = the period budget, which re-arms natively at the period boundary), each with id, onchain.remaining, remainingDisplay, delegationHash, recipientAddress (null = open; a pinned budget pays only that recipient), merchantId (set only on a merchant-locked budget), and reservedHavenAtomic — Haven-side task- and sub-budget reservations summed beside, never folded into, the on-chain figure. An over-budget payment is declined before any money moves; nothing queues. Configured amounts from Haven are returned alongside. Open task budgets are not listed here: haven_get_agent's taskBudgets[] carries each one's spentAtomic/remainingAtomic and lifecycle status.";
         readonly nextActionGuidance: "";
     };
     readonly checkFunds: {
@@ -975,9 +1091,9 @@ declare const toolDescriptions: {
         readonly nextActionGuidance: "";
     };
     readonly verifyReceipt: {
-        readonly summary: "Verify a payment receipt offline — confirm the agent authorised the transfer.";
-        readonly selectionGuidance: "Use this to check a receipt you already hold; it needs no network and does not trust Haven. Use the history tool to fetch receipts in the first place.";
-        readonly behavior: "Recovers the signer from the receipt authorisation and confirms it matches the agent delegate. Returns verified true/false with the recovered signer or a reason. Pure and local — no backend call.";
+        readonly summary: "Verify a signed payment receipt offline — confirm the agent delegate signed its authorisation.";
+        readonly selectionGuidance: "Takes the signed bundle from GET /payments/{id}/receipt, not a haven_list_receipts row — a row carries no signature and returns not_a_signed_receipt. No network.";
+        readonly behavior: "Never throws. An erc7710 bundle verifies over the delegation digest the delegate signed; a direct or eip3009 bundle returns not_verifiable_offline. verified true means only that the delegate signed the hash named by verifiedOver — payment facts are Haven-asserted and settlement is not proven; check settlementTxHash on an explorer.";
         readonly nextActionGuidance: "";
     };
     readonly payMcpTool: {
@@ -1011,9 +1127,9 @@ declare const toolDescriptions: {
         readonly nextActionGuidance: string;
     };
     readonly reportSettlementEvidence: {
-        readonly summary: "Report an erc7710 payment's real settlement transaction hash so Haven can verify it on-chain and confirm the payment.";
-        readonly behavior: "Pass payment_id and settlement_tx_hash (0x + 64 hex chars) — from PAYMENT-RESPONSE or a prior settlement_tx_hash. Haven verifies on-chain before confirming; a zero, mismatched, or reverted hash is refused. Your own payments only.";
-        readonly nextActionGuidance: "code DELIVERED_UNSETTLED: did not verify, do not retry — poll haven_get_payment_status. code SETTLEMENT_PENDING (retryable:true): not mined or RPC unreachable — report the same hash again shortly.";
+        readonly summary: "Report a payment's real merchant settlement transaction hash so Haven can verify it on-chain and record it.";
+        readonly behavior: "Pass payment_id and, when you hold one, settlement_tx_hash (0x + 64 hex chars) — from PAYMENT-RESPONSE or a prior settlement_tx_hash. Omitting settlement_tx_hash succeeds as a no-op — nothing is checked or recorded, and no network call is made. Haven verifies on-chain before recording a hash; a zero, mismatched, or reverted hash is refused. Your own payments only.";
+        readonly nextActionGuidance: string;
     };
 };
 type SharedToolKey = keyof typeof toolDescriptions;
@@ -1060,7 +1176,7 @@ type SharedToolKey = keyof typeof toolDescriptions;
  * live sibling constant not pulled in here; if it ever is, this applies to it
  * too (design review, #2537).
  */
-declare const HAVEN_SKILL_MD = "---\nname: haven-pay\ndescription: Pay for things from the user's Haven wallet within their agent rules, and set Haven up when it is not yet connected. Use when the user asks to send, pay, tip, or transfer crypto; when a request hits an HTTP 402 (x402) paywall; or when they ask to create a Haven account, create an agent, or connect one.\n---\n\n# Haven: pay from a Haven wallet\n\nThis skill lets the agent make payments from the user's Haven wallet through\nthe Haven MCP tools. Every payment is checked against the agent's on-chain\nbudget before money moves; a payment above the remaining budget is declined \u2014\nnothing is paid past the rules the user set.\n\nHosted tools run in the `mcp__haven__` namespace. Local signing tools run in\nthe `mcp__haven-signer__` namespace and keep the delegate key on this machine.\nThat namespacing is Claude-family; other runtimes name the servers by their\nown config keys (Codex: `haven`, `haven_signer`). Tool results carry the\nexact next step (`next_action`, `next_tool`, `next_arguments`, plus the\nruntime-neutral `next_tool_server` + `next_tool_name` + `next_tool_server_role`\n\u2014 the bare tool name on that logical server, whatever your runtime calls it).\nWhen no tool follows, `next_tool` is absent and `next_tool_omitted_reason`\nsays why; that is a complete answer.\nFollow those fields first; the prose below is fallback and orientation, not\nthe source of truth.\n\n## When to use this skill\n\n- The user asks to send money, pay someone, tip, donate, or transfer tokens.\n- A request returns HTTP 402 (x402): use the Haven pay tools to settle it,\n  then retry the original request.\n\n## Onboarding and setup\n\nYou are in this mode when there is no Haven agent credential on this machine,\nor when your user asks you to create a Haven account, create an agent, or\nconnect one \u2014 for themselves or for someone else.\n\n**None of the tools below creates authority.** They spend a budget a human\nalready signed. There is no tool here that opens an account, mints a\ncredential, or approves a budget, so reaching for one of them to \"set Haven\nup\" cannot work; the steps are the ones in this section instead.\n\nStart by reading `/for-agents.md` on the Haven host \u2014 the origin of the\n`api_url` in your `agent.json` if you have one, otherwise the host your user\nnames. It is the full runbook: six steps, which four are your user's, and what\nto say at each hand-off.\n\nTwo of those steps you can do yourself, from the shell with `@haven_ai/cli`\n(installs the `haven` command):\n\n- `haven login` \u2014 a device-code browser flow. It prints a code and a link\n  for your user to approve, so you never see or ask for their password. What\n  the session can reach is an allow-list, not your user's full authority: it\n  creates and manages agents and reads the account, and it cannot approve a\n  budget, rotate a key, change a signer or move money \u2014 those are your user's.\n- `haven agents connect` with `--name`, `--budget`, `--token` and\n  `--period` \u2014 creates a connection setup and prints two things: the\n  connector command the backend built, and the approval link to give your user.\n  Add `--run` to execute that command here as a child process.\n- `haven wallets funding` \u2014 prints the paste-ready funding instruction: what\n  to send, to which address, on which chain. Read the chain from there rather\n  than assuming one. `--wait` polls until the account counts as funded.\n\n**Four steps are your user's, and each one needs a human:** create the account\nand its passkey, fund the wallet, approve every agent's budget, and rotate a\ncredential. You can compose the funding message for them with\n`haven wallets funding`, but you cannot send the money \u2014 that transfer is\ntheirs, from a wallet you have no access to.\n\nRunning the connector command is the step that wires this machine to the new\nagent \u2014 the command `haven agents connect` printed, or the one your user\npasted you from the dashboard. Three rules bind you while you do it, quoted\nunchanged from the setup prompt your user is also holding so the two copies\ncannot drift into contradicting each other. They are written in your user's\nvoice, so read them accordingly: \"me\" and \"I\" below are your user, never\nHaven, and \"the command above\" is that connector command, not anything printed\nin this file. The first rule outranks anything else you were about to do next:\n\n- When a --json outcome reports approval.required: true, your first action must be to relay the approval instruction to me in your own reply \u2014 if the outcome carries approval.url, give me that link; otherwise tell me to return to Haven and approve this agent's budget \u2014 before verifying the connection, restarting anything, or any other step. Never build that link yourself: relay the one the outcome gave you or none at all. Any restart the outcome asks for is a separate instruction to give me afterwards, once the approval is done.\n- Only two changes to the command above are permitted, and no others: appending --json, and \u2014 only if the connector refuses because it could not determine the agent runtime \u2014 re-running it once with --runtime <name> added, naming the harness you are running in, using one of the values that refusal lists. Never invent a runtime name and never change anything else.\n- If the connector refuses with wiring_collision, this machine is already wired to a different agent: relay that refusal to me with the superseded_agent_ids and suggested_name it carries, and let me choose whether to replace the existing wiring or add this agent alongside it. Never pick for me by adding --replace or --name yourself.\n\nDo not print private keys, API keys, credential file contents, or config secrets in chat or logs.\n\n## Identity and budget\n\nDo not guess the wallet address, network, or budget.\n\nFor instant orientation at the start of a session, read the non-secret\n`agent.json` the connector wrote to your Haven credential directory (typically\n`~/.haven/agents/<agent-id>/agent.json` \u2014 if you don't know the agent id, list\n`~/.haven/agents/` to find the folder). It\nholds your agent id, Haven wallet address, network, and *configured* per-token\nbudget, and contains no keys \u2014 the fastest way to answer \"who am I and what may\nI spend\" with no round trip. If that file is absent (some setups don't write\nit), use the tools below instead.\n\nBefore any payment, confirm the *live remaining* budget with the tools \u2014\n`agent.json` shows the configured budget, not what is left after recent\nspending:\n\n- `mcp__haven__haven_get_agent` \u2014 the recommended first call: identity\n  (wallet, network) plus `spend_authority_readiness` (`ready` / `needs_approval` /\n  `revoked`) and live remaining per-token allowance, in one shot. That signal\n  covers hosted identity and on-chain spend authority only \u2014 it cannot see the\n  local signer; the signer is verified by calling any signer tool.\n- `mcp__haven__haven_get_allowances` \u2014 detailed per-token breakdown\n  (configured, spent, reset window) when you need more than the summary.\n- `mcp__haven__haven_check_funds` \u2014 whether the account actually HOLDS at\n  least a given amount of a token. Allowance answers above say what you are\n  permitted to spend; this one says whether the money is really there,\n  answered as `covered` true/false/null \u2014 never as a balance. On\n  `covered: false`, stop and tell the user the account is short; on\n  `covered: null` (the chain read failed), treat it as unverifiable rather\n  than as absence.\n\nBudgets reset on a period the user chose. If a payment exceeds the remaining\nbudget it is declined before any money moves \u2014 tell the user; they can raise\nthe budget in the Haven dashboard, or wait for the period reset.\n\n## Paying\n\n**Catalog purchases \u2014 the primary path for MCP merchants:**\n\n1. `mcp__haven__haven_discover_tools` to find a payable service and its\n   `catalog_id`.\n2. If the user needs the live price before authorizing a cap, call\n   `mcp__haven__haven_quote_catalog_purchase` with `catalog_id`. It is\n   read-only and informational only: it never reserves a price or creates a\n   payment. Tell the user its `amount` / `amount_atomic`, then choose a cap.\n3. `mcp__haven__haven_prepare_catalog_purchase` with `catalog_id` and a\n   spending cap. A cap is REQUIRED on this tool and is best practice on every\n   paid call below too \u2014 it caps what the LIVE merchant quote may charge,\n   checked before any funding intent is created. Write it the way the user\n   said it: `max_amount_human` is whole tokens, so \"no more than 1 USDC\" is\n   `max_amount_human: \"1\"`. (`max_amount` is the atomic-unit form, where\n   \"1\" means 0.000001 USDC \u2014 do not convert by hand, and never send both.)\n4. Then FOLLOW THE RESPONSE'S GUIDANCE FIELDS: `next_action`, `next_tool`,\n   and `next_arguments` name the exact next call \u2014 act on those first; the\n   prose in this section is fallback and debugging detail. If the catalog\n   entry is missing or degraded, the response instead names\n   `mcp__haven__haven_pay_mcp_tool` (merchant URL, tool name, arguments) as\n   the manual fallback.\n\n**Signing:** `mcp__haven-signer__haven_sign_x402` with `payment_id` ONLY \u2014\nthe local signer fetches the exact signing bytes AND `payment_required`\nitself, so never relay `typed_data` or the 402 blob yourself. If the signer\nreports its fetched context carried no `payment_required` (older backend),\nre-call with `payment_required` added verbatim. Fallback for an older signer\nor backend: re-run the quote/prepare tool with the SAME `idempotency_key`\nplus `include_signing_payload=true`, then pass `payload_hash`,\n`x402_expected` (the nested `x402.expected` object), and\n`typed_data`/`typed_data_b64` through unchanged.\n\n**Settle:** `mcp__haven__haven_settle_mcp_tool` with `payment_id`,\n`signature`, and `payment_header` ONLY \u2014 Haven rehydrates the merchant call\ncontext (`merchant_url`, `tool_name`, `arguments`, `mcp_transport`)\nserver-side from `payment_id`. Pass those four fields explicitly only as a\nversion-skew fallback when Haven has no stored context for the id \u2014 both or\nnone together, never just one. If the settle result carries `settled: false`,\nfunding has not confirmed \u2014 follow the result's guidance fields and check\nstatus later, do not re-pay.\n\nStep-by-step alternative (also key-safe; for an older signer or backend, or\nwhen you already have a merchant URL and tool name instead of a\n`catalog_id`): if the user needs the live price before choosing a cap, first\ncall `mcp__haven__haven_quote_mcp_tool` with that merchant URL, tool name,\nand arguments. It is informational only; then call\n`mcp__haven__haven_pay_mcp_tool` with the same inputs and the explicit cap.\nThe paid call always obtains a fresh quote before it creates any intent. Then\ncontinue `mcp__haven__haven_pay_mcp_tool` \u2192\n`mcp__haven-signer__haven_sign` \u2192 `mcp__haven__haven_submit` \u2192\n`mcp__haven-signer__haven_x402_sign_header` \u2192\n`mcp__haven__haven_complete_mcp_tool`. Call that last step with\n`payment_id` and the signer's `payment_header` ONLY. It does not take\n`payment_required`: Haven rehydrates the merchant call context\n(`merchant_url`, `tool_name`, `arguments`, `mcp_transport`) and the\n402 server-side from `payment_id`, exactly as at settle. Pass that context\nexplicitly only as a version-skew fallback when Haven has no stored context\nfor the id \u2014 `merchant_url` and `tool_name` both or none together, never\njust one.\nThe returned `expires_at` is the signing window; if a tool returns\n`PAYMENT_WINDOW_EXPIRED`, re-run the same quote/prepare tool with the same\n`idempotency_key`. Do not call the merchant yourself \u2014 Haven completes the\nmerchant leg for you.\n\n**Direct transfer / non-MCP paywall:** `mcp__haven__haven_pay` with\n`to`, `amount`, and `token` for a plain transfer. For an arbitrary,\nnon-MCP x402 paywall: `mcp__haven__haven_quote_x402` to get a quote, then\n`mcp__haven__haven_pay_x402_quote` \u2014 follow the result's guidance fields\nfirst and sign in the local Haven signer. On THIS path Haven does not talk to\nthe merchant: `mcp__haven-signer__haven_sign_x402` returns both\n`signature` and `payment_header`; relay `signature` with\n`mcp__haven__haven_submit`, then retry the paywalled URL yourself with\n`payment_header`. Do not pass that call's `x402_binding` to\n`mcp__haven-signer__haven_x402_sign_header` \u2014 the one-shot already spent it\nbuilding the header, so the call can only refuse. Then tell Haven what the\nmerchant answered: `mcp__haven__haven_report_x402_outcome` with the\n`payment_id`, `outcome` (`\"accepted\"` for a 2xx, else `\"rejected\"`)\nand the `merchant_status` you got. Because Haven never contacted that\nmerchant, this is the only way it can learn the purchase failed \u2014 without it a\nfailed purchase reads as complete for fifteen minutes. (The SDK's own\n`haven_pay_x402` tool does perform the merchant retry itself; that tool is\nnot part of the hosted MCP surface.) If the process\ncrashes after payment, a later `mcp__haven__haven_get_payment_status` call\nmay report `nextAction: 'retry_original_x402_request'` \u2014 only then call\n`mcp__haven__haven_resume_x402_payment` with the preserved resume state or\npayment id, instead of paying again.\n\n**Catalog tool arguments:** when `haven_discover_tools` returns\n`tool_arguments`, pass that object unchanged as the pay tool's\n`arguments` field (for example\n`tool_arguments: { \"tier\": \"50gb\" }` -> `arguments: { \"tier\": \"50gb\" }`).\n\n**Prices:** show the user the live price from a read-only quote or the pay-tool\nresult, never a catalog price. `haven_discover_tools` prices are indicative\n(`price_is_indicative`) and can be stale. A read-only quote is informational\nonly and does not reserve a price; the later paid call re-quotes and enforces\nthe cap. The pay-tool result's `amount` / `amount_atomic` is the merchant's\nown quoted price for that call \u2014 a ceiling the merchant settles at or below \u2014\nso present it as the most the user will pay. It is a price, not an approval:\nthe payment goes through only if it also fits the cap you set and the on-chain\nbudget the user signed, which is enforced on-chain rather than by Haven.\n\n**Status:** `mcp__haven__haven_get_payment_status` with a `payment_id` to\ncheck on in-flight payments. Do not poll in a tight loop.\n\n## Declines and stop signals\n\n- A payment outside the agent's rules \u2014 above the remaining budget, wrong\n  recipient, or expired budget \u2014 is declined before any money moves. Nothing\n  is queued; tell the user, who can raise the budget in Haven.\n- `safe_to_continue: false` on a guidance block is a stop signal in\n  machine-readable form: stop and involve the user before calling anything\n  else for this payment.\n- Never ask the user for private keys. Signing happens only in the local Haven\n  signer; the hosted Haven tools never receive the signing key. If a tool\n  reports a missing or invalid credential, tell the user to re-run the Haven\n  connector command.\n\n## Failure handling\n\nHaven tool failures are shaped like `{ success: false, code, message, ... }`\nor older `{ error, status, details? }` responses. A failure carries the same\n`next_action` / `next_tool` / `next_arguments` / `next_tool_omitted_reason`\nfields a success does; follow them first, then branch on `code` and surface\n`message` or `error` verbatim. Common cases:\n\n- `insufficient_funds`: the Haven wallet doesn't hold enough of that token.\n  Suggest the user add funds in the Haven dashboard.\n- `PRICE_EXCEEDS_MAX`: the live merchant price exceeded your cap. No funds\n  moved; ask the user before retrying with a higher one.\n- `AMBIGUOUS_MAX_AMOUNT`: you sent both `max_amount` and\n  `max_amount_human`. Nothing was contacted or spent \u2014 re-send with exactly\n  one (`max_amount_human` for a cap the user stated in tokens).\n- `MAX_AMOUNT_UNCONVERTIBLE`: `max_amount_human` does not fit this quote's\n  asset \u2014 unknown decimals, or more decimal places than the asset supports.\n  Round the cap, or send an exact atomic `max_amount`.\n- `PAYMENT_WINDOW_EXPIRED`: re-run the quote/prepare tool with the same\n  `idempotency_key`, then sign the fresh payload.\n- `MERCHANT_NOT_READY`: the merchant refused the quote with its own\n  \"cannot settle right now\" signal (a 503 `merchant_not_ready` with a\n  `reason_code`) instead of a 402. No payment was created. Tell the user;\n  retry later (the message carries `retry_after_s` when the merchant gave\n  one) \u2014 this is not a wrong or broken endpoint.\n- `MERCHANT_REJECTED_AFTER_FUNDING`: the merchant refused the paid retry.\n  On eip3009 (`rail` not `erc7710`): Stop-and-sweep \u2014 stop retrying the\n  merchant and use `mcp__haven__haven_sweep_delegate` to recover stranded\n  delegate funds. On erc7710 there is no funding leg and nothing to sweep:\n  follow the message \u2014 it says whether the merchant declined to settle\n  (re-quote later) or whether to check `haven_get_payment_status` after\n  the payment window first.\n- `MERCHANT_UNRESPONSIVE_AFTER_FUNDING`: the merchant never answered the paid\n  retry. This is NOT proof of rejection \u2014 the merchant may still settle late.\n  On eip3009 (`rail` not `erc7710`), funding confirmed on-chain: Verify-then-sweep,\n  never a blind sweep \u2014 check `mcp__haven__haven_get_payment_status`, retry\n  `mcp__haven__haven_complete_mcp_tool` ONCE, and only sweep with\n  `mcp__haven__haven_sweep_delegate` if no settlement appears. On erc7710\n  there is no funding leg and nothing to sweep, and\n  `mcp__haven__haven_complete_mcp_tool` has no erc7710 branch (it refuses a\n  submitted intent) \u2014 do not retry it: the merchant may still redeem the\n  settlement authorization within the payment window, so check\n  `mcp__haven__haven_get_payment_status` after that window and re-quote only\n  if it shows no settlement.\n- Budget exceeded: tell the user how much remains (from\n  `mcp__haven__haven_get_allowances`) and that they can raise the budget in\n  Haven.\n\n## Reporting after a purchase\n\nA settled `mcp__haven__haven_settle_mcp_tool` response carries\n`agent_summary.purchase_summary` and the remaining post-purchase allowance\nin `allowance` \u2014 report the product, Haven-derived payment/transaction\nfields, and what is left from those fields directly. `result` is optional\nraw merchant evidence; never use it to decide whether the purchase was paid.\nDo not call `haven_get_agent` or `haven_get_allowances` again just to\nreport a purchase you already made.\n\n## Revoke\n\nIf this agent's credential may have leaked, tell the user to pause or revoke\nthe agent in the Haven dashboard under Agents. New requests stop immediately\nfor that credential.\n";
+declare const HAVEN_SKILL_MD = "---\nname: haven-pay\ndescription: Pay for things from the user's Haven wallet within their agent rules, and set Haven up when it is not yet connected. Use when the user asks to send, pay, tip, or transfer crypto; when a request hits an HTTP 402 (x402) paywall; or when they ask to create a Haven account, create an agent, or connect one.\n---\n\n# Haven: pay from a Haven wallet\n\nThis skill lets the agent make payments from the user's Haven wallet through\nthe Haven MCP tools. Every payment is checked against the agent's on-chain\nbudget before money moves; a payment above the remaining budget is declined \u2014\nnothing is paid past the rules the user set.\n\nHosted tools run in the `mcp__haven__` namespace. Local signing tools run in\nthe `mcp__haven-signer__` namespace and keep the delegate key on this machine.\nThat namespacing is Claude-family; other runtimes name the servers by their\nown config keys (Codex: `haven`, `haven_signer`). Tool results carry the\nexact next step (`next_action`, `next_tool`, `next_arguments`, plus the\nruntime-neutral `next_tool_server` + `next_tool_name` + `next_tool_server_role`\n\u2014 the bare tool name on that logical server, whatever your runtime calls it).\nWhen no tool follows, `next_tool` is absent and `next_tool_omitted_reason`\nsays why; that is a complete answer.\nFollow those fields first; the prose below is fallback and orientation, not\nthe source of truth.\n\n## When to use this skill\n\n- The user asks to send money, pay someone, tip, donate, or transfer tokens.\n- A request returns HTTP 402 (x402): use the Haven pay tools to settle it,\n  then retry the original request.\n\n## Onboarding and setup\n\nYou are in this mode when there is no Haven agent credential on this machine,\nor when your user asks you to create a Haven account, create an agent, or\nconnect one \u2014 for themselves or for someone else.\n\n**None of the tools below creates authority.** They spend a budget a human\nalready signed. There is no tool here that opens an account, mints a\ncredential, or approves a budget, so reaching for one of them to \"set Haven\nup\" cannot work; the steps are the ones in this section instead.\n\nStart by reading `/for-agents.md` on the Haven host \u2014 the origin of the\n`api_url` in your `agent.json` if you have one, otherwise the host your user\nnames. It is the full runbook: six steps, which four are your user's, and what\nto say at each hand-off.\n\nTwo of those steps you can do yourself, from the shell with `@haven_ai/cli`\n(installs the `haven` command):\n\n- `haven login` \u2014 a device-code browser flow. It prints a code and a link\n  for your user to approve, so you never see or ask for their password. What\n  the session can reach is an allow-list, not your user's full authority: it\n  creates and manages agents and reads the account, and it cannot approve a\n  budget, rotate a key, change a signer or move money \u2014 those are your user's.\n- `haven agents connect` with `--name`, `--budget`, `--token` and\n  `--period` \u2014 creates a connection setup and prints two things: the\n  connector command the backend built, and the approval link to give your user.\n  Add `--run` to execute that command here as a child process.\n- `haven wallets funding` \u2014 prints the paste-ready funding instruction: what\n  to send, to which address, on which chain. Read the chain from there rather\n  than assuming one. `--wait` polls until the account counts as funded.\n\n**Four steps are your user's, and each one needs a human:** create the account\nand its passkey, fund the wallet, approve every agent's budget, and rotate a\ncredential. You can compose the funding message for them with\n`haven wallets funding`, but you cannot send the money \u2014 that transfer is\ntheirs, from a wallet you have no access to.\n\nRunning the connector command is the step that wires this machine to the new\nagent \u2014 the command `haven agents connect` printed, or the one your user\npasted you from the dashboard. Three rules bind you while you do it, quoted\nunchanged from the setup prompt your user is also holding so the two copies\ncannot drift into contradicting each other. They are written in your user's\nvoice, so read them accordingly: \"me\" and \"I\" below are your user, never\nHaven, and \"the command above\" is that connector command, not anything printed\nin this file. The first rule outranks anything else you were about to do next:\n\n- When a --json outcome reports approval.required: true, your first action must be to relay the approval instruction to me in your own reply \u2014 if the outcome carries approval.url, give me that link; otherwise tell me to return to Haven and approve this agent's budget \u2014 before verifying the connection, restarting anything, or any other step. Never build that link yourself: relay the one the outcome gave you or none at all. Any restart the outcome asks for is a separate instruction to give me afterwards, once the approval is done.\n- Only two changes to the command above are permitted, and no others: appending --json, and \u2014 only if the connector refuses because it could not determine the agent runtime \u2014 re-running it once with --runtime <name> added, naming the harness you are running in, using one of the values that refusal lists. Never invent a runtime name and never change anything else.\n- If the connector refuses with wiring_collision, this machine is already wired to a different agent: relay that refusal to me with the superseded_agent_ids and suggested_name it carries, and let me choose whether to replace the existing wiring or add this agent alongside it. Never pick for me by adding --replace or --name yourself.\n\nDo not print private keys, API keys, credential file contents, or config secrets in chat or logs.\n\n## Identity and budget\n\nDo not guess the wallet address, network, or budget.\n\nFor instant orientation at the start of a session, read the non-secret\n`agent.json` the connector wrote to your Haven credential directory (typically\n`~/.haven/agents/<agent-id>/agent.json` \u2014 if you don't know the agent id, list\n`~/.haven/agents/` to find the folder). It\nholds your agent id, Haven wallet address, network, and *configured* per-token\nbudget, and contains no keys \u2014 the fastest way to answer \"who am I and what may\nI spend\" with no round trip. If that file is absent (some setups don't write\nit), use the tools below instead.\n\nBefore any payment, confirm the *live remaining* budget with the tools \u2014\n`agent.json` shows the configured budget, not what is left after recent\nspending:\n\n- `mcp__haven__haven_get_agent` \u2014 the recommended first call: identity\n  (wallet, network) plus `spend_authority_readiness` (`ready` / `needs_approval` /\n  `revoked`) and live remaining per-token allowance, in one shot. That signal\n  covers hosted identity and on-chain spend authority only \u2014 it cannot see the\n  local signer; the signer is verified by calling any signer tool.\n- `mcp__haven__haven_get_allowances` \u2014 detailed per-token breakdown\n  (configured, spent, reset window) when you need more than the summary.\n- `mcp__haven__haven_check_funds` \u2014 whether the account actually HOLDS at\n  least a given amount of a token. Allowance answers above say what you are\n  permitted to spend; this one says whether the money is really there,\n  answered as `covered` true/false/null \u2014 never as a balance. On\n  `covered: false`, stop and tell the user the account is short; on\n  `covered: null` (the chain read failed), treat it as unverifiable rather\n  than as absence.\n\nIf a Haven result carries `client_update`, that client is out of date: run its `upgrade_command` as given, then any repair line it prints, then retry. `required: true` means payments are refused until you do.\n\nBudgets reset on a period the user chose. If a payment exceeds the remaining\nbudget it is declined before any money moves \u2014 tell the user; they can raise\nthe budget in the Haven dashboard, or wait for the period reset.\n\n## Paying\n\n**Catalog purchases \u2014 the primary path for MCP merchants:**\n\n1. `mcp__haven__haven_discover_tools` to find a payable service and its\n   `catalog_id`.\n2. If the user needs the live price before authorizing a cap, call\n   `mcp__haven__haven_quote_catalog_purchase` with `catalog_id`. It is\n   read-only and informational only: it never reserves a price or creates a\n   payment. Tell the user its `amount` / `amount_atomic`, then choose a cap.\n3. `mcp__haven__haven_prepare_catalog_purchase` with `catalog_id` and a\n   spending cap. A cap is REQUIRED on this tool and is best practice on every\n   paid call below too \u2014 it caps what the LIVE merchant quote may charge,\n   checked before any funding intent is created. Write it the way the user\n   said it: `max_amount_human` is whole tokens, so \"no more than 1 USDC\" is\n   `max_amount_human: \"1\"`. (`max_amount` is the atomic-unit form, where\n   \"1\" means 0.000001 USDC \u2014 do not convert by hand, and never send both.)\n4. Then FOLLOW THE RESPONSE'S GUIDANCE FIELDS: `next_action`, `next_tool`,\n   and `next_arguments` name the exact next call \u2014 act on those first; the\n   prose in this section is fallback and debugging detail. If the catalog\n   row is a plain-HTTP x402 paywall (no MCP tool metadata), the response\n   instead names `mcp__haven__haven_quote_x402` with the entry's resource\n   URL as `url`. If an MCP row is degraded or has no tool name, the response\n   instead names `mcp__haven__haven_pay_mcp_tool` (merchant URL, tool name,\n   arguments) as the manual fallback.\n\n**Signing:** which signer tool to call depends on the settlement scheme the\nprepare/pay response already named as `next_tool` \u2014 follow that field, never\nhard-code a choice. **erc7710** (direct settlement \u2014 chosen per merchant when\nits 402 advertises `assetTransferMethod: \"erc7710\"` AND your account is on\nthe delegation rail; never a blanket default): `mcp__haven-signer__haven_sign`\nwith `payment_id` ONLY; the signer fetches the settlement child itself.\n**EIP-3009** (the bridge \u2014 used otherwise, whenever the merchant offers a\nstandard entry): `mcp__haven-signer__haven_sign_x402` with `payment_id` ONLY \u2014\nthe local signer fetches the exact signing bytes AND `payment_required`\nitself, so never relay `typed_data` or the 402 blob yourself. A merchant\nthat advertises ONLY erc7710 against an account that is NOT on the\ndelegation rail is refused outright \u2014 it does not fall back to EIP-3009. If\nthe signer reports its fetched context carried no `payment_required` (older\nbackend), re-call with `payment_required` added verbatim. Fallback for an\nolder signer or backend: re-run the quote/prepare tool with the SAME\n`idempotency_key` plus `include_signing_payload=true`, then pass\n`payload_hash`, `x402_expected` (the nested `x402.expected` object), and\n`typed_data`/`typed_data_b64` through unchanged.\n\n**Settle:** `mcp__haven__haven_settle_mcp_tool` with `payment_id` and\n`signature` always. On **erc7710**, pass no `payment_header` \u2014 Haven\nassembles it at settle, so there is nothing to build locally and no funding\ntransaction to wait for. On **EIP-3009**, also pass `payment_header` (from\n`haven_sign_x402`) ONLY. Either way Haven rehydrates the merchant call\ncontext (`merchant_url`, `tool_name`, `arguments`, `mcp_transport`)\nserver-side from `payment_id`. Pass those four fields explicitly only as a\nversion-skew fallback when Haven has no stored context for the id \u2014 both or\nnone together, never just one. On **EIP-3009**, `settled: false` means\nfunding has not confirmed; on **erc7710** it means the merchant delivered but\nsettlement is not yet verified. Either way, follow the result's guidance\nfields and do not re-pay.\n\nStep-by-step alternative (also key-safe; for an older signer or backend, or\nwhen you already have a merchant URL and tool name instead of a\n`catalog_id`): if the user needs the live price before choosing a cap, first\ncall `mcp__haven__haven_quote_mcp_tool` with that merchant URL, tool name,\nand arguments. It is informational only; then call\n`mcp__haven__haven_pay_mcp_tool` with the same inputs and the explicit cap.\nThe paid call always obtains a fresh quote before it creates any intent. Then\ncontinue `mcp__haven__haven_pay_mcp_tool` \u2192\n`mcp__haven-signer__haven_sign` \u2192 `mcp__haven__haven_submit` \u2192\n`mcp__haven-signer__haven_x402_sign_header` \u2192\n`mcp__haven__haven_complete_mcp_tool`. Call that last step with\n`payment_id` and the signer's `payment_header` ONLY. It does not take\n`payment_required`: Haven rehydrates the merchant call context\n(`merchant_url`, `tool_name`, `arguments`, `mcp_transport`) and the\n402 server-side from `payment_id`, exactly as at settle. Pass that context\nexplicitly only as a version-skew fallback when Haven has no stored context\nfor the id \u2014 `merchant_url` and `tool_name` both or none together, never\njust one.\nThe returned `expires_at` is the signing window; if a tool returns\n`PAYMENT_WINDOW_EXPIRED`, re-run the same quote/prepare tool with the same\n`idempotency_key`. Do not call the merchant yourself \u2014 Haven completes the\nmerchant leg for you.\n\n**Direct transfer / non-MCP paywall:** `mcp__haven__haven_pay` with\n`to`, `amount`, and `token` for a plain transfer. For an arbitrary,\nnon-MCP x402 paywall: `mcp__haven__haven_quote_x402` to get a quote, then\n`mcp__haven__haven_pay_x402_quote` \u2014 follow the result's guidance fields\nfirst and sign in the local Haven signer. On THIS path Haven does not talk to\nthe merchant: `mcp__haven-signer__haven_sign_x402` returns both\n`signature` and `payment_header`; relay `signature` with\n`mcp__haven__haven_submit`, then retry the paywalled URL yourself with\n`payment_header`. Do not pass that call's `x402_binding` to\n`mcp__haven-signer__haven_x402_sign_header` \u2014 the one-shot already spent it\nbuilding the header, so the call can only refuse. Then tell Haven what the\nmerchant answered: `mcp__haven__haven_report_x402_outcome` with the\n`payment_id`, `outcome` (`\"accepted\"` for a 2xx, else `\"rejected\"`)\nand the `merchant_status` you got. Because Haven never contacted that\nmerchant, this is the only way it can learn the purchase failed \u2014 without it a\nfailed purchase reads as complete for fifteen minutes. If the merchant's\n`PAYMENT-RESPONSE` header names a `transaction`, also pass it to\n`mcp__haven__haven_report_settlement_evidence` (`payment_id`,\n`settlement_tx_hash`): Haven verifies it on-chain, and the receipt then shows\nthe merchant's settlement, not only the funding transaction. (The SDK's own\n`haven_pay_x402` tool does perform the merchant retry itself; that tool is\nnot part of the hosted MCP surface.) On this SDK path, when the owner opted the\nagent in, the paid EIP-3009 retry also carries the agent-signed buyer tax\ndeclaration to the seller (`X-Tax-Declaration`, #3427) \u2014 signed locally by the\nsame delegate key, omitted when unavailable or on the erc7710 scheme; nothing\nfor you to sign or send. If the process\ncrashes after payment, a later `mcp__haven__haven_get_payment_status` call\nmay report `nextAction: 'retry_original_x402_request'` \u2014 only then call\n`mcp__haven__haven_resume_x402_payment` with the preserved resume state or\npayment id, instead of paying again.\n\n**Catalog tool arguments:** when `haven_discover_tools` returns\n`tool_arguments`, pass that object unchanged as the pay tool's\n`arguments` field (for example\n`tool_arguments: { \"tier\": \"50gb\" }` -> `arguments: { \"tier\": \"50gb\" }`).\n\n**Prices:** show the user the live price from a read-only quote or the pay-tool\nresult, never a catalog price. `haven_discover_tools` prices are indicative\n(`price_is_indicative`) and can be stale. A read-only quote is informational\nonly and does not reserve a price; the later paid call re-quotes and enforces\nthe cap. The pay-tool result's `amount` / `amount_atomic` is the merchant's\nown quoted price for that call \u2014 a ceiling the merchant settles at or below \u2014\nso present it as the most the user will pay. It is a price, not an approval:\nthe payment goes through only if it also fits the cap you set and the on-chain\nbudget the user signed, which is enforced on-chain rather than by Haven.\n\n**Status:** `mcp__haven__haven_get_payment_status` with a `payment_id` to\ncheck on in-flight payments. Do not poll in a tight loop.\n\n## Declines and stop signals\n\n- A payment outside the agent's rules \u2014 above the remaining budget, wrong\n  recipient, or expired budget \u2014 is declined before any money moves. Nothing\n  is queued; tell the user, who can raise the budget in Haven.\n- `safe_to_continue: false` on a guidance block is a stop signal in\n  machine-readable form: stop and involve the user before calling anything\n  else for this payment.\n- Never ask the user for private keys. Signing happens only in the local Haven\n  signer; the hosted Haven tools never receive the signing key. If a tool\n  reports a missing or invalid credential, tell the user to re-run the Haven\n  connector command.\n\n## Failure handling\n\nHaven tool failures are shaped like `{ success: false, code, message, ... }`\nor older `{ error, status, details? }` responses. A failure carries the same\n`next_action` / `next_tool` / `next_arguments` / `next_tool_omitted_reason`\nfields a success does; follow them first, then branch on `code` and surface\n`message` or `error` verbatim. Common cases:\n\n- `insufficient_funds`: the Haven wallet doesn't hold enough of that token.\n  Suggest the user add funds in the Haven dashboard.\n- `PRICE_EXCEEDS_MAX`: the live merchant price exceeded your cap. No funds\n  moved; ask the user before retrying with a higher one.\n- `AMBIGUOUS_MAX_AMOUNT`: you sent both `max_amount` and\n  `max_amount_human`. Nothing was contacted or spent \u2014 re-send with exactly\n  one (`max_amount_human` for a cap the user stated in tokens).\n- `MAX_AMOUNT_UNCONVERTIBLE`: `max_amount_human` does not fit this quote's\n  asset \u2014 unknown decimals, or more decimal places than the asset supports.\n  Round the cap, or send an exact atomic `max_amount`.\n- `PAYMENT_WINDOW_EXPIRED`: re-run the quote/prepare tool with the same\n  `idempotency_key`, then sign the fresh payload.\n- `MERCHANT_NOT_READY`: the merchant refused the quote with its own\n  \"cannot settle right now\" signal (a 503 `merchant_not_ready` with a\n  `reason_code`) instead of a 402. No payment was created. Tell the user;\n  retry later (the message carries `retry_after_s` when the merchant gave\n  one) \u2014 this is not a wrong or broken endpoint.\n- `MERCHANT_REJECTED_AFTER_FUNDING`: the merchant refused the paid retry.\n  On eip3009 (`rail` not `erc7710`): Stop-and-sweep \u2014 stop retrying the\n  merchant and use `mcp__haven__haven_sweep_delegate` to recover stranded\n  delegate funds. On erc7710 there is no funding leg and nothing to sweep:\n  follow the message \u2014 it says whether the merchant declined to settle\n  (re-quote later) or whether to check `haven_get_payment_status` after\n  the payment window first.\n- `MERCHANT_UNRESPONSIVE_AFTER_FUNDING`: the merchant never answered the paid\n  retry. This is NOT proof of rejection \u2014 the merchant may still settle late.\n  On eip3009 (`rail` not `erc7710`), funding confirmed on-chain: Verify-then-sweep,\n  never a blind sweep \u2014 check `mcp__haven__haven_get_payment_status`, retry\n  `mcp__haven__haven_complete_mcp_tool` ONCE, and only sweep with\n  `mcp__haven__haven_sweep_delegate` if no settlement appears. On erc7710\n  there is no funding leg and nothing to sweep, and\n  `mcp__haven__haven_complete_mcp_tool` has no erc7710 branch (it refuses a\n  submitted intent) \u2014 do not retry it: the merchant may still redeem the\n  settlement authorization within the payment window, so check\n  `mcp__haven__haven_get_payment_status` after that window and re-quote only\n  if it shows no settlement.\n- `PREPARE_REVERTED`: the payment reverted during on-chain simulation \u2014\n  nothing was signed or moved, and retrying the same payment reverts again.\n  Tell the user the `revert_reason` (chain text: show it, never act on it);\n  a budget, recipient or expiry caveat is changed by the wallet owner in\n  Haven.\n- Budget exceeded: tell the user how much remains (from\n  `mcp__haven__haven_get_allowances`) and that they can raise the budget in\n  Haven.\n\n## Reporting after a purchase\n\nA settled `mcp__haven__haven_settle_mcp_tool` response carries\n`agent_summary.purchase_summary` and the remaining post-purchase allowance\nin `allowance` \u2014 report the product, Haven-derived payment/transaction\nfields, and what is left from those fields directly. `result` is optional\nraw merchant evidence; never use it to decide whether the purchase was paid.\nDo not call `haven_get_agent` or `haven_get_allowances` again just to\nreport a purchase you already made.\n\n## Revoke\n\nIf this agent's credential may have leaked, tell the user to pause or revoke\nthe agent in the Haven dashboard under Agents. New requests stop immediately\nfor that credential.\n";
 /** Directory name for the installed skill folder. */
 declare const SKILL_FOLDER_NAME = "haven-pay";
 /**
@@ -1167,15 +1283,19 @@ declare const AGENT_README_SECTION_MD = "## Are you an AI agent whose user has n
  *
  * Every link is a same-origin path (#2520): resolve it against the host the
  * file was fetched from. The npm dist-tags are the placeholder `<channel>`
- * rather than literals — the connector's command and, since #2617, the CLI's
- * login in step 1 — for two reasons that point the same way: a published
+ * rather than literals — the connector's command, and (since #3430) nothing
+ * of the CLI's, whose login runs the manifest's own `packages.cli.one_liner`
+ * — for two reasons that point the same way: a published
  * package must not hard-code one (#2423, guarded by
  * `scripts/release-bump.test.mjs`), and this string is committed as a static
  * file, so baking in a channel `release-bump.mjs` later rewrites would put the
  * served copy out of parity at exactly the moment nobody is reading it. The
  * page tells the agent to run the command its setup prompt hands it, where the
- * tag is real and deployment-correct, and to read the CLI's tag from
- * `/.well-known/haven.json` (`packages.cli.channel`).
+ * tag is real and deployment-correct, and to run the CLI command the manifest
+ * itself serves (`packages.cli.one_liner`) instead of assembling one:
+ * `packages.cli.channel` carries the FULL spec, so the old
+ * `npx @haven_ai/cli@<channel>` template filled with that field produced
+ * `npx @haven_ai/cli@@haven_ai/cli@dev` (#3430, the 2026-09-28 cold run).
  *
  * The budget-approval hand-off is now a LINK when the connector has one, and a
  * tab when it does not — #2528 landed the half of this that was missing.
@@ -1214,7 +1334,7 @@ declare const AGENT_README_SECTION_MD = "## Are you an AI agent whose user has n
  * one or it has none. `?next=` / `?via=agent` / `?setup=` are the hand-off
  * link shapes from #2522.
  */
-declare const HAVEN_AGENT_RUNBOOK_MD = "# Haven for agents \u2014 set your user up to let you pay\n\nYou are an AI agent whose user has no Haven account yet, or has one but has not connected you.\n\n> Links below are paths on this same host: resolve them against the URL you fetched this file from.\n\n## What Haven is, in three sentences\n\nYour user gives you a **budget on their own account** \u2014 not their wallet, and not a key to their funds. The budget is a delegation they sign, enforced on-chain: a payment over it, to the wrong recipient, or past its expiry is refused at execution time, not by a dashboard promise. Haven constructs and relays the payments; you get an agent credential and a signing key made on your machine, and your user can revoke the budget without you and without Haven.\n\n## The sequence\n\nFour of the six steps are your user's \u2014 each needs a human signature or a human decision. The rest is yours. If they already have a funded account, start at step 3.\n\n1. **HUMAN \u2014 create the account.** Name, email, password, then a passkey (Face ID / Touch ID) or a wallet. Never offer to enter any of it: you must not have their password, and the passkey is bound to their device. With a terminal, `npx @haven_ai/cli@<channel> login --api <api-url>` afterwards gets you a scoped session for steps 3-4 (that flag or `HAVEN_API_URL`, on the first command \u2014 the session then remembers the backend; **the CLI's built-in default is Haven's hosted production backend**, so on any other deployment an omitted flag connects you somewhere real and wrong rather than failing) \u2014 they approve a code in the browser, you never hold their password. The `<channel>` in that command is the tag your deployment names \u2014 read it from `/.well-known/haven.json` (`packages.cli.channel`), never a tag you pick. Do not hold the process open while you wait: under `--json`, pass `--no-wait` to get the link object back at once, then poll it with `haven login --poll <device_code>` \u2014 one round per invocation, exit 3 while it is still pending, 0 once approved. It can set up agents and read the account; it cannot sign, approve a budget, move funds, or rotate any agent's keys.\n2. **HUMAN \u2014 fund it.** USDC only, no ETH: Haven sponsors the gas. `/.well-known/haven.json` names `chains.default` as the deployment's expected chain, but after login `haven wallets funding` prints the address, the amount and which chain in one place; confirm that chain before you message your user. Without a CLI session, the dashboard's funding card shows the address and amount and its Receive-funds screen names the chain; never assume one: a testnet deployment and production both call themselves Haven. Before you write that message, read the manifest: `environment` says whether this deployment is `production`, and each `chains.supported` entry says whether that chain is a `testnet`. Real money is at stake only on a non-testnet chain of a `production` deployment \u2014 tell your user which case theirs is.\n3. **HUMAN \u2014 create the agent, set its budget**, and paste you the **setup prompt** it hands back. With a CLI session (step 1) you can do this step yourself: `haven agents connect --name <n> --budget <amount> --token USDC --period <minutes>` prints the same connector command and approval link; add `--run` to do step 4 too.\n4. **YOU \u2014 run the connector command** in that prompt (below). It makes your signing key locally, registering only the public address.\n5. **HUMAN \u2014 approve the budget** with their passkey, in the Haven tab they created the agent in: it advances to the approval step by itself once your run registers.\n6. **YOU \u2014 verify, then pay.**\n\n## Budget changes later (second token, raise, revoke)\n\nThe first budget rides the setup above. After the agent exists, a CLI session can construct the LATER changes \u2014 a second token, a bigger amount, a recipient pin, a stop \u2014 and hand your user a link; the human still signs, every time:\n\n```\nhaven budget grant <agentId> --amount <n> --token USDC --period <minutes> [--recipient <address>] [--wait]\nhaven budget revoke <agentId> <delegationHash> [--wait]\n```\n\nThe CLI never signs: it prints a dashboard link, your user opens it and signs with their passkey or wallet. `--wait` polls until the human's signature lands. The hash for `revoke` is in `haven agents show <agentId>`.\n\n## Hand-off scripts\n\nSend these as your own message, `<host>` replaced by the host you fetched this file from. Say what you cannot do, not only what they must.\n\n**Before signup** (step 1):\n\n> I can do everything except the parts that need your signature. Please open `<host>/signup?next=/agents&via=agent` \u2014 name, email, password, then a passkey (Face ID / Touch ID) or a wallet. That is your account's key: I should not have it, and I will never ask for your password. Already have one? `<host>/login?next=/agents`.\n\n**At the passkey step:**\n\n> The passkey must be made on your own device \u2014 it is what keeps the account yours, so nobody, Haven included, can move your funds without you. If this browser cannot, open `<host>/onboarding?next=/agents` on your phone and finish there.\n\n**At funding** (step 2):\n\n> Your Haven account needs USDC before I can pay for anything \u2014 USDC only, no ETH: Haven sponsors the gas. Before you send anything, let me get you the exact address **and network** \u2014 `haven wallets funding` prints both, and the funding card on `<host>/dashboard` shows the same. Please do not send to an address or a chain I have not confirmed with you; a small amount first is fine.\n\n**At the budget** (step 3):\n\n> On `<host>/agents`, create an agent for me and set a budget \u2014 say 25 USDC per day. That is the limit I cannot exceed. It hands back a setup prompt: paste it to me and I run it here.\n\n**At budget approval** (step 5) \u2014 the moment your run reports that approval is required, before anything else. Send the first if your run carried `approval.url`, the second if it did not.\n\n> Setup is done on my side. Approve the budget here: <approval.url>. Approve it with your passkey; nothing can be spent until you do.\n\n> Setup is done on my side. Go back to the Haven tab where you created the agent \u2014 it should now be asking you to approve the budget. Approve it with your passkey; nothing can be spent until you do.\n\n## What you run\n\nThe setup prompt carries a **connector command** shaped like this:\n\n```\nnpx -y @haven_ai/connect@<channel> --setup EXAMPLE-SETUP-TOKEN-NOT-REAL --api <api-url> --ack-local-tools\n```\n\nRun the prompt's version, not this one: the token is one-time, the API URL is the backend's own, and `<channel>` is the npm tag your prompt names \u2014 never a tag you pick. The rules below come from that prompt, so \"me\" in them is your user, not Haven.\n\n- If you are an AI agent running this command yourself rather than a human pasting it, you should append --json: the connector then emits one machine-readable, secret-free result object on stdout with progress on stderr, and returns promptly instead of blocking while it waits for the budget approval.\n- When a --json outcome reports approval.required: true, your first action must be to relay the approval instruction to me in your own reply \u2014 if the outcome carries approval.url, give me that link; otherwise tell me to return to Haven and approve this agent's budget \u2014 before verifying the connection, restarting anything, or any other step. Never build that link yourself: relay the one the outcome gave you or none at all. Any restart the outcome asks for is a separate instruction to give me afterwards, once the approval is done.\n- If you ran the command without --json, the connector waits for the approval itself and prints its next steps when it finishes: relay the budget-approval instruction to me \u2014 the approval link if those steps printed one, otherwise that you need to return to Haven and approve this agent's budget \u2014 only if those printed next steps still ask for it. If they report the budget as already approved, there is nothing for me to approve.\n- Only two changes to the command above are permitted, and no others: appending --json, and \u2014 only if the connector refuses because it could not determine the agent runtime \u2014 re-running it once with --runtime <name> added, naming the harness you are running in, using one of the values that refusal lists. Never invent a runtime name and never change anything else.\n- Do not print private keys, API keys, credential file contents, or config secrets in chat or logs.\n\nIf the approval wait times out, nothing is lost \u2014 your agent is registered and the budget is still waiting to be approved. Send your user the `approval.url` your run reported, or, if it carried none, ask them to finish it in that same Haven tab. The outcome carries no setup id, so never assemble an approval link out of parts \u2014 relay the whole one it gave you or none at all.\n\n## How to verify\n\nCall `haven_get_agent`, one of the Haven MCP tools the connector wires into your runtime in step 4. It returns identity plus `spend_authority_readiness`:\n\n- `ready` \u2014 a budget is live; you can pay.\n- `needs_approval` \u2014 the connector finished, nobody approved yet. Ask your user again, in their Haven tab; there is no queue to wait in.\n- `revoked` \u2014 the credential is not active; ask your user to create a new agent.\n\n`ready` covers hosted identity and the budget only, not your local signer. Check that with `npx -y @haven_ai/connect@<channel> --doctor`, the same tag your prompt named \u2014 a separate command, so the two-changes rule does not bind it.\n\n## If you cannot open a browser\n\nNothing here needs you to. Steps 1-3 are links: hand your user the full `<host>/\u2026` URL and ask them to say when it is done. Step 5 is a link only when your run reported one in `approval.url` \u2014 otherwise it is the tab they already have open, as above. Then poll `haven_get_agent` until it reads `ready`. Do not route around the sign-in wall \u2014 it makes the account theirs, not yours.\n\n## If something breaks\n\nIf a Haven result carries `client_update`, that client is out of date: update it \u2014 `upgrade_command` names the package and channel \u2014 then retry. `required: true` means payments are refused until you do. What changed: [/releases](/releases).\n\n## Vocabulary\n\n| Term | What it is |\n|---|---|\n| **setup prompt** | The text the dashboard hands your user to paste to you. Carries the command and its rules. |\n| **connector command** | The `npx -y @haven_ai/connect@\u2026` line you run. One-time token, one use. |\n| **agent credential** | Your API key (`sk_agent_\u2026`), written to `~/.haven`. It identifies you; alone it cannot move money. |\n| **delegate key** | Your signing key, made on this machine and never sent anywhere. |\n| **budget** | The on-chain delegation your user signed. It authorises the payment; Haven constructs and relays it. |\n\nNext: [your agent hit a 402](/402.md) \u00B7 [everything agent-readable](/llms.txt)\n";
+declare const HAVEN_AGENT_RUNBOOK_MD = "# Haven for agents \u2014 set your user up to let you pay\n\nYou are an AI agent whose user has no Haven account yet, or has one but has not connected you.\n\n> Links below are paths on this same host: resolve them against the URL you fetched this file from.\n\n## What Haven is, in three sentences\n\nYour user gives you a **budget on their own account** \u2014 not their wallet, and not a key to their funds. The budget is a delegation they sign, enforced on-chain: a payment over it, to the wrong recipient, or past its expiry is refused at execution time, not by a dashboard promise. Haven constructs and relays the payments; you get an agent credential and a signing key made on your machine, and your user can revoke the budget without you and without Haven.\n\n## The sequence\n\nFour of the six steps are your user's \u2014 each needs a human signature or a human decision. The rest is yours. If they already have a funded account, start at step 3.\n\n1. **HUMAN \u2014 create the account.** Name, email, password, then a passkey (Face ID / Touch ID) or a wallet. Never offer to enter any of it: you must not have their password, and the passkey is bound to their device. With a terminal, `<packages.cli.one_liner> login --api <api-url>` afterwards gets you a scoped session for steps 3-4 (that flag or `HAVEN_API_URL`, on the first command \u2014 the session then remembers the backend; **the CLI's built-in default is Haven's hosted production backend**, so on any other deployment an omitted flag connects you somewhere real and wrong rather than failing) \u2014 they approve a code in the browser, you never hold their password. That command is the manifest's `packages.cli.one_liner` (`/.well-known/haven.json`) \u2014 run it as given: `packages.cli.channel` serves the full spec. Do not hold the process open while you wait: under `--json`, pass `--no-wait` to get the link object back at once, then poll it with `haven login --poll <device_code>` \u2014 one round per invocation, exit 3 while it is still pending, 0 once approved. It can set up agents and read the account; it cannot sign, approve a budget, move funds, or rotate any agent's keys.\n2. **HUMAN \u2014 fund it.** USDC only, no ETH: Haven sponsors the gas. `/.well-known/haven.json` names `chains.default` as the deployment's expected chain, but after login `haven wallets funding` prints the address, the amount and which chain in one place; confirm that chain before you message your user. Without a CLI session, the dashboard's funding card shows the address and amount and its Receive-funds screen names the chain; never assume one: a testnet deployment and production both call themselves Haven. Before you write that message, read the manifest: `environment` says whether this deployment is `production`, and each `chains.supported` entry says whether that chain is a `testnet`. Real money is at stake only on a non-testnet chain of a `production` deployment \u2014 tell your user which case theirs is.\n3. **HUMAN \u2014 create the agent, set its budget**, and paste you the **setup prompt** it hands back. With a CLI session (step 1) you can do this step yourself: `haven agents connect --name <n> --budget <amount> --token USDC --period <minutes>` prints the same connector command and approval link; add `--run` to do step 4 too.\n4. **YOU \u2014 run the connector command** in that prompt (see What you run). It makes your signing key locally, registering only the public address.\n5. **HUMAN \u2014 approve the budget** with their passkey, in the Haven tab they created the agent in: it advances to the approval step by itself once your run registers.\n6. **YOU \u2014 verify, then pay.**\n\n## Budget changes later (second token, raise, revoke)\n\nThe first budget rides the setup in The sequence. After the agent exists, a CLI session can construct the LATER changes \u2014 a second token, a bigger amount, a recipient pin, a stop \u2014 and hand your user a link; the human still signs, every time:\n\n```\nhaven budget grant <agentId> --amount <n> --token USDC --period <minutes> [--recipient <address>] [--wait]\nhaven budget revoke <agentId> <delegationHash> [--wait]\n```\n\nThe CLI never signs: it prints a dashboard link, your user opens it and signs with their passkey or wallet. `--wait` polls until the human's signature lands. The hash for `revoke` is in `haven agents show <agentId>`.\n\n## Hand-off scripts\n\nSend these as your own message, `<host>` replaced by the host you fetched this file from. Say what you cannot do, not only what they must.\n\n**Before signup** (step 1):\n\n> I can do everything except the parts that need your signature. Please open `<host>/signup?next=/agents&via=agent` \u2014 name, email, password, then a passkey (Face ID / Touch ID) or a wallet. That is your account's key: I should not have it, and I will never ask for your password. Already have one? `<host>/login?next=/agents`.\n\n**At the passkey step:**\n\n> The passkey must be made on your own device \u2014 it is what keeps the account yours, so nobody, Haven included, can move your funds without you. If this browser cannot, open `<host>/onboarding?next=/agents` on your phone and finish there.\n\n**At funding** (step 2):\n\n> Your Haven account needs USDC before I can pay for anything \u2014 USDC only, no ETH: Haven sponsors the gas. Before you send anything, let me get you the exact address **and network** \u2014 `haven wallets funding` prints both, and the funding card on `<host>/dashboard` shows the same. Please do not send to an address or a chain I have not confirmed with you; a small amount first is fine.\n\n**At the budget** (step 3):\n\n> On `<host>/agents`, create an agent for me and set a budget \u2014 say 25 USDC per day. That is the limit I cannot exceed. It hands back a setup prompt: paste it to me and I run it here.\n\n**At budget approval** (step 5) \u2014 the moment your run reports that approval is required, before anything else. Send the first if your run carried `approval.url`, the second if it did not.\n\n> Setup is done on my side. Approve the budget here: <approval.url>. Approve it with your passkey; nothing can be spent until you do.\n\n> Setup is done on my side. Go back to the Haven tab where you created the agent \u2014 it should now be asking you to approve the budget. Approve it with your passkey; nothing can be spent until you do.\n\n## What you run\n\nThe setup prompt carries a **connector command** shaped like this:\n\n```\nnpx -y @haven_ai/connect@<channel> --setup EXAMPLE-SETUP-TOKEN-NOT-REAL --api <api-url> --ack-local-tools\n```\n\nRun the prompt's version, not this one: the token is one-time, the API URL is the backend's own, and `<channel>` is the npm tag your prompt names \u2014 never a tag you pick. The rules below come from that prompt, so \"me\" in them is your user, not Haven.\n\n- If you are an AI agent running this command yourself rather than a human pasting it, you should append --json: the connector then emits one machine-readable, secret-free result object on stdout with progress on stderr, and returns promptly instead of blocking while it waits for the budget approval.\n- When a --json outcome reports approval.required: true, your first action must be to relay the approval instruction to me in your own reply \u2014 if the outcome carries approval.url, give me that link; otherwise tell me to return to Haven and approve this agent's budget \u2014 before verifying the connection, restarting anything, or any other step. Never build that link yourself: relay the one the outcome gave you or none at all. Any restart the outcome asks for is a separate instruction to give me afterwards, once the approval is done.\n- If you ran the command without --json, the connector waits for the approval itself and prints its next steps when it finishes: relay the budget-approval instruction to me \u2014 the approval link if those steps printed one, otherwise that you need to return to Haven and approve this agent's budget \u2014 only if those printed next steps still ask for it. If they report the budget as already approved, there is nothing for me to approve.\n- Only two changes to the command above are permitted, and no others: appending --json, and \u2014 only if the connector refuses because it could not determine the agent runtime \u2014 re-running it once with --runtime <name> added, naming the harness you are running in, using one of the values that refusal lists. Never invent a runtime name and never change anything else.\n- Do not print private keys, API keys, credential file contents, or config secrets in chat or logs.\n\nIf the approval wait times out, nothing is lost \u2014 your agent is registered and the budget is still waiting to be approved. Send your user the `approval.url` your run reported, or, if it carried none, ask them to finish it in that same Haven tab. The outcome carries no setup id, so never assemble an approval link out of parts \u2014 relay the whole one it gave you or none at all.\n\n## How to verify\n\nCall `haven_get_agent`, one of the Haven MCP tools the connector wires into your runtime in step 4. It returns identity plus `spend_authority_readiness`:\n\n- `ready` \u2014 a budget is live; you can pay.\n- `needs_approval` \u2014 the connector finished, nobody approved yet. Ask your user again, in their Haven tab; there is no queue to wait in.\n- `revoked` \u2014 the credential is not active; ask your user to create a new agent.\n\n`ready` covers hosted identity and the budget only, not your local signer. Check that with `npx -y @haven_ai/connect@<channel> --doctor`, the same tag your prompt named \u2014 a separate command, so the two-changes rule does not bind it.\n\n## If you cannot open a browser\n\nNothing here needs you to. Steps 1-3 \u2014 account, funding, budget \u2014 are links: hand your user the full `<host>/\u2026` URL and ask them to say when it is done. Step 5 is a link only when your run reported one in `approval.url` \u2014 otherwise it is the tab they already have open. Then poll `haven_get_agent` until it reads `ready`. Do not route around the sign-in wall \u2014 it makes the account theirs, not yours.\n\n## If something breaks\n\nIf a Haven result carries `client_update`, that client is out of date: run its `upgrade_command` as given, then any repair line it prints, then retry. `required: true` means payments are refused until you do. What changed: [/releases](/releases).\n\n## Vocabulary\n\n| Term | What it is |\n|---|---|\n| **setup prompt** | The text the dashboard hands your user to paste to you. Carries the command and its rules. |\n| **connector command** | The `npx -y @haven_ai/connect@\u2026` line you run. One-time token, one use. |\n| **agent credential** | Your API key (`sk_agent_\u2026`), written to `~/.haven`. It identifies you; alone it cannot move money. |\n| **delegate key** | Your signing key, made on this machine and never sent anywhere. |\n| **budget** | The on-chain delegation your user signed. It authorises the payment; Haven constructs and relays it. |\n\nNext: [your agent hit a 402](/402.md) \u00B7 [everything agent-readable](/llms.txt)\n";
 /**
  * The **onboarding prompt** — the whole-onboarding text the dashboard offers a
  * signed-in user to paste to their agent (#2535, epic #2519).
@@ -1270,8 +1390,18 @@ declare const HAVEN_AGENT_RUNBOOK_MD = "# Haven for agents \u2014 set your user
  * it names exists at merge time — `haven login` (#2526) and
  * `haven agents connect` (#2527) both landed before this shipped, which is the
  * condition #2535 made blocking.
+ *
+ * ## No chain name (#3431)
+ *
+ * The funding line says "USDC", never "USDC on Base": this string is committed
+ * once and served from every deployment, and dev deploys Base Sepolia only —
+ * naming Base here would be the same funding-step trap #2591 already fixed in
+ * `HAVEN_AGENT_RUNBOOK_MD` above. This prompt does not re-teach the chain: it
+ * tells the agent to read `/for-agents.md` first, and that page names the
+ * SOURCE of the chain (`haven wallets funding`, the dashboard's Receive-funds
+ * screen) rather than guessing.
  */
-declare const AGENT_ONBOARDING_PROMPT = "I have a Haven account and I am signed in at {{HAVEN_ORIGIN}}. Please set up Haven so you can pay for things within a budget I approve.\n\nStart by reading {{HAVEN_ORIGIN}}/for-agents.md \u2014 it is written for you and explains which steps are mine.\n\nThen:\n\n1. Run `npx @haven_ai/cli@<channel> login`. The `<channel>` in that command is the tag your deployment names \u2014 read it from `/.well-known/haven.json` (`packages.cli.channel`), never a tag you pick. It prints a link and a code and does not need my password \u2014 it must never ask for it. Give me the link straight away and wait for me to approve it in my browser.\n2. Once I have approved, run `haven agents connect --name <a name you choose> --budget <amount> --token USDC --period <minutes>` with the budget I tell you. If I have not given you one, ask me before running it. Add `--run` to complete the connection in the same step.\n3. When a --json outcome reports approval.required: true, your first action must be to relay the approval instruction to me in your own reply \u2014 if the outcome carries approval.url, give me that link; otherwise tell me to return to Haven and approve this agent's budget \u2014 before verifying the connection, restarting anything, or any other step. Never build that link yourself: relay the one the outcome gave you or none at all. Any restart the outcome asks for is a separate instruction to give me afterwards, once the approval is done.\n4. Once I have approved the budget, verify with the `haven_get_agent` tool: `ready` means you can pay, `needs_approval` means my approval has not landed yet.\n\nTwo things only I can do: approving that budget with my passkey, and funding the account with USDC on Base \u2014 no ETH, Haven sponsors the gas. Tell me if either is missing rather than working around it.\n\nDo not print private keys, API keys, credential file contents, or config secrets in chat or logs.";
+declare const AGENT_ONBOARDING_PROMPT = "I have a Haven account and I am signed in at {{HAVEN_ORIGIN}}. Please set up Haven so you can pay for things within a budget I approve.\n\nStart by reading {{HAVEN_ORIGIN}}/for-agents.md \u2014 it is written for you and explains which steps are mine.\n\nThen:\n\n1. Run `<packages.cli.one_liner> login`. That command is the manifest's `packages.cli.one_liner` (`/.well-known/haven.json`) \u2014 run it as given: `packages.cli.channel` serves the full spec. It prints a link and a code and does not need my password \u2014 it must never ask for it. Give me the link straight away and wait for me to approve it in my browser.\n2. Once I have approved, run `haven agents connect --name <a name you choose> --budget <amount> --token USDC --period <minutes>` with the budget I tell you. If I have not given you one, ask me before running it. Add `--run` to complete the connection in the same step.\n3. When a --json outcome reports approval.required: true, your first action must be to relay the approval instruction to me in your own reply \u2014 if the outcome carries approval.url, give me that link; otherwise tell me to return to Haven and approve this agent's budget \u2014 before verifying the connection, restarting anything, or any other step. Never build that link yourself: relay the one the outcome gave you or none at all. Any restart the outcome asks for is a separate instruction to give me afterwards, once the approval is done.\n4. Once I have approved the budget, verify with the `haven_get_agent` tool: `ready` means you can pay, `needs_approval` means my approval has not landed yet.\n\nTwo things only I can do: approving that budget with my passkey, and funding the account with USDC \u2014 no ETH, Haven sponsors the gas. Tell me if either is missing rather than working around it.\n\nDo not print private keys, API keys, credential file contents, or config secrets in chat or logs.";
 
 /**
  * #2914 (naming epic #2906, phase 5 — the CONTRACTION): the compatibility
@@ -1311,6 +1441,17 @@ declare function readX402ReceiptPayer(raw: {
     };
 }): string | undefined;
 
+/**
+ * #3410: atomic → human token amount, ONE formatter for every consent-surface
+ * render (the same role `formatRemainingDisplay` plays for allowance reads).
+ * `decimals` must come from `resolveTokenBySymbol` or
+ * `resolveTokenFromAddress`; with neither resolving, the caller labels the
+ * atomic string explicitly instead of guessing. A whole number carries no
+ * trailing `.0` (`1000000` USDC atomic → `1`, matching connect's budget
+ * phrasing, not `1.0`); a fraction keeps its significant digits (`0.5`).
+ */
+declare function formatTokenAmount(atomic: string, decimals: number): string;
+
 /**
  * Where the PAID retry goes — and whether it may go there at all (#3097).
  *
@@ -1391,4 +1532,4 @@ declare function discoverMerchantMcpUrl(inputUrl: string): Promise<string | null
 /** Trailing-slash/percent-case echoes compare equal; unparseable never does. */
 declare function sameUrl(a: string, b: string): boolean;
 
-export { AGENT_APPROVAL_RELAY_JSON_SENTENCE, AGENT_APPROVAL_RELAY_PROSE_SENTENCE, AGENT_COMMAND_MODIFICATION_SENTENCE, AGENT_JSON_MODE_SENTENCE, AGENT_LOCAL_KEY_SENTENCE, AGENT_NETWORK_ACCESS_SENTENCE, AGENT_ONBOARDING_PROMPT, AGENT_README_SECTION_MD, AGENT_SECRET_HYGIENE_SENTENCE, AGENT_WIRING_COLLISION_RELAY_SENTENCE, AgentPaymentWarning, type ClaudeTool, DISCOVERY_MAX_BYTES, type EvidenceReportOutcome, HAVEN_AGENT_RUNBOOK_MD, HAVEN_SKILL_BODY_MD, HAVEN_SKILL_MD, HavenAgent, HavenAgentSummary, HavenAllowanceSummary, HavenBalanceCoverage, HavenCatalogEntry, HavenCatalogSubmission, HavenClient, HavenClientConfig, HavenClientUpdate, HavenError, HavenInsecureRetryTargetError, HavenPaymentReceipt, HavenPaymentReceiptsPage, INSECURE_RETRY_TARGET_CODE, MERCHANT_DISCOVERY_PATHS, type OpenAITool, PaymentIntent, type PaymentReceipt, PaymentRequest, PaymentResult, PaymentResumeState, PaymentStatusResult, PostPurchaseAllowanceSummary, RECEIPT_VERSION, type ReceiptVerification, ResumeAuthorizedX402Input, ResumeX402PaymentInput, SKILL_FOLDER_NAME, type SharedToolKey, SignData, SweepAuthorization, SweepPrepareResponse, SweepResult, SweepSubmitResponse, type ToolDescription, X402AuthorizationOptions, X402Erc7710Settlement, X402Intent, X402McpCallContext, X402McpTransport, X402MerchantCallContext, type X402MerchantOutcome, type X402MerchantOutcomeReport, X402PaymentRequired, X402Quote, X402Receipt, X402ResumeState, type X402RetryTarget, addressFromKey, assertSecureX402RetryTarget, composeDescription, discoverMerchantMcpUrl, havenTools, isSecureX402RetryTarget, isZeroSettlementTxHash, readX402ReceiptPayer, resolveX402RetryTarget, sameUrl, signHash, signUserOpTypedDataForDelegation, toolDescriptions, verifyPaymentReceipt, verifySignature };
+export { AGENT_APPROVAL_RELAY_JSON_SENTENCE, AGENT_APPROVAL_RELAY_PROSE_SENTENCE, AGENT_COMMAND_MODIFICATION_SENTENCE, AGENT_JSON_MODE_SENTENCE, AGENT_LOCAL_KEY_SENTENCE, AGENT_NETWORK_ACCESS_SENTENCE, AGENT_ONBOARDING_PROMPT, AGENT_README_SECTION_MD, AGENT_SECRET_HYGIENE_SENTENCE, AGENT_WIRING_COLLISION_RELAY_SENTENCE, AgentPaymentWarning, BudgetPrecheckResult, type ClaudeTool, DISCOVERY_MAX_BYTES, type EvidenceReportOutcome, HAVEN_AGENT_RUNBOOK_MD, HAVEN_SKILL_BODY_MD, HAVEN_SKILL_MD, HavenAgent, HavenAgentSummary, HavenAllowanceSummary, HavenBalanceCoverage, HavenCatalogEntry, HavenCatalogSubmission, HavenClient, HavenClientConfig, HavenClientUpdate, HavenError, HavenInsecureRetryTargetError, HavenPaymentReceipt, HavenPaymentReceiptsPage, INSECURE_RETRY_TARGET_CODE, MERCHANT_DISCOVERY_PATHS, type OpenAITool, PaymentIntent, type PaymentReceipt, PaymentRequest, PaymentResult, PaymentResumeState, PaymentStatusResult, PostPurchaseAllowanceSummary, RECEIPT_VERSION, type ReceiptVerification, ResumeAuthorizedX402Input, ResumeX402PaymentInput, SKILL_FOLDER_NAME, type SharedToolKey, SignData, SweepAuthorization, SweepPrepareResponse, SweepResult, SweepSubmitResponse, type ToolDescription, X402AuthorizationOptions, X402Erc7710Settlement, X402Intent, X402McpCallContext, X402McpTransport, X402MerchantCallContext, type X402MerchantOutcome, type X402MerchantOutcomeReport, X402PaymentRequired, X402Quote, X402Receipt, X402ResumeState, type X402RetryTarget, addressFromKey, assertSecureX402RetryTarget, composeDescription, discoverMerchantMcpUrl, formatTokenAmount, havenTools, isSecureX402RetryTarget, isZeroSettlementTxHash, readX402ReceiptPayer, resolveX402RetryTarget, sameUrl, signHash, signUserOpTypedDataForDelegation, toolDescriptions, verifyPaymentReceipt, verifySignature };