Add ERC: Deferred Token Transfer #465
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
✅ All reviewers have approved. |
|
The commit 8e22e04 (as a parent of 5614006) contains errors. |
abcoathup
reviewed
Jun 9, 2024
abcoathup
reviewed
Jun 9, 2024
13 tasks
SamWilsn
approved these changes
Jun 11, 2024
Comment on lines
+97
to
+107
| The design of the Deferred Token Transfer contract aims to provide a straightforward and secure method for handling time-locked token transfers. The following considerations were made during its development: | ||
|
|
||
| **Simplicity and Usability**: The contract interface is designed to be simple and intuitive, making it easy for users to create deposits and for beneficiaries to withdraw tokens once the conditions are met. | ||
|
|
||
| **Security**: The contract ensures secure token transfers, preventing common vulnerabilities associated with ERC-20 transfers. Additionally, the contract includes checks to prevent multiple withdrawals of the same deposit. | ||
|
|
||
| **Flexibility**: The contract supports various ERC-20 tokens, allowing users to create deposits with any standard ERC-20 token. This flexibility makes it suitable for a wide range of use cases. | ||
|
|
||
| **Event Logging**: Events are emitted for both deposit creation and token withdrawal. This provides transparency and allows easy tracking of contract activities, which is crucial for auditability and user confidence. | ||
|
|
||
| **Conditional Payments**: By implementing a time-lock mechanism, the contract ensures that tokens are only transferred after a specific timestamp. This feature is essential for use cases like vesting schedules, escrow arrangements, and timed rewards, where payments need to be delayed until certain conditions are met. |
There was a problem hiding this comment.
Your Rationale is pretty generic. These considerations kinda apply to all ERCs, and aren't specific to this one. Some examples you could explain here are why you chose a full uint256 for _unlockTime, or why you've chosen to overload transferFrom instead of introducing a new function name.
eip-review-bot
approved these changes
Jun 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: