Skip to content

Update ERC-5725: Remove duplicate word and fix some typos #1103

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SamWilsn merged 1 commit into from
Jul 15, 2025
Merged

Update ERC-5725: Remove duplicate word and fix some typos #1103

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions ERCS/erc-5725.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -210,7 +210,7 @@

**`vestingPayout` + `vestedPayout`**

`vestingPayout(uint256 tokenId)` and `vestedPayout(uint256 tokenId)` add up to the total number of tokens which can be claimed by the end of of the vesting schedule. This is also equal to `vestedPayoutAtTime(uint256 tokenId, uint256 timestamp)` with `type(uint256).max` as the `timestamp`.
`vestingPayout(uint256 tokenId)` and `vestedPayout(uint256 tokenId)` add up to the total number of tokens which can be claimed by the end of the vesting schedule. This is also equal to `vestedPayoutAtTime(uint256 tokenId, uint256 timestamp)` with `type(uint256).max` as the `timestamp`.

The rationale for this is to guarantee that the tokens `vested` and tokens `vesting` are always in sync. The intent is that the vesting curves created are deterministic across the `vestingPeriod`. This creates useful opportunities for integration with these NFTs. For example: A vesting schedule can be iterated through and a vesting curve could be visualized, either on-chain or off-chain.

Expand All @@ -234,9 +234,9 @@

### Timestamps

Generally in Solidity development it is advised against using `block.timestamp` as a state dependant variable as the timestamp of a block can be manipulated by a miner. The choice to use a `timestamp` over a `block` is to allow the interface to work across multiple **Ethereum Virtual Machine** (EVM) compatible networks which generally have different block times. Block proposal with a significantly fabricated timestamp will generally be dropped by all node implementations which makes the window for abuse negligible.
Generally in Solidity development it is advised against using `block.timestamp` as a state dependent variable as the timestamp of a block can be manipulated by a miner. The choice to use a `timestamp` over a `block` is to allow the interface to work across multiple **Ethereum Virtual Machine** (EVM) compatible networks which generally have different block times. Block proposal with a significantly fabricated timestamp will generally be dropped by all node implementations which makes the window for abuse negligible.

The `timestamp` makes cross chain integration easy, but internally, the reference implementation keeps track of the token payout per Vesting NFT to ensure that excess tokens alloted by the vesting terms cannot be claimed.
The `timestamp` makes cross chain integration easy, but internally, the reference implementation keeps track of the token payout per Vesting NFT to ensure that excess tokens allotted by the vesting terms cannot be claimed.

### Limitation of Scope

Expand All @@ -254,7 +254,7 @@
## Backwards Compatibility

- The Vesting NFT standard is meant to be fully backwards compatible with any current [ERC-721](./eip-721.md) integrations and marketplaces.
- The Vesting NFT standard also supports [ERC-165](./eip-165.md) interface detection for detecting `EIP-721` compatibility, as well as Vesting NFT compatibility.

Check failure on line 257 in ERCS/erc-5725.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

EIP references should not be in backticks 

error[markdown-no-backticks]: EIP references should not be in backticks
   --> ERCS/erc-5725.md
    |
257 | - The Vesting NFT standard also supports [ERC-165](./eip-165.md) interface detection for detecting `EIP-721` compatibility, as well...
    |
    = info: the pattern in question: `(?i)(eip|erc)-[0-9]+`
    = help: see https://ethereum.github.io/eipw/markdown-no-backticks/

## Test Cases

Expand All @@ -268,7 +268,7 @@

**timestamps**

- Vesting schedules are based on timestamps. As such, it's important to keep track of the number of tokens which have been claimed and to not give out more tokens than alloted for a specific Vesting NFT.
- Vesting schedules are based on timestamps. As such, it's important to keep track of the number of tokens which have been claimed and to not give out more tokens than allotted for a specific Vesting NFT.
- `vestedPayoutAtTime(tokenId, type(uint256).max)`, for example, must return the total payout for a given `tokenId`

**approvals**
Expand Down
Loading