The issue arises when a new account is created with an ephemeral key: there is no way to upgrade the account’s implementation except via the proxy pattern. In cases like Porto or Openfort, which work with ephemeral keys and delegate the owner role to a WebAuthn signer or another EOA (depending on the contract logic), there is no opportunity to attach a new implementation directly upgrades are only possible through a proxy.
The problem appears if the user wants the option to rotate implementations between whitelisted, trusted delegators (designators). I’m not addressing storage slots or admin key validation logic here, but consider this scenario for user starts with Porto (using WebAuthn as the admin key) and then upgrades to Uniswap. Two issues arise:
- The user becomes tied permanently to the Uniswap implementation, since it’s now managed by the proxy pattern.
- Initialization of the new implementation may not activate the current admin key as expected.
I see two main issues when using ephemeral keys:
- The user might upgrade the account and become stuck forever with an implementation that lacks an upgrade function or proxy support.
- The user could lose access to their assets if the new implementation uses different admin-key access or validation logic.
For these reasons, I believe we need a standard for this case so users can reliably rotate or upgrade their accounts without falling through the cracks or losing access to their assets