Ripple Validators Vote in Favor of XLS-20 Amendment

Today, Ripple is upgrading its servers to the recently released version 1.9.1 of rippled, the reference implementation of the XRP Ledger (XRPL) protocol, and configuring its validators to vote in favor of activating the XLS-20 amendment on XRPL Mainnet.

Ripple proposed XLS-20 last May to bring native NFT support to the XRPL and provide developers access to NFT minting, trading and burning functionality. XLS-20 also includes advanced features like automatic royalties, co-ownership of assets and more without the need for smart contracts.

What’s New

In line with Ripple's previous commitment, we conducted extensive testing to ensure that the NFT code is stable, scalable and performant in the face of the additional transaction volume anticipated by native, on-ledger support for NFTs. As a result of that testing, we feel confident that the XRPL can support the extra transaction load at scale.

We plan to share the results of our testing in the coming weeks so server operators can better understand the performance characteristics and resource requirements of the server software in a world where XLS-20 is activated.

Included in the 1.9.1 release are fixes to address syncing difficulties, as well as several improvements, including:

• The fixNFTokenDirV1 amendment, to fix a corner case that could result in a potential off-by-one error when determining which page an NFT object belongs on.
• The ExpandedSignerList amendment that would expand the maximum number of signers on an account from 8 to 32 to enable more advanced use cases. Additionally, this amendment allows each signer to have an arbitrary 256-bit data field that can be used by external code.
• Improved Memory Efficiency of Pathfinding: Code improvements that reduce the memory footprint of pathfinding operations by discarding trust line results that cannot be used before those results are fully loaded or cached.

XRPL Amendments: The road to XLS-20

Activating an amendment to the XRPL Mainnet is not up to a single entity, operator or server. The amendment process requires broad network agreement for an extended period. The default for proposed new feature amendments—including the XLS-20 standard—is set to vote “No.”

By design, this allows validators time to review proposed amendments before deciding whether to vote in favor of enabling them. If either of the two amendments introduced in the 1.9.1 release reaches and maintains the requisite 80% support, servers running on previous versions will find themselves amendment blocked. To ensure service continuity, server operators should be prepared to upgrade to a version of the software that includes support for amendments that have gained majority support.

As with all proposed amendments that introduce new features, Ripple recommends that XRPL validators do their own due diligence before moving forward and voting to enable XLS-20.

To further address the scalability and performance of the network, Ripple continues to work on the open-source Clio project as part of our ongoing commitment to developing best-in-class tools and building on top of open protocols.

For anyone interested in experimenting with XLS-20 and exploring the NFT capabilities it introduces, Ripple is operating an NFT-Devnet. All are welcome to explore NFT-Devnet, which demonstrates the performance characteristics and implications of the proposed XLS-20 standard without compromising the performance of the XRPL Mainnet.

To learn more about improvements and new functionality in 1.9.1, visit www.xrpl.org.