Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIP-???? | Enforceable royalties #378

Closed
wants to merge 0 commits into from

Conversation

MartinSchere
Copy link

Overview

This CIP introduces a technical design to enforce royalties on-chain. This CIP is still developing and we hope to receive much constructive feedback.

Technical Requirements

The initial draft of the CIP was developed with the following technical requirements (ordered for reference, not by priority):

  1. Interaction with a contract occurs (asset is unlocked from a script UTxO) must trigger royalties payments. Importantly, this must operate independently and outside the control of any specific marketplace. Solutions requiring tacit social agreement (e.g. "every marketplace should use X script") are disallowed - any nonconforming party can circumvent such an agreement.

  2. It must not redefine the ownership of native assets: Cardano has already defined ownership of native assets - creating an auxiliary definition would require at least

    1. extensive changes in wallets and dApps
    2. operating outside the technical guarantees provided by Cardano’s proven, academic models (insecure).
  3. It should be backwards-compatible: Current NFT collections should be able to upgrade their collections to adopt this standard and enforce royalties.

Benefits

Adopting this CIP would guarantee that creators would receive royalties on any transaction involving their created assets - not only those creators for whom particular marketplaces process their royalties.
This also allows creators control over their royalties, instead of delegating that control to marketplaces.

Draft’s Shortcomings

The initial draft of the CIP successfully meets these three technical requirements. However, we have encountered the following shortcomings (ordered arbitrarily):

  1. Creators must maintain a whitelists which burdens newer marketplaces and the contract update process.
  2. Current assets require a migration in order to receive the aforementioned benefits of this CIP
  3. This draft proposal requires actors to watch the chain, mint Proof Tokens, and applying penalties. This implies and requires significant adoption by a distributed set of parties with competing economic interests.

We encourage and appreciate any feedback.

@Tenancio
Copy link
Contributor

One of the drawbacks of this CIP (as stated) is that creators must maintain a whitelist of scripts that they "allow" their NFTs to reside in. With the Cardano ecosystem growing so rapidly it is impossible to keep track of all the script addresses that are acceptable. I believe this would stifle development of new contracts where they struggle to get whitelisted for collections.

Another problem I see (if I am understanding correctly) is that this system seems to penalise the user and not the marketplace that is selling tokens with 0% royalties. If I knew nothing about cardano NFTs and I stumbled across marketplace with an NFT I liked, I could buy it without realising the marketplace is 0% royalties and then have my NFT rendered worthless by someone minting the proof token because it was at a script address that wasn't whitelisted.

I think starting this discussion is the right way to go as there needs to be an enforceable royalties method, however this seems like only a small part of the solution and we have a long way to go from here.

@itsmestale
Copy link

Hey Martin,

This is definitely a problem worth solving.
One question I had was if there would ever be a scenario where a user purchased an NFT from a "malicious" marketplace and sold it to another user on a compliant marketplace such as jpg.store. Would the new owner of this asset be in a position where they could be left with a "useless" asset despite never acting maliciously?

@MartinSchere
Copy link
Author

Hey Martin,

This is definitely a problem worth solving.
One question I had was if there would ever be a scenario where a user purchased an NFT from a "malicious" marketplace and sold it to another user on a compliant marketplace such as jpg.store. Would the new owner of this asset be in a position where they could be left with a "useless" asset despite never acting maliciously?

Ideally, the "watchers" would do the job fast enough to "punish" the seller, and not the buyer.

So the watcher will reference the UTxO and immediately render the NFT useless, before anyone is able to buy.

On top of that, a point of consideration is that the possibility of the punishment taking place should discourage the non-royalty-payers from listing.

@MartinSchere
Copy link
Author

One of the drawbacks of this CIP (as stated) is that creators must maintain a whitelist of scripts that they "allow" their NFTs to reside in. With the Cardano ecosystem growing so rapidly it is impossible to keep track of all the script addresses that are acceptable. I believe this would stifle development of new contracts where they struggle to get whitelisted for collections.

Another problem I see (if I am understanding correctly) is that this system seems to penalise the user and not the marketplace that is selling tokens with 0% royalties. If I knew nothing about cardano NFTs and I stumbled across marketplace with an NFT I liked, I could buy it without realising the marketplace is 0% royalties and then have my NFT rendered worthless by someone minting the proof token because it was at a script address that wasn't whitelisted.

I think starting this discussion is the right way to go as there needs to be an enforceable royalties method, however this seems like only a small part of the solution and we have a long way to go from here.

Thank you for the feedback.

Please read my comment below regarding your second point.

Regarding the first one, ideally the marketplace should be punished. However, we did not find a good way of accomplishing this.

@thaddeusdiamond
Copy link
Contributor

Definitely appreciate the approach this is taking and the need to solve for skirting royalties. Tackling the problem is important. Some additions I think this needs:

  1. Tokenomics or other incentives to the "watchers" and a discussion of specifically who they should be
  2. A pseudocode (or real code, thinking Helios for lightweight nature of referencing) implementation of the different endpoints
  3. A mechanism for "restitution"... I don't think NFTs should be permanently rugged there should be a way to restore the trust of the user in case it was an accidental royalty-skimp (e.g., unwitting buyers pay 5% plus some fee to unrug the NFT)

@alessandrokonrad
Copy link
Contributor

What happens if you trade NFT for NFT, or a bundle of NFTs for other NFTs? Or go with completely crazy selling mechanisms that cannot be captured inside the royalty config. It would limit the possibilities of your asset.

@Tenancio
Copy link
Contributor

Thank you for the feedback.

Please read my comment below regarding your second point.

Regarding the first one, ideally the marketplace should be punished. However, we did not find a good way of accomplishing this.

I still think this approach will stifle innovation on Cardano through the whitelisting system. It should ultimately be up to users to decide what contracts they use and there should not be any consequences for doing so. What I can see happening with this whitelist system that could help contract developers is that a central repository could be created to keep track of all the various scripts that are "trustworthy" however this in itself would require moderation and would favour open source contracts over commercial closed-source ones (whilst we should strive for open source there are some cases where closed source is necessary).

I also don't think we should push for a system that punishes users just because we can't think of a better alternative.

@nullhashpixel
Copy link

I don't see why such a CIP would be necessary. If payment of royalties needs be enforced, the one and only place for this should be the validator of the marketplace smart contract.
No need for any change on protocol level which would destroy one of the advantages of native assets on Cardano and make the ecosystem more centralized.

Speaking from a creator point of view, I don't want to keep any whitelists or blacklists, for both practical and ideological reasons.

@MartinSchere
Copy link
Author

MartinSchere commented Nov 17, 2022

I don't see why such a CIP would be necessary. If payment of royalties needs be enforced, the one and only place for this should be the validator of the marketplace smart contract. No need for any change on protocol level which would destroy one of the advantages of native assets on Cardano and make the ecosystem more centralized.

Speaking from a creator point of view, I don't want to keep any whitelists or blacklists, for both practical and ideological reasons.

I see how creators can have their reasons not to opt into the system. Royalties are opt-in, they are a feature for creators, established in a contractual way when the mint occurs. This CIP aims to provide a way to enforce such a pact in an on-chain manner.

Without a standard, anyone can circumvent the requirement by just listing the NFT in another validator.

@MartinSchere
Copy link
Author

Although the implementation can be improved (e.g some alternatives to not maintain a whitelist), I believe that there is consensus in the community and evidence from other ecosystems that royalties are a necessary feature.

@Tenancio
Copy link
Contributor

Although the implementation can be improved (e.g some alternatives to not maintain a whitelist), I believe that there is consensus in the community and evidence from other ecosystems that royalties are a necessary feature.

I don't think anyone is arguing the need for royalties but this CIP seems to have too many flaws to be implementable. Surely the best course of action is to have marketplaces enforce royalties through their smart contracts rather than through continuous monitoring of the blockchain? It shouldn't be too hard to add the royalty address and percentage into the datum of the smart contract listings and therefore enforce that the correct royalties are paid. This would also solve the issue of external marketplaces that use the same contract as it would force them to pay royalties also without the need for the transaction to be signed by the original marketplace.

Whilst this doesn't stop a 0% royalty marketplace from existing, it would at least stop bad actors bypassing the royalties on trustworthy marketplace contracts until a true on-chain solution is possible.

@nullhashpixel
Copy link

Although the implementation can be improved (e.g some alternatives to not maintain a whitelist), I believe that there is consensus in the community and evidence from other ecosystems that royalties are a necessary feature.

There is probably no doubt that royalties are a useful feature, I'm just concerned that the protocol is not the right place to implement them. When speaking of evidence from other ecosystems, it should also has to be mentioned that similar features (in this case implemented in the token SCs) have also been abused a lot e.g. as "sales tax" for fungible tokens as integral part of many ponzinomics.

It is also not always clear if a certain transaction is a purchase, enforcing royalties on non-purchase transactions can kill new innovative business ideas.

@klarkc
Copy link

klarkc commented Nov 17, 2022

I would like to see a real world example where a NFT is used in this way ( with a SC ensuring royalties payment ), do we have any? I tend to agree that this is the validator job, not the protocol.

@MartinSchere
Copy link
Author

Whilst this doesn't stop a 0% royalty marketplace from existing, it would at least stop bad actors bypassing the royalties on trustworthy marketplace contracts until a true on-chain solution is possible.

This is exactly what we are looking for. What could be the "true on-chain solution"?

Spending policies? Freezing policies? If so, then we would like this CIP to be the place to discuss it.

@alessandrokonrad
Copy link
Contributor

So the watcher will reference the UTxO and immediately render the NFT useless, before anyone is able to buy.

