EIP-5058:Lockable ERC-721 Standard

EIPS/eip-5058.md

@@ -0,0 +1,185 @@
+---
+eip: 5058
+title: Lockable ERC-721 Standard
+description: Lockable ERC-721 can be uesed for locking, staking, lending, crowdfunding, etc.
+author: Tyler(@radiocaca), Alex(@gojazdev)
+discussions-to: <URL>
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-04-30
+requires (*optional): 165,721
+---
+
+## Abstract
+A secure locking standard for non-fungible tokens (NFTs). The NFT owner approve the operator to lock the NFT through `setLockApprovalForAll()` or `lockApprove()`. The apporved operator locks the NFT through `lockFrom`. The locked NFT cannot be transferred until the end of the lock period. NFTs that implement this standard can participate in NFTFi projects that are compatible with this protocol without leaving the owner's wallet.
+
+## Motivation
+With the continuous development of the NFT ecosystem, the market value of NFTs is growing, and more and more blue-chip NFTs have appeared in the market. The problem of poor liquidity of NFTs has become increasingly prominent. Many projects have also introduced solutions to solve the liquidity of NFTs, such as: [NFTFi](https://www.nftfi.com/), [BendDAO](https://www.benddao.xyz/), etc., based on the current ERC-721 protocol standard, when users use these projects, they must transfer their NFTs to the project contract. This behavior has huge risks:
+
+1. Potential bugs in NFTFi project contracts may lead to loss of users' NFTs
+2. NFT has its use value, such as being used as PFP, when the user wallet does not own the NFT after mortgage, the use value of NFT is limited.
+3. Many NFTs have airdrops. When NFTs are pledged, users cannot directly receive airdrops, which brings huge losses to users.
+
+This standard perfectly solves the problems caused by the lack of the above [ERC-721](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md) standard：
+
+1. Compared with transferring the NFT to the project contract, it is more secure and guarantees the user's ownership of the NFT. Unless sold and transferred, in any other scenario, the NFT can participate and can be kept in the user's wallet.
+2. When the NFT is locked, it just cannot be transferred, it does not affect the use of the NFT, and the various rights and uses brought by the NFT can be enjoyed without distinction.
+3. The NFT is always kept in the user's wallet. Even if the NFT is locked due to participating in the pledge, the NFT airdrop can still be claimed directly.
+
+This standard manages the control of NFTs in a safer and more convenient way, enabling NFTs to natively support NFTFi activities such as locking, staking, lending, crowdfunding, etc., which will encourage NFT holders to participate more actively in NFTFi projects, indirectly Solve the value liquidity of NFT.
+
+## Specification
+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.
+
+Lockable ERC-721 **MUST** implement the `IERC721Lockable` interfaces:
+```solidity
+// SPDX-License-Identifier: MIT
+// Creator: [email protected]
+
+pragma solidity ^0.8.8;
+
+import "@openzeppelin/contracts/utils/introspection/IERC165.sol";
+
+/**
+ * @dev ERC-721 Non-Fungible Token Standard, optional lockable extension
+ * ERC721 Token that can be locked for a certain period and cannot be transferred.
+ * This is designed for a non-escrow staking contract that comes later to lock a user's NFT
+ * while still letting them keep it in their wallet.
+ * This extension can ensure the security of user tokens during the staking period.
+ * If the nft lending protocol is compatible with this extension, the trouble caused by the NFT
+ * airdrop can be avoided, because the airdrop is still in the user's wallet
+ */
+interface IERC721Lockable is IERC165 {
+    /**
+     * @dev Emitted when `tokenId` token is locked from `from`.
+     */
+    event Locked(address indexed operator, address indexed from, uint256 indexed tokenId, uint256 expired);
+
+    /**
+     * @dev Emitted when `tokenId` token is unlocked from `from`.
+     */
+    event Unlocked(address indexed operator, address indexed from, uint256 indexed tokenId);
+
+    /**
+     * @dev Emitted when `owner` enables `approved` to lock the `tokenId` token.
+     */
+    event LockApproval(address indexed owner, address indexed approved, uint256 indexed tokenId);
+
+    /**
+     * @dev Emitted when `owner` enables or disables (`approved`) `operator` to lock all of its tokens.
+     */
+    event LockApprovalForAll(address indexed owner, address indexed operator, bool approved);
+
+    /**
+     * @dev Returns the current locker of the `tokenId` token.
+     *
+     * Requirements:
+     *
+     * - `tokenId` must exist.
+     */
+    function lockerOf(uint256 tokenId) external view returns (address locker);
+
+    /**
+     * @dev Lock `tokenId` token until `expired` from `from`.
+     *
+     * Requirements:
+     *
+     * - `from` cannot be the zero address.
+     * - `tokenId` token must be owned by `from`.
+     * - `expired` must be greater than block.timestamp
+     * - If the caller is not `from`, it must be approved to lock this token
+     * by either {lockApprove} or {setLockApprovalForAll}.
+     *
+     * Emits a {Locked} event.
+     */
+    function lockFrom(
+        address from,
+        uint256 tokenId,
+        uint256 expired
+    ) external;
+
+    /**
+     * @dev Unlock `tokenId` token until `expired` from `from`.
+     *
+     * Requirements:
+     *
+     * - `from` cannot be the zero address.
+     * - `tokenId` token must be owned by `from`.
+     * - the caller must be the operator who locks the token by {lockFrom}
+     *
+     * Emits a {Unlocked} event.
+     */
+    function unlockFrom(address from, uint256 tokenId) external;
+
+    /**
+     * @dev Gives permission to `to` to lock `tokenId` token.
+     *
+     * Requirements:
+     *
+     * - The caller must own the token or be an approved lock operator.
+     * - `tokenId` must exist.
+     *
+     * Emits an {LockApproval} event.
+     */
+    function lockApprove(address to, uint256 tokenId) external;
+
+    /**
+     * @dev Approve or remove `operator` as an lock operator for the caller.
+     * Operators can call {lockFrom} for any token owned by the caller.
+     *
+     * Requirements:
+     *
+     * - The `operator` cannot be the caller.
+     *
+     * Emits an {LockApprovalForAll} event.
+     */
+    function setLockApprovalForAll(address operator, bool _approved) external;
+
+    /**
+     * @dev Returns the account lock approved for `tokenId` token.
+     *
+     * Requirements:
+     *
+     * - `tokenId` must exist.
+     */
+    function getLockApproved(uint256 tokenId) external view returns (address operator);
+
+    /**
+     * @dev Returns if the `operator` is allowed to lock all of the assets of `owner`.
+     *
+     * See {setLockApprovalForAll}
+     */
+    function isLockApprovedForAll(address owner, address operator) external view returns (bool);
+
+    /**
+     * @dev Returns if the `tokenId` token is locked.
+     */
+    function isLocked(uint256 tokenId) external view returns (bool);
+}
+
+```
+
+## Rationale
+
+### NFT lock approvals
+The NFT owner can give another trusted operator the right to lock his NFT through the approve function. The `lockApprove()` function only approve the specified NFT, and `setLockApprovalForAll()` approve all NFTs of the collection under the user wallet. When a user participates in NFTFi, the NFTFi project contract calls `lockFrom()` to lock the user's NFT.Locked NFT will not be able to be transferred, the NFTFi project contract can also use the unlock function (`unlockFrom()`) to unlock the NFT.
+
+### NFT lock period
+When the NFT is locked, the lock expiration time needs to be set. The expiration time must be greater than the current block time. After the lock expires, the NFT is automatically released and can be transferred.
+
+### Bound NFT
+This standard takes into account that some NFTFi projects want to learn more about NFT participation, such as viewing NFT information through lock-up contracts, so we designed a boundNFT. When the lock contract locks the NFT, it can choose to mint the boundNFT of the NFT to the lock contract address. The boundNFT is consistent with the original NFT metadata and other information, but the boundNFT has no value and cannot be transferred. It is just a lock certificate. When the user's NFT lockup ends, the boundNFT will be destroyed.
+
+
+## Backwards Compatibility
+This standard is compatible with current ERC-721 standards.
+
+## Reference Implementation
+You can find an implementation of this standard in [RadioCaca](https://github.com/radiocaca/ERC721L/tree/main/contracts/EIP5058).
+
+## Security Considerations
+There are no security considerations related directly to the implementation of this standard.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).