EIP-7066: Lockable Extension for ERC721

EIPs
, , ,
1

Keywords: Lockable, non-fungible tokens, NFTs, ERC-721

EIP-7066

Various ERC721 Lockable implementations have been discussed but there is no standardization yet. This feature enables a multiverse of NFT liquidity options like peer-to-peer escrow-less rentals, loans, buy now pay later, staking, etc. Solana has a similar capability to lock approved assets and this proposal shall build the capability on the EVM ecosystem enabling more NFT use-cases.
ERC-7066: Lockable Extension for ERC721
Pull Request #7066

Reference Lockable Discussions

  • [EIP-5753] Filipp Makarov (@filmakarov), “ERC-5753: Lockable Extension for EIP-721 [DRAFT],” Ethereum Improvement Proposals, no. 5753, October 2022. [Online serial]. Available: ERC-5753: Lockable Extension for EIP-721.

  • [EIP-5058] Tyler (@radiocaca), Alex (@gojazdev), John (@sfumato00), “ERC-5058: Lockable Non-Fungible Tokens [DRAFT],” Ethereum Improvement Proposals, no. 5058, April 2022. [Online serial]. Available: ERC-5058: Lockable Non-Fungible Tokens.

Please let us know what your thoughts are on this proposal and if our motivation seems useful! :crossed_fingers:

5 Likes
2

Much required functionality. Been looking for such token capability for some time.
I would love to contribute to this proposal if possible.

3 Likes
3

sure, let us know how we can make it better! :raised_hands:

1 Like
4

It can enable a plethora of use cases in the NFTFi space. Super excited to follow the progress and standard coming to light. Our game can make use of this proposal.

3 Likes
5

we could use all of this functionality for our 721 contract. How can we help?

1 Like
6

Hey could you add the interface implementation on the specification? It is currently hard to read (unless you go to the reference implementation, which it’s great that you have!)

It feels similar to 5753 and 5058, what makes this one different?

1 Like
7

Thanks!!
We are pushing for this proposal as of now. You can help review our code and help us identify any more utility. We are building our rental and lending protocol as of now using ERC-7066. Existing upgradeable ERC-721 can also migrate to ERC-7066.

8

Thanks for the input, shall work on that!!
Also for your query:

  1. ERC-5058: Supports additional utility like time-bound locking, which we feel is great idea but can be achieved without the specified functionality. Locking and Unlocking can be based on any conditions (for e.g: repayment, expiry). Therefore time-bound unlocks a relatively specific use-case that can be achieved via smart-contracts themselves without that being a part of the token contract.

  2. ERC-5753: We are proposing a separation of rights via locker and approver. Both users can lock an asset but approvers can unlock and withdraw tokens (opening up opportunities like: renting, lending, bnpl etc), and lockers lack the rights to revoke token yet can lock and unlock if required (opening up opportunities like: account-bound NFTs).

Also both EIPs are in draft and not accepted yet, therefore we are trying to push this functionality via our proposal (which we have tried to simplify and optimize more on existing proposals). Hope that answers your query! :raised_hands:

2 Likes
9

Thanks for adding the interface there, much easier to check.

Suggestion here:

/**
     * @dev Lock the token `id` if msg.sender is approved
     */
    function lockApproved(uint256 id) external;

    /**
     * @dev Unlock the token `id` if msg.sender is approved
     */
    function unlockApproved(uint256 id) external;

Are these actually setters? The name suggests to me that they are getters, but the dev comment suggest the opposite. If they are getters, you should receive the address you want to check so it does not need a signer.

10

hello @stoicdev0 !
these are setters, for user with approval to lock/unlock token-id. Should I rename these functions to something else?

11

I did not expect two lock and unlock methods, why not merge them? so lock should lock if sender is locker or approved, similarly unlock. WDYT?

1 Like
12

@stoicdev0 I chose abstraction over here, considering the possibility locker might call ‘lock’ by mistake when the asset is already locked, this shall unlock the token and provide all rights to user again. But this implementation shall save us some gas. Let me know if you think this abstraction is not required :raised_hands:

Also, we shall be pushing some major functionality and optimizations to the EIP in next couple of days :crossed_fingers:

13

I did not mean to join lock and unlock, but lock+lockApproved and unlock+unlockApproved.

Looking forward to the new functionality.

14

@stoicdev0 agree with you, locker/approver can be internally checked on lock/unlock. If a user is locker and approved both, approved shall take priority. I shall think more and implement this.

In new update, we have created: transferAndLock transferAndApprove
so that for rental like usecases:

  1. transferAndApprove → transfer and setApproval to self/contract
  2. lock → lock the asset

Problem in previous implementation was, after transfer rental contract will need approval but that will need new onwer to approve hence creating a scenario, renter hold asset without lock and approval provided to actual owner. This implementation shall take care of that, let me know your thoughts :raised_hands:

15

Really nice catch! I agree it’s important.

1 Like
16

@stoicdev0 Have updated the code to support lock, unlock and transferAndLock. All delegations based on locker and approve are taken care internally. Thanks for the feeback, code is much simpler to understand and integrate.