Since the actual user token is not burned, I don't think it will stop anyone from buying/selling these assets. Maybe because metadata are cached for a few hours so people can't even see that it's invalid. In general I think explaining someone this concept of reference NFT and user NFT is way too difficult. As long as they hold something in their wallet they think they own it.

@Tenancio
Copy link
Contributor

This is exactly what we are looking for. What could be the "true on-chain solution"?

Spending policies? Freezing policies? If so, then we would like this CIP to be the place to discuss it.

To be honest I'm not sure there is a one solution fits all approach to enforcing royalties on Cardano. I think it is up to the marketplaces to enforce the royalties but in a decentralised way, i.e by enforcing it in the smart contract validator. If a marketplace chooses not to do this then they should be quickly abandoned by the community.

@alessandrokonrad
Copy link
Contributor

If a marketplace chooses not to do this then they should be quickly abandoned by the community.

That's how I see it too. The only way to enforce it is through social pressure and have the rules embedded in each marketplace contracts.

@BlakeBrown
Copy link

If a marketplace chooses not to do this then they should be quickly abandoned by the community.

That's how I see it too. The only way to enforce it is through social pressure and have the rules embedded in each marketplace contracts.

We've already seen that social pressure isn't enough on other blockchains. What makes you think it'd be any different on Cardano?

@BlakeBrown
Copy link

It shouldn't be too hard to add the royalty address and percentage into the datum of the smart contract listings and therefore enforce that the correct royalties are paid.

This is already what we're doing on JPG Store. It's not enough to protect creators royalties. There will be competition that pops up which doesn't honor the existing CIPs.

@BlakeBrown
Copy link

Whilst this doesn't stop a 0% royalty marketplace from existing, it would at least stop bad actors bypassing the royalties on trustworthy marketplace contracts until a true on-chain solution is possible.

This is exactly what we are looking for. What could be the "true on-chain solution"?

Spending policies? Freezing policies? If so, then we would like this CIP to be the place to discuss it.

This is the purpose of this CIP - a truly decentralized approach to enforcing royalties. I think we should steer this discussion back towards that goal. This isn't the place to ask why we can't just "rely on marketplaces to do the right thing", if you're curious about that I'd encourage you to read the threads below and discuss in the NFT guild Discord: discord.gg/9ZQXs8Xu2q

https://twitter.com/PuffYachty/status/1584277265311240192?s=20&t=7HYUHIAhkvyqtue0lUUk_A
https://twitter.com/kemos4be/status/1579314353895264256?s=46&t=ej4nMqcR5kLq1HV_dqSzpQ
https://twitter.com/MagicEden/status/1581101016686399491?s=20&t=YT9Q_aBwyLSxymjoj8HFCg

@diarpiiiii
Copy link

We've already seen that social pressure isn't enough on other blockchains. What makes you think it'd be any different on Cardano?

Because social pressure on Cardano is (or at least can be) a wildly different entity. Along those lines, and to invert your question, what makes you assume the experiences and trajectory of Magic Eden and Open Sea will be the same for Cardano? This entire problem derives from a choice by one marketplace on Solana to change their approach to royalties, and then go off on a crusade to come back with an on-chain solution for their ecosystem.

This history of NFTs on Cardano has been much different, with CIP-27 offering an on-chain solution to royalties before the implementation of smart contracts. This can be applied in single-asset sales, as well as bundle sales with different policy IDs and royalty percentages for each individual asset. This is, and has been, the configuration on some marketplaces in Cardano since last year. This CIP is not the be-all-end-all of royalties on Cardano, but could be, nevertheless, a meaningful starting place for future development. There's lots of fun things we still need to take care of. For example, solutions are needed for sales conditions where a royalty is stipulated, but payments are done via native assets. But problems like those are what make Cardano, Cardano. Ultimately, I feel we should not assume the past performance of other ecosystems is a guarantee of future results in our own.

@Tenancio
Copy link
Contributor

We've already seen that social pressure isn't enough on other blockchains. What makes you think it'd be any different on Cardano?

Perhaps it isn't but this isn't the way to go about enforcing the royalties. There are major flaws in this idea that would be an incredible hinderance to innovation on the chain. How do you decide who is a good and a bad actor? How do you then keep track of every smart contract address as more and more marketplaces and dapps become available and similarly how will you store those addresses when the list gets too big to store in transaction datums? How do you ensure the marketplace is punished and not the user? How do you define the rules of when royalties should be paid?

There are so many questions that need to be sorted IMO before a CIP like this can even be considered. Lets take a step back and approach this in the way Cardano is renowned for - research backed and right first time. There is no need to rush into this when the problem hasn't even affected us yet.

This is already what we're doing on JPG Store. It's not enough to protect creators royalties. There will be competition that pops up which doesn't honor the existing CIPs.

If you are already doing this then why is the jpg signing key required?

@thaddeusdiamond
Copy link
Contributor

thaddeusdiamond commented Nov 18, 2022

I'm not sure what kind of research is needed here, but I have a dog in this fight as a creator: I want to make sure no one circumvents my royalties.

I view this proposal as a starting point and people should propose alternatives. At the very least there are three use cases that need to be covered:

  1. Wallet-to-wallet transfers (no royalty required)
  2. Direct-trade escrows (e.g., trading tent) - open to whether or not royalties are required since the currency is a barter/native asset
  3. Marketplaces - royalties must be enforced and bad actors must be punished or good actors must be rewarded

Gordon Goner (pseudonymous founder of BAYC) summarizes this well in a blog post. But there are open questions for Cardano specifically:

  1. Do we need to protect new buyers who will not know about these standards and might be susceptible to ending up on a zero-royalties site accidentally?
  2. Should there be a mechanism for restitution once a zero-royalty marketplace has come in the picture?
  3. Should this be enforced at the token level or the protocol level (e.g., through "watcher nodes")?
  4. How do we allow for backward compatibility across our (now 2) existing NFT standards?

Guys, what I do know is that allowing marketplaces to enforce this through the smart contracts is not enough and the day will come when some bad actor circumvents this. When that happens, I and other creators will stop developing for Cardano. Reattaching this photo on what a detriment this would have

Ffx7xneXwAEImUf

Let's not argue over "if" this will happen. If there are more appropriate forums for this or other considerations that need to be taken into account let's do that. I'm not willing to wait until someone starts ripping me off to try to put a bandage on it.

@Tenancio
Copy link
Contributor

I'm not sure what kind of research is needed here, but I have a dog in this fight as a creator: I want to make sure no one circumvents my royalties.

I think we all agree that we don't want royalties circumvented, the issue is implementing this correctly first time.

I view this proposal as a starting point and people should propose alternatives. At the very least there are three use cases that need to be covered:

  1. Wallet-to-wallet transfers (no royalty required)
  2. Direct-trade escrows (e.g., trading tent) - open to whether or not royalties are required since the currency is a barter/native asset

I think royalties should not apply here if it is a straight trade of native assets since there is no "value" being exchanged.

Open questions:

  1. Do we need to protect new buyers who will not know about these standards and might be susceptible to ending up on a zero-royalties site accidentally?

IMO absolutely. If mainstream adoption is ever going to happen, new users cannot be caught out by a nuance they don't even know about. This is why I am so strongly against punishing the user by making the NFT worthless.

  1. Should there be a mechanism for restitution once a zero-royalty marketplace has come in the picture?
  2. Should this be enforced at the token level or the protocol level (e.g., through "watcher nodes")?

Both good questions that require a full discussion.

Guys, what I do know is that allowing marketplaces to enforce this through the smart contracts is not enough and the day will come when some bad actor circumvents this. When that happens, I and other creators will stop developing for Cardano. Reattaching this photo on what a detriment this would have

You are right it is not enough for the long term but in the short term it is. We are at such an early stage that user sentiment towards a marketplace is everything. We haven't reached the point of having a Cardano equivalent of OpenSea and so it is very easy for users to switch marketplaces to the most reputable. There will almost always be a way around royalties no matter what, we just need to find they way that means 99% of people abide them. As for stopping developing on Cardano, piracy is rampant in the entire tech sector despite it supposedly having strong consequences but that doesn't stop creators from creating because 99% of people follow the 'rules'.

Let's not argue over "if" this will happen. If there are more appropriate forums for this or other considerations that need to be taken into account let's do that. I'm not willing to wait until someone starts ripping me off to try to put a bandage on it.

Likewise I'm sure you don't want to be in a situation where people are put off buying your NFTs because of the possibility of it being made worthless all because they sent it to a contract that wasn't whitelisted. This is why the correct action needs to be taken rather than rushing into the first solution that comes to mind.

@thaddeusdiamond
Copy link
Contributor

thaddeusdiamond commented Nov 18, 2022

I'm not sure what kind of research is needed here, but I have a dog in this fight as a creator: I want to make sure no one circumvents my royalties.

I think we all agree that we don't want royalties circumvented, the issue is implementing this correctly first time.

I view this proposal as a starting point and people should propose alternatives. At the very least there are three use cases that need to be covered:

  1. Wallet-to-wallet transfers (no royalty required)
  2. Direct-trade escrows (e.g., trading tent) - open to whether or not royalties are required since the currency is a barter/native asset

I think royalties should not apply here if it is a straight trade of native assets since there is no "value" being exchanged.

Open questions:

  1. Do we need to protect new buyers who will not know about these standards and might be susceptible to ending up on a zero-royalties site accidentally?

IMO absolutely. If mainstream adoption is ever going to happen, new users cannot be caught out by a nuance they don't even know about. This is why I am so strongly against punishing the user by making the NFT worthless.

  1. Should there be a mechanism for restitution once a zero-royalty marketplace has come in the picture?
  2. Should this be enforced at the token level or the protocol level (e.g., through "watcher nodes")?

Both good questions that require a full discussion.

Guys, what I do know is that allowing marketplaces to enforce this through the smart contracts is not enough and the day will come when some bad actor circumvents this. When that happens, I and other creators will stop developing for Cardano. Reattaching this photo on what a detriment this would have

You are right it is not enough for the long term but in the short term it is. We are at such an early stage that user sentiment towards a marketplace is everything. We haven't reached the point of having a Cardano equivalent of OpenSea and so it is very easy for users to switch marketplaces to the most reputable. There will almost always be a way around royalties no matter what, we just need to find they way that means 99% of people abide them. As for stopping developing on Cardano, piracy is rampant in the entire tech sector despite it supposedly having strong consequences but that doesn't stop creators from creating because 99% of people follow the 'rules'.

To be clear when I say "developing" I mean doing stuff with my entire Wild Tangz community. It's not a threat, I am just trying to drive home one project creator's perspective. I am not sure how tech applies here, but if artists weren't paid by Spotify they would pull their music and go to court to enforce licensing. This is a decentralized ecosystem, but we have to recognize that without royalties communities and artists will disappear quickly.

Let's not argue over "if" this will happen. If there are more appropriate forums for this or other considerations that need to be taken into account let's do that. I'm not willing to wait until someone starts ripping me off to try to put a bandage on it.

Likewise I'm sure you don't want to be in a situation where people are put off buying your NFTs because of the possibility of it being made worthless all because they sent it to a contract that wasn't whitelisted. This is why the correct action needs to be taken rather than rushing into the first solution that comes to mind.

Agree I don't want to rush it, I just don't want to waste time questioning the premise either.

@rphair rphair changed the title CIP-0079? | Enforceable royalties CIP-???? | Enforceable royalties Nov 18, 2022
@rphair
Copy link
Collaborator

rphair commented Nov 18, 2022

@MartinSchere it's great to see that this is generating so much interest, but that also creates more of a problem with assigning a CIP number that's not guaranteed yet (since people often discuss on social networking & create unmaintainable references).

Can you remove the number 79 from the document title (and header preamble, when you create one), and rename the directory of your README from CIP-0079 to something non-numerical like CIP-enforceable-royalties? 🙏

edit, p.s.: when you have the directory moved, can you also link to the README from the top comment in this PR, so people can jump into the discussion more easily? 😎

@clayinvaders
Copy link

@MartinSchere I like the idea of enforceable royalties, but not the punishment part.

I think that this standard need to define something that includes:

  • Mints with a multi-sig approach instead of smart contracts
  • NFT Marketplaces with a multi-sig approach instead of smart contracts
  • Projects with their own Marketplaces

How do you think you are going to track addresses? marketplace addresses could change continuously and make it impossible to track.

Why not define a holders-centered standard, where users that buy/sell NFTs in Good Actors Marketplaces receive an extra token/future royalties/whatever.

Royalties of future sales look like a nice idea to explore.

Change from an enforcement/penalty to an enforcement/reward approach.

@MartinSchere
Copy link
Author

I think that we should not abandon the discussion.

This CIP could be rewritten with a completely different approach (e.g "freezing policies"?), and we are happy to see creative suggestions.

What is not acceptable is to do nothing about the issue, waiting for a zero-royalty marketplace to enter the space and destroy the ecosystem, as evidenced in other spaces.

@meltedplastic
Copy link

I think royalties should not apply here if it is a straight trade of native assets since there is no "value" being exchanged.

Yes, NFT >< NFT trades should not be accounted for.
Whenever ₳ is included, sure. That's how we've approached it in Tent.

What about if I buy an NFT with $yummi? $yummi royalties to the Project?

@Tenancio
Copy link
Contributor

What if you had a seed in the contract, and we autenticate with a generated number using the same seed with this contract to change the datum with the new owner of the token, and in this process we pass the ADA in accordance to the royalties? The problem is how to know the NFT price at the tx moment, for this one could use a trusted oracle

We could have a listing of trusted NFTs (the ones who are paying royalties), and the market can regulate itself this way

The idea of the seed is to have this "counter", a "number generator" that sync's with NFT transactions. One must pay all tx royalties to "unlist" some NFT.

I believe this also aligns with #357

If I understand it correctly, this seems like an overly complicated way of simply enforcing royalty payments in a marketplace contract and still relies on trusting the marketplaces to do so.

@klarkc
Copy link

klarkc commented Nov 18, 2022

@Tenancio yes, actually it really does not matter if it's a counter, just an oracle, many oracles, in the end is up to the marketplace to go with the contract.

I like the idea of having a listing so buyers can check if an NFT is paying royalties before buying, but I don't like the idea of forcing anyone to pay royalties, this sounds like an invasion of the NFT owner's property rights.

@Tenancio
Copy link
Contributor

Tenancio commented Nov 18, 2022

I have a potential proposal.

Rather than maintaining a whitelist of allowed smart contracts, we have an on chain governance contract that maintains a blacklist of untrustworthy sites via storing tokens of a specific policy/asset id in a locked smart contract address. Wallet developers should standardise a check on these tokens before connecting to a site and not allow a user to connect their wallet if the site is blacklisted.

Advantages:

  • User is not punished by using 0% royalty marketplaces without knowing.
  • Almost completely decentralised (requires wallets to conform to the standard)
  • Doesn't require creators to maintain a whitelist of allowed contract addresses
  • Increases cost of bypassing the restriction since buying new domains costs money.

Disadvantages:

  • Requires all wallets to implement the standard (easily doable though)
  • Will not affect Cardano-CLI or other Plutus scripts from interacting with contracts from blacklisted sites
  • Governance contract would need to be developed, audited and deployed which will take time.
  • Voting on blacklisting a site would also take time to allow more people to vote.
  • How do you manage the voting? 1 wallet 1 vote? Ada proportional?

I'm not a wallet developer so I can't say how easy this is to implement but I can't imagine it would be a huge job (feel free to correct me). I also think that marketplaces should still enforce royalties in their contract rather than in the frontend.

There are of course ways around this but it seems like it would certainly discourage most users from using the blacklisted sites.

@Tenancio
Copy link
Contributor

@Tenancio yes, actually it really does not matter if it's a counter, just an oracle, many oracles, in the end is up to the marketplace to go with the contract.

I like the idea of having a listing so buyers can check if an NFT is paying royalties before buying, but I don't like the idea of forcing anyone to pay royalties, this sounds like an invasion of the NFT owner's property rights.

I'm still not sure I understand the need for an oracle. But I do kind of agree with the fact we can't FORCE anyone to pay the royalties. They are opt-in after all. But I do think we should make it more difficult to bypass paying royalties.

@elRaulito
Copy link

I am late in the convo but maybe I am lost,

  • Why can't each smartcontract marketplace regulate the royalties in the validator itself?
  • In case a marketplace is doing 0 royalties listing blockchain would show in the transactions

instead of watchers I would prefer a script that mint "rewards" for good actors, but what are the benefits for this? Maybe all marketplaces could create collections purchasable with these tokens?

Instead of punish the bad actors, incentivize the good ones

I think CIP68 helps a lot giving power to creators to define or update the royalties address of their collection

But what in case of rugpulls? should they still be in control of their royalties? Decentralization works in both ways

@Tenancio
Copy link
Contributor

  • Why can't each smartcontract marketplace regulate the royalties in the validator itself?

It can and imo should.

  • In case a marketplace is doing 0 royalties listing blockchain would show in the transactions

Indeed it would yes but that doesn't stop them doing it.

instead of watchers I would prefer a script that mint "rewards" for good actors, but what are the benefits for this? Maybe all marketplaces could create collections purchasable with these tokens?

How would you define a good actor in a decentralised way? And like you say, what would the benefit be?

But what in case of rugpulls? should they still be in control of their royalties? Decentralization works in both ways

Interesting point, I think in the context of the on-chain governance blacklist I proposed above you could have another type of list for "blacklisted" NFT policies. Tokens can still be sold normally but marketplaces can check if the project is blacklisted and thereby allow ignoring the royalties.

@BlakeBrown
Copy link

Rather than maintaining a whitelist of allowed smart contracts, we have an on chain governance contract that maintains a blacklist of untrustworthy sites via storing tokens of a specific policy/asset id in a locked smart contract address. Wallet developers should standardise a check on these tokens before connecting to a site and not allow a user to connect their wallet if the site is blacklisted.

This is an interesting idea, but has its own set of pros/cons. The main con I see is that it's another form of centralization and requires wallets to conform to the standard. Even if we get all wallets on the same page, there's also nothing stopping someone from creating a new wallet which doesn't conform.

@elRaulito
Copy link

Rather than maintaining a whitelist of allowed smart contracts, we have an on chain governance contract that maintains a blacklist of untrustworthy sites via storing tokens of a specific policy/asset id in a locked smart contract address. Wallet developers should standardise a check on these tokens before connecting to a site and not allow a user to connect their wallet if the site is blacklisted.

This is an interesting idea, but has its own set of pros/cons. The main con I see is that it's another form of centralization and requires wallets to conform to the standard. Even if we get all wallets on the same page, there's also nothing stopping someone from creating a new wallet which doesn't conform.

Indeed, I could use cardano-cli and that's it, bypass the wallet

@BlakeBrown
Copy link

For reference, this CIP follows in the footsteps of the same approach that OpenSea is taking: https://github.com/ProjectOpenSea/operator-filter-registry

Rather than a whitelist approach, they went with a blacklist. This might be easier to maintain overtime if we imagine that more marketplaces will support royalties than those that don't. This eliminates a barrier to entry for new entrants.

This was clearly effective, as it led to the largest 0% royalty marketplace on ETH switching course and supporting royalties today.

@Tenancio
Copy link
Contributor

This is an interesting idea, but has its own set of pros/cons. The main con I see is that it's another form of centralization and requires wallets to conform to the standard. Even if we get all wallets on the same page, there's also nothing stopping someone from creating a new wallet which doesn't conform.

I agree, the idea isn't perfect but it could be along the right lines. I think centralisation here isn't so much of an issue seeing as it would need be an open-source, audited contract that anyone could interact with to start a backlist vote etc. meaning it should be far less centralised than I fear this proposal would end up being. But you are right, it is still possible to bypass it as I eluded to which could be conceived as an issue.

Indeed, I could use cardano-cli and that's it, bypass the wallet

Yep exactly, this is the main downfall of the approach.

Rather than a whitelist approach, they went with a blacklist. This might be easier to maintain overtime if we imagine that more marketplaces will support royalties than those that don't. This eliminates a barrier to entry for new entrants.

This is exactly what I was trying to propose, a whitelist solution would be far harder to maintain than a blacklist. The main issue with porting this over to Cardano is that native assets are not bound by smart contracts so they can be sent a blacklisted address either way if there is no intervention from a front end or wallet and I am still against punishing NFT owners instead of the marketplaces other than cases where it is absolutely certain the owner is deliberately attempting to avoid royalties to make a few extra Ada.

@klarkc
Copy link

klarkc commented Nov 18, 2022

From descentralization standpoint, having a governance system is really better than having whiltelisting in creators hands? Who is gonna vote for blacklisting, based on what criteria? A governance system in hands of a few players could be potentially worse than giving decision power to the policy creator. Having the majority of the voting tokens basically means that one player could subvert the governance objectives with anti-competitive behavior

@Tenancio
Copy link
Contributor

From descentralization standpoint, having a governance system is really better than having whiltelisting in creators hands? Who is gonna vote for blacklisting, based on what criteria, a governance system in hands of a few players could be potentially worse than giving decision power to many policy creators. Having the majority of the voting tokens basically means that one player could subvert the governance objectives with anti-competitive behavior

The reason I said that was because with a creator-defined whitelist approach many creators will want a go-to repository with a majority of the trusted marketplaces and contracts. Who controls that and what stops them from altering it as they wish? With an on-chain governance at least everyone will be able to have a say and so it wouldn't be in the hands of a few players. Obviously the voting mechanism would need to be carefully designed to mitigate the risk of a single entity owning a majority. Something like quadratic voting could work in this case.

Perhaps the two could be combined, have a global on-chain blacklist but allow policy creators to override this in their royalty tokens or add extra addresses to the blacklist. This would allow more freedom to creators to decide what their tokens can/can't be used for.

@klarkc
Copy link

klarkc commented Nov 18, 2022

Oh maybe better: Allow the creator to override the governance entity of their tokens, something like "my minting policy is following whitelisting/backlisting of this governance entity".

@Tenancio
Copy link
Contributor

Tenancio commented Nov 18, 2022

Oh maybe better: Allow the creator to override the governance entity of their tokens, something like "my minting policy is following whitelisting/backlisting of this governance entity".

I like this a lot. Still need to figure out what blacklisting/whitelisting means though

@klarkc
Copy link

klarkc commented Nov 18, 2022

I like this a lot. Still need to figure out what blacklisting/whitelisting means though

I was thinking in leaving the choice open, (blacklist or whitelist), and let the governance entity define what each word means and addition / removal criteria. The entity would suggest the application / specification for wallet implementations, this way the creator will use his interpretation of what is fair and choose it accordingly.

Of course the most logical path is to use blacklist to remove bad actors and whitelist as endorsement.

@Tenancio
Copy link
Contributor

I like this a lot. Still need to figure out what blacklisting/whitelisting means though

I was thinking in leaving the choice open, (blacklist or whitelist), and let the governance entity define what each word means and addition / removal criteria. The entity would suggest the application / specification for wallet implementations, this way the creator will use his interpretation of what is fair and choose it accordingly.

Of course the most logical path is to use blacklist to remove bad actors and whitelist as endorsement.

My meaning was, what will a whitelist/blacklist do? Punishing users should still be off the table but how will the whitelist/blacklist be enforced?

@MagicApes
Copy link

I have a lot of problems with what is being discussed here. this smells just like the fight we have had in the USA for the last decade with manufacturers over right to repair. If someone owns something it is their right to do with it what they please, without conditions being forced upon it.

Same thing here. if someone owns the NFT it is their choice to list it where they want or sell it how they want. If they choose to sell it through a platform that supports royalties, then Awesome! and if not, that is their choice. Crypto, and specifically Cardano is all about a free market ecosystem. If we don't want a marketplace that doesn't support royalties to come in and overtake the other marketplaces then the current Marketplaces need to provide a product that is so far superior to the others that the users choose it.

JPG store literally gained their market share by supporting Royalties. and in doing so, the NFT creators pushed their communities to it and away from CNFT.io. This CIP is wrong because, JPG store trying to do this would have been like cnft.io trying to create a CIP to ban royalties back in Aug. of 21. It isnt how the free market works.

Now, there is a different story for a new marketplace aggregating other marketplaces listings and then not paying royalties. But, I believe we already have a way to fix that. Can't the Marketplace use the Royalty system laid out in CIP-27 to build the SC in a way that forces the royalties to be paid automatically on each transaction when the buyer interacts with the SC? basically as part of the SC it finds the 777 tag on the policy ID and then uses the address and percentage in that to automatically send the royalties? that way even if an aggregator uses the listings from jpg.store, the SC automatically forces it to pay royalties?

If that can be done, it makes way more sense, because then if the owner posts on JPG.store, they know the royalties will get paid no matter what, and it still doesnt take away their free choice whether or not to post it on a royalty marketplace.

@MagicApes
Copy link

Also, We could reach out to the wallets to implement a way to say to the buyer "this NFT creator requests a X% royalty, but the transaction is excluding that. Do you wish to include the royalty?" then the person can choose to pay it..

@klarkc
Copy link

klarkc commented Nov 18, 2022

how will the whitelist/blacklist be enforced?

It could be enforced in the protocol, but I believe it should not be enforced, only recommended.

@nullhashpixel
Copy link

Now, there is a different story for a new marketplace aggregating other marketplaces listings and then not paying royalties. But, I believe we already have a way to fix that. Can't the Marketplace use the Royalty system laid out in CIP-27 to build the SC in a way that forces the royalties to be paid automatically on each transaction when the buyer interacts with the SC? basically as part of the SC it finds the 777 tag on the policy ID and then uses the address and percentage in that to automatically send the royalties? that way even if an aggregator uses the listings from jpg.store, the SC automatically forces it to pay royalties?

It's not possible to read metadata like the 777 tag directly, but there are for sure ways to implement it into a smart contract by the marketplace doing one transaction setting the datum of a uniquely defined UTXO for each collection.

Not sure if this is actually the case, did not look at their contract and seen contradicting statements, but: if it's possible to build a valid buy transaction for existing listings, circumventing royalties, this would simply be a bug/shortcoming of their code.

@michaelpj
Copy link
Contributor

It sounds like there's a lot of interest in defining the problem, and not much agreement about what the solution should look like. Perhaps it would be good for the participants here to collaborate on writing a CPS? Then we can try and get people on the same page on what the different requirements that people care about are, what the use cases are, etc.

@Tenancio
Copy link
Contributor

It sounds like there's a lot of interest in defining the problem, and not much agreement about what the solution should look like. Perhaps it would be good for the participants here to collaborate on writing a CPS? Then we can try and get people on the same page on what the different requirements that people care about are, what the use cases are, etc.

I agree. Many of us feel that there is no problem necessarily however I am happy to take part in a discussion should the other part of the community feel a solution to enforceable royalties is required and I think a more specific scope should be defined on what we are trying to solve. i.e should all royalties be enforced or should there be optional royalties? What counts as a transaction where royalties should be applied? and more.

I was particularly intrigued to read #336 and the solution proposed (and rejected) in there and I think this could prove to be a valuable starting discussion.

@rphair rphair mentioned this pull request Nov 30, 2022
@KtorZ
Copy link
Member

KtorZ commented Nov 30, 2022

As per today's editor discussion, we'll postpone assigning a number to this proposal because it seems like it would deserve being framed as a CPS first (given the numerous comments and areas of debates regarding the definition of the requirements themselves).

Waiting for @MartinSchere to comment on this.

@rphair
Copy link
Collaborator

rphair commented Nov 30, 2022

also @MartinSchere - thanks for removing the inappropriate number 79 (which now belongs to what will be a very popular CIP) but you have left a redundant copy of your README there in your branch: can you delete the first of these please?

  • CIP-0079/README.md
  • CIP-enforceable-royalties/README.md

@MartinSchere
Copy link
Author

Hello!

Apologies for the delayed response.

I agree, we should discuss this as a CPS.

@rphair I removed the README from the CIP-0079 folder.

@MartinSchere
Copy link
Author

Should we close this in the meantime?

@rphair
Copy link
Collaborator

rphair commented Nov 30, 2022

@MartinSchere I don't think it needs to be closed, since leaving it open would make it easier for discussion points to insert into the new CPS so they can be followed by existing reviewers. It's only been a Draft so far, so you can just mark it as Ready for review when it's re-posted in your branch as a CPS with the CIP document removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.