From f237eb536a0253c20ecfcab377a96c3ac8d171e3 Mon Sep 17 00:00:00 2001 From: sirawt <31649128+MASDXI@users.noreply.github.com> Date: Tue, 7 Jan 2025 23:26:00 +0700 Subject: [PATCH] Update ERC-7818: Move to Review Merged by EIP-Bot. --- ERCS/erc-7818.md | 14 +++++++------- assets/erc-7818/README.md | 18 +++++++++--------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/ERCS/erc-7818.md b/ERCS/erc-7818.md index 33fcd6c228..52e3f51877 100644 --- a/ERCS/erc-7818.md +++ b/ERCS/erc-7818.md @@ -4,7 +4,7 @@ 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-erc20/21655 -status: Draft +status: Review type: Standards Track category: ERC created: 2024-11-13 @@ -28,7 +28,7 @@ This extension facilitates the development of [ERC-20](./eip-20.md) standard com ## 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. +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. ### Epoch Mechanism @@ -41,7 +41,7 @@ Tokens linked to an `epoch` remain valid as long as the `epoch` is active. Once ### Balance Look Back Over Epochs -To retrieve the usable balance, tokens are checked from the **current epoch** against a **past epoch** (which can be any **_n_** epochs back). The past epoch can be set to any value **n**, allowing flexibility in tracking and summing tokens that are still valid from previous epochs, up to **n** epochs back. +To retrieve the usable balance, tokens are checked from the **current epoch** against a **past epoch** (which can be any **_n_** epochs back). The past epoch can be set to any value **_n_**, allowing flexibility in tracking and summing tokens that are still valid from previous epochs, up to **_n_** epochs back. The usable balance is the sum of tokens valid between the **current epoch** and the **past epoch**, ensuring that only non-expired tokens are considered. @@ -59,7 +59,7 @@ The usable balance is the sum of tokens valid between the **current epoch** and Tokens from **Epoch 2** and **Epoch 3** are valid. The same logic applies for any **_n_** epochs back, where the usable balance includes tokens from the current epoch and all prior valid epochs. -Compatible implementations MUST inherit from [ERC-20](./eip-20.md)'s interface and **MUST** have all the following functions and all function behavior **MUST** meet the specification. +Compatible implementations **MUST** inherit from [ERC-20](./eip-20.md)'s interface and **MUST** have all the following functions and all function behavior **MUST** meet the specification. ```solidity // SPDX-License-Identifier: CC0-1.0 @@ -103,7 +103,7 @@ interface IERC7818 is IERC20 { /** * @dev Retrieves the duration of a single epoch. * @return uint256 The duration of a single epoch. - * @notice The unit of the epoch length is determined by the `validityPeriodType()` function. + * @notice The unit of the epoch length is determined by the `validityPeriodType` function. */ function epochLength() external view returns (uint256); @@ -169,7 +169,7 @@ For example, if `epoch` 5 has expired, calling `balanceOfByEpoch(5, address)` re - `epochType` **MUST** return the type of epoch used by the contract, which can be either `BLOCKS_BASED` or `TIME_BASED`. - `validityDuration` **MUST** return the validity duration of tokens in terms of `epoch` counts. - `isEpochExpired` **MUST** return true if the given `epoch` is expired, otherwise `false`. -- `transfer` and `transferFrom` **MUST** exclusively transfer tokens that remain non-expired at the time of the transaction. Attempting to transfer expired tokens **MUST** revert the transaction or return false. Additionally, implementations **MAY** include logic to prioritize the automatic transfer of tokens closest to expiration, ensuring that the earliest expiring tokens are used first, provided they meet the non-expired condition. +- `transfer` and `transferFrom` **MUST** exclusively transfer tokens that remain non-expired at the time of the transaction. Attempting to transfer expired tokens **MUST** revert the transaction or return `false`. Additionally, implementations **MAY** include logic to prioritize the automatic transfer of tokens closest to expiration, ensuring that the earliest expiring tokens are used first, provided they meet the non-expired condition. - `transferAtEpoch` and `transferFromAtEpoch` **MUST** transfer the specified number of tokens held by an account at the specified epoch to the recipient, If the epoch has expired, the transaction **MUST** `revert` or return `false` - `totalSupply` **SHOULD** be set to `0` or `type(uint256).max` due to the challenges of tracking only valid (non-expired) tokens. - The implementation **MAY** use a standardized custom error, such as `ERC7818TransferredExpiredToken` or `ERC7818TransferredExpiredToken(address sender, uint256 epoch)`, to clearly indicate that the operation failed due to attempting to transfer expired tokens. @@ -204,7 +204,7 @@ Run out of gas problem due to the operation consuming higher gas if transferring Exceeds block gas limit if the blockchain has a block gas limit lower than the gas used in the transaction. ### Block values as a proxy for time -if using `block.timestamp` for calculating `epoch()` and In rare network halts, block production stops, freezing `block.timestamp` and disrupting time-based logic. This risks asset integrity and inconsistent states. +if using `block.timestamp` for calculating `epoch` and In rare network halts, block production stops, freezing `block.timestamp` and disrupting time-based logic. This risks asset integrity and inconsistent states. ### Fairness Concerns In a straightforward implementation, where all tokens within the same epoch share the same expiration (e.g., at `epoch`:`x`), bulk expiration occurs. diff --git a/assets/erc-7818/README.md b/assets/erc-7818/README.md index 58504f15cd..af646306a9 100644 --- a/assets/erc-7818/README.md +++ b/assets/erc-7818/README.md @@ -49,15 +49,15 @@ A **sorted** list is integral to this approach. Each `epoch` maintains its own l Assuming each year contains 4 `epoch`, which aligns with familiar time-based divisions like a year being divided into four quarters, the following table presents various scenarios based on block time and token receipt intervals. It illustrates the potential transaction frequency and likelihood of receiving tokens within a given period. -| Block Time (ms) | Receive Token Every (ms) | Index/Epoch | Transactions per Day | Likelihood | -| --------------- | ------------------------ | ----------- | -------------------- | ------------- | -| 100 | 100 | 78,892,315 | 864,000 | Very Unlikely | -| 500 | 500 | 15,778,463 | 172,800 | Very Unlikely | -| 1000 | 1000 | 7,889,231 | 86,400 | Very Unlikely | -| 1000 | 28,800,000 | 273 | 3 | Unlikely | -| 1000 | 86,400,000 | 91 | 1 | Possible | -| 5000 | 86,400,000 | 18 | 1 | Very Likely | -| 10000 | 86,400,000 | 9 | 1 | Very Likely | +| Block Time (ms) | Receive Token Every (ms) | Index/Epoch | Frequency | Likelihood | +| --------------- | ------------------------ | ----------- | ------------------- | ------------- | +| 100 | 100 | 78,892,315 | 864,000 _times/day_ | Very Unlikely | +| 500 | 500 | 15,778,463 | 172,800 _times/day_ | Very Unlikely | +| 1000 | 1000 | 7,889,231 | 86,400 _times/day_ | Very Unlikely | +| 1000 | 28,800,000 | 273 | 3 _times/day_ | Unlikely | +| 1000 | 86,400,000 | 91 | 1 _times/day_ | Possible | +| 5000 | 86,400,000 | 18 | 1 _times/month_ | Very Likely | +| 10000 | 86,400,000 | 9 | 3 _times/month_ | Very Likely | > [!IMPORTANT] > - Transactions per day are assumed based on loyalty point earnings.