CIP Draft - NFT royalties functionality expansion

Simple Summary

Royalties are an important part of the Cardano NFT ecosystem and its sustainability. They are one of the main ways to continuously fund project creators, authors and artists through sales on the secondary market and, if implemented correctly, remove the need for outside funding. This CIP proposes an update to CIP 27 which has not really been adopted by the community. The aim is to have a simple, easy to use standard that supports distributing royalties to multiple addresses and updateable royalties.


This CIP proposes a creation of two different policies:

  1. Main project policy - can be open or closed - contains all the authors NFTs
  2. Royalty policy - can be open or closed, but has to be open to have updateable royalties - contains only a single royalty NFT

Main project policy can be open or closed, only important thing is that it contains a royalty reference token. Royalty reference token points to the royalty policy which always contains a single royalty NFT. This royalty NFT can be burned and re-minted at any time. This gives flexibility to the authors to update the royalties as they wish and an exact place for marketplaces to read the data. Expanded royalty NFT standard is presented in this CIP to support multi-address royalty dispersion.


The CIP 27 was written soon after NFTs became possible on Cardano. Motivation behind it was to have some sort of a quick royalty standard that the community can follow without the need to implement smart contracts. It is nice and simple, but somewhat limited. Unfortunately, it was not largely accepted by the community and by the key stakeholders in the Cardano NFT ecosystem. Authors wanted more flexibility with the royalties while keeping the simplicity of CIP 27. It also became an unwritten rule that NFT policies should be locked. That is why we expanded CIP 27 to adapt to the development of Cardano.


Royalty token standard (777)

