Add ERC: Valued Tokens with Layered Liquidity #368
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eip-review-bot
changed the title
eip-review-bot
changed the title
eip-review-bot
changed the title
|
The commit f00d1c8 (as a parent of f708ba4) contains errors. |
|
Welcome to join our discuss by visit ethereum-magicians |
SamWilsn
reviewed
Apr 8, 2024
ERCS/erc-2510.md
Outdated
| @@ -0,0 +1,261 @@ | |||
| --- | |||
| eip: 2510 | |||
There was a problem hiding this comment.
Suggested change
| eip: 2510 | |
| eip: 7680 |
Don't forget to also rename the file!
There was a problem hiding this comment.
So what you mean is that I need rename erc-2510.md to erc-7680.md and re-pr right now?
There was a problem hiding this comment.
I was able to update your pull request for you. For now, there is nothing you need to do. An EIP Editor will be by eventually to give you more in-depth feedback.
There was a problem hiding this comment.
You should update all other references in the PR & the discussion on Eth Magicians to use the assigned number.
abcoathup
reviewed
Apr 15, 2024
ERCS/erc-7680.md
Outdated
| title: Valued Tokens with Layered Liquidity | ||
| description: Layered liquidity protocol to ensure intrinsic value and enhanced stability for tokens | ||
| author: Jackie JC.Lee (@catiga) | ||
| discussions-to: https://ethereum-magicians.org/t/erc2510-embedding-perpetual-value-and-liquidity-in-tokens/19577 |
There was a problem hiding this comment.
Suggested change
| discussions-to: https://ethereum-magicians.org/t/erc2510-embedding-perpetual-value-and-liquidity-in-tokens/19577 | |
| discussions-to: https://ethereum-magicians.org/t/erc-7680-embedding-perpetual-value-and-liquidity-in-tokens/19577 |
There was a problem hiding this comment.
Yes, I've made erc number changed to correct
gaudren
reviewed
Apr 22, 2024
| The primary motivation behind this proposal is to address the vulnerability of token value in traditional ERC-20 tokens, which often relies on third-party liquidity pools. These pools are susceptible to sudden and significant value depletion, often resulting in tokens being rendered valueless, particularly in the event of liquidity withdrawal by pool creators, colloquially known as 'rug pulls'. Such events can undermine investor confidence and destabilize the token ecosystem. By ensuring that each proposal token maintains an intrinsic base value, the standard aims to protect token holders, enhance market stability, and promote trust in the tokenization model on the Ethereum blockchain. This innovation is especially critical in a landscape where decentralized finance is becoming increasingly prevalent, and the assurance of token value integrity is paramount. | ||
|
|
||
| ## Specification | ||
|
|
There was a problem hiding this comment.
Suggested change
| The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174. | |
| ``` | ||
|
|
||
| #### Solid Value Keeper for more independent execution | ||
| In the implementation contract, the Keeper private _keeper attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. This architectural decision underpins the robustness of the token's value support mechanism, by safeguarding the foundational eth reserves that back the intrinsic value of the token, and thereby, fortifying investor confidence in the token's stability and reliability. |
There was a problem hiding this comment.
Suggested change
| In the implementation contract, the Keeper private _keeper attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. This architectural decision underpins the robustness of the token's value support mechanism, by safeguarding the foundational eth reserves that back the intrinsic value of the token, and thereby, fortifying investor confidence in the token's stability and reliability. | |
| In the implementation contract, the Keeper private `_keeper` attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. This architectural decision underpins the robustness of the token's value support mechanism, by safeguarding the foundational eth reserves that back the intrinsic value of the token, and thereby, fortifying investor confidence in the token's stability and reliability. |
| Implementation tokens MUST maintain a base liquidity pool that is separate from external liquidity providers like DEXs. This pool serves as the foundational layer of value for the tokens and is managed by the token contract itself. | ||
|
|
||
| ### Value Enhancement and Retrieval | ||
| Token holders MAY contribute ETH to enhance the token's value, and MAY retrieve the equivalent value in ETH based on their token holdings, as per the enhanceTokenValue and retrieveTokenValue methods, respectively. |
There was a problem hiding this comment.
Suggested change
| Token holders MAY contribute ETH to enhance the token's value, and MAY retrieve the equivalent value in ETH based on their token holdings, as per the enhanceTokenValue and retrieveTokenValue methods, respectively. | |
| Token holders MAY contribute ETH to enhance the token's value, and MAY retrieve the equivalent value in ETH based on their token holdings, as per the `enhanceTokenValue` and `retrieveTokenValue` functions, respectively. |
| ``` | ||
|
|
||
| ### Base Liquidity Pool | ||
| Implementation tokens MUST maintain a base liquidity pool that is separate from external liquidity providers like DEXs. This pool serves as the foundational layer of value for the tokens and is managed by the token contract itself. |
There was a problem hiding this comment.
Suggested change
| Implementation tokens MUST maintain a base liquidity pool that is separate from external liquidity providers like DEXs. This pool serves as the foundational layer of value for the tokens and is managed by the token contract itself. | |
| Implementation tokens MUST maintain a base liquidity pool that is separate from external liquidity providers like decentralized exchanges (DEXs). This pool serves as the foundational layer of value for the tokens and is managed by the token contract itself. |
|
|
||
| ## Rationale | ||
|
|
||
| The standard was motivated by the desire to create a more stable and transparent token economy within the Ethereum ecosystem. In traditional ERC-20 tokens, value is often only as stable as the liquidity provided by third-party decentralized exchanges (DEXs). This standard aims to mitigate the risks of market manipulation and the potential for rapid devaluation due to liquidity withdrawal by introducing an inherent base liquidity pool within the token contract itself. |
There was a problem hiding this comment.
Suggested change
| The standard was motivated by the desire to create a more stable and transparent token economy within the Ethereum ecosystem. In traditional ERC-20 tokens, value is often only as stable as the liquidity provided by third-party decentralized exchanges (DEXs). This standard aims to mitigate the risks of market manipulation and the potential for rapid devaluation due to liquidity withdrawal by introducing an inherent base liquidity pool within the token contract itself. | |
| The standard was motivated by the desire to create a more stable and transparent token economy within the Ethereum ecosystem. In traditional ERC-20 tokens, value is often only as stable as the liquidity provided by third-party DEXs. This standard aims to mitigate the risks of market manipulation and the potential for rapid devaluation due to liquidity withdrawal by introducing an inherent base liquidity pool within the token contract itself. |
| ``` | ||
|
|
||
| #### Solid Value Keeper for more independent execution | ||
| In the implementation contract, the Keeper private _keeper attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. This architectural decision underpins the robustness of the token's value support mechanism, by safeguarding the foundational eth reserves that back the intrinsic value of the token, and thereby, fortifying investor confidence in the token's stability and reliability. |
There was a problem hiding this comment.
Suggested change
| In the implementation contract, the Keeper private _keeper attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. This architectural decision underpins the robustness of the token's value support mechanism, by safeguarding the foundational eth reserves that back the intrinsic value of the token, and thereby, fortifying investor confidence in the token's stability and reliability. | |
| In the implementation contract, the Keeper private _keeper attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. |
Explaining architectural decisions should go in the Rationale section.
| * Provides mechanisms for adding, removing, and extending liquidity in a secure manner. | ||
| * Designed to be extended by ERC-2510 token contracts for integrated liquidity management. | ||
| */ | ||
| abstract contract ERC2510Liquidity is ReentrancyGuard { |
There was a problem hiding this comment.
The Specification section should only detail the externally visible behaviour of the contract. Using an abstract contract likely means you're including implementation details.
| ``` | ||
|
|
||
| #### Solid Value Keeper for more independent execution | ||
| In the implementation contract, the Keeper private _keeper attribute plays a pivotal role in enhancing the protocol's security and stability features by segregating the eth held in the base liquidity pool from the standard liquidity pool integrated within the token contract. The Keeper contract is a dedicated entity designed to manage the eth specifically allocated for the base liquidity pool, ensuring a clear distinction and protection of these funds from the operational mechanics of the standard liquidity pool activities. This architectural decision underpins the robustness of the token's value support mechanism, by safeguarding the foundational eth reserves that back the intrinsic value of the token, and thereby, fortifying investor confidence in the token's stability and reliability. |
There was a problem hiding this comment.
eth
Please use consistent casing for eth/ETH.
| Token holders MAY contribute ETH to enhance the token's value, and MAY retrieve the equivalent value in ETH based on their token holdings, as per the enhanceTokenValue and retrieveTokenValue methods, respectively. | ||
|
|
||
| ### Liquidity Lock and Unlock Mechanism | ||
| The standard MUST define a clear mechanism for liquidity locking and unlocking, which safeguards against premature withdrawals from the base liquidity pool and ensures long-term value stability for the token. |
There was a problem hiding this comment.
Don't make requirements on the standard ("The standard MUST...".) Just define the mechanism.
|
|
||
| ## Specification | ||
|
|
||
| The standard is designed to introduce a new layer of liquidity enhancement for ERC-20 compatible tokens. This specification details the required functionality for implementing the standard, which allows for competing and interoperable implementations across different Ethereum platforms, such as Besu, Erigon, EthereumJS, Go-Ethereum, Nethermind, among others. |
There was a problem hiding this comment.
Suggested change
| The standard is designed to introduce a new layer of liquidity enhancement for ERC-20 compatible tokens. This specification details the required functionality for implementing the standard, which allows for competing and interoperable implementations across different Ethereum platforms, such as Besu, Erigon, EthereumJS, Go-Ethereum, Nethermind, among others. |
This is already covered by your abstract and motivation.
SamWilsn
reviewed
Jun 7, 2024
| ## Abstract | ||
|
|
||
| This proposal establishes a protective layer of liquidity within [ERC-20](./eip-20.md), guaranteeing a minimum intrinsic value and countering the risks associated with liquidity withdrawal. | ||
| This proposal standard is a protocol that extends the [ERC-20] token standard to integrate a foundational liquidity pool, serving as a value floor for each token. This innovation ensures that tokens have a base value, which is protected from total loss in scenarios where liquidity is entirely removed. The protocol mandates a minimum inherent value for tokens by embedding a base amount of Ether within the smart contract, calculated and represented as a 'solid value' floor. This system also enables the direct extraction of this underlying value by token holders, providing a fail-safe mechanism and enhanced stability. Additionally, the proposal supports the dynamic enhancement of token value through community contributions to the liquidity pool and includes protective measures against value dilution during token transfer and burning processes. |
There was a problem hiding this comment.
Suggested change
| This proposal standard is a protocol that extends the [ERC-20] token standard to integrate a foundational liquidity pool, serving as a value floor for each token. This innovation ensures that tokens have a base value, which is protected from total loss in scenarios where liquidity is entirely removed. The protocol mandates a minimum inherent value for tokens by embedding a base amount of Ether within the smart contract, calculated and represented as a 'solid value' floor. This system also enables the direct extraction of this underlying value by token holders, providing a fail-safe mechanism and enhanced stability. Additionally, the proposal supports the dynamic enhancement of token value through community contributions to the liquidity pool and includes protective measures against value dilution during token transfer and burning processes. | |
| This proposal extends ERC-20 with a foundational liquidity pool, serving as a value floor for each token. This innovation ensures that tokens have a base value, which is protected from total loss in scenarios where liquidity is entirely removed. The protocol mandates a minimum inherent value for tokens by embedding a base amount of Ether within the smart contract, calculated and represented as a 'solid value' floor. This system also enables the direct extraction of this underlying value by token holders, providing a fail-safe mechanism and enhanced stability. Additionally, the proposal supports the dynamic enhancement of token value through community contributions to the liquidity pool and includes protective measures against value dilution during token transfer and burning processes. |
Bit of rewording.
| ```solidity | ||
| pragma solidity ^0.8.20; | ||
|
|
||
| import "@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol"; |
There was a problem hiding this comment.
Avoid importing OpenZeppelin in the Specification section. Generally, you can use the interface names from the ERCs themselves (either IERC20 or EIP20Interface in this case.)
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces ERC-2510, a new token standard proposal that aims to embed a foundational layer of liquidity within ERC-20 tokens to ensure a minimum intrinsic value and offer enhanced stability. ERC-2510 achieves this by integrating a base liquidity pool mechanism, which functions as a protective value floor for each token. This not only fortifies tokens against the total loss in liquidity withdrawal scenarios but also allows token holders to actively participate in the valuation of their assets.
The proposed standard is designed to be fully compatible with ERC-20 while introducing novel features such as direct liquidity enhancement and retrieval, and robust measures against devaluation. The addition of these features addresses the urgent need for more resilient token economics, especially in the face of 'rug pulls' and market volatility.
Key components of ERC-2510 include:
This PR contains the initial draft of the ERC-2510 standard, including detailed specifications, rationale, and security considerations. It is submitted for discussion and feedback from the Ethereum community.
For more information and ongoing discussion, please visit the dedicated thread on Ethereum Magicians: ERC2510: Embedding Perpetual Value and Liquidity in Tokens.
Your contributions and insights are valuable to refine and improve this proposal. Thank you for considering ERC-2510 as a candidate for Ethereum's growing list of innovative standards.