Royalty Enforcement Asset Class Proposal

[austbot]

UPDATE Nov 23 2022

The Doc has been updated and we moved it to a new location where we will begin MIPs in public.

https://github.com/metaplex-foundation/mip/blob/main/mip-1.md

Please read through the proposal and discuss it further here.

[jpbogle]

Thanks @austbot for opening up some discussion. I can add some thoughts from our perspective at Cardinal. We are quite familiar with the possible approaches here and the specific details so open to providing our view.

We’d initially like to encourage discussion here around 5 points in the proposal

1. Staking MPLX token: Given the below proposal, we don’t believe mandating staking of MPLX to be in the verified list to dissuade bad actors makes sense. Removal of bad actors and denying re-verification seems like incentive enough for good behavior, and requiring that protocols buy MPLX feels like an unnecessary barrier to entry to be included in the ecosystem. Curious for more comments on that

2. Identity system around transfers: While a federated identity is something that seems useful in other contexts, it seems complicated to be built into the same program and strongly hinders new user adoption. While there are ways to make this more seamless within a wallet/dApp, it seems like an unnecessary hurdle if a whitelist is already being employed. Can we get more details on why the allowlist of programs would not be sufficient and a multi-wallet federated identity is also required? Do we actually envision wallets will all implement some linking flow with time countdowns on when they can add a new wallet?

3. Creator driven upgrades: Many people believed that “MasterEdition” tokens were tokens that were forever user controlled. Breaking this assumption and allowing an authority to change fundamentals about the token that did not exist previously seems like breaking the trust and creator/buyer agreement. It also sort of breaks trust in the core protocol if it can always be updated to change what should be contracts that are more or less immutable or at least forwards compatible forever (this is effectively reducing functionality in a breaking manner). Would be much more in favor of spending efforts building out user driven upgrade/migration solutions.

4. Metaplex “god mode”: At the end of the day, we view rulesets and their accompanying allowlists as a setting that creators should be able to set and manage. Metaplex or other institutions can create and promote actively managed rulesets, but there shouldn’t be only one set of programs managed by Metaplex that the creator can apply. There could even be financial incentive for actively managed rulesets that creators can opt into or extend.

5. Implementation of transfer logic inside of token-metadata: Would love to hear more discussion around this given that this program is built for handling metadata. This doesn’t seem necessarily relevant to NFTs but more to tokens in general. All of this could fundamentally be built into token-22 for example as an extension called “TransferRestriction” (was this considered?) that proxies an upstream program to check transfers. The need for a read and write interface for tokens is real, but why tie that into existing metadata implementations with its own token economy.

If Metaplex feels strongly that all transfers should be going through token-metadata, we believe there is an extendable model that could be based around something like a token type called “Permissioned” token that allows another program to plug in rules to transfer given a programID, to/from account and instructions sysvar, and all additional accounts in the transfer instruction as mutable. Anyone (including metaplex) could provide custom transfer logic in a composing program. However I'd also ask what thought has been given to client interfaces for token transfer in general allowing new programs to seamlessly implement the same client interface that wallets / dApps can use.

With the core points listed above, we can further explain an approach to how we have been rolling out royalty enforcement using existing protocols. The solution Cardinal proposes isn't focused on just solving royalties, but can be used more broadly as a way for creators to have some control over their tokens by program permissioning but in a creator controlled way. Ultimately the balance of creator control is fragile but we think providing knobs for creators to set permissions on their token to guide their holders on where and how their tokens can be used across the ecosystem is a feature that many NFT creators want and need. Happy to share more details on this as well but those are some thoughts on the current MIP

[Jac0xb]

100% agree with cardinal's response on an ideological and practicality basis.

[Findiglay]

@gauravtechie I think this is Cardinal's https://github.com/cardinal-labs/cardinal-creator-standard

+1 for ruleset with allowlist

[gauravtechie]

@Findiglay there's no issue to discuss. There are many implications of what they're doing and cardinal actually competes with a lot of other dapps (Renting, staking). If they lock the NFT's with Cardinal royalty enforcement, how these dapps would then work?

PS: Metaplex has already thought through that.

[jpbogle]

thats correct @Findiglay and yes @gauravtechie those contracts work the same as they do now (we have already updated our staking, rentals and marketplace to work with this), holder can still delegate the token or transfer the token the creator just has to allow the programs they want their tokens to interact with

[gchatz22]

also @gauravtechie linking the docs to our proposal here https://docs.cardinal.so/the-creator-standard along with our GitHub discussion solana-nft-programs/creator-standard#29

