@x402api/agent-wallet-cli 0.2.7 → 0.2.8

package/README.md

@@ -13,7 +13,7 @@ The CLI runs on the buyer or agent host; merchant integrations do not host it
 or receive its keys. A wallet's funded token balance is spend authority, and
 `wallet create --maximum-payment-atomic N` can add a per-payment ceiling. The
 ceiling is not a daily, cumulative, or merchant-specific permission and cannot
-be updated in place in version 0.2.7.
+be updated in place in version 0.2.8.
 
 Run `x402api wallet setup --json` once on a fresh host. It idempotently creates
 a high-entropy managed unlock file under the private x402api data root; the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@x402api/agent-wallet-cli",
-  "version": "0.2.7",
+  "version": "0.2.8",
   "description": "Command-line wallet for autonomous x402 purchases.",
   "license": "MIT",
   "repository": {
@@ -38,6 +38,6 @@
     "lint": "tsc --noEmit -p tsconfig.json"
   },
   "dependencies": {
-    "@x402api/agent-wallet-core": "0.2.7"
+    "@x402api/agent-wallet-core": "0.2.8"
   }
 }

package/skill/references/cli-reference.md

@@ -41,7 +41,7 @@ x402api wallet sweep --wallet NAME --to ADDRESS --json
 `--maximum-payment-atomic` is an optional canonical decimal in atomic units for
 the wallet's supported payment asset. It is enforced on each authorization and
 returns `payment_limit_exceeded` when the exact amount is larger. It is not a
-daily or cumulative budget. Version 0.2.7 sets it only at wallet creation and
+daily or cumulative budget. Version 0.2.8 sets it only at wallet creation and
 does not provide a policy-update command.
 
 On a fresh host, `wallet setup` atomically creates one high-entropy managed

package/skill/references/merchant-integration.md

@@ -31,6 +31,10 @@ integration. It is not the buyer payment identifier, does not affect the token
 authorization, and must not be added to this exact V1 envelope. The wallet
 creates its own `buyerPaymentIdentifier` when it authorizes a selected payment
 requirement.
+`challengeDigest` is the authoritative `charge_digest` returned by x402api
+programmatic charge creation. Copy it unchanged. Do not derive it from
+`PAYMENT-REQUIRED`; that hash is not the frozen server challenge and the wallet
+rejects it before signing.
 
 ## Programmatic charge handoff
 
@@ -45,7 +49,8 @@ That operation belongs to trusted merchant server code—not this wallet.
   exact runtime amounts for a non-empty subset; the wallet independently
   validates and selects one returned `PAYMENT-REQUIRED.accepts` alternative.
 - The request envelope receives only the exact credential-free protected
-  request and canonical `PAYMENT-REQUIRED` challenge. It never contains the
+  request, canonical `PAYMENT-REQUIRED` challenge, and authoritative
+  `charge_digest` mapped to `challengeDigest`. It never contains the
   tenant API credential, `resource_version_id`, or a tenant-side API request.
 - Retiring or replacing a template is a merchant concern. The wallet validates
   the exact issued challenge and must not discover, guess, or rewrite a

package/skill/references/safety.md

@@ -9,7 +9,7 @@ Base, Solana, and TRON.
 
 An optional `maximumPaymentAtomic` value adds a local ceiling to each payment.
 It does not limit aggregate or daily spend, restrict merchants, revoke existing
-artifacts, or protect a wallet on a compromised same-user host. Version 0.2.7
+artifacts, or protect a wallet on a compromised same-user host. Version 0.2.8
 sets this value only when creating a wallet and has no policy-update command.
 
 Show the exact network, token contract or mint, public address, and requested