Hola Magicians, I want to share my thoughts and get feedback from devs who have been working lately on 7702 delegators.
We know that after the Pectra upgrade it’s possible to attach code to an EOA, so we can have smart contract like behavior in the context of an EOA.
During development of a delegator with my team, we realized that since we’re working with ephemeral EOAs, after delegation and initialization of the account the ephemeral key is removed from the system and it’s not possible to use the esdca key in the future.
Here comes the question: how can the user invoke a new implementation for their EOA? The solution is proxy contracts. The user attaches a proxy contract acting as a delegator pointing to an implementation. This means in the future if the user wants to upgrade the current implementation, they can use the upgrade function to invoke a new implementation. Of course, we follow best practices and avoid the risks of the proxy pattern.
Another question arises: how can we be 100% sure that another implementation will have the same pattern and behavior in the proxy contract, with the same logic for updating the implementation? For my core team, we can be trusted and ensure we continuously implement the same pattern in upgraded implementations. But what about other teams or projects? How can we ensure that a user who started with our contract and then upgrades to an implementation not produced by us will still have the upgrade function? Otherwise, the user could end up stuck with the upgraded implementation, since we can’t be sure the next implementation includes an upgrade function.
My thought: we could provide an ERC standard so that all delegator contracts include a function like upgrade7702proxy
. This would allow an ephemeral EOA to upgrade its implementation at any moment.
Please share your thoughts about this case.
Im starting to plan this ERC draft. How it will be a solution for ephemeral EOAS
Best wishes!