An idea I have been toying with given all the recent discussion is modifying how AUTHCALL works. Today, AUTHCALL simply changes msg.sender to the authorized address. This is different from how smart contract wallets operate today and it is seems like a model which is hard for people to wrap their heads around.
Instead I am wondering if we could modify AUTHCALL to behave a bit more like 5806. Add a new parameter target which is the target code that will execute within the context of the EOA. That target would basically be a smart contract wallet implementation. Let’s say the signature is now 0x04 ++ invokerAddr ++ targetAddr ++ commit. AUTH verifies the EOA did authorize their account to execute target in it’s context with some data commit. AUTHCALL then kicks off that frame of execution.
Now this flow more closely matches how smart contract wallets work. The initial validation phase is more rooted in EVM ops, but I think that is neccessary to process the authorization safely. The neat thing here is that the invoker is now way less important. It doesn’t do anything on your behalf. I’m not even sure if it needs to be signed over. The real key is the target. This is the code you are authorizing to execute within your account, just like a smart contract. That target could even implment well understood plugin systems like 6900. So it feels like it retains most of the power of 3074 without giving quite as much power to wallet whitelists. The target would still have to be something whitelisted by the wallet (or the messaging will be a bit different like “WARNING: YOU ARE CHANGING THE IMPLEMENTATION OF YOUR SMART CONTRACT WALLET ARE YOU SURE YOU WANT TO DO THAT”). I think this is more teneable than asking users to understand 3074 invokers.