@x402api/agent-wallet-cli 0.2.1 → 0.2.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -4,9 +4,16 @@ Installs the `x402api` executable and bundled `x402api-pay` skill for persistent
|
|
|
4
4
|
agent wallets and exact x402 payments.
|
|
5
5
|
|
|
6
6
|
The launch payer authorizes only sponsored Base USDC and sponsored Solana
|
|
7
|
-
USDC/USDT. x402api supplies the network fee asset
|
|
8
|
-
SOL
|
|
9
|
-
|
|
7
|
+
USDC/USDT. x402api supplies the network fee asset from its platform treasury,
|
|
8
|
+
so buyers do not need ETH or SOL and actual gas is not debited from the
|
|
9
|
+
merchant tenant. TRON payment authorization returns `unsupported_profile`
|
|
10
|
+
until that rail is launched.
|
|
11
|
+
|
|
12
|
+
The CLI runs on the buyer or agent host; merchant integrations do not host it
|
|
13
|
+
or receive its keys. A wallet's funded token balance is spend authority, and
|
|
14
|
+
`wallet create --maximum-payment-atomic N` can add a per-payment ceiling. The
|
|
15
|
+
ceiling is not a daily, cumulative, or merchant-specific permission and cannot
|
|
16
|
+
be updated in place in version 0.2.3.
|
|
10
17
|
|
|
11
18
|
Run `x402api help --json` for the machine-readable command summary. Unlock
|
|
12
19
|
material is accepted only from standard input or an owner-only file named by
|
|
@@ -26,3 +33,6 @@ configured `X402API_NOTIFICATION_URL`. x402api resolves the verified refill
|
|
|
26
33
|
contact, tenant display name, and purchased product from the subscription
|
|
27
34
|
reference; the CLI never accepts an arbitrary recipient email or untrusted
|
|
28
35
|
tenant/product display text.
|
|
36
|
+
|
|
37
|
+
The client contract is included in this package, but the hosted notification
|
|
38
|
+
endpoint is deployed separately and is not provided by the CLI package.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@x402api/agent-wallet-cli",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.3",
|
|
4
4
|
"description": "Command-line wallet for autonomous x402 purchases.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"repository": {
|
|
@@ -38,6 +38,6 @@
|
|
|
38
38
|
"lint": "tsc --noEmit -p tsconfig.json"
|
|
39
39
|
},
|
|
40
40
|
"dependencies": {
|
|
41
|
-
"@x402api/agent-wallet-core": "0.2.
|
|
41
|
+
"@x402api/agent-wallet-core": "0.2.3"
|
|
42
42
|
}
|
|
43
43
|
}
|
package/skill/SKILL.md
CHANGED
|
@@ -22,6 +22,11 @@ Install only the skill bundled with the exact CLI version. If it is not already
|
|
|
22
22
|
installed, an operator can run `x402api skill install --output PATH --json`.
|
|
23
23
|
The command refuses to overwrite an existing skill directory.
|
|
24
24
|
|
|
25
|
+
The `x402api` CLI runs on the buyer or agent host where its encrypted wallet is
|
|
26
|
+
stored. Merchant tools, including the WarpMetal reference integration, may
|
|
27
|
+
prepare requests and consume artifacts, but they do not host the CLI or receive
|
|
28
|
+
its private keys.
|
|
29
|
+
|
|
25
30
|
Do not supply a passphrase on the command line. An operator must arrange
|
|
26
31
|
`X402API_WALLET_PASSWORD_FILE` as an owner-only file or supervise
|
|
27
32
|
`--password-stdin`. Never read, print, summarize, or paste that passphrase,
|
|
@@ -35,7 +40,8 @@ seed, private key, encrypted keystore, or complete payment signature.
|
|
|
35
40
|
an address from another network or create a new wallet merely because an
|
|
36
41
|
order is a renewal.
|
|
37
42
|
4. Treat the funded balance as fully spendable by the autonomous agent, subject
|
|
38
|
-
to any local per-payment ceiling.
|
|
43
|
+
to any local `maximumPaymentAtomic` per-payment ceiling. That ceiling is not
|
|
44
|
+
a daily, cumulative, or merchant-specific permission.
|
|
39
45
|
5. Show the public address, exact network, supported asset, sponsored native
|
|
40
46
|
fee currency, and requested token funding amount when funding is
|
|
41
47
|
insufficient. Never ask the owner to fund ETH/SOL or reveal or import a
|
|
@@ -74,7 +80,9 @@ instructions to the human instead of sending email.
|
|
|
74
80
|
request and receive its `402 Payment Required` challenge.
|
|
75
81
|
2. Have that integration write the exact credential-free request envelope.
|
|
76
82
|
Never place authorization tokens, cookies, SSH keys, or owner credentials in
|
|
77
|
-
the envelope.
|
|
83
|
+
the envelope. Keep any merchant-side `X-X402API-Challenge-Handle` out as
|
|
84
|
+
well; it is reconciliation metadata, not the buyer payment identifier or a
|
|
85
|
+
signing input.
|
|
78
86
|
3. Verify the URL, method, exact body bytes, resource, network, asset, amount,
|
|
79
87
|
recipient, profile, and challenge digest.
|
|
80
88
|
4. Require a launch-sponsored Base USDC or Solana USDC/USDT profile and the
|
|
@@ -98,7 +106,8 @@ submission rules.
|
|
|
98
106
|
Distinguish these states:
|
|
99
107
|
|
|
100
108
|
- funding: the wallet has usable USDC/USDT balance; x402api sponsors launch-rail
|
|
101
|
-
ETH/SOL from the merchant tenant's
|
|
109
|
+
ETH/SOL from its platform treasury, subject to the merchant tenant's active
|
|
110
|
+
sponsorship allowance;
|
|
102
111
|
- authorization: one durable payment artifact exists;
|
|
103
112
|
- settlement: the payment is authoritative on the chosen rail;
|
|
104
113
|
- fulfillment: the merchant returned the purchased result.
|
|
@@ -31,6 +31,12 @@ x402api wallet retire --wallet NAME --confirm NAME --json
|
|
|
31
31
|
x402api wallet sweep --wallet NAME --to ADDRESS --json
|
|
32
32
|
```
|
|
33
33
|
|
|
34
|
+
`--maximum-payment-atomic` is an optional canonical decimal in atomic units for
|
|
35
|
+
the wallet's supported payment asset. It is enforced on each authorization and
|
|
36
|
+
returns `payment_limit_exceeded` when the exact amount is larger. It is not a
|
|
37
|
+
daily or cumulative budget. Version 0.2.3 sets it only at wallet creation and
|
|
38
|
+
does not provide a policy-update command.
|
|
39
|
+
|
|
34
40
|
Unlocking commands additionally require `X402API_WALLET_PASSWORD_FILE` or an
|
|
35
41
|
operator-supervised `--password-stdin`. Supported V1 networks are
|
|
36
42
|
`eip155:8453`, `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp`, and
|
|
@@ -42,7 +48,7 @@ operator-supervised `--password-stdin`. Supported V1 networks are
|
|
|
42
48
|
x402api wallet notify-refill \
|
|
43
49
|
--wallet NAME \
|
|
44
50
|
--subscription-reference ID \
|
|
45
|
-
--renew-by
|
|
51
|
+
--renew-by RFC3339_UTC_DEADLINE \
|
|
46
52
|
--target-balance-atomic N \
|
|
47
53
|
--reason renewal \
|
|
48
54
|
--json
|
|
@@ -54,6 +60,10 @@ asset balance in atomic units, not the native fee balance. Results have status
|
|
|
54
60
|
email recipient and derives tenant and product display data from the
|
|
55
61
|
subscription; those values are intentionally not CLI arguments.
|
|
56
62
|
|
|
63
|
+
The client command is shipped, but this repository does not provide the hosted
|
|
64
|
+
notification endpoint. Configure `X402API_NOTIFICATION_URL` only for an
|
|
65
|
+
approved deployment of the server contract.
|
|
66
|
+
|
|
57
67
|
## Payment commands
|
|
58
68
|
|
|
59
69
|
```text
|
|
@@ -79,17 +89,27 @@ when a merchant-specific integration owns the request lifecycle.
|
|
|
79
89
|
- `password_required`, `wallet_locked`: request operator unlock assistance;
|
|
80
90
|
never request secret material in chat.
|
|
81
91
|
- `wallet_storage_unsafe`, `payment_artifact_corrupt`: stop and escalate.
|
|
92
|
+
- `payment_limit_exceeded`: the exact payment exceeds the wallet's local
|
|
93
|
+
per-payment ceiling; do not split or reauthorize it to evade the limit.
|
|
82
94
|
- `insufficient_asset_balance`: show exact funding instructions or request a
|
|
83
95
|
registered refill notification.
|
|
84
96
|
- `insufficient_network_fee_resources`: is not expected for a valid launch
|
|
85
97
|
profile; stop because the merchant challenge was not safely sponsored.
|
|
86
|
-
- `
|
|
87
|
-
`
|
|
88
|
-
|
|
98
|
+
- `gas_sponsorship_unavailable`, `gas_treasury_below_floor`,
|
|
99
|
+
`sponsor_signature_unavailable`: retain the exact attempt and retry only with
|
|
100
|
+
bounded backoff; never switch to buyer-funded gas.
|
|
101
|
+
- `sponsorship_allowance_unavailable`, `sponsorship_payment_cap_exceeded`,
|
|
102
|
+
`sponsorship_payment_allowance_exhausted`,
|
|
103
|
+
`sponsorship_volume_allowance_exhausted`,
|
|
104
|
+
`sponsorship_gas_budget_exhausted`: the current authorization is terminal.
|
|
105
|
+
The merchant tenant must top up or change its allowance configuration and
|
|
106
|
+
issue a fresh challenge; the buyer must not fund native gas.
|
|
107
|
+
- `tenant_gas_credit_insufficient`: legacy-server response; retain the exact
|
|
108
|
+
attempt and retry only after the merchant tenant restores service credit.
|
|
109
|
+
- `sponsorship_reservation_expired`: obtain a fresh challenge without reusing
|
|
110
|
+
the expired authorization.
|
|
89
111
|
- `sponsored_payload_invalid`: stop; the challenge or signed payload is not
|
|
90
112
|
safely sponsored.
|
|
91
|
-
- `sponsor_signature_unavailable`: retain the exact attempt and retry with
|
|
92
|
-
bounded backoff.
|
|
93
113
|
- `settlement_outcome_unknown`: keep the exact attempt and request envelope;
|
|
94
114
|
retry or reconcile them without creating a new authorization.
|
|
95
115
|
- `unsupported_network`, `unsupported_asset`, `unsupported_profile`,
|
|
@@ -25,7 +25,12 @@ The merchant tool writes an owner-only JSON file:
|
|
|
25
25
|
The body is exact canonical base64 and is never parsed and reserialized before
|
|
26
26
|
paid submission. The decoded `resource.url` must equal the normalized envelope
|
|
27
27
|
URL. The envelope excludes authorization headers, cookies, API keys, SSH keys,
|
|
28
|
-
and
|
|
28
|
+
owner tokens, and merchant-side challenge handles. A response header such as
|
|
29
|
+
`X-X402API-Challenge-Handle` is opaque reconciliation metadata for the merchant
|
|
30
|
+
integration. It is not the buyer payment identifier, does not affect the token
|
|
31
|
+
authorization, and must not be added to this exact V1 envelope. The wallet
|
|
32
|
+
creates its own `buyerPaymentIdentifier` when it authorizes a selected payment
|
|
33
|
+
requirement.
|
|
29
34
|
|
|
30
35
|
## Payment submission or artifact handoff
|
|
31
36
|
|
|
@@ -47,8 +52,11 @@ never downgraded by a later transport or replay failure.
|
|
|
47
52
|
|
|
48
53
|
## Hosted refill endpoint
|
|
49
54
|
|
|
50
|
-
The CLI posts a signed envelope to
|
|
51
|
-
|
|
55
|
+
The shipped CLI client posts a signed envelope to
|
|
56
|
+
`X402API_NOTIFICATION_URL`. This repository does not implement or deploy that
|
|
57
|
+
hosted endpoint. An approved server implementing the separate contract must be
|
|
58
|
+
available before a notification workflow is advertised. The signed intent
|
|
59
|
+
includes:
|
|
52
60
|
|
|
53
61
|
- a domain-separated V1 kind and exact endpoint audience;
|
|
54
62
|
- the subscription reference;
|
|
@@ -7,6 +7,11 @@ balance is the economic permission granted to the agent and may be spent at
|
|
|
7
7
|
different compatible x402 merchants. Preserve separate keys and addresses for
|
|
8
8
|
Base, Solana, and TRON.
|
|
9
9
|
|
|
10
|
+
An optional `maximumPaymentAtomic` value adds a local ceiling to each payment.
|
|
11
|
+
It does not limit aggregate or daily spend, restrict merchants, revoke existing
|
|
12
|
+
artifacts, or protect a wallet on a compromised same-user host. Version 0.2.3
|
|
13
|
+
sets this value only when creating a wallet and has no policy-update command.
|
|
14
|
+
|
|
10
15
|
Show the exact network, token contract or mint, public address, and requested
|
|
11
16
|
asset amount before funding. A correct address on the wrong network is not
|
|
12
17
|
valid funding. Buyers do not fund ETH or SOL for launch-sponsored payments.
|