Developers of most major blockchain networks have been betting big on NFTs and their functionality. Until recently, Ripple was on the cusp of implementing native NFT support on the XRP Ledger.
However a bug was unveiled recently, and the same has triggered developers to withdraw their consent votes. Owing to the said hiccup, malicious players are in a position to abuse minted NFTs and fidget with issuers’ reserves.
The official issue description note on GitHub read,
NFTs minted with the trustline & transferable flag enabled with a TransferFee > 0 are susceptible to attack by a malicious user which allows the attacker to create an infinite number of currencies on their attacking issuing account and maxes out the victims’ reserve requirement on the NFT account.
Breaking down the XRPL issue
Usually, whenever an NFT is sold, the creator is in a position to command a transfer fee, like royalty. The same is paid in the currency that the NFT was sold in. So now, if the creator of the NFT didn’t have a trust line to the currency, one could automatically be added.
Trust lines are basically structures in the XRP Ledger for HODLing tokens. They enforce the XRP Ledger’s rule that one cannot cause someone else to hold a token they don’t want.
So now, the combination of options involving transfer fees, allowing nonXRP sales, and auto trusting—in conjunction—have cropped up to be the issue. So, once an NFT is minted like that, a bad actor can simply sell the NFT between a few accounts for different currencies each time, adding a new trust line to the creator’s account. The same would be done at the cost of the XRP reserve.
Further elaborating on the same, Wietse Wind—Lead XRPL Developer—tweeted,
A once minted and sent/sold NFT with the lsfTrustLine + Transfer Fee could then be sold back and forth between two or more accounts from an attacker, causing more and more Trust Lines to be created for random shitcoins issued by the attacker. This goes against the idea that a Trust Line should never be created without explicit consent to < Trust > the issuer and asset.
Owing to the said finding, he further went on to ‘temporarily’ remove the ‘yay’ vote of the XRP Labs validator, halting support until the issue was resolved.
Alongside, another XRPL validator—Alloy Networks—tweeted that it will veto the XLS-20 amendment proposal until the bug is fixed. Its official tweet read,
“A late stage possible exploit has been reported in relation to the XLS20 amendment. In light of this, we will veto the amendment till a fix is found. It’s disappointing, yes, but the safety of both issuers and buyers is paramount. And the network of course.”
What next?
Wind went on to chalk out a series of actions that would likely follow. The issue will be fixed first, and then, operators will have to update to a new Ripple version that encapsulates the amendment. Post that, a re-test and re-vote will take place. If a majority is sought, then the amendment will go live.
He, however, exclaimed that this is “not something to rush” and “slow and steady wins the race.”
With respect to a plausible timeline, an analysis thread from ‘Combat Kanga’ revealed that XLS-20 will go live in a month in the best case. In the worst-case scenario, however, the same could stretch to two-and-a-half months.
Also Read – $304B: Ripple eclipses Bitcoin, Ethereum, Cardano on-chain activity front