What are Sub Accounts?
Sub Accounts allow you to provision app-specific wallet accounts for your users that are embedded directly in your application. Once created, you can interact with them just as you would with any other wallet via the wallet provider or popular onchain libraries like OnchainKit, wagmi, and viem.Looking for a full implementation? Jump to the Complete Integration Example.
Key Benefits
- Frictionless transactions: Eliminate repeated signing prompts for high frequency and agentic use cases or take full control of the transaction flow.
- No funding flows required: Spend Permissions allow Sub Accounts to spend directly from the universal Base Account’s balance.
- User control: Users can manage all their sub accounts at account.base.app.
If you would like to see a live demo of Sub Accounts in action, check out our Sub Accounts Demo.
Spend PermissionsSub Accounts are optimized for use with Spend Permissions to allow your app to take advantage of the user’s existing Base Account balances. See the Spend Permissions guide for more information about how they work.
Installation
Install the Base Account SDK:Using Sub Accounts
Initialize the SDK
First, set up the Base Account SDK. Be sure to customize theappName
and appLogoUrl
to match your app as this will be displayed in the wallet connection popup and in the account.base.app dashboard. You can also customize the appChainIds
to be the chains that your app supports.
Create a Sub Account
Make sure to authenticate the user with their Base Account before creating a Sub Account.
For that, you can choose one of the following options:
- Follow the Authenticate users guide
- Simply use
provider.request({ method: 'eth_requestAccounts' });
for a simple wallet connection
publicKey
parameter is provided, a non-extractable browser CryptoKey is generated and used to sign on behalf of the Sub Account.

Get Existing Sub Account
Retrieve an existing Sub Account using the provider’s wallet_getSubAccounts RPC method. This will return the Sub Account associated with the app’s domain and is useful to check if a Sub Account already exists for the user to determine if one needs to be created.Send transactions
To send transactions from the connected sub account you can use EIP-5792wallet_sendCalls
or eth_sendTransaction
. You need to specify the from
parameter to be the sub account address.
When the Sub Account is connected, it is the second account in the array returned by
eth_requestAccounts
or eth_accounts
. wallet_addSubAccount
needs to be called in each session before the Sub Account can be used. It will not trigger a new Sub Account creation if one already exists.If you are using mode: 'auto'
, the Sub Account will be the first account in the array.wallet_sendCalls
eth_sendTransaction
wallet_sendCalls
in conjunction with a paymaster to ensure the best user experience. See the Paymasters guide for more information.
Advanced Usage
Import an existing account
If you already have a deployed Smart Contract Account and would like to turn it into a Sub Account of the connected Base Account, you can import it as a Sub Account using the provider RPC method:Before the Sub Account is imported, you will need to add the Base Account address as an owner of the Sub Account. This currently needs to be done manually
by calling the
addOwnerAddress
or addOwnerPublicKey
functions on the Smart Contract of the Sub Account that was imported and setting the Base Account address as the owner.Additionally, only Coinbase Smart Wallet contracts are currently supported for importing as a Sub Account into your Base Account.The Coinbase Smart Wallet contract ABI can be found on GitHub.Add Owner Account
Sub Accounts automatically detect when an ownership update is needed when a signature is required and will prompt the user to approve the update before signing. However, you can also add an owner to a Sub Account manually using the SDK convenience method:addOwnerAddress
or addOwnerPublicKey
functions on the Sub Account’s smart contract to add the owner.
Ownership changes are expected if the user signs in to your app on a new device or browser.Ensure you do not lose your app’s Sub Account signer keys when using the SDK on the server (e.g. Node.js) as updating the owner requires a signature from the user, which cannot be requested from server contexts.
Auto Spend Permissions
Auto Spend Permissions allows Sub Accounts to access funds from their parent Base Account when transaction balances are insufficient. This feature can also establish ongoing spend permissions, enabling future transactions to execute without user approval prompts, reducing friction in your app’s transaction flow.Configuration
Auto Spend Permissions is only available in SDK version2.1.0
or later. This feature is enabled by default when using Sub Accounts.
To disable Auto Spend Permissions when using Sub Accounts, set unstable_enableAutoSpendPermissions
to false
in your SDK configuration:
How it works
First-time transaction flow: When a Sub Account attempts its first transaction, Base Account displays a popup for user approval. During this approval process, Base Account:- Automatically detects any missing tokens (native or ERC-20) needed for the transaction
- Requests a transfer of the required funds from the parent Base Account to the Sub Account to fulfill the current transaction
- Allows the user to optionally grant ongoing spend permissions for future transactions in that token
- First, attempt using existing Sub Account balances and granted spend permissions
- If insufficient, prompt the user to authorize additional transfers and/or spend permissions from their Base Account
Spend permission requests are limited to the first token when multiple transfers are needed for a single transaction. Additional tokens require separate approvals.