Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EIP: ERC-721 Holding Time Tracking #6806

Merged
merged 23 commits into from
Jun 2, 2023
Merged
Changes from 22 commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
130 changes: 130 additions & 0 deletions EIPS/eip-6806.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
---
eip: 6806
title: ERC-721 Holding Time Tracking
description: Add holding time information to ERC-721 tokens
author: Saitama (@saitama2009), Combo <[email protected]>, Luigi <[email protected]>
discussions-to: https://ethereum-magicians.org/t/draft-eip-erc721-holding-time-tracking/13605
status: Draft
type: Standards Track
category: ERC
created: 2023-03-30
requires: 721
---

## Abstract

This standard is an extension of [ERC-721](./eip-721.md). It adds an interface that tracks and describes the holding time of a Non-Fungible Token (NFT) by an account.

## Motivation

In some use cases, it is valuable to know the duration for which a NFT has been held by an account. This information can be useful for rewarding long-term holders, determining access to exclusive content, or even implementing specific business logic based on holding time. However, the current ERC-721 standard does not have a built-in mechanism to track NFT holding time.

This proposal aims to address these limitations by extending the ERC-721 standard to include holding time tracking functionality.

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

**Interface**

The following interface extends the existing ERC-721 standard:

```solidity
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0

interface IERC6806 {
function getHoldingInfo(
uint256 tokenId
) external view returns (address holder, uint256 holdingTime);
}
```

**Functions**

### getHoldingInfo

```
function getHoldingInfo(uint256 tokenId) external view returns (address holder, uint256 holdingTime);
```

This function returns the current holder of the specified NFT and the length of time (in seconds) the NFT has been held by the current account.

* `tokenId`: The unique identifier of the NFT.
* Returns: A tuple containing the current holder's address and the holding time (in seconds).

## Rationale

The addition of the `getHoldingInfo` function to an extension of the ERC-721 standard enables developers to implement NFT-based applications that require holding time information. This extension maintains compatibility with existing ERC-721 implementations while offering additional functionality for new use cases.

The `getHoldingInfo` function provides a straightforward method for retrieving the holding time and holder address of an NFT. By using seconds as the unit of time for holding duration, it ensures precision and compatibility with other time-based functions in smart contracts.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about something like this, to explain the return values of getHoldingInfo?

Suggested change
`getHoldingInfo` returns both `holder` and `holdingTime` so that some token owners (as decided by the implementation) can be ignored for the purposes of calculating holding time. For example, a contract may take ownership of an NFT as collateral for a loan. Such a loan contract could be ignored, so the real owner's holding time increases properly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, it looks good

## Backwards Compatibility

This proposal is fully backwards compatible with the existing ERC-721 standard, as it extends the standard with new functions that do not affect the core functionality.

## Reference Implementation

```solidity
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "./IERC6806.sol";

contract ERC6806 is ERC721, Ownable, IERC6806 {
mapping(uint256 => address) private _holder;
mapping(uint256 => uint256) private _holdStart;
mapping(address => bool) private _holdingTimeWhitelist;

constructor(
string memory name_,
string memory symbol_
) ERC721(name_, symbol_) {}

function _afterTokenTransfer(
address from,
address to,
uint256 firstotTokenId,
uint256
) internal override {
if (_holdingTimeWhitelist[from] || _holdingTimeWhitelist[to]) {
return;
}

if (_holder[firstotTokenId] != to) {
_holder[firstotTokenId] = to;
_holdStart[firstotTokenId] = block.timestamp;
}
}

function getHoldingInfo(
uint256 tokenId
) public view returns (address holder, uint256 holdingTime) {
return (_holder[tokenId], block.timestamp - _holdStart[tokenId]);
}

function setHoldingTimeWhitelistedAddress(
address account,
bool ignoreReset
) public onlyOwner {
_holdingTimeWhitelist[account] = ignoreReset;
emit HoldingTimeWhitelistSet(account, ignoreReset);
}
}
```

## Security Considerations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The content of this section seems boilerplate generated by ChatGPT since it appear to be unrelated to the actual technicality of providing holding time


This EIP introduces additional state management for tracking holding times, which may have security implications. Implementers should be cautious of potential vulnerabilities related to holding time manipulation, especially during transfers.

When implementing this EIP, developers should be mindful of potential attack vectors, such as reentrancy and front-running attacks, as well as general security best practices for smart contracts. Adequate testing and code review should be performed to ensure the safety and correctness of the implementation.

Furthermore, developers should consider the gas costs associated with maintaining and updating holding time information. Optimizations may be necessary to minimize the impact on contract execution costs.

It is also important to note that the accuracy of holding time information depends on the accuracy of the underlying blockchain's timestamp. While block timestamps are generally reliable, they can be manipulated by miners to some extent. As a result, holding time data should not be relied upon as a sole source of truth in situations where absolute precision is required.

## Copyright

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