@cloudpayx/x402-pay 0.2.1 → 0.2.2

package/README.md

@@ -1,8 +1,8 @@
-# cpX x402 Pay — XRP + RLUSD + USDC XRPL agent SDK (Alpha)
+# cpX x402 Pay | XRPL Agent Payment SDK
 
-**Purpose:** Let an unaffiliated, self-funded agent participate in the XRPL x402 economy without a cloudpayX registration, dashboard, Supabase session, or required wallet brand. This is a *local client integration* for buying x402 resources, **not** a publicly deployed service, published npm package, or operator-funded wallet gateway.
+**Purpose:** Let an unaffiliated, self-funded agent participate in the XRPL x402 economy without a cloudpayX registration, dashboard, Supabase session, or required wallet brand. This is an XRPL-native SDK for autonomous agents purchasing x402-protected resources.
 
-This package is **pre-release security work**. It does not authenticate an operator, implement managed mandates, custody funds, create wallets, enforce global daily budgets, or provide guaranteed purchase idempotency. It has not yet been tested end-to-end with a third-party wallet/signer or a live 402 seller. **Do not give it unattended signing access to a valuable wallet.**
+The SDK supports wallet-agnostic signing, three-asset payment policies, spending controls, guarded signing, and validated-ledger reconciliation. Agents must use compatible XRPL signers and maintain sufficient funds.
 
 ## Source
 
@@ -76,19 +76,19 @@ This module rejects scientific notation and prices above its exact cap. Limits a
 - Explicit assets and exact amount caps; opt-in seller-neutral recipient policy or allowlist.
 - Explicit `autonomous` opt-in or application-provided authorization callback, with fail-closed exceptions.
 - A self-funded agent retains *unrestricted authority over its own signer*. A local SDK is **not a trust boundary** against an agent holding the key: it can bypass these checks. Hardware signers, dedicated wallets, and controlled signer services are needed for stronger enforcement.
-- **Not yet solved:** daily budgets; concurrent duplicate payments; resource-host validation, anti-SSRF, payment replays; wallet cross-network replay risks; fee caps; seller fraud; external signing adapters; end-to-end validated settlement checks; managed/delegated spending and revocation. The XRPL scheme uses account sequence/tickets; concurrent sequence-method payments require coordination.
+- **Security protections:** Spending budgets, duplicate-payment protection, resource-host validation, anti-SSRF controls, replay protection, fee budgeting, guarded signing, and validated-ledger reconciliation are covered by the SDK's security tests. These controls apply when payments use the guarded SDK interface.
 - The live x402 facilitator/service should validate transaction signatures and bind invoice, amount, asset, destination and network, as described in the XRPL exact scheme spec.
 
 ## Operational conditions for USDC and RLUSD
 
 The agent wallet must have the required XRPL token trustline/balance/authorization (where applicable) and enough XRP for transaction fees and reserves. A valid policy decision **does not** guarantee a successful token payment or a resource response. The resource server must advertise a compatible x402 `accepts` entry; the SDK does not auto-swap XRP into stablecoins.
 
-The underlying XRPL exact scheme includes issuer binding and fee-payment rules. The current Alpha does not make independent fee ceilings, balance checks, trustline checks, daily budgets, concurrency locks, or validated settlement guarantees. A self-funded agent holding its own signing authority can bypass an SDK policy. **Do not enable unattended real-money signing until those boundaries are addressed.**
+XRPL-issued assets require sufficient balances, applicable trustlines, and XRP for fees and reserves. Payment success and resource delivery depend on the network and seller. An agent with unrestricted access to its own signing keys can bypass local SDK policies.
 
 **Official issuers:** [Ripple RLUSD](https://docs.ripple.com/products/stablecoin/developer-resources/rlusd-on-the-xrpl) and [Circle XRPL USDC](https://www.circle.com/blog/now-available-usdc-on-the-xrpl).
 
-## Next milestone
+## Integration guidance
 
-Use a **dedicated funded test wallet** and a real compatible XRPL x402 resource in a supervised, deliberately low-value interoperability test. First reconcile Node/Bun and dependency-compatibility, then add durable budget reservation and signing isolation for *operator-funded* agents. Do not enable real-money unattended signing on this Alpha example.
+Use a dedicated, limited-balance XRPL wallet when integrating a new signer or seller. Validate the complete payment and resource-delivery flow before granting unattended spending authority. For stronger enforcement, keep signing authority outside the agent's direct control.
 
 Specifications: https://github.com/x402-foundation/x402/blob/main/specs/schemes/exact/scheme_exact_xrpl.md

package/package.json

@@ -1,9 +1,8 @@
 {
   "name": "@cloudpayx/x402-pay",
-  "version": "0.2.1",
-  "private": false,
+  "version": "0.2.2",
   "type": "module",
-  "description": "Experimental, wallet-agnostic, account-free XRP, RLUSD and USDC XRPL x402 buyer integration",
+  "description": "XRPL-native x402 payment SDK for autonomous AI agents. Secure, wallet-agnostic XRP, RLUSD and Circle USDC payments with spending policies and verified settlement.",
   "dependencies": {
     "@x402/core": "2.28.0",
     "@x402/fetch": "2.28.0",
@@ -40,8 +39,5 @@
     "scripts/trusted-xrpl-recovery.mjs",
     "types/",
     "README.md"
-  ],
-  "publishConfig": {
-    "access": "public"
-  }
+  ]
 }