-
Notifications
You must be signed in to change notification settings - Fork 318
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
Conversation
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. |
Hey Martin, This is definitely a problem worth solving. |
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. |
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. |
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:
|
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. |
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. |
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. 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. |
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. |
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. |
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. |
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. |
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. |
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. |
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? |
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. |
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 |
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. |
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.
If you are already doing this then why is the jpg signing key required? |
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:
Gordon Goner (pseudonymous founder of BAYC) summarizes this well in a blog post. But there are open questions for Cardano specifically:
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 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. |
I think we all agree that we don't want royalties circumvented, the issue is implementing this correctly first time.
I think royalties should not apply here if it is a straight trade of native assets since there is no "value" being exchanged.
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.
Both good questions that require a full discussion.
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'.
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. |
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.
Agree I don't want to rush it, I just don't want to waste time questioning the premise either. |
@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 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? 😎 |
@MartinSchere I like the idea of enforceable royalties, but not the punishment part. I think that this standard need to define something that includes:
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. |
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. |
Yes, NFT >< NFT trades should not be accounted for. What about if I buy an NFT with $yummi? $yummi royalties to the Project? |
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. |
@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 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:
Disadvantages:
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. |
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. |
I am late in the convo but maybe I am lost,
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 |
It can and imo should.
Indeed it would yes but that doesn't stop them doing it.
How would you define a good actor in a decentralised way? And like you say, what would the benefit be?
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. |
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 |
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. |
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.
Yep exactly, this is the main downfall of the approach.
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. |
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 |
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. |
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 |
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? |
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. |
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.. |
It could be enforced in the protocol, but I believe it should not be enforced, only recommended. |
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. |
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. |
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. |
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
|
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. |
Should we close this in the meantime? |
@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. |
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):
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.
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
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):
We encourage and appreciate any feedback.