Thread by @kristofgazso

We are witnessing the rise of non-financial applications on Ethereum.

But there is a problem: if we stay with our current account model, these apps will be unusable.

Account Abstraction solves this!

Here's how:

(🧵)

1/ Some background:

Many non-financial Dapps like Dark Forest require the user to quickly take many actions on-chain.

There are currently two ways these Dapps can get around this problem.

One way is to keep relying on your already existing wallet.

2/ This is safe because you retain complete control over your funds and how you transact.

However, this can also slow down your experience, as you will have to manually approve each transaction.

3/ The worst part is the more OpSec you have (e.g. using a hardware wallet), the more friction you will suffer for each transaction.

This can very quickly make the Dapp unusable.

4/ So what most of these Dapps do is generate a burner account for you.

They generate a private key and store it in your browser or another 'secure' storage location.

5/ Anytime you want to transact with the Dapp, they automatically sign your transaction with the private key without you noticing.

This sounds great. A lot less friction!

However, it also comes with issues.

You're burner account is completely detached from your main account.

6/ This means that any balances you have on it are secured only by whatever security mechanism the Dapp uses, as opposed to leveraging the (hopefully) good OpSec you maintain with your Hardware wallet / Social recovery / Multisig scheme.

What if there was a better way?

7/ Luckily, Account Abstraction (AA) is here to save the day.

Imagine if you could get the security of your already existing wallet with the convenience of being able to spin up linked burner wallets with custom permissions.

8/ Here is a quick thread on Account Abstraction for the uninitiated:

https://twitter.com/kristofgazso/status/1576716946250543104

9/ With AA, you can define how your account works in any way you want, allowing for custom signature schemes, gas sponsorship, different account permissions (!!!), and more.

Let's focus on the different account permissions for now.

10/ Imagine that your account uses a multisig scheme (e.g. requiring 2 out of 3 signers to agree for a transaction to be valid).

However, you want to use Dapp XYZ, an on-chain game where all transactions go through their hub contract.

11/ With AA, you could have your account programmed so that the multisig can 'authorize' a burner private key to have limited control over your account.

So returning to our example, you generate a private key that will be used to interact with the Dapp.

12/ Then, you use your multisig to authorize the private key to be able to transact from your main account, but ONLY with Dapp XYZ's hub contract.

13/ You might also add more restrictions, like that this burner private key can only transact a maximum of 100 times a day (so that even if it's stolen, it can't waste all the native tokens from your account as gas fees)

14/ Now, you can give the Dapp this private key with these limited permissions and not have to worry about manually signing each transaction.

But also, anytime you receive any tokens or NFTs from the Dapp, they will belong to your main account!

15/ Therefore, no need to transfer between accounts, and any history or profiles you maintain with your main account will be reflected on the burner (such as @ensdomains names, and @LensProtocol profiles).

16/ You can also decide to modify or even withdraw the permissions this burner has while keeping all the history and/or tokens associated with the Dapp with your account, very extensible!

17/ And as an added benefit, with ERC-4337, it will be child's play to allow transactions made by this burner wallet to have their gas sponsored, leading to even better UX.

18/ I only mentioned burner accounts for simplicity, but with AA you can create any sub-account with any permissions for any purpose!

You could create other mechanisms.

19/ For example, imagine having admin permissions belonging to your multisig as before, but allowing a private key to spend at most $1000 of tokens per day for any purpose. This sub-account could be controlled with a Metamask-like extension.

20/ Now, you get Metamask's level of convenience for most daily use cases, while any larger transactions have to be approved by your super secure multisig. Win-win!

21/ So why isn't this widespread?

Standards for Account Abstraction like ERC-4337 are still relatively new, and we need more time and projects building on it for it to be more widespread. But there is already lots of momentum (looking at you @soulwallet_eth and @candidewallet)

22/ Also, there needs to be a standard interface for creating burner accounts and setting custom access permissions by Dapps for the Smart Contract wallets.

23/ Please reach out if you are interested in making ERC-4337 more popular or creating a standard for generating sub-accounts with me! You'd be helping solve the most existential UX problem Ethereum is facing!

The End!