Add Account framework #5657
Add Account framework #5657
Conversation
🦋 Changeset detectedLatest commit: 8fa6fd9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| + name: '', // Not initialized in the context of signer | ||
| + version: '', // Not initialized in the context of signer |
There was a problem hiding this comment.
As part of the upgradeable transpilation pipeline, we generate the upgradeable versions and the run tests against them. However, ERC-7702 accounts will delegate to an EIP-712 (through ERC7739) contract, so the domain separator will be rebuilt each time without the name or version set in the EOA's storage.
In practice, if users are delegating to an upgradeable contract, it should be a proxy pointing to an implementation that uses the EIP712Upgradeable version so that the domain can be initialized (and reinitialized) properly.
There was a problem hiding this comment.
In practice, if users are delegating to an upgradeable contract, it should be a proxy pointing to an implementation that uses the EIP712Upgradeable version so that the domain can be initialized (and reinitialized) properly.
I don't get that part. If an EOA delegates to a proxy, stuff will just not work. The proxy logic will be applied, and it will try to read from the EOA storage. That is true of the name and version ... but actually it is also true of the implementation address, which is likelly not set at all.
The proxy initialization of the implementation is on the proxy's storage, so its not visible from the EOA doing the delgation.
My understanding is that 7702 should never target proxies, and it should also NOT be used with EIP712Upgradeable
There was a problem hiding this comment.
I don't get that part. If an EOA delegates to a proxy, stuff will just not work.
You literally just described how not to use a proxy, but nothing to do with an EOA in particular. An ERC-4337 upgradeable account would be deployed by a proxy factory and set its own implementation address in storage as a proxy would do, and a delegated EOA can delegate to a proxy too. I understand it'd be more desirable to delegate with 7702 to a new implementation, but the implementations must be upgradeable variants (e.g. stateless or with initializers).
My understanding is that 7702 should never target proxies,
This is a strong statement. A 7702 account could decide to manage itself as a proxy if the developer wants to. Remember users aren't always supposed to pick their accounts, so I see valid reasons to use a proxy if you're a developer and you want a managed upgrading experience
... and it should also NOT be used with EIP712Upgradeable
There's an important difference here, either you want your 7702 account to use the implementation's domain separator or the account's own domain separator. I would argue it should be the account's own domain and therefore they should delegate to an EIP712Upgradeable contract. (Both are fine btw)
3 participants
Moves the community contracts account abstraction framework to this repository.
Check #5664 before
PR Checklist
npx changeset add)