Access wallets from your backend

Privy enables you to configure delegated access to a user's wallet from a third-party service, for instance your app backend. This means that with the permission of a user's account abstraction (AA) wallet, you can build features such as:

• Sending transactions on behalf of the user
• Triggering transactions based on automated criteria
• Scheduling transactions when the user is not active
• Setting recurring transactions

Privy embedded wallets are self-custodial, which means only the user has access to their wallet. Using the Privy embedded wallet as a signer on an onchain account using account abstraction, you can enable permissioned access to the user's account by a third-party. This keeps the user in control but gives you greater flexibility to act on their behalf.

This involves setting up a session key that your service controls, which has permissioned access to the user's AA account.

Check out the example integration, which we break down in the following guide. In this example, our users each have a Privy embedded wallet which is the signer (master key) of their account abstraction wallet. We want to create a server-side API from which we can trigger and automate transactions for our users.

Example integration using ZeroDev

In this guide, we will leverage the account abstraction provider ZeroDev.

ZeroDev is a toolkit for creating ERC-4337-compatible smart wallets for your users, using the user's EOA as the smart wallet's signer. This allows you to easily add Account Abstraction features into your app.

Set up your user's smart wallet

After setting up your Privy integration, follow the Privy ZeroDev integration guide to set up your user's smart wallet with the Privy embedded wallet as its signer.

Set up a session key controlled by your backend

Follow the ZeroDev session key guide to set up session keys enabling your backend service to automate transactions on behalf of the user's smart wallet.

In the example app, we enable session keys by following these steps:

• The backend creates a session key.
  • /api/session_key/init.ts
  • This endpoint creates a remote signer.
  • The endpoint sends the remote signer address back to the user for approval.
  • At this point, the session key has not been approved by the user.
• The user approves the session key.
  • /dashboard.tsx
  • The user can set permissions on the session key.
  • The user approves the session key by generating an approval signature.
• The user returns the approval to the backend.
  • /api/session_key/register.ts
  • The user sends the session key approval (signature) to the backend.
  • The backend caches the approval, which is required for the session key to be used.
• The backend service can now send transactions on behalf of users using the approval and the session key.
  • /api/session_key/rpc.ts
  • The backend initializes a smart wallet client using the approval and session key.
  • The backend can now send transactions according to the permissions set on the session key.