First draft discussion

[SamDelaney]

NOTE: This PR will remain as a draft and be closed once a second draft is finalized. The actual merge from this branch into master will be done in the CF Cips repo, after third draft is finalized.

[SamDelaney]

Right now, this pretty much just represents my understanding of how Nebula royalties work with CIP68.

There's a couple ideas I may want to add / propose, such as introducing asset-specific royalties. I haven't gotten to fleshing those out in my head yet though. If you guys have other ideas you'd like to propose, please include them here for discussion. I will drop my ideas here as well once I get my head around them.

[SamDelaney]

Fixed the token name to match nebula implementation since I hadn't meant to depart from it.

I do have something of an issue with the way the nebula implementation tethers royalties to collections, but I think that's likely better addressed with a more robust datum structure than by allowing multiple royalty data. Still mulling this idea over.

[SamDelaney]

Regarding the above ^ we decided against departing from the most basic implementation. We intend to first push a simple, forward compatible base for royalty information to ensure it passes the CIP process, and then follow with improvements such as multiple royalties which may be more controversial.

[SamDelaney]

A couple realizations from my review today:

1: In the current implementation & specification designed by Ales for Nebula, neither to policyId nor the tokenName of the royalty NFT needs to be related to the collection. This completely breaks the lookup paradigm used for the 3 other token types.

Solutions I've come up with are:

• Enforce that the policyId must match that of the user token
• Leave out the lookup section, as looking up the royalty based on the user token is impossible

I lean toward the former, but that would break some of the Nebula royalty NFTs that have already been minted. I expect Ales had some solution in mind for lookups, but want to get your feedback before I ask him. @colll78 @solidsnakedev

2: Although it isn't specified anywhere yet, I wonder if we may have more luck passing this solution if we specify some limitation on validation rules for the script the royalty NFT is locked at. (Probably just an always-fails script for now, complicating validation too much sounds like a good way to alienate people.)

I'm leaning away from this for our first/second drafts; I figure we can introduce that if people request it in the public review, but again interested in your input.

[solidsnakedev]

My understanding when reading our Onchain solutions is that , we mint 3 tokens with the same Minting Policy ID

• NFT TokenName + label 100 -> lock at MetadataControl Script
• NFT TokenName + label 222 -> lock at user wallet
• Royalty token name + label 500 -> it's not clear yet but it may be lock at AlwaysFails script or a RoyaltyControl script with some metadata constrains

I think It's possible to find the royalty info if we do the follwing:

• Fetch the NFT PolicyID from wallet's user
• Build lucid Unit
  royaltyUnit = toUnit ( PolicyID, fromText("Royalty"), 500)
• Query Royalty token at AlwaysFails script or RoyaltyControl script
  royaltyUTXO = lucid.utxosAtWithUnit( RoyaltyControlAddress, royaltyUnit)

IMO Nebula solution is far away from what we're proposing, since Ales made it so that it only works with his marketPlace contract, and we might as well consider using a different royalty label.

[SamDelaney]

I went ahead and made the policyId match required. Since there are a lot of possible valid designs for royalty control, I left out specifying it at all.

I believe this should be ready to pass on to Ales / Nick etc. for their thoughts.

[SamDelaney]

Closing. Will create a second draft PR so we have a clean slate as we gather collaborator input.