-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
eth-bot
merged 23 commits into
ethereum:master
from
saitama2009:draft_erc721_holding_time
Jun 2, 2023
Merged
Changes from 22 commits
Commits
Show all changes
23 commits
Select commit
Hold shift + click to select a range
d0ee05f
Add:eip-draft_erc721_holding_time.md
saitama2009 938c06c
Rename: eip file
saitama2009 eaa06d9
Update: lint
saitama2009 19936bd
Rename: eip-6806.md
saitama2009 410225d
Update: interface and reference implementation
saitama2009 0ee58a5
Add comments
saitama2009 f528704
Merge branch 'master' into draft_erc721_holding_time
saitama2009 aaf900f
Commit from EIP-Bot
eth-bot 796f5fb
Merge branch 'eipbot/6806' into draft_erc721_holding_time
eth-bot 363ea64
Update branch
saitama2009 09eeadd
Merge branch 'master' into draft_erc721_holding_time
eth-bot d2b586f
Commit from EIP-Bot
eth-bot 0f6cbd0
Merge branch 'eipbot/6806' into draft_erc721_holding_time
eth-bot d913c2f
rename
saitama2009 7924e3a
Merge branch 'master' into draft_erc721_holding_time
eth-bot 8639302
Commit from EIP-Bot
eth-bot d3ada4f
Merge branch 'eipbot/6806' into draft_erc721_holding_time
eth-bot 98af569
Merge branch 'master' into draft_erc721_holding_time
saitama2009 54538b2
Merge branch 'master' into draft_erc721_holding_time
saitama2009 55c0fa5
update eip number
saitama2009 0d14b07
rename file
saitama2009 52cc21c
Update interface
saitama2009 c834031
Update rationale
saitama2009 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. | ||
|
||
## 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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). |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, it looks good