Royalty fees

Developers Native Tokens
1

In a recent interview, Charles Hoskinson clearly states:
We can talk about this concept of perpetual royalties. So for example, let's say you create a piece of art. You can build into the token itself a perpetual royalty to something you care about. Maybe, every time it sells, it pays it back to you. Or maybe, every time it sells it donates to some clean water charity, or something like that. The point is, the actual acquisition of the NFT requires adherence to that smart contract. So people cannot deviate from your desire, even after you die. So, you know, stuff from Andy Warhol, or Picasso, that can still be generating some donation every time a Picasso sells to something else. You can do that with NFTs.

From everything I have come to understand about eUTXO, you cannot do that, if you actually want to send the native token to someone’s wallet. You lose control and have no way to enforce royalty fees.

I have been thinking about simply never sending the native tokens to a wallet, and always keep them inside of a smart contract, so you can force royalty fees. And then the contract would use transaction metadata to somehow keep track of who “owns” the tokens. I do not like this approach, it emulates the way Ethereum tokens work, dependent on the smart contract acting as a ledger. Hence I am asking here for any input on how to truly build a correct royalty feature.

The interview: Charles Hoskinson: Cardano | Lex Fridman Podcast #192 - YouTube

9 Likes
2

Thanks for posting this insightful question. I don’t think that this issue is widely appreciated.

  1. Regarding the approach you mentioned, holding the token in a smart contract is the straightforward decentralized way to enforce royalties. The contract would keep a record of the public key hash of the current owner. You don’t even need a token in the contract because the contract itself could be considered a “smart token”.

  2. If there is an off-chain notion of “validity” of ownership, the owner could hold the token in their wallet, but only transfers that paid the royalty would be deemed “valid”. Passing the token through a smart contract during the transfer could “validate” by adding metadata, or alternatively an oracle could just watch transactions and assert whether royalties had been paid. This sort of “validity” is not the same as the rigorous #1 above, and is a somewhat of an honor system or social construct. Tokens whose royalties were fully “paid up” might have more value because of their impeccable provenance.

  3. I get the impression that some of the NFT marketplaces will collect royalties on intra-marketplace trading. They might not even allow the token to leave the marketplace. This is a centralized approach. This could be less centralized if marketplaces formed a cartel for enforcing royalties.

  4. It might be possible to set up an escrow account from which royalties are paid.

I’d love to hear about other approaches.

3 Likes
3

Would it work to actually have a token pair ?

First token would be the NFT itself.
Second token would be sent by the Royalty smart contract.

Only the pair would be considered valuable in that case. And the only way to obtain the SC token would be to send a % of the NFT acquisition value to it. The SC could emit a new token with a counter, highest counter taking precedence over any other person claims.

People would cheat ? Yeah, but if you send to 1 ada royalty the SC when actually you paid 10K ada, you’re a bad person, but most importantly this piece of information will be contained in a metadata associated with the token sent by the SC. So anyone can take it as the true value of the last payment.

Want to cheat the other way ? And claim a ridiculously large payment you never did ? ok. But then, you’d need to send the actual % of it to the SC get the SC token back.

Hand waiving here … is that even realistic ?

ps: That sounds and feels like a variant of solution 2 from the post above. I started my answer when it landed, so I finished it.

4 Likes
4

Thanks for this detailed answer. I believe a true solution for this issue requires significant changes to the way transfers of tokens are validated. You would want to define not just a minting and burning policy, but also a transfer policy. But because I cannot influence the architecture on which my application runs, I will be looking into alternative ways of achieving royalties or transaction fees.

I did some more searching and found another developer with the same issue I brought up: https://www.reddit.com/r/cardano/comments/m5a86z/concern_regarding_cardano_native_token_transfer/ However, no answers were provided.

Regarding your #1 solution. I fear that wallets would not show the NFT to be in your wallet, like MetaMask does do for Ethereum. However, I do have to critisize MetaMask for this, since I have seen examples of smart contracts taking away tokens from wallets without those wallet owners making a transaction. Truly malicious code if you ask me, since the users did pay for the tokens.

But without a standardized way in which wallets and chain explorers show the “fake ownership” of a token, I fear it would cause too much confusion for anyone to be willing to put real money into this. I could write a wallet or website myself that shows they are the owner of the token, according to my own rules based on custom transaction metadata, but as soon as they would use different wallet software or another online explorer, it would be very difficult to see who the owner is.

Regarding your #2 solution. I think this way is probably the best way. It is still a far inferior solution, since nobody is forcing anybody to adhere to the rules. And I am afraid that the “validity” of a token is hard to show to non-tech art collectors. Again, most likely not all wallets or chain explorers would display whether a token is valid or not. And if that is the case, there will always be people that will stop paying royalties, or reflection fees, etc.

Both your #3 and #4 solution I don’t think are direct solutions to the issue, unless I am mistakes. #3 is just using #1.

So far, developers are using IPFS to upload images that are considered the real “value” the NFT is giving you ownership of. I like that this solves the problem of being dependent on a centralized host. However, if there was a way to have a service like IPFS, but one that also verifies if the token is still valid, or else it would not show the image, it would provide another way of truly forcing owners to act in accordance with the contract, or else they would need to try to sell a token that has no corresponding image.

That so far is the only trick I have been able to think about. But it only works in relation to NFTs, not in relation to FTs. FTs with transaction fees would simply never be possible. The value of a fungible token does not come in any way from its metadata. So users would not care whether the transactions that these tokens were part of were valid or not.

The only true way of achieving the same functionality Ethereum tokens provide, but without the weakness of Ethereum tokens depending on a (usually badly written) smart contract as a ledger, is to have a transfer policy. We already have minting and burning policies, why not add a transfer policy? I am not certain whether my assumption in this case is correct. Perhaps a core Cardano developer can tell me whether that would work or not.

Thanks again for your response @bwbush

4 Likes
5

Thanks, @Luuk_van_Egeraat and @Psychomb , for the additional information and perspective. Yes, a transfer policy would be the cleanest way to handle this.

We could also make a distinction between ownership and use:

  1. Ownership could be transferred without any smart contract or transfer policy, but “using” the token would require that the royalties have been paid. For example, if the token represents an image, then the image could only be viewed on secure hardware or a software-based DRM (digital rights management) system that verifies that royalties have been paid before the current owner can view the image associated with the token. (The hardware or software DRM would also prevent duplication.) This would probably be cumbersome and annoying, but might be relevant for very high value tokens.
2 Likes
6

And then once again there is an issue around centralisation of the DRM software. The Cardano ecosystem (or perhaps the entire blockchain ecosystem) would need to arrive to a standard way of validating tokens, so there can be multiple token validators, perhaps hosting the images in the same way IPFS hosts them.

I also found a third forum post regarding this same topic, again without a solution:

5 Likes
7

I suggested transfer policies for native tokens in the Developer Community on Discord:

Screenshot 2021-06-18 073743
Screenshot 2021-06-18 0737431158Ă—143 35.7 KB

And I also responded:

I agree, there would be a high performance cost. And besides, it would still not be an optimal user experience, since it would involve the user having to pay reflections manually or else their transaction fails. I can’t even see it being possible in the current wallets. I think its only possible to send native tokens to multiple addresses in one transaction through he CLI.

However, the fact remains that Ethreum / BSC do support reflections. It is arguably what is making tokens like SafeMoon so successful. I truly dislike the way it works, since it is impossible to actually see the transaction of the fee to each other account. All you can do is ask the smart contract what the balance is and see it is different from adding up all transactions they ever made.

So I don’t like my own proposal for a transfer policy. And I also don’t like the Ethereum way of adding reflection. But I do feel limited in my imagination for future dApps and tokens I want to launch without this feature.

I hope we can find a good way of adding this feature to Cardano.

4 Likes
8

Won’t this all depend on how Smart Contracts are implemented? It seems like this royalty “feature” is consistently cited as a driver of using smart contracts. Is there any indication that smart contracts as proposed will/won’t support royalties?

1 Like
9

It won’t support it on native tokens sent to a wallet. But if you keep the native tokens inside a smart contract, and use some other way to determine who “owns” the tokens, it can work. You’re basically required to do what Ethereum contracts always do, they act as ledgers.

Now I don’t want my smart contract to act as a ledger. And I don’t consider myself the owner of a token until I have it in my wallet. But since contracts are immutable, it’s not unthinkable for people to trust they own a token even if the contract contains it. Again, that is exactly how ERC20 tokens work on Ethereum. And people put in a lot of money and trust in those.

4 Likes
10

@Luuk_van_Egeraat has there been any updates regarding this issue as of Jan, 2022?

1 Like