fix: eip walidator and other

Signed-off-by: MASDXI <[email protected]>
ethereum · Nov 15, 2024 · 756a3d6 · 756a3d6
1 parent d072092
commit 756a3d6
Showing 1 changed file with 24 additions and 28 deletions.
diff --git a/ERCS/erc-7818.md b/ERCS/erc-7818.md
@@ -1,26 +1,23 @@
 ---
 eip: 7818
-title: Expirable ERC20
-description: An extension of the ERC20 standard that enables the creation of fungible tokens with configurable expiration features, allowing for time-sensitive use cases.
+title: Expirable ERC-20
+description: An ERC-20 extension for creating fungible tokens with expiration, supporting time-limited use cases.
 author: sirawt (@MASDXI), ADISAKBOONMARK (@ADISAKBOONMARK)
 discussions-to: https://ethereum-magicians.org/t/erc-7818-expirable-mechanism-for-erc20-token/21655
 status: Draft
 type: Standards Track
 category: ERC
 created: 2024-11-13
+requires: 20
 ---
 
-## Simple Summary
-
-An extended interface to enables fungible token to possess expiration capabilities, allowing them to expire after a predetermined period of time.
-
 ## Abstract
 
-Introduces an extension for `ERC20` tokens , which facilitates the implementation of an expiration mechanism. Through this extension, tokens are designated a predetermined validity period, after which they become invalid and can no longer be transferred or used. This functionality proves beneficial in scenarios such as time-limited bond, loyalty reward , or game token necessitating automatic invalidation after a specific duration. The extension is meticulously crafted to seamlessly align with the existing `ERC20` standard, ensuring smooth integration with prevailing token contracts, while concurrently introducing the capability to govern and enforce token expiration at the contract level.
+Introduces an extension for `ERC-20` tokens , which facilitates the implementation of an expiration mechanism. Through this extension, tokens are designated a predetermined validity period, after which they become invalid and can no longer be transferred or used. This functionality proves beneficial in scenarios such as time-limited bond, loyalty reward , or game token necessitating automatic invalidation after a specific duration. The extension is meticulously crafted to seamlessly align with the existing `ERC-20` standard, ensuring smooth integration with prevailing token contracts, while concurrently introducing the capability to govern and enforce token expiration at the contract level.
 
 ## Motivation
 
-This extension standard facilitates the development of `ERC20` standard compatible tokens featuring expiration dates. This capability broadens the scope of potential applications, particularly those involving time-sensitive assets. Expirable tokens are well-suited for scenarios necessitating temporary validity, including:
+This extension standard facilitates the development of `ERC-20` standard compatible tokens featuring expiration dates. This capability broadens the scope of potential applications, particularly those involving time-sensitive assets. Expirable tokens are well-suited for scenarios necessitating temporary validity, including:
 
 - Bonds or financial instruments with defined maturity dates
 - Time-constrained assets within gaming ecosystems
@@ -31,17 +28,17 @@ This extension standard facilitates the development of `ERC20` standard compatib
 
 ## Rationale
 
-The rationale for developing an expirable `ERC20` token extension is based on several key requirements that ensure its practicality and adaptability for various applications to
+The rationale for developing an expirable `ERC-20` token extension is based on several key requirements that ensure its practicality and adaptability for various applications to
 
-- Compatibility with the existing `ERC20` standard. The extension should integrate smoothly with the `ERC20` interface, This ensures compatibility with existing token ecosystems and third-party tools like wallets and blockchain explorers.
+- Compatibility with the existing `ERC-20` standard. The extension should integrate smoothly with the `ERC-20` interface, This ensures compatibility with existing token ecosystems and third-party tools like wallets and blockchain explorers.
 - Flexible design for business use cases. The smart contract should be extensible, allowing businesses to tailor the expiration functionality to their specific needs, whether it’s dynamic reward systems or time-sensitive applications.
 - Configurable expiration period. After deployment, users should have the flexibility to define and modify the expiration period of tokens according to their business requirements, supporting various use cases.
 - Configurable block time after network upgrades. Following a blockchain network upgrade, block times may fluctuate upward or downward. The smart contract must support configurable block times to allow dynamic adjustments to the block times, ensuring expiration calculations remain accurate as transaction speeds evolve.
