This is looking good! If I understand correctly, this design requires almost no changes on our current Account contract implementation aside from using Ethereum’s ecdsa, right?
Since this is definitely a hard UX problem for many parties: users, wallet developers, and frontend/dapp developers; I’d like to address a few UX issues we might face:
Account addresses
This solution definitely works. But a big problem for users is going to be the split between “their address” (what they see in metamask, the EOA) and their account contract address. This could open the door for user mistakes such as sending/receiving tokens to EOA addresses instead of account addresses).
Another common error is to send tokens to the right address on the wrong network (e.g. send to polygon instead of eth mainnet). With the EOA/account contract address split, funds sent to the right user on the wrong network could result in loss of funds.
It would also be very confusing for users to understand the difference between these addresses (which they will definitely encounter in different places such as web dapps, Metamask, tx metadata, etc) and this confusion could be also exploited by attackers. This is also highlighted on the getBalance/send ERC20 section of the OP.
To minimize risk, reduce cognitive overhead for users, and simplify overall adapters, I’d like to suggest adding a special CREATE opcode to deploy accounts to an EOA-derived address. Without taking into account contract code, salts, etc. Only proving EOA ownership once. This way, if you own an ethereum private key that controls a given EOA, you can deploy an account contract to the same address. This should be feasible since ethereum addresses are 20bytes long, smaller thus representable in Starknet’s >31bytes.
Metadata display
There’s also the issue of how tx metadata is shown to the user, since every tx is in a way a meta-transaction (all txs are redundantly calling execute on the same account contract, always). Solving this issue will probably require wallet-side development.
Nonces
I think we should leverage wallet-side nonce management. The RPC endpoint could expose a method for getting the nonce of a given account, then use that to build the transaction. Did you have anything in mind regarding this?
Account creation
When should account be created? Who’s going to pay for it? Maybe this is something the dapps could cover, but it still bears the UX issue of requiring users to sign an account creation transaction, which will not always be obvious/easy to explain. I think we should think about this flow too.