Ethereum Account Abstraction

AA fam, how are we thinking about the intersection of modules and keystore rollup?

Namely, I assume if a user wants a module on one chain they probably want on all. What’s the best approach?

If modules are deployed to the same addresses across chains, L2 accounts could query the L1 account for approved modules so that they don’t need to be approved on every chain. 

Inspo from https://hackmd.io/@i275DA5ZRjOAeSFUkffw5Q/H1rQQwY9n

@rhinestone team, figure you may have thoughts?

The future of account abstraction is modular

leading Builder Success @base | onchain since '17 | anything for the builders

Yeah but part of the goal of the keystore rollup is giving users a single source of truth signer even when addresses differ. 

I’m not sure modules at the same address should be designed around

Devised a system using an Account Circuit that can process solidity libraries and then use a create2 factory to deploy modules.

Devised a system using an Account Circuit that can process solidity libraries and then use a create2 factory to deploy modules. 

https://hackmd.io/@ilikesymmetry/solidity-account-circuits

imo it would make sense to have a core config that is synced across chains and where modules are tied to some identifies (eg address, ens, ...) and then a way to override this config on different chains. what is tricky is that modules themselves have configs so this also needs to be synced

Maybe all module on all chain - what's da perfect move?