Add ERC: Non-transferable to EOA ERC20 #1129
Conversation
File
|
eip-review-bot
changed the title
ERCS/erc-9999.md
Outdated
| ## Abstract | ||
|
|
||
| This EIP introduces a new token architecture where tokens are non-transferable to externally owned accounts (EOAs), enabling mathematically permanent liquidity. vTOKENs exist only within smart contracts and convert automatically into native tokens when sent to EOAs. This model prevents rug pulls, liquidity extraction, and ensures immutable liquidity depth, while maintaining [ERC-20](./eip-20.md) interface compatibility. |
There was a problem hiding this comment.
You begin to explain benefits here ("prevents rug pulls…"). Abstracts should only describe what the ERC does, not why. (while keeping it an overview).
There was a problem hiding this comment.
Thank you for pointing out the structure of the "Abstract" section. You are absolutely right.
The "Abstract" MUST serve as a concise overview of what the ERC standard does, rather than detailing its benefits or motivations. We will revise this section to remove the explanatory benefits such as "prevents rug pulls, liquidity extraction, and ensures immutable liquidity depth" and focus purely on describing the core functionality and architecture of the ERC-vTOKEN.
The detailed "why" and the problems it solves will be fully articulated in the "Motivation" section, where it appropriately belongs.
Thank you again for helping us refine the EIP to meet the standard formatting and best practices.
| - Locking liquidity in contracts permanently | ||
| - Enforcing economic sustainability mathematically | ||
|
|
||
| ## Specification |
There was a problem hiding this comment.
There’s a clear need to include the RFC 2119/8174 disclaimer in here.
Also, using the keywords (MUST, SHOULD, etc.) consistently makes the spec easier to follow and implement, to clearly distinguish between strict requirements and flexible recommendations throughout the spec.
There was a problem hiding this comment.
Dear bomanaps,
Thank you for your valuable feedback on the ERC-vTOKEN EIP draft. We truly appreciate your detailed review.
You are absolutely correct. There is a clear need to include the RFC 2119/8174 disclaimer to properly define the keywords used in the specification. We will add the following statement to the "Abstract" or "Introduction" section of the EIP:
"The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 [RFC2119] when, and only when, they appear in all capitals, as defined in RFC 8174."
Furthermore, we agree that using these keywords consistently throughout the EIP will significantly enhance its clarity and ease of implementation. We will revise the "Specification" and "Security Considerations" sections, among others, to rigorously apply MUST, SHOULD, etc., to distinguish clearly between strict requirements and flexible recommendations.
For example, in "Core Features", instead of "Non-transferable to EOAs: vTOKENs revert when transferred to EOAs", we will phrase it as:
"vTOKENs MUST NOT be transferable to Externally Owned Accounts (EOAs); attempts to transfer to an EOA MUST trigger an automatic conversion to the paired native token."
And in "Security Considerations", "Reentrancy: Conversion logic should use standard protections (e.g. nonReentrant)" will become:
"Conversion logic SHOULD utilize reentrancy guards (e.g., nonReentrant) to prevent reentrancy attacks."
We believe these updates will greatly improve the precision and readability of the ERC-vTOKEN EIP, aligning it more closely with established EIP formatting standards.
Thank you again for your critical input; it is invaluable in refining this proposal.
Best regards,
Fukuhi
AetherCycle Protocol
|
|
||
| Reference implementation available in the repository: [`ERC-vTOKEN`](../ERC-vTOKEN) | ||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
Consider adding what happens if a user accidentally sends vTOKEN via a raw transfer from an EOA?
Can the token be rescued or is it burned?
There was a problem hiding this comment.
Consider adding what happens if a user accidentally sends vTOKEN via a raw transfer from an EOA? Can the token be rescued or is it burned?
Dear bomanaps,
Thank you for your insightful question regarding the handling of vTOKENs if an attempt is made to send them via raw transfer to an Externally Owned Account (EOA).
We appreciate you highlighting this crucial scenario, and it touches upon a core design principle of the ERC-vTOKEN standard: vTOKENs are fundamentally non-transferable to and cannot be held by EOAs under any circumstances. This is a defining feature engineered to enable permanent, mathematically-enforced liquidity.
To clarify what would occur in such an event:
If a transfer to an EOA is attempted (even via a raw transfer or any other method), the _transfer function within the ERC-vTOKEN contract will automatically detect that the recipient is an EOA and not on the whitelist.
Instead of the vTOKEN reaching the EOA, a virtual conversion mechanism is triggered.
The vTOKEN amount from the sender (which must be a whitelisted contract) is burned, and an equivalent amount of the paired native token is transferred to the recipient EOA.
Therefore, the vTOKEN itself is not lost or "burned" in an unrecoverable sense from the user's perspective. Instead, it is seamlessly converted into its usable native token equivalent, ensuring value preservation while maintaining the integrity of the vTOKEN's permanent liquidity model.
This design ensures a seamless user experience where users always receive usable tokens, while preventing the confusion of holding non-transferable tokens.
We believe this automatic conversion mechanism robustly addresses the concern, ensuring that vTOKENs never exist in user wallets and that any "accidental" transfers to EOAs result in the intended native token conversion. We will consider adding a more explicit note regarding this specific scenario in the "Security Considerations" or "Rationale" section of the ERC-vTOKEN documentation for further clarity.
Thank you again for your valuable feedback, which helps strengthen the standard.
Best regards,
Fukuhi
AetherCycle Protocol
Co-authored-by: Andrew B Coathup <[email protected]>
eip-review-bot
changed the title
This commit incorporates feedback to enhance the EIP's clarity and adherence to EIP standards. Key changes include: - Added RFC 2119/8174 disclaimer for keyword interpretation. - Applied consistent use of 'MUST', 'SHOULD', 'MAY', etc., throughout the Specification and Security Considerations sections. - Revised the Abstract to focus purely on describing the ERC's functionality, moving benefits to the Motivation section.
|
The commit 77388be (as a parent of f5d9d10) contains errors. |
There was a problem hiding this comment.
You'll need to update the file name.
| @@ -0,0 +1,134 @@ | |||
| eip: 7991 | |||
| title: Non-transferable to EOA ERC20 | |||
There was a problem hiding this comment.
| title: Non-transferable to EOA ERC20 | |
| title: Non-transferable to EOA ERC-20 |
| @@ -0,0 +1,134 @@ | |||
| eip: 7991 | |||
| title: Non-transferable to EOA ERC20 | |||
There was a problem hiding this comment.
This title does a poor job of conveying the core idea of the proposal. This token isn't just about not being transferable to EOAs, but also that it converts to native tokens.
It's also a bit weird grammatically.
| requires: 20 | ||
| --- | ||
|
|
||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] when, and only when, they appear in all capitals, as defined in RFC 8174. |
There was a problem hiding this comment.
This should only appear in the Specification section. Also, we don't really cite BCPs, just the RFCs.
| title: Non-transferable to EOA ERC20 | ||
| description: ERC-20-compatible token that only exists in contracts and auto-converts to native tokens for EOAs. | ||
| author: Fukuhi (@aethercycle) | ||
| discussions-to: https://ethereum-magicians.org/t/erc-vtoken-virtual-token-standard/12345 |
There was a problem hiding this comment.
You actually need to create the discussion topic...
|
|
||
| ## Rationale | ||
|
|
||
| * **Transfer Override**: Overriding the standard `_transfer` function **MUST** be implemented to ensure all transfer logic paths correctly enforce the virtual conversion and whitelist rules. This maintains ERC-20 compatibility while adding the unique vTOKEN behavior. |
There was a problem hiding this comment.
_transfer isn't a standard function.
| ## Rationale | ||
|
|
||
| * **Transfer Override**: Overriding the standard `_transfer` function **MUST** be implemented to ensure all transfer logic paths correctly enforce the virtual conversion and whitelist rules. This maintains ERC-20 compatibility while adding the unique vTOKEN behavior. | ||
| * **Whitelist Enforcement**: An explicit whitelist **SHOULD** be used to prevent unauthorized contract interactions and allow precise control over vTOKEN circulation. Typical whitelisted addresses include liquidity pool contracts, routers, and protocol treasuries. |
There was a problem hiding this comment.
Don't create new requirements outside the Specification section. The Rationale section should only explain why requirements exist, not make new ones.
| ## Test Cases | ||
|
|
||
| Comprehensive test cases **SHOULD** be provided in the reference repository to cover critical scenarios, including: | ||
|
|
||
| * Transfer to an EOA **MUST** trigger conversion to native tokens. | ||
| * Transfer to a whitelisted contract **MUST** be allowed and behave as a standard ERC-20 transfer. | ||
| * Transfer to an unknown (non-whitelisted, non-EOA) address **MUST** revert. | ||
| * Conversion with insufficient native token balance in the vTOKEN contract **MUST** revert. |
There was a problem hiding this comment.
Test cases should be simple inputs/outputs/state changes, or possibly unit tests defined with some framework. They cannot just be vague descriptions of what test cases will eventually exist.
Note that you do not have to provide test cases. For now, I'd just remove this section and add it back later if you decide to spec them out.
|
|
||
| ## Reference Implementation | ||
|
|
||
| A reference implementation **SHOULD** be available in the repository: [https://github.com/aethercycle/ERC-vTOKEN](https://github.com/aethercycle/ERC-vTOKEN) |
There was a problem hiding this comment.
We don't permit links outside our repository (with limited exceptions). If you'd like to include a simple reference implementation, you may do so in the assets directory.
| Copyright and related rights waived via [CC BY-SA 4.0](https://www.google.com/search?q=../LICENSE-CC-BY-SA-4.0.md). | ||
|
|
||
| *This draft EIP proposes a new ERC standard for virtual tokens. Feedback and implementations are welcomed via the GitHub repository.* |
There was a problem hiding this comment.
Please use the exact license waiver from the eip template.
5 participants
ERC-vTOKEN: Virtual Token Standard for Mathematically Permanent Liquidity
Summary
This ERC proposes a novel token architecture where vTOKENs exist exclusively within smart contracts and liquidity pools, fundamentally unable to be transferred to externally owned accounts (EOAs). This standard establishes a framework for creating permanent, mathematically-enforced liquidity that is immune to removal or rug pull events, all while maintaining full ERC-20 compatibility for seamless protocol interactions.
Key Benefits
Mathematical Anti-Rug Pull: Eliminates the possibility of rug pulls by preventing the removal of initial liquidity, as vTOKENs cannot be withdrawn to EOAs.
Permanent Liquidity Depth: Ensures a continuously growing and unbreakable liquidity pool, as vTOKENs remain locked within designated contracts, fostering long-term stability.
Enhanced Trust & Security: Reduces reliance on trust in developers or centralized entities, as the liquidity mechanism is enforced by the token's core logic.
Seamless User Experience: vTOKENs automatically convert to their paired native tokens upon attempted transfer to non-whitelisted addresses, providing users with immediately usable assets.
Anti-Fragile Design: The system becomes stronger under pressure, as economic actions (e.g., conversions, protocol fees) contribute to the permanent locked liquidity.
ERC-20 Compatibility: Maintains the standard ERC-20 interface for balanceOf(), allowance(), and event emissions, allowing broad integration with existing DeFi tools and protocols.
Use Cases
Perpetual Decentralized Exchanges (DEXs): Creating liquidity pools where the vTOKEN side of the pair is permanently locked, ensuring a continuous trading environment.
Autonomous Treasuries: Protocols can convert a portion of their revenue into vTOKENs to build a self-sustaining and ever-growing permanent liquidity base.
Fair Launch Mechanisms: Enabling token distribution where the contributed funds are immediately and permanently locked as liquidity, providing instant and secure price discovery.
Non-Custodial Staking/Farming: Designing yield-generating protocols where underlying liquidity is mathematically secured and cannot be withdrawn by administrators.
Bonding Curves with Permanent Liquidity: Implementing token bonding curves where the acquired collateral forms a permanent, non-removable liquidity pool.