How to use Abstract Accounts from server-side (API)

[mmiro-balize]

Hello! I'm building a tokenization platform that is mostly centralized except for the wallet custody (AlchemySigner using Turnkey and Passkeys).

I would love some insights/guidance on the implementation of Alchemy's Abstract Account given the "centralized approach":

1. Is it possible to batch Passkey authentication requests? When using AlchemySigner from @alchemy/aa-alchemy, if the user's session has expired I must re-authenticate the user's session to perform the desired action (e.g. sign a transaction). This means that users must input their Passkey twice. Is there a workaround? Here's an example gist that shows this bad-UX approach.

2. How can I create a modular account for a signer and verify the user's signer credentials from the server? My idea is that the client should:

   • Create the signer wallet with the user's Passkey.
   • Create a modular account with the signer's credentials.
   • Hash a unique text (e.g. user's ID) to verify the signer wallet's ownership from the server.
   • Send the signer address, modular account address, and hashed message to the server/API to update the user's wallet info.

   This flow also relates to problem 1, as a user will need to input their Passkey 3 times to complete it.

3. Once a user's signer and modular account wallets are created, is it possible to sign a transaction client-side, send the signed user operation to the server and execute the transaction/userOp from the server? If not, how can I track new transactions relative to my app (that involves many smart contracts) and update the database to show these transactions?

Any help is appreciated

[moldy530]

1. We don't yet support creating passkey sessions, but is something the Turnkey team has shipped support for. We are looking to add that because agreed, it requires a lot of passkey prompts. The best way to get sessions without prompts right now is to use email based auth.
2. You can definitely do this. You have 2 options basically. The first is readily available and you can use SIWE to achieve sending an authenticated / signed request to your backend so that you know who the user is. This does require signatures so again you'd have to use email auth until we add the passkey session support to the SDK.
3. Yup also possible. We have a couple methods in the SDK to support this. The SmartAccountClient has a buildUserOperation method and a signUserOperation method. This would allow you to generate a signed user operation on the client and then send it to the server. From the server you would use BundlerClient and call bundlerClient.sendRawUserOperation to send already signed user ops if you want to track this that way. Another way to track transactions is to use sendTransaction on the client which will send a uo and then wait for the tx to be mined and finally returns to you a tx hash. You can then send that tx hash to your server, if you need the UO body as well, then you would use sendUserOperation + waitForUserOperationTransaction. The first method returns the UO body that was sent and the second methods returns to you a tx hash once mined

[moldy530]

oh I said 2 options and left out the second on 2 above. The second option requires us to expose a stampWhoAmiRequest method on the signer itself. This would get a user stamped request from the client which you can pass to your server. You would then call our /v1/signer/whoami endpoint to get the user details and avoid having to do a SIWE flow