diff --git a/ERCS/erc-9999.md b/ERCS/erc-9999.md new file mode 100644 index 00000000000..7749a6c47a6 --- /dev/null +++ b/ERCS/erc-9999.md @@ -0,0 +1,134 @@ +eip: 7991 +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 +status: Draft +type: Standards Track +category: ERC +created: 2025-07-22 +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. + +## Abstract + +This EIP introduces a novel token architecture where tokens are non-transferable to Externally Owned Accounts (EOAs). vTOKENs **MUST** exist solely within smart contracts and **MUST** automatically convert into their paired native tokens when an attempt is made to send them to an EOA. This standard defines an ERC-20 compatible interface for these virtual tokens. + +## Motivation + +DeFi protocols currently face fundamental challenges that compromise long-term stability and user trust: + +* Liquidity can be withdrawn by liquidity providers, leading to sudden price drops and breaking established price floors. +* The risk of "rug pulls" exists, where developers or large token holders can drain liquidity pools, causing significant financial loss to participants. +* Many yield farming and liquidity mining models offer only temporary solutions, often collapsing once incentives diminish. +* Users are frequently required to place trust in human-controlled admin functions, which can be exploited or misused. + +The ERC-vTOKEN standard addresses these problems by introducing a design that: + +* Prohibits the custody of vTOKENs by individual user wallets (EOAs). +* Enables seamless, automatic conversion of vTOKENs to their native token counterparts upon attempted transfer to an EOA. +* Ensures liquidity, once provided, is permanently locked within designated contracts. +* Enforces economic sustainability and prevents liquidity extraction through mathematical design. + +## Specification + +### Core Features + +1. **Non-transferable to EOAs**: vTOKENs **MUST NOT** be transferable to Externally Owned Accounts (EOAs). Attempts to transfer vTOKENs to an EOA **MUST** trigger an automatic conversion to the paired native token. +2. **Automatic Conversion**: Transfers to EOAs **MUST** trigger a conversion where the vTOKENs are burned from the sender and an equivalent amount of native tokens are transferred to the recipient EOA. +3. **Whitelist System**: Only approved smart contracts **MAY** hold vTOKENs. Implementations **SHOULD** include a mechanism to manage this whitelist. +4. **ERC-20 Compatible**: Implementations **MUST** be fully compliant with the standard [ERC-20](https://www.google.com/search?q=./eip-20.md) interface, allowing for seamless integration with existing DeFi protocols. + +### Interface + +```solidity +interface IERCvTOKEN is IERC20 { + /** + * @dev Emitted when vTOKEN is virtually converted to native token. + * @param recipient The address receiving native tokens. + * @param vTokenAmount Amount of vTOKEN attempted to transfer. + * @param nativeTokenAmount Amount of native token received. + */ + event VirtualConversion(address indexed recipient, uint256 vTokenAmount, uint256 nativeTokenAmount); + + /** + * @dev Emitted when whitelist status changes. + * @param account The address whose status changed. + * @param status New whitelist status. + */ + event WhitelistUpdated(address indexed account, bool status); + + /** + * @dev Returns whether an address can receive vTOKEN. + * @param account Address to check. + * @return bool True if whitelisted. + */ + function isWhitelisted(address account) external view returns (bool); + + /** + * @dev Calculates the native token equivalent for a given vTOKEN amount. + * @param vTokenAmount Amount of vTOKEN. + * @return uint256 Equivalent native token amount. + */ + function calculateNativeEquivalent(uint256 vTokenAmount) external view returns (uint256); + + /** + * @dev Returns the address of the paired native token. + * @return address Native token contract. + */ + function nativeToken() external view returns (address); +} +``` + +### Behavior + +* Transfers to EOAs **MUST** trigger a conversion: vTOKENs are burned from the sender, and the calculated native token equivalent is transferred to the EOA. +* Transfers between whitelisted contracts **MUST** proceed as standard ERC-20 transfers. +* Any transfer attempt to an unauthorized recipient address (i.e., not an EOA triggering conversion, and not a whitelisted contract) **MUST** cause a revert. + +## 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. +* **Burn-on-convert Model**: vTOKENs **MUST** be burned during conversion to prevent supply inflation and ensure the conservation of value. This mechanism maintains accurate supply metrics. +* **Deterministic Conversion Logic**: The `calculateNativeEquivalent` function **SHOULD** implement deterministic or oracle-based conversion rates to avoid manipulation. The rate **MAY** be fixed (e.g., 1:1) or dynamically derived (e.g., from an AMM or TWAP oracle). + +## Backwards Compatibility + +ERC-vTOKEN maintains: + +* Compatibility with existing [ERC-20](https://www.google.com/search?q=./eip-20.md) tools and functions, such as `balanceOf`, `allowance`, and `transferFrom` (when interacting with whitelisted contracts). +* Consistency in event emissions and metadata (e.g., `name()`, `symbol()`, `decimals()`). + +It is **not compatible** with: + +* Standard cryptocurrency wallets that expect to hold and directly transfer tokens from an EOA. +* Decentralized Exchange (DEX) aggregators or other protocols that do not explicitly integrate or understand the vTOKEN conversion mechanism. + +## 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. + +## Reference Implementation + +A reference implementation **SHOULD** be available in the repository: [https://github.com/aethercycle/ERC-vTOKEN](https://github.com/aethercycle/ERC-vTOKEN) + +## Security Considerations + +* **Reentrancy**: The `_transfer` function and any logic involving external calls (e.g., native token transfer during conversion) **MUST** be protected against reentrancy attacks, ideally using a `nonReentrant` modifier or following the checks-effects-interactions pattern. +* **Whitelist Management**: The management of the whitelist **SHOULD** be restricted to authorized entities (e.g., `Ownable` or a DAO). For maximum security, the whitelist **MAY** be made immutable or fully governance-controlled post-deployment. +* **Conversion Failure**: The contract **MUST** gracefully revert if it lacks sufficient native token balance to perform a required conversion. Automated refill mechanisms **SHOULD** be considered. +* **Admin Privileges**: It is **STRONGLY RECOMMENDED** to renounce ownership or transfer admin privileges to a time-locked contract or DAO post-deployment to minimize central points of failure and potential for abuse. + +## Copyright + +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.*