CIP-0027 | Standardization of royalties

This is quite abstract for me, would it be possible if you could provide examples in a CIP? In addition, I don't get how distribution of royalties would be made, for this one needs smart contract right?

This is quite abstract for me, would it be possible if you could provide examples in a CIP? In addition, I don't get how distribution of royalties would be made, for this one needs smart contract right?

This isnt meant to directly create royalties; at least not initially.  The expectation is that secondary markets would respect the tagging.  This is something the larger ones have all stated they plan to implement.  Without a standard defined, royalty payments would become fragmented, depending on which market an NFT is resold on.
As far as smart contracts, I dont believe there is any function that will be released in the Alonzo update.  So the tagging serves two purposes.  Allows for immediate adoption of royalties'.  And with the standard defined, a future update could provide a smart contract that honors the tags.  With the instruction set held off chain, the instructions can be updated if that becomes necessary.

Shouldn't that be an update proposal for CIP-0025 instead of a new CIP? CIP-0025 describes the NFT metadata format. So why not do a "royalty" key in there?

Shouldn't that be an update proposal for CIP-0025 instead of a new CIP? CIP-0025 describes the NFT metadata format. So why not do a "royalty" key in there?
Just a few thoughts:
If you do Offchain files, there should be a hashing about it, so you can see if it was modified. Offchain data may not be available at a certain point in time, how to handle that? I think i don't fully understand how this should work, when you buy an NFT from a platform you want to know the conditions about it, so an artists gets a percentage of that resale? Who decides how much, and who can change that? Is it possible to change it to 100% for the artist too just before a sale or after it was re-saled for 10 times? When you have an NFT in your wallet, you own it, you can do whatever you want with it, so sending it to another wallet (could be one that the owner already owns) would trigger a resale percentage? How to enforce payments to 3rd parties, by a court and sue someone?

All valid questions.  The changing of royalty percentage at a future date is a potential problem point.  Another option would be to require the aggregate royalty percent to be a static on chain tag.  This way the percentage cannot be changed in the future.
For hashing, I've been trying to think of a way to accomplish that.  The challenge is that the royalties payments are likely to change in the future.  At some point, people pass away, payment wallets can get lost or stolen, etc.  If we assume that someone will continue to earn royalties long after their gone, which is how it should be, we need a way to adjust things in the future.  And that future will would be long after the NFT's minting policy expires.  As silly as it sounds, I think having a central authoritative list of valid roylaties jsons would make good sense.  It doesnt all have to be handled by one entity.  You could look at it like SSL certificates.  As long as a source is considered to be valid, you can have several different curated repositories.  But with that said, it doesnt have to be required either.  If we're just using a shortened link to point somewhere, that somewhere can always be moved.
For moving an NFT between wallets, owned by the same person, there shouldnt be any problem.  Since these royalties would not be a blockchain smart contract function, they would only be triggered when an nft passes through a marketplace.  This of course means there are ways to circumvent them.  But thats not really all that different than royalties in the music industry today.  Any major player will respect the royalties, but there will always be cheaters.
To the last point of should this be part of the metadata standard proposal; it could be.  I just felt that this topic is worthy of its own proposal.  Especially since this one tag is going to take allot of community input to solidify.  And its important to have allot of eyes on it, because its something the community needs to agree upon so that future marketplaces coding would be able to identify this info.  And lastly, by having kept the instruction set offnet, the royalties standard could be updated.  I think its a bit too big of a topic to place it within the metadata standard proposal.

This latest update was the result of a large-scale roundtable of prominent individuals involved in the CNFT creation and marketplace space. The goal being to develop a community-accepted standard for how royalties should be handled as it relates to native assets in general on the Cardano blockchain and not exclusively to the CIP-25 NFT Metadata standard.
Having a separate JSON index to describe royalties and a procedure to create an ultimate and immutable source of truth protects both consumers and marketplaces from the "evolutionary" aspect of metadata for current tokens on chain and also allows us to minimize "ledger bloat" by needing to repeat static information in the metadata of individual tokens.
I, for one, am happy to accept and support this proposal.

Whats the plan to enforce such payment on the blockchain? Who is going against sales without royalties payments? How do you differ between private-to-private sales and private-to-own-private wallet transactions? There should be rules in the CIP how to enforce something like this on the chain, what do you do when the originally assigned payment-address gets lost by the artist and the artist is providing this information publicly? Do you still send %pct to the lost payment-address instead of a new working one?

Whats the plan to enforce such payments on the blockchain? Who is going against sales without royalties payments? How do you differ between private-to-private sales and private-to-own-private wallet transactions? There should be rules in the CIP how to enforce something like this on the chain, what do you do when the originally assigned payment-address gets lost by the artist and the artist is providing this information publicly? Do you still send %pct to the lost payment-address instead of a new working one?

At the moment, there doesnt appear to be a mechanism at the blockchain level to enforce these payments.  Thats why this becomes a community driven effort to be enforced through the marketplaces.  But it DOES create a framework, that a future generation smart contract could be modeled after.  The questions regarding how to differ between private party and ones own wallet are what makes enforcement through a smart contract an unlikely use case.  And there would be no way to prevent a private party sale and enforce a royalty.  But if done through the marketplaces, it should capture a substantial amount of exchanges.  The question about the wallet is one that was agreed upon through community discussion.  The key desire was to keep the entire instruction set on chain.  Therefore it becomes the burden of the asset creator to take this in to serious consideration, and understand the consequences of losing access to the royalties wallet.  There is a high likelihood that another type of business will be born out of this, where this 3rd party will manage royalties for CNFT creators.  This way there can be further breakdown of the royalties payments.

We should change the address to an nft, or two. People change wallets. You can send the nft to the new wallet, and not have to keep a wallet open for 30 years.

We should change the address to a nft. People change wallets. You can send the nft to the new wallet, and not have to keep a wallet open for 30 years.

That was one of the ideas proposed.  And it is an excellent idea.  But in the end, everyone agreed up the address as being the preferred method.  Its been suggested, but currently uncomfirmed, that a smart wallet may be able to provide this function.  So the payment address would feed to a smart contract, and the smart contract would manage the distribution(s) based on where this new NFT is placed.  It could even be a fungible that breaks down the payments for more people.
We think that the latest revision as is, represents the the best compromise for simplicity of implementation, best mitigation of bad actors gaming the system, and predictable results; with the bonus that smart contracts can be used downstream for whatever is desired after the royalties are forwarded.
I also see that a business could be born out of this, that is distinctly for managing royalties for artists.  They would use their clients master wallet.  Then do the distributions on the back end.  This obviously requires risk mitigation.  But every wallet does.

We should change the address to a nft. People change wallets. You can send the nft to the new wallet, and not have to keep a wallet open for 30 years.

That was one of the ideas proposed. And it is an excellent idea. But in the end, everyone agreed up the address as being the preferred method. Its been suggested, but currently uncomfirmed, that a smart wallet may be able to provide this function. So the payment address would feed to a smart contract, and the smart contract would manage the distribution(s) based on where this new NFT is placed. It could even be a fungible that breaks down the payments for more people.
We think that the latest revision as is, represents the the best compromise for simplicity of implementation, best mitigation of bad actors gaming the system, and predictable results; with the bonus that smart contracts can be used downstream for whatever is desired after the royalties are forwarded.
I also see that a business could be born out of this, that is distinctly for managing royalties for artists. They would use their clients master wallet. Then do the distributions on the back end. This obviously requires risk mitigation. But every wallet does.

Hope that answered your question  I'll close the comment.  But feel free to ask follow up questions if you have them.  Or you're welcome to reach out to me, and I can get a dialogue going between some or all of the parties involved with this proposal.

Reopening

Have you considered an array of pct / addr pairs instead of only a single pct and addr at the top level?
For example:
{ 	"777": {         [             {                 "pct": "0.1", 		        "addr": "<<first address>>"             },             {                 "pct": "0.05", 		        "addr": "<<second address>>"             }         ]	 	} }
This way if a piece of art (or music) was a collaboration, or if an artist wanted to also support a charity, this scheme could handle that as well.

Have you considered an array of pct / addr pairs instead of only a single pct and addr at the top level?
For example:
{ "777": { [ { "pct": "0.1", "addr": "<<first address>>" }, { "pct": "0.05", "addr": "<<second address>>" } ] } }
This way if a piece of art (or music) was a collaboration, or if an artist wanted to also support a charity, this scheme could handle that as well.

This was considered and rejected by the community leaders.  A Smart Contract could be the target for the royalty, so the separation of funds can be handled there.  There is also minimum UTxO's to consider.

The royalty token must be minted prior to creating any assets off the policy.  All markets will be instructed to look at the timeline of use on a policy.  Any assets minted prior to the royalty token would not be honored.

How is this going to work for a lot of existing projects?

The royalty token must be minted prior to creating any assets off the policy.  All markets will be instructed to look at the timeline of use on a policy.  Any assets minted prior to the royalty token would not be honored.

How is this going to work for a lot of existing projects?

It distinctly wont work for pre-existing projects.  It would be a rug pull for someone to attach a royalty to tokens that have already been purchased, when the buyer wouldnt have been aware that the cnft creator would add them at a later date.  Its for the same reason that only the first mint of the no name token will be honored.  It wouldnt be acceptable for the cnft creator to be able to change the royalties after the fact.

A few questions / points (sorry if it was already answered somewhere):

What would be a motivation for a project to set 5% royalty when everyone will be setting 20%?
Who is to decide what is absurd and what is not? 25%? 35%? 40%?
In 2021 we consider 50% is outrageous. In 2030 90% might be sensible - the more decentralized our world becomes, the less we'll be paying intermediates. Do not build a standard that will age badly.
What is 20% to the author?

A suggestion to the above points:
Use Sale Price %.
"royalty_fee": "0.01" - 1% of the sale value
When marketplaces sell the product they can always explain what are the fees:
Your sale is 100 ADA. Of which 1.5 ADA will go to the Author and 2 ADA to the marketplace
If you don't like our marketplace fee go to another marketplace
If you don't like the author's fee then do not trade their collection
This way we will NOT have a conflict between authors and marketplaces.
Regards,
Jev - CryptoDoggies

Deleted my previous comment as I misunderstood.
Please adjust the wording to remove potential misunderstandings for others:
The "pct" is the percentage of the SALE VALUE, and not of the fees the marketplace acquired.
It is different from what we're used to Discord fees where we get 20-40% of the fees which ends up being around 0.6% of the sale price.

I recommend using the same structure of 721
{
    "777": {
        "<policy_id>": {
            "pct": <float>,
            "addr": <string>
        }
    }
}

I recommend using the same structure of 721
{
    "777": {
        "<policy_id>": {
            "pct": <float>,
            "addr": <string>
        }
    }
}

The policy ID is being looked up because of the listing of an asset minted off of it.  Any site looking up the royalties are already looking for this policy ID, so it would be redundant.

Does cardano natively supports royalty split or plans to in the future? Can we get royaties distributed in multiple account of an nft sale?

The current implementation would have you setup a smart contract for that
part of the process. This only allows a single address for output.
On Fri, Sep 24, 2021, 6:10 AM Priyanshu Bindal @.***>
wrote:

Does cardano natively supports royalty split or plans to in the future?
Can we get royaties distributed in multiple account of an nft sale?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/116#issuecomment-926509588,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANNWZH6HANSOZ26BYRV2PLUDRFBNANCNFSM5CFGGCAQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Does cardano natively supports royalty split or plans to in the future? Can we get royaties distributed in multiple account of an nft sale?

The challenge with a smart contract is that you would have to have one created for each sale.  And you cant force the holder of the NFT to use one when they sell.  Thats why this was developed to be implemented via marketplaces.  The output could be an SC or a regular wallet.

The current standard makes it so you can only have 1 address or array of addresses per policy id, right?
This means there is no way to have different royalties/addresses unless you create multiple policies.
I am working on a project that has various artists I want to assign royalties to.  Is it possible to have royalties on a per NFT/asset/token name?
Ex
Sales of Token001 pays royalties to addr123abc...
Sales of Token002 pays royalties to addr456def...
Something like
{
  "777": {
    "<policy_id>": {
      "pct": <float>,
      "addr": <string>,
      "Token001": {
        "pct": <float>,
        "addr": <string>,
      },
      "Token002": {
        "pct": <float>,
        "addr": <string>,
      }
    }
  }
}

The current standard makes it so you can only have 1 address or array of addresses per policy id, right?
This means there is no way to have different royalties/addresses unless you create multiple policies.
I am working on a project that has various artists I want to assign royalties to. Is it possible to have royalties on a per NFT/asset/token name?
Ex
Sales of Token001 pays royalties to addr123abc...
Sales of Token002 pays royalties to addr456def...
Something like
{
  "777": {
    "<policy_id>": {
      "pct": <float>,
      "addr": <string>,
      "Token001": {
        "pct": <float>,
        "addr": <string>,
      },
      "Token002": {
        "pct": <float>,
        "addr": <string>,
      }
    }
  }
}

Thanks 🙏

Since the standard is implemented through the secondary market, simplicity is necessary as to not overburden them.  Its easy enough to make a second policy ID for what you're asking.

Since the standard is implemented through the secondary market, simplicity is necessary as to not overburden them. Its easy enough to make a second policy ID for what you're asking.

Appreciate the response. 👍
However, creating additional policy ids is not an easy solution because the marketplaces verify by policy id. Different policy == Different project. So I'd have to have different policy ids/projects for every additional artist I work with and would have to get each project verified independently. As a creator, ideally, I want all NFTs grouped under one policy/project.
If the second market is just parsing the metadata JSON, it should be a pretty simple code implementation. They can just check both values and OR them.
Ex.
const metadata = {
  "777": {
    "7a7c1cd55": {
      "pct": 0.1,
      "addr": "addr123",
      "Token001": {
        "pct": 0.2,
        "addr": "addr456",
      },
      "Token002": {
        "pct": 0.15,
        "addr": "addr789",
      }
    }
  }
}

const policyId = "7a7c1cd55"
const assetName = "Token001"

const royaltyPercent = metadata["777"]?.[policyId]?.[assetName]?.pct || metadata["777"]?.[policyId]?.pct
const royaltyAddress = metadata["777"]?.[policyId]?.[assetName]?.addr || metadata["777"]?.[policyId]?.addr

console.log(royaltyPercent)
console.log(royaltyAddress)

Even if it's via CLI, I bet it's fairly easy to check both values.

Since the standard is implemented through the secondary market, simplicity is necessary as to not overburden them. Its easy enough to make a second policy ID for what you're asking.

Appreciate the response. 👍
However, creating additional policy ids is not an easy solution because the marketplaces verify by policy id. Different policy == Different project. So I'd have to have different policy ids/projects for every additional artist I work with and would have to get each project verified independently. As a creator, ideally, I want all NFTs grouped under one policy/project.
If the second market is just parsing the metadata JSON, it should be a pretty simple code implementation. They can just check both values and OR them.
Ex.
const metadata = {
  "777": {
    "7a7c1cd55": {
      "pct": 0.1,
      "addr": "addr123",
      "Token001": {
        "pct": 0.2,
        "addr": "addr456",
      },
      "Token002": {
        "pct": 0.15,
        "addr": "addr789",
      }
    }
  }
}

const policyId = "7a7c1cd55"
const assetName = "Token001"

const royaltyPercent = metadata["777"]?.[policyId]?.[assetName]?.pct || metadata["777"]?.[policyId]?.pct
const royaltyAddress = metadata["777"]?.[policyId]?.[assetName]?.addr || metadata["777"]?.[policyId]?.addr

console.log(royaltyPercent)
console.log(royaltyAddress)

Even if it's via CLI, I bet it's fairly easy to check both values.

You are referring to having a verified policy on CNFT.io, as opposed to royalties.  The royalties standard would be effective, regardless of it being stamped as verified.

You are referring to having a verified policy on CNFT.io, as opposed to royalties. The royalties standard would be effective, regardless of it being stamped as verified.

I understand verifying the policies is different from the royalties working.
What I am trying to explain is that policies and royalties are related from the creator's perspective. Releasing a new project/policy for every separate royalty/artist is a problem. On the marketplaces (CNFT or others), I don't want to create 20 separate projects/policies to assign royalties to different artists.
I need one policy/project that has all my NFTs with the ability to assign different royalties to different assets/tokens. I believe many other creators will have similar requirements. It would be nice to bake in this functionality before the standard is set in stone or it could be a major flaw/shortcoming.
I have a music-branded NFT. We plan on having many artists (10s or 100s). I don't want 10s to 100s of policies/projects. I need one policy that can assign different royalties to different artists.

You are referring to having a verified policy on CNFT.io, as opposed to royalties. The royalties standard would be effective, regardless of it being stamped as verified.

I understand verifying the policies is different from the royalties working.
What I am trying to explain is that policies and royalties are related from the creator's perspective. Releasing a new project/policy for every separate royalty/artist is a problem. On the marketplaces (CNFT or others), I don't want to create 20 separate projects/policies to assign royalties to different artists.
I need one policy/project that has all my NFTs with the ability to assign different royalties to different assets/tokens. I believe many other creators will have similar requirements. It would be nice to bake in this functionality before the standard is set in stone or it could be a major flaw/shortcoming.
I have a music-branded NFT. We plan on having many artists (10s or 100s). I don't want 10s to 100s of policies/projects. I need one policy that can assign different royalties to different artists.

Unfortunately you are trying to skirt the inevitable.  Each individual project should in fact have its own policy.

I like the addition of the per asset name addr/royalty.
It makes the standard more powerful, flexible and adaptable to different use cases with a very small increase in complexity.

I like the addition of the per asset name addr/royalty.
It makes the standard more powerful, flexible and adaptable to different use cases with a very small increase in complexity.

I'm not sure why this is necessary.  For this to work, you'd have to know in advance what your token names would be; meaning you'd already know which projects you're going to do.  If you already know which projects you're going to do, why then wouldnt you just create your separate policies?  You cant change the policy once its minted.

I'm not sure why this is necessary. For this to work, you'd have to know in advance what your token names would be; meaning you'd already know which projects you're going to do. If you already know which projects you're going to do, why then wouldnt you just create your separate policies? You cant change the policy once it's minted.

Thanks @shawnim 🙏
It's needed because I want/need to credit various artists under one project/policy. I plan on having 10s or 100s of artists under my project since it's music-based. If I use someone's song in an NFT, I want only the artist that worked on that song to receive royalties. I don't want to release a new project/policy for every different artist I work with.
Yes, I will know all the token names in advance.
No, I don't want a new policy for every separate royalty.
I'm okay with not changing the policy/royalties once they are minted. Although it would be beneficial to assign new royalties if I mint more songs/NFTs after launching. I plan on having an open policy since new music is always coming out so I plan on minting more in the future. I understand this is difficult cause we don't want creators changing royalties/rug pulling, but still something to think about.
I appreciate you looking at this @huths0lo
Is there anyone else we could tag to get more ideas/discussion on this?
Per asset royalties are pretty important for the implementation of my project.

I'm not sure why this is necessary. For this to work, you'd have to know in advance what your token names would be; meaning you'd already know which projects you're going to do. If you already know which projects you're going to do, why then wouldnt you just create your separate policies? You cant change the policy once it's minted.

Thanks @shawnim 🙏
It's needed because I want/need to credit various artists under one project/policy. I plan on having 10s or 100s of artists under my project since it's music-based. If I use someone's song in an NFT, I want only the artist that worked on that song to receive royalties. I don't want to release a new project/policy for every different artist I work with.
Yes, I will know all the token names in advance.
No, I don't want a new policy for every separate royalty.
I'm okay with not changing the policy/royalties once they are minted. Although it would be beneficial to assign new royalties if I mint more songs/NFTs after launching. I plan on having an open policy since new music is always coming out so I plan on minting more in the future. I understand this is difficult cause we don't want creators changing royalties/rug pulling, but still something to think about.
I appreciate you looking at this @huths0lo
Is there anyone else we could tag to get more ideas/discussion on this?
Per asset royalties are pretty important for the implementation of my project.

I think most are on the thread already.  When we finished the meeting where this was all ironed out, we planned to review it again, to see if a version 2.0 is needed.  That will probably happen in about month or so.  And this something that could be considered.  But you have a unique use case.  I understand it creates more work for you; but I dont see the current design not meeting your goals.  I think that most NFT makers have allot of projects.  I'm currently working with both KMFDM and Lords of Acid.  And I would anticipate many more.

I think most are on the thread already. When we finished the meeting where this was all ironed out, we planned to review it again, to see if a version 2.0 is needed. That will probably happen in about month or so. And this something that could be considered. But you have a unique use case. I understand it creates more work for you; but I dont see the current design not meeting your goals. I think that most NFT makers have allot of projects. I'm currently working with both KMFDM and Lords of Acid. And I would anticipate many more.

The current design technically works, but it's a terrible solution for my use case.
It doesn't make sense for me to release a new project for every artist. I would have to create CardanoAudioArtistA, CardanoAudioArtistB, CardanoAudioArtistC, etc. for 10s to 100s of projects/policies. I need one policy/project (CardanoAudio) with the ability to assign royalties on a per asset basis.
I assume MADinArt has a similar use case. They onboard artists and release everything under MADinArt. They probably won't want to set up a new policy for every new artist.
Thanks again! Just trying to contribute and help build the best standards for all of us. Yeah, maybe it will get picked up in V2 😀

I think most are on the thread already. When we finished the meeting where this was all ironed out, we planned to review it again, to see if a version 2.0 is needed. That will probably happen in about month or so. And this something that could be considered. But you have a unique use case. I understand it creates more work for you; but I dont see the current design not meeting your goals. I think that most NFT makers have allot of projects. I'm currently working with both KMFDM and Lords of Acid. And I would anticipate many more.

The current design technically works, but it's a terrible solution for my use case.
It doesn't make sense for me to release a new project for every artist. I would have to create CardanoAudioArtistA, CardanoAudioArtistB, CardanoAudioArtistC, etc. for 10s to 100s of projects/policies. I need one policy/project (CardanoAudio) with the ability to assign royalties on a per asset basis.
I assume MADinArt has a similar use case. They onboard artists and release everything under MADinArt. They probably won't want to set up a new policy for every new artist.
Thanks again! Just trying to contribute and help build the best standards for all of us. Yeah, maybe it will get picked up in V2 😀

MADinArt actually contributed to the design discussions.

Ok. I understand. Since later mintings can't change this metadata maybe the way to accomodate what @drewhaines wants is to have the original no name token minting be the default for the policy but allow the first minting of named assets to specify an overriding value in their metadata.

Ok. I understand. Since later mintings can't change this metadata maybe the way to accomodate what @drewhaines wants is to have the original no name token minting be the default for the policy but allow the first minting of named assets to specify an overriding value in their metadata.

Thats not going to be an option at all.  It strays in a completely different direction than the design.  You may as well just go back to putting the royalty in the metadata on every asset; which was distinctly opposed.

It is confusing that the tag is called "pct" but the range is between 0.0 and 1.0.
You should either change the tag name to something like "royalty" or change the range to be between 0.0 and 100.0.

It is confusing that the tag is called "pct" but the range is between 0.0 and 1.0.
You should either change the tag name to something like "royalty" or change the range to be between 0.0 and 100.0.

This is pretty standard.  Its the same way you set a stakepools margin.

It is confusing that the tag is called "pct" but the range is between 0.0 and 1.0.
You should either change the tag name to something like "royalty" or change the range to be between 0.0 and 100.0.

This is pretty standard. Its the same way you set a stakepools margin.

When creating the stake pool registration certificate the value is refered to as --pool-margin, not --pool-percent.
It is fine to have the range be from 0.0 to 1.0 but it is mislabeled to call it "pct".
A percentage goes from 0.0 to 100.0.
If you want to keep the same range, you need to change the label.

It is confusing that the tag is called "pct" but the range is between 0.0 and 1.0.
You should either change the tag name to something like "royalty" or change the range to be between 0.0 and 100.0.

This is pretty standard. Its the same way you set a stakepools margin.

When creating the stake pool registration certificate the value is refered to as --pool-margin, not --pool-percent.
It is fine to have the range be from 0.0 to 1.0 but it is mislabeled to call it "pct".
A percentage goes from 0.0 to 100.0.
If you want to keep the same range, you need to change the label.

I dont think that anyone is going to want to change it at this point.  These are the labels that were picked.  There has already been tens of thousands of assets produced using the methods described in the CIP.  I personally dont see this is a significant flaw, as using a decimal point is another way of displaying a percentage.  The marketplaces have either already implemented it the way its described, or are going to implement it the way its described.

The royalty token must be minted prior to creating any assets off the policy.  All markets will be instructed to look at the timeline of use on a policy.  Any assets minted prior to the royalty token would not be honored.

How is this going to work for a lot of existing projects?

It distinctly wont work for pre-existing projects. It would be a rug pull for someone to attach a royalty to tokens that have already been purchased, when the buyer wouldnt have been aware that the cnft creator would add them at a later date. Its for the same reason that only the first mint of the no name token will be honored. It wouldnt be acceptable for the cnft creator to be able to change the royalties after the fact.

I think this is another thing we should think about. It would be very helpful to be able to edit the token's royalty attributes in a safe way if the policy is unlocked.
If the creator/original wallet still has ownership of the token, why should they not be able to change the royalty attributes?
Ex Burn my NFT and remint with new royalty metadata.
Obviously, if it's tracked as the unnamed token, you run into the problems with creators maliciously changing royalties after the token has been sold. So why are we not tracking this with 721 or the latest metadata attached to the token?
Ex.
{
  "721": {
    "7300e48e9...": {
      "Token001": {
        "name": "Cardano Audio 1"
        ...
        "pct": 0.2,
        "addr": "addr456"
      },
      "Token002": {
        "name": "Cardano Audio 2"
        ... more metadata
        "pct": 0.15,
        "addr": "addr789"
      },
      "Token003": {
        "name": "Cardano Audio 3"
        ...
        "pct": 0.1,
        "addr": "addr123",
      }
    }
  }
}

or
{
  "721": {
    "7300e48e9...": {
      "Token001": {
        "name": "Cardano Audio 1"
        ...
      },
      "Token002": {
        "name": "Cardano Audio 2"
        ...
      },
      "Token003": {
        "name": "Cardano Audio 3"
        ...
      }
    }
  },
  "777": {
    "7300e48e9...": {
      "pct": 0.1,
      "addr": "addr123",
      "Token001": {
        "pct": 0.2,
        "addr": "addr456"
      },
      "Token002": {
        "pct": 0.15,
        "addr": "addr789"
      }
    }
  }
}

You can't change the metadata attached to the token without actually having the token, wallet, and policy, right?
So if the standard is to check the metadata minted with the token, only the creator/original wallet could change the royalties.
This ☝ makes the most sense to me as a dev and creator. Is there something I am missing as to why that's not better than the unnamed token approach?

The royalty token must be minted prior to creating any assets off the policy.  All markets will be instructed to look at the timeline of use on a policy.  Any assets minted prior to the royalty token would not be honored.

How is this going to work for a lot of existing projects?

It distinctly wont work for pre-existing projects. It would be a rug pull for someone to attach a royalty to tokens that have already been purchased, when the buyer wouldnt have been aware that the cnft creator would add them at a later date. Its for the same reason that only the first mint of the no name token will be honored. It wouldnt be acceptable for the cnft creator to be able to change the royalties after the fact.

I think this is another thing we should think about. It would be very helpful to be able to edit the token's royalty attributes in a safe way if the policy is unlocked.
If the creator/original wallet still has ownership of the token, why should they not be able to change the royalty attributes?
Ex Burn my NFT and remint with new royalty metadata.
Obviously, if it's tracked as the unnamed token, you run into the problems with creators maliciously changing royalties after the token has been sold. So why are we not tracking this with 721 or the latest metadata attached to the token?
Ex.
{
  "721": {
    "7300e48e9...": {
      "Token001": {
        "name": "Cardano Audio 1"
        ...
        "pct": 0.2,
        "addr": "addr456"
      },
      "Token002": {
        "name": "Cardano Audio 2"
        ... more metadata
        "pct": 0.15,
        "addr": "addr789"
      },
      "Token003": {
        "name": "Cardano Audio 3"
        ...
        "pct": 0.1,
        "addr": "addr123",
      }
    }
  }
}

or
{
  "721": {
    "7300e48e9...": {
      "Token001": {
        "name": "Cardano Audio 1"
        ...
      },
      "Token002": {
        "name": "Cardano Audio 2"
        ...
      },
      "Token003": {
        "name": "Cardano Audio 3"
        ...
      }
    }
  },
  "777": {
    "7300e48e9...": {
      "pct": 0.1,
      "addr": "addr123",
      "Token001": {
        "pct": 0.2,
        "addr": "addr456"
      },
      "Token002": {
        "pct": 0.15,
        "addr": "addr789"
      }
    }
  }
}

