@zkp2p/cash 0.4.10 → 0.4.11-rc.1

package/AGENTS.md

@@ -4,9 +4,10 @@
 > contribute to the SDK itself (layout, ground rules, CI, releasing), start at
 > [CLAUDE.md](https://github.com/zkp2p/peer-cash/blob/main/CLAUDE.md).
 
-You are integrating Peer Cash: an offramp that routes any Relay-supported EVM
-source asset into Base USDC, then converts Base USDC to fiat (Venmo, Revolut,
-Wise, Zelle, ...) at the live Chainlink market rate. The user whose USDC you
+You are integrating Peer Cash: an offramp that routes Relay-supported EVM
+assets or NEAR Intents 1Click external deposits into Base USDC, then converts
+Base USDC to fiat (Venmo, Revolut, Wise, Zelle, ...) at the live Chainlink
+market rate. The user whose USDC you
 manage is the **maker**; a buyer pays them fiat and proves it with TEE-TLS; the
 protocol releases the USDC. Funds are held by the protocol, and only the maker
 can withdraw an unmatched deposit.
@@ -23,14 +24,18 @@ can withdraw an unmatched deposit.
    the plan, submit the transactions in order, and wait for each receipt. After
    `createDeposit` confirms, pass its receipt to `finalizePreparedCashout()` and
    persist the returned `depositId`. If the original plan set
-   `accessPolicyRequired: true`, submit and confirm
-   `prepareAccessPolicy(depositId)` with the depositor next.
+   a non-empty `accessPolicyPaymentMethods`, submit and confirm
+   `prepareAccessPolicy(depositId, paymentMethod)` with the depositor for each
+   returned method.
 3. **You are a tool-use host** (MCP server, CLI) → import the manifest from
    `@zkp2p/cash/tools` and map the tool names to the verbs above. Base-USDC
    mutating tools return unsigned transactions. `cash_source_quote` is a quote,
    not an execution tool; the host must execute and confirm Relay through its
    signer/runtime, use `cash_source_status` to monitor it, then call the
-   Base-USDC `cash_cashout` tool. Never pass `source` into `prepare()`.
+   Base-USDC `cash_cashout` tool. For NEAR Intents, persist
+   `cash_near_intents_quote`, fund its deposit address externally exactly once,
+   and poll `cash_near_intents_status` to `SUCCESS` before the Base cash-out.
+   Never pass `source` into `prepare()`.
 
 Every transaction (including approves) carries ERC-8021 attribution:
 `peer-cash`, then optional `peer-ref-XXXXXX` from the six-character
@@ -41,13 +46,13 @@ deposit-level integration share instead of applying maker L1/L2.
 **Platform caveats:**
 
 - **Venmo, Cash App, and PayPal restrict who can signal intents by default.**
-  If any payout leg uses one of these platforms, signed
-  `cashout()` confirms `createDeposit`, then submits and confirms the Plus, Pro,
-  Peer Makers, and Peer Pay policy using the same viem wallet. This is a
-  deliberate non-atomic follow-up with a brief unprotected interval. For
-  `prepare()`, check `accessPolicyRequired`; after `createDeposit` confirms,
-  finalize its receipt and submit `prepareAccessPolicy(depositId)` with the
-  depositor. Any viem EOA works; Privy is not required.
+  Signed `cashout()` confirms `createDeposit`, then submits and confirms a
+  method-scoped Peer Pay merchant policy for every restricted payout leg using
+  the same viem wallet. This is a deliberate non-atomic follow-up with a brief
+  unprotected interval. For `prepare()`, read `accessPolicyPaymentMethods`;
+  after `createDeposit` confirms, finalize its receipt and submit
+  `prepareAccessPolicy(depositId, paymentMethod)` for every returned method.
+  Any viem EOA works; Privy is not required.
 
 - **Wise and PayPal** carry `requiresIdentityAttestation: true`. A new curator
   registration needs a signed maker identity attestation this SDK cannot mint
@@ -70,6 +75,8 @@ const cash = createCashClient({ environment: 'production' });
 const caps = cash.capabilities();
 // Optional: live Relay EVM source chains/tokens.
 const relayCaps = await cash.capabilities({ includeRelaySources: true });
+// Optional: live NEAR Intents 1Click external-deposit assets.
+const nearCaps = await cash.capabilities({ includeNearIntentsSources: true });
 
 // 2. Estimate - idempotent, cacheable, no side effects. Includes rolling ETA.
 const est = await cash.estimate({ amount: usdc(500), currency: 'EUR' });
@@ -148,6 +155,32 @@ console.log(routed.source?.amount);
 console.log(routed.source?.transactions?.origin, routed.source?.transactions?.destination);
 ```
 
+External-deposit source route (NEAR Intents / Zcash example):
+
+```ts
+const quote = await cash.quoteNearIntentsSource({
+  sourceAsset: 'nep141:zec.omft.near',
+  amount: usdc(1), // EXACT_OUTPUT is denominated in Base USDC units
+  recipient: signer.account.address,
+  refundTo: transparentZcashAddress,
+  tradeType: 'EXACT_OUTPUT',
+  deadline: new Date(Date.now() + 3 * 60_000).toISOString(),
+});
+persist(quote); // do this before the origin send
+const txHash = await zcashWallet.send(quote.depositAddress!, quote.inputAmount);
+await cash.submitNearIntentsDeposit({
+  depositAddress: quote.depositAddress!,
+  ...(quote.depositMemo ? { depositMemo: quote.depositMemo } : {}),
+  txHash,
+});
+const route = await cash.nearIntentsStatus({
+  depositAddress: quote.depositAddress!,
+  ...(quote.depositMemo ? { depositMemo: quote.depositMemo } : {}),
+  expectedQuote: quote,
+});
+// Reconcile the Base receipt/output when route.status === 'SUCCESS', then cash out Base-only.
+```
+
 ## Rules that prevent wrong behavior
 
 - **Never promise a rate.** `estimate()` is `kind: 'oracle-estimate'`; the
@@ -165,6 +198,15 @@ console.log(routed.source?.transactions?.origin, routed.source?.transactions?.de
   `sourceSigner`. Use `EXACT_INPUT` in high-level cash-out flows so `amount`
   remains source-token base units. `source.amount` is Relay's guaranteed
   minimum output and the exact Base USDC deposit amount.
+- **Treat NEAR Intents as an external-deposit route.** Discover asset ids with
+  `capabilities({ includeNearIntentsSources: true })`. Persist the signed quote,
+  deposit address, optional memo, and deadline before sending. Browser code
+  uses a same-origin proxy so the 1Click JWT remains server-side. Never reuse
+  an expired route or resend after an uncertain wallet submission.
+- **A failed NEAR deposit notification is not a failed send.** Retry only
+  `submitNearIntentsDeposit()` with the same address and hash; 1Click also
+  detects source deposits on-chain. Wait for `nearIntentsStatus()` `SUCCESS`
+  and reconcile its destination evidence before a Base-only cash-out.
 - **Use a nonce-managed source signer for routed cashouts.** Relay routes
   with more than one source-chain transaction (approve, then route) are
   refused preflight with `SOURCE_NONCE_MANAGER_REQUIRED` on plain local
@@ -236,6 +278,7 @@ Every `CashError` carries `code`, `retryable`, `remediation`. Behavior:
 | `SOURCE_QUOTE_FAILED`                   | yes       | Refresh capabilities and request a new canonical Base-USDC quote                           |
 | `SOURCE_NONCE_MANAGER_REQUIRED`         | no        | Preflight; recreate the source signer with viem's `nonceManager`, then quote again         |
 | `SOURCE_EXECUTION_FAILED`               | no        | Inspect source transactions and Relay status before any retry                              |
+| `SOURCE_DEPOSIT_SUBMISSION_FAILED`      | yes       | Retry only the 1Click notification; never resend source funds                              |
 | `SOURCE_STATUS_FAILED`                  | yes       | Retry only the status read                                                                 |
 | `SOURCE_ROUTE_COMPLETED_CASHOUT_FAILED` | no        | Do not route again; retry Base-only with `recovery.amount`                                 |
 | `SOURCE_CASHOUT_SUBMISSION_UNKNOWN`     | no        | Inspect Base activity and orders; prove no deposit exists before retrying                  |
@@ -270,7 +313,7 @@ Prove your integration against `environment: 'staging'` with a funded test
 wallet. Never wait on a buyer - buyer-side is out of your scope:
 
 1. `cashout()` a small amount (1–2 USDC) → capture `depositId` and, for a
-   restricted payout, `accessPolicyTxHash`.
+   restricted payout, every entry in `accessPolicyTxHashes`.
 2. `order(depositId)` shows `awaiting-buyer` (retry through indexer lag).
 3. `orders(owner)` includes the deposit.
 4. `withdraw(depositId)` → transaction succeeds.

package/README.md

@@ -1,8 +1,9 @@
 # @zkp2p/cash
 
-Route any Relay-supported EVM source asset into Base USDC, then cash out to
-fiat on Venmo, Revolut, Wise, Zelle, and more at the live Chainlink market
-rate, with zero spread and no centralized off-ramp provider.
+Route Relay-supported EVM assets or NEAR Intents 1Click external deposits into
+Base USDC, then cash out to fiat on Venmo, Revolut, Wise, Zelle, and more at the
+live Chainlink market rate, with zero spread and no centralized off-ramp
+provider.
 
 Peer Cash is an **offramp-only** SDK for the [ZKP2P](https://peer.xyz)
 protocol. The cashing-out user is the maker: their USDC becomes a deposit in
@@ -38,7 +39,7 @@ const fillStats = await cash.fillStats();
 const pairStats = fillStats['venmo:USD'];
 const multiCurrencyStats = fillStats['revolut:EUR+GBP+USD'];
 
-const { depositId, accessPolicyTxHash } = await cash.cashout(
+const { depositId, accessPolicyTxHashes } = await cash.cashout(
   {
     amount: usdc(1000),
     receive: { platform: 'venmo', currency: 'USD', payee: '@you' },
@@ -46,7 +47,7 @@ const { depositId, accessPolicyTxHash } = await cash.cashout(
   { signer }, // any viem WalletClient on Base, including an EOA
 );
 // Venmo, Cash App, and PayPal return only after their access policy confirms.
-console.log(depositId, accessPolicyTxHash);
+console.log(depositId, accessPolicyTxHashes);
 
 // One method can offer several currencies. The buyer chooses the fill
 // currency, and each option resolves at its own live oracle rate.
@@ -100,13 +101,16 @@ arbitrary protocol operations.
 | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
 | `capabilities()`                                               | Sync discovery: Base USDC destination/default source, platforms × currencies × payee hints × amount bounds                      |
 | `capabilities({ includeRelaySources: true })`                  | Async discovery: adds live Relay SDK EVM source chains/tokens                                                                   |
+| `capabilities({ includeNearIntentsSources: true })`            | Async discovery: adds live NEAR Intents 1Click source assets                                                                    |
 | `fillStats()`                                                  | Cached 30-day fill counts and median first-fill time per exact `platform:currency` pair or sorted multi-currency set            |
 | `quoteSource(input)` / `executeSourceQuote(quote, { signer })` | Relay SDK EVM source routing into Base USDC before cashout                                                                      |
 | `relayStatus(requestId)`                                       | Relay request status from the Relay SDK request path                                                                            |
+| `quoteNearIntentsSource(input)`                                | Signed 1Click quote with an origin-chain deposit address and optional memo                                                      |
+| `submitNearIntentsDeposit(input)` / `nearIntentsStatus(input)` | Optionally register an origin tx, then track 1Click delivery/refund evidence                                                    |
 | `estimate({ amount, currency }, { includeEta? })`              | Base USDC oracle estimate; optionally skip the historical ETA for progressive rendering                                         |
-| `cashout(input, { signer })`                                   | Creates the order with any viem wallet; Venmo, Cash App, and PayPal then attach the canonical access groups                     |
-| `prepare(input)` / `finalizePreparedCashout(receipt)`          | Prepare external signing, resolve the deposit, then check `accessPolicyRequired` for the follow-up                              |
-| `prepareAccessPolicy(depositId)`                               | Prepare the post-deposit Plus, Pro, Peer Makers, and Peer Pay policy transaction                                                |
+| `cashout(input, { signer })`                                   | Creates the order with any viem wallet; restricted methods then attach the Peer Pay merchant policy                             |
+| `prepare(input)` / `finalizePreparedCashout(receipt)`          | Prepare external signing, resolve the deposit, then iterate `accessPolicyPaymentMethods` for follow-ups                         |
+| `prepareAccessPolicy(depositId, paymentMethod)`                | Prepare one post-deposit, method-scoped Peer Pay merchant policy transaction                                                    |
 | `order(depositId)` / `orders(owner)`                           | Resume any order from its id alone; list all orders for a wallet                                                                |
 | `watch(depositId)`                                             | Async iterator: yields on every state change until terminal, abort, or timeout                                                  |
 | `withdraw(depositId, { signer, amount? })`                     | The ONE unwind verb - partial with an `amount` (live intents don't block it), full close without (prunes expired intents first) |
@@ -137,8 +141,8 @@ mixed historical deposit.
 
 | Payout rail           | Access-policy behavior                                                     | New payee registration                                                                 |
 | --------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
-| Venmo / Cash App      | Four groups attach after deposit confirmation                              | Curator validates the live handle                                                      |
-| PayPal                | Same four-group follow-up                                                  | Requires a Peer TEE browser-extension identity attestation                             |
+| Venmo / Cash App      | Peer Pay merchant policy attaches for that payment method                  | Curator validates the live handle                                                      |
+| PayPal                | Same method-scoped Peer Pay follow-up                                      | Requires a Peer TEE browser-extension identity attestation                             |
 | Wise                  | No access-policy follow-up                                                 | Requires a Peer TEE browser-extension identity attestation                             |
 | Other supported rails | No access-policy follow-up; use `capabilities()` for currencies and format | Follow the `payeeHint`; live-validation behavior is described in the integration guide |
 
@@ -148,14 +152,15 @@ EOA; no Privy wallet or signer API is required. The deprecated
 `requiresAtomicAccessPolicy` capability remains for wire compatibility and is
 always `false`.
 
-Venmo, Cash App, and PayPal cash-outs restrict intent signaling to Plus, Pro,
-Peer Makers, and Peer Pay groups by default. If any payout leg uses one of
-those platforms, signed `cashout()` creates the deposit first, then uses the
-same wallet to submit and confirm the policy transaction; this intentionally
+Venmo, Cash App, and PayPal cash-outs restrict intent signaling to the Peer Pay
+merchant group by default. Each restricted payout method gets its own policy.
+Signed `cashout()` creates the deposit first, then uses the same wallet to
+submit and confirm every required policy transaction; this intentionally
 leaves a brief non-atomic interval. Prepared integrations receive
-`accessPolicyRequired: true` and, after confirming `createDeposit`, must call
-`finalizePreparedCashout(receipt)` followed by
-`prepareAccessPolicy(depositId)`. Other platforms do not need the follow-up.
+`accessPolicyPaymentMethods`; after confirming `createDeposit`, call
+`finalizePreparedCashout(receipt)`, then submit
+`prepareAccessPolicy(depositId, paymentMethod)` once for every returned method.
+Other platforms do not need the follow-up.
 
 If policy attachment fails, `ACCESS_POLICY_CONFIGURATION_FAILED.recovery`
 identifies the existing deposit and any submitted policy transaction. Never
@@ -176,7 +181,9 @@ extension. An already-registered Wise or PayPal handle can be reused with bare
 payee data. A new handle without its signed attestation fails during curator
 registration with `PAYEE_VERIFICATION_REQUIRED`, before funds move on-chain.
 
-## Source routing (any EVM asset in)
+## Source routing
+
+### Relay (signed EVM route)
 
 The default/minimal flow is unchanged: pass Base USDC base units to
 `estimate()` and `cashout()`. For any other source asset, pass `source` to
@@ -189,7 +196,7 @@ discovered and quoted by `@relayprotocol/relay-sdk`, not a static token
 allowlist.
 
 ```ts
-const { depositId, accessPolicyTxHash, source } = await cash.cashout(
+const { depositId, accessPolicyTxHashes, source } = await cash.cashout(
   {
     amount: 10_000_000n, // exact input: 10 USDC in source-token base units
     source: {
@@ -206,7 +213,7 @@ const { depositId, accessPolicyTxHash, source } = await cash.cashout(
 // amount deposited into the cash-out order. It is not the route's actual output.
 console.log(source?.amount, source?.requestId);
 console.log(source?.transactions?.origin, source?.transactions?.destination);
-console.log(accessPolicyTxHash); // present because this example uses Venmo
+console.log(accessPolicyTxHashes); // one entry because this example uses Venmo
 ```
 
 Routes that submit more than one source-chain transaction (approve, then
@@ -216,6 +223,58 @@ refuses the route preflight with `SOURCE_NONCE_MANAGER_REQUIRED` instead of
 letting the route transaction reuse the approval's nonce and revert
 mid-route. Browser wallets are unaffected.
 
+### NEAR Intents (external-deposit route)
+
+NEAR Intents 1Click supports non-EVM origins such as Zcash, so the SDK does
+not pretend a viem wallet can execute the source transfer. It returns a signed
+quote with an origin-chain `depositAddress` and optional `depositMemo`; your
+wallet sends exactly once, then the SDK tracks the provider route into
+canonical Base USDC. Use `EXACT_OUTPUT` when the Peer order amount must be
+known before the origin send.
+
+```ts
+const cash = createCashClient({
+  environment: 'production',
+  nearIntents: {
+    // Browser-safe same-origin proxy; it keeps the 1Click JWT server-side.
+    apiUrl: '/api/v1/near',
+    transport: 'proxy',
+  },
+});
+
+const sources = await cash.capabilities({ includeNearIntentsSources: true });
+const zec = sources.source.nearIntents?.assets.find((asset) => asset.symbol === 'ZEC');
+const quote = await cash.quoteNearIntentsSource({
+  sourceAsset: zec!.assetId,
+  amount: 1_000_000n, // exact 1 Base USDC output
+  recipient: baseSigner.account.address,
+  refundTo: transparentZcashRefundAddress,
+  tradeType: 'EXACT_OUTPUT',
+  deadline: new Date(Date.now() + 3 * 60_000).toISOString(),
+});
+
+persist(quote); // before sending: address, memo, signed response, deadline
+const originTxHash = await zcashWallet.send(quote.depositAddress!, quote.inputAmount);
+await cash.submitNearIntentsDeposit({
+  depositAddress: quote.depositAddress!,
+  ...(quote.depositMemo ? { depositMemo: quote.depositMemo } : {}),
+  txHash: originTxHash,
+});
+const route = await cash.nearIntentsStatus({
+  depositAddress: quote.depositAddress!,
+  ...(quote.depositMemo ? { depositMemo: quote.depositMemo } : {}),
+  expectedQuote: quote,
+});
+// On SUCCESS, reconcile the Base receipt/balance, then call Base-only cashout().
+```
+
+Direct server integrations may pass `nearIntents: { token }`. Browser code
+must use a same-origin proxy and must never receive the 1Click JWT. Never reuse
+an expired deposit address, resend funds after an uncertain wallet submission,
+or infer success from a wallet-wide balance alone. If optional deposit
+registration fails, retry only `submitNearIntentsDeposit()` with the same hash;
+1Click can also detect the transfer on-chain.
+
 ## Source-route recovery
 
 Persist `depositId`, transaction hashes, and the Relay `requestId` as soon as
@@ -227,6 +286,9 @@ they are available. A source-routed result includes both a flat
   can stay in `relayStatus` `waiting` indefinitely. Decide from the error's
   recovery payload and origin transactions, never by waiting for a terminal
   Relay status.
+- `SOURCE_DEPOSIT_SUBMISSION_FAILED`: the NEAR Intents origin transaction may
+  already be final. Retry only the provider notification with the same address
+  and hash; never resend source funds.
 - `SOURCE_ROUTE_COMPLETED_CASHOUT_FAILED`: Relay completed, but the Base
   cashout was not created. Do not route again. Retry a Base-USDC-only
   `cashout()` with `BigInt(error.recovery.amount)`.
@@ -244,7 +306,8 @@ they are available. A source-routed result includes both a flat
 - `ACCESS_POLICY_CONFIGURATION_FAILED`: the deposit exists, but its required
   Venmo, Cash App, or PayPal policy was not confirmed. Do not cash out again;
   inspect `recovery.transactionHash` when present, then retry
-  `prepareAccessPolicy(error.recovery.depositId)` only if the prior policy
+  `prepareAccessPolicy(error.recovery.depositId, error.recovery.paymentMethod)`
+  only if the prior policy
   transaction did not succeed.
 
 Wallet clients pinned to the wrong chain fail with `SIGNER_CHAIN_MISMATCH`
@@ -325,8 +388,10 @@ analytics-only ERC-8021 codes such as `acme-app`.
 - Mutating tool calls return unsigned transactions by default; signing stays
   with the host that owns custody, policy, and user approval.
 - After a prepared restricted cash-out confirms, the host adapter must call
-  `finalizePreparedCashout(receipt)` and `prepareAccessPolicy(depositId)`; these
-  receipt/signing operations are `CashClient` methods, not built-in tool calls.
+  `finalizePreparedCashout(receipt)` and submit
+  `prepareAccessPolicy(depositId, paymentMethod)` for every value in
+  `accessPolicyPaymentMethods`; these receipt/signing operations are
+  `CashClient` methods, not built-in tool calls.
 - Every error carries `code`, `retryable`, and a `remediation` sentence.
 - Every order carries `nextActions: ('wait' | 'withdraw')[]` - no heuristics.
 - Every wire type has a zod schema + JSON codec - state crosses process
@@ -363,6 +428,10 @@ Runnable first-party examples in [`examples/`](examples):
 
 - [`node-cashout.ts`](examples/node-cashout.ts) - server-side cash-out with a private-key signer, plus order tracking.
 - [`agent-tool-use.ts`](examples/agent-tool-use.ts) - wiring the verbs into an agent tool-use loop with host-side signing.
+- [`carpe-diem-provider-cashout`](examples/carpe-diem-provider-cashout) - cash out confirmed Carpe Diem provider DIEM revenue through the connected Base wallet.
+- [`mpp-merchant-cashout`](examples/mpp-merchant-cashout) - turn confirmed MPP merchant revenue into an unsigned Peer Cash plan while the merchant keeps custody and signing.
+- [`onchain-demo`](examples/onchain-demo) - the Peer Cash Demo: the express sell flow as one page that bundles the SDK and is stored on Base as contract bytecode, served by an immutable ERC-5219 wrapper,
+  [live on Base](https://basescan.org/address/0x6d6c7af86bfc6f49f32761e1718cf982224cf343).
 
 ## Trust model, honestly
 

package/dist/{chunk-4LPWKZMW.js → chunk-JRJLMQS4.js}

@@ -3,24 +3,9 @@ var BASE_CHAIN_ID = 8453;
 var BASE_USDC_ADDRESS = "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913";
 var CASH_RESTRICTED_PLATFORMS = /* @__PURE__ */ new Set(["venmo", "cashapp", "paypal"]);
 var CASH_ACCESS_GROUP_IDS = {
-  production: [
-    "0xb8747401b308d4891385620071b5916e9c61284f25c4611541c529703de5babf",
-    "0xf030f72e772f954059ca28f94974088aaf6ba37bb1f264df48843a3d0c221dc3",
-    "0xdf1c64c54745aa1ce00642a5874f97e3183bf5e993c1f559d0a37a4df0b803c7",
-    "0x174b8a29536721a3eae290bfd55651b85a53fc334b971d993fa93ed8dde15e48"
-  ],
-  preproduction: [
-    "0xb8747401b308d4891385620071b5916e9c61284f25c4611541c529703de5babf",
-    "0xf030f72e772f954059ca28f94974088aaf6ba37bb1f264df48843a3d0c221dc3",
-    "0xdf1c64c54745aa1ce00642a5874f97e3183bf5e993c1f559d0a37a4df0b803c7",
-    "0x174b8a29536721a3eae290bfd55651b85a53fc334b971d993fa93ed8dde15e48"
-  ],
-  staging: [
-    "0xf6133c227eab8ae7da1ee143945bf7f31204394f3ba801dc9691f8af6ca8efa5",
-    "0xa6beb459bc621e7b050e431736c1c3298da26356d7095719185e859d68f70d9e",
-    "0x9cded1332f25c3ee0a9a822a4c827d3fbd081a8d7b2ba39c49917ec1983b8d6c",
-    "0xc82c20c00033046a2f017b65532d7148a337282f17c73296663a530e49ba00f7"
-  ]
+  production: ["0x174b8a29536721a3eae290bfd55651b85a53fc334b971d993fa93ed8dde15e48"],
+  preproduction: ["0x174b8a29536721a3eae290bfd55651b85a53fc334b971d993fa93ed8dde15e48"],
+  staging: ["0xc82c20c00033046a2f017b65532d7148a337282f17c73296663a530e49ba00f7"]
 };
 var USDC_DECIMALS = 6;
 var MARKET_SPREAD_BPS = 0;
@@ -217,21 +202,21 @@ var errors = {
     retryable: false,
     remediation: `For one-call source cashout, deliver Relay output to the depositor address. For a different recipient, bridge first and then cash out from that recipient's signer.`
   }),
-  sourceCapabilitiesFailed: (cause) => new CashError(
+  sourceCapabilitiesFailed: (cause, provider = "Relay", capabilityMethod = "sourceCapabilities") => new CashError(
     {
       code: "SOURCE_CAPABILITIES_FAILED",
-      message: `Relay source-chain discovery failed.`,
+      message: `${provider} source discovery failed.`,
       retryable: true,
-      remediation: `Retry sourceCapabilities() shortly, or use the default Base USDC path.`
+      remediation: `Retry ${capabilityMethod}() shortly, or use the default Base USDC path.`
     },
     { cause }
   ),
-  sourceQuoteFailed: (cause) => new CashError(
+  sourceQuoteFailed: (cause, provider = "Relay", quoteMethod = "quoteSource") => new CashError(
     {
       code: "SOURCE_QUOTE_FAILED",
-      message: `Relay did not return a valid route to canonical Base USDC.`,
+      message: `${provider} did not return a valid route to canonical Base USDC.`,
       retryable: true,
-      remediation: `Refresh source capabilities and request a new quote. Do not submit transactions from this response.`
+      remediation: `Refresh source capabilities and call ${quoteMethod}() again. Do not submit transactions from this response.`
     },
     { cause }
   ),
@@ -258,12 +243,21 @@ var errors = {
     },
     { cause }
   ),
-  sourceStatusFailed: (requestId, cause) => new CashError(
+  sourceDepositSubmissionFailed: (depositAddress, cause) => new CashError(
+    {
+      code: "SOURCE_DEPOSIT_SUBMISSION_FAILED",
+      message: `NEAR Intents could not register the origin transaction for deposit ${depositAddress}.`,
+      retryable: true,
+      remediation: `Retry only submitNearIntentsDeposit() with the same deposit address and origin transaction hash. Never resend the source funds; 1Click can also detect the deposit on-chain.`
+    },
+    { cause }
+  ),
+  sourceStatusFailed: (requestId, cause, provider = "Relay", statusMethod = "relayStatus") => new CashError(
     {
       code: "SOURCE_STATUS_FAILED",
-      message: `Relay status is unavailable for request ${requestId}.`,
+      message: `${provider} status is unavailable for route ${requestId}.`,
       retryable: true,
-      remediation: `Retry relayStatus(requestId) shortly; keep the request id and transaction hashes for recovery.`
+      remediation: `Retry ${statusMethod}() shortly; keep the route identifier and transaction hashes for recovery.`
     },
     { cause }
   ),
@@ -411,11 +405,12 @@ var errors = {
       code: "ACCESS_POLICY_CONFIGURATION_FAILED",
       message: `Cash-out deposit ${depositId} was created, but its access policy could not be confirmed.`,
       retryable: false,
-      remediation: `Do not create another cash-out. If recovery.transactionHash is present, inspect that policy transaction first. Otherwise, or if it is confirmed reverted, submit and confirm prepareAccessPolicy(recovery.depositId) with the same depositor wallet.`,
+      remediation: `Do not create another cash-out. If recovery.transactionHash is present, inspect that policy transaction first. Otherwise, or if it is confirmed reverted, submit and confirm prepareAccessPolicy(recovery.depositId, recovery.paymentMethod) with the same depositor wallet.`,
       recovery: {
         kind: "configure-cashout-access-policy",
         depositId,
         groupIds: [...groupIds],
+        ...context.paymentMethod ? { paymentMethod: context.paymentMethod } : {},
         ...context.transactionHash ? { transactionHash: context.transactionHash } : {},
         ...context.source ? {
           source: {