Skip to content

Commit

Permalink
Update ERC-7818: Move to Review
Browse files Browse the repository at this point in the history
Merged by EIP-Bot.
  • Loading branch information
MASDXI authored Jan 7, 2025
1 parent 226f234 commit f237eb5
Show file tree
Hide file tree
Showing 2 changed files with 16 additions and 16 deletions.
14 changes: 7 additions & 7 deletions ERCS/erc-7818.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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

Expand All @@ -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.

Expand All @@ -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
Expand Down Expand Up @@ -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);
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down
18 changes: 9 additions & 9 deletions assets/erc-7818/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down

0 comments on commit f237eb5

Please sign in to comment.