The XRP Ledger AI Starter Kit, v1.1: Open Standards, Not an Island

Ripple released version 1.1 of its XRPL AI Starter Kit, adding XRP Ledger support to the Open Wallet Standard (OWS) for local-first agent key management and making XRPL a supported settlement rail for the Machine Payments Protocol (MPP) co-authored by Tempo and Stripe. The update also introduces the xrpl-mpp-sdk for handling HTTP 402 challenge-response flows and xrpl-up, a one-command local sandbox node for testing agentic payment flows. Ripple said the XRP Ledger has processed 5.6 million X402 transactions since the kit's June launch.

TL;DR xrpl-up , for fast local testing, and a Skill for XRPL DEX trading. When we introduced the XRPL AI Starter Kit https://ripple.com/insights/xrpl-ai-starter-kit/ in June, the goal was narrow and deliberate: give developers the fastest path from zero to a confirmed agent payment on the XRP Ledger, starting with X402 support for XRP and RLUSD. The XRPL has seen 5.6M X402 https://xrpl-ai.org/ transactions since its inception. Since then, the agentic payments landscape has continued to evolve, and a few standards have emerged as genuine points of convergence rather than one-off frameworks. Wallet management is consolidating around shared, local-first interfaces instead of every tool reinventing its own keystore. And machine-to-machine settlement is consolidating around HTTP 402-based protocols that let any agent pay any service without an account or a checkout flow. XRPL AI Starter Kit v1.1 is about showing up in both of those places, not just the one we started with. OWS https://openwallet.sh/ is an open specification for local-first, multi-chain wallet storage and agent access to a single encrypted vault and a single interface CLI, MCP, SDK, or REST for every chain and every tool an agent might use. Instead of an agent's keys scattered across a dozen tool-specific config files and environment variables, OWS keeps them in a single vault at ~/.ows/ , decrypted only long enough to sign, then wiped from memory. With v1.1, XRPL is supported as a chain in OWS. A single ows wallet create command now derives an XRPL address alongside addresses for every other chain OWS supports, and agents can request XRPL signatures through the same policy-gated ows sign interface they'd use for any other chain with no XRPL-specific key handling required. We're also shipping docs https://xrpl.org/docs/agents/xrpl-agent-wallet-skill that walk through creating an OWS-backed XRPL wallet, wiring it to an agent, and sending a signed payment, all without the agent ever touching a raw private key. Why this matters: Agent frameworks don't want to write custom key management code for each chain. By supporting OWS, XRPL becomes accessible through the same wallet layer that developers are already adopting across other ecosystems. MPP https://stripe.com/blog/machine-payments-protocol , co-authored by Tempo and Stripe, is an open standard for HTTP-native agent payments: a service returns a 402 status with a price, the agent authorizes payment, and the resource is delivered. No accounts, no checkout flows. XRPL is now a supported settlement rail for MPP, live today for two payment modes: Stablecoin support for session payments is next. XRPL is adding IOU and MPT support to payment channels tracked as XLS-93d https://github.com/XRPLF/XRPL-Standards/discussions/287 , so RLUSD-denominated single payments and streaming sessions will follow the same lock-stream-settle mechanics as XRP today. For developers, the new xrpl-mpp-sdk https://github.com/ripple/xrpl-mpp-sdk handles the full 402 challenge-response flow, credential signing, and session management for both charge and channel modes, namely, XRP, IOUs, and MPTs are all supported today, with demos covering everything from a basic XRP charge to a Claude agent paying per-prompt over a payment channel. The npm package can be found here http://npmjs.com/package/xrpl-mpp-sdk , and the MPP documentation https://mpp.dev/payment-methods/xrpl also shows XRPL support. The npm package is in beta, so we welcome your feedback. Testing agentic payment flows against the public Testnet or Devnet means facing faucet rate limits, ~4-second consensus times, and a shared state you don't control. xrpl-up https://github.com/ripple/xrpl-up fixes that with a local sandbox: a one-command xrpld node with instant ledger closes, pre-funded accounts, and a full CLI surface for payments, trust lines, escrows, channels, AMM pools, MPTs, and more. It also ships a Claude Code plugin, so a developer can spin up a sandbox, create an AMM pool, or check a balance by describing what they want in plain language rather than having to remember flag syntax. xrpl-up isn't specific to agentic payments; it's a general local testing tool and the fastest way to iterate on any of the flows above OWS wallets, MPP charges and channels, X402 without touching a public network. This skill https://xrpl.org/docs/agents/getting-started-with-xrpl-trading enables autonomous permissionless DEX trading on the XRPL. The OWS and MPP additions are XRPL showing up within a standard someone else is driving, rather than asking developers to adopt something XRPL-specific. OWS is a chain-agnostic wallet infrastructure with contributors spanning PayPal, Circle, the Solana Foundation, and others. XRPL is one of the chains it now speaks natively. MPP is a rail-agnostic settlement standard co-authored by Tempo and Stripe, and XRPL is one of the rails. X402, which we launched in June, works the same way. That pattern matters more than any single integration. The agentic payments ecosystem is still deciding which standards win, and XRPL's bet is to be a first-class citizen in the ones that do by bringing deterministic finality, predictable low fees, and native primitives like Payment Channels that map cleanly onto what these protocols actually need, rather than requiring a smart contract to bolt the behavior on. xrpl-mpp-sdk demos. Start with the basic XRP charge, then the payment-channel session demo to see the streaming pattern end-to-end. xrpl-up start , and point your scripts at ws://localhost:6006 instead of a public faucet. As with V1, this is a milestone in the journey, and not the finish line. Tell us what you're building, what's working, and what standard we should be looking at next.