Wallets API Quickstart (API)
We’ll demonstrate how to use the wallet_requestAccount, wallet_prepareCalls, wallet_sendPreparedCalls, and wallet_getCallsStatus endpoints.
1. Request an Account for the Owner Signer
Given an owner address, call wallet_requestAccount to return the smart account address for that owner. The owner address can be any signer (or public key) that has the ability to sign transactions.
- If you want to use social sign up / log in, you can simply use the SDK to authenticate user’s and retrieve their signer address
- If instead, you want to generate and control wallets with a custodied owner, you can generate any public private key pair (e.g. any EOA)
This will return the account address associated with the given signer, as well as a uuid you could use to differentiate between accounts for the same signer in the future.
This will return the smart account address associated with the given signer:
2. Prepare Calls
Now that we have an account, it’s time to prepare some calls!
This will return the userop request (the data field) and a signature request, for example:
If using Alchemy’s signer service, this is the full raw payload to sign.
If using a library like Viem, you can instead use personal_sign to sign the hash.
3. Sign the userop
With the returned signature request, all you have to do is sign the signature request (returned in step 2). You’ll sign this using the account owner (from step 1).
If using an Alchemy Signer, you can learn how to stamp the request on the frontend here. When using the Alchemy Signer, it’s easiest to sign the signatureRequest.rawPayload directly.
If you are using a library such as Viem that supports the personal_sign method, you should use that to sign the hash (since the signatureRequest.type is "personal_sign").
4. Send the Prepared Calls!
With the signature from step 3 and the useropRequest from step 2, you’re good to send the call!
This will return the array of prepared call IDs!
5. Check The Calls Status
Now you can simply call wallet_getCallsStatus to check the status of the calls. A “pending” state (1xx status codes) is expected for some time before the transition to “confirmed,” so this endpoint should be polled while the status is pending. If the call does not progress, refer to the retry guide.
See here for all of the possible results.