On Monday the 12th of September 2022, the much-anticipated XLS-20 amendment was unfortunately postponed despite having reached a majority approval from UNL validators 13 days prior. Although the sudden change in consensus comes as a surprise to many, we would like to take the time to explore the reasoning behind the voting mechanism and subsequent postponement of the XLS-20 amendment.
In 2021, Ripple proposed the XLS-20 amendment in the hopes to bring native NFT support to the XRPL. This extension would provide capabilities such as NFT minting, trading, and burning, which are functions that NFT artists & developers require to build sustainably in the ecosystem. The reason why this amendment was met with so much enthusiasm is that the low transaction costs and fast speeds experienced on the XRPL form a perfect environment for creators to thrive in.
The open source and dynamic nature of the XRPL ecosystem mean that all participants and community members, that have a genuine interest in finding exploitable issues, are also able to help document and, in turn, resolve them. This protection is further amplified as new developments must be approved by the most trusted validators on the XRPL known as UNLs.
When an amendment is proposed, the trusted validator nodes must test and approve the proposal before it becomes active. Once checked by a validator, they can vote for or against the proposal depending on their findings. This transparent voting system can be observed here under the amendments section. The website conveniently displays all the validators that have voted ‘yay’, and all those voting ‘nay’. However, simply reaching enough ‘yay’ votes does not imply that the amendment can go live.
Once consensus is reached, the vote needs to stay above the 80% threshold for a two-week period. This is, again, in the best interest of the blockchain and, therefore, the community since, during this time, validator operators can run tests and conduct due diligence to find any further issues within the code. For the amendment to pass, validators must agree that the code is stable, scalable, performant, and most importantly secure. If the 80% agreement is held for two weeks, determining that the amendment in question has met these criteria, it is pushed to the public network, therefore, becoming the new standard on the XRPL.
In multiple threads, which are available on GitHub and Twitter, a potential exploit involving trust line flags was discovered during testing by trusted community member x-Tokenize. These threads explained a problem pertaining to the possibility for malicious actors in the space to spam issuer wallet accounts with random currencies, subsequently depleting their reserves.
Before jumping into the specifics, we will need to explore certain fundamental mechanisms of the XRPL.
The XRPL is known for its quick & easy-to-follow token creation. In fact, when an individual issues (or creates) a fungible (IOU) token on the XRPL, he/she can do so by following a few simple steps which are outlined in detail here. The two main components which need to be attributed to better explain this exploit are trust lines and reserve requirements.
To receive a token on the XRPL, you must first set up a trust line. This trust line is specific to the currency code of the token and, when signed, indicates that your account (also known as a hot address) ‘’trusts’’ the issuer of the token in question (known as the cold address).
When setting up a trust line, the hot address needs to allocate 2XRP, known as a reserve requirement, which is held into custody until the trust line is removed. Upon its removal, the reserve is fully reimbursed to the hot wallet.
Until now, this process was typically conducted manually, meaning, that the hot address had to physically sign the trust line transaction on their XUMM wallet. However, the new XLS-20 specifications indicate that if such a trust line flag has been set on an NFT, by either the issuer or marketplace, a trust line will automatically be created between the issuer wallet and the cold address when the NFT is minted. This is important to remember for the next segment.
When creating an NFT series, the individual or project in question needs to create an issuer wallet to issue the NFTs and receive royalties on secondary sales. If the trust line flag is activated on this issuer wallet, the wallet is vulnerable to the recently discovered exploit. Here is why:
If this process is repeated multiple times with multiple currencies, the issuer wallet begins to clog up with various sums and types of redundant currencies whilst simultaneously experiencing a reduction in its reserve. As one can imagine, this is an issue that may hamper the development of a healthy ecosystem.
This attack simulation was demonstrated by community member x-Tokenize. In the simulation, he came across some potentially detrimental effects when multiple accounts were used during the attack.
Upon further investigation, this newly discovered issue was determined to be an exploitable bug by other community members as well. Consequently, both the community and validators have decided to postpone the amendment until this concern has been resolved.
You can find x-Tokenize’s extensive sequence on this GitHub post.
Although this discovery was untimely in the eyes of many, everyone agrees that the possibility of exploitation should be revisited and corrected in order for the ecosystem to thrive in the long term.
A silver lining to this situation is that, unlike the previous proposals of XLS-20, the network had established more than 80% validator support version of the amendment, prior to this discovery. Once this issue is resolved, the relevant operators will update to the new rippled version containing the fixed NFT amendment, meaning, tests can be carried out again, allowing the vote to hopefully come through in the near future. If the majority agreement holds for the 14-day period, XLS 20 will finally become the new standard for the XRPL.
Related Articles
