CIP - Royalties

Developers CIPs
1

The following parties have provided input on this CIP: Digital Syndicate (Cardano Budz) @Huth_Solo, Adam Dean (Buffy Bot), Artano @DeFi_Authority, & CNFT.io @Stale.

I believe there is a misunderstanding in the community on how royalties for NFT’s would work when smart contracts come out. I believe that Smart Contracts wont directly address royalties. Since this seems to be something highly desired, with many people “waiting for smart contracts” for this exact thing, its going to be necessary to create a community standard that is enforced through the CNFT markets, and any future dApps. My proposal is very simple. Use a single metadata tag of “royalties”, which points to an off chain json. This would work the same way stakepools register all their ticker information. Since it points offchain, the contents of this json can evolve, and be updated over time.

percentRoyalties: 10.0
paymentAddress: addr1122334455
version: 0.1

Allot more info can be added of course. And as the final iteration of this json’s content evolves, the version number would be advanced. Marketplaces would of course have to respect the tags. But right now, there is no standard. So this proposal can get that moving forward.

6 Likes
2

Thank you @Huth_S0lo for this post and the shout out!

As we spoke yesterday, Artano has proposed the following simple standard in JSON format:

royalty: {
            address: [...],
            percent: XX
     }

After talking to you yesterday we could also work with the following:


royalties: {
            address: [...],
            percent: XX
     }

JSON url or inline json work for us.

Happy to hear other proposals, let’s do this :muscle:

1 Like
4

This could be an option. The main consideration is backwards compatibility.

royalties: {
type: standard (or no type tag at all for backwards compatibility)
address: […],
percent: XX
}

royalties: {
type: multiple
primaryAddress: […],
primaryPercent: XX
secondaryAddress:
secondaryPercent:
tertiaryAddress:
tertiaryPercent:
quaternaryAddress:
quaternaryPercent:
}

1 Like
5

This seems like overkill for a structure that could just take a list like so: ?

royalties: [
   {
      "address": "asdfasdf",
      "percent": X
    },
    {
      "address": "asdfasfasdf",
      "percent": Y
    }
]
2 Likes
6

This is a very important topic for digital artists. The aftermarket has to be managed to support the original artist. There are many artist waiting on the sidelines because they dont trust the digital world will take care of them.

3 Likes
7

Just so everyone understands, Huth_S0lo is the snake who stole my multi-million dollar idea.

After months of discussions.
After countless assurances that I was on the team.
After countless hours of presentations.
After hours of teaching their team Haskell.

Once I helped them join the Plutus Pioneer Program, they realized they no longer needed me to create a much simpler version of my idea. I could release the screenshots, discussions of pay-to-win schemes and setting up the next shadow entity, but this should be enough.

CardanoBudz == CardanoCity == RetroNFTs == LovelaceMarketplace == NFTAtelier, and they never put their real names behind their work. Nuff said.

1 Like
8

Every single claim made here by Seamoss is not just demonstrably false; but its even comically false. It looks like we’re approaching restraining order time.

1 Like
9

Hi, I am a video game developer and I am really interested in links between Tokens and Games. I’ve just discovered this CIP on royalties and it’s a good thing that royalties can be done without smart contract. I think several persons can be involved in the creation of a token, so that could be great if we could specify more than one address and percent. Wouldn’t it be possible to use an array of object instead of a single object for the 777 tag for example ? Is there a mean for me to enter the discussion ?

1 Like
10

No. Because that burdens the marketplace, and creates challenges with minimum utxo. You can use the address of a smart contract if you want to distribute it; or you can write a script.

11

I understand. Thank you for your answer.

12

You are a comically bad liar! Allow me to demonstrate Huth’s true nature for all to see, in screenshots. You know you won’t take me to court because then all else I have on you becomes public record. If I had your resources, I’d already have sued you.

Woops! Looks like Seamoss brought receipts. This is how Huth disavows people he steals from:

  • SS1: Huth showing me the super-secret Dragon Egg because I’m a member of his team. Admitting the only purpose of the project is maximal profit.

  • SS2: Multiple hours on call with the core team, teaching them Haskell

  • SS3: Huth admitting that I am in the inner circle of his team.

What do you have to say for yourself, @Huth_S0lo?

13

Seamoss, I’m going to repsond to your three claims, and then I’m going to ask that you not contact me again.

SS1) Yes, you seemed to be trustworthy, so you were shared some of our secrets. Every CNFT project on the planet is focused on maximizing profits. You may be surprised to find out that literally every business on the planet has this same focus. The hardest part of any cnft project is determining a price point that will strike the balance between being to low (making it of low value), or too high, to make it so people dont want to buy it. Congratulations on figuring this out, and exposing our completely normal approach to business.

SS2) We had one phone call with you, that was 45 minutes long. You smoked weed throughout the entire call. You said you’d help us build a webstore, and never did. You said you’d help us get stickers created, and you never did. I dont know Haskell today, and have no plans to learn it. I dont know a single line of Haskell; period. And you certainly never showed me any. Making some dellusional claim online is not showing receipts. By the way, you’ve made several claims of this nature to other projects. I’ve lots of stories about you. You’re a pariah at this point.

SS3) Nope. That never happened. You wanted to do business with us, so we let you have some insider information. You didnt deliver on a single promise; and then went off on some batshit crazy rant in our discord. It was at that point that you were removed and banned.

Closing notes. Harass again online, and I’ll have to move forward with legal action against you. You’ve followed me around, and tried to smear my name at every opportunity. Defamation of character is a real thing; and you’ve long crossed that threshold.

14

That’s correct - defamation of character IS a real thing. You think I don’t know what you’ve said about me behind closed doors?

I’ll see you in court.

15

First of all great proposal love the work you put into this!
Quick question about the process on how to use this cip 777 …

here is the overall process stated as follows:

  1. Create policy for planned assets.
  2. Mint no name token with community standard royalties metadata.
  3. Burn no name token to free up UTxO (recommended, but not required).
  4. Mint planned assets using this same policy.

is it implied that i do step 4 with the “normal” label 721 ? or do i continue to use 777 but with the NFT Assets infos.

Thx

16

Correct. 777 is specific to the royalty. Once your 777 token is made, proceed as you normally would; whether it be 721, or some future derivative. Since there are other proposals for metadata, we chose a new tag so there would no conflict.

1 Like
17

I just noticed when minting a token on Tokhun with royalties registration … the Json field for the percentage is named “pct” in their metadata but in the current 777 the field is called “rate”
… am i missing sth here or is the implementation of Tokhun faulty?

18

Just opened this idea to explore: CIP-0027: Covering existing policy locked assets · Issue #168 · cardano-foundation/CIPs · GitHub

I’m creating a testnet demonstration now.

19

For anyone interested/following, here’s the write up on this and a proof of concept test performed on testnet. Feel free to use the testnet smartcontract to walk through the process: MintedWithLovelace/README.md at sandbox · MadeWithLovelace/MintedWithLovelace · GitHub

I believe this would work fairly efficiently and it allows for owner validation over the target policy ID you want to set royalty over, locks in a royalty % immutably, is very easy for anyone to query against any policy id, can be done anytime after so no reliance on knowing the royalty up front/planning, and most of the information can be obtained via simple cli calls.

This is what I’m looking to implement for MintedWithLovelace decentralized nft launchpad/marketplace. I’d love to hear feedback and discuss!

20

Yeah, someone made a stink about it being called pct vs rate. So the whole CIP process was held up until the change was made. If you read the CIP all the way though, its noted that you can still use pct; which is probably what 100% of everyone that uses it will do.

21

You still havent shown how this proves ownership over the policy; and you never explained the logic between wallet signing and policy signing. Policies and wallets are mutually exclusive and can exist without each other. On top of that, you can use any wallet you want, whenever you want to mint an asset with a given policy as long as the policy is still open.

More so, you havent explained why the community would want to allow someone to tack on royalties arbitrarily. Whats to prevent someone from appending 100% royalties as soon as their assets are all sold?