DEV Community: Ajit Kulkarni

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

Ajit Kulkarni — Tue, 15 Sep 2026 19:12:13 +0000

TL;DR

In mid-June, we launched the XRPL AI Starter Kit to help developers build agentic payment applications on the XRP Ledger.
Today we're shipping v1.1, adding support for two emerging cross-chain agent standards: the Open Wallet Standard (OWS) and Tempo and Stripe's Machine Payments Protocol (MPP), a new CLI, xrpl-up, for fast local testing, and a Skill for XRPL DEX trading.
The throughline: XRPL isn't building agentic payments in isolation. It's showing up in the standards the rest of the agent ecosystem is converging on, and giving developers reference implementations for each.

When we introduced the 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 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.

What's New in v1.1

1. XRPL support for the Open Wallet Standard (OWS)

OWS 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 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.

2. XRPL support for Tempo's Machine Payments Protocol (MPP)

MPP, 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:

Single (charge) payments in XRP, IOU, and MPT. An agent hits a 402 challenge, the XRPL payment settles in 3–5 seconds with sub-cent fees, and the resource is delivered. Deterministic finality means the transaction either confirms or it doesn't, with no ambiguous pending state for the agent to poll or retry.
Session payments via XRPL Payment Channels for XRP. This is MPP's most powerful primitive: instead of settling every API call individually, an agent opens a payment channel once, streams cumulative signed vouchers off-chain as it consumes a service, and the provider settles the total in a single on-chain transaction at the end. XRPL Payment Channels were built for exactly this pattern, where vouchers can be signed at rates exceeding 100,000 per second, verified locally by the provider with no blockchain call required, and the whole session costs just two on-chain transactions: open and close.

Stablecoin support for session payments is next. XRPL is adding IOU and MPT support to payment channels (tracked as XLS-93d), 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 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, and the MPP documentation also shows XRPL support. The npm package is in beta, so we welcome your feedback.

3. `xrpl-up`: a local CLI for fast developer iteration

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 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.

4. An XRPL DEX trading Skill

This skill enables autonomous permissionless DEX trading on the XRPL.

Why This Matters: XRPL Is Not on an Island

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.

Start Building

Wallets: Follow the new OWS tutorial to create an XRPL-backed wallet and wire it into an agent.
Payments: Try the xrpl-mpp-sdk demos. Start with the basic XRP charge, then the payment-channel session demo to see the streaming pattern end-to-end.
Local testing: Install xrpl-up, run xrpl-up start, and point your scripts at ws://localhost:6006 instead of a public faucet.
Still on X402? Nothing here changes it, and X402 support for XRP and RLUSD from the original launch is unaffected.

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.

Strengthening XRPL EVM Sidechain: Key Takeaways from Informal Systems Security Audit

Ajit Kulkarni — Thu, 03 Apr 2025 22:43:46 +0000

The XRPL EVM Sidechain—bringing smart contract capabilities to the XRP Ledger ecosystem—recently underwent a rigorous security audit conducted by Informal Systems, a team of world-class researchers, engineers and operators who specialize in security audits for blockchain products.. The audit, carried out in February of 2025, assessed the correctness, security, and reliability of the XRPL EVM Sidechain implementation, including both the core node diff and its customized Cosmos EVM fork.

As programmability expands across the XRP Ledger ecosystem, ensuring a secure foundation is paramount. The XRPL EVM Sidechain is built with Cosmos SDK and its consensus layer is enabled by CometBFT. It has full EVM compatibility, including all Ethereum libraries, smart contracts and EVM development tools like Open Zeppelin and Hardhat, and it supports institutional use cases and cross-chain flow of digital assets. This audit helps validate the robustness of the sidechain’s architecture as it scales for real-world financial applications.

The diagram above illustrates the architecture of Cosmos SDK using Evmos/Cosmos EVM as the EVM execution layer and CometBFT as the consensus layer.

Exploring Audit Findings
The audit identified only one critical issue overall, which was tied to the use case of the crisis module for invariant enforcement. Other issues were rated low or informational and are largely related to architectural clarity and best practices. All of these findings have since been resolved by the Peersyst and RippleX engineering teams, with Informal Systems designating them as such. Let’s dive into a breakdown of the aforementioned findings:

Reference material for the report

Critical Finding: Crisis module Ineffectiveness
The audit identified that the crisis module does not reliably halt the chain upon detecting invariant violations, which could allow unnoticed security issues. This behaviour is consistent with a broader Cosmos SDK advisory.

RippleX and building partner Peersyst are actively considering alternative approaches for checking invariants, and have since added a relevant fix which has been acknowledged by Informal Systems.

PoA with Guardrails: A Secure Validator Set
The audit outlines that the XRPL EVM Sidechain’s Proof-of-Authority (PoA) consensus is enforced with strong and stable safeguards that include the fact that validators can only be added or removed via a transparent governance process. A key aim in building the XRPL EVM Sidechain was the preservation of the XRP Ledger’s focus on security and trust, where consensus participants define their own Unique Node List (UNL) and as a consequence the XRPL network minimizes the risk of a single point of failure or centralized control.

The PoA Consensus is built on CometBFT’s PoS: The XRPL EVM sidechain adapts CometBFT’s PoS consensus by introducing specific restrictions to enforce PoA:

Validators are added and removed exclusively through the governance process.
A special BondDenom token is used solely for staking:
-- When a validator is created, a predefined amount is minted as stake.
-- When a validator is removed, the staked amount is burned.
The system does not contain any unstaked (free) BondDenom tokens.
Re-delegations and un-delegations are not permitted.
Each validator has only a single self-delegation (created at the moment of adding the validator, when the staking amount is minted).
Slashing penalties do not apply, meaning staking amounts remain unchanged.
No BondDenom token rewards are distributed (no inflationary rewards), and since there are no delegations, rewards distribution and commission rate settings are irrelevant.

These parameters reinforce predictable validator behaviour and reduce governance and consensus risk, which is of course critical for institutional-grade applications.

Strengthened Token Management via Cosmos EVM Fork
The Evmos fork introduced enhancements to ERC-20 token precompiles, allowing minting, burning, and ownership transfer. The audit confirmed that only authorized token owners can mint or burn assets. Ownership is gated through governance or EVM precompiles with strict checks, and no unauthorized token actions are possible through the Cosmos SDK or EVM paths.

The audit also suggested separating ownership revocation from transfer logic to avoid unintentional contract lockouts- an improvement the team has acknowledged and will consider for future releases.

Low-Risk and Informational Observations Roundup
Most other findings related to other informational aspects that did not pose immediate risks but offer opportunities for streamlining and ensuring further clarity in future development cycles.

Minimum and maximum validator number validation
Unnecessary token burning on validator removal
Cosmos SDK v0.50 upgrade housekeeping
Separate revoke ownership from transfer ownership
Messages MsgDelegate and MsgCancelUnbondingDelegation should be disabled
Refactoring suggestions (For example, separating logic in mint.go)

Building on the Audit
The RippleX engineering team and Peersyst have since addressed all relevant recommendations, as outlined in the final report, and will continue to strengthen the XRPL EVM Sidechain ahead of production-grade adoption. This audit reaffirms the XRPL EVM Sidechain’s willingness and readiness to support enterprise-grade tokenization, smart contract deployment, and real-world asset applications.

To learn more you can explore the official XRPL EVM Sidechain website and reach out to the Peersyst team and broader RippleX team via X to stay up to date on future developments, open source contributions, and production rollout plans. You can also reach out to the masterminds at Peersyst who have been instrumental in the development of the XRPL EVM Sidechain.

Results from the Bishop Fox Security Audit and Remediation of the Cross-Chain Bridge and EVM Sidechain

Ajit Kulkarni — Thu, 16 Nov 2023 19:46:42 +0000

As new and exciting developments are made on the XRP Ledger, comprehensive security audits remain an important part of ensuring innovations remain rigorous and secure.

On July 24, the cyber security firm Bishop Fox completed an extensive security audit of the EVM sidechain. The team specifically assessed the EVM sidechain implementation, its consensus mechanism and the bridging implementation between the XRPL and the EVM that uses the cross-chain bridging (XLS-38d) specification for the XRPL.

On October 6, Bishop Fox delivered remediation reports for both the EVM Sidechain and the XLS-38 Cross-Chain Bridge. All of the reports are listed below, followed by a summary of the findings.

Reference material for the reports:

Audit Findings, EVM Sidechain

The auditor determined that “RPC networking interfaces were well-protected against injection-based attacks and identified no core issues with the bridging functionality.”

Overall, the audit didn’t find any critical or high severity issues. There were 11 total findings - 3 of “medium” risk, and 8 of “low” risk. The audit found minor issues related to the use of outdated dependencies and the use of some unsafe command and code execution patterns. Bishop Fox recommended that the developer team firstly update software dependencies, and secondly remove unsafe execution patterns.

The PeerSyst team has since addressed these issues in the latest implementation and these fixes will be part of the Mainnet launch of the EVM sidechain.

The latest remediation report underlines the relevant progress that has been made. Partial and complete remediations, as can be viewed in the document, have in turn ensured that relevant risk levels have been downgraded for highlighted vulnerabilities.

Notably, Bishop Fox added in the initial report that “despite attempting multiple potential attack paths against the EVM bridge, the team did not identify mechanisms for a remote attacker to violate the operational integrity of the EVM bridge applications or forge bridging transactions.” While the initial report findings were reassuring, the PeerSyst team’s remediation efforts have ensured the implementation is even more robust.

Audit Findings, XLS-38 Cross-Chain Bridge
The RippleX engineering team also fixed the issues brought out by the Bishop Fox team during their audit of the XLS-38 Cross-Chain Bridge changes in rippled code. The Bishop Fox team conducted remediation testing and has published a remediation report verifying these fixes.

About the EVM Sidechain

The EVM sidechain is being developed by Peersyst in partnership with Ripple and is effectively optimized for DeFi. Users have already enjoyed the sidechain which has been available on a new version of Devnet (v2), as of June 2023.

As a result of the development, builders will have the opportunity to be one of the first to market their DeFi app on a new chain that is home to a user base of over 4.5M XRP wallet holders. Builders will be able to utilize familiar smart contract languages to build and deploy cross-chain dApps seamlessly. EVM sidechain is built with CometBFT to enable 3.5 second block times and low gas fees that are paid for in XRP. You are also able to utilize the secure bridge, based on the XLS-38 cross-chain bridging specification, to transfer funds seamlessly between XRPL Mainnet and the EVM sidechain, ensuring easy navigation.

Connect to the EVM sidechain Devnet here:

Name: EVM Sidechain
RPC URL: https://rpc-evm-sidechain.xrpl.org
Network identifier: 1440002
Digital Asset: XRP
EVM Block Explorer URL: https://evm-sidechain.xrpl.org
Bridge URL: https://bridge.devnet.xrpl.org