We are expanding the 777 token described in CIP 27 simply by stating that more than one address can be added to the array within JSON and changing the rate property to array type.

	"777": {
		"rate": [
		"addr": [

In this example following royalties are applied to following addresses:

Royalty Address that receives the royalty
10% addr1q8g3dv6ptkgsafh7k5muggrvfde2szzmc2mqkcxpxn7c63l9znc9e3xa82hpf39scc37tcu9ggy0l89gy2f9r2lf7husfvu8wh
12% addr1q8l6e8chpp2hna268ktg3tu6l37qe3e3n8qez9csjxw75s8l4j03wzz4086450vk3zhe4lrupnrnrxwpjyt3pyvaafqqc94x78
5% addr1qycgag4mkeghnhfa2dcm9pgqrdnteu6t6rh7exkz8r6cdhutz5rw6ughfl3z0ct20ayusyaqkzwvwssgjce83re3xwvqe09gm4

Addresses are broken up in 2 array elements because of 64 character per line limitation.

Royalty reference token standard (776)

We are defining a new token standard to reference a policy ID which keeps the royalty token.

	"776": {
		"policy": "d5e6bf0500378d4f0da4e8dde6becec7621cd8cbf5cbb9b87013d4cc"


Several other designs were considered:

1. Simply keeping the NFT policy open and minting and burning the royalty token

This would be a minimal expansion of CIP 27 but would force the policy creator to have an open policy

2. Create a standardized royalty transaction

This on-chain transaction would contain a standardized message in metadata with updated royalty fee. This idea was abandoned because of a radical change from the current practice.

3. Referencing the royalty policy ID from the main policy ID

This idea considered adding a field in the policy script that would reference another policy that contains the 777 token. This solution would be a bit more elegant because it would remove the need to mint a 776 token, but it would require a protocol level change, so it was abandoned.

4. Creating a fungible token

This idea consisted of reference token like in the currently proposed solution, but instead of having a 777 token, the referenced policy would contain fungible tokens and royalties would be distributed to the addresses that own fungible tokens in percentage that is owned. For example, if the total supply of fungible tokens is 1000 and wallet A holds 100 tokens, wallet A receives 10% royalties. We are still considering this idea and how to possibly include it.

5. Smart contract

Creating a standard smart contract for royalty dispersion, auditing it and testing it would be a final solution. Currently, this idea takes a lot of time, money and energy and we came to the conclusion that it is not the right moment for it. We do, however, see a smart contract solution replacing this CIP in the future.

Backward Compatibility

This CIP was developed keeping in mind the state of the Cardano NFT ecosystem at the time of writing and we made our best efforts how to keep it as backwards compatible as possible. Existing projects with open policies can easily mint a 776 token and open a new policy with the royalty token, so this CIP is fully backwards compatible with them. Unfortunately, projects with closed policies are not compatible with this CIP. If enough interest is shown from all stakeholders, it is possible to implement a standard for closed policy projects based on idea 2 described above.


my impressions, mostly to start a wider discussion about this:

CIP 27 … has not really been adopted by the community

A workable CIP submission would have to go into more detail about this: at least quoting a source, and perhaps citing a reference implementation if there was one (e.g. a CIP-27 implementation which the community didn’t adopt).

And mainly… if this could be written so it’s backwards-compatible with CIP-27 (offhand I don’t see why applications couldn’t check "rate" to see whether it’s an array) that would help it get through the CIP process, considering how many agencies were backing CIP-27 as it was written (from Abstract):

It has been developed with input from Artano, BuffyBot,, Digital Syndicate, Fencemaker, MADinArt,, Hydrun, Tokhun, and many more.

At some point all these stakeholders agreed that the proper way to more finely distribute royalties was with a smart contract & it’s likely they considered this approach already. I would be interested in bringing them into the discussion to document more about why they didn’t write it that way from the beginning (and would they do it any differently now?).

The rest is beyond me since I’m not an NFT expert. The one thing I would be sure of is that the addition of Royalty reference token standard (776) doesn’t make it possible to change the royalty rules after a token is released… the consortium that developed CIP-27 seemed pretty emphatic about that, which to me makes common sense.

Copying the main participants of prior forum thread - CIP - Royalties (I would want to do the same with contributors to PR#116 if & when you make a pull request on GitHub): @Huth_S0lo @DeFi_Authority

I really don’t agree that CIP-27 wasn’t adopted since all minters do it and marketplaces respect it… But that is actually besides the point.

Trying to do updatable and multi-address royalty distribution, I agree that this is a clean way to do it with a 776 pointing to a 777 token in another policy. This also allows pointing multiple policies of the same project to a single 777 reference token determining the royalty split for all collections.

As for idea 4 (that I keep pushing for): the main value is that, rather than require a minting and burning of the 777 token to update shareholders and/or their addresses, it becomes a free market. This allows an investor to be “paid” in royalty tokens, but also it allows the selling of royalty tokens in a decentralized manner. I would implement that by keeping the 776 pointing to a policy and then, in that policy emit a 777 fungible token with the metadata specifying only the total “rate”. Split and destination is determined by the token distribution.

And, yes, like we said way back when in the original CIP-27: I personally agree this will end up in Smart Contracts in the near future but that it is (still) not time yet.

And the third rate string in the array is missing a double quote and is invalid JSON. :wink:

And it says 0.05 but the table right after says 10%.

Fixed, thank you!

Hi Robert, thank you for your comments!

For CIP 27 adoption - we will work on getting more factual data on this.

For backwards compatibility with CIP 27 - understood, we will expand a little to cover those cases.

For getting stakeholders involved - working on it!

About changing the royalty rules after token release - this is one of the points of this new standard, stakeholders agreed that royalty fees and addresses that receive royalties should be updateable after minting. I understand we need more community members to state this beyond doubt.

Thank you again!


The evidence for CIP 27 not being widely used is documented quite clearly in the recordings and transcripts of our roundtables.

Just a few examples:

JPG store, which is by far the most consequential actor as of now, uses their own proprietary database to manage royalties and only defaults to CIP 27 when they lack any other data, which in practice is probably close to never, because creators must manually submit royalties information as part of their verification request.

The minting service that JPG Store provides also doesn’t mint a royalty token by default, again preferring their proprietary solution.

Since currently accounts for almost 98% of the volume on Cardano (Cardano NFT Data: market cap, size, data, growth, value in chart - OpenCNFT), it’s probably safe to say that CIP 27 hasn’t been fully adopted.

Artano have also indicated that they use another system for royalties and only fall back to CIP 27 as a last resort.

Fibo, the marketplace and minting service launched by Emurgo, has actually preferred not to support royalties at all due to the limitations with the current standard. While Fibo is not widely used or even known, it reflects the position of one of Cardano’s founding entities on the matter.

Hope that doesn’t come across as combative :slightly_smiling_face:, but there’s actually a wide body of evidence that CIP 27 is not being widely used.

In terms of this solution, we see it as a temporary evolution which will hopefully be replaced by something more robust, perhaps a protocol level change.

1 Like