You can't change the metadata attached to the token without actually having the token, wallet, and policy, right?
So if the standard is to check the metadata minted with the token, only the creator/original wallet could change the royalties.
This ☝ makes the most sense to me as a dev and creator. Is there something I am missing as to why that's not better than the unnamed token approach?

There is nothing stopping a bad actor from significantly adjusting their royalty after the primary sale.

The royalty token must be minted prior to creating any assets off the policy.  All markets will be instructed to look at the timeline of use on a policy.  Any assets minted prior to the royalty token would not be honored.

How is this going to work for a lot of existing projects?

It distinctly wont work for pre-existing projects. It would be a rug pull for someone to attach a royalty to tokens that have already been purchased, when the buyer wouldnt have been aware that the cnft creator would add them at a later date. Its for the same reason that only the first mint of the no name token will be honored. It wouldnt be acceptable for the cnft creator to be able to change the royalties after the fact.

I think this is another thing we should think about. It would be very helpful to be able to edit the token's royalty attributes in a safe way if the policy is unlocked.
If the creator/original wallet still has ownership of the token, why should they not be able to change the royalty attributes?
Ex Burn my NFT and remint with new royalty metadata.
Obviously, if it's tracked as the unnamed token, you run into the problems with creators maliciously changing royalties after the token has been sold. So why are we not tracking this with 721 or the latest metadata attached to the token?
Ex.
{
  "721": {
    "7300e48e9...": {
      "Token001": {
        "name": "Cardano Audio 1"
        ...
        "pct": 0.2,
        "addr": "addr456"
      },
      "Token002": {
        "name": "Cardano Audio 2"
        ... more metadata
        "pct": 0.15,
        "addr": "addr789"
      },
      "Token003": {
        "name": "Cardano Audio 3"
        ...
        "pct": 0.1,
        "addr": "addr123",
      }
    }
  }
}

or
{
  "721": {
    "7300e48e9...": {
      "Token001": {
        "name": "Cardano Audio 1"
        ...
      },
      "Token002": {
        "name": "Cardano Audio 2"
        ...
      },
      "Token003": {
        "name": "Cardano Audio 3"
        ...
      }
    }
  },
  "777": {
    "7300e48e9...": {
      "pct": 0.1,
      "addr": "addr123",
      "Token001": {
        "pct": 0.2,
        "addr": "addr456"
      },
      "Token002": {
        "pct": 0.15,
        "addr": "addr789"
      }
    }
  }
}

You can't change the metadata attached to the token without actually having the token, wallet, and policy, right?
So if the standard is to check the metadata minted with the token, only the creator/original wallet could change the royalties.
This ☝ makes the most sense to me as a dev and creator. Is there something I am missing as to why that's not better than the unnamed token approach?

There is nothing stopping a bad actor from significantly adjusting their royalty after the primary sale.

Assuming we go the route of using the latest metadata attached/minted to the NFT and not the unnamed token ...
If I sold the NFT/token and no longer have it, how would I or a bad actor update the metadata/royalties attached to the NFT?
My understanding is to update the metadata attached to the token, I'd have to:

Have the token
Burn it
Remint it with the new metadata

You can't change the metadata attached to the token without actually having the token, wallet, and policy, right?
So if the standard is to check the metadata minted with the token, only the creator/original wallet could change the royalties.
This ☝ makes the most sense to me as a dev and creator. Is there something I am missing as to why that's not better than the unnamed token approach?

There is nothing stopping a bad actor from significantly adjusting their royalty after the primary sale.

Assuming we go the route of using the latest metadata attached/minted to the NFT and not the unnamed token ...
If I sold the NFT/token and no longer have it, how would I or a bad actor update the metadata/royalties attached to the NFT?
My understanding is to update the metadata attached to the token, I'd have to:

Have the token
Burn it
Remint it with the new metadata

You would mint another with the same name, then burn it.

You would mint another with the same name, then burn it.

Dang. So if I mint and then burn a second one, it updates the metadata that was attached to the first token as well?

You would mint another with the same name, then burn it.

Dang. So if I mint and then burn a second one, it updates the metadata that was attached to the first token as well?

That is correct.  Thats why its very important to only respect the first mint of the 777 token.  And if you're thinking that lots of projects could do a significant rug pull on previously sold NFT's if they have an active policy, you would be correct.  Thats why trust goes a long ways.  But not everyone is trustworthy.  Hence the limitations that were imposed on this proposal.

It is confusing that the tag is called "pct" but the range is between 0.0 and 1.0.
You should either change the tag name to something like "royalty" or change the range to be between 0.0 and 100.0.

This is pretty standard. Its the same way you set a stakepools margin.

When creating the stake pool registration certificate the value is refered to as --pool-margin, not --pool-percent.
It is fine to have the range be from 0.0 to 1.0 but it is mislabeled to call it "pct".
A percentage goes from 0.0 to 100.0.
If you want to keep the same range, you need to change the label.

I dont think that anyone is going to want to change it at this point. These are the labels that were picked. There has already been tens of thousands of assets produced using the methods described in the CIP. I personally dont see this is a significant flaw, as using a decimal point is another way of displaying a percentage. The marketplaces have either already implemented it the way its described, or are going to implement it the way its described.

Seems pointless to discuss this CIP any further then.
If too many people have implemented it to fix a simple logical flaw then it is a defacto standard and we accept it with it's flaws.

I've read through the proposal and this discussion and I understand it, but there's one part that remains unclear to me... does the 777 token have to be the absolute first thing ever minted on a given policy? Or is it simply that only the later NFTs minted after the 777 token on the policy get the royalties?
Scenario:

I have an existing open policy. I already minted 10 NFTs under it.
I mint the 777 token defining the royalty percentage and address as per the standard.
I mint another 10 NFTs afterwards.

I understand the first 10 will never get royalties as it'd be a rug pull for the buyer.
But would the second 10 get royalties under the same policy or no?
My understanding is those second 10 would get royalties, but the ideal use case would be minting the 777 as the first thing on the policy, correct?
Just checking this as it's currently very useful to keep the same time locked policy for a certain project rather than creating
a new one for every drop given the waiting times to get them verified on CNFT.io.
Cheers.

I've read through the proposal and this discussion and I understand it, but there's one part that remains unclear to me... does the 777 token have to be the absolute first thing ever minted on a given policy? Or is it simply that only the later NFTs minted after the 777 token on the policy get the royalties?
Scenario:

I have an existing open policy. I already minted 10 NFTs under it.
I mint the 777 token defining the royalty percentage and address as per the standard.
I mint another 10 NFTs afterwards.

I understand the first 10 will never get royalties as it'd be a rug pull for the buyer.
But would the second 10 get royalties under the same policy or no?
My understanding is those second 10 would get royalties, but the ideal use case would be minting the 777 as the first thing on the policy, correct?
Just checking this as it's currently very useful to keep the same time locked policy for a certain project rather than creating
a new one for every drop given the waiting times to get them verified on CNFT.io.
Cheers.

It has to be the first thing ever minted.

It has to be the first thing ever minted. But you dont have to create a new policy every time. Once you have a 777 token, you can use the policy for as long as you like.

Makes sense, thank you for clarifying. I know that after creating a new policy and minting a 777 token I can mint multiple drops under the same policy as before, but it just means getting new policies verified sooner than expected. Still this is an external issue out of your control and a temporary one at that so this isn't a criticism of the proposal per se.
Imo however, it would be helpful to explicitly state this in the documentation, as although the description of the flow gives the instruction to mint the 777 token first and states NFTs minted before the 777 won't get royalties, it's not entirely clear that minting 777 before anything else is mandatory.
Everything else is good though. I think this is a nice, clean, simple implementation that will work for the vast majority of use cases. Good job.

It has to be the first thing ever minted. But you dont have to create a new policy every time. Once you have a 777 token, you can use the policy for as long as you like.

Makes sense, thank you for clarifying. I know that after creating a new policy and minting a 777 token I can mint multiple drops under the same policy as before, but it just means getting new policies verified sooner than expected. Still this is an external issue out of your control and a temporary one at that so this isn't a criticism of the proposal per se.
Imo however, it would be helpful to explicitly state this in the documentation, as although the description of the flow gives the instruction to mint the 777 token first and states NFTs minted before the 777 won't get royalties, it's not entirely clear that minting 777 before anything else is mandatory.
Everything else is good though. I think this is a nice, clean, simple implementation that will work for the vast majority of use cases. Good job.

Thats fair.  I will go back and re-read it.  I thought that it was stated.  But I believe you if you say it doesnt.  It is important for it to be mentioned, so I'll make sure it is.

Happy to help write docs/examples if needed.
Thanks 🙏

I am using https://cardano-tools.io/mint
On there, I'd create my collection policy id, then replace this code:
``
{
"721": {
"MYPOLICYID": {
"Token1": {}
}
}
}
``
With this code?
``
{
"721": {
"MYPOLICYID": {
"Token1": {}
}
}
"777": {
"pct": "0.2",
"addr": "addr1v9nevxg9wunfck0gt7hpxuy0elnqygglme3u6l3nn5q5gnq5dc9un"
}
}
``

so an implication here may be that we need a royalty oracle?

so an implication here may be that we need a royalty oracle?

I dont follow.  The way this is implemented, the info is written up front before assets are made, and cant be changed later.

Tentatively adding this PR to the upcoming CIP Editors meeting 31 later today to start discussing the content. If this PR is of relevance to you, please consider attending (note: this PR will likely continue into the following Editors meeting 32 two weeks from now if you are unable to attend this one)

I think this pull request brings up an important point about the CIP process.
It's a useful proposal that I support but it has a logical error.
The "pct" field is defined to have a range of 0-1.
Either the name should be changed to "royalry" or the range should be changed to 0-100.
If the name was changed to "royalty" implementors could also accept "pct" for backwards compatability with existing assets.
It is an easily fixable error but the change is being resisted because community members have already implemented the proposal.
This brings up the balance between quality and expediency that I think should be thought carefully about before approving this CIP as is.

Tentatively adding this PR to the upcoming CIP Editors meeting 31 later today to start discussing the content. If this PR is of relevance to you, please consider attending (note: this PR will likely continue into the following Editors meeting 32 two weeks from now if you are unable to attend this one)

I had planned to be on today's call, but forgot to place it on my calendar.  The meetings take place at 2:30am my time.  I will plan for CIP Editors Meeting 32.

I think this pull request brings up an important point about the CIP process. It's a useful proposal that I support but it has a logical error. The "pct" field is defined to have a range of 0-1. Either the name should be changed to "royalry" or the range should be changed to 0-100. If the name was changed to "royalty" implementors could also accept "pct" for backwards compatability with existing assets. It is an easily fixable error but the change is being resisted because community members have already implemented the proposal. This brings up the balance between quality and expediency that I think should be thought carefully about before approving this CIP as is.

Its not really a flaw.  You are displaying a percentage as an integer.

It's a useful proposal that I support but it has a logical error.
The "pct" field is defined to have a range of 0-1.

Its not really a flaw. You are displaying a percentage as an integer.

@shawnim @huths0lo I've invited some more community developers to submit their ideas about that issue through this forum thread: https://members.spocra.io/posts/17444451

Its not really a flaw. You are displaying a percentage as an integer.

In my opinion this is like saying: "Mis-labelling the field is not a problem because people will understand what you really mean."

I am using https://cardano-tools.io/mint On there, I'd create my collection policy id, then replace this code (under "advanced"):
{
   "721": {
      "MYPOLICYID": {
         "Token1": {}
      }
   }
}

With this code?
{
   "721": {
      "MYPOLICYID": {
         "Token1": {}
      }
   }
	"777": {
		"pct": "0.2",
		"addr": "MYRECEIVINGADDRESSSTRING"
	}

}

Is this correct? Thanks

If you're using a tool/app to make your NFTs, I think you are dependent on them implementing it correctly.
My understanding is the 777 metadata should be attached to the first mint of an unnamed token. It is separate from the 721 metadata minted with your NFTs/tokens.
NFT Maker already has this somewhat implemented.

Note this ☝ was just me testing stuff. Not working/live royalties.

I am using https://cardano-tools.io/mint On there, I'd create my collection policy id, then replace this code (under "advanced"):
{
   "721": {
      "MYPOLICYID": {
         "Token1": {}
      }
   }
}

With this code?
{
   "721": {
      "MYPOLICYID": {
         "Token1": {}
      }
   }
	"777": {
		"pct": "0.2",
		"addr": "MYRECEIVINGADDRESSSTRING"
	}

}

Is this correct? Thanks

If you're using a tool/app to make your NFTs, I think you are dependent on them implementing it correctly.
My understanding is the 777 metadata should be attached to the first mint of an unnamed token. It is separate from the 721 metadata minted with your NFTs/tokens.
NFT Maker already has this somewhat implemented.

Note this ☝ was just me testing stuff. Not working/live royalties.

Unfortunately this isnt a practical request.  The intention of this CIP is to lock the minter in to their royalty at the outset, so that it cant be changed later.  You're using a tool thats meant to simplify the process of creating assets.  Unfortunately this tool doesnt provide the utility you are looking for.  Tokhun.io has built the code in to their minting service.  You would be better off using that, or learning the process of creating your own assets on a Cardano Node.

Unfortunately this isnt a practical request. The intention of this CIP is to lock the minter in to their royalty at the outset, so that it cant be changed later. You're using a tool thats meant to simplify the process of creating assets. Unfortunately this tool doesnt provide the utility you are looking for. Tokhun.io has built the code in to their minting service. You would be better off using that, or learning the process of creating your own assets on a Cardano Node.

I was just responding to @Fwumply about their question.
I mint most of mine manually using Node/cardanocli-js 🙂
Still would appreciate per asset royalties in the standard. Thanks for staying ontop of the thread.

Whats the plan to enforce such payments on the blockchain? Who is going against sales without royalties payments? How do you differ between private-to-private sales and private-to-own-private wallet transactions? There should be rules in the CIP how to enforce something like this on the chain, what do you do when the originally assigned payment-address gets lost by the artist and the artist is providing this information publicly? Do you still send %pct to the lost payment-address instead of a new working one?

At the moment, there doesnt appear to be a mechanism at the blockchain level to enforce these payments. Thats why this becomes a community driven effort to be enforced through the marketplaces.

Why it can be done in the following way:

Create 2 output txs: 1st to contain the main transaction with NFT and 2nd to be for paying royalties.
Policy script to validate if there is a 2nd tx and if yes and fee is paid to allow the transaction.
Royalty data to be stored in Datum instead of metadata so it can be readable inside a script.

Are there any disadvantages that I am not aware of?

Whats the plan to enforce such payments on the blockchain? Who is going against sales without royalties payments? How do you differ between private-to-private sales and private-to-own-private wallet transactions? There should be rules in the CIP how to enforce something like this on the chain, what do you do when the originally assigned payment-address gets lost by the artist and the artist is providing this information publicly? Do you still send %pct to the lost payment-address instead of a new working one?

At the moment, there doesnt appear to be a mechanism at the blockchain level to enforce these payments. Thats why this becomes a community driven effort to be enforced through the marketplaces.

Why it can be done in the following way:

Create 2 output txs: 1st to contain the main transaction with NFT and 2nd to be for paying royalties.
Script to validate if there is a 2nd tx and if yes and fee is paid to allow the transaction.
Royalty data to be stored in Datum instead of metadata so it can be readable inside a script.

Are there any disadvantages that I am not aware of?

Honestly not sure what you're asking.  Crypto 2099 has already developed an API to grab the data from the info written on the 777 token.  Any decent script can query that api.

Sorry I did not explain well. I mean that you can program in validator script to not accept transactions if it is not paid royalty to specified royalty address. The idea is for a marketplace to have that kind of Smart Contract that will do that job. I think that is possible to be achieved, at least in theory.

Maybe this belongs in another CIP but I believe we should encourage the payments to come with metadata attached that describes the purpose of the payment and the source. I am thinking of a future where random payments are coming in to wallets and we have no standard in place for how to track them. A simple metadata message could be sent with the payment to explain source, period, etc.

A simple and flexible payment metadata standard is a great idea but I think it should be a separate CIP so it can take into consideration other use cases.

Oh year. I guess this would be a new CIP that extends CIP-20 to define the msg format for NFT payment transactions.

CIP-0020 allows to add additional keys. So you have two options, use the already defined msg-key entries and put the information in there. Or, fill the msg-key with a description and add additional key fields. But, it is currently hard enough to get the transaction message displayed in the wallets. ccwallet.io supports it for example. so, adding additional keys is even harder to get support for. many tools support the transactions messages CIP0020 now. So if you will have a kind of fast solution, just go with it.

Hey everyone,
Mateja here from Artano. Correct me if I'm writing this wrong and if me and my team misunderstood the 777 standard, but here's our take on the proposal.
The Artano team believes that the current proposal is missing 2 key components to be accessible to all artists and collectors, specifically for big, decentralized 1/1 collections (without a single authority) or artists who want to have their own policy ID as a "signature" for their work.
TL;DR:=
One NFT should have a unique royalties tag, independent of its policy ID, otherwise, this excludes 1/1 artists who don't want to do big collections and use policy IDs as their signature. The current standard is skewed towards huge collections with centralized authority
1. Collaborations between multiple artists on the same collection are impossible, unless they reach a consensus
If there are multiple artists (let's say 10) working on the same project, but one participated disproportionately more than the others, the artist who is a "lead" might want to receive higher royalties. Alternatively, if one artist was an apprentice, maybe the lead wants their apprentice to receive most royalties. Our artists already asked us if this would be possible. The current proposal seems to have had huge collections form a single source (organization, person, artist) in mind. The standard does not account for many artists participating on the same project.
Example: We have an upcoming collection of 70+ artists under the same policy ID. They all want to have different royalties. How do we account for this with the current standard? We can't, unless they all agree to have the same royalties for the whole collection.
2. The current standard+policy ID makes 1/1 pieces and marketplaces impossible on Cardano, if one artist wants to use one policy ID as their signature
For our solution each artist will have their own policy ID, that will allow them to mint NFTs linked to their profile, which makes sense for 1/1 works.
The policy will change on a yearly basis, so they will have enough time to apply to other marketplaces if they want to sell there. However, according to the current standard, the artist has to have one royalty amount that is forever linked to their profile (from what we understand?).
If an artist wants to use their policy ID as their signature, they will have to either:

Create a new policy for each NFT and that way have different royalties and reapply for approval from other marketplaces for each NFT.
Create one policy that is associated with them and have 1 royalty % for an X amount of time

This is not very user friendly.
Again, if any of you sees a solution for low-quantity, decentralized projects, let us know, but how we see it, the current standard makes big collaborations with only 1/1 pieces almost impossible to work with.
Thanks!

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this.  But I beleive the answer is much easier than that.  Any value < 0 is a floating point value, and any value > 0 is a percent.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me.
A simple "Find and Replace" of "pct" to "rate" is all that is needed.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me. A simple "Find and Replace" of "pct" to "rate" is all that is needed.

Changing the label is a non starter.  Its already been used on thousands of tokens.

Changing the label is a non starter. Its already been used on thousands of tokens.

Thats not an argument. Why do the CIP process in first place then? Saying: "we can't change a proposal because there are already some using it this way" is the wrong path. If you think so, you don't need a CIP at all.

Changing the label is a non starter. Its already been used on thousands of tokens.

Thats not an argument. Why do the CIP process in first place then? Saying: "we can't change a proposal because there are already some using it this way" is the wrong path. If you think so, you don't need a CIP at all.

The CIP repo is a surfacing mechanism: if this is merged, it's for visibility, nothing would prevent someone else to fork this PR and propose an alternative implementation.
There is no direct implied acceptance by IOG or the Foundation, solely that it was reviewed for form and content by CIP Editors for inclusion in the repo. (i.e. many CIPs have been merged that may not be implemented or followed by others - however the greater ecosystem benefits from having a place to look for existing proposals to either align on or evolve)

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me. A simple "Find and Replace" of "pct" to "rate" is all that is needed.

Changing the label is a non starter. Its already been used on thousands of tokens.

As I just said, the existing tokens can easily be handled by marketplaces accepting either "pct" or "rate".

If anyone is interested in ways to improve this standard, I want to make a complete new (or parallel) CIP royalties proposal, since this one is too expensive for 1/1 artists and marketplaces who want to approve projects by policyID (like CNFT).
Here's a link: https://forum.cardano.org/t/cip-royalties-777-version-2-0/83665

@DeFi-Authority will check it out. thanks for taking the initiative here.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me. A simple "Find and Replace" of "pct" to "rate" is all that is needed.

Changing the label is a non starter. Its already been used on thousands of tokens.

As I just said, the existing tokens can easily be handled by marketplaces accepting either "pct" or "rate".

Will be iterating the version of the proposal for this.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me. A simple "Find and Replace" of "pct" to "rate" is all that is needed.

Changing the label is a non starter. Its already been used on thousands of tokens.

As I just said, the existing tokens can easily be handled by marketplaces accepting either "pct" or "rate".

Will be iterating the version of the proposal for this.

Awesome! I look forward to seeing it and providing my full support for the proposal.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me. A simple "Find and Replace" of "pct" to "rate" is all that is needed.

Changing the label is a non starter. Its already been used on thousands of tokens.

As I just said, the existing tokens can easily be handled by marketplaces accepting either "pct" or "rate".

Will be iterating the version of the proposal for this.

Awesome! I look forward to seeing it and providing my full support for the proposal.

Its been updated.  Please have a look, and let me know if anything is out of place.

I still think the "pct" label should be changed to "rate" before this is moved forward.

I'm sorry, I just dont think the case is strong enough to not merge this for that reason. In just the last few weeks alone, I've seen this implemented more and more. Just yesterday Claymates announced they were implementing this code for their Joel Madden drop this weekend. I contacted them to make sure they had done it right. They implemented it correctly, and said their dev read through this document. Its pretty clear that if the document is read, its not difficult to understand. With now thousands of tokens using it under this design, its not a strong enough case to change it mid stream because an opinion on nomenclature.
And again, the stakepool margin is done the same way. Sure, a handful of people have made mistakes because they didnt read up on how to do it. Reading the doc goes a long ways here. And most people will get it right. We cant possibility write this in a way that someone at some point wont mess up.

The existing use can be handled by accepting both "pct" and "rate". Document "rate" as the standard and add a note on backwards compatibility. A simple solution that alleviates potential confusion and costly mistakes in the future without affecting NFTs that have already used the "pct" label.
The problem is not the use of the range of 0 to 1, the problem is the incorrect label. The stakepool margin is a range from 0 to 1 but it is not labeled as "percentage" so it is not confusing.
Before merging is the best time to fix this kind of simple to resolve problem.

I'm not saying that I'm agreeing to this. But I believe the answer is much easier than that. Any value < 1.0 is a floating point value, and any value >= 1.0 is a percent.

I appreciate that you are considering addressing the issue but this proposal sounds even more confusing to me. A simple "Find and Replace" of "pct" to "rate" is all that is needed.

Changing the label is a non starter. Its already been used on thousands of tokens.

As I just said, the existing tokens can easily be handled by marketplaces accepting either "pct" or "rate".

Will be iterating the version of the proposal for this.

Awesome! I look forward to seeing it and providing my full support for the proposal.

Its been updated. Please have a look, and let me know if anything is out of place.

Looks great. I think this is a simple, easy to understand, and easy to implement solution for many use cases. It also leaves open the possibility for future extensions to add functionality to accomodate other use cases.
I support this propoosal and will be using it.
Thanks for all of your work on this, @huths0lo !

maybe a good idea to also include an implementation conclusion part and an ill-formatted part like we did here?
https://github.com/cardano-foundation/CIPs/blame/master/CIP-0020/CIP-0020.md#L109-L131

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

It is up to the marketplaces to decide what to do, this is an informational CIP so it merely advertises "this is what we wanna do, this is how we're going about it".
With that said, if you decide to go on that route, it should be a separate CIP which circles back to this one so that everyone can adopt it also and you can get wider adoption.
In addition, ideally the decision would be made by the NFT holders themselves thru an on-chain vote.

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

This was a community driven proposal.  Many ideas were discussed.  Ultimately the most important design aspect of the 777 standard is its inflexibility, to prevent a project team from making changes.  The expectation is if you are in a position of making assets, you should know how to do exactly that.  It is noted in the CIP that the address could be a smart contract address; thus allowing modification through that.
As of lately I personally am thinking it might make more sense to not have an address at all.  And like an $adahandle, you would send the 777 token to the address you want to receive the royalties.  You could then move it wherever you please.  The 777 token would still have to be the first one minted, and would still have the pct tag (or rate for the only person on this planet that feels like that is the correct tag).
But alas, this was community driven, with community democratic vote.  It was always intended to revisit it at a point in the future.  It might be time to have another community discussion now that more marketplaces have come online.  It really requires another majority vote before making a change to the proposal as is.

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

This was a community driven proposal. Many ideas were discussed. Ultimately the most important design aspect of the 777 standard is its inflexibility, to prevent a project team from making changes. The expectation is if you are in a position of making assets, you should know how to do exactly that. It is noted in the CIP that the address could be a smart contract address; thus allowing modification through that.
As of lately I personally am thinking it might make more sense to not have an address at all. And like an $adahandle, you would send the 777 token to the address you want to receive the royalties. You could then move it wherever you please. The 777 token would still have to be the first one minted, and would still have the pct tag (or rate for the only person on this planet that feels like that is the correct tag).
But alas, this was community driven, with community democratic vote. It was always intended to revisit it at a point in the future. It might be time to have another community discussion now that more marketplaces have come online. It really requires another majority vote before making a change to the proposal as is.

This is extremely useful context, thanks @huths0lo! Curious how the community democratic vote was held?

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

It is up to the marketplaces to decide what to do, this is an informational CIP so it merely advertises "this is what we wanna do, this is how we're going about it".
With that said, if you decide to go on that route, it should be a separate CIP which circles back to this one so that everyone can adopt it also and you can get wider adoption.
In addition, ideally the decision would be made by the NFT holders themselves thru an on-chain vote.

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

It is up to the marketplaces to decide what to do, this is an informational CIP so it merely advertises "this is what we wanna do, this is how we're going about it".
With that said, if you decide to go on that route, it should be a separate CIP which circles back to this one so that everyone can adopt it also and you can get wider adoption.
In addition, ideally the decision would be made by the NFT holders themselves thru an on-chain vote.

I couldnt think of a worse position to take.  Standards exist for a reason.  To prevent fragmentation the community.  Look at none other than Ethereum to see how not agreeing upon a standard can make discontiguous markets.
Additionally there are several CIP's that arent just that (proposals).  Even the mighty 728 metadata tag is a CIP.
If you want a new standard, then by all means, propose one.  If you want to break the 100k tokens that have used 777, thats something you'll have to decide for yourselves.  Just keep in mind that Cardano is a community first blockchain.  Not respecting the work and progress that came before you is not a good look.

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

This was a community driven proposal. Many ideas were discussed. Ultimately the most important design aspect of the 777 standard is its inflexibility, to prevent a project team from making changes. The expectation is if you are in a position of making assets, you should know how to do exactly that. It is noted in the CIP that the address could be a smart contract address; thus allowing modification through that.
As of lately I personally am thinking it might make more sense to not have an address at all. And like an $adahandle, you would send the 777 token to the address you want to receive the royalties. You could then move it wherever you please. The 777 token would still have to be the first one minted, and would still have the pct tag (or rate for the only person on this planet that feels like that is the correct tag).
But alas, this was community driven, with community democratic vote. It was always intended to revisit it at a point in the future. It might be time to have another community discussion now that more marketplaces have come online. It really requires another majority vote before making a change to the proposal as is.

This is extremely useful context, thanks @huths0lo! Curious how the community democratic vote was held?
I definitely think not burning the token, and allowing it to be moved to new wallets would be extremely helpful for creators. I've also had some creators ask us to send royalties to multiple addresses. I think there are many ways for this proposal to be improved, so would love to be part of that effort!
I will share these perspectives with the folks who attend our Twitter space tomorrow.

I'm gonna delete this branch, since is now very stale.  But feel free to email me at<EMAIL_ADDRESS>or hit me up on twitter.  I sent you guys a tweet.  You should get this reply in your inbox though.

Hi there, I have a question about this proposal. What are folks thoughts on using a different royalty address besides the one in the royalty token for a project? There are instances where a creator might decide to leave a project, or accidentally mints a token with the wrong address, and I believe marketplaces should be able to send royalties to a new address chosen by a meaningful majority of the community in these instances.
We are hosting a Twitter space with ADA Clouds, a rugged NFT project where the community is trying to take over and redirect royalties away from the creator who left. The Twitter space is tomorrow on our main Twitter account, @jpgstoreNFT at 20:00 UTC if any of you are interested in sharing your opinions in person. Otherwise, I will have my notifications on if anyone prefers to respond here!

It is up to the marketplaces to decide what to do, this is an informational CIP so it merely advertises "this is what we wanna do, this is how we're going about it".
With that said, if you decide to go on that route, it should be a separate CIP which circles back to this one so that everyone can adopt it also and you can get wider adoption.
In addition, ideally the decision would be made by the NFT holders themselves thru an on-chain vote.

Apologies about my reply to your message.  I didnt realize I was replying to another person, and misunderstood the context of it.

I think paying the royalties to the address holding the 777 token is brilliant.
It allows people to not only move between wallets but also to sell their royalty rights.
Great idea!
(For what it's worth from apparently the only person that knows what a percentage means)

Not to mention that you can fractionalize said token like Fracada does and distribute the royalties among different team members in second stage of protocol execution.

Not to mention that you can fractionalize said token like Fracada does and distribute the royalties among different team members in second stage of protocol execution.

This idea, specifically was proposed by Fencemaker.  So he would deserve all of the credit if that were to be used.  But the reason we didnt do multiple tokens, and probably ultimately didnt further pursue using tokens is because of min-utxo.  But I dont think we stopped to consider leaving it as a single token.
Aside from this one change, I think everything else should remain unchanged with the 777 token.  It needs to be the first mint.  We only honor the first mint.  The rate/percent is locked in.  And its backwards compatible, because it either has an addr, or it doesnt.  If it doesnt, we query db-sync to locate it.  And its non commercialized.  I'm sure there will be many services pop up like $adahandle.  I was actually working on a similar concept earlier in 2021, but didnt see it through.  So leaving it as a no name token, keeps it true to its intent.
But regardless, I would want to have a meeting of the minds before introducing a potential change to the CIP.  The plan was to meet as needed every few months to discuss potential changes.  And I think it makes allot of sense at this point.  Adam Dean did a survey about a month ago.  At that time we had over 9000 royalty tokens.  Its very clear that the standard is being widely adopted.  And I've never opposed challenging views on it.  What I've opposed is a challenging view, with no proposal that worked that could replace it.  To date, no one has proposed anything viable.
I'm going to try to set up another meeting in the not too distant future.

I think paying the royalties to the address holding the 777 token is brilliant. It allows people to not only move between wallets but also to sell their royalty rights. Great idea! (For what it's worth from apparently the only person that knows what a percentage means)

You're both right and wrong a the same time.  I know that you're correct, that the language "rate" is technically correct.  But where this goes wrong is that we dont see rate used anywhere.  Mark was totally correct when he responded last night.  This was community driven, and really needed to remain using pct, as that was what the community decided.  You'll note I was completely opposed to making that change; and it was for that reason.  I finally caved because we were starting to get too many squeaky wheels making allot of noise (with no useful proposed replacements) who were opposing the standard.  It finally just made sense to adopt our change to get it across the finish line.
And, respectfully, the change was not appreciated.  And I'm not saying that for myself.  We made this change well over a month after the community meeting was completed. Everyone that participated when on with their lives, and used the standard as discussed.  I've been publicly lambasted by at least a couple for making the change; because they felt like we picked something, and then I personally arbitrarily changed it.
But the numbers also dont lie.  Out of the 9000+ 777 tokens, only something like 10 use rate.  The rest use pct.
I know you strongly feel that rate is the correct tag; and I understand why.  But take a step back and consider the bigger picture.  This is not something anyone else wants.  If I were to make any changes to the proposal, at this point, I would move back to pct because no one is using rate.

Regarding the proposed change:
It would be good to clarify the case where you have an existing 777 token containing an addr and what happens if it is sent to a different wallet.
A - If you stick with the addr then the existing projects don't get the benefit of the new feature.
B - If you go with the holder of the 777 token, it's possible a few existing projects sent the token somewhere where they don't want the royalties to go because they understood the addr to be permanent. My guess would be that would be a small number of cases.
This decision is important for people minting 777 tokens in the short term since if we go with A you would not want to include the addr in order to take advantage of t
he new feature but if we go with B you could include the addr so it works with current marketplaces and you would still be able to transfer the rights.
Lastly, what happens if the 777 token is burned?
Does that end all royalties whether it contains an addr or not?
Regarding the whole rate/pct thing, I understand your perspective and I am sorry if that caused undue trouble for you or any implementers.
With standards there is often tension between accepting common use and attempting to improve the standard.
I felt my proposal was a way of accomodating both.

I agree it would need to be backwards compatible.  I would expect that you
would have two choices; with a permanent address or follow the token.
I think we’re going to set up another meeting of the minds In the next few
weeks.  There’s enough interest at this point that it makes good sense.
And it was always intended to be revisited.  What we’ve seen is a wide
adoption from asset makers, but little in the marketplaces.  The only one
that provides native support is Tokhun.  Now that the space is more mature
and more people are aware of CIP-0027, the timing feels right.  Ping me a
good email so I can ensure you are invited.  @.***
I do know there are quite a number of minor proposed concepts that go hand
in hand.  And I also know some people want it to remain as is.  So it would
definitely be hotly debated.
On Sun, Jan 9, 2022 at 12:20 PM Shawn McMurdo @.***>
wrote:

Regarding the proposed change:
It would be good to clarify the case where you have an existing 777 token
containing an addr and what happens if it is sent to a different wallet.
A - If you stick with the addr then the existing projects don't get the
benefit of the new feature.
B - If you go with the holder of the 777 token, it's possible a few
existing projects sent the token somewhere where they don't want the
royalties to go because they understood the addr to be permanent. My guess
would be that would be a small number of cases.
This decision is important for people minting 777 tokens in the short term
since if we go with A you would not want to include the addr in order to
take advantage of t
he new feature but if we go with B you could include the addr so it works
with current marketplaces and you would still be able to transfer the
rights.
Lastly, what happens if the 777 token is burned?
Does that end all royalties whether it contains an addr or not?
Regarding the whole rate/pct thing, I understand your perspective and I am
sorry if that caused undue trouble for you or any implementers.
With standards there is often tension between accepting common use and
attempting to improve the standard.
I felt my proposal was a way of accomodating both.
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/116#issuecomment-1008367267,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASZQAMGFQEQ4WRWUPQXVD5LUVHUYXANCNFSM5CFGGCAQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

I agree it would need to be backwards compatible. I would expect that you would have two choices; with a permanent address or follow the token. I think we’re going to set up another meeting of the minds In the next few weeks. There’s enough interest at this point that it makes good sense. And it was always intended to be revisited. What we’ve seen is a wide adoption from asset makers, but little in the marketplaces. The only one that provides native support is Tokhun. Now that the space is more mature and more people are aware of CIP-0027, the timing feels right. Ping me a good email so I can ensure you are invited. @.*** I do know there are quite a number of minor proposed concepts that go hand in hand. And I also know some people want it to remain as is. So it would definitely be hotly debated.
…
On Sun, Jan 9, 2022 at 12:20 PM Shawn McMurdo @.> wrote: Regarding the proposed change: It would be good to clarify the case where you have an existing 777 token containing an addr and what happens if it is sent to a different wallet. A - If you stick with the addr then the existing projects don't get the benefit of the new feature. B - If you go with the holder of the 777 token, it's possible a few existing projects sent the token somewhere where they don't want the royalties to go because they understood the addr to be permanent. My guess would be that would be a small number of cases. This decision is important for people minting 777 tokens in the short term since if we go with A you would not want to include the addr in order to take advantage of t he new feature but if we go with B you could include the addr so it works with current marketplaces and you would still be able to transfer the rights. Lastly, what happens if the 777 token is burned? Does that end all royalties whether it contains an addr or not? Regarding the whole rate/pct thing, I understand your perspective and I am sorry if that caused undue trouble for you or any implementers. With standards there is often tension between accepting common use and attempting to improve the standard. I felt my proposal was a way of accomodating both. — Reply to this email directly, view it on GitHub <#116 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZQAMGFQEQ4WRWUPQXVD5LUVHUYXANCNFSM5CFGGCAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.>

I could not find any way to direct message you so I'm posting here.
You can reach me at<EMAIL_ADDRESS>.

Not to mention that you can fractionalize said token like Fracada does and distribute the royalties among different team members in second stage of protocol execution.

This idea, specifically was proposed by Fencemaker. So he would deserve all of the credit if that were to be used. But the reason we didnt do multiple tokens, and probably ultimately didnt further pursue using tokens is because of min-utxo. But I dont think we stopped to consider leaving it as a single token.
Aside from this one change, I think everything else should remain unchanged with the 777 token. It needs to be the first mint. We only honor the first mint. The rate/percent is locked in. And its backwards compatible, because it either has an addr, or it doesnt. If it doesnt, we query db-sync to locate it. And its non commercialized. I'm sure there will be many services pop up like $adahandle. I was actually working on a similar concept earlier in 2021, but didnt see it through. So leaving it as a no name token, keeps it true to its intent.
But regardless, I would want to have a meeting of the minds before introducing a potential change to the CIP. The plan was to meet as needed every few months to discuss potential changes. And I think it makes allot of sense at this point. Adam Dean did a survey about a month ago. At that time we had over 9000 royalty tokens. Its very clear that the standard is being widely adopted. And I've never opposed challenging views on it. What I've opposed is a challenging view, with no proposal that worked that could replace it. To date, no one has proposed anything viable.
I'm going to try to set up another meeting in the not too distant future.

We're still trying to decide how we want to handle the ADA Clouds case where the creator rugged the project after minting the royalty token and never paid the artists.
If I understand correctly, the purpose of this proposal is to enable buyers of an NFT collection to have a guarantee that the royalty percentage won't be changed on them in the future thus potentially harming their investment.
In this view, it should be okay for us to modify the address, but not the percentage of the minted royalty token. Does anyone object to this? We really want to support ADA Clouds given the scenario, their community had a vote with something like +95% approval that they didn't want to trade on any marketplaces honoring the original royalty token. Furthermore, it seems the folks here are planning to create a 2nd version of this proposal which would allow for the royalty token to switch addresses regardless.

Its not that cut and dried. You have to consider both 1) Strain on the marketplaces. Every time something changes, we're effectively telling them they need to make code update. 2) Min-utxo.
…
On Mon, Jan 10, 2022 at 9:15 AM Blake Brown @.> wrote: Not to mention that you can fractionalize said token like Fracada does and distribute the royalties among different team members in second stage of protocol execution. This idea, specifically was proposed by Fencemaker. So he would deserve all of the credit if that were to be used. But the reason we didnt do multiple tokens, and probably ultimately didnt further pursue using tokens is because of min-utxo. But I dont think we stopped to consider leaving it as a single token. Aside from this one change, I think everything else should remain unchanged with the 777 token. It needs to be the first mint. We only honor the first mint. The rate/percent is locked in. And its backwards compatible, because it either has an addr, or it doesnt. If it doesnt, we query db-sync to locate it. And its non commercialized. I'm sure there will be many services pop up like $adahandle. I was actually working on a similar concept earlier in 2021, but didnt see it through. So leaving it as a no name token, keeps it true to its intent. But regardless, I would want to have a meeting of the minds before introducing a potential change to the CIP. The plan was to meet as needed every few months to discuss potential changes. And I think it makes allot of sense at this point. Adam Dean did a survey about a month ago. At that time we had over 9000 royalty tokens. Its very clear that the standard is being widely adopted. And I've never opposed challenging views on it. What I've opposed is a challenging view, with no proposal that worked that could replace it. To date, no one has proposed anything viable. I'm going to try to set up another meeting in the not too distant future. We're still trying to decide how we want to handle the ADA Clouds case where the creator rugged the project after minting the royalty token and never paid the artists. If I understand correctly, the purpose of this proposal is to enable buyers of an NFT collection to have a guarantee that the royalty percentage won't be changed on them in the future thus potentially harming their investment. In this view, it should be okay for us to modify the address, but not the percentage of the minted royalty token. Does anyone object to this? We really want to support ADA Clouds given the scenario, their community had a vote with something like +95% approval that they didn't want to trade on any marketplaces honoring the original royalty token. Furthermore, it seems the folks here are planning to create a 2nd version of this proposal which would allow for the royalty token to switch addresses regardless. — Reply to this email directly, view it on GitHub <#116 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.>

Applies in the case of multiple royalty addresses.

I understand 1) the strain on other marketplaces. I suppose it is up to each marketplace to decide how they would prefer to handle these situations.

Indeed.
The second round community discussion will be starting up in a couple of
weeks.  If you feel like you have something to contribute, and would like
to participate, please reach out to me directly.  You can hit me up on my
huths0lo and/or cnfthub twitter.
On Mon, Jan 10, 2022 at 10:24 AM Blake Brown @.***>
wrote:

Its not that cut and dried. You have to consider both 1) Strain on the
marketplaces. Every time something changes, we're effectively telling them
they need to make code update. 2) Min-utxo.
… <#m_6482734460801158391_>
On Mon, Jan 10, 2022 at 9:15 AM Blake Brown @.> wrote: Not to mention
that you can fractionalize said token like Fracada does and distribute the
royalties among different team members in second stage of protocol
execution. This idea, specifically was proposed by Fencemaker. So he would
deserve all of the credit if that were to be used. But the reason we didnt
do multiple tokens, and probably ultimately didnt further pursue using
tokens is because of min-utxo. But I dont think we stopped to consider
leaving it as a single token. Aside from this one change, I think
everything else should remain unchanged with the 777 token. It needs to be
the first mint. We only honor the first mint. The rate/percent is locked
in. And its backwards compatible, because it either has an addr, or it
doesnt. If it doesnt, we query db-sync to locate it. And its non
commercialized. I'm sure there will be many services pop up like
$adahandle. I was actually working on a similar concept earlier in 2021,
but didnt see it through. So leaving it as a no name token, keeps it true
to its intent. But regardless, I would want to have a meeting of the minds
before introducing a potential change to the CIP. The plan was to meet as
needed every few months to discuss potential changes. And I think it makes
allot of sense at this point. Adam Dean did a survey about a month ago. At
that time we had over 9000 royalty tokens. Its very clear that the standard
is being widely adopted. And I've never opposed challenging views on it.
What I've opposed is a challenging view, with no proposal that worked that
could replace it. To date, no one has proposed anything viable. I'm going
to try to set up another meeting in the not too distant future. We're still
trying to decide how we want to handle the ADA Clouds case where the
creator rugged the project after minting the royalty token and never paid
the artists. If I understand correctly, the purpose of this proposal is to
enable buyers of an NFT collection to have a guarantee that the royalty
percentage won't be changed on them in the future thus potentially harming
their investment. In this view, it should be okay for us to modify the
address, but not the percentage of the minted royalty token. Does anyone
object to this? We really want to support ADA Clouds given the scenario,
their community had a vote with something like +95% approval that they
didn't want to trade on any marketplaces honoring the original royalty
token. Furthermore, it seems the folks here are planning to create a 2nd
version of this proposal which would allow for the royalty token to switch
addresses regardless. — Reply to this email directly, view it on GitHub
<#116 (comment)
https://github.com/cardano-foundation/CIPs/pull/116#issuecomment-1009145417>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ
https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ
. Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.>

