Authors: Mayukha Vadari, David Fuelling, Ajit Kulkarni, Elliot Lee, Peng Wang, Oleksandr Pidskopnyi

As announced in September, Ripple, in collaboration with the community, is committed to bringing permissionless programmability to the XRP Ledger (XRPL).

The first step of this initiative was for the authors to conduct a survey of VM options to build a native programmability system, by sourcing input from the broader XRPL community along with other blockchain ecosystems.

We envision programmability on the XRPL as the glue that seamlessly connects its powerful, native building blocks with the flexibility of custom on-chain business logic. This vision focuses on preserving what makes the XRPL special—its efficiency, reliability, and simplicity—while empowering builders to unlock new possibilities.

The Road So Far

While the XRP Ledger’s amendment process allows for careful, collectively-driven updates and provides a secure approach to introducing widely applicable features, this leaves a gap for developers who need to address the bespoke needs of their business but don’t want to (or can’t) drive broad community adoption for a niche use case. The smart contract functionality proposed in this post will offer additional flexibility for these developers by enabling permissionless development in a way that complements the functionality of amendments.

As a recap, the team’s main considerations for Mainnet programmability are:

• Permissionless by design (i.e. no need for UNL approval for the network to execute user code)
• Meshes well with XRPL in both design and implementation
• Easy access to native features/primitives, to build on the XRPL’s powerful building blocks
• Easy for new developers to learn (e.g. familiar design paradigms)
• Minimal impact on existing XRPL users and use cases, especially regarding payments, performance, and security
• Minimal impact to node/validator costs

This initiative’s anti-objectives are:

• Being exactly the same as some existing design (at the expense of what is best for the XRPL)
• Replacing XRPL’s existing building blocks with smart contracts (its primitives are a key selling point)
• A modification to the consensus protocol that would pay validators (out of scope)

Over the past few months, we researched several VM options for XRPL programmability, published a blog post with our findings, and reached the conclusion that Web Assembly (WASM) is the best choice for the XRPL because it balances flexibility, performance, and integration ease better than the other options.

Community feedback has been instrumental in shaping this vision. Developers across a broad variety of projects have shared valuable insights that have helped refine this approach to XRPL programmability. This collaborative process continues as we all work together to create the best path forward.

Introducing Extensions: Making XRPL Features Smarter

As David Schwartz explained a few months ago, one of the core goals of our approach to programmability is to move carefully and take smaller steps towards programmability, rather than jump straight to it. The first step that we’ve come up with is what we’re calling Extensions.

What is an Extension?

An “extension” is a small piece of code attached to an XRPL building block, which allows users to add some custom logic to existing primitives. Extensions can be very useful for projects that like the existing features of the XRPL, but need a minor modification to a feature to be able to use it.

Feature + Extension = Smart Feature

A feature with an extension attached will be more efficient, already mostly audited, and easier to use than reinventing the wheel with a completely separate smart contract.

Why Smart Features?

One of the XRPL’s biggest strengths lies in its foundational building blocks—primitives like tokens, escrows, and the DEX, which offer secure, robust, native functionality. Smart Features allow us to lean into these strengths by enhancing what already exists, rather than replacing it. By leveraging the existing toolkit of the XRPL, we can unlock powerful new capabilities while maintaining the simplicity and efficiency the network is known for.

This approach also eliminates the need to reinvent the wheel when looking to modify existing features. Instead, developers can build on top of a trusted (and audited) foundation, creating their own custom behavior and functionality that integrates seamlessly with the XRPL’s core design. It’s an approach that prioritizes compatibility, allows innovation to accelerate, and ensures that progress is made in harmony with the network’s proven architecture.

Smart Escrows: The First Extension

Currently, there are 2 methods of releasing an escrow: time-based (after a certain time has passed) and condition-based (essentially requiring a password for an escrow).

Smart escrows will allow developers to write their own custom escrow release conditions, building on top of the existing Escrow primitive without needing to rebuild it in a smart contract.

Some sample use cases:

• Notary escrow - only a certain account can unlock an escrow
• Credential-based escrow - an escrow can only be released if the recipient has received a certain credential or NFT
• Cascading escrows (for real estate) - one escrow can’t be unlocked unless the previous one has
• Trustless swaps - one escrow can’t be unlocked unless another one has been created
• “Options” - one escrow can’t be unlocked unless a Price Oracle shows the price of a token at a certain value

Read the full spec here.

Other Smart Feature Ideas

The idea of Smart Features could be applied to any of the building blocks that already exist on the XRPL - not just Escrows. Some possible options we came up with as examples:

• Smart AMMs could allow AMMs to have custom trading curves.
• Smart Accounts could incorporate XLS-86d, Firewall and/or XLS-76d, MinIncomingAmount, and potentially allow additional WASM code to protect accounts.
• Smart Tokens could allow issuers to perform additional regulatory checks on user transfers.
• Smart Batch transactions could allow users to implement custom AND/OR tree logic for their transactions.

In other words, any existing XRPL feature could be made smarter via this new paradigm, and new features could be “smart” from the beginning. The world is your oyster!

Smart Contracts

Smart Features and Smart Contracts aren’t mutually exclusive. We believe that the XRPL would be best served with both of these elements.

Having Smart Features means that if an XRPL feature gives you most of what you need, but is missing some small part, you don’t need to completely reinvent the wheel with a Smart Contract, and you still get the benefit of a well-tested, audited, efficient XRPL primitive. On the other hand, Smart Contracts provide more flexibility for features that are completely custom - for example, a new DeFi protocol.

Some sample use cases:

• Integration with a new bridging protocol
• A new DeFi protocol (e.g. derivatives or perpetuals)
• Issued token staking rewards

Our design for Smart Contracts combines the easy-to-learn overall design of EVM smart contracts (addresses + functions) with the familiarity of XRPL transactions. A Smart Contract lives on a pseudo-account and is triggered via a new ContractCall transaction, which calls a specific function on the smart contract, with provided parameters. The Smart Contract can modify its own state data, or interact with other XRPL building blocks (including other smart contracts) via submitting its own XRPL transactions from its code.

Read the full spec here.

How the XRPL EVM Sidechain Fits In

The XRPL EVM sidechain serves a complementary role to the XRPL, but is not a replacement for mainnet programmability.

We believe that the XRPL EVM Sidechain is a great opportunity to attract EVM ecosystem developers to the XRPL ecosystem. It can also be used to launch protocols that are not currently possible on the XRPL - especially ones that are already written in Solidity, or specifically require the EVM. This bridged solution, using a cross-chain approach, is useful if a project requires an alternative form of programmability.

Timeline

• Q1: Early devnet for smart escrows
• Q2: Full-functional Smart Escrow devnet
• Q3: Release Smart Escrows in an amendment for voting
• Q4: Smart Contract devnet

Starting with Smart Escrows (instead of going straight to Smart Contracts) allows us to test out the VM integration with a much smaller feature, so that it’s much easier to protect against unforeseen errors, and any issues will be much smaller and more limited.

If you’re interested in contributing to this development process, please reach out.