NIP: ERC-721 Holding Time Tracking
Add holding time information to ERC-721 tokens.
Authors
Combo: combo@1combo.io
Saitama: saitama@1combo.io
Abstract
This standard is an extension of ERC-721. 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:
// 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
// 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
This NIP 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 NIP, 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.
that would piss me off honestly