Over the past nine years, the XRP community has committed to driving the innovation and advancement of the XRP Ledger (XRPL) to dramatically increase its decentralization, performance, and feature set.
Some of the most requested features we’ve heard from the developers and contributors of the XRP Ledger include smart contract features brought about by the exponential growth of decentralized finance (DeFi). In fact, the number of DeFi developers has increased 110% since 2019, and that number is expected to grow well beyond 2021. At Ripple, however, we have long spoken out against features that would detract from the XRP Ledger’s highly efficient focus on payments.
Today we propose a strategy that enables the best of both worlds: Federated sidechains for the XRP ledger. This will enable developers to implement new functions such as native smart contracts that work seamlessly with XRP and the XRP ledger, while the XRP ledger can maintain its existing, “lean and efficient” functionality.
Federated sidechains enable experimentation and specialization so that developers can enjoy the power of the XRPL on a sidechain that acts as its own blockchain. For example, imagine the potential to step into new functionality by reducing the functionality of the XRPL to a specific subset for a specific use case – or even creating a private, parallel network for an authorized blockchain. Federated sidechains could very well make this a reality.
To understand the vision for federated sidechains, it is first important to define a federator: software that connects to at least two instances of the XRPL software. The Federator software means anyone who wanted could run a sidechain to the XRP ledger. On one side the Federator is connected to the XRP Ledger Mainnet. On the other hand, it connects to one or more sidechains. The federator would only be operated by parties who operate validators on at least one sidechain.
The vision is that each sidechain would function as its own blockchain. They would have their own ledger and transactions, just like the XRP ledger. What makes them sidechains is the federation system, which allows XRP and issued tokens to move from one chain to another.
Federated sidechains could use XRP as their primary asset. In that case, people could use the federation system to move XRP from XRPL to the sidechain. Then the relocated XRP could be used in the sidechain in the same way as in the main chain. Anyone could move XRP from one chain to the other.
Alternatively, sidechains could use their own native asset, allowing people with accounts in both ledgers to move XRP to and from the issued asset on the sidechain.
Federated assets imported on XRPL itself would be traded on the XRPL’s integrated decentralized exchange (DEX). XRP imported into sidechains would also be used for liquidity on their built-in DEX.
This strategy requires three things:
- Creation of new software or the “Federator”.
- Making two trivial changes to the operation of the live XRP ledger network.
- Adding new features to the XRPL server software so that it can operate on a sidechain. However, these functions would Not activated on XRPL itself. (The current recommendation is to fork the XRPL software so that new versions of the sidechain software can come out without creating new versions of the XRPL software and to reduce the risk of XRPL harm.)
Each sidechain would have a “trust” account in the XRPL mainnet. This account can hold assets on the XRPL on behalf of users of the sidechain. The account would use a multisign or threshold key with the signers being the sidechain validators. Each sidechain validator operator registers a signature key that signs transactions on XRPL; Thus, the sidechain validators can collectively create transactions to manage the sidechain’s mainnet account.
The XRP Ledger Mainnet has a native asset, XRP, and an unlimited number of issued tokens, which can represent everything else but do not have the same status as XRP. It wouldn’t make sense for every sidechain to start with a whole new set of 100 billion XRP. Instead, sidechains have two options for their native asset: Either you have a new native asset for the sidechain or you put real XRP aside for use in the sidechain. If the sidechain uses XRP as a native asset, the chain’s account on the mainnet keeps the total amount of XRP on the sidechain “trustworthy” for use on the sidechain. If the sidechain creates another native asset, this asset can be issued via the mainnet account of the sidechain in the XRPL mainnet.
The sidechain can contain other assets and tokens that are natively issued on the XRPL mainnet; just like with XRP, the sidechain’s mainnet account contains the total amount used on the sidechain. Ownership of this asset within the sidechain can change due to transactions and events on the sidechain that the XRPL mainnet never needs to see. Whenever an asset – XRP or otherwise – has to be moved “out” of the sidechain, the mainnet account of the sidechain sends this amount of XRP to the intended recipient in the mainnet. This could even be the account of another sidechain, which means that assets from one sidechain can be transferred to another sidechain via the mainnet. Conversely, to send funds “into” a sidechain, you would send funds to that sidechain’s mainnet account.
Someone setting up a new sidechain should choose a number of initial validators and let them negotiate an appropriate threshold or multi-signing key. They would then create the sidechain’s XRPL mainnet account and set it up so that only the collective signing power of the sidechain validators can control that account. If the sidechain validators change, the mainnet account should change its keys to match the new list of trusted validators. (Note: the XRP ledger’s native multi-signing lists are limited to 8 keys or less, but threshold keys can support as many signers as are required for each of the sidechain’s validators).
With this software everyone can choose whether they want to run a sidechain to the XRP ledger. For developers, it opens up new use cases such as native DeFi functions and smart contracts. Developers can also create and launch blockchain functions that are “burned” into these sidechains; in the future, successful features could even be ported to the XRPL mainnet.
The developers who manage a sidechain also have the freedom to decide how their chains work. They would choose their own validators for their sidechain and could modify the rules of the system as needed (in collaboration with the validators of their sidechain). For example, a sidechain could work with no transaction fees or reserve requirements, it could work without its own copy of the XRP ledger’s decentralized exchange, or it could add new transaction types and functions for storing large amounts of data in the ledger. The possibilities are limitless: A sidechain can be subject to strict authorization or (almost) without authorization, centralized or (mostly) decentralized. You can even run a sidechain temporarily while letting it maintain real value, and gracefully shut it down once it’s served its purpose.
Immediate benefits of federated sidechains for developers include:
Horizontal scaling: Sidechains can have their own fee system, their own reserve system, and their own transaction capacity. Someone looking to build a system with thousands of users that can hold XRP has a better option than being the custodian or putting all accounts directly on XRPL.
Low risk: The XRP ledger doesn’t have to change at all. Even the changes that would be helpful are quite minimal.
Lower expense: Anyone who needs or wants to experiment with a blockchain can start immediately with a complete system that is based on the powerful, stable and sustainable XRP ledger technology.
Long roadmap: New features can be added over a long period of time based on feedback of what people find interesting. This would be a continuous stream of new features and capabilities.
Changes to the XRP ledger
Making this vision a reality will require some changes to the XRPL software that would not be used on XRPL itself to support the sidechain functionality. The primary change to the software is to support the Unique Node List (UNL) stored in the ledger. Pseudo-transactions to change the UNL would be required. A “hint” UNL would have to be supported to avoid the chicken and egg problem that the UNL is needed to get the ledger and the ledger to get the UNL.
Assistance for coordinating the creation of threshold and / or multisign keys and signing XRPL transactions introduced by the Federator is also required. Some API enhancements would likely be needed to handle pseudotransactions introduced by the federation or federation-federator communication over the peer network.
The XRP ledger mainnet could also use a flag to indicate whether or not an issued asset is allowed to be federated. For example, some asset issuers might insist that all holders of their assets be directly represented in the main chain for regulatory purposes, while others might allow their assets to trade freely on sidechains. (It is always possible to privately assign some of your own resources to others, with or without a sidechain, to automate the process, but legal responsibilities for doing this may vary depending on the jurisdiction and circumstances.)
Sidechains would have a special entry in their ledgers that keeps track of the last sidechain transaction that was performed on the main chain and the last main chain transaction that was performed on the sidechain.
When federators see a new transaction on the sidechain that affects the main chain, they coordinate the transmission of that transaction to the main chain. When federators see a new transaction on the main chain that affects the sidechain, they coordinate the transmission of that transaction to the main chain.
Making these changes is probably the largest part of that effort because even if they are not enabled on XRPL, there is still a risk of changing the software. For example, existing code may have to be moved or adapted, which carries the risk of an unintentional change in behavior.
The strategy outlined is a starting point for collecting feedback from the XRP Ledger community. We invite developers and community contributors to visit our Dev To Community page for review and feedback. Let’s create a roadmap for innovative, new use cases together.