New account abstraction docs, moving from extends?

[tuler]

I was reading the new account abstraction docs and I noticed that instead of using a single client instance with an extends extension, the docs suggest to have a client and a separate explicit bundlerClient from that client.

Does this means viem will move away from the extensions mechanism?

[jxom]

Viem is not moving away from Extensions, the reason why they are two separate Clients is because they interact with different backends. The client instance interacts with an Execution Node (coupled with an Execution Node transport), whereas the bundlerClient interacts with a Bundler Node (coupled with a Bundler Node transport).

Clients in Viem are intended to be a one-to-one interface to a backend (Execution Node, Wallet, Bundler Node, some server, etc). Extending Actions on a Client only makes sense if those Actions interact with the same backend.

The good thing is that once Account Abstraction is enshrined in the protocol, this will likely make the Bundler Client redundant as AA transactions will simply be another transaction type on the Execution layer!

[tuler]

I understand, thanks for the clarification. I was designing an extension but now I understand.

So, this new API "replaces" permissionless, right? Is it the same codebase, or a new one? How will the migration look like for projects that used permissionless, like for example the ZeroDev SDK. What about the path for integration of additional smart wallet factories?

Sorry for so many questions, let me know if there is any blog post or issue about these changes around AA.

[jxom]

The APIs for Account Abstraction in Viem intend to be low-level primitives/building blocks and don't delve into much higher-level abstractions. So there is still a purpose for permissionless.js to cover those higher-level abstractions and use-cases as they currently do already (ie. supercharged Viem AA).

For example:

• We have purposely chosen not to implement several Smart Account Implementations (ie. Kernel, Safe, Alchemy, Trust, etc), as we would imagine permissionless.js (or alternative libraries) would be able to maintain these, as this would be too much of a maintenance burden on Viem.
• Viem does not intertwine User Operations into our core Transaction APIs (ie. sendTransaction), as ERC-4337 is not enshrined into the protocol (User Operations are fundamentally different to Transactions). Instead, we would expect permissionless.js (or alternative libraries) to abstract this if they want.
• Viem's AA extension probably won't focus too much on experimental/bleeding edge AA ERCs (e.g. ERC-7579), and also leave that up to permissionless.js (or alternative libraries).

Permissionless.js have also hinted on v0.2 built on Viem AA