NFTs & IP 2: Leveraging ERC20 Fungibility
Representing Intellectual Property rights via ERC20 for AMM-based price discovery and more
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. This article focuses on the ERC20 fungible token standard for blockchain * IP, and describes how it helps price discovery and more. Article 3 links ERC721 & ERC20.
1. Introduction
1.1 Fungibility & Price Discovery
Apple-apple. If you have two identical apples side by side, and one sells for $0.75, then you can readily establish the price of the other apple as $0.75. You can swap them for each other and it doesn’t matter. That is, they’re fungible. With gold, one ounce of can be swapped for another; it’s fungible. Same for TSLA stock. Same for Bitcoin. Same for ERC20 tokens (fungible token standard).
Apple-orange. If you have an apple and an orange side-by-side, and the apple sells for $2, you still don’t have much information to price the orange. The apple and orange can’t be swapped for each other. They’re non-fungible. This makes them harder to price. An ounce of gold can’t be swapped for an ounce of silver; it’s non-fungible. A one-of-a-kind painting can’t be swapped with another painting; it’s non-fungible. Same for ERC721 tokens (non-fungible token standard).
Price discovery. Of the two scenarios above, it’s easier to price apples to apples, rather than apples to oranges, because “apples to apples” are fungible. It’s hard to overstate the importance of this: fungibility greatly helps price discovery. It’s easier to price ERC20 tokens than ERC721 [1].
1.2 Fungible IP Licenses
When a publisher prints a book, they print thousands or millions of copies. Coming off the press, each of those copies can be swapped for another. They’re fungible.
Open up a book to one of the first pages and you’ll find information about the place of publication, and what printing round it was. Importantly, you’ll also see the well-known copyright © symbol, and the name of the base IP rights holder. This matters because the physical copy of that book includes a license to use that copyrighted material, that base IP. Holding that book in your hands gives you physical access to use that IP. A printed book includes a fungible IP license.
If you rent a movie from Amazon Prime, you’re getting a license to the IP of that movie, that base IP. You get digital access to it for 48 hours. Over time, millions of people may rent that movie, i.e. license that base IP. A rented movie includes a fungible IP license.
Consider a weather station recording temperature, windspeed, wind direction, rainfall, and air pressure over years. The weather station owners hold this dataset as IP, and license it to thousands of weather-prediction agencies throughout the world. Each license is just like the other licenses. A weather data license is a fungible IP license.
There are plenty more examples in music, video games, photographs, and more. It goes beyond copyright IP; it happens for trademark IP and patent IP as well, anytime there is more than one swappable license.
Fungible IP licenses may have limited or unlimited editions. Limited edition use cases are around collectibles and the art world. Unlimited edition use cases include licensing stock photos, renting movies, buying e-books, and more.
1.2 ERC20 Standard
ERC20 is a fungible token standard. It’s the most popular standard for tokens, fungible or otherwise.
Most crypto wallets support ERC20. AMM DEXes exploit ERC20 fungibility property for price discovery, to great success: they now have have billions in daily volume. It’s not just for exchanges; the DeFi community has developed tools for loans, stablecoins, insurance and more, all around ERC20. Even many non-Ethereum chains support ERC20.
If one wants to tokenize fungible assets, ERC20 is a good choice.
1.3 Fungible IP Licenses via ERC20
IP licenses can be fungible; and ERC20 is the leading fungible token standard. Then, ERC20 is a logical choice to represent fungible IP licenses. The NFT field uses it accordingly; let’s review some examples.
RAC’s $TAPE token is an example using ERC20. Here, 1.0 TAPE tokens are used to redeem a music license in a cassette medium. TAPE is on Uniswap AMM, enabling price discovery to around $4K per token these days.
$SOCKS is another example, where SOCKS tokens redeem a pair of socks. Or, $FAME and $BAP are used to redeem t-shirts. While the focus is on the physical artifact, each has an associated copyright design. AMM price discovery has led to a single $SOCKS edition hitting $164K, and $thousands for $FAME and $BAP. These are exciting use cases.
The above are example one-off tokens. Ocean Market scales this, as a platform that makes it easy to publish, stake/swap and redeem ERC20 tokens for IP with appropriate legals. It uses AMMs for price discovery, liquidity, and curation. Ocean Market is a reference marketplace; more than a dozen teams have forked its Apache2 frontend code to make their own blockchain IP markets for their own niche.
1.4 *Non* Fungible IP Licenses & ERC20
In the book example above, the author got copyright for their book committing their creative writing to paper. The author could then print many copies of the book themselves, as fungible licenses. However, printing books may not be the author’s forte. So they’d typically do an exclusive license of the base IP to the publishing house; then, the house prints the books as fungible sub-licenses.
Same for music. The musician could license their works directly to their thousands of listeners. Traditionally this has been hard, so musicians would typically do an exclusive license of the base IP (“master tape”) then the label would do fungible sub-licensing to listeners etc. The exclusive licensee takes over the rights that the copyright holder had initially.
ERC20 has a means to represent the owner of this base IP (copyright / exclusive license): the address that controls ERC20.owner [4]. We elaborate below.
The rest of this article gets more technical; it describes what ERC20 code is doing from an IP perspective.
2. ERC20 Code & IP
This section describes how ERC20 code-level behavior maps to an IP framing. To emphasize similarity to the limited-edition ERC721 approach given in the first article, here we use an example on limited-edition ERC20 (vs. unlimited edition; without loss of generality).
2.1 Definitions
Limited-edition ERC20s means there are several licenses (editions) for the same base IP. Here’s how to implement.
- To Publish means to claim base IP, ready for sub-licensing of limited editions. The claim is via ERC20.constructor(), and metadata points to a T&C stating this is a claim of base IP. Metadata is stored as an extension to ERC20 or in a separate contract. Then, ERC20.mint(to=self, value=n licenses) to prepare for sub-licensing.
- 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) [2]. For legals, the T&C states that owning 1.0 tokens means having a sub-license with specific rights. In deploying the ERC20, one could set decimals=0 to represent exactly 1 license always. Even better, if we set decimals=18 we allow fractional ownership of licenses [3], and enable the token to work for AMMs, loans, etc (a big plus).
- Base IP: represented by the ERC20 address from the publish transactions.
- Base IP holder: Stored in ERC20.owner. This means that ERC20 gives a convenient way to identify the base IP holder.
- Sub-licensee: any address holding ≥ 1.0 ERC20 tokens.
It’s important that the tokens of a given ERC20 contract can only redeem a single type of license / item, otherwise it inadvertently replaces the semantic meaning of the ERC20 token itself (“it’s a license”) with simply being a unit-of-exchange token.
2.2 Limited-Edition ERC20: Management of Base IP
ERC20 tokens themselves are for management of IP licenses. Interestingly, the setup supports managing the underling base IP (copyright or exclusive license). Here’s how.
First, recall that base IP ownership is stored in a state variable (ERC20.owner). So, one can transfer base IP ownership by changing its value to a new address via ERC20.transferOwnership(). Base IP ownership is fractional when a multisig wallet or DAO controls the address. Value can accrue to base IP before any licenses are created, ie before ERC20 tokens are minted. To monetize with >1 license types (e.g. e-book vs print book), create one ERC20 contract for each license type, each with the same base IP.
2.3 Limited-Edition ERC20: Sequence Diagram
Here’s a worked example focusing on behavior. There are 3 limited editions.
Step ❶ is a Publish action. The publisher calls ERC20.constructor() method to claim the base IP, then ERC20.mint() to mint 3 tokens with addressP as initial owner. The ERC20’s owner attribute (an address) gets updated to addressP, and its balances attribute (a mapping) gets updated to 3.0 at index addressP.
Step ❷ is a Sub-License action of one edition, from Publisher to Licensee1 (address1). ERC20.balances gets updated: the value at addressP is decremented by 1.0, and the value at address1 gets set to 1.0.
Step ❸ is a Sub-License action of one edition from Licensee1 to Licensee2. ERC20.balances gets updated accordingly.
Step ❹ is a Sub-License action of one edition from Publisher to Licensee3. ERC20.balances gets updated accordingly.
Step ❺ transfers the base IP to a new exclusive license holder, by calling ERC20.transferOwnership() which changes ERC20.owner to a new address. (Note: this step wasn’t shown for Limited-Edition ERC721 because it’s not possible in that setup.)
2.4 Limited-Edition ERC20: Structure Diagram
Here’s the same worked example, showing system state after each action.
When Completed ❶ (Publish), the value of ERC20.owner is set to the publisher’s address (addressP). As the NFT editions haven’t been transferred yet, the addressP owner is interpreted as the base IP holder. ERC20._balances indicates that addressP is the only holder of sub-licenses (3 of them).
When Completed ❷ (Sub-License), addressP owner has 2 sub-licenses(from 3) and address1 owner has 1 sub-license (from 0).
When Completed ❸ ❹, then addressP, address2, and address3 owners have 1 sub-license each. The Base IP holder remains addressP owner.
When Completed ❺, the Base IP holder has changed, to address3 owner (not shown).
3. Auto Price Discovery in ERC20 IP
When ERC20 tokens represent IP licenses, then AMMs and other ERC20 & DeFi tools can help tremendously with automatic price discovery, liquidity and curation. The image below illustrates.
The ERC20 IP tokens may initially be distributed in an AMM (image: top right), Dutch Auctions, LBPs, or any mechanic used for traditional Initial Coin Offerings (ICOs). These tokens may go on to secondary markets in DEXes like AMMs (image: bottom right) or CEXes. Being ERC20-based allows for IP index funds (example), IP loans, IP-backed stablecoins, and ERC20 DeFi tools applied to IP.
The DEXes and CEXes naturally allow for automatic price discovery and liquidity. Fees and airdrops incentivize providing liquidity. The amount of liquidity in a particular IP’s pool is a useful curation signal — the more stake the higher the quality of the IP asset.
5. Conclusion
This article connected IP to ERC20 Solidity implementations, and how it enables price discovery and other benefits.
The next article covers IP*blockchain using ERC721+ERC20, to combine the benefits of both.
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] Price discovery for single ERC721s remains a challenge. This piece by Jake Brukhman points to many exciting projects aiming to tackle this. Interestingly, several of them re-introduce fungibility.
[2] For readability, we use values scaled for ETH, not Wei. An actual implementation would use Wei.
[3] With fractional ownership of base IP, one may need to account for securities laws in some jurisdictions.
[4] For more flexibility, replace traditional ERC20.owner with ERC725y.owner. (Thanks Fabian Vogelsteller for pointing this out… and developing ERC725.)
