Add ERC: Non-transferable to EOA ERC20

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.*