[ellttBen]

Hi,
Looking at the design, it seems to us at Bonfida that the identity system might be a bit too restrictive, especially when users might want to move assets from compromised wallets. As an alternative system, we would like to propose for the protocol to break a component of trustlessness between parties involved in an unrestricted transfer. Since unrestricted transfers should only be allowable between wallets controlled by the same party, this should not be an issue.
One way to break unrestricted transfers would be to make them reversible during a set period of time by the source. This period of time is the transfer finality delay (TFD). The transfer finality delay can be different depending on the nature of the destination account :

• if the destination token account is owned by a PDA, then the TFD can be set to 24 hours. This makes unauthorized escrows easy to use.
• If the destination token account is owned by a wallet address (on the ed curve), then the TFD can be set to a shorter period of time, for instance 5 minutes. This breaks trustless OTC transactions. For legitimate transfers, UX remains virtually identical.
  There would be ways to circumvent this system, but our understanding is that it would add enough friction to make users will gravitate to the better UX found on authorized markets (no 24h+ delay to list an NFT for instance).
  In terms of implementation, we are confident that this is not only doable, but deliverable and deployable on a tight schedule.

[austbot]

Thanks @jpbogle for your response here and thank you for your work on Cardinal. I'll try to clear up some things and bring more clarity to things we have already told you in meetings we have had when we proposed the initial design to you some time ago.

For the rest of Github, I would like to give some context. Because Cardinal was a team we have worked with in the past, we showed them a proposal before we made it public to get their initial feedback as another great builder in the space. Some of the current proposal takes into account their feedback. Since I'm directly responding to a great dev @jpbogle I will refer back to some of those meetings in an attempt to clarify our engineering position.

In general this proposed design is very different from the initial design we proposed, marketplaces and other companies such as yours gave feedback and we listened. Some of the ideas listed in the doc were in direct response to a collaborative process with Cardinal. The current proposal represents our interpretation of what the community + marketplaces were hoping as an initial state and as the solution gains traction things like the whitelist fall away. I'll address your points below.

1.

Staking MPLX token: Given the below proposal, we don’t believe mandating staking of MPLX to be in the verified list to dissuade bad actors makes sense. Removal of bad actor....

The managed whitelist idea is bad(personal opinion), we are in favor of creator driven lists(our original proposal to you and others). But as creators will need help and sensible defaults we propose launching with a list to take that burden off them. And we propose adding an open market system to encourage self regulation. Without an open market where participants can arbitrate against bad actors for monetary incentive such as the scenario when a marketplace that uses the protocol to enforce royalties tries to game by selling way below floor "0.001" sol and then sends the money to the seller in a separate transaction. Our initial proposal contained a whitelist that was managed by the creator, but there was some negative feedback by the initial marketplaces we showed it too. It's not easy to strike the balance between everyones desires.

2.

Identity will not be built into the same program and that was never in the proposal. Also whitelists are not involved here. This is at the very least a signature system(similar to the below bonfida idea) that allows self transfers and at most a decentralized profile system with public and private data scopes.

I dont think that the comment about the program whitelist being a solve for self transfers is technically sound. A malicious set of actors could easily build and OTC system of transfer and pay to bypass royalties. The creator driven whitelist of programs is not something that can influence self transfers. It is meant to allow the creator to decide where their IP is allowed to be sold.

3.

There are two points here, The Master Edition system always had this update Authority system where the creator or update authority can change things unless this was immutable. Perhaps some points of the proposal were missed. We propose optionality.

In the doc we say

---

There are two main scenarios for the migration of existing collections:

1. An entire NFT collection migrates at once
   1. A creator would organize a vote via their DAO or another transparent mechanism for the current NFT holders. If the vote passes, the entire collection can be migrated by the creator.
   2. There would be specific Protocol-level guardrails or vote requirements to be met to ensure the current NFT holders have a fair chance at voting.
   3. Prerequisite for vote-based migration: Using Metaplex’s sized collections standard would be required so the smart contracts can calculate the quorum and passing votes percentages based on the number of NFTs in the collection.
2. NFTs migrate individually
   1. Collectors could individually migrate the NFTs they hold to the new asset class.
   2. This could lead to a full collection migration if a certain % of collectors individually migrate.

---

4.

I guess it's the same as Cardinals "God Mode". In the Cardinal protocol your developers have the ability to mint another instance of the SFT that is being used as an NFT. I think pointing out that Metaplex can change the contract is the same as saying Cardinal can change their contracts. We have built things for the community, taken 0 fees. In contrast Cardinal takes % based fees. And there is nothing wrong with that but let's level set on the actual solution.

