ERC809/1201: Tokenizing Non-fungible Access
NFT (Non-fungible Token) has been one of the most exciting developments in the Ethereum ecosystem. The ERC721 standard, in particular, gave a common language to create on-chain token that represents non-fungible assets. Some of the most popular examples include CryptoKitties, Decentraland, and CryptoPunks.
While the canonical use case of non-fungible tokens and ERC721 has been digital or digitized collectibles, we can use the same framework to tokenize ownership of other sorts such as rental rights of a non-fungible asset.
For example, BookLocal proposed ERC809 as a standard for rental rights over rival non-fungible tokens. ERC1201 explores the same topic with an improved approach. In this post, I am excited to present MeetETH, a proof of concept implementation of the above token standard proposals to tokenize ephemeral access rights to non-fungible tokens. I will discuss the technical challenges compared to digital collectible ERC721 tokens, and why ERC809/1201 can become fundamental building blocks for profound use cases such as traffic planning for autonomous vehicles.
Introducing MeetETH
MeetETH is a scheduling Dapp that allows user to create tokenized calendar bound to an Ethereum account and invite other users to create tokenized reservations on such calendars.
The Dapp and its smart contracts manage two set of tokens: Calendar and Reservation. Let us consider short term rental properties as a concrete example since this is what ERC809 and ERC1201 were designed to do.
A property owner or manager who wants to list an accommodation space online can create a Calendar token for each of her listing as a row of calendar dates shown below. A guest can then reserve a block of time for a specific calendar by minting a Reservation token that is associated with the particular Calendar token with a start and end date time. That is to say each Reservation token represents a block on the corresponding calendar.
In MeetETH, both Calendar and Reservation tokens are ERC721 tokens. This means we get wallet, transfer, and trading support for free.
This also opens the door to a secondary market of rental rights that can reuse a lot of NFT infrastructure we are already building today. One might ask what if I want some form of guest verification or simply banning secondary trading altogether. This is feasible indeed because we conform to ERC721 token standard first and foremost. Exchange protocols such as 0x have already been exploring compliant peer-to-peer trading. We could deploy a permissioned Calendar token such that each Calendar owner can set their desired secondary trading/transfer restrictions. The power of composing token standards and get free interoperable infrastructure is one of the killing applications of Smart Contract.
Why it matters
While the interactions in MeetETH may look simple, it can be generalized to many exciting use cases. At its core, this is about reserving an ephemeral access to a non-rival goods.
Human to Human Reservations
Doctor appointments are often made weeks in advance in U.S. and people often have to choose between expensive emergency care and week long wait for an appointment. Doctor offices often spend a ten of time and resource calling patients to juggle appointments based on patient’s schedule and preferences.
A tokenized reservation would allow patients to easily swap reservation time and guardrails can be set up in smart contract to prevent squatting and scalping. Furthermore, as ERC809 inherits ERC721, the token can be traded using common protocol such as 0x or common exchanges such as OpenSea and RareBits which dramatically reduces engineering work, increases liquidity, and lowers cost.
Lastly, doctors with common practice area could participate in a TCR where access to healthcare can be efficiently pooled among doctors who have similar experience, reputation, and expertise.
Human to Machine Reservations
It is not difficult to see how such calendars can belong to other smart contracts as well. For example, one can reserve a self-driving car for a multi-day trip. One may also reserve a cloud computing resource at a pre-agreed price akin to AWS reserved instances.
Machine to Machine Reservations
This naturally extends to machine to machine as well. A self-driving autonomous vehicle can manage its own wallet and bids for rides. When providing the ride, it communicates with traffic management smart contract to bid and reserve the right of road at an intersection. When it does its route planning, it can precisely calculate the time it enters and leaves each intersection, and can further trade the right of road as traffic condition changes. The existence of such market for public goods enables price discovery and creates an incentive structure to prioritize shared resources that were traditionally difficult to value or allocate equitably. This provides a framework to represent rights of road that supports decentralized planning and real time calibration.
A Two-Tier Token Approach
Last but not least, I would like to present MeetETH’s smart contract architecture and my proposal to improve the design of ERC809/1201 token standard.
ERC809 proposed to add additional functions on top of ERC721 to “allow an owner to rent access to their rival NFTs using a standard set of commands, thus allowing users to view all past and current rental agreements from a single wallet interface.”
One of the shortcomings stems from the fact the “rental rights” itself is not a token. Therefore there is no easy way to query the renter or transfer the reservation.
It is worth noting that this was a logical choice for the use case of BookLocal, a platform for rental property management. I thought it was sensible to abstract each property room as a unit of NFT but later realized that renting a NFT is often times different from owning the NFT over a period of time. Having a token that grants me access to a vacation rental property does not equal to owning a token that represents the ownership of the property: I cannot modify, sell, or destroy the place as if I am the owner however short or long my reservation may be. That is to say a NFT represents the management of renting out a property is different from another NFT represents property deeds. In other words, a physical object can have different digital NFTs for different purposes.
@hyperfekt gave the brilliant suggestion that individual reservation should also be treated as NFT as well. This is what ERC1201 sets out to accomplish.
Each ERC1201 ownership token manages the reservations according to its own inventory. In addition, each reservation mints one or more reservation token(s) by unit of reserved time (e.g. day.) In other words, ERC1201 reservation token is two dimensional: NFT assets (rows) by time slots (columns.) Take rental property example above, each reservation token maps to a calendar square in the multi-calendar. A traveler who books a two nights trip will receive two ERC1201 tokens representing each night.
This is a good step forward from ERC809 but the rental tokens mostly duplicate ERC721 functions with rental prefix. This greatly hinders interoperability of this contract. The ability to display, transfer, and trade access rights (Reservation token) is much more desirable than perform these operations to the management (Calendar token). Under this approach, we would need to rebuild wallet and exchange to support ERC1201. Fortunately, we can do better.
Since it is evident that both ownership and reservation tokens are valid NFT, MeetETH proposes a paired smart contracts architecture: ERC809 and ERC809Child, both inheriting ERC721. Furthermore, ERC809 has a contract immutable variable that points to the ERC809Child so information can be shared and synchronized.
Notice ERC809 and ERC809Child are rather simple and missing the reserve function. This is intentional. Just like ERC721 does not have mint function as part of the standard, the reserve action has a lot of variables that we cannot account for: whether user pays now or later, what auxiliary data is required at the time of reservation, whether the reservation is instantly accepted or require further approval and etc. With such amount of variance, it is difficult to design a reserve interface that is useful across implementations.
In practice, this is how MeetETH implements Calendar.sol and Reservation.sol implementing ERC809 and ERC809Child respectively:
In a way the two smart contracts are rather coupled: to make a reservation, user needs to interact with Calendar smart contract because the owner of Calendar sets the availability and keep track of the sold inventory. Meanwhile, Calendar smart contract needs to mint the Reservation token by calling the Reservation contract. The same applies to cancellation. The heavy lifting, checking availability, has been implemented in the Calendar contract because we feel the complexity belongs to the owner who could setup complicated calendar rules or even use Oracles to enforce availability.
There is big upsides to this approach. We eliminated the trade off between favoring either owner and renter.
Since Ownership and Reservation tokens are both ERC721, we can leverage existing infrastructures for wallet, transfer, and exchange support.
When we design token standard, it is not only important to think how smart contract can empower a decentralized solution, but also how we can build on top of others’ ideas and work.
Whenever we can solve problems by composing ideas and standards (e.g. Token Composables), we be rewarded with interoperable protocols and infrastructure. Software engineering has long recognized the importance of code reuse and open source. Composing token standard not only let us reuse the smart contract implementations but also strengthen the underneath economy and protocol at the same time.
Next Steps and Acknowledgments
Neither ERC809 and ERC1201 are close to a mature state and this post is just another possible improvement to this standard which contains great potential. I welcome thoughts and suggestions and look forward to someone building on top my idea and proposing something better. I listed a few ideas I have not yet explored and they may or may be relevant to the common standard. Last but not least, this has been a more of intellectual exploration for me, thanks to Consensys Academy, and I would love to see someone to take this standard and build real world applications.
Finally, I would like to acknowledge BookLocal team for proposing the ERC809 standard and sponsoring @ETHMemphis, Zeming Yu for sharing his thoughts and discussing ERC809 with me, working through and proposing ERC1201 as an enhancement, and Matt Condon for his thought provoking comment in ERC1155 which challenged me and helped me arriving this solution. Shoutout also goes to Brian Flynn for his awesome NFTY newsletter that expanded my mind a lot about NFT.
