CIP Royalties-777 version 2.0

Hey everyone,

After talking to some folks in the community (artists, artist managers, devs) and a 2h discussion internally to make things better for the future of Cardano, I decided to post this CIP proposal on a parallel or different royalties standard before the current one is merged.

Software is opinionated, and I’m just sharing my thoughts on the current proposal and how we can make it better. I would like to start a constructive conversation around enabling all artists to create and collaborate on Cardano, without focusing on either high-volume or 1/1 collections, with the creatives’ user experience and cutting costs wherever possible always on mind. Please give me feedback on this proposal and take everything I write with a grain of salt. I understand some projects started working with the current proposal, but it hasn’t been merged yet.

If a lot of people already implemented the proposed royalties standard, I can of course comply, but I just don’t believe in the long-term vision of the currently proposed royalty standard.


Artano was one of the first (if not the first) to put royalties in an NFT metadata in July 2021, during our first auction. This was also the first automated UI-based auction, outside of the discord space on Cardano.

The royalties data structure that was chosen was a quick solution, and we didn’t give it much thought: you have an object with an address and a royalty percentage. Now we understand that this was not good for the network, and that it was also not good for the artists who would like to collaborate and add more than 1 royalty address. Only 15 iNFTs were minted with this royalties implementation that’s on the chain right now.

What is the problem with the current standard?

The current standard was made to fit large collections of hundreds or thousands of NFTs, where you would want to set a single royalty fee with the unnamed token per policy. This means you’d pay the extra ADA for the royalties token ONCE if you have a big collection. Under that policyID you must have the same royalties/addresses for each of your NFTs under the policy, which is predefined upon minting and decided by a centralized authority. We run into a problem when it comes to 1/1 NFTs, donations or collaborations, where people might want to distribute royalties differently with each NFT they mint:

  1. Collaborations would be more centralized: The problem is when it comes to collaborations of 2+ artists under 1 policyID; they have to agree on a single royalty fee according to the current standard; it does not work well for single policyID collaborations, where artists work on a common theme, without relying on a centralized authority to decide royalty fees for them. This also means that 2 artists have to receive the same royalties in a collaboration to one address, even though one of them might be “pulling the weight” of the project, and has more experience/did more work. Writing a smart contract for this is possible, but it would be an overkill for something that could be solved through a simple json object array (more about this below).

  2. Unnecessary dependency between PolicyID and Royalties: You cannot change a royalty fee on your NFTs, unless all of them have separate policy IDs. This creates a dangerous dependency of unrelated data: policy IDs and royalties.

a) Burdening approval processes: Linking royalties to policyIDs would lead to creating more policyIDs, which would further burden other marketplaces that rely on approving projects by policy ID (especially for people who mint outside a marketplace). It would take marketplaces like a lot more time to approve each 1/1 NFT, since artists would only be able to change royalties if they mint an NFT with a new policy.

b) Current standard isn’t future proof: You have to create a new policy ID, just to create a new royalty - we’re creating a dependency that could give us headaches in the future. PolicyID should just be a signature by which an artist is recognized, not tied to other parts of the metadata.

Comment: This isn’t fixed by storing approved IDs on each marketplace’s repo, since it excludes independent artists and projects that don’t want to rely on any marketplace. We’re just creating more policyIDs in order to distribute royalties - again, an unnecessary dependency.

  1. There’s an unnecessary cost of minting an unnamed token, just to set a json object. This can actually be done off-chain or by checking the initial state of the NFT when it was minted from the ledger.

  2. The current solution might not scale over time, when there are thousands of creatives making 1/1 NFTs, where each NFT has its own royalty. Ten years from now, we might have hundreds of thousands of artists, and each of them could have hundreds of policy IDs, since they will collaborate, or want to donate to a different charity with each NFT. Yes, storage is getting cheaper, but why add this unnecessary (computational) cost.

The proposal

I propose that the royalties are independent and decoupled from policyID’s. Each artist and project should specify their royalty percentage independently, per mint. This means that there’s no need to create new policies, just for the sake of changing royalties. This proposal gets rid of a dependency in the metadata of 2 unrelated elements (signature/ID and commissions/royalties) and lowers the number of needed policyIDs, which will be increasingly many in the years to come.

The proposal is to have a simple link that is part of the metadata. Yes, this gives people opportunities to change their NFT royalties, but we can always refer back to the initial state of the NFT when it was sold from the ledger. This also allows changing royalties before the first sale happened.

Therefore I propose the following:

777: {
  addrX: pctY
  addrZ: pctXY

The smart contract would just have to read an object of key/value pairs and distribute appropriate percentages upon sale.

If you have any comments or amendments to this proposal, I’m always open to feedback. If you think this proposal is crap and it gets rejected because the community already started implementing according to the old standard (even though it wasn’t approved), I can comply and understand the hassle, but I believe we can do better, especially with scaling and user-friendliness to non-Cardano natives in mind (especially artists, to whom understanding the intricacies of policyIDs and how royalties are implemented on Cardano are an overkill).

Remember, NFTs should be accessible to creatives and we want to expand Cardano to more artists, not just developers or people who are already in the Cardano ecosystem.

PS. This is not to invalidate anyone’s hard work, but to improve the current standard proposal. If we can do this by tweaking the current proposal and decoupling royalties from policy, that would be great, but I don’t see a solution at the moment. Also ideas on going on-chain with this thru SCs would be much appreciated, to exclude having this as a link off-chain.


Although the 777 design is meant to have the ability to evolve, deciding that its not ideal for you, doesnt make it bad. The 777 standard was developed through a tremendous effort within the community; and Artano was invited to these discussions. If you make another standard, its no longer a standard. If you want to evolve the 777 standard, its going to require working with the community. The current iteration has already been adopted extensively. So digging your heels in and saying that you’d prefer a different way, because its too much work for you, doesnt magically invalidate all of the previous discussions and events that took place prior.

So if you want to see the standard change, its going to require more than this post.

1 Like

This has nothing to do with hard work, we’ve alread started implementing the solution that was suggested. It has to do with the future of Cardano NFTs. As I’ve said this is a proposal and we can build off of this. Linking PolicyIDs with Royalties isn’t a good strategy in the long run, since marketplaces have to approve each policy and this would just create more policies to approve, only because someone wants to distribute royalties differently (edit: on a 1/1 NFT, or collab). Policy and Royalties should be decoupled.

As told to you directly on Telegram, the delay in getting policy id’s approved is because that repository was implemented by one person, and not designed to scale. That isnt a problem with the 777 standard. Its a problem with everyone using the policy id repo, and them not updating it regularly.

I’ve already proposed to the community that major cnft developers, such as Artano, have their own repo, and all of the major marketplaces scan through all of the repos. I’ve also told you that if you allow people to put the royalty in the metadata of each token, its as easy as overwriting that metadata to change the royalty. This is a non starter. Having the ability to place the royalty off chain creates the same problem. These were all ideas discussed during the 777 conversations, and were shut down for this exact reason. You’re proposing something that the community members already flatly rejected.

1 Like

I dont want to keep revisiting this, so this is going to be my last reply to this thread. These are some facts that you obviously havent let sink in.

  1. You were invited to the conversations for royalty implementations. Which means your voice was heard.
  2. If you want to go review CIP-0027, you’ll find that the very first draft is exactly the way you described it.
  3. A community standard has to be voted on democratically by the community leaders. That was done. And this design you’ve proposed was rejected.
  4. Your proposal is not the only one that was rejected. There was allot of bright minds who put allot of time and effort in to this. In the end a concesus was decided; and that concensus is what you see in the current version of CIP-0027.
  5. If you now decide you’re not interested in the approach from CIP-0027, you are going to be doing a huge disservice to your clients. Because the two biggest marketplaces are going to use the design from CIP-0027. You will be abandoning the community; since it was the community that decided on this democratically.
  6. CIP-0027 doesnt even need to exist. The design has already moved forward. The reason CIP-0027 is continuing to go through the process of being merged is because it really needs to be visible for anyone who needs to find the standard; and for it to be from a legitimate source.
  7. Its always been planned to revisit the 777 standard to decide if it needs a revision. Bickering on this forum isnt going to accomplish that. You need to organize a call with the community leaders to have this discussion.
  8. Any design you propose, that has the ability to be modified, will be handily rejected.
1 Like

You mention “overwriting that metadata to change the royalty”.

Wouldn’t this require the asset to be burned and a new one to be minted in its place?
Or is there another way the metadata can be changed?

Artano has nothing to do with this proposal change. Artano will implement both solutions, the one that adds flexibility to its users, and the CIP-0027. I am writing this as a dev, Matt, not as a founder.

The proposal hasn’t been merged yet, and there is already one group of developers writing a universal marketplace contract (I’m not included in this), which will hopefully make all marketplaces collaborate.

Again, this was a proposal, and I hope you don’t take it personally. I just want Cardano to improve and see how we can all make a standard that works for everyone in an open forum.

I don’t take anything personally, so you don’t have to worry about any hard feelings. But I still think you need to start the conversation with the existing markets and nft makers. You can write whatever proposal floats your boat. But you’ll need buy in from the community to get anywhere with it. And I’ve just told you why the approach you’ve mentioned likely wouldn’t.

1 Like

The fresh consensus from today’s CIP meeting (this link documents both the verbal discussion & chat) is that we are now eagerly awaiting a new CIP from the Artano reps which fully documents the alternative approach :sunglasses:

As per our discussion with the foundation today, we’ll propose an enhancement to the current standard. Since the one right now has been implemented, we can make the new one backwards compatible - this is for those who were worried that we want to write a completely new standard.

Will post the github link once it’s written. Thanks! :v:

1 Like

Hi quick question, trying the 777

Text string metadata value must consist of at most 64 UTF8 bytes, but it consists of 108 bytes.
It doesn’t accept the long string 2 address in array, am I missing something?

Each line in your metadata has to be 64 characters long.

Snippet from some random NFT metadata:


To be clear, this is one long string that they had to split up.

The 777 token isnt for creating an NFT. Its for creating the royalty stamp on the policy. Please read through the CIP-0027 proposal. It explains in detail how to implement it.

1 Like

Trying to catch up on all this. I’m still fairly new to Cardano and just familiarizing myself with CIPs and things :slight_smile:

I’m creating MintedWithLovelace which is a decentralized (dapp) nft launchpad and 2ndary marketplace. I wanted to build in royalty standards and was totally unaware of what the current standards are, etc., to obviously see if I can implement existing mechanisms.

My first thoughts were to create a smartcontract which can be viewed easily and creators could deposit an amount of a special “royalty” token, in who’s metadata is their policy hash used to create the target policy id, along with that target policy script details for validation and the royalty token itself’s policy script for ownership validation. The amount of token 10 for example = the % so 10%. over the target (target can be self)…and if the policy isn’t locked the user could mint these royalty tokens for the current policy, and anyone could take a given token for sale, get its policy id, concat “royaltycontrol” in hex or some expected name, then query for that asset. If it can’t find it, it checks a global smart contract.

If there is a method already in place in a decentralized way, where I don’t have to involve github or something similar, I’d love to learn and see how I can implement that. Where do I go to see the CIP being referred to in this post (and/or) whatever the CIP being used most or moving toward adoption? Thanks!

Nevermind! I found it and added an “issue” for proposing the idea of how to handle previous/locked mints.

I’m working on an NFT launchpad (markeplace to come) dapp and implementing automated 777 minting on the onset of a policy/campaign launch. A couple questions:
1 - Can the 777 be minted and immediately burned? Any advantage/disadvantage and what are the standards for marketplaces with regards to this, or where it’s sent etc after minting?
2 - I’m curious to read any CIP you have as I had done some thinking through some scenarios wherein a creator may want or need to update their payout address at a minimum, and did a write up on how this could be achieved utilizing a combination of SC and clever metadata proofs, post slot locking: MintedWithLovelace/dapp-smartcontracts/global-registry at main · MadeWithLovelace/MintedWithLovelace · GitHub and wanted to see if there is any value here for working together toward improving the current CIP.


I made the mistake of leaving the 777 token unburned and even sent it to my wallet with the NFT’s. The presence of the 777 token in the android ADAM app was enough to crash it. Probably best to either leave it at the minting address or burn it.

I began the NFT verification 808 proposal based on the 777 draft. Sounds like maybe some of you would have chosen per asset rather than policy? Maybe come have a look at what we are trying to do and share your input.

Maybe have a look at the 808 proposal. It copies the 777 functionality but adds off chain correlated accounts to verify collections.

@Huth_S0lo How does a proposer get developers from the stores to come and look at a proposed cip? Ive started the one linked above but have no idea if any store developers are aware. I think it might benefit all stores.

You just reach out to them :slight_smile: