-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Add EIP-4985: Non-fungible Token for GameFi #4985
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
Conversation
|
Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s): (fail) EIPS/eip-4985.md
|
|
Please read these two documents: |
|
i amn't clear how this eip solves the pain points you mentioned above |
1 similar comment
|
i amn't clear how this eip solves the pain points you mentioned above |
| @@ -0,0 +1,456 @@ | |||
| # EIP-4985: Non-fungible Token for GameFi | |||
|
|
|||
| - [EIP-4985: Non-fungible Token for GameFi](#EIP-4985-non-fungible-token-for-gamefi) | |||
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.
Please follow the header format in EIP-1.
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
@eth-bot rerun |
|
Closing since the author hasn't been seen in >3 months (the stale threshold). |
1. Summary
This EIP describes a proposal for GameFi specific NFT on the Ethereum.
2. Abstract
Games using non-fungible tokens to stand for their internal objects including roles, assets etc. and there will be some dynamic data asscociated with them, e.g.
The existing ERC721 standard does not compatible with these kind of use-cases, and the new protocol introduce a simple data structure to store attributes.
3. Status
This EIP is already implemented.
4. Motivation
The existing NFT protocol stores Metadata externally and links through URI. This link relationship is fragile, and developers can even modify the URI. In addition, the storage location of Metadata is also uncertain and may be stored on a centralized server. Through this protocol:
You can find the specific implementation case here.
5. Specification
5.1 Attribute standard
EIP-4985 is an extension of eip-721. Following attribute-related functions and events are suggested to be added:
5.2 Implementation
5.2.1 The flow of NFT in the protocol
5.2.2 EIP-4985 implementation
The attribute operation permission of NFT is controlled by the treasure contract.
5.2.3 Treasure contract implementation
There are two permissions that need to be controlled:
Solutions:
Refer to this treasure contract example:
6. License
The content is licensed under CC0.