---
eip: 5604
title: NFT Lien
description: Extend EIP-721 to support putting liens on NFT
author: Allen Zhou <allen@ubiloan.io>, Alex Qin <alex@ubiloan.io>, Zainan Victor Zhou (@xinbenlv)
discussions-to: https://ethereum-magicians.org/t/creating-a-new-erc-proposal-for-nft-lien/10683
status: Review
type: Standards Track
category: ERC
created: 2022-09-05
requires: 165, 721
---

## Abstract

This EIP introduces NFT liens, a form of security interest over an item of property to secure the recovery of liability or performance of some other obligation. It introduces an interface to place and removes a lien, plus an event.

## Motivation

Liens are widely used for finance use cases, such as car and property liens. An example use case for an NFT lien is for a deed.
This EIP provides an interface to implement an interface that performs the lien holding relationships.

## 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.

1. Any compliant contract MUST implement [EIP-721](./eip-721.md), and [EIP-165](./eip-165.md).

2. Any compliant contract MUST implement the following interface:

```solidity
interface IERC_LIEN is EIP721, EIP165 {

    /// === Events ===

    /// @notice MUST be emitted when new lien is successfully placed.
    /// @param tokenId the token a lien is placed on.
    /// @param holder the holder of the lien.
    /// @param extraParams of the original request to add the lien.
    event OnLienPlaced(uint256 tokenId, address holder, bytes calldata extraParams);

    /// @notice MUST be emitted when an existing lien is successfully removed.
    /// @param tokenId the token a lien was removed from.
    /// @param holder the holder of the lien.
    /// @param extraParams of the original request to remove the lien.
    event OnLienRemoved(uint256 tokenId, address holder, bytes calldata extraParams);

    /// === CRUD ===

    /// @notice The method to place a lien on a token
    ///         it MUST throw an error if the same holder already has a lien on the same token.
    /// @param tokenId the token a lien is placed on.
    /// @param holder the holder of the lien
    /// @param extraParams extra data for future extension.
    function addLienHolder(uint256 tokenId, address holder, bytes calldata extraParams) public;

    /// @notice The method to remove a lien on a token
    ///         it MUST throw an error if the holder already has a lien.
    /// @param tokenId the token a lien is being removed from.
    /// @param holder the holder of the lien
    /// @param extraParams extra data for future extension.
    function removeLienHolder(uint256 tokenId, address holder, bytes calldata extraParams) public;

    /// @notice The method to query if an active lien exists on a token.
    ///         it MUST throw an error if the tokenId doesn't exist or is not owned.
    /// @param tokenId the token a lien is being queried for
    /// @param holder the holder about whom the method is querying about lien holding.
    /// @param extraParams extra data for future extension.
    function hasLien(uint256 tokenId, address holder, bytes calldata extraParams) public view returns (bool);
}
```

## Rationale

1. We only support [EIP-721](./eip-721.md) NFTs for simplicity and gas efficiency. We have not considered other EIPs, which can be left for future extensions. For example, [EIP-20](./eip-20.md) and [EIP-1155](./eip-1155.md) were not considered.

2. We choose separate "addLienHolder" and "removeLienHolder" instead of use a single `changeLienholder` with amount because we believe
the add or remove action are significantly different and usually require different Access Control,
for example, the token holder shall be able to add someone else as a lien holder but the lien holder of that token.

3. We have not specified the "amount of debt" in this interface. We believe this is complex enough and worthy of an individual EIP by itself.

4. We have not specified how endorsement can be applied to allow holder to signal their approval for transfer or swapping. We believe this is complex enough and worthy of an individual EIP by itself.

## Backwards Compatibility

The EIP is designed as an extension of EIP-721 and therefore compliant contracts need to fully comply with EIP-721.

## Security Considerations

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).