NFTs & IP 3: Combining ERC721 & ERC20

Representing base IP with ERC721 and fungible IP licenses with ERC20, to combine benefits of both

Summary

The goal of this series is to practically connect NFTs with Intellectual Property (IP) to help NFT creators and collectors. It uses the language of IP and focuses on Solidity code-level implementations.

Article 1 of this series focused on the ERC721 non-fungible token standard, and article 2 on ERC20 fungible token standard. This article links ERC721 & ERC20, and describes how combining them gets benefits of both.

1. Introduction

1.1 Scenarios

There are two big-picture scenarios on how base IP and sub-licenses relate.

1. Just base IP. This is quite simple. It’s a single artifact and there are no sub-licenses. For example, an artist paints a painting and has a copyright of it. That painting is sold to a collector who then gets exclusive rights to it. The base IP started as copyright held by the painter, then was transferred to the collector.
2. Sub-licenses against the base IP. This has many varieties. Typically the sub-licenses are fungible. For example, an author writes a book and has copyright of it; he does an exclusive license of this base IP to a publishing house. The house sells 10,000 physical books, each having its own fungible sub-license against the base IP. As a second revenue stream, it might also sell 20,000 e-books, each having its own fungible sub-license (a different license compared to the physical books).

1.2 Implementing Scenarios in Blockchain

Here’s how these scenarios might get implemented in blockchain.

For scenario 1 above, the Single-Edition ERC721 described in Article 1 is appropriate.

Scenario 2 is much richer, leading to several implementation possibilities. Article 1 described how Limited-Edition ERC721 could be used, and Article 2 described how ERC20 could be used. This article will describe a third approach that combines both. But first let’s do some comparison.

1.3 Comparing ERC721 andERC20

Here are pros and cons for ERC721 for limited-edition / fungible IP.

• EC721 Benefits. First, if history of each unique token matters, and its provenance needs to be traced. Second, user experience is decent, since ERC721 wallets explicitly hold ERC721 tokens and render images alongside the ERC721. ERC721 markets have good price discovery for truly non-fungible assets, typically using auctions.
• ERC721 Challenges. Limited-edition ERC721 assumes the tokens are non-fungible, even if the actual asset is fungible IP licenses. This makes the pricing problem harder, because it converts an apples-to-apples comparison into an apples-to-oranges one. Then, it can’t use AMMs and other powerful ERC20 price discovery tools. Finally, limited-edition ERC721 doesn’t model who owns the base IP at all, let alone make it easy to manage.

Here are pros and cons for ERC20 for Limited-edition / fungible IP.

• ERC20 Benefits. First, tokens can go directly in AMMs which allows automatic price discovery, liquidity, and curation. Second, tokens play well with the rest of ERC20 & DeFi infrastructure, from ERC20 wallets to bridges to loans. Third, base IP is represented by ERC20.owner address, and therefore it can be transferred and managed.
• ERC20 Challenges. While base IP can be transferred and managed, tooling doing so is poor. For example, wallets only store the private key for the ERC20.owner address; it doesn’t show up as a token.

Here’s the key takeaways. First, the benefits of one are roughly the challenges for the other. Second, neither does well in managing base IP. It’s nonexistent for ERC721 and poor for ERC20. Yet managing base IP is extremely important! We want to make it easy for people to sell base IP, have multiple revenue streams against it, link it with physical objects and more.

1.4 Combining ERC721 + ERC20: How

This section describes at a high level how to combine the benefits of ERC721 and ERC20, and better manage base IP.

The basic idea is to tokenize the base IP and tokenize sub-licenses against it. Let’s bring in specific token standards.

1. Base IP is non-fungible, so ERC721 is a good way to represent it.
2. Fungible IP sub-licenses are best represented by fungible token standard ERC20. And, we generalize this to multiple revenue streams against the base IP; some use ERC20, some may use ERC721, and others may use other standards or fully custom approaches [1]. A “good default” is simply ERC20.

1.4 Combining ERC721 + ERC20: Benefits

This leads to benefits at a high level, benefits from ERC721, and benefits from ERC20. Here are high-level benefits:

• Simple mental model non-fungible base IP → non-fungible token standard, and fungible IP licenses → fungible standard.
• Enables multiple revenue streams against the base IP, with different sub-licenses. For example, a book might have a kindle version, softcover print version, and hardcover print version [8].

Base IP inherits benefits of ERC721:

• Direct wallet support for base IP. Render images, transfer base IP, versus just holding the private key for ERC20.owner
• Sell base IP in marketplaces focusing on ERC721 NFTs, with corresponding price discovery tuned for ERC721. E.g. OpenSea
• Easier to link physical objects with base IP, e.g. WISeKey chips in paintings, linked directly to NFTs
• Tools to fractionalize ownership of base IP, e.g. Niftex tool. This allows co-ownership of base IP, such as VitaDAO for drug discovery data

Fungible IP sub-licenses inherit benefits of ERC20:

• Fungible IP tokens can go directly in AMMs, for automatic price discovery, liquidity, and curation.
• Fungible IP tokens play well with the rest of ERC20 & DeFi infrastructure, from ERC20 wallets to bridges to loans.

This combines the UX benefits of ERC721 with the fungibility benefits of ERC20. ERC20 doesn’t have to be limited-edition either; for example ERC20 tokens (licenses) could be minted on-the-fly.

At Ocean Protocol for V3, we built an ERC20-based IP framework. We’re now working on ERC721+ERC20 for Ocean V4.

The rest of this article gets more technical; it describes what ERC721+ERC20 code is doing from an IP perspective.

2. ERC20 + ERC721 Code & IP

2.1 Definitions

• To Publish means to claim base IP, ready for sub-licensing of limited editions. The claim is via ERC721._safeMint() at a new tokenId with to=self, and metadata points to a T&C stating this is a claim of base IP. Metadata follows ERC721Metadata extension. Then, use ERC20.constructor() and ERC20.mint(to=self, value=n licenses) to prepare for sub-licensing. The ERC20 can be linked to ERC721 in one of many ways.
• To Sub-license means to transfer one (of many) sub-licenses to a new licensee. This is implemented as ERC20.transfer(to=licensee, value=1.0) [6]. For legals, T&C states that owning ≥1.0 tokens means having a sub-license with specific rights. Those sub-license rights associated with the given ERC20 contract, not the ERC721 contract.
• Base IP: represented by the tuple of {ERC721 deployment, tokenId}.
• Base IP holder: represented by the owner of the address at ERC721.owners[tokenId].
• Sub-licensee: any address holding ≥ 1.0 ERC20 tokens.

2.2 ERC20 + ERC721: Sequence Diagram

Here’s a worked example focusing on behavior. There are 3 limited editions.

Step ❶ is a Publish action. The publisher calls ERC721._safeMint() to claim the base IP, which sets the value at ERC721._owner[tokenId=7] is set to addressP. Then the publisher calls ERC20.constructor() and ERC20.mint() to mint 3 sub-license tokens with addressP as initial owner; this sets the value at ERC20.owner to addressP, and ERC20.balances value at key addressP is set to 3.0.

Step ❷, ❸ and ❹ only involve the ERC20 contract, and work exactly like Limited-Edition ERC20 sub-license steps.

Step ❺ transfers the base IP to a new exclusive license holder, by calling ERC721.safeTransferFrom() which changes ERC721.owners[tokenId=x] to a new address.

ERC721+ERC20: UML Sequence Diagram

2.3 ERC20 + ERC721: Structure Diagram

Here’s the same worked example, showing system state after each action. The two images below illustrate.

When Completed ❶ (Publish), the ERC721._owners[tokenId=7] value is addressP, meaning the publisher is the base IP holder. The ERC20._balances attribute holds one entry with key addressP and value 3.0, meaning the publisher holds three sub-licenses.

The ERC20 can link to the ERC721 in one of many ways. In this example, we riff on ERC20 Ownable mixin with an NftOwnable mixin, replacing ERC20.owner with ERC20.nftOwner that points to the NFT tuple {ERC721 address, tokenId}. Ability to mint ERC20 tokens and other permissions that Ownable gave to the address at ERC20.owner now go to the address at ERC721._owners[tokenId].

Steps ❷, ❸ and ❹ only involve the ERC20 contract. They only change ERC20._balances variables just like Limited-Edition ERC20 sub-license steps. ERC721 state is not changed.

ERC721+ERC20: UML Structure Diagram, steps 1–4

When ❺ is complete, base IP has been transferred. ERC721.owners[tokenId=7] now holds the value address3 (not shown). The address3 owner now controls ERC20 minting and other permissions.

ERC721+ERC20: Structure Diagram, step 5

3. Conclusion

Article 1 of this series focused on the ERC721 non-fungible token standard, and article 2 on ERC20 fungible token standard.

This article connected IP to ERC721+ERC20 Solidity implementations, and how it combines the benefits of ERC721 and of ERC20 individually.

[Update May 2022] At Ocean, we used this article as the mental model for Ocean V4, which uses ERC721 “data NFTs” to represent base IP, and ERC20 “datatokens” to represent licences. Further reading: blog post, docs, code.

4. Appendix: Related Approaches

4.1 NFT Vaults

This is another approach to represent base IP & fractional licenses. Start with ERC20 setup of article 2, but put the private key that owns ERC20.owner attribute into an NFT “vault” using NFwallets, Charged Particles, or emblem.vault.

This seems simple at first glance. However, each ERC20’s owner would be represented by a different NFT, which causes ambiguity if only one of those NFTs is transferred. Also, the workflow to publish is clumsier. Finally, the overall mental model is more complex, which hinders adoptability.

4.2 Fractional ownership of ERC721

Base IP can have fractional ownership. Here’s a traditional example: a company holds a patent, and that company has 10 shareholders. Each shareholder therefore has fractional ownership of the base IP.

Standards like EIP1633, EIP2981 and EIP3601, and tools like Niftex allow one to shard ownership of an ERC721 token, where ERC20 tokens represent the fraction of ownership into the ERC721 token. That’s highly useful to shard ownership for base IP, including the setup in this article where base IP is represented by ERC721.

The main goal of this article is to contemplate representing ERC20 as fungible IP license against ERC721 base IP.

In short, there are (at least) two complementary ways to use ERC20 in relation to ERC721: ERC20 to shard an ERC721 token, and ERC20 for fungible IP licenses against base ERC721 IP. This article focuses on the latter.

Interestingly, by using ERC20 for fungible IP licenses, we get fractional ownership of these IP licenses (if decimals > 0, which is usually the case).

Acknowledgements

Article 1 of this series acknowledges the many people that have helped towards the whole series, including this article. Thank you again!

Notes

[1] Having base IP represented as ERC721 tokens is general enough to allow monetization beyond basic ERC20 IP sub-license datatokens. For example, have Superfluid ERC20 datatokens for streaming payments in C2D or subscriptions. Or, have ERC721 IP sub-licenses. Basically anything, since they just point to the ERC721.