In the original proposal we showed that RuleSets are managed by the creator. And this is always the goal to get to. Preliminary feedback indicated that creators may have trouble managing these lists. When we received this feedback we proposed launching an initial set of Rules that enforce royalties. In which the creator can add to , but to have a default set of rules:

Identity Transfers->Full transfers without sale or Utility operations must be ID->ID
To Start this will be self transfers, but we want to enable low volume gift transfers.

Sale Delegate must be a PDA of a Program that is on the Creator Driven Marketplace whitelist,
Utility Delegate can only do force transfers back to the original owner (this supports lending and staking)

5.

We worked with @joncinque at solana extensively to see if Token 2022 made sense for Metaplex protocols. And there has not been much interest in a transfer authority extension until now with all the royalties meta flowing around. The Token 2022 program is an amazing piece of tech and while we see a path for it being helpful for new collections, existing collections wont be able to take advantage of this without the Mint ids changing for the entire collection. The mint Id changing is a HUGE deal for the long tail of indexers, rarity tools, uis. When using the Sized MCC it becomes less of an issue but we still see alot of integration pain. We are currently working with Solana Labs team on how we can accomplish some wrapping to make this better. Your feedback thus far logically has one thoughtful point, "how do we minimize scope and integration pain". We are also thinking about this, on top of all these changes introducing another token program is a typical project night mare and immediately wont have wallet support or existing program support.

If Metaplex feels strongly that all transfers should be going through token-metadata, we believe there is an extendable model that could be based around something like a token type called “Permissioned” token that allows another program to plug in rules to transfer given a programID, to/from account and instructions sysvar, and all additional accounts in the transfer instruction as mutable. Anyone (including metaplex) could provide custom transfer logic in a composing program. However I'd also ask what thought has been given to client interfaces for token transfer in general allowing new programs to seamlessly implement the same client interface that wallets / dApps can use.

This is indeed the first proposal we put in front of you, I'm glad to see you have changed your position on this and is something you are interested in. We proposed "AuthorityManaged" where the authority is the creator. We also believe that the Rulesets System can be extended to allow composable program restrictions just like you are talking about. We deeply care about composability which is why we have created the following composability systems:

Token Metadata Authority Delegates -> Uses and Collections, this functionality allows delegation and I believe at one point was being used by your progams.
Candy Machine V3 -> Now a new system of guards and forked guard programs emerges that allowes composability without destroying the network (the network also is much stronger these days)
Auctioneer -> A logic layer on top of Auction Hosue
Token owned Escrow-> A token wallet, tokens owning tokens. This primitive can be used to implement many many new designs

As always @jpbogle thanks for your comments

[kmozurkewich]

Including identity in the same proposal as royalty enhancement seems like scope-creep. This type of requirement would also open up to a naming-service from the protocol. Does linking social accounts potentially to NFTs concern the community around provenance vs. anonymity ? Identity is a first-class citizen that should be composable instead of adjacent to a functional enhancement around NFT configuration.

The mention of ZK having a place in this is appreciated.

[austbot]

Without a system to prevent otc marketplaces via we would be left with no self transfers.

As said above the identity system is at least an async way to verify ownership of two wallets (possible zk things here)

But the naive implementation of the "take it back" or what we propose where there is data on chain and a peristent link will still expose the provenance of the nft due to the way solana transfers work.

If we were to make a identity system with data on chain we can obfuscate the link until the time of transfer after which point we cannot because the transfer has occurred.

One way to bypass this is to derive new key-pairs from other key-pairs but this also must have a wallet app coordination or standard to show ownership in the main wallet ui.

[Findiglay]

Could you clarify the "always-frozen" aspect? Is this using token account delegation and freezing via edition pda? Wouldn't this prevent subsequent transfers within particular windows, where any transfer could be reversed?

[kespinola]

1. Metaplex should not act as any sort of governing body over which programs can broker the exchange of NFTs or set any restrictions on creators updating their NFTs to this or any future standard. Metaplex should give creators the ability to manage and restrict their creations in whatever way they see fit. The creator needs to be the one that manages their community and is liable for any backlash for actions that may aggravate their community.

• Metaplex should not maintain a list of approved programs but instead require the creator to set every program that is allowed to process the transfer of their creations.
• Metaplex should not put in any governance workflows that restrict the migration of a collection to the royalty asset standard. My thesis is that creators that disregard their community will lose their current and future collector base. Metaplex doesn't need to act as a governing body because the market will govern itself.

