Enhance NFToken transfer fee (AKA "royalties") functionality

[ledhed2222]

Problems:

1. Currently there is no way to delegate another account as the recipient for an issuer’s NFT royalties (AKA NFT transfer fees). This is a problem if the issuer is a blackholed account, which is desirable to prove there are a limited number of NFTs in a collection.
2. Currently there is no way to split royalties among several parties without trusting a single party to pay out fairly and in a timely manner.

Potential Solution:

• Add an AccountSet flag asfNFTokenTransferFeeReceipient that, if set, will send all transfer fees to the indicated account. This also means adding a field sfNFTokenTransferFeeReceipient to AccountRoot.
• Add an AccountSet flag asfNFTokenTransferFeeSplit that, if set to a value > 0 and <= 1 will send only that proportion of the transfer fees to the account indicated in asfNFTokenTransferFeeReceipient. This also means adding a field sfNFTokenTransferFeeSplit to AccountRoot.

This solution solves problem 1.. It only partially solves problem 2, but may be sufficient for the 95% cases.

[pkmelee337]

That would be a perfect addition! The only addition is that I would expect the asfNFTokenTransferFeeSplit to be a value between 0 and 100000, allowing transfer proportion rates between 0.00% and 100.00%, as I don't think it's possible to add decimal values. Still leaves us with problem 2 indeed when an issuer is a blackholed account, but that could get fixed with hooks in time.

[shashwatmittal92]

Yes, you're right. An issuer that has a need for blackholing their NFT issuer account will not really be able to leverage the benefits of splitting royalties.

[scottschurr]

I'd rather see the entirety of this problem solved with Hooks.

I'm not keen to add yet more special purpose fields to the AccountRoot. The AccountRoot is at the heart of the XRP Ledger. Things that are added to the AccountRoot can never go away.

If this problem is solved with Hooks then the Hook code will be owned only by those accounts that need the Hook. The burden can be localized rather than carried by every single account in the ledger. And Hooks can solve many additional problems. Hooks provide a general solution that can solve the identified problem plus many more.

The AccountRoot already has four fields that are only used by accounts that are NFToken issuers:

• NFTokenMinter,
• MintedNFTokens,
• BurnedNFTokens, and
• FirstNFTokenSequence,

This proposed change would add yet two more fields. When will this be done? I have no confidence these will be the last two additional fields.

Is there a way to confirm that this feature will be useful to a significant proportion of the user community? Can we, instead, use the existence of these problems as additional motivation to get Hooks integrated into the main network expeditiously?

That said, the proposed solution looks like it ought to work. I agree with @pkmelee337 that the new optional sfNFTokenTransferFeeSplit field should be a 32-bit unsigned value with a valid range from 0 to 100000 representing 0.000% to 100.000%. That keeps the interface aligned with the TransferFee field used in minting.

But just because it would work does not make it a good idea. Consider Hooks instead.

[xVet]

Great thoughts on this, however, to 1. , this is not the perception of the community when it comes to limited collection. There's no demand for on chain proof to not being able to mint more in exchange for black holing the issuer wallet and basically disabling the address.

In fact, the same issuer is the actual value here especially for nfts minted for different series of digital media. Provenance.

To 2.) splitting royalties to n parties is indeed something the community is interested in. Very much actually. The accountSet here would enable only allow n=2.

Hooks might never come to main chain. But this would be something i would love to see being solved on a layer2 actually.

[ledhed2222]

Can you say more about how you'd envision it integrating w a layer 2?

[xVet]

Can you say more about how you'd envision it integrating w a layer 2?

That goes actually with what Scott said, we would need Hooks and ideally universal smart contracts like Evernode would provide. Imo the best solution to solve the trust issue involved here. You'd need to trigger on account level, it would be awesome to trigger those splits at TX level but you'd need to have Hooks engaging with NFTokenPages which i think is not planned.

[billian]

Hi, Is there any developments in this direction re royalties to more than one recipient or multiple? I could certainly use this.