EIP5007: TimeNFT, ERC-721 Time Extension #5007

emojidao · 2022-04-15T00:07:39Z

This standard is an extension of ERC-721. It proposes some additional property(startTime, endTime,originalTokenId) to help with the on-chain time management.

eth-bot · 2022-04-15T00:08:29Z

All tests passed; auto-merging...

(pass) eip-5007.md

classification
`updateEIP`

passed!

(pass) assets/eip-5007/.gitignore

classification
`ambiguous`

file assets/eip-5007/.gitignore is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/README.md

classification
`ambiguous`

file assets/eip-5007/README.md is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/contracts/ERC5007.sol

classification
`ambiguous`

file assets/eip-5007/contracts/ERC5007.sol is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/contracts/ERC5007Demo.sol

classification
`ambiguous`

file assets/eip-5007/contracts/ERC5007Demo.sol is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/contracts/IERC5007.sol

classification
`ambiguous`

file assets/eip-5007/contracts/IERC5007.sol is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/migrations/1_initial_migration.js

classification
`ambiguous`

file assets/eip-5007/migrations/1_initial_migration.js is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/package.json

classification
`ambiguous`

file assets/eip-5007/package.json is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/test/test.js

classification
`ambiguous`

file assets/eip-5007/test/test.js is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

(pass) assets/eip-5007/truffle-config.js

classification
`ambiguous`

file assets/eip-5007/truffle-config.js is associated with EIP 5007; because there are also changes being made to EIPS/eip-5007.md all changes to corresponding assets are also allowed

decafboba · 2022-04-17T15:09:34Z

Thanks for this, it is a great idea.

Here are some initial things to consider.

uint64 for time does not seem worth it. In practice, the savings here are diminished or worse when other operations using these values are considered (such as multiplying by other uint265).

For this reason, uint265 has been fairly standard for time tracking operations, and I recommend sticking with that. If you do choose to stick with uint64, you should provide very thorough data though real world use-case example gas costs to back up your rationale.
Why the additonal functionality that isn't startTime(), and endTime()? The ability for minting new tokens from an old token seems like some very specific project use-case, along with merging into one.

originalTokenId(), split(), merge() do not seem general enough if we are trying to encompass all ERC721 that wants to be extended with time functionality. startTime() + endTime(), with possibly the isValidNow() and TimeUpdate event seem the only ones that should be included here.

SamWilsn · 2022-04-22T18:19:26Z

EIPS/eip-5007.md

+
+## Abstract
+
+This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional property( `startTime`, `endTime`,`originalTokenId`) to help with the on-chain time management.


Suggested change

This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional property( `startTime`, `endTime`,`originalTokenId`) to help with the on-chain time management.

This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional properties (`startTime`, `endTime`,`originalTokenId`) to help with on-chain time management.

SamWilsn · 2022-04-22T18:19:51Z

EIPS/eip-5007.md

+
+## Motivation
+
+Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.


Could you include an example of what kind of NFTs have a time component?

Could you include an example of what kind of NFTs have a time component?

ENS :
nameExpires(id) of ENS --> endTime(id) of EIP-5007 ;
register time of ENS --> startTime(id) of EIP-5007 ；

doNFT of Double Protocol:
getDuration(id)[0] , start time of the lease --> startTime(id) of EIP-5007
getDuration(id)[1] , end time of the lease--> endTime(id) of EIP-5007

Sorry, I meant in the EIP itself 🤣

Seems like a good standard for utility tokens as we move towards more decentralization. Access can be token gated for a period of time. Hence, no need to trust the party to burn or transfer them.

SamWilsn · 2022-04-22T18:23:42Z

EIPS/eip-5007.md

+
+## Motivation
+
+Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.


Suggested change

Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.

Some NFTs have a defined usage period and cannot be used outside of that period. With traditional NFTs that do not include time information, if you want to mark a token as invalid or enable it at a specific time, you need to actively submit a transaction—a process both cumbersome and expensive.

SamWilsn · 2022-04-22T18:24:44Z

EIPS/eip-5007.md

+
+Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.
+
+There are also some NFTs contain time functions, but the naming is different, third-party platforms are difficult to develop based on it.


Suggested change

There are also some NFTs contain time functions, but the naming is different, third-party platforms are difficult to develop based on it.

Some existing NFTs contain time functions, but their interfaces are not consistent, so it is difficult to develop third-party platforms for them.

SamWilsn · 2022-04-22T18:25:36Z

EIPS/eip-5007.md

+    /// @notice Emitted when the `startTime` or `endTime` of a NFT is changed
+    /// @param tokenId  The tokenId of the NFT
+    /// @param startTime  The new start time of the NFT
+    /// @param endTime  The new end time of the NFT
+    event TimeUpdate(uint256 tokenId, uint64 startTime, uint64 endTime);


Is this emitted when tokens are minted/burned? Is the behaviour in constructors different?

Is this emitted when tokens are minted/burned? Is the behaviour in constructors different?

TimeUpdate will not be emitted when tokens are minted/burned. I will change this event to MetadataUpdate of EIP4906

EIPS/eip-5007.md

+    function merge(uint256 firstTokenId, uint256 secondTokenId, address newTokenOwner) external returns(uint256);
+}
+```
+


SamWilsn · 2022-04-22T18:45:47Z

EIPS/eip-5007.md

+    /// @notice Get the token id which this NFT mint from
+    /// @dev Throws if `tokenId` is not valid NFT
+    /// @param tokenId  The tokenId of the NFT
+    /// @return The token id which this NFT mint from
+    function originalTokenId(uint256 tokenId) external view returns (uint256);


I don't understand what this does from this comment alone.

I'd guess that if you had a token 0x01, and you split it into 0x01 and 0x02, then originalTokenId(0x02) == 0x01?

What happens if you then merged 0x02 with 0x03, which happened to be adjacent?

I'd guess that if you had a token 0x01, and you split it into 0x01 and 0x02, then originalTokenId(0x02) == 0x01?

Yes, originalTokenId(0x02) == 0x01

What happens if you then merged 0x02 with 0x03, which happened to be adjacent?

I'm still curious about this case.

SamWilsn · 2022-04-22T18:47:24Z

EIPS/eip-5007.md

+
+### Time Data Type
+
+The max value of `uint64` is 18446744073709551615,  timestamp 18446744073709551615 is about year 584942419325. `uint64` is sufficient and saves gas compared to `uint256`.


Does this actually save gas? I thought all integer types encoded to 32 bytes: https://docs.soliditylang.org/en/develop/abi-spec.html#examples

Does this actually save gas? I thought all integer types encoded to 32 bytes:

struct TimeNftInfo { uint256 originalTokenId; uint64 startTime; uint64 endTime; } encoded to 64 bytes.

struct TimeNftInfo { uint256 originalTokenId; uint256 startTime; uint256 endTime; } encoded to 96 bytes.

Another reason，uint256 is too big for some software such as MySQL, Elastic Search. uint64 is natively supported on many software and programming languages.

Another reason，uint256 is too big for some software such as MySQL, Elastic Search. uint64 is natively supported on many software and programming languages.

That's still completely arbitrary.

I just ran some tests on a project that already makes heavy use of time-based NFTs to confirm whether it was even worth it to switch to uint64 for storage. Our gas costs actually ended going up...

I highly recommend switching to uint256 completely.

I just ran some tests on a project that already makes heavy use of time-based NFTs to confirm whether it was even worth it to switch to uint64 for storage. Our gas costs actually ended going up...

Could you please send the code link of this time-based NFTs?

It's private at the moment, but the reasoning for can be elaborated on. There is still some minimal amount of arithmetic and comparisons against other uint256's, and the uint64 => uint256 transitions adds gas everytime. For example, a common use-case is to add or compare against now (block.timestamp) which is natively uint256.

SamWilsn · 2022-04-22T18:47:34Z

EIPS/eip-5007.md

+
+## Backwards Compatibility
+
+As mentioned in the specifications section, this standard can be fully ERC721 compatible by adding an extension function set.


Suggested change

As mentioned in the specifications section, this standard can be fully ERC721 compatible by adding an extension function set.

As mentioned in the specifications section, this standard can be fully ERC-721 compatible by adding an extension function set.

SamWilsn · 2022-04-22T18:47:57Z

EIPS/eip-5007.md

+
+## Security Considerations
+
+Implementors of the `ERC5007` standard must consider the condition of `merge` function.  The `originalTokenId` of two NFTs should be same and the time of two NFTs should be adjacent.


I don't understand what this means.

I will add more test code later.

I meant more the English description of the security consideration. I don't understand what you're trying to convey. I think it just needs to be reworded a bit to be more understandable.

0xanders · 2022-04-23T03:04:33Z

2. Why the additonal functionality that isn't startTime(), and endTime()? The ability for minting new tokens from an old token seems like some very specific project use-case, along with merging into one.

An old token is not support this EIP could be wrapped to this standards.

decafboba · 2022-04-23T17:08:36Z

Why the additonal functionality that isn't startTime(), and endTime()? The ability for minting new tokens from an old token seems like some very specific project use-case, along with merging into one.

An old token is not support this EIP could be wrapped to this standards.

Extending existing NFTs can be an optional addon / separate interface later, since it nothing to do with a general interface for time-based NFTs.

See how OpenZeppling wraps ERC20 tokens to make them compatible with voting / governance: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Wrapper.sol

Remember, small interfaces allow for better composability and modularity (good software design). My suggestion is that you want ERC5007 = ERC721 + startTime() + endTime() and nothing else. A set of ERC5007 extensions for your specific project needs can be added later.

0xanders · 2022-04-24T02:12:44Z

Remember, small interfaces allow for better composability and modularity (good software design). My suggestion is that you want ERC5007 = ERC721 + startTime() + endTime() and nothing else. A set of ERC5007 extensions for your specific project needs can be added later.

Thanks for your suggestion, I will discuss this with my team.

SamWilsn · 2022-04-29T19:13:21Z

EIPS/eip-5007.md

+
+## Abstract
+
+This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional properties( `startTime`, `endTime`,`originalTokenId`) to help with on-chain time management.


Suggested change

This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional properties( `startTime`, `endTime`,`originalTokenId`) to help with on-chain time management.

This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional properties (`startTime`, `endTime`,`originalTokenId`) to help with on-chain time management.

SamWilsn · 2022-04-29T19:13:54Z

EIPS/eip-5007.md

+
+## Motivation
+
+Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.


Sorry, I meant in the EIP itself 🤣

SamWilsn · 2022-04-29T19:15:53Z

EIPS/eip-5007.md

+
+Some existing NFTs contain time functions, but their interfaces are not consistent, so it is difficult to develop third-party platforms for them.
+
+By introducing (`startTime`, `endTime`) and unifying the naming, it is possible to enable and disable NFT automatically on chain.


Suggested change

By introducing (`startTime`, `endTime`) and unifying the naming, it is possible to enable and disable NFT automatically on chain.

By introducing these properties (`startTime`, `endTime`) and unifying the naming, it is possible to enable and disable NFT automatically on chain.

SamWilsn · 2022-04-29T19:22:58Z

EIPS/eip-5007.md

+    /// @notice Get the start time of the NFT
+    /// @dev Throws if `tokenId` is not valid NFT
+    /// @param tokenId  The tokenId of the NFT
+    /// @return The start time of the NFT
+    function startTime(uint256 tokenId) external view returns (uint64);


Alright, note that in the EIP!

SamWilsn · 2022-04-29T19:23:05Z

EIPS/eip-5007.md

+    /// @dev Throws if `tokenId` is not valid NFT
+    /// @param tokenId  The tokenId of the NFT
+    /// @return The end time of the NFT
+    function endTime(uint256 tokenId) external view returns (uint64);


Also note this too. I know it's in the comment for isValidNow, but it could be more visible.

SamWilsn · 2022-04-29T19:44:56Z

EIPS/eip-5007.md

+
+## Security Considerations
+
+Implementors of the `ERC5007` standard must consider the condition of `merge` function.  The `originalTokenId` of two NFTs should be same and the time of two NFTs should be adjacent.


I meant more the English description of the security consideration. I don't understand what you're trying to convey. I think it just needs to be reworded a bit to be more understandable.

lightclient · 2022-05-03T15:50:52Z

assets/eip-5007/README.md

@@ -0,0 +1,15 @@
+# EIP5007
+This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional functions (`startTime`, `endTime`, `isValidNow`) to help with on-chain time management.


Suggested change

This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional functions (`startTime`, `endTime`, `isValidNow`) to help with on-chain time management.

This standard is an extension of [ERC-721](../EIPS/eip-721.md). It proposes some additional functions (`startTime`, `endTime`, `isValidNow`) to help with on-chain time management.

Wouldn't it be ../../EIPS/eip-721.md? assets/eip-5007/../EIPS == assets/EIPS and /assets/eip-5007/../../EIPS == /EIPS.

Wouldn't it be ../../EIPS/eip-721.md? assets/eip-5007/../EIPS == assets/EIPS and /assets/eip-5007/../../EIPS == /EIPS.

Yes, it should be ../../EIPS/eip-721.md.

ghost · 2022-05-05T13:47:06Z

EIPS/eip-5007.md

+
+### Time Data Type
+
+The max value of `uint64` is 18446744073709551615,  timestamp 18446744073709551615 is about year 584942419325. `uint256` is too big for some software such as MySQL, Elastic Search, and `uint64` is natively supported on mainstream programming languages.


Should really show a more detailed analysis of gas-savings with a real use case if you are going to take a non-uint256 opinionated view. This seems like the main property of the current EIP that needs further discussion.

ghost · 2022-05-05T13:49:26Z

assets/eip-5007/contracts/IERC5007.sol

+    /// @dev Throws if `tokenId` is not valid NFT
+    /// @param tokenId  The tokenId of the NFT
+    /// @return The the NFT is valid now
+    /// if(startTime <= now <= endTime) {return true;} else {return false;}


isCurrent is more clear than isValidNow, since the term valid has more generic implications about the property of the NFT.

isCurrent is more clear than isValidNow, since the term valid has more generic implications about the property of the NFT.

Thanks. Different project may has different definition of 'valid', so I removed isValidNow function.

ghost · 2022-05-05T13:55:57Z

assets/eip-5007/contracts/IERC5007.sol

+    /// @dev Throws if `tokenId` is not valid NFT
+    /// @param tokenId  The tokenId of the NFT
+    /// @return The the NFT is valid now
+    /// if(startTime <= now <= endTime) {return true;} else {return false;}


As I am sure you know, there will be many use cases where you will specifically not want overlapping times between NFTs. startTime <= now <= endTime means that, if NFT 1 has seconds startTime: 0, endTime: 10, and NFT 2 has startTime: 10, endTime: 20, both will be current on second 10.

Best approach for this EIP is to simply not take a view on whether these ranges are doubly-inclusive, only inclusive for startTime, only inclusive for endTime, or neither. Leave that up to the implementation to specify.

ghost

Would like to see final analysis and discussion of the choice uint64 instead of uint256.

This opinionated approach to how timestamps are stored will be the determining factor of whether this EIP will gain popular adoption. It is taking a hard stance that uint64 is the canonical way for time storage on Ethereum, which may be correct, but should be backed up by:

Evidence of how popular projects are currently handling timestamps (e.g. OZ Timelock Controller using uint256).
Gas saving in a real world use case, keeping in mind that non-trivial projects:
- Do not store just an array of timestamps (mappings tend to be far more common).
- Have arithmetic mostly based on other uint256, such as block,timestamp and other project-specific values.

Other than that, this looks good to me. Thank you for your contribution.

Pandapip1 · 2022-05-13T12:40:21Z

EIPS/eip-5007.md

+No security issues found.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


Suggested change

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

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

lightclient · 2022-05-25T20:08:41Z

assets/eip-5007/README.md

@@ -0,0 +1,15 @@
+# EIP5007


Suggested change

# EIP5007

# EIP-5007

* add eip-TimeNFT.md * add Reference Implementation * update code * update Implementation code * add test code * update test code * update code * update test code * rename file name * remove spaces * update Reference Implementation * update title * update by SamWilsn's suggestion * update Backwards Compatibility * update code * simplify EIP5007 * remove empty lines * udpate readme * update readme * update Test Cases * fix link in readme.md * fix link in readme.md * remove function isValidNow * update Copyright * update copyright * change EIP5007 to EIP-5007 Co-authored-by: anders <> Co-authored-by: Anders <anders@emojidao.org>

anders added 8 commits April 13, 2022 00:41

add eip-TimeNFT.md

605ef1b

add Reference Implementation

a206f54

update code

a40d4e9

update Implementation code

fb12667

add test code

dac290a

update test code

978bf23

update code

b5f83d4

update test code

9bdf95f

eth-bot added the ambiguous label Apr 15, 2022

anders added 2 commits April 15, 2022 10:32

rename file name

cd4e30a

remove spaces

2b761bd

eth-bot added newEIPFile and removed ambiguous labels Apr 15, 2022

emojidao changed the title ~~[DRAFT] ERC721 Time Extension~~ EIP5007: ERC721 Time Extension Apr 15, 2022

update Reference Implementation

7cf51d9

emojidao changed the title ~~EIP5007: ERC721 Time Extension~~ EIP5007: ERC-721 Time Extension Apr 15, 2022

ed738 approved these changes Apr 15, 2022

View reviewed changes

update title

5a26c7d

emojidao changed the title ~~EIP5007: ERC-721 Time Extension~~ EIP5007: TimeNFT, ERC-721 Time Extension Apr 16, 2022

SamWilsn reviewed Apr 22, 2022

View reviewed changes

Anders and others added 3 commits April 24, 2022 11:57

update by SamWilsn's suggestion

4c554fa

update Backwards Compatibility

4ac78f2

update code

dc3ada3

SamWilsn reviewed Apr 29, 2022

View reviewed changes

0xanders added 2 commits May 2, 2022 02:18

simplify EIP5007

750d93f

remove empty lines

19438fe

eth-bot added the ambiguous label May 1, 2022

0xanders added 3 commits May 2, 2022 02:32

udpate readme

a1be629

update readme

53ada90

update Test Cases

d7b9b81

poojaranjan mentioned this pull request May 3, 2022

EIP editor apprenticeship meeting 16 ethcatherders/EIPIP#124

Closed

lightclient requested changes May 3, 2022

View reviewed changes

0xanders added 2 commits May 4, 2022 00:06

fix link in readme.md

07deb47

fix link in readme.md

e896964

0xanders approved these changes May 5, 2022

View reviewed changes

ghost suggested changes May 6, 2022

View reviewed changes

remove function isValidNow

d67a619

ghost approved these changes May 8, 2022

View reviewed changes

Pandapip1 reviewed May 13, 2022

View reviewed changes

0xanders added 2 commits May 13, 2022 21:29

update Copyright

cbcf0e1

update copyright

3623026

ed738 approved these changes May 16, 2022

View reviewed changes

poojaranjan mentioned this pull request May 17, 2022

EIP editor apprenticeship meeting 17 ethcatherders/EIPIP#135

Closed

lightclient requested changes May 25, 2022

View reviewed changes

assets/eip-5007/README.md Outdated

@@ -0,0 +1,15 @@

# EIP5007

Copy link

Member

lightclient May 25, 2022

Choose a reason for hiding this comment

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

Suggested change

# EIP5007

# EIP-5007

change EIP5007 to EIP-5007

fb07ee4

SamWilsn approved these changes May 27, 2022

View reviewed changes

eth-bot added updateEIP and removed newEIPFile labels May 27, 2022

MicahZoltu closed this May 28, 2022

MicahZoltu reopened this May 28, 2022

eth-bot enabled auto-merge (squash) May 28, 2022 06:03

eth-bot merged commit 86a7b57 into ethereum:master May 28, 2022


		## Abstract

		This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional property( `startTime`, `endTime`,`originalTokenId`) to help with the on-chain time management.


		## Motivation

		Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.


		Some NFTs have a defined usage period and cannot be used when they are not at a specific time. If you want to make NFT invalid when it is not in use period, or make NFT enabled at a specific time, while the NFT does not contain time information, you often need to actively submit the chain transaction, this process is both cumbersome and a waste of gas.

		There are also some NFTs contain time functions, but the naming is different, third-party platforms are difficult to develop based on it.

	There are also some NFTs contain time functions, but the naming is different, third-party platforms are difficult to develop based on it.
	Some existing NFTs contain time functions, but their interfaces are not consistent, so it is difficult to develop third-party platforms for them.


		### Time Data Type

		The max value of `uint64` is 18446744073709551615, timestamp 18446744073709551615 is about year 584942419325. `uint64` is sufficient and saves gas compared to `uint256`.


		## Backwards Compatibility

		As mentioned in the specifications section, this standard can be fully ERC721 compatible by adding an extension function set.


		## Security Considerations

		Implementors of the `ERC5007` standard must consider the condition of `merge` function. The `originalTokenId` of two NFTs should be same and the time of two NFTs should be adjacent.


		Some existing NFTs contain time functions, but their interfaces are not consistent, so it is difficult to develop third-party platforms for them.

		By introducing (`startTime`, `endTime`) and unifying the naming, it is possible to enable and disable NFT automatically on chain.

	By introducing (`startTime`, `endTime`) and unifying the naming, it is possible to enable and disable NFT automatically on chain.
	By introducing these properties (`startTime`, `endTime`) and unifying the naming, it is possible to enable and disable NFT automatically on chain.

		@@ -0,0 +1,15 @@
		# EIP5007
		This standard is an extension of [ERC-721](./eip-721.md). It proposes some additional functions (`startTime`, `endTime`, `isValidNow`) to help with on-chain time management.

	Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
	Copyright and related rights waived via [CC0](../LICENSE.md).

EIP5007: TimeNFT, ERC-721 Time Extension #5007

EIP5007: TimeNFT, ERC-721 Time Extension #5007

Conversation

emojidao commented Apr 15, 2022

eth-bot commented Apr 15, 2022 • edited Loading

All tests passed; auto-merging...

(pass) eip-5007.md

(pass) assets/eip-5007/.gitignore

(pass) assets/eip-5007/README.md

(pass) assets/eip-5007/contracts/ERC5007.sol

(pass) assets/eip-5007/contracts/ERC5007Demo.sol

(pass) assets/eip-5007/contracts/IERC5007.sol

(pass) assets/eip-5007/migrations/1_initial_migration.js

(pass) assets/eip-5007/package.json

(pass) assets/eip-5007/test/test.js

(pass) assets/eip-5007/truffle-config.js

decafboba commented Apr 17, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as resolved.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xanders Apr 23, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xanders commented Apr 23, 2022

decafboba commented Apr 23, 2022

0xanders commented Apr 24, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost left a comment

Choose a reason for hiding this comment

Pandapip1 May 13, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eth-bot commented Apr 15, 2022 •

edited

Loading

decafboba commented Apr 17, 2022 •

edited

Loading

0xanders Apr 23, 2022 •

edited

Loading

Pandapip1 May 13, 2022 •

edited

Loading