Applies in the case of multiple royalty addresses.

I understand 1) the strain on other marketplaces. I suppose it is up to
each marketplace to decide how they would prefer to handle these situations.
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/116#issuecomment-1009206765,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASZQAMCDSA4WDLQAU7WGDATUVMP63ANCNFSM5CFGGCAQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Indeed. The second round community discussion will be starting up in a couple of weeks. If you feel like you have something to contribute, and would like to participate, please reach out to me directly. You can hit me up on my huths0lo and/or cnfthub twitter. On Mon, Jan 10, 2022 at 10:24 AM Blake Brown @.> wrote:
…
Its not that cut and dried. You have to consider both 1) Strain on the marketplaces. Every time something changes, we're effectively telling them they need to make code update. 2) Min-utxo. … <#m_6482734460801158391_> On Mon, Jan 10, 2022 at 9:15 AM Blake Brown @.> wrote: Not to mention that you can fractionalize said token like Fracada does and distribute the royalties among different team members in second stage of protocol execution. This idea, specifically was proposed by Fencemaker. So he would deserve all of the credit if that were to be used. But the reason we didnt do multiple tokens, and probably ultimately didnt further pursue using tokens is because of min-utxo. But I dont think we stopped to consider leaving it as a single token. Aside from this one change, I think everything else should remain unchanged with the 777 token. It needs to be the first mint. We only honor the first mint. The rate/percent is locked in. And its backwards compatible, because it either has an addr, or it doesnt. If it doesnt, we query db-sync to locate it. And its non commercialized. I'm sure there will be many services pop up like $adahandle. I was actually working on a similar concept earlier in 2021, but didnt see it through. So leaving it as a no name token, keeps it true to its intent. But regardless, I would want to have a meeting of the minds before introducing a potential change to the CIP. The plan was to meet as needed every few months to discuss potential changes. And I think it makes allot of sense at this point. Adam Dean did a survey about a month ago. At that time we had over 9000 royalty tokens. Its very clear that the standard is being widely adopted. And I've never opposed challenging views on it. What I've opposed is a challenging view, with no proposal that worked that could replace it. To date, no one has proposed anything viable. I'm going to try to set up another meeting in the not too distant future. We're still trying to decide how we want to handle the ADA Clouds case where the creator rugged the project after minting the royalty token and never paid the artists. If I understand correctly, the purpose of this proposal is to enable buyers of an NFT collection to have a guarantee that the royalty percentage won't be changed on them in the future thus potentially harming their investment. In this view, it should be okay for us to modify the address, but not the percentage of the minted royalty token. Does anyone object to this? We really want to support ADA Clouds given the scenario, their community had a vote with something like +95% approval that they didn't want to trade on any marketplaces honoring the original royalty token. Furthermore, it seems the folks here are planning to create a 2nd version of this proposal which would allow for the royalty token to switch addresses regardless. — Reply to this email directly, view it on GitHub <#116 (comment) <#116 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ https://github.com/notifications/unsubscribe-auth/ASZQAMCJRJEEGOXFSF6NF73UVMH2DANCNFSM5CFGGCAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.> 1. Applies in the case of multiple royalty addresses. I understand 1) the strain on other marketplaces. I suppose it is up to each marketplace to decide how they would prefer to handle these situations. — Reply to this email directly, view it on GitHub <#116 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZQAMCDSA4WDLQAU7WGDATUVMP63ANCNFSM5CFGGCAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.**>

I have been thinking in ways to handle fake NFTs but I'm sure its going to have to be a joined effort with markets and asset makers too. I've been thinking in the idea of using a MD5checksum for the metadata of the minted transaction. We asset makers should verify within our history for the existence of a minted asset and "flag" them accordingly I supposed, where a MD5checksum can be stored, indexed and be quickly available  to verify the uniqueness of the computed file within our systems.
Now, if there is a way to appended to the NFT transaction or something else that could exist that I don't know of that could be really nice lol