Thread by @ape16z

Can We Enforce Creator Royalties on the Smart Contract Level?

we think we can.

A thread on our proposition. 🧵

1/ There was a fruitful debate on the topic of creator royalties in a recent podcast Co-Hosted by @hosseeb (@dragonfly_xyz) and @laurashin (@Unchained_pod), with guests @ZhuoxunYin (@MagicEden) and @ljin18 (@variantfund).

2/ In the clip below, Haseeb explains the difficulties on enforcing royalties without compromising Censorship-Resistance or Turing-Completeness.

3/ As Haseeb hinted, the solution to this problem is trivial if you allow for some surveillance/censorship mechanism. If an NFT sale is observed to avoid royalty payments, the censoring party will do the following:

4/ Blacklist the item (burn it with privileged rights, alter metadata to blur the image, mutate the contract, etc), effectively solving the problem.

Zhuoxun explains a previous solution that followed this structure and how the response was negative.

5/ At @ape16z, we don't believe nonconsensual censorship or mutability is an option. This begs the real question.

Can We Enforce Creator Royalties While Maintaining Censorship-Resistance and Turing-Completeness?

Let's review the two fundamental problems that Haseeb mentioned.

6/ Fundamental Problem 1 (denoted as FP1):

Assuming Turing-Completeness, there is no way of discerning between a sale and a transfer at the contract level.

What does this mean exactly? Imagine your contract has two functions: `transfer(recipient)` and `sale(buyer, saleAmount)`

7/ In this case, marketplaces can simply conduct sales with a call to `transfer()` and escrow the funds externally.

There are two potential solutions to this.

8/ FP1, Solution 1.

A higher-level wallet-identifying application, similar to that offered by @MatricaLabs, to identify if the transfer parties belong to the same person.

9/ Users would have the option of registering wallets to a single account, between which transfers would avoid any royalty payments (i.e. transfer from burner wallet to ledger)

10/ This solution maintains web3 alignment, as it's entirely optional for the user.

Additionally, the implementation of the wallet-identifying application could include privacy-preserving technology (e.g., ZK-Proofs for wallet <> profile linking).

11/ And the application itself could be managed by a community multisig/governance mechanism rather than a centralized authority.

12/ Some concerns arise wrt maliciously gaming this mechanism, depending on its implementation.

For example, if wallets can be unregistered, then temporarily register your wallet to the selling party's profile to avoid royalties.

13/ Even if wallets cannot be unregistered, a service can create a "Trading DAO" profile where all linked wallets can trade with one another royalty-free.

14/ We understand this solution is not perfect (nothing is), but we do believe there's room to explore this mechanism, especially for certain collections/use cases in particular.

Now for our second solution.

15/ FP1, Solution 2.

If we can't discern between a `transfer()` and a `sale()`, then let's just treat ALL transfers as sales.

This does come with the downside that an intra-person transfer (i.e. burner to ledger) is obligated to pay royalties.

16/ This may be a reasonable mechanism with NFTs - unlike fungible tokens, wherein a mandatory tax on ALL transfers (exchanges/market makers having to pay tax on intra-book rebalances, etc.), would break everything.

So we solved it! Right?

No, not yet.

17/ Fundamental Problem 2 (denoted as FP2):

In the event of a sale, how does the contract determine the *true* value of the sale?

18/ Now imagine the contract's only function was `sale(buyer, saleAmount)`

Marketplaces can still avoid royalties -- simply call the sale function with amount == 0.01 SOL, and escrow the rest of the funds externally.

We again propose two solutions to this problem.

19/ FP2, Solution 1. Fixed Royalties

This is a trivial solution. Rather than charging x% of saleAmount, charge a fixed .5 SOL fee. Or offer an option between an arbitrary amount of (amount, token) pairs, effectively the minimum.

20/ The tradeoff here is that creator royalties scale with volume (# of transfers), not value. For some collections/use-cases this may be perfectly fine. For those in which it's not, however, we have our second solution.

21/ FP2, Solution 2. Oracle-Price-Based Royalties.

This would allow the creator to charge x% royalties (as is the standard), but of the `fairPrice` as derived from a trust-less appraisal mechanism, rather than `saleAmount` from a single-party (marketplace or seller).

22/ The technical details behind this solution are more complex. For example, Floor Price items are relatively easier to identify `fairPrice` where as rare items are more complex.

23/ There are entire protocols (on @solana and @ethereum) founded with the sole purpose of solving this problem, such as @abacus_wtf.

24/ Conclusion.

ape16z proposes these paths toward solving a complex issue, not only for Solana, but for crypto-based creator economies as a whole.

25/ We call on developers, marketplaces, and community members to chime in and help us collectively implement the optimal solution(s).

@metaplex
@MagicEden
@hyperspacexyz
@MatricaLabs
@cardinal_labs
@dust_labs
@osec_io
@solanalabs
@BlocksmithLabs
@peblo69

@metaplex @MagicEden @hyperspacexyz @MatricaLabs @cardinal_labs @dust_labs @osec_io @solanalabs @BlocksmithLabs @peblo69 26/ And now that we've shared our proposal for the path forward ("Can we enforce"), soon we will share our opinion on creator royalties ("Should we enforce").

@metaplex @MagicEden @hyperspacexyz @MatricaLabs @cardinal_labs @dust_labs @osec_io @solanalabs @BlocksmithLabs @peblo69 27/ This thread and path-forward was the monumental effort of our very own @apecortex. He finally made a twitter so let's show him some love.

We also want to thank our founder @DegenerateKong and mentor @Beanthatgotaway for their ideas that contributed to the thread.