DEV Community: Mayukha Vadari

Smart Escrow Series #3: Security

Mayukha Vadari — Thu, 18 Dec 2025 18:28:25 +0000

The XRP Ledger (XRPL) is recognized for its stability, efficiency, and robustness. As the XRPL introduces custom on-chain business logic via Smart Escrows and the underlying WebAssembly (WASM) virtual machine, one paramount design objective is to maintain the network's integrity and security.

The implementation of Smart Escrows relies on a security-first design.

The Strict Sandbox: Preventing Unauthorized Access

The WASM code is executed in a secure, sandboxed environment. Advanced WASM features are disabled, to limit the surface area for bugs and exploits. The memory limits of the WASM module is also strictly limited.

The fundamental rule for the WASM code in Smart Escrows is read-only access, with only very specific write access allowed. WASM code has read-only access to all ledger objects and a variety of other on-chain data (such as ledger header information). It only has write access to the Data field in the Escrow that it is attached to. The only influence the WASM code has is updating the Data field and returning whether or not the escrow can be released. This strict limitation ensures that the custom logic cannot negatively affect the integrity of the ledger or the balances of other accounts.

Guarding the Network: Resource Limits and Gas

A major security concern with introducing programmable code is the potential for denial-of-service (DoS) attacks, where malicious code attempts to create infinite loops or consume excessive resources. To mitigate this, execution is strictly bounded.

Every step of WASM execution consumes "gas". When a user submits an EscrowFinish transaction, they must include a ComputationAllowance field, which dictates the maximum amount of gas they are willing to pay for the code execution. If the custom code exceeds the gas budget provided in the ComputationAllowance, the execution is immediately terminated with a deterministic failure. This prevents malicious or buggy code from running infinitely and ensures the execution remains fast and predictable.

Key resource constraints, such as the maximum WASM code size and the maximum computation allowed, are UNL-adjustable parameters controlled via the standard fee-voting process. This allows the network to dynamically adjust resource usage and pricing as network performance changes or if abuse attempts arise, without requiring a separate, full amendment. This also enables a fast shutdown mechanism, with the ability to shut down all usage of WASM code by setting the computation limit to 0.

User and Developer Protections

To mitigate the risk of funds becoming permanently locked (stuck) due to buggy custom code, any escrow containing a FinishFunction must also be cancellable. This mandatory feature ensures that if the custom conditions can never be met (due to a bug in the code or a flaw in the logic), the sender can still recover the funds after the specified CancelAfter time has passed.

Audits and Testing

The entire implementation is currently undergoing rigorous testing and multiple security audits to confirm that the WASM runtime is securely integrated into rippled and ensure that WASM code cannot violate the assumptions and invariants that have been established.

Wasmi, the chosen runtime, has also been audited twice previously for blockchain use cases. Those audit reports are available publicly here: https://github.com/wasmi-labs/wasmi/tree/main/resources

This security framework ensures that the flexibility of custom programming is introduced through small, measured steps, leveraging the stability of existing XRPL primitives while strictly containing the risks associated with user-deployed code.

Smart Escrow Post #2: What is WebAssembly?

Mayukha Vadari — Fri, 12 Dec 2025 22:04:51 +0000

As the XRPL moves toward permissionless programmability, starting with Smart Escrows, it needs a secure, reliable, and high-performance engine to run custom developer code. The conclusion we came to is that that engine should be WebAssembly, often abbreviated as WASM.

Earlier this year, the RippleX Programmability team surveyed various virtual machine (VM) options, and concluded that WASM was the best choice for the XRPL ecosystem for a few different reasons. Read more here: https://dev.to/ripplexdev/a-survey-of-vms-for-xrpl-programmability-eoa

WASM is not exclusive to the blockchain world. It’s a universal, open standard that was originally designed to run high-performance applications in web browsers (though now it is used in many other contexts as well). It is intended to support any language on any operating system, and in practice most languages have some level of support. https://webassembly.org/

WASM-based smart contract runtimes are deterministic, secure, and portable. The entire system relies on WebAssembly's core promise of deterministic execution, meaning the code will run identically on all rippled nodes, regardless of operating system or hardware, to ensure consensus is maintained. In addition, WASM promises better performance, and supports many general-purpose programming languages, like Rust, C, and Go (in other words, a Web2 developer may not have to learn a new language). With those benefits, WASM is the most popular smart contract language choice of many of the newer blockchain projects, such as Polkadot, Cosmos, Near, and most recently Soroban on Stellar.

Host Functions

To securely access ledger data and improve the efficiency of computation-intensive tasks, the WASM code relies on Host Functions. Think of a Host Function as an internal API call: it is expressed outside the WASM code (in the efficient C++ code that runs the XRPL) and allows the WASM program to securely query data from the ledger state. In EVM terms, this is roughly equivalent to precompiles.

The fundamental rule for the WASM code in Smart Escrows is read-only access, with only very specific write access allowed. WASM code has read-only access to all ledger objects and a variety of other on-chain data (such as ledger header information). It only has write access to the Data field in the Escrow that it is attached to. This strict limitation ensures that the custom logic cannot negatively affect the integrity of the ledger or the balances of other accounts.

WASM runtime environments are low-level virtual stack machines, like JVM, and can be embedded into any host application (such as rippled). There are several different implementations, with various tradeoffs. We chose Wasmi due to its performance and history of use in other blockchains (Polkadot and Solana also use Wasmi). https://dev.to/ripplexdev/xrpl-programmability-wasm-runtime-revisit-2ak0

In summary, WASM is the secure, high-performance virtual machine that executes the custom release logic for Smart Escrows. It allows developers to deploy complex, conditional rules using familiar programming languages, all while operating within carefully guarded boundaries that ensure the security and stability the XRPL is known for.

Smart Escrows Post #1: What are Smart Escrows?

Mayukha Vadari — Thu, 04 Dec 2025 17:35:56 +0000

I’m starting a series focusing on different aspects of Smart Escrows. Post #1: What are Smart Escrows?

The XRP Ledger is built on a foundation of powerful, native features like Tokens/Issued Assets, Escrow, the DEX, and Payment Channels, which are renowned for their security, efficiency, and robustness. While the XRPL’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 specific (sometimes niche) use case. To maintain these core strengths while allowing developers greater onchain flexibility, a new vision for permissionless programmability is emerging.

The first major component of this initiative is the concept of Smart Features. These allow developers some limited customizability, built on top of individual XRPL primitives. Essentially, developers are able to unlock powerful new capabilities while maintaining the simplicity and efficiency the network is known for. The Escrow is the very first primitive to receive this upgrade: enter Smart Escrows.

First: a refresher on the existing state of XRPL Escrows.

XRPL Escrows are essentially onchain contracts that govern the all-or-nothing transfer of funds from one account to another based on pre-agreed terms. Currently, they can only hold XRP, but the TokenEscrow amendment (currently up for voting) will enable holding both IOUs (issued assets) and MPTs (multi-purpose tokens).

Historically, there were only two ways to release funds held in an Escrow:

Time-based: The escrow can be released after a specific, predetermined time has passed.
Condition-based: The escrow requires a "password" to be provided during the release transaction (essentially a hash-lock).

