-
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: Redeemable Tokens #6732
Conversation
File
|
@abcoathup Oh okay, I must have missed that. I apologize. I will remove the EIP number. However, it would be easier to keep this number since it's not taken and used extensively in the reference implementation code. I can absolutely change that if necessary. |
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 fix the CI errors.
We're experimenting with a new automated system to assign EIP numbers. Feel free to ignore the eip walidator error about the missing eip
header for now.
Avoid self-references. Simply refer to the current eip as "this EIP", rather than by "EIP-X". For the code, simply use descriptive names for the classes. It's much more readable than an opaque number, anyway.
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 get the drill.
Co-authored-by: Andrew B Coathup <[email protected]>
The commit 4699fd2 (as a parent of 1a84d4a) contains errors. |
@eth-bot rerun |
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.
In addition to my other comments, would you mind reducing your reference implementation down to something more minimal? At minimum you should remove any of the OZ source. The readers can find those implementations themselves.
Generally the reference implementation should be one or two files to illustrate your proposal, and not a fully working production contract.
EIPS/eip-6732.md
Outdated
|
||
## Reference Implementation | ||
|
||
- [Reference implementation](../assets/eip-6732/) |
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 markdown renderer probably won't let you link to the whole directory. We normally recommend linking to the readme.
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.
Do you mean the reference implementation's readme? If I should remove the migrations and slim the implementation down I suppose I should also remove the reference implementation's readme since it's not necessary at that point. Correct?
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.
Yeah, if you cram the whole reference implementation into a single file, just link to that. If not, you can make a README.md
that's just a manual listing of files:
# ERC-XXXX Reference Implementation
* [SomeContract.sol](./SomeContract.sol)
* [MagicInterface.sol](./MagicInterface.sol)
truffle deploy | ||
``` | ||
|
||
However, dont forget to link Ganache to the project (tutorial [here](https://trufflesuite.com/docs/ganache/how-to/link-a-truffle-project/)), alternatively create a Ganache quickstart workspace and match the server host and port in `truffle-config.js`. |
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'll need to remove external links from your reference implementation as well.
assets/eip-6732/contracts/.gitkeep
Outdated
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.
Remove this file please.
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 reference implementation shouldn't need migrations. It shouldn't be a fully working project, just an illustrative example without any extra code.
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.
Would it be sufficient to keep the files under the examples and token folders and remove the rest including utils and migrations?
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.
That sounds reasonable, yes.
Co-authored-by: Sam Wilson <[email protected]>
Co-authored-by: Sam Wilson <[email protected]>
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'll also still need to remove external links and build files from your reference implementation.
|
||
- Implementers SHOULD NOT allow tokens to be minted if total supply exceeds max supply. | ||
- Implementers SHOULD increment total supply upon minting and decrement upon burning. | ||
- Implementers are RECOMMENDED to override the `_beforeMint` hook to increment total supply upon minting and decrement upon burning. |
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 _beforeMint
function is part of the reference implementation, not the specification itself. The Specification section should be understandable on its own without the other sections, while the reference implementation should help to clarify what's in the the Specification section.
- Implementers are RECOMMENDED to override the `_beforeMint` hook to increment total supply upon minting and decrement upon burning. |
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. 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. |
I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually. As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process. If there is relevant history here, please link to this PR from the new pull request. On behalf of the EIP Editors, I apologize for this inconvenience. |
A proposal for redeemable tokens.