Decentralized blockchains such as the XRP Ledger (XRPL) rely on the collective decision-making of their participants in order to coordinate changes to the protocol. Amendments are the primary mechanism for initiating changes to the XRPL, which track changes to transaction processing. This includes new features, enhancements to existing functionality, and bug fixes. Validator operators vote on these amendments. If more than 80% of support is maintained for two consecutive weeks, the amendment activates, enabling the associated behavior.
The XRP Ledger software (rippled) generally defaults to voting against new amendments in order to reduce the odds that older servers become "amendment blocked" (context). It’s expected that some amendments may default to “yes" in a future release of the software—after the code to understand them has been included in a stable rippled release for some time. For example, an important fix might be given a default "yes" vote. In most cases, bug fix amendments are expected to move from default "no" to default "yes" after being in stable release for about two release cycles.
Overview of Amendment Blocking
Amendment blocking is a safety feature that protects the XRPL. When an amendment is enabled, servers running earlier versions of the rippled software are designed to detect that they don’t have the source code required to understand the amendment. Therefore, they can’t reliably process transactions correctly, according to the current protocol rules. Instead of potentially misinterpreting transactions or ledgers, these servers automatically become amendment blocked, effectively ceasing to function. They don’t submit or process transactions, and they don’t participate in consensus.
The voting configuration of a server doesn’t influence whether or not it becomes amendment blocked. Servers always follow the amendments enabled by the rest of the network, and amendment blocking occurs solely based on the absence of the code required to understand the rule changes.Connecting your server to a parallel network with different amendments enabled can also lead to amendment blocking. For example, the RippleX-operated Devnet test network often has experimental amendments enabled. Even if you are running the latest production release, your server may not have the code for those experimental amendments. When relevant, details about experimental amendments on Devnet will be posted to the XRP Ledger Blog.
To unblock an amendment blocked server, update to a newer version of the rippled software. On the Mainnet production network, the latest stable version always understands the enabled amendments on the network.
How Ripple Votes
Validator operators should independently assess the impact of amendments and exercise judgment to make informed voting decisions. A balanced approach considers the network's stability, robustness, and usefulness. Ripple takes this approach and recommends it to other stakeholders. It is beneficial for the network's overall robustness and security to minimize the number of amendment blocked nodes. Additionally, updating the software is a burden and should not be taken lightly. Every update brings both improvements and risks, as new bugs could be introduced and unexpected emergent behavior could occur.
Participants take time to review release notes and code changes, and nodes on the network tend to be updated to newer versions of rippled over time. There is a diverse community of independent node operators, and not all of them apply updates on a frequent basis. It makes sense to offer a reasonable amount of time between the introduction of an amendment and its activation to allow the network as a whole to upgrade and mitigate nodes becoming amendment blocked. This is why Ripple has intentionally chosen not to vote in favor of a new amendment until some time has passed since its introduction in a stable release.
Ripple does not control the XRP Ledger Mainnet and runs only 1 of the 30+ validators on the most commonly-used UNL. At the protocol level, Ripple's amendment votes have the same amount of influence as the votes of any other validator. Each node operator chooses the UNL they wish to use, which may include configuring their own UNL.
As always, we encourage ongoing engagement and dialogue. You can reach the software maintainers by opening an issue on GitHub.
In this post, we provide an analysis of the six amendments that were introduced in rippled version 1.10, released in March 2023. Each amendment brings its own set of changes and implications.
featureImmediateOfferKilled
featureImmediateOfferKilled changes the response code of an OfferCreate transaction with the tfImmediateOrCancel flag, changing it from tecSUCCESS to tecKILLED when no funds are moved. (Full details)
This change improves the clarity of the transaction status by providing a more intuitive result code. The tradeoff is that applications and services that rely on the previous response code may need to be updated. In our assessment, the improved clarity outweighs the potential need for minor adjustments in applications. Ripple has voted in favor of the featureImmediateOfferKilled amendment.
featureDisallowIncoming
featureDisallowIncoming allows an account to block incoming checks, payment channels, NFToken offers, and trust lines. (Full details)
This feature provides users with increased control by allowing accounts to block incoming transactions. For users who do not wish to use certain features, disallowing them is a good way to improve the user experience by preventing spam. It may also help to reduce ledger bloat, as users can block certain unwanted ledger objects from being created. On the other hand, users who have blocked certain ledger objects will not have access to use cases that depend on those objects. In our assessment, the added control outweighs the potential limitations on certain use cases. Ripple has voted in favor of the featureDisallowIncoming amendment.
featureXRPFees
This amendment simplifies transaction cost calculations by using XRP directly, instead of calculating indirectly in "fee units". All instances of "fee units" are updated in the protocol and ledger data to be drops of XRP. (Full details)
This refactor streamlines transaction cost calculations and simplifies fee-related calculations. On the other hand, it may require adjustments in applications that rely on the previous fee unit calculations. In our assessment, the streamlined calculations and improved maintainability of the implementation outweighs the potential need for adjustments in applications. Furthermore, we are not aware of any specific applications that will need to be updated. Ripple has voted in favor of the featureXRPFees amendment.
fixUniversalNumber
This amendment simplifies and unifies the code for decimal floating-point math, resulting in slightly improved accuracy. (Full details)
This refactor provides slightly better accuracy in decimal floating-point math calculations. However, it may cause edge case discrepancies in places where precise calculations are used, such as ranking of offers, or processing of payments that use several different paths. In our assessment, the improved maintainability of the code justifies the potential edge case discrepancies. Ripple has voted in favor of the fixUniversalNumber amendment.
fixNonFungibleTokensV1_2
This amendment includes multiple fixes related to NFTokens. It allows NFTs with more than 500 offers to be burned (#4346). It fixes a few NFToken offer acceptance issues (#4380). It prevents brokered sales of NFTokens to owners (#4403). And for NFT offers that have a destination set, only that destination will be able to settle through brokerage (#4399). (Full details)
While these fixes are not extremely urgent, they are important quality-of-life improvements for NFToken users, marketplaces, and businesses. They enhance the overall reliability and usability of NFToken features. Ripple has voted in favor of the fixNonFungibleTokensV1_2 amendment.
fixTrustLinesToSelf
This amendment removes two trust lines that are not between two different accounts. Although trust lines must be between two different accounts, the two trust lines removed by this amendment exist due to a previous bug. (Full details)
Removing the two trust lines is not expected to have any meaningful impact on the ledger. Ripple has voted in favor of the fixTrustLinesToSelf amendment.
Conclusion
After carefully evaluating the pros and cons of each amendment, we provide our decisions as outlined above. We encourage active participation and evaluation by every validator operator in making decisions on how, and when, to vote on each amendment.
As in the past, this post intends to shed light on Ripple’s voting decisions. We believe that the amendment process is important and plays a crucial role in guiding the XRP Ledger’s continued evolution. Because of that, validator operators should be active and engaged participants in the amendment process. Please evaluate proposed amendments using criteria that you believe to be important.
Casting a Ballot
To vote in favor of a particular amendment, the command to execute is:
/opt/ripple/bin/rippled feature NAME accept
To vote against a particular amendment, the command to execute is:
/opt/ripple/bin/rippled feature NAME reject
Replace /opt/ripple/bin/ with the path to your rippled binary, and NAME with the name of the amendment.
Top comments (0)