ape16z Profile picture
Oct 20 28 tweets 14 min read
Can We Enforce Creator Royalties on the Smart Contract Level?

we think we can.

A thread on our proposition. 🧵 Image
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) Image
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.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with ape16z

ape16z Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @ape16z

Oct 24
3 days ago, we dropped a thread on how to enforce creator royalties.

Today, we're going to share our take on should creator royalties be enforced. Image
1/ As a reminder, a lot of our thoughts were inspired by the ongoing discussion happening in the space and the Unchained podcast.

unchainedpodcast.com/the-chopping-b…
2/ To summarize the podcast and participants' viewpoints, Laura and Li sided with "yes" and Haseeb and Zhouzun sided with "No" on the enforcement of creator royalties.

Before discussing our view, we think it's necessary to steelman each side of the argument.
Read 11 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(