[General] Account abstraction contract deployment step embedding and fees compensations

[otorbiievskyi]

Team or Project

N/A

ZK chain

Era

Environment

Testnet

L2 block number

N/A

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

The case

Is there a way to somehow batch a smart account deployment step with an action done on its behalf (transfer call, or smart contract call, etc.)? The flow I'm interested in is very similar to how smart account deployment works in the regular EVM world, i.e.:

1. The user has no smart account deployed
2. He gets the precomputed smart account address (using his webauthn credentials, for example)
3. Deposits funds into it
4. Initiates a transfer (and inside of a single transaction, that's fully paid by the user, both the deployment and transfer are executed)

In the regular EVM networks, it's done via Bundler/EntryPoint and a user operation's initCode field that contains all the parameters that are needed for the account deployment itself through a factory (of course, we are not talking about ERC7702, which requires EOA anyway).

Why is it even needed?

This flow is fairly useful when the user has only a specific kind of credentials (P256 keys, as described above) and has no EOA private key at all. And in the case described above, the user pays fees for deployment, and no EOA is used (except the one that's present on the bundler side to call the EntryPoint).

The question

The current implementation in zkSync (as far as I get it from docs and my research) pushes me to store an EOA private key that will eventually call a smart account factory and create an account for a user (therefore, the stored EOA pays fees for the deployment and doesn't get them back).
Is the aforementioned even possible to do using existing AA implementation and infrastructure, or is it needed to invent some kind of an EntryPoint clone that will do everything at once (deployment, action, and fees compensation)

Repo Link (Optional)

No response

Additional Details

No response

[bxpana]

Good question and asking internally for you

[cpb8010]

It sounds like you're trying to perform a counter-factual deployment. Using a factory to manage the account deployment can serve the same purpose as the 4337 bundler entry point, allowing you to batch all the account setup steps into a single transaction. If you don't want to use a factory and paymaster to manage the initial account deployment, you can move the funds from the deployment account to the deployed smart contract after the deployment is complete.

If you are working with AA, I'd suggest to take at look at the ZKSync-SSO smart account deployment if you haven't already so you don't have to manage or re-invent this yourself. If this doesn't meet your needs I'd love to know why! It already supports deploying a smart account for free with a paymaster that supports webauthn keys!

[otorbiievskyi]

I generally understand the concept, but there are a couple of points I would like to emphasize regarding the SSO implementation that you've mentioned. Correct me if I'm wrong.

• Deployment (+ setup) of an account and action are separate things, and they are done via two separate transactions, in contrast to how it works through EntryPoint, where deployment and (for example) transfer can be done in a single shot;
• As far as I see, in the SSO implementation, the deployment is done via a "throw-away" address and paid via the paymaster, therefore, the deployment is free for a user.

What I'm trying to achieve:

• Deployment, setup, and action (again, it can be a transfer, or a swap, or something else) should be done in a context of a single transaction;
• The deployment itself should be paid by a user, from the pre-funded pre-computed user address, which we got from the address pre-computation ("counter-factual deployment").

And, as I see, for now, there is no way to do the described above using the existing tools and contracts. So I'll need to make some kind of sophisticated factory that will deploy an account for a user, set it up, withdraw fees, and execute an action, similarly to how the canonical EntryPoint does it.

The end goal for this is to remove all the friction from the user and put all the "fee" load fully on their regard.

[cpb8010]

Yes! The goal with SSO is to remove all the friction from the user so the account setup and deployment is done in a single transaction that doesn't require funding! If you want to provide funding before account deployment you can compute the deployment address via create2 from the unique account id ( and holding the deployer address constant)

Is there a benefit for having the user pay for their own account deployment? We've found this significantly complicates user sign up flows, which is why we provide a paymaster so all SSO accounts are free to deploy!