-
Notifications
You must be signed in to change notification settings - Fork 618
Add ERC: ERC-721 Guarantee Extension #349
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
Reference implementation will be provided later
✅ All reviewers have approved. |
The commit 178c74f (as a parent of 69e31bf) contains errors. |
ERCS/erc-7652.md
Outdated
--- | ||
eip: 7652 | ||
title: ERC-721 Guarantee Extension | ||
description: ERC-721 Guarantor role interface extension |
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.
Your description doesn't really add any information not in your title. Try to expand on the ideas you've introduced in the title. For example, you could explain what an ERC-721 guarantee actually is.
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.
Thank you for your suggestion, the modification is as follows.
description: An extension interface that can guarantee NFT holders the ability to exchange their NFTs for circulating tokens at any time
|
||
## Abstract | ||
|
||
This specification defines functions outlining a guarantor role for instance of [EIP-721](./eip-721.md). The guarantee interface implements the user-set valuation and guarantee share for a given NFT (token ID), as well as the guarantee rights enjoyed and obligations assumed during subsequent transactions. An implementation enables the user to read or set the current guarantee value for a given NFT (token ID), and also realizes the distribution of guarantee interest and the performance of guarantee obligations. It sends the standardized events when the status changes. This proposal relies on and extends the existing [EIP-721](./eip-721.md). |
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.
This is a decent abstract, but could use a bit of text explaining what a "guarantor role" is.
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.
Thank you for your proposal, the new abstract has added a description of the responsibilities and rights of the guarantor:
Any participant can act as a guarantor to provide a subjective value assessment for an NFT. The guarantor's assessed value represents both the price the guarantor is willing to buy the NFT for and the weight value for sharing the guarantor's commission.
|
||
## Motivation | ||
|
||
NFT (token ID) commonly face the issue of insufficient market liquidity: the main reason being the lack of transparency in NFT pricing, making it difficult for users to cash out after trading and purchasing NFT (token ID). |
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 is "token ID" related to NFT here?
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.
Thank you for your attention. There is just a slight difference in detail, which is a specific NFT within the set of NFTs.
|
||
With the introduction of the guarantor role, different guarantor groups can offer various price guarantees for NFT (token ID), establishing a multi-faceted price evaluation system for NFT (token ID). | ||
|
||
After purchasing an NFT (token ID), users can return it to the guarantor at any time at the highest guaranteed price to protect their interests. |
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.
I don't think you need to follow NFT with "token ID" every time you use the initialism.
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.
Thank you for your suggestion, the new version has removed these redundant expressions.
|
||
The keywords “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. | ||
|
||
Every contract compliant to the `ERC721Guarantee` MUST implement the `IERC721Guarantee` guarantee interface. |
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.
Every contract compliant to the `ERC721Guarantee` MUST implement the `IERC721Guarantee` guarantee interface. | |
Every contract compliant with this proposal MUST implement the `IERC721Guarantee` guarantee interface. |
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.
Thank you for your suggestion, the new version has made the relevant revisions to the wording.
|
||
Every contract compliant to the `ERC721Guarantee` MUST implement the `IERC721Guarantee` guarantee interface. | ||
|
||
The **guarantee extension** is OPTIONAL for EIP-721 contracts. |
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.
The **guarantee extension** is OPTIONAL for EIP-721 contracts. |
You can just omit this because it's always implied. You can't place requirements on implementations of other proposals.
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.
Thank you for your suggestion, the new version has made the relevant revisions to the wording.
Key factors influencing the standard: | ||
|
||
- Pay attention to ensuring fairness between and within groups when allocating commissions | ||
- Keeping the number of guarantee groups (DAOs)in the interfaces to prevent contract bloat | ||
- The guarantee group is a DAO contract, which MUST implement the `ERC721TokenReceiver` interface | ||
- Simplicity | ||
- Gas Efficiency |
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.
You should go in-depth on specific choices you made, not give general thoughts on your design.
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.
Thank you for your suggestion,
These descriptions are issues that should be focuses on in the coding implementation.
The reference implementation will also pay attention to these issues.
## Reference Implementation | ||
|
||
The reference implementation will be provided 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.
## Reference Implementation | |
The reference implementation will be provided later. |
Just remove this section until you have the reference implementation ready.
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.
Thank you for your suggestion, the new version has made the relevant revisions to the wording.
|
||
## Security Considerations | ||
|
||
Needs discussion. |
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.
Needs discussion. | |
Needs discussion. <!-- TODO --> |
If you use HTML-style comments, the linter will make sure you come back to them before going into the next status.
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.
Thank you for your suggestion, the new version has corrected this mistake. Very appreciate it.
edit's suggest
检查版本错误的原因
description: 开头多余的空格是错误的
检查错误原因……
错误定位处理
错误故障定位处理
故障定位……
Did you publish the new version somewhere? I can't see it in the "Files Changed" tab, so I can't review it 😅 |
There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR 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. |
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.
All Reviewers Have Approved; Performing Automatic Merge...
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: