@spengrah love the direction! Do you have some simple example in mind on how you’d use such an extraData param to facilitate advanced router logic? For more context →
Opt-in / opt-out upgrades is something I’ve thought a lot about while constructing the EIP.
I write smart contracts at thirdweb, and we built our smart wallet factory contracts using the EIP’s pattern, in parallel to writing an EIP.
You can read here about the DynamicAccountFactory and ManagedAccountFactory contracts. Both factory contracts deploy upgradeable account contracts, however we wrote the Dynamic smart wallets to have opt-in upgrades system and Managed smart wallets to have a forceful upgrades – all without any additional params.
Here’s a high-level comparison diagram:
A Dynamic smart wallet is a router and EIP-7504 compliant, and its parent factory contract is just a regular contract. And so, all upgrades to a smart wallet are controlled locally, by the smart wallet’s admin. This allows building an ‘opt-in’ upgrades system for smart wallets, where the wallet-factory admin can propose upgrades, and wallets can choose to accept.
A Managed smart wallet is a router and EIP-7504 compliant, and its parent factory contract is also a router and EIP compliant. Here, all child smart wallets use their parent factory contract’s RouterState, and thus an upgrade to the router map in the wallet-factory is applied “instantly” to all its child smart wallets (effectively, a push upgrade).