The XRP Ledger (XRPL) was developed in order to provide a robust range of functions for the basis of the digital asset XRP in addition to the processing of payments and the exchange of digital assets of all kinds. The open source community of developers who support innovation in XRPL continues to fundamentally improve the technology to ensure performance, stability, security, quality, decentralization, developer experience, and governance.
It’s no secret that governance is one of the most difficult problems to solve in blockchain technology today. Blockchain is a rapidly evolving set of technologies, so adaptability and consistent improvement are essential. However, as the number of developers in the community grows and the servers on the network grow, the governance process becomes more difficult. As the XRP ledger network grows, so does the need for improved governance.
One of the main governance mechanisms that XRPL uses is the change process, which is intentionally designed and built for broad participation. The activation of changes to the XRP ledger protocol is coordinated by the community through this process.
The change process
Changes always start with an idea for an improvement or a new function. Because changes require broad consensus, discussion of new features often takes place in public forums. Last year the community discussed a number of possible features and design changes that could be introduced into the XRP ledger.
The next steps are to turn ideas into a proposed implementation and generate a series of code changes. At this point a change can be assigned to the function. Those that support this feature can run versions of the XRP Ledger software.
The change process itself can then be used by the community to coordinate activation of the feature. Validators who want the change to be activated on the network can indicate this. If 80% support is found, the reviewers start a two-week clock to allow the change. The change must be supported 80% during the two weeks or the cycle must start over.
During these two weeks, the community will have the opportunity to express their opinion on the change request. Validators can change their position, and in extreme cases, the community can even change which validators they want to hear. Ripple’s Unique Nodes List (UNL) has become more and more diverse and robust. Ripple now runs about 18% of the validators on UNL.
If the change is activated at the end of the two week process, participants who do not agree to the change will not be able to agree to the validators who support them and will be blocked. This security function is used to protect applications that depend on XRP Ledger data.
Bring collective change
The purpose of this change process is to empower the community to coordinate activation of changes that have broad support with minimal disruption and to avoid accidental branching when servers fail to agree on network rules. Validators cannot activate changes that do not have broad support, as this would only cause the network to branch out, and participants can of course change which validators they wish to agree to at any time.
Changes in the past have enabled a number of new features and fixed many minor bugs. Support for managed multi-signing has been made possible through changes, as has the general ledger’s on-chain escrow and payment channel capabilities.
Managed multiple signing enables an account to have multiple signers whose quorum is required to complete transactions. Members of the quorum can manage their own credentials. Payment channels greatly improve scalability by allowing transactions to take place outside of the general ledger but still be secured by the general ledger.
Today a new feature suggested in the change process is “Deletable Accounts” and is waiting to acquire and maintain a super major of 80% before activating. This feature can remove XRPL accounts from the general ledger and restore most of the reserve locked in the accounts to prevent spam.
These changes – and future changes – made as part of the change process add further confidence to the general ledger and ensure that XRPL continues to perform well with no downtime. The XRPL change process will continue to ensure that new features are activated appropriately and responsibly by the community and protect against accidental network forks.