-- Automatic selection of nearly expired tokens, When transferring tokens, the system should prioritize tokens that are approaching their expiration date, following a First-In-First-Out (`FIFO`) approach. This mechanism encourages users to utilize their tokens before they expire. Datat structure that suitable is `List` and `Queue`.
+- Automatic selection of nearly expired tokens, When transferring tokens, the system should prioritize tokens that are approaching their expiration date, following a First-In-First-Out (`FIFO`) approach. This mechanism encourages users to utilize their tokens before they expire. Data structure that suitable is `List` and `Queue`.
 - Effortless on state management, The contract’s design minimizes the need for operation `WRITE` or `UPDATE` frequent on-chain state maintenance. By reducing reliance on off-chain indexing or caching, the system optimizes infrastructure usage and ensures streamlined performance without unnecessary dependencies. This design reduces operational overhead while keeping state securely maintained within the chain.
-- Resilient Architecture, The contract architecture is built for robustness, supporting `EVM` types `1`, `2`, and `2.5`, and remains fully operational on Layer 2 solutions with sub-second block times. By anchoring operations to `block.number`, the system ensures asset integrity and continuity, even during prolonged network outages, safeguarding against potential asset loss. see more detail in [taiko article on EVM Types](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4)
-
-## Design and Technique
+- Resilient Architecture, The contract architecture is built for robustness, supporting `EVM` types `1`, `2`, and `2.5`, and remains fully operational on Layer 2 solutions with sub-second block times. By anchoring operations to `block.number`, the system ensures asset integrity and continuity, even during prolonged network outages, safeguarding against potential asset loss.  
+  
+### Design and Technique
 
 #### Sliding Window Algorithm for maintain window to look for expiration balance
 
@@ -73,13 +70,13 @@ In this design, the buffering slot is the critical element that requires careful
 
 #### First-In-First-Out (FIFO) priority to enforce token expiration rules
 
-Enforcing `FIFO` priority ensures that tokens nearing expiration are processed before newer ones, aligning with the token lifecycle and expiration rules. This method eliminates the need for additional off-chain computation and ensures that all token processing occurs efficiently on-chain, fully compliant with the ERC20 interface.
+Enforcing `FIFO` priority ensures that tokens nearing expiration are processed before newer ones, aligning with the token lifecycle and expiration rules. This method eliminates the need for additional off-chain computation and ensures that all token processing occurs efficiently on-chain, fully compliant with the ERC-20 interface.
 A **Sorted List** is integral to this approach. Each slot maintains its own list, sorted by token creation which can be `block.number` or `block.timestamp`, This separation ensures that tokens in one slot do not interfere with the balance handling in another. The contract can independently manage token expirations within each slot to maintain accuracy and predictability in processing account balances.
 
 #### Sliding Window 
 
 ``` Solidity
-// SPDX-License-Identifier: MIT
+// SPDX-License-Identifier: CC0-1.0
 pragma solidity >=0.8.0 <0.9.0;
 
 /// @title An implemation sliding window algorithm in Solidity, the sliding frame relying on block-height rather than block-timestmap.
@@ -342,7 +339,9 @@ library SlidingWindow {
 }
 ```
 
-## Interfaces
+## Specification
+
+The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
 ```solidity
 function tokenList(address account,uint256 era,uint8 slot) external view returns (uint256[] memory list);
@@ -368,7 +367,7 @@ function balanceOfBlock(uint256 blocknumber) returns (uint256);
 function transfer(address to, uint256 fromEra, uint8 fromSlot, uint256 toEra, uint8 toSlot) external returns (bool);
 ```
 
-- Purpose: This function works similarly to `ERC20` transfer but allows to move tokens within specific eras and slots.
+- Purpose: This function works similarly to `ERC-20` transfer but allows to move tokens within specific eras and slots.
 - Parameters:
   - `to`: The address of the account to which tokens are being transferred.
   - `fromEra`: The era from which the tokens are being transferred.
@@ -381,7 +380,7 @@ function transfer(address to, uint256 fromEra, uint8 fromSlot, uint256 toEra, ui
 function transferFrom(address form, address to, uint256 fromEra,uint8 fromSlot,uint256 toEra,uint8 toSlot) external returns (bool);
 ```
 
-- Purpose: This function works similarly to `ERC20` transferFrom but allows to move tokens within specific eras and slots.
+- Purpose: This function works similarly to `ERC-20` transferFrom but allows to move tokens within specific eras and slots.
 - Parameters:
   - `from`: The address of the account from which tokens are being transferred.
   - `to`: The address of the account to which tokens are being transferred.
@@ -415,16 +414,13 @@ Assuming each `Era` contains 4 `slots`, which aligns with familiar time-based di
 
 ## Security Considerations
 
-- [SC06:Denial Of Service](https://owasp.org/www-project-smart-contract-top-10/2023/en/src/SC06-denial-of-service-attacks.html) Run out of gas problem due to the operation consuming high gas used if transferring multiple groups of small tokens [dust](https://www.investopedia.com/terms/b/bitcoin-dust.asp) transaction.
-- [SC09:Gas Limit Vulnerabilities](https://owasp.org/www-project-smart-contract-top-10/2023/en/src/SC09-gas-limit-vulnerabilities.html) Exceeds block gas limit if the blockchain have block gas limit lower than the gas used of the transaction.
-- [SWC116:Block values as a proxy for time](https://swcregistry.io/docs/SWC-116/) and [avoid using `block.number` as a timestamp](https://consensys.github.io/smart-contract-best-practices/development-recommendations/solidity-specific/timestamp-dependence/#avoid-using-blocknumber-as-a-timestamp) Emphasize that network block times can fluctuate. In networks with variable block times, contracts relying on block values for time-based operations may not behave as expected. This can lead to inaccurate calculations or unintended outcomes.
-- [Solidity Division Rounding Down](https://docs.soliditylang.org/en/latest/types.html#division) This contract may encounter scenarios where the calculated expiration block is shorter than the actual expiration block. This discrepancy can arise from the outputs of `blockPerYear` and `blockPerSlot * slotPerEra`, which may differ. Additionally, Solidity's division operation only returns integers, rounding down to the nearest whole number. However, by enforcing valid block times within the defined limits of `MINIMUM_BLOCK_TIME_IN_MILLISECONDS` and `MAXIMUM_BLOCK_TIME_IN_MILLISECONDS`, the contract mitigates this risk effectively.
+- SC06:Denial Of Service Run out of gas problem due to the operation consuming high gas used if transferring multiple groups of small tokens dust transaction.
+- SC09:Gas Limit Vulnerabilities, Exceeds block gas limit if the blockchain have block gas limit lower than the gas used of the transaction.
+- SWC116:Block values as a proxy for time and avoid using `block.number` as a timestamp, Emphasize that network block times can fluctuate. In networks with variable block times, contracts relying on block values for time-based operations may not behave as expected. This can lead to inaccurate calculations or unintended outcomes.
+- Solidity Division Rounding Down, This contract may encounter scenarios where the calculated expiration block is shorter than the actual expiration block. This discrepancy can arise from the outputs of `blockPerYear` and `blockPerSlot * slotPerEra`, which may differ. Additionally, Solidity's division operation only returns integers, rounding down to the nearest whole number. However, by enforcing valid block times within the defined limits of `MINIMUM_BLOCK_TIME_IN_MILLISECONDS` and `MAXIMUM_BLOCK_TIME_IN_MILLISECONDS`, the contract mitigates this risk effectively.
 
 ---
 
-#### Historical links related to this standard
-
-- [Idea: Expirable Non-Fungible Token](https://ethereum-magicians.org/t/idea-expirable-non-fungible-token/8275)
-- ethereum stack exchange question [#27379](https://ethereum.stackexchange.com/questions/27379/is-it-possible-to-create-an-expiring-ephemeral-erc-20-token)
-- ethereum stack exchange question [#63937](https://ethereum.stackexchange.com/questions/63937/erc20-token-with-expiration-date)
+## Copyright
 
+Copyright and related rights waived via [CC0](../LICENSE.md).