A Custom Release Function for Escrows

Smart Escrows introduce a new layer of programmability to the existing Escrow primitive. Instead of being limited to just the time- and condition-based release options, developers can now write their own custom release conditions.

This enhancement allows conditions that go beyond the current time-based or crypto-conditional constraints, significantly expanding the XRPL’s utility. Because Smart Escrows build upon the existing, battle-tested Escrow primitive, developers gain custom functionality without having to reinvent the wheel, such as via a completely separate smart contract.

The custom logic is introduced via a small, programmable code block that lives directly on the Escrow object. When an Escrow is created using an EscrowCreate transaction, the developer uploads this code block (written in compiled WebAssembly or WASM - more on this to come) alongside the standard parameters and the funds to be locked.

When a user attempts to complete the escrow and release the funds using an EscrowFinish transaction, the FinishFunction is executed on-chain. The function runs, and that custom code determines whether or not the escrow’s funds are released to its destination.

By just adding this small bit of programmability, Smart Escrows allow a significant amount of new onchain functionality. Examples include:

Notary Escrows: The escrow is structured so that only a specific, trusted account (the "notary") can authorize the release of the asset.
Compliance and Temporary Holds: Funds are held until compliance checks or KYC verification is complete. The custom function could check if the destination account holds a specific on-chain credential or NFT issued by a compliance provider before allowing the transfer.
Trustless Token Swaps (Delivery vs. Payment): Developers can link two escrows so that the completion of one depends on the creation or completion of the other, ensuring a trustless, atomic exchange of value or assets.

If you want to read more about XLS-100, here’s a link to the spec: https://xls.xrpl.org/xls/XLS-0100-smart-escrows.html

XRPL Programmability: WASM Runtime Revisit

Mayukha Vadari — Mon, 01 Dec 2025 18:09:46 +0000

Authors: David Fuelling, Oleksandr Pidskopnyi, Mayukha Vadari, Peng Wang

One primary aspect of the WebAssembly (WASM) integration with rippled is the runtime used. WASM runtime environments are low-level virtual stack machines, like JVM, and can be embedded into any host application (such as rippled). There are several different implementations, with various tradeoffs. When we did an initial analysis of different runtimes earlier this year, we chose to use WAMR, primarily due to its performance benefits.

Upon finishing the initial development of the Smart Escrows implementation and reaching the review and testing stage, the RippleX programmability team decided to revisit the decision on the initial selection of WAMR as our WebAssembly VM runtime, to ensure the chosen runtime is well-positioned for success in our XRPL usage context. The team now had better context on VM internals and a better understanding of WebAssembly in general, which enabled a deeper analysis now compared to when the initial decision was made. Based on some initial meetings with members of the WebAssembly community, the team investigated two alternative runtimes (Wasmi and Wasmtime).

The team spoke to each of the three VM runtime teams directly, did some deeper analysis of the codebases and the ecosystems around each of the runtimes, and spoke to other trusted parties in the broader WebAssembly community.

Initial Investigation

The three runtimes investigated were:

WAMR (the VM currently integrated in the Smart Escrow implementation)
WasmTime (highly recommended by several researchers in the WASM ecosystem)
Wasmi (used by Stellar and Polkadot)

Security Postures

WAMR was created to service embedded-systems use-cases where the code running in the VM is “first party”, meaning that it is assumed to be trusted.
WASMTime was created to run untrusted code (such as in a browser).
Wasmi was also created to run untrusted code (on a blockchain). Wasmi was originally created by Parity Technologies, the team behind Polkadot, for the explicit purpose of running programmability on the Polkadot blockchain.

Code Complexity

WAMR: The code is quite simple and written in C, which the team has a lot of experience with.
WasmTime: Rather complex code and architecture. This makes it cumbersome to use and the increased complexity increases chances of potential bugs and security issues. To prevent resource exhaustion attacks, we explored loading/running wasmtime (at least the components before execution) in the VM itself - a complexity not needed for other runtimes.
Wasmi: A simpler architecture and easier to digest, which also makes it easier for the programmability team to build knowledge about VM internals.

History of Security/Bugs

WAMR: See section 2.2 of this research paper for some historical examples of bugs or security issues in WAMR that (according to the paper’s author) seem to be caused by a posture of assuming “first party” code on the part of the WAMR team. There have been a handful of major CVEs reported. The project has not had any audits done.
WasmTime: There are many security-minded researchers working on it (as evidenced by the number of small CVEs reported). The project has had audits done, but none of them are public.
Wasmi: There are 2 public blockchain-focused audits. The runtime is live in two blockchains (Polkadot and Stellar) and has not had major issues. There has only been one major CVE reported.

Language Implementation

Wasmtime and Wasmi are written in Rust, and support C APIs. WAMR is written in C.

Rust brings to bear memory safety and other compile-time checks that help improve the robustness of any project as compared to projects implemented in C or C++. While not a firm requirement of the VM we choose, the advantage of a Rust-based VM is that bugs or vulnerabilities can more easily be caught at compile time. A disadvantage of a Rust-based VM is that our engineering team has less experience with Rust, so digging into it or customizing a Rust project might be more difficult. Potentially the use of AI tools and reliance on the WASMTime dev team to implement new features could be a mitigant here.

High-Level Comparison

	WAMR	WasmTime	Wasmi
Code complexity	Simple	Complex - 10x the code of Wasmi, with a lot of advanced features we don’t need	Simple, easier to digest/understand
Prior blockchain usage	None	DFINITY’s Internet Computer, Polkadot	Polkadot, Stellar’s Soroban
Security	Intended for embedded use cases and first-party code, not third-party code	Security is first and foremost for the team	Security is very good
Audits	Has not been audited	Has been audited (not blockchain-focused), but the audits are not public	Multiple public audits, based on blockchain usage
Native Fuel support	Yes	Yes	Yes
Language	C	Rust	Rust

Performance Analysis

This report details the results of a comparative baseline performance test between four WebAssembly (WASM) virtual machines: WAMR, WasmTime (Pulley¹), Wasmi, and Wasmtime (Winch²).

The VMs were tested against a basic WASM module at load levels of 100 TPS and 300 TPS, with each test running for 30 minutes. Higher TPS thresholds were not tested for this initial set of tests, since 300 TPS was enough to differentiate the four VM configurations.

Note: these are just preliminary tests to differentiate the VM configurations, and should not be taken as an indication of final Smart Escrow/VM performance yet. These tests are also specific to integrating the runtimes into rippled, and are not reflective of the runtime performances in other contexts.

Bottom Line

Under the 300 TPS high-stress workload, Wasmi delivered the most balanced and consistent performance profile. It combined fast ledger validation times, high ledger-processing throughput, and stable operation with minimal overvalidations³ and no sync issues. WAMR performed well but had some minor stability issues, and WasmTime (both Pulley and Winch) were highly unstable and slow (possibly due to large amounts of time spent loading/parsing contract bytecode into intermediate representations).

Key Findings

At 100 TPS: All four VMs performed comparably and were stable, with no significant issues observed
At 300 TPS: Significant performance differences emerged.
- Stability: Wasmi and WAMR showed the highest stability. Wasmi had the lowest overvalidations (1) and zero P2P sync issues. WAMR also had zero sync issues, with slightly higher overvalidations (18).
- Instability: WasmTime (Pulley) and Wasmtime (Winch) were highly unstable, with large overvalidations (217 and 149) and significant P2P sync problems (32 and 53).
- Ledger Processing: Wasmi processed the most ledgers (480), making it the most efficient VM under load. WAMR was second (441). WasmTime and Winch processed substantially fewer (266 and 230).
- Validation Time: Wasmi had the fastest mean validation time (3.872s) at 300 TPS, ahead of WAMR (4.212s). WasmTime and Winch were significantly slower (6.983s and 8.082s).
- Transaction Throughput: Wasmtime (Winch) showed a high mean TPS (492.66), but this is misleading; its slow validation, low ledger count, and instability suggest irregular batching rather than sustained throughput. Wasmi (294.04 TPS) and WAMR (286.31 TPS) delivered more consistent and realistic throughput aligned with their ledger processing.

Key Metrics @ 300 TPS (Averaged):

Metric	WAMR (Avg)	WasmTime Pulley (Avg)	Wasmi (Avg)	Wasmtime Winch (Avg)
Mean Validation Time (s)	4.212	6.983	3.872	8.082
Mean TPS	286.31	325.3	294.04	492.66⁴
Ledger Count (30 min)	441	266	480	230
Overvalidations	18	217	1	149
P2P Out of Sync	0	32	0	53

Conclusion

Based on these results (best performance, excellent qualitative findings), the RX Programmability team decided to switch to Wasmi.

Next Steps

The RX Programmability team is almost done with migrating all the Smart Escrow code to use Wasmi instead of WAMR. This change will be included in the next Devnet release.

Pulley is Wasmtime's portable interpreter, it executes a custom, register-based bytecode format generated by the Cranelift compiler. ↩
Winch is wasmtime's Single-Pass Compiler. It does less optimization during compilation, so the compilation step takes less time than Cranelift, but execution times are longer. ↩
An overvalidation is when it takes a ledger over 5 seconds to validate. ↩
Do not be misled by Winch’s high “Mean TPS” (492.66). Combined with its long validation time and very low ledger count, this indicates inconsistent queuing and spiky batch processing, not smooth throughput. Wasmi’s throughput (294.04 TPS) was strong and consistent, aligning with its good validation time and highest ledger count. ↩

Permissioned Domains: Enabling Compliance-Driven Onchain Finance on the XRPL

Mayukha Vadari — Thu, 06 Mar 2025 18:23:33 +0000

The XRP Ledger (XRPL) is introducing new tools to enhance compliance, security, and institutional adoption. One of the most important developments in this space is Permissioned Domains (XLS-80), a proposed amendment that enables issuers and financial institutions to create controlled environments for blockchain-based transactions.

Permissioned Domains allow institutions to define access requirements for specific parts of the XRPL, ensuring that only authorized users — those with verifiable credentials — can participate in certain transactions. Permissioned Domains enable other features to become more compliant, representing a major step toward institutional-grade decentralized finance (DeFi) by ensuring privacy, regulatory compliance, and controlled asset flows.

What are Permissioned Domains?

Permissioned Domains introduce a new on-chain access control mechanism that allow institutions, businesses, and issuers to define rules for participation in specific financial activities.

More specifically, they enable the creation of controlled environments within a broader system where specific rules and restrictions can be applied to user interactions and asset flows. These rules are recorded directly on the XRPL, enabling domain creators to establish a trusted, transparent framework for their blockchain-based operations, helping traditional financial institutions meet the regulatory requirements they face.

For example, credential-gating ensures that via a Domain object, institutions can specify which credentials are required for access to their permissioned domain, ensuring compliance with relevant KYC/AML regulations. Permissioned Domains allow for institutional-grade compliance and risk management without relying on external intermediaries or encroaching on privacy. The ledger itself only tracks whether the user’s credential is valid and accepted by the domain.

For a closer look at Credentials on the XRPL, a feature introduced through XLS-70 that allows for on-chain identity management and credential verification, you can check out my recent piece on DevTo.

A Key Enabler for the Upcoming Permissioned DEX

Permissioned Domains are not just an isolated feature — they serve as the foundation for another major institutional finance upgrade: the Permissioned DEX.

What is the Permissioned DEX?

The Permissioned DEX is effectively an evolution of the XRPL’s existing decentralized exchange (DEX) that allows only credentialed participants to trade within specific liquidity pools. While the XRPL’s native DEX has provided seamless on-chain trading for years, regulated financial institutions require greater control over who can participate in certain transactions.

How Permissioned Domains Enable the Permissioned DEX:

Restricted Orderbooks: Trading pairs on the Permissioned DEX can require users to hold approved credentials (facilitated by Permissioned Domains), ensuring that only authorized participants can place orders.
Regulatory Compliance: Institutions issuing tokenized real-world assets (RWAs) or stablecoins can create private trading environments that comply with financial regulations.
Permissioned but Decentralized: Instead of splitting into separate private blockchains or special authorized tokens, the Permissioned DEX allows regulated institutions to reuse XRPL’s core DEX capabilities — just with added checks to ensure participants belong to the same, credential-gated domain.

With Permissioned Domains, the Permissioned DEX will allow financial institutions to engage in DeFi while meeting compliance requirements, opening the door to regulated secondary markets for tokenized assets.

Credentials: A Prerequisite for Permissioned Domains

As outlined in my earlier blog, Permissioned Domains build on top of Credentials and DID to facilitate a flexible, institutional-grade identity system on XRPL. Before users can access a Permissioned Domain, they must hold the required Credentials.

How Credentials Work with Permissioned Domains

Credential-Gated Membership: A domain object can list accepted credentials, such that any account holding any one of those credentials is automatically considered a member.
Streamlined Control: Organizations can define requirements (like KYC credentials from a trusted issuer) and manage who joins or transacts within a domain.
Privacy Preservation: Rather than upload personal information to the public blockchain or provide it to each platform, users only need to prove they hold a required credential. The network itself only tracks whether the user’s credential is valid and accepted by the domain.

By combining Credentials and Permissioned Domains, XRPL ensures on-chain privacy, security, and compliance, making institutional DeFi more accessible and scalable.

How to Vote for Permissioned Domains

To support the adoption of Permissioned Domains on the XRPL, you can participate in the amendment voting process!

Refer to the Amendments Guide for a step-by-step overview of how to vote.

New to the XRPL? The guide also explains how the amendment process works and how you can contribute to the network’s evolution.

A Proposed Vision for XRP Ledger Programmability

Mayukha Vadari — Tue, 25 Feb 2025 13:41:28 +0000

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.

Credentials: Building a Compliant Identity Layer for the XRP Ledger

Mayukha Vadari — Fri, 07 Feb 2025 22:33:52 +0000

Credentials is a new feature that provides a secure, lightweight framework for issuing, managing, and verifying user credentials directly on the XRP Ledger, enabling robust compliance while preserving user privacy.

Last year, the RippleX team introduced the XLS-70 spec for the XRPL, and it is currently undergoing the amendment voting process as part of the rippled 2.3.0 release. This article will cover how the feature is built, what it enables, and how it fits into a bigger picture of enabling compliant, institutional-grade DeFi on XRPL.

Robust Build

Credentials are designed to be a lightweight feature and are additive to the recent Decentralized Identity (DID) standard. The Credentials standard introduces a new Credential ledger object along with new transaction types for creating, accepting, and deleting credentials.

Credential ledger object
- Stores basic details about a credential such as issuer, subject, credential type, optional expiration, and URI.
- A flag (lsfAccepted) indicates whether the subject has accepted it. Before acceptance, the issuer maintains the reserve; after acceptance, the subject does.
- A credential is considered “valid” if it has been accepted by the subject and is not expired.
Extended Deposit Authorization flow
- Deposit Authorization is an optional feature that blocks direct incoming payments from unknown senders, requiring explicit preauthorization or self-initiated transactions to receive funds. Entities may comply with regulations that require knowledge and control over inbound transactions.
- DepositPreauth is an existing object type that allows an account requiring deposit authorization to explicitly preauthorize specific sending addresses to send direct payments. Essentially, it acts as a whitelisting capability for deposit authorization.
- With Credentials, DepositPreauth is extended to allow specifying credentials rather than only individual accounts, meaning an account may require incoming transactions to provide valid credentials (e.g. KYC status) issued by one or more trusted issuers.
- Internally, DepositPreauth objects can now hold an array of (Issuer, CredentialType) pairs in place of an account. A transaction must include the specified credentials to be authorized.
- Transactions that require showing credentials include a CredentialIDs field listing the valid credential object IDs. The ledger checks those objects to confirm validity, issuer, subject, and expiration before allowing the transaction.
New Transaction Types
- CredentialCreate: An issuer creates a credential ledger object on the XRPL, specifying the subject, credential type, optional expiration, and related data.
- CredentialAccept: The subject uses this transaction to “accept” the credential, flipping the lsfAccepted flag and transferring its reserve burden from the issuer to the subject.
- CredentialDelete: Either the issuer or the subject can delete a credential at any time. Anyone can delete it if the credential has expired.

Immediate Use Cases

Upon activation, developers may utilize the Credentials feature to streamline user onboarding processes. It will first work with Deposit Authorization, where senders can be automatically approved, instead of a manual process. Credentials can also be used to authorize off-ledger activities in association with a decentralized identifier.

Because the robust design of Credentials combines on-ledger credential objects, enhanced DepositPreauth checks, and specialized transaction types, it allows for issuing, accepting, revoking, and using credentials directly on XRPL without exposing personal data. Essentially, privacy is an embedded use case within the design of this feature.

Broader Implications

Credentials can be thought of as a modular building block to DID. It can be applied to attest to some criteria (e.g. KYC) for a user and issued to their DID. This may create an important foundation for enabling a smooth onboarding process when accessing products like tokenized RWAs.

Two additional features on the RippleX team’s roadmap, Permissioned Domains and a Permissioned DEX, may build on top of Credentials and DID to facilitate a flexible, institutional grade identity system on XRPL:

Permissioned Domains is a protocol that enables an entity such as a financial institution to create a controlled environment on XRPL that requires specified credentials for access. Here are a few ways this can work with the Credentials feature:
- Credential-Gated Membership: A domain object can list accepted credentials, such that any account holding any one of those credentials is automatically considered a member.
- Streamlined Control: Organizations can define requirements (like KYC credentials from a trusted issuer) and manage who joins or transacts within a domain.
- Privacy Preservation: Rather than upload personal information, users only prove they hold a required credential. The ledger itself only tracks whether the user’s credential is valid and accepted by the domain.
- Additionally, Permissioned Domains will enable a Permissioned DEX and could be used with the upcoming lending protocol.
Permissioned DEX is a protocol that extends the XRPL’s built-in decentralized exchange (DEX) to operate in a controlled environment, where creating or filling orders requires specified credentials.
- Restricted Orderbooks: An offer tagged with a domain ID can only be matched by other offers from accounts within the same domain who also hold valid credentials.
- Regulatory Compliance: Institutions can trade on the XRP Ledger’s DEX while enforcing AML/KYC rules. Only properly credentialed accounts in the same domain can interact with one another on that orderbook.
- Controlled but Still Decentralized: Instead of splitting into separate private blockchains or specialized tokens, the Permissioned DEX reuses XRPL’s core DEX capabilities—just with added checks to ensure participants belong to the same, credential-gated domain.

Taken together, DIDs serve as a foundational “fingerprint” for each user, while Credentials provide the identity and compliance layer required for different scenarios. Building on these foundations, Permissioned Domains and Permissioned DEX protocols enforce membership and compliance rules by requiring the appropriate DID-based Credentials, all while preserving the decentralized nature of the XRPL.

How to Vote for the Credentials Amendment

To support the adoption of Credentials on the XRPL, you can participate in the amendment voting process!

Refer to the Amendments Guide for a step-by-step overview of how to vote.

New to XRPL? This guide also explains how the amendment process works and how you can contribute to the network’s evolution.

For more information and updates, visit the XRPL Credentials Overview.

A Survey of VMs for XRPL Programmability

Mayukha Vadari — Mon, 27 Jan 2025 20:37:01 +0000

There is a growing demand for permissionless programmability on the XRP Ledger. This kind of programmability will give developers the flexibility to securely implement complex scenarios in on-chain, user-deployed code, without needing permission from anyone (such as a UNL quorum).

To this end, the Programmability team at RippleX has been hard at work over the last few months researching different smart contract systems that exist in the broader crypto ecosystem. This blog post outlines our preliminary findings and also details what we believe to be the best VM solution for the future of XRPL programmability.

Overview

We started by researching possible solutions to the programmability question, to determine what was even remotely worth considering, and which designs seemed to match our goals at a first look. We called this “Phase 1”.

We then narrowed down the list of VMs to the most promising three options, and created some simple proofs-of-concept integrating those into rippled (the software that the XRPL runs on), to determine what was most feasible from a more technical perspective (“Phase 2”).

This post will provide an update on both Phases 1 and 2.

Note: this blog post only addresses the applicability of different VMs to XRPL programmability, and does not handle other design considerations, such as gas and storage mechanisms. We'll share our thoughts on those topics in a follow-up post.

Overall Design Objectives

The main goals we have for programmability on the XRPL are:

Permissionless by design (i.e. no need for UNL approval for the network to execute user code)
Meshes well with the XRPL, both design- and implementation-wise
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 to existing XRPL users/use-cases, especially with regard to payments, performance, and security
Minimal impact to node/validator costs

Phase 1: Discovery Research

As part of our discovery process, we considered the following technologies (including possibly modifying them to meet the needs of the XRPL). We also spoke extensively with developers from many of these communities to gather their input.

Hooks
Stellar (Soroban)
EVM
Solana
Aptos/Sui (Move)
TON
NEAR
BitVM
RISC-V
L2s/Sidechains

