-
Notifications
You must be signed in to change notification settings - Fork 830
Add ERC: ERC-20 totalSupply Extension #997
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
base: master
Are you sure you want to change the base?
Add ERC: ERC-20 totalSupply Extension #997
Conversation
ERCS/erc-7924.md
Outdated
| --- | ||
| eip: 7924 | ||
| title: ERC-20 totalSupply Extension | ||
| description: A Simple Mechanism to Manage the Maximum Supply of Stablecoin Compliant with ERC-20. |
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.
| description: A Simple Mechanism to Manage the Maximum Supply of Stablecoin Compliant with ERC-20. | |
| description: Manage the maximum supply of ERC-20 stablecoins. |
I'd suggest removing fluff from your description and optionally using the extra space to further describe your proposal.
ERCS/erc-7924.md
Outdated
|
|
||
| ## Abstract | ||
|
|
||
| This proposal defines a validator role for ERC20-compliant stablecoins and introduces the concept of maximum supply. Validators manage stablecoin collateral and calculate the maximum token supply based on collateral value. The maxSupply method is provided to query the current supply cap, ensuring totalSupply never exceeds maxSupply. |
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 proposal defines a validator role for ERC20-compliant stablecoins and introduces the concept of maximum supply. Validators manage stablecoin collateral and calculate the maximum token supply based on collateral value. The maxSupply method is provided to query the current supply cap, ensuring totalSupply never exceeds maxSupply. | |
| This proposal defines a validator role for ERC20-compliant stablecoins and introduces the concept of maximum supply. Validators manage stablecoin collateral and calculate the maximum token supply based on collateral value. The maxSupply method is provided to query the current supply cap, ensuring totalSupply never exceeds maxSupply. |
| This proposal defines a validator role for ERC20-compliant stablecoins and introduces the concept of maximum supply. Validators manage stablecoin collateral and calculate the maximum token supply based on collateral value. The maxSupply method is provided to query the current supply cap, ensuring totalSupply never exceeds maxSupply. | |
| This proposal defines a validator role for [ERC-20](./eip-20.md) compliant stablecoins and introduces the concept of maximum supply. Validators manage stablecoin collateral and calculate the maximum token supply based on collateral value. The `maxSupply` method is provided to query the current supply cap, ensuring `totalSupply` never exceeds `maxSupply`. |
ERCS/erc-7924.md
Outdated
| ## Motivation | ||
|
|
||
| Most stablecoin issuers are required to hold reserve funds or collateralized assets to back the stablecoin's value. However, existing models lack a mechanism to enforce a supply cap aligned with reserve assets. This EIP aims to: | ||
| 1. Create a new role to regulate totalSupply. |
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.
| 1. Create a new role to regulate totalSupply. | |
| 1. Create a new role to regulate `totalSupply`. |
ERCS/erc-7924.md
Outdated
| * `Issuer`: the issuer of the stable coin | ||
|
|
||
| * `Validator`: the reserve fund custodians or collateral managers |
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.
| * `Issuer`: the issuer of the stable coin | |
| * `Validator`: the reserve fund custodians or collateral managers | |
| * _Issuer_: the issuer of the stable coin | |
| * _Validator_: the reserve fund custodians or collateral managers |
Use backticks (`) only for inline code snippets.
ERCS/erc-7924.md
Outdated
|
|
||
| 1. Validator Management | ||
| + Validator address must be publicly verifiable | ||
| + The maximum token supply update operations should contain the statement or receipt from the Validator, such as CAMT052 statement. |
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.
CAMT052
This is not a commonly known term in the Ethereum space. Where is it defined?
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.
have update the description of CAMT052 statement. which is an ISO 20022 message format used for bank-to-customer intraday account reporting. It provides near real-time transaction details on an account, including both transactions and balances, offering a dynamic view of account activity.
|
The commit c828686 (as a parent of 1f548e9) contains errors. |
…/astroyhzcc/ERCs into astroyhzcc_stablecoin_max_supply
|
|
||
| 1. Validator Management | ||
| + Validator address must be publicly verifiable | ||
| + The maximum token supply update operations should contain the statement or receipt from the Validator, for example ISO 20022 message format used for bank-to-customer intraday account reporting such as CAMT.052 statement. |
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.
We do not permit links to (most) ISO standards. They are not free to access, and are therefore incompatible with the open ERC process.
| + The maximum token supply update operations should contain the statement or receipt from the Validator, for example ISO 20022 message format used for bank-to-customer intraday account reporting such as CAMT.052 statement. | ||
| + Validator changes require governance approval | ||
| 2. Supply Enforcement | ||
| + all mint operations must check:totalSupply() + mintAmount ≤ maxSupply() |
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 put code snippets in backticks (`)
| + Validator address must be publicly verifiable | ||
| + The maximum token supply update operations should contain the statement or receipt from the Validator, for example ISO 20022 message format used for bank-to-customer intraday account reporting such as CAMT.052 statement. | ||
| + Validator changes require governance approval | ||
| 2. Supply Enforcement |
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 markdown syntax for nested lists is a little off here.
| 1. Validator Role: Reserve custodians or collateral managers act as validators to ensure supply aligns with asset value. | ||
| 2. Maximum supply updates: Validators must update maxSupply promptly when collateral or reserve value changes. |
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.
Neither of these points really explain why you made a decision, which is what this section is for.
Defining what the validator role is probably belongs in specification, and setting a requirement on their behaviour definitely does.
Instead, use this section to explain why you made particular choices while developing your standard. For example, why you include a data parameter on setMaxSupply.
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: