Why We Have To Wait a Little Longer for NFTs on The XRPL
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.
What is XLS-20?
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.
Why is the XRPL Open Source?
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.
Why is a Broad Network Agreement Required?
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.
Why Was XLS-20 Delayed?
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.
Token Creation & Trustlines
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.
The Exploitation of Issuer Wallets & Royalties
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:
- An NFT is issued with an activated trust line flag and minted by an attacker.
- The attacker is now in possession of a vulnerable NFT on Account 1 which he/she can trade freely for any fungible IOU token on the XRPL.
- The attacker creates two more accounts:
- Account 2, on which he/she issues a custom XRPL IOU token
- Account 3, on which he/she sets up a trust line with this custom IOU.
- Account 2 sends 1 IOU token to Account 3.
- Account 1 creates a sale offer to Account 3 for 1 IOU token.
- By accepting this offer, the IOU token is transferred to Account 1 minus the royalty which is allocated to the vulnerable issuer wallet that has automatically created a trust line and, therefore, paid a reserve requirement of 2XRP. In addition, the issuer wallet now has a portion of the transaction in the form of a random IOU currency.
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.