At Comity Labs, we’re exploring infrastructure that would better enable coordination for digital communities. The recent surge of digital assets, and the emergence of socioeconomic models such as gaming guilds and scholarships in Axie Infinity, in Axie scholarships owners lend their Axies to scholars and lower the barrier to play the game/enter the eco system, validates that similar to traditional asset classes, there is utility in sharing digital assets (and it’s safe to assume the utility will only increase with time.)
Existing implementations of rentals or sharing that we’ve come across use ad hoc agreements and off-chain techniques. For example, Axie Infinity enables scholarships by allowing for game sign-in with username/password credentialing associated with a wallet, meaning an owner can allow a counterparty to play with their assets without giving them full control of the wallet. Other games allow asset holders to specify delegates who are allowed to play with the assets. While these may serve users well in the short-run, their centralized nature threatens users’ true ownership of the asset—do you really own the asset if a developer can give the privileges associated with that asset to another party without your permission? Furthermore, such a design limits the ability to share assets outside of the application’s ecosystem. It also potentially burdens developers with subjective arbitration and dispute resolution where counterparties disagree, which should be avoidable with well defined smart contracts. We believe that “native rental support” in ERC721 will accelerate and promote decentralized and composable approaches.
There have been a few exciting and relevant proposals, e.g. from devinaconley and Daniel-K-Ivanov. The key difference in our proposal, as we see it, is that it would not require trust between owner and renter/consumer.
We propose a new ERC721 extension interface to handle temporary ownership transfer, backward compatibility, and great flexibility to support any rental agreement design. The key point is to delegate the rental logic (price, duration…) to a separate contract to allow for maximum flexibility, and enforce the agreement and rental terms in the blockchain. Other proposals have created an interface to allow rental, but they are based on trust, and nothing enforces that the owner nor the renter respects agreed-upon rental terms.
More specifically, we introduce two interfaces:
IERC721Rental, which inherits from IERC721, acts as a rental agreement manager: it activates and removes rental agreements, and handles the transfer of ownership during the rental. The proposed version modifies the
ownerOfreturn result when the rental is in progress but does not grant the renter more rights on the token.
IERC721RentalAgreement, the interface for the rental agreement. The logic and terms of the rental will be entirely defined, delegated, and enforced to the contract implementing this interface. For example, it will define the rental fees and the rental duration. It also defines how the rental agreement interacts with the IERC721. In particular, it guarantees that the rental agreements are honored after it has been started.
We implemented three examples for standard rental agreements. We are interested in learning about use cases and seeing how we can extend these.
- ERC721SingleRentalAgreement.sol: rent a specific token Id from a specific ERC721 contract for pre-defined fees and duration.
- ERC721BundleRentalAgreement.sol: a contract that enables to start rental agreement for any token Id of any contract. In case of early termination, a cancellation fee has to be paid and the renter gets reimbursed for the time they didn’t consume the token.
- ERC721SwapRentalAgreement.sol: two token owners can swap their tokens for a period of time.
IERC721Rental <> IERC721RentalAgreement interactions
Below is a diagram that illustrates how the IERC721Rental and IERC721RentalAgreement interact. For more details and context about the interfaces, please refer to the code.
The proposed interface is not perfect, but we believe it enables the most flexibility and compatibility. The first point of contention is changing the value of the
ownerOf function. While in theory this offers backward compatibility by not requiring changes to smart contracts that interact with the ERC721s, it may create surprises. Note that contracts aware of our rental interface could still know if a token is rented by using the
The second point is that while delegating the rental logic to a separate contract allows for maximum flexibility, a poorly designed or malicious rental agreement contract could lock a token in the rental state permanently. Special care has to be taken by the token owner to avoid using such contracts.
We would really value your feedback.
ERC721 upgradeability framework
We intend to provide a framework to migrate existing ERC721 tokens to the new interface. For security concerns, we plan to allow both upgradeability and downgrade ability options so DAPP and DAO developers can introduce the new rental feature safely.
We think that a rental framework should eventually support cross-chain rentals (Alice owns a token in Ethereum and rents to Bob in Polygon), but we haven’t spent too much time thinking about it yet. There have been already very interesting proposals to bridge NFTs such as cross-rollup-nft-wrapper-and-migration-ideas