The functionality of NFTs has been placed a significant emphasis by the developers of the majority of the main blockchain networks. Ripple was, up until very recently, very close to finishing the implementation of native NFT capability on the XRP Ledger.
However, it was only just discovered that there was a flaw, and because of this, developers have decided to retract their consent votes. Because of the aforementioned problem, dishonest players are now in a position to take advantage of newly issued NFTs and mess with issuers’ reserves.
NFTs that have been minted with the trusting & transferable flag enabled and a TransferFee that is greater than zero are vulnerable to attack by a malicious user. This type of attack grants the attacker the ability to create an infinite number of currencies on their attacking issuing account and brings the reserve requirement for the NFT account of the victim up to its maximum.
What is the XRPL problem?
Whenever an NFT is sold, the inventor is often in a position to demand a transfer fee, which may be thought of as a kind of royalty. The same amount is remunerated in the currency in which the NFT was originally purchased. Now, if the developer of the NFT did not have a trust line to the currency, it would be possible for one to be added automatically.
Simply said, trust lines are structures on the XRP Ledger that are used for storing HODL tokens. They ensure that the rule of the XRP Ledger, which states that one cannot compel another user to keep a token that they do not desire, is followed.
As a result, the problem that has arisen is the interaction between the many possible solutions including transfer costs, the authorization of sales in currencies other than XRP, and automatic trusting. Therefore, once an NFT has been minted in such a manner, a malicious actor may easily sell the NFT between many accounts for various currencies at each transaction, adding a new trust line to the account of the originator. The identical thing would be done, but with the XRP reserve being used up in the process.
In light of the aforementioned discovery, he then proceeded to ‘temporarily’ delete the ‘yes’ vote of the XRP Labs validator, so putting an end to support until the problem was fixed. In the same thread, an additional XRPL validator known as Alloy Networks tweeted that it would cast a vote of no confidence in the XLS-20 amendment proposal until the flaw is resolved.
In connection with the XLS20 modification, a potentially exploitable vulnerability at a late stage was disclosed. In light of this, we will use our right to veto the amendment until we can find a solution. It is disheartening, there is no question about it, but the customers’ and the sellers’ safety must come first. Of course, there is also the network.
What comes next?
The wind then proceeded to sketch up a sequence of events that would most likely take place. After the problem has been resolved, operators will be required to upgrade to a new version of Ripple that includes the modification as part of its functionality. After then, there will be another exam, as well as another vote, taken. If a majority is achieved, the amendment in question will be implemented.
On the other hand, he emphasized that this is “not something to hurry,” and that “slow and steady wins the race.” An analytical thread on ‘Combat Kanga’ found that the best-case scenario for when XLS-20 would be online is one month from now. This information relates to a reasonable schedule. However, if things go from bad to worse, the same period might be extended to two and a half months.
