This standard is an extension of EIP-721. It introduces lockable NFTs. The locked asset can be used in any way except by selling and/or transferring it. The owner or operator can lock the token. When a token is locked, the unlocker address (an EOA or a contract) is set. Only the unlocker is able to unlock the token.
With NFTs, digital objects become digital goods, which are verifiably ownable, easily tradable, and immutably stored on the blockchain. That's why it's very important to continuously improve UX for non-fungible tokens, not just inherit it from one of the fungible tokens.
In DeFi there is an UX pattern when you lock your tokens on a service smart contract. For example, if you want to borrow some $DAI, you have to provide some $ETH as collateral for a loan. During the loan period this $ETH is being locked into the lending service contract. Such a pattern works for $ETH and other fungible tokens.
However, it should be different for NFTs because NFTs have plenty of use cases that require the NFT to stay in the holder's wallet even when it is used as collateral for a loan. You may want to keep using your NFT as a verified PFP on Twitter, or use it to authorize a Discord server through collab.land. You may want to use your NFT in a P2E game. And you should be able to do all of this even during the lending period, just like you are able to live in your house even if it is mortgaged.
The following use cases are enabled for lockable NFTs:
Lockable extension you can lock your NFT and declare your safe cold wallet as an unlocker. Thus, you can still keep your NFT on MetaMask and use it conveniently. Even if a hacker gets access to your MetaMask, they won’t be able to transfer your NFT without access to the cold wallet. That’s what makes Lockable NFTs safe.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
EIP-721 compliant contracts MAY implement this EIP to provide standard methods of locking and unlocking the token at its current owner address.
If the token is locked, the getLocked function MUST return an address that is able to unlock the token.
For tokens that are not locked, the getLocked function MUST return address(0).
The user MAY permanently lock the token by calling lock(address(1), tokenId).
When the token is locked, all the EIP-721 transfer functions MUST revert, except if the transaction has been initiated by an unlocker.
When the token is locked, the EIP-721 approve method MUST revert for this token.
When the token is locked, the EIP-721 getApproved method SHOULD return unlocker address for this token so the unlocker is able to transfer this token.
When the token is locked, the lock method MUST revert for this token, even when it is called with the same unlocker as argument.
When the locked token is transferred by an unlocker, the token MUST be unlocked after the transfer.
Marketplaces should call getLocked method of an EIP-721 Lockable token contract to learn whether a token with a specified tokenId is locked or not. Locked tokens SHOULD NOT be available for listings. Locked tokens can not be sold. Thus, marketplaces SHOULD hide the listing for the tokens that has been locked, because such orders can not be fulfilled.
The supportsInterface method MUST return true when called with 0x72b68110.
This approach proposes a solution that is designed to be as minimal as possible. It only allows to lock the item (stating who will be able to unlock it) and unlock it when needed if a user has permission to do it.
At the same time, it is a generalized implementation. It allows for a lot of extensibility and any of the potential use cases (or all of them), mentioned in the Motivation section.
When there is a need to grant temporary and/or redeemable rights for the token (rentals, purchase with instalments) this EIP involves the real transfer of the token to the temporary user's wallet, not just assigning a role. This choice was made to increase compatibility with all the existing NFT eco-system tools and dApps, such as Collab.land. Otherwise, it would require from all of such dApps implementing additional interfaces and logic.
Naming and reference implementation for the functions and storage entities mimics that of Approval flow for [EIP-721] in order to be intuitive.
This standard is compatible with current EIP-721 standards.
There are no security considerations related directly to the implementation of this standard for the contract that manages EIP-721 tokens.
unlocker can actually unlock the token in all cases.transferFrom instead of safeTransferFrom to avoid re-entrancies.Copyright and related rights waived via CC0