2. royalty enforcement should be concerned with marketplaces bypassing royalty payment and should not try address normal OTC trades between 2 individual parties.

The transfer instruction should work similar to Candy Machine bot tax where if the program_id of the transaction is not part of the allowlist set by the creator it is rejected.

https://github.com/metaplex-foundation/metaplex-program-library/blob/master/candy-machine/program/src/processor/mint.rs#L152

The transfer instruction should let any transfer go through as long as it does not include a system program transfer instruction in the same transaction. I understand this check can be circumvented by the marketplace sending 1 transaction to process the transfer of SOL (or SPL token) and another for the NFT but that workflow is fragile and requires a user experience that I believe will deter the growth of such marketplaces.

This simplified logic removes the need to include the identity NFT in this proposal. Though I support the addition of an identity mechanism I don't think it should be used to govern the transfer of NFTs.

3. The allowlist of programs should be associated to the MCC by either extending the account or introducing a new PDA that manages the list of approved programs. The NFTs looking to use royalty enforcement should be upgrade to the new token standard and be associated to a MCC. The transfer instruction should accept the NFT to be transferred and the MCC (or associated PDA) for checking the allowlist of programs that invoke transfer through a CPI.

[Findiglay]

Re: Delegate Utility:

The program can only send the asset back to the original owner.

This means that use cases like options, loans & rentals would no longer be possible? Please correct me if I am misunderstanding here, but the ability to collateralize a digital asset requires the ability to liquidate that asset and send to a lender.

[samuelvanderwaal]

The RoyaltiesNonFungible asset doesn't replace NonFungible tokens, it's an additional asset class with its own trade-offs, costs, and benefits. Creators can choose which asset class makes the most sense for their particular use case.

[Findiglay]

@samuelvanderwaal I agree, but I think there's a valid use case for NFTs that can enforce royalties but also provide the tangible benefits of digitial ownership. We should be able to do at least as much - and probably much more - as we can with physical goods. I'd point to this simple solution for this:

One simple solution I see here is to allow creators to optionally whitelist program ids that can make free use of delegate/freeze authority.

Why not let the creators decide?

[samuelvanderwaal]

Because that's an insufficient solution for royalty enforcement, so it's unclear what creators gain from that solution on its own without the other components specified in the royalties proposal.

[Findiglay]

@samuelvanderwaal if Creator's can decide which programs can make use of delegation (for purposes other than selling) how would this not be sufficient for royalty enforcement? They could simply remove any program id that is not respecting their interests.

Could you explain the attack vector here?

[samuelvanderwaal]

How would self-transfers work in this idea?

[ilmoi]

Thanks @austbot for the proposal and all the work that Metaplex is doing to support a thriving NFT ecosystem on Solana.

I'll give a quick tldr of our feedback here and link to a more extensive document in the end.

tl;dr;

We believe that currently proposed royalty enforcement solutions, including MIP-1:

1. Being allowlist-first, kill the permissionless nature of NFTs
2. Being creator-specific, give launchpads excessive influence over creators

Our proposed amendment to MIP-1 is to use denylists, not allowlists as the main controlling primitive and more specifically a single global denylist for the first iteration. The most important thing is to keep Solana NFTs permissionless by default.

We acknowledge that our proposal doesn’t close every door to evading royalties - but we believe in the iterative approach:

1. We start with minimal intervention and see if issue persists
2. If it does persist, what is its scale? Are 80% of NFTs traded royalty-free or are 5%?
3. If scale is sufficiently large, we learn and we ship another version

The main goals here are speed and simplicity. We want to get something out fast that solves the issue and gets creators paid, while also being the least amount of work for both Metaplex and 3rd party Solana developers.

Detailed doc

You can find our detailed proposal over here.

We're totally open to conversation. Ultimately we just want what's best for ecosystem - the creators, the devs, and the community. Talk to us about what you like/don't like and let's find a solution where everyone wins.

[ilmoi]

That is valid criticism. We've deferred the discussion around governance for now as we'd like to come to an agreement that this approach as a whole is the right approach forward. We can then flesh out governance as a next step.

I think whether not this is the right approach largely depends on the details of governance. Poor governance will be unable to react quickly enough to manage a global denylist against agile bad-faith markets. Do you really want to have a DAO vote every time a bad actor changes their program ID?

Thanks for this comment Sam. I agree with you here. If I'm honest when we were proposing this we went back and forth on whether governance should be part of the initial proposal, and ultimately decided not to include it to focus the discussion on just "gloibal denylist - yes or no?". Perhaps that was a mistake.

Let us do another turnaround with a few possible governance structures, and maybe the discussion can get more concrete.

[Findiglay]

PS all of my arguments are re mandatory DEX. If the DEX is non-mandatory, I don't see why we're even discussing it here. That seems to me like a private for-profit project that Metaplex can choose to do/not do on their own, and that should have nothing to do with the standard or the standrd's contracts.

Open-liquidity is not mandatory at all but I think helps ensure an open marketplace for an allowlist implementation. I also think it would be good for market efficiency, competition, and a powerful foundation for NFT financialization. Let's set that aside though since I agree its a bit of a segue to the current discussion.

To get back on current topic - I think there are practical problems with denylists. Any marketplace with bad intentions could setup methods to switch a program id on a weekly/daily basis without too much difficulty. It's going to be fairly easy to exploit. If the denylist is creator controlled, how will creators be expected to monitor and update the denylist constantly? If the denylist is global and controlled via governance, wouldn't this be even worse? If the denylist is centrally controlled, doesn't this go even further against the permissionless nature of NFTs?

Let's say I believe that NFTs should be fractionalized and I want to build an entire economy around fractions. If there's a single DEX that is mandator to transact through, well, I can go take my ideas somewhere else coz I clearly can't build them here ¯_(ツ)_/¯

Let's say an allowlist is required for things like fractionalization via escrow. How would this work practically? It would probably involve something like the collection mint authority going to a website and clicking "approve". For DAOs this would likely happen through a single proposal and vote post mint. So practically, its not really going to be difficult to onboard creators and communities provided its in their interest.

I think whether creators/communities should be able to decide on the rules is the main question here. I don't think we should automatically start from an assumption that any owner of any NFT should be able to do anything they want. There are certainly going to be instances where communities don't want to support fractionalization or where things like rentals might not be in their best interest, if for example the community is built around exclusivity and the ability to rent that NFT would diminish the value of that community.

This discussion only applies to the ProgrammableNonFungible standard and there's no reason the NonFungible standard couldn't also continue to be used for use cases where "ownership means you can do whatever you want with your NFT and the creator/community doesn't get a say". There would need to be an option to freeze NFTs to this standard.

[Restuta]

Upon re-reading the suggestion and all the discussion it seems like denylist still has the best set of tradeoffs to chose as a starting point. I failed to find a compelling counterpoint to that so far.

[chemixrx]

I disagree that being "creator-specific, gives launchpads excessive influence over creators." If anything, it gives creators more leverage with their creations.

The notion that launchpads will engage in anti-competitive practices is unfounded as their doing such would be illegal under existing laws and regulations. Anti-competitive practices, such as forcing creators to only allow list a particular marketplace, are prohibited by competition laws in many jurisdictions. It is unlikely that legit launchpads such as Magic Eden would engage in such practices, as they would be at risk of facing legal consequences.

Additionally, using allowlists and denylists in the current solutions is not necessarily a requirement. The proposed solutions simply offer these options as defaults, but creators are free to customize and use other methods to ensure royalties are paid on NFT sales. Therefore, it is not necessarily true that the vast majority of NFTs on Solana will be permissioned.

Furthermore, the use of allowlists and denylists does not necessarily make NFTs on Solana centralized or un-investable. The proposal is simply one method in ensuring that royalties are paid on NFT sales and doesn't necessarily impact the overall decentralization of the NFT market on Solana. Therefore, it is not necessarily true that capital will not flow into the NFT market on Solana due to the use of the proposed method.

The final point I'd like to make is that creators are the most essential thing to consider when it comes to a solution. As it currently stands, NFTs on Solana are lacking compared to web2 digital standards in terms of functionality. NFTs are practically limited to being collectibles as they don't adequately protect creators or ensure their rights. For NFTs to evolve into a functional asset class, we need proposals like this that empower creators.

Empowering creators isn't the most important thing though. The most important thing hasn't changed in over a decade. Decentralization, Immutability, self-governance, and trustlessness.

The point isn't that ME would be legally liable, or that centralized use of launchpads may or may not happen.. The point, as always, is to take away any doubt of bad actorship, by decentralizing and removing trust entirely.

The elixir proposal is correct by first principles. Enforcing royalties at the protocol level would make tools like Elixir, Sharky, and Hadeswap completely unusuable, thus bringing NFTs back to where they were 1+ years ago.

[chemixrx]

Upon re-reading the suggestion and all the discussion it seems like denylist still has the best set of tradeoffs to chose as a starting point. I failed to find a compelling counterpoint to that so far.

Absolutely agree - and I think we all agree that this is the best step going forward.