Phase 1 Evaluation Criteria

In this first phase, we only considered a subset of the design objectives listed above (namely, those that were easier to investigate without needing to build a proof-of-concept):

Permissionless
Meshes well with the XRPL, design-wise (especially its account-based model)
Easy integration with native features
Easy learning for new developers
1. Use familiar development models
2. Ecosystem adoption (looking at the broader crypto ecosystem) - as a partial proxy for ease of learning

1. Hooks

Hooks are small pieces of code that are installed on an account. They are triggered by incoming and outgoing transactions and can:

Block an incoming or outgoing transaction
Modify an outgoing transaction
Create and send a new, additional transaction

Why This Was Investigated

Hooks was originally designed for the XRPL, and already exists in one form on Xahau, where it has been in production for more than a year.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Via transaction emission.
Ease of Learning		Yes, with some modifications, such as JSHooks.
Design Meshes Well with XRPL
Ease of rippled Integration
Ecosystem Adoption		Xahau is the only chain that supports Hooks, and it is still very new.

We decided to move Hooks onto the next step. Since Hooks was designed for the XRPL, it easily passed many of the criteria that we were evaluating at this step. The main two sticking points were ease of learning for new developers (due to needing to know the C programming language) and low ecosystem adoption, but these factors were not enough of a concern to stop it from moving onto the next stage of evaluation.

2. Stellar (Soroban)

Soroban is the smart contracts platform on the Stellar network. Soroban Contracts are small programs written in the Rust programming language and compiled as WebAssembly (WASM) for deployment.

Why This Was Investigated

Stellar and the XRPL are very similar in their overall architecture - for example, both are account-based and use trustlines. As a result, it may be easy enough to port Soroban to the XRPL.

Notes

There does not appear to be a way to interact with Stellar-native features from a Soroban smart contract. For example, in order to get assets to work with a smart contract, you need a Stellar Asset Contract (SAC) that pairs with it and stores the smart contract asset balances. These are deployed like normal smart contracts. In addition, there is no way to access ledger object data unless it’s the data stored in the contract (with the exception of the SAC, which can access trustline balances), and no way to integrate with a Stellar-native AMM without something off-chain or special wrapper logic.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding additional APIs (known as “host functions” in WASM).
Ease of Learning		Soroban contracts are somewhat difficult to read for someone who is new to the ecosystem.
Design Meshes Well with XRPL		Stellar and the XRPL are very similar in architecture.
Ease of rippled Integration		While Soroban was designed to be used by other blockchains as well, the 10 years of divergence between Stellar and the XRPL will likely still make integration somewhat difficult.
Ecosystem Adoption		Electric Capital’s Developer Report doesn’t show many Stellar developers.

We decided not to proceed with Soroban. Soroban fails our criteria in two key places: Ecosystem Adoption and Native Feature Access. The lack of native feature access essentially counteracts the benefits of Stellar’s similarities to the XRPL.

3. EVM

The Ethereum Virtual Machine is a smart contract VM used on many different chains, but started on the Ethereum network. Contracts are written in Solidity, which was developed specifically for the EVM.

Why This Was Investigated

The EVM is by far the most popular development stack in the crypto ecosystem.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding precompiles.
Ease of Learning		Solidity is the most popular smart contract language.
Design Meshes Well with XRPL		The EVM idea of unique contract addresses is roughly analogous to the XRPL’s pseudo-accounts.
Ease of rippled Integration		The VM is a standalone module, but was never designed to be integrated with something as different as the XRPL, so there will likely be difficulties.
Ecosystem Adoption		Electric Capital’s Developer Report shows it as by far the most popular development stack

We decided to move the EVM onto the next step. Given its popularity and ease of use, the EVM easily passes this round of evaluation. The biggest questions are about whether you would be able to access native features, and how well the code would integrate with rippled.

4. Solana

On Solana, contracts (which are called “programs”) are written in the Rust programming language. Solana’s on-chain programs are compiled via the LLVM compiler infrastructure to an Executable and Linkable Format (ELF) containing a variation of the Berkeley Packet Filter (BPF) bytecode.

Why This Was Investigated

Solana is the second most popular smart contract stack for crypto developers.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding native programs.
Ease of Learning		The tooling ecosystem is relatively mature, and Rust is a fairly popular programming language.
Design Meshes Well with XRPL		The contract data is stored in a separate account from the executable, which doesn’t mesh very well with the way the XRPL uses accounts (accounts store their own data, or data is stored in other ledger objects).
Ease of rippled Integration		The VM isn’t a standalone module, so it would have to be extracted from the Solana codebase before it could be added to rippled.
Ecosystem Adoption		Electric Capital’s Developer Report shows it as the second-most popular development stack.

We decided not to proceed with SolVM. This is mainly because they have a very different system of transactions, and making the conversion would likely be too difficult. In addition, the Solana VM is embedded into their server code, and would be difficult to extract.

5. Aptos/Sui (Move)

Move is a very high-performance, memory-safe, parallel-execution capable VM that currently powers smart contracts on the Aptos & Sui chains.

This evaluation focused on the Aptos version of Move.

Why This Was Investigated

Move smart contracts are gaining in popularity. In addition, its ability to handle parallel execution of transactions is intriguing and could potentially benefit the XRPL performance-wise in the future if the XRPL were to adopt it.

Aptos’s version of Move was chosen instead of Sui’s because Aptos has an account-based model (like the XRPL), which would likely be easier to port to the XRPL.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding host functions.
Ease of Learning		It has a very steep learning curve, but is nice to work with once that is overcome.
Design Meshes Well with XRPL		It is also an account-based system with a reserve-like method of storage rent. Interestingly, they have a unique method of contract data storage, where the user holds their data, instead of the contract account.
Ease of rippled Integration		The VM isn’t a standalone module, so it would have to be extracted from the Aptos codebase before it could be added to rippled.
Ecosystem Adoption		Electric Capital’s Developer Report shows that it has a solid developer base, but not near the top.

We decided to move Move onto the next step. The memory-safe and parallel execution nature of the Move VM make it very intriguing when thinking about how the XRPL can improve in the future.

6. TON

The TON blockchain has its own custom smart contract implementation, written in the FunC programming language and using the TON Virtual Machine (TVM).

Why This Was Investigated

The TON VM is intended to handle large numbers of smaller transactions, which may mesh with the XRPL’s method of processing via independent transactions, rather than larger smart contract functions.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding additional APIs.
Ease of Learning		FunC is difficult to learn, but they have a higher-level language, Tact, that’s easier to use.
Design Meshes Well with XRPL		It emphasizes small, modular contracts, but uses TON types all the way down.
Ease of rippled Integration		The TVM uses TON types all the way down - for example, integers are signed 257 bits in TON, so each XRPL integer would need to be converted to that format.
Ecosystem Adoption		Electric Capital’s Developer Report doesn’t show many TON developers.

We decided not to proceed with TON. This is mainly due to the fact that the TON VM uses TON types all the way down, and this would likely be difficult to work with.

7. NEAR

The NEAR blockchain/platform (launched in October 2020) supports smart contracts written in Rust and TypeScript which are compiled to WebAssembly (WASM) for deployment. NEAR uses proof-of-stake consensus.

Why This Was Investigated

NEAR is another blockchain that uses WASM, and is also account-based. It also has claims of a unique sharding mechanism (Nightshade) intended to support 1000+ TPS, which could be useful for the XRPL’s performance in the future.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding additional APIs (known as “host functions” in WASM).
Ease of Learning		Rust and TypeScript are fairly easy to learn, but the smart contracts use some unusual decorators.
Design Meshes Well with XRPL		NEAR also uses an account-based model for asset holdings.
Ease of rippled Integration		NEAR uses different data types.
Ecosystem Adoption		Electric Capital’s Developer Report shows that it has a solid developer base, but not near the top

We decided to move NEAR onto the next step, since we already had WASM on the list.

8. BitVM

BitVM is a conceptual framework that leverages Bitcoin’s limited scripting language to enable Turing-complete Bitcoin contracts without modifying the network's consensus rules. The main idea is to compile a program into a Boolean circuit and commit it in a Taproot address.

Why This Was Investigated

Neither Bitcoin nor the XRPL support Turing-complete smart contracts. As a result, BitVM is an interesting area of exploration because it offers the promise of programmability (with minimal changes to the XRPL), by using off-chain Turing-complete computation that can be verified by a much simpler computation layer on the main blockchain.

Notes

Representing a general-purpose computation on the XRPL is challenging. The XRPL does not have the capability to represent a computation as a NAND gate circuit, for example.
BitVM is stateless, and therefore uses the Lamport signature scheme to commit Boolean circuits for state transition. The XRPL does not currently support this.
Further fraud-proof and dispute-resolution mechanisms are required if a BitVM solution is selected.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some heavy modifications, as new machine instructions would need to be added and a fraud-proof mechanism would be required.
Ease of Learning		Developers have to do everything at the machine instruction level - there is no higher-level language.
Design Meshes Well with XRPL		It is designed for a UTXO blockchain, which the XRPL is not.
Ease of rippled Integration		BitVM has dependents that make integration difficult, such as the Lamport signature scheme.
Ecosystem Adoption		It is only used on Bitcoin, but Bitcoin is a very popular chain.

We decided not to proceed with BitVM, since our research showed that it didn’t mesh well from a design or implementation perspective.

9. RISC-V

RISC-V is an emerging CPU instruction-set architecture that can be used to execute blockchain computation.

Why This Was Investigated

RISC-V is register-based rather than stack-based as in WASM, which makes RISC-V more efficient.
RISC-V only contains ~40-50 instructions, while WASM has more than 200 instructions.
RISC-V is hardware-friendly and more suitable for resource-constrained devices.
RISC-V has built-in crypto support, which makes ZK proof generation and verification more efficient.

Evaluation Results

Requirement	Satisfies?	Notes
Permissionless
Native Feature Access		Yes, with some modifications, such as adding additional APIs.
Ease of Learning		It is still a very nascent VM.
Design Meshes Well with XRPL		Since RISC-V is its own independent VM, it should be easy enough to customize it.
Ease of rippled Integration		It would be a similar level of integration as WASM.
Ecosystem Adoption		It is still very nascent, and projects are only starting to use it.

We decided not to proceed with RISC-V, mainly due to its current maturity level. We plan to monitor RISC-V VM development in the blockchain ecosystem and will consider it as an alternative/additional solution for XRPL programmability in the future. For example, Nervos, Polkadot, and Ethereum are all in the process of developing RISC-V based projects.

10. Layer 2s and Sidechains

The two main examples considered here were rollups and sidechains.

Why This Was Investigated

L2 roll-ups provide parallel scalability and can be customized to fit a diverse set of application needs. Their safety comes from the mainnet (L1), and the safety of the mechanism connecting each roll-up to its L1 is guaranteed by each roll-up protocol.

Roll-Ups

L2 roll-ups provide parallel scalability and can be customized to fit a diverse set of application needs. Their safety comes from the Layer-1 (L1) mainnet, and the safety of the bridges between the roll-ups and their L1s is guaranteed by each roll-up protocol.

We investigated both Optimistic and ZK roll-ups.

Evaluation Results

There are several practical issues impeding the addition of roll-ups as a native primitive to the current XRPL:

The XRPL would need to add ~10 new transactors, for bridging between the mainnet and any roll-up, and additional native support beyond this would be required to verify ZK proofs.
XRPL does not have the appropriate logic and/or libraries to verify ZK proofs yet. Adding these would require significant testing and integration before being safely added to the XRPL.
- The zkVM libraries and several other projects we investigated are not yet production-ready. For example, they are in various stages of development (alpha, beta, or even still just a prototype).
Proving a ZK roll-up is very computationally expensive, so more research is needed to enable this to work in the confines of the current consensus model.

Note: Full permissionless programmability on the XRPL would make roll-ups a more practical solution because the infrastructure required to support them on-chain could be implemented in smart contracts, instead of transactors.

Other Networks (e.g. Sidechains)

We discounted the concept of XRPL sidechains (or other networks connected to XRPL via a bridge) as a solution because bridges are too inefficient for any effective native programmability solution. As an example, it is very difficult to interact with XRPL-native features from inside a smart contract on a different chain.

Despite our choice above, sidechains still very much have their place in the XRPL ecosystem. For example, the XRPL EVM Sidechain provides EVM support for those who need a completely EVM-based solution, which would never be possible on the XRPL, due to the XRPL having a very different implementation and structure from any EVM chain.

Phase 1 Conclusions

To summarize: we advanced WASM, MoveVM, and EVM to the next phase.

Phase 2: A Deeper Dive

Phase 2 focused on VMs rather than ecosystems or smart contract designs. This is because choosing a specific VM is independent from what the eventual smart contract design on the XRPL might look like.

For every VM studied in Phase 2, we attempted to integrate it into rippled and build a very simple proof-of-concept of what that might look like. The options that passed the initial Phase 1 round of review and made it to the final cut were:

WASM (e.g. Hooks, NEAR)
Move (Aptos-style)
EVM

The considerations in the deeper dive were:

Compatibility with the rippled codebase
Ease of embedding into the rippled codebase
Ability to read and write from XRPL ledger state
Performance impact

WebAssembly (WASM)

Similar to Solidity/EVM, WASM-based smart contract runtimes are deterministic, secure, and portable. In addition, WASM promises better performance, and supports many general-purpose programming languages (in other words, a Web2 developer may not have to learn a new language). With those benefits, WASM is the most popular smart contract language choice of many of the newer blockchain projects, such as Polkadot, Cosmos, Near, and most recently Soroban on Stellar.

We built a simple prototype with limited functionality. The prototype can store the smart contract Wasm code as part of a ledger object. The smart contract functions can be invoked by transactions. Once invoked, our POC processes the transaction and the ledger object, and stores data to a small storage attached to the smart contract.

Compared to Solidity/EVM, which was purposely built for smart contracts, WASM is general purpose and targets web2 developers. This provides more flexibility when integrating into a blockchain, but it also requires additional work to add or modify components, such as the storage interface and gas measurement mechanism. Fortunately, there are enough other blockchain projects that have already implemented WASM-based programmability solutions that we can look to for possible solutions on how to solve those problems.

Move

It took some time to learn Move and the associated tooling, but the experience of developing in Move was pleasant. However, we decided not to advocate for integrating it into the XRPL mainnet due to some practical concerns:

The standalone MoveVM is easily extracted into rippled, but the VM alone is not useful without additional library support. In the Aptos case, these extended Move libraries are not well isolated from the Aptos codebase itself, making it difficult to incorporate the overall VM into rippled.
To understand the effort in integrating Aptos’ MoveVM, we tried to build a prototype that simulates the interaction of rippled with the MoveVM. Unfortunately, the Aptos code base was not stable, likely due to the introduction of Move 2, which inhibits our ability to fully consider this as a viable option in the short-term.
- The prototype imported too much code from Aptos code base. The imported code was “internal” to another project, it was not easy to understand and was hard to tell which was by design that less likely to change and which was implementation detail.
The XRPL’s rich set of native objects would need to be translated into objects that can be understood by the MoveVM, but this effort would be non-trivial.

EVM

EVM is the world’s first blockchain smart contract VM. Its programming language, Solidity, is still the most popular smart contract language. We created a prototype that hosted an EVM. The host prototype interacts with the EVM by providing storage for storing code and data, and by publishing smart contract bytecode to the EVM and later invoking the contract. The library we used, revm, was very easy to work with, and we had a similarly positive experience with associated tooling, reflecting the mature state of the EVM ecosystem.

However, we decided not to advocate for integrating it into the XRPL mainnet for the following reasons:

We wouldn't be able to support many Ethereum RPCs because tooling (for code development, or wallets for example) would need to be changed, resulting in both rippled development work, tooling work, and a steeper smart contract developer learning curve, which would likely delay overall adoption.
The changes we’d have to make to the EVM to enable it to work in the XRPL would remove many of the great benefits of the EVM (e.g. tooling, copy-paste-ability of contracts, etc.)
Hypothesis: The ostensible benefit of choosing EVM is easy copy-pasting of existing Solidity code. However, existing Solidity code doesn’t know anything about the XRPL (addresses, signatures, objects, etc.). So, to allow this sort of copy-pasting into the rippled version of EVM, we would have to abandon many XRPL primitives, which we see as a core strength of the XRPL.
- Likewise, this approach would not be beneficial to EVM developers as they would have to rewrite their smart contracts to use XRPL primitives.
- The XRPL ecosystem already has a planned sidechain with EVM capabilities (the XRPL EVM Sidechain). That will be a more optimal option for Solidity developers, since it will be a standard EVM environment to build in.

Phase 2 Conclusions

Given our findings in Phase 2 (outlined in the table below), we propose that the VM choice for XRPL programmability is based on WASM.

Next Steps

Stay tuned for a second blog post outlining our proposed vision for programmability on the XRPL, as well as a couple of XLS specs!

EVM Sidechain Devnet is Now Available for Testing and Development

Mayukha Vadari — Mon, 26 Jun 2023 17:11:06 +0000

As of June 26, the EVM sidechain for the XRP Ledger is available on a new version of Devnet (v2). This new version features a decentralized bridge design using the XLS-38d specification and supports XRP, IOU, and ERC-20 token transfers in both directions between the XRP Ledger and EVM sidechain. This EVM sidechain uses a Proof of Authority (PoA) consensus mechanism. Developers are encouraged to test the new functionality of the Devnet v2, as well as the functionality of the bridge using all supported token types.

Connect to the new version of the EVM sidechain 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

For support, updated documentation is available at opensource.ripple.com. Developers are also welcome to engage in the XRPL developer Discord, which has a dedicated EVM-sidechain channel.

Full list of updates:

EVM Sidechain:
- Improved block time from 5.4 to 3.5 s/block
- Improved chain performance upgrading Tendermint to Comet BFT consensus algorithm
- Implemented PoA validator election mechanism
Explorer:
- Improved Sidechain Block Explorer, now including smart contract verification
- Developed Explorer on the Cosmos layer (in progress)
Bridge:
- Included Faucet support to facilitate onboarding (for XRP and tokens)
- Included support to bridge ERC-20 and IOU tokens
- Implemented a Witness Bridge to now use XChain transactions to natively secure bridge transfers between XRPL and the Sidechain with XLS-38d
- Witness bridge can now be distributed and operated by multiple parties - Up to 32 signers on XRPL
- Witness keys can be stored on AWS KMS to safely secure the keys
dApps:
- Launched Gnosis Safe dApp used to secure the bridged assets on the EVM Sidechain part
- Open dApp interface to everyone for safely creating a multisig account in the EVM Sidechain

The EVM sidechain is being developed by Peersyst in partnership with Ripple. Developers can iterate on their projects and applications faster and use popular smart contract languages like Solidity, while having access to XRP liquidity and a secure bridge to the XRP Ledger.

The original version of the EVM sidechain announced last October here will be available at the following URLs for the next 1 month after which it will be retired. Developers are encouraged to use the new EVM sidechain instead to deploy their apps.

EVM Sidechain V1 (which will be retired in a month)

RPC URL: https://archived-rpc-evm-sidechain.xrpl.org
EVM Block Explorer URL: https://archived-evm-sidechain.xrpl.org
Bridge URL: https://archived-bridge.devnet.xrpl.org

A security audit of the EVM sidechain is being conducted in July, the results of which will be published for the community to review. Peersyst and Ripple will take action to address any issues, and that information will also be shared with the community as well.

The EVM sidechain is expected to go live on mainnet following the approval of the XLS-38d bridge amendment. The bridge is dependent on the proposal of the amendment, followed by at least 80% of the XRPL validator community accepting the proposal and holding their vote for at least two weeks.

XRP Ledger Sidechains Available on New Devnet

Mayukha Vadari — Wed, 29 Mar 2023 20:36:20 +0000

Last year, RippleX developers shared details on the new design of sidechains for the XRP Ledger.

After testing and reviewing community feedback from the preview, the implementation, spec and documentation of that design (XLS-38d) are now complete and ready for review and testing. A new Devnet is also available for sidechains-related testing. Developers are invited to join the cross-chain bridge standards discussion on Github, or check out the documentation to learn more and get started.

XRPL Sidechains Devnet Access Details

The sidechains support for XRPL is now available for testing and initial application development. This proposal allows for the creation of an XRPL based sidechain, 2 door accounts connecting the locking chain (or mainchain) to issuing chain (or sidechain) and a set of witness servers to manage the flow of funds between these 2 blockchains. Below are access instructions for a public development network that has been set up.

Please use this form to report any bugs, provide feature feedback, or share any network issues you are experiencing.

How to access this network:

Locking chain: sidechain-net1.devnet.rippletest.net
- Websocket: wss://sidechain-net1.devnet.rippletest.net:51233
- JSON-RPC: http://sidechain-net1.devnet.rippletest.net:51234
Issuing chain: sidechain-net2.devnet.rippletest.net
- Websocket: wss://sidechain-net2.devnet.rippletest.net:51233
- JSON-RPC: http://sidechain-net2.devnet.rippletest.net:51234
Locking chain faucet: curl -X POST https://sidechain-faucet.devnet.rippletest.net/accounts
XRP-XRP Bridge:
- Locking Chain Door: "rMAXACCrp3Y8PpswXcg3bKggHX76V3F8M4"
- Issuing Chain Door: "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"

Client Library Support (Beta):

JavaScript library: xrpl.js@2.7.0-beta.3, ripple-binary-codec@1.5.0-beta.3
Python library: xrpl-py 1.8.0b2

Network Explorer:

https://custom.xrpl.org/

Note: This network is still in beta and there may be crashes or network resets. Please use this form to report any issues.

What’s Next For Programmability? EVM Sidechain and Hooks

RippleX engineers also recently unveiled an Ethereum Virtual Machine (EVM) sidechain on Devnet to allow even more developers easy access to XRPL’s feature set and bring existing Solidity-based smart contracts written for EVM-compatible chains to the XRPL.

Additionally, as a direct response to the demand for smart contract-like functionality on the XRP Ledger, the team at XRPL Labs has introduced Hooks. Hooks are small, efficient pieces of code that allow for the quick and easy execution of logic before and after a transaction — all native to the Ledger. Hooks will enable additional programmability on top of XRPL as well as smart contact capabilities that are fast, low-cost and eliminate the need for Solidity or contract-to-contract calling.

We will keep the community apprised of new updates as we continue to progress our roadmap for XRPL sidechains.

With the re-release of sidechains, developers and contributors are invited to the XRPL discord community to comment and ask questions To learn more about sidechains and other innovations, visit GitHub or check out the XRP Ledger Learning Portal course.

An EVM Sidechain for the XRP Ledger

Mayukha Vadari — Mon, 17 Oct 2022 13:17:49 +0000

Last September, David Schwartz introduced his thoughts on an Ethereum Virtual Machine (EVM) sidechain to bring Ethereum smart contracts to the XRP Ledger (XRPL) and lower the barriers to entry for developers wanting to build apps with cross-chain interoperability.

Today, Peersyst is announcing that it has released the first phase of the EVM sidechain for the XRPL now live on XRPL Devnet.

This milestone means more developers can easily access the XRPL’s feature set (such as its speed, sustainability and low-cost transactions) and bring Solidity-based smart contracts to the XRPL. As part of the phase 1 launch, we’re also introducing a bridge between an EVM-compatible chain and the XRP Ledger Devnet.

The release means developers no longer have to choose between XRPL or EVM-compatible blockchains; they can have the best of both worlds.

The Road(map) Ahead
This first phase of the EVM sidechain is currently available for testing on the XRPL Devnet. Using a bridge, developers can test the exchange of Devnet XRP between the EVM sidechain and XRP Ledger to:

Assess available technologies
Deploy their existing Solidity apps on the EVM sidechain and access the XRPL Devnet userbase

Phase two of the project, on track for early 2023, will feature a permissionless EVM sidechain and bridge with a unique design that connects to the XRPL Devnet to expand participation and test scalability within a controlled environment. The end goal is phase three: a permissionless EVM sidechain and bridge available on the XRPL Mainnet slated to follow.

Throughout all three phases, the EVM sidechain will feature block and finality times comparable to the XRPL Mainnet and support Ethereum smart contracts and applications like Metamask, Remix and Truffle.

Bridging Between the Best of Both Worlds

Many crypto developers today choose to build on Ethereum or EVM-compatible chains because of the popularity of Solidity for programming smart contracts and a robust ecosystem of available developer tools and dApps (decentralized applications). On the other hand, the XRPL appeals to developers because of its speed, low cost, sustainability and other features.

However, making the XRP Ledger EVM-compatible could undermine its efficiency, scalability and security. So, instead of forcing developers to choose between chains, Peersyst and Ripple partnered to create an EVM sidechain connected to the main XRPL.

By building an EVM sidechain and bridge, we are making XRPL features accessible to more developers that would benefit from XRPL advantages like fast, low-cost transactions at scale. Developers can also leverage the sidechain and bridge to use XRP within the EVM sidechain environment.

Between Ethereum smart contracts, Hooks and Smart Transactors, XRPL developers will have the flexibility to build the next generation of blockchain-driven apps.

Experiment Today
Developers can try out the new EVM sidechain today by connecting XRPL Devnet with a XUMM wallet, connecting Metamask with the EVM sidechain, then transferring XRP from XRPL Devnet to the EVM sidechain and back again.

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

Developers, we invite you to experiment with the EVM sidechain on Devnet and join the XRPL Developers Discord to provide your feedback/suggestions.

You can also learn more about the redesigned XRPL sidechains here and watch Peersyst’s demo on how to design an EVM sidechain at Apex 2022.

Introducing xrpl.js

Mayukha Vadari — Wed, 20 Oct 2021 22:02:18 +0000

RippleX and the XRP Ledger Foundation (XRPLF) are excited to announce xrpl.js version 2.0.0, a JavaScript/TypeScript library for interacting with the XRP Ledger (XRPL). Formerly known as ripple-lib, the library was renamed to better represent its role in the XRPL ecosystem and overhauled to take advantage of modern JavaScript features.

Background

JavaScript is one of the most widely-used programming languages, and as such has a massive community of active developers. Maintaining a JavaScript SDK enables these developers to seamlessly interact with the XRP Ledger, both in the browser and in Node.js. In addition, the JavaScript libraries (xrpl.js, ripple-binary-codec, ripple-keypairs, and ripple-address-codec) power many apps in the XRPL ecosystem, as well as packages from companies such as BitGo and Ledger.

Changes

With this release of xrpl.js, the JavaScript, Java, and Python libraries provided by the XRPLF now have parallel structures and systems. This enables developers to easily work with their preferred programming language depending on their specific needs, without having to learn an entirely new interface.

xrpl.js will continue to support all ripple-lib features, such as:

Serializing, signing, and submitting transactions to the XRPL
Retrieving information from the XRPL
Helpful utility functions (such as converting between drops and XRP)
Support for Node.js, web browsers, and React

It also introduces a number of new features, including:

TypeScript types for all transaction types and WebSocket requests
A Wallet class to make it easier to work with key pairs
Protections against the partial payment attack vector
An additional submit implementation that returns the transaction's final outcome after validation.

In version 2.0, the library is now much more aligned with the core XRP Ledger interface. This means XRPL developers—whether new or experienced—can refer to multiple sources of documentation instead of needing to rely solely on the library-specific documentation. There are also a number of general architecture improvements, such as simplifying code, making user interfaces more intuitive (especially in relation to the core ledger), and revamping the testing structure. For a detailed list of changes, visit the changelog.

Start Building

To get started using xrpl.js, see this tutorial on xrpl.org, or check out the project repo or reference documentation.

If you already have a project that uses ripple-lib, migrate today! We have a migration guide for moving your code from ripple-lib v1.10 to xrpl.js v2.0.

We hope you enjoy building the Internet of Value, and feel welcome to reach out to the XRP Ledger developer community if you have any questions!