Add ERC: Minimal intent-centric EOA smart account #696
Conversation
hellohanchen
changed the title
eip-review-bot
changed the title
eip-review-bot
changed the title
|
Hi team, could you please help review this PR again? I've updated with more examples and re-worked the whole thing a little bit. |
ERCS/erc-7806.md
Outdated
| --- | ||
| eip: 7806 | ||
| title: Minimal intent-centric EOA smart account | ||
| description: Minimal effort intent-centric interfaces for EOA account abstraction |
There was a problem hiding this comment.
Minimal effort
This doesn't really add a lot of information to the description. It's better to include specific/differentiating features than generally saying "minimal".
ERCS/erc-7806.md
Outdated
| * **BatchExecution** | ||
| * **GasSponsorship** | ||
| * **AccessControl** |
There was a problem hiding this comment.
Why are these joined into single words? If they are code (and I don't believe they are), you should put them in backticks (`). Otherwise, put a space between the words.
ERCS/erc-7806.md
Outdated
| trying to keep the whole solution forward-compatible. | ||
|
|
||
| With `SET_CODE_TX_TYPE=0x04` allowing EOA accounts to set contract code, EOA accounts will gain similar programmability | ||
| as SCA (Smart Contact Account). A new standard, that provides EOA with highly-demanded AA features while potentially |
There was a problem hiding this comment.
You should move this expansion "SCA (Smart Contract Account)" to the first time the abbreviation is used (line 42-ish).
ERCS/erc-7806.md
Outdated
| 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. | ||
|
|
||
| ### UserIntent bytes |
There was a problem hiding this comment.
If "UserIntent" is the name of a Solidity type:
| ### UserIntent bytes | |
| ### `UserIntent` bytes |
ERCS/erc-7806.md
Outdated
| > The main challenge with a generalized intent standard is being able to adapt to the evolving world of intents. Users | ||
| > need to have a way to express their intents in a seamless way without having to make constant updates to their smart | ||
| > contract wallets. --- ERC-7521 | ||
|
|
||
| The interface designs proposed in this EIP is inspired by ERC-7521, and the author tries to avoid turning EIP into a | ||
| real implementation. |
There was a problem hiding this comment.
You don't need to quote 7521 here. Just write your rationale describing the decisions made within this document. If you're going to point to another EIP in this section, that is a hint that you're not actually writing content appropriate for the Rational section. My favourite analogy is:
Motivation: We need to build a shed because...
Rationale: We painted the shed red because...
ERCS/erc-7806.md
Outdated
| ### Auditability of both validation and execution | ||
|
|
||
| It is very important both the standard and account implementation can be publicly audited and shared. The most important | ||
| reason is security. And this can also help mediate the compatibility issues between standard and account. |
There was a problem hiding this comment.
This is more content for the security considerations section.
ERCS/erc-7806.md
Outdated
| Within a intent-centric system, solvers are helping account owners to fulfill the intent and solvers are rewarded. This | ||
| proposal allows any solver to execute the intent, bringing a positive competitive environment. And supported by gas | ||
| abstraction, solvers will pay the native token as gas fee and take other tokens back from the EOA account. Besides, | ||
| solvers can further reduce the cost of their side by bundling multiple intent executions into one blockchain | ||
| transaction. |
There was a problem hiding this comment.
You're mixing motivation and rationale here again. For example:
This proposal allows any solver to execute the intent, bringing a positive competitive environment.
This is an argument for using this proposal over other proposals. That belongs in the Motivation section.
There was a problem hiding this comment.
Moved this section to Motivation 🙏
ERCS/erc-7806.md
Outdated
| And another fact, which is easy to be ignored, is that intent has value by itself. For example, if an EOA is always | ||
| willing to swap 1000 USDC to 1000 USDT and vice versa, this EOA will be considered as a "liquidity provider" in the | ||
| market. The account can send the signed intent to exchanges and make the exchange reward the account every time the | ||
| intent is executed. |
There was a problem hiding this comment.
This is again more relevant to Motivation. You aren't explaining any choices made within this document, so it doesn't belong in Rationale.
There was a problem hiding this comment.
Updated to be No re-entry protection enforced
ERCS/erc-7806.md
Outdated
| This is mainly controlled by the standard and account implementation to make sure the account is safe. Solver needs to | ||
| responsible for its own security when executing intents. | ||
|
|
||
| More discussion needed. |
There was a problem hiding this comment.
| More discussion needed. | |
| More discussion needed. <!-- TODO --> |
Co-authored-by: Sam Wilson <[email protected]>
…into erc-intent-7702
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: