Add ERC: An Interface for Transfer From Native #987
Conversation
|
It would be really useful to add a |
Co-authored-by: Eric Zhong <[email protected]>
Co-authored-by: Eric Zhong <[email protected]>
updates from comments
eip-review-bot
changed the title
|
The commit b131bb9 (as a parent of 7e95f98) contains errors. |
| @@ -0,0 +1,160 @@ | |||
| --- | |||
| eip: 7914 | |||
| title: An Interface for Transfer From Native | |||
There was a problem hiding this comment.
An Interface for
This bit doesn't really add much to your title. Because space is so limited (~44 characters), I'd recommend removing it and trying to make your title more information dense.
For example:
| title: An Interface for Transfer From Native | |
| title: Approved Spenders for Native Ether |
| --- | ||
| eip: 7914 | ||
| title: An Interface for Transfer From Native | ||
| description: This proposal introduces a method for approved spenders to execute native token transfers on behalf of users. |
There was a problem hiding this comment.
Similarly, here in your description, there's a lot of text that doesn't actually add any information. You could trim this down like so:
| description: This proposal introduces a method for approved spenders to execute native token transfers on behalf of users. | |
| description: Approved spenders for native token transfers from EIP-7702 EOAs and ERC-4337 smart accounts on behalf of users. |
|
|
||
| ## Abstract | ||
|
|
||
| This proposal introduces a method for native transfers that can originate from an approved spender on a smart contract wallet or a [ERC-7702](./eip-7702.md) delegated EOA account. For wallets that can execute code, other contracts can be authorized to pull native tokens via a new callback mechanism. |
There was a problem hiding this comment.
Your abstract does a good job of sketching out the goals of the proposal, but is lacking a high-level but still technical overview of how the proposal accomplishes those goals. Essentially, your abstract should additionally answer the question: what is the method?
|
|
||
| ## Motivation | ||
|
|
||
| Because Native transfers must be initiated by the calling account, spenders cannot pull Native tokens without executing code on a user's wallet. This presents a problem in intent-based systems, where transactions are expected to be sent on behalf of users rather than initiated by the users themselves. |
There was a problem hiding this comment.
Why are you capitalizing native?
| function transferFromNative(address from, address recipient, uint256 amount) public returns (bool); | ||
| ``` | ||
|
|
||
| - `from` : The account that the ETH transfer should originate from. If this function is implemented on the spender’s contract account, then it should check `from` is set to `address(this)`. If `from` is not `address(this)` the contract COULD forward the call. Note that specifically parameterizing a `from` address allows for flexibility, and other types of integrations with this standard. |
There was a problem hiding this comment.
Note that specifically parameterizing a
fromaddress allows for flexibility, and other types of integrations with this standard.
This type of content belongs in the Rationale section.
|
|
||
| ### Persistent Approval | ||
|
|
||
| An approval system similar to the [ERC-20](./eip-20.md) `approve` mechanism MUST be implemented to allow users to specify trusted accounts that can perform Native transfers on their behalf. |
There was a problem hiding this comment.
An approval system similar [...]
In this line, "similar" here is too vague. You should either exactly copy the approval from ERC-20 or define the system in this document.
| function transientNativeAllowance(address spender) public view returns (uint256) | ||
| ``` | ||
|
|
||
| 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. |
There was a problem hiding this comment.
This should be moved to the top of the Specification section.
| - Enables seamless ETH transfers without requiring users to submit raw transactions themselves. | ||
| - Leverages the capabilities introduced by ERC-7702, which allows EOAs to execute code. | ||
| - Adopts a standardized approval mechanism similar to ERC-20 for developer experience. | ||
| - Outlines both persistent and transient approval mechanisms to minimize hanging approvals for tighter security on the account. |
There was a problem hiding this comment.
All of this belongs in the Motivation section because it's justifying the proposal as a whole. The Rationale section should be used to explain choices made within your document. My pet analogy for the two sections are:
Motivation: We need to build a shed because...
Rationale: We decided to paint our shed red because...
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: