CIP - Royalties

Developers CIPs
22

just replied on github with the following (and I have demonstrated this very clearly I thought?):

– from github:
"Hmm, not sure how to clarify better. If I have a token with a policy ID, and I present to you the slot height and my policy keyhash, you can validate that the policy ID I presented HAD TO BE minted by my keyhash/slot height combo. So if I also then present the slot height of any other token I minted using that policy keyhash, you can validate that indeed you get the same policy id when running my keyhash/thattoken’s slot height through the cardano-cli transaction policyid command. So if I can present a token that displays it’s own slot height AND the slot height of the token I aim to set royalty over, along with my 1 keyhash which was used to mint BOTH token policies, you can confirm that since I am controlling the token with the policyid which is derived from the keyhash, then the target policy which you can confirm HAD to be derived from the SAME keyhash, is indeed also mine.

So the royalty token has a big sign saying "here’s the data to confirm that I was minted by the same policy keyhash as the target, therefore the royalty I’m setting is set by the owner of the policy keyhash signing key, as demonstrated in my own policy id derived from this data I’m holding up on a “sign” (metadata is the “bilboard” advertising this and giving others a way to validate my rights to the policy when combined with the royalty control token’s own policy id seen at the utxo of the smartcontract)

I don’t know how to explain it clearer sorry. But I have performed the steps in creating a proof of this concept on testnet. Given the royalty control token I minted, you can see that the metadata shows the params of how that control token was minted, the policy ID is a derivation of my policy keyhash and locking slot…and using that SAME policy keyhash you can then also prove that the target policy I’m setting royalty over, definitively was minted using that SAME policy keyhash which you can prove I own because the control token’s policy id is a result of the keyhash and slot height for it. What am I missing here? I almost feel like I’m being trolled tbh, but don’t want to sound mean if there is truly a miscommunication. :)"

23

Something I’ll do maybe today, is mint a token attempting to override the one locked in the smartcontract, from a different policy keyhash to demonstrate.

But conceptually it would look like this:

malicious person wants to override the rate and payout addr. They mint a token with the two policy script datasets, “self” and the target policy. They put MY keyhash into the metadata for BOTH of these datasets. When a validator tries to take MY keyhash and slot lock height for “self”, it will come up with a DIFFERENT policy ID then the royalty control token has at the utxo = failed validation. There is no way around this besides the malicious person stealing my policy signing key.

Once that “phase” of validation does pass, then the inquiring market would try the same over the target, to ensure that MY keyhash ALSO can be used to generate the matching policy of the target. So BOTH this control token’s own policy ID seen at the utxo AND the target policy id seen in the Datum of the utxo, must share the exact SAME KEYHASH for a full validation that whoever deposited this control token either legitimately owns the policy signing key from which the target was minted, or is in possession of that skey file somehow. There’s absolutely no way (to my knowledge) to otherwise mint newly minted royalty control token with a policy id which would be derived from and only from the policy skey holder.

Sure metadata can be faked, but the key to this is that the metadata has to validate against the actual royalty token’s own policy id on chain…if it can and if also the policy id of the target can validate against this same keyhash then the conclusion is defitiively: Both policies HAD TO HAVE been minted using the exact SAME keyhash/policy skey.

I hope that helps to clarify things! :slight_smile:

24

Nothing prevents them from creating a too high royalty with any implementation that I’m aware of, when they can mint themselves. An interesting idea would be to create a smartcontract which does the minting of this control token and limits the max royalty setting. And anyone providing a service or software that makes this minting easy with the correct metadata formatting etc, could do the same. Also, secondary markets can impose limitations if they would like to avoid this, but this is a different problem which I don’t see being solved by either the 777 type or this proposed more flexible control token.

As for after the fact, my suggestion is that when checking royalties locked at the SC, the marketplace may find multiple entries for a single policy because the creator may try to change it several times by minting new tokens to do so. The rule of thumb would be “always honor the lowest” so a creator can lower the royalty but not raise it unexpectedly. In general this seems again, like a different type of problem which neither solution really can control/mitigate if a creator just decides to do something like this in either implementation.

The primary purpose of this other “control” token I’m proposing for use, is to allow creators with a way to set royalties over any truly owned (they have the keys over the policytarget), in an agnostic-to-time-or-lock manner, while maintaining on-chain/transparent/and fully verifiable proof of ownership over the given target policy. So this would coexist with your original CIP is what I’m saying, it does not threaten it or undermine it, and perhaps could be an improvement on it! :slight_smile:

One more quick update: I’m going to add to this that the metadata contains the slot height at the time of minting the royalty control token. This helps users and secondary markets in two ways: allows the secondary market to filter by submission time, finding the “oldest” and “newest” if there are more than 2 submitted by a creator for making changes. This allows the user to make changes to their payout address or list of addresses. This could be critically important to teams with multiple recipients and terms that govern their qualification to receive royalties as one example. Secondary markets can also quickly compare any royalty % change attempts based on just 2, the first % they set and the last/latest one, and pick the smaller of the two, making this process more efficent.

So the disadvantages this proposed solution faces are ~equal to the current cip-0027 with the exception of creators modifying rewards in attempts to take all sales, in which case this is already possible in a less flexible way and seems to be something markets can easily mitigate in a competitive way, while we gain the following advantages:

  1. Royalty can be set over an owned policy id at any time, regardless if the creator forgot/didn’t know/was before cip-0027 and the policy they’d like to set royalties over is now locked. This mechanism being a “control” token is able to aleviate that issue entirely with exactly the same proof of ownership and validation.
  2. Modifications to payment addresses can be made and immediately “live” on the blockchain for secondary markets to “see” and honor
  3. Royalties can be lowered. The creator can also attempt to raise them, however the secondary markets who would need to implement the simple code functions to perform this new validation can always only honor the lowest % set.
  4. This makes use of the Always Fails plutus contract, which personally I think is just fantastic :slight_smile:

I hope I’m not stepping on any toes in presenting this idea and if this is the wrong place to discuss I can move the discussion elsewhere. However I really appreciate the challenge of explaining better you’re presenting me with!

Edit addition:
Two quick thoughts on the lines of “what if a creator goes rogue and suddenly ups the %”:

By giving artists the ability to do this, when they may not have known better before and it’s now locked, is of greater weight and value when abuse could easily be mitigated by a marketplace. If, for competitive advantage, a marketplace had a complex/centralized way for an artist to setup royalties over a locked/unroyatied policy, they would do it and they would mitigate the risks of abuse or attempts at taking 100% (rug pull) etc. So why not implement a solution that is decentralized and requires arguably less effort on the part of markets to adopt and mitigate?

Another thought is this: Say a creator sets a reasonable % and then goes rogue. It could be a standard that if you submit another Royalty Control token to the smartcontract, the only section you may modify is the “self” slot height of course (and policy id over the royalty control of course), the “controlslot” since it’s for when this new one was made, and the “addr” and that’s it. If a creator changes the %, the marketplace ignores that entirely. They can see which is the latest vs first by taking the “controlslot” value and comparing them both against each other and against the actual mint tx times of each Royalty Token (so the control slot value cannot be faked).

Again, what is gained in this is inclusion of anyone past, present, future who was ignorant or had someone helping them who didn’t know how or if about setting royalties etc…allows flexibility in their rollout for new projects…and very crucially allows for modification of the payout addresses. All while maintaining decentralized/onchain…and all while utilizing the fails plutus script!! :slight_smile:

Final thoughts/update:
To remain consistent and satisfy the parameters being employed by CIP-0027, it may be a reasonable approach to merge these two into a single implementation. The caveat would be the 777 token, if found with additional metadata particularly the “self” section, would be an indicator that this particular 777 also contains additional metadata possibly pertaining to a different (but provably owned) policy ID.

In this implementation design, the 777 token contains all the same metadata as the CIP-0027 plus additional as outlined in the readme at MintedWithLovelace/dapp-smartcontracts/global-registry at sandbox · MadeWithLovelace/MintedWithLovelace · GitHub

This “merge” of these two approaches also has the side-benefit of providing the policy script data onchain, for sites such as pool.pm to query, making this information decentralizedly transparent and easily available.

25

We’re getting reports from NFT buyers that they’d like to see the option for a minimum threshold below which they royalties aren’t paid - I think NFT authors would be willing to add that to their NFTs, if there were a standard on how to do it. Suggest adding to the 777 metadata a “threshold” field which takes a cutoff amount in ada or lovelace, below which royalties are not paid. I really think this would be positive for both creators and buyers in the Cardano NFT space.

26

The minimum would be 1.0 ada regardless because of the minutxo. Some markets could potentially hold aside less than that in a holding wallet; and once it reaches a threshold, they pay them out. That doesnt get around min utxo. But instead the market would have a database maintaining that info, and would have a master wallet to pay out from. I wouldnt expect anyone to do that though.

Anyways, long story short, minutxo is the minimum.

27

The current standard doesn’t seem to account for scenarios where the value of the NFT can not be known. For example when swapping 1 NFT for another or paying 100ada for 2 different NFTs. Were these scenarios deliberately left out? In any case, what should a marketplace/dApp that offer those types of the transaction do in this case? (case in point: https://atomic-swap.io/)

I see two possible solutions.

  1. Ignore the problem. if >90% of volume are simple 1 NFT from some ADA maybe it is not worth fixing for the amount of hassle.
  2. Fractionalize the NFT (simply mint 1000000 tokens representing the NFT and then set the number of decimals to 6) and pay the royalty using those tokens. So if your swap 1 NFT for another NFT perhaps 2-4 percentage points of the NFTs would be sent back to the original creators.
28

Since this is community driven, its not possible to cover every potential scenario. The CIP-27 is aimed to capture the most likely scenario of a cNFT of high value, being sold through the traditional channels. Bundled sales would tend to all be of the same asset type, so that should also be easy since all tokens from the same policy would share the same royalty. It might make sense to suggest that sites who offer bundled tokens, only allow bundling of tokens on the same policy, if a proper 777 token exists.

In regard to Atomic Swap, they should absolutely be implementing the 777 token lookup whenever a transaction occurs. I’ll try to contact that team to talk to them about it.

I’ve been trying to initiate the community discussion for a version 2 of CIP-27. But theres been very little participation. I’m probably going to set up a more decentralized approach to it. I’ll post in the Cardano Forums once I have that arranged.

29

Hi everyone, NFT guild is working on creating a CIP draft to improve on CIP 27 with multi-address royalty distribution and updateable royalty fees. You can see our current ideas here: Royalty CIP - Google Slides

We are planning to combine ideas 4 and 5 into a well-rounded CIP that would allow closed NFT policy with updateable royalty fees in a transparent way. We would love to hear some input from minting services and marketplaces on how open would you be to these ideas. I will soon post some more technical details (new token standards, ways of interacting etc.)

30

The majority of the people involved with writing v1 will be at cNFT Con. Why not plan to all meet at some point to refine a version 2?

1 Like