You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is necessary to use a private RPC provider (`YOUR_PRIVATE_RPC_URL`) due to the computational demands associated with some of the ENSIP-19 resolution steps.
38
+
39
+
</Tip>
40
+
41
+
<Warning>
42
+
43
+
There may be some latency between the initial registration of a Basename and the ability to resolve this name via ENSIP-19 due to the slow production of state proofs necessary for trustless resolution.
44
+
</Warning>
45
+
46
+
[Learn more about getEnsName →](https://viem.sh/docs/ens/actions/getEnsName)
Base Account's self-custodial design requires a user passkey prompt for each wallet interaction, such as transactions or message signing. While this ensures user awareness and approval of every wallet interaction, it can impact user experience in applications requiring frequent wallet interactions.
11
-
12
-
To support Base Account with user experiences that need more developer control over wallet interactions, we've built Sub Accounts in conjunction with [ERC-7895](https://eip.tools/eip/7895), a new wallet RPC for creating hierarchical relationships between wallet accounts.
13
-
14
-
Sub Accounts allow you to provision wallet accounts that are directly embedded in your application for your users. You can control when a Sub Account is created and interact with them just as you would with another wallet via the wallet provider or popular web3 libraries like OnchainKit, wagmi, and viem.
10
+
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.
15
11
16
-
These Sub Accounts are linked to the end user's Base Account through an onchain relationship. When combined with our [Spend Permission feature](/base-account/improve-ux/spend-permissions), this creates a powerful foundation for provisioning and funding app accounts securely, while giving you ample control over building the user experience that makes the most sense for your application.
12
+
<Note>
13
+
Looking for a full implementation? Jump to the [Complete Integration Example](/base-account/improve-ux/sub-accounts#complete-integration-example).
14
+
</Note>
17
15
18
16
## Key Benefits
19
17
20
-
-**Seamless UX**: Reduce user friction by eliminating repeated signing prompts
21
-
-**Developer Control**: Manage when and how Sub Accounts are created
22
-
-**Secure Relationships**: Onchain linking between main account and sub accounts
23
-
-**Spend Permissions**: Control what Sub Accounts can spend and when
24
-
-**Easy Integration**: Works with existing web3 libraries and tools
18
+
-**Frictionless transactions**: Eliminate repeated signing prompts for high frequency and agentic use cases or take full control of the transaction flow.
19
+
-**No funding flows required**: Spend Permissions allow Sub Accounts to spend directly from the universal Base Account's balance.
20
+
-**User control**: Users can manage all their sub accounts at [account.base.app](https://account.base.app).
25
21
26
22
<Note>
27
-
If you would like to see a live demo of Sub Accounts in action, check out our [Sub Accounts Demo](https://sub-account-demo.com).
23
+
If you would like to see a live demo of Sub Accounts in action, check out our [Sub Accounts Demo](https://sub-accounts-fc.vercel.app).
28
24
</Note>
29
25
30
26
<Tip>
31
-
**Pair with Spend Permissions**
27
+
**Spend Permissions**
32
28
33
-
In order to make your UX more seamless, you can pair Sub Accounts with the
Sub 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](/base-account/improve-ux/spend-permissions) guide for more information about how they work.
36
30
</Tip>
37
31
38
32
## Installation
@@ -57,11 +51,11 @@ bun add @base-org/account
57
51
```
58
52
</CodeGroup>
59
53
60
-
## Basic Setup
54
+
## Using Sub Accounts
61
55
62
56
### Initialize the SDK
63
57
64
-
First, set up the Base Account SDK with Sub Account support:
58
+
First, set up the Base Account SDK. Be sure to customize the `appName` 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.
Make sure to authenticate the user with their Base Account before creating a Sub Account.
79
+
For that, you can choose one of the following options:
80
+
- Follow the [Authenticate users](/base-account/guides/authenticate-users) guide
81
+
- Simply use `provider.request({ method: 'eth_requestAccounts' });` for a simple wallet connection
82
+
</Tip>
84
83
85
-
Create a Sub Account for your application using the providerRPC method:
84
+
Create a Sub Account for your application using the provider's [wallet_addSubAccount](/base-account/reference/core/provider-rpc-methods/wallet_addSubAccount)RPC method. When no `publicKey` parameter is provided, a non-extractable browser CryptoKey is generated and used to sign on behalf of the Sub Account.
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
152
-
by calling the [`addOwnerAddress`](https://github.com/coinbase/smart-wallet/blob/a8c6456f3a6d5d2dea08d6336b3be13395cacd42/src/MultiOwnable.sol#L101) or [`addOwnerPublicKey`](https://github.com/coinbase/smart-wallet/blob/a8c6456f3a6d5d2dea08d6336b3be13395cacd42/src/MultiOwnable.sol#L109) functions on the Smart Contract of the Sub Account that was imported and setting the Base Account address as the owner.
153
-
154
-
Additionally, only Coinbase Smart Wallet contracts are currently supported for importing as a Sub Account into your Base Account.
155
-
</Note>
156
-
157
116
### Get Existing Sub Account
158
117
159
-
Retrieve an existing Sub Account using the providerRPC method:
118
+
Retrieve an existing Sub Account using the provider's [wallet_getSubAccounts](/base-account/reference/core/provider-rpc-methods/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.
160
119
161
120
```tsx
162
121
// Get the universal account
@@ -181,10 +140,9 @@ if (subAccount) {
181
140
}
182
141
```
183
142
184
-
Get the Sub Account associated with the current app using the SDK convenience method:
143
+
Alternatively, you can use the SDK convenience method:
To send transactions from the connected sub account you can use EIP-5792 `wallet_sendCalls` or `eth_sendTransaction`. You need to specify the `from` parameter to be the sub account address.
195
153
196
-
197
-
198
154
<Tip>
199
-
**Tip:**
155
+
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.
200
156
201
-
When the sub account is connected, it is the second account in the array returned by `eth_requestAccounts` or `eth_accounts`.
157
+
If you are using `mode: 'auto'`, the Sub Account will be the first account in the array.
202
158
</Tip>
203
159
160
+
First, get all the accounts that are available, of which the sub account will be the second account:
We recommend using `wallet_sendCalls` in conjunction with a paymaster to ensure the best user experience. See the [Paymasters](/base-account/improve-ux/sponsor-gas/paymasters) guide for more information.
212
+
213
+
## Advanced Usage
214
+
215
+
### Import an existing account
216
+
217
+
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:
218
+
219
+
```tsx
220
+
const subAccount =awaitprovider.request({
221
+
method: 'wallet_addSubAccount',
222
+
params: [
223
+
{
224
+
account: {
225
+
type: 'deployed',
226
+
address: '0xYourSmartContractAccountAddress',
227
+
chainId: 8453// the chain the account is deployed on
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
239
+
by calling the [`addOwnerAddress`](https://github.com/coinbase/smart-wallet/blob/a8c6456f3a6d5d2dea08d6336b3be13395cacd42/src/MultiOwnable.sol#L101) or [`addOwnerPublicKey`](https://github.com/coinbase/smart-wallet/blob/a8c6456f3a6d5d2dea08d6336b3be13395cacd42/src/MultiOwnable.sol#L109) functions on the Smart Contract of the Sub Account that was imported and setting the Base Account address as the owner.
240
+
241
+
Additionally, only Coinbase Smart Wallet contracts are currently supported for importing as a Sub Account into your Base Account.
242
+
243
+
The Coinbase Smart Wallet contract ABI can be found on [GitHub](https://github.com/base/account-sdk/blob/master/packages/account-sdk/src/sign/base-account/utils/constants.ts#L8).
244
+
</Note>
245
+
246
+
248
247
### Add Owner Account
249
248
250
-
Add an owner to a Sub Account:
249
+
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:
This generates a transaction to call the `addOwnerAddress` or `addOwnerPublicKey` functions on the Sub Account's smart contract to add the owner.
262
+
263
+
<Note>
264
+
Ownership changes are expected if the user signs in to your app on a new device or browser.
265
+
266
+
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.
267
+
</Note>
268
+
263
269
## Auto Spend Permissions
264
270
265
271
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.
@@ -301,6 +307,13 @@ Spend permission requests are limited to the first token when multiple transfers
301
307
</Warning>
302
308
303
309
310
+
## Technical Details
311
+
312
+
Base Account's self-custodial design requires a user passkey prompt for each wallet interaction, such as transactions or message signing. While this ensures user awareness and approval of every wallet interaction, it can impact user experience in applications requiring frequent wallet interactions.
313
+
314
+
To support Base Account with user experiences that need more developer control over wallet interactions, we've built Sub Accounts in conjunction with [ERC-7895](https://eip.tools/eip/7895), a new wallet RPC for creating hierarchical relationships between wallet accounts.
315
+
316
+
These Sub Accounts are linked to the end user's Base Account through an onchain relationship. When combined with our [Spend Permission feature](/base-account/improve-ux/spend-permissions), this creates a powerful foundation for provisioning and funding app accounts securely, while giving you ample control over building the user experience that makes the most sense for your application.
304
317
305
318
306
319
## Complete Integration Example
@@ -345,7 +358,6 @@ export default function SubAccountDemo() {
Copy file name to clipboardExpand all lines: docs/base-chain/tools/onramps.mdx
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,6 +19,10 @@ description: Documentation for fiat-to-crypto onramps for the Base network.
19
19
20
20
[Ramp](https://ramp.network/) is an onramp and offramp that empowers users to buy & sell crypto inside your app. Ramp supports 40+ fiat currencies and 90+ crypto assets, including ETH on Base.
21
21
22
+
## Thirdweb
23
+
24
+
[Thirdweb Payments](https://thirdweb.com/payments) is an all-in-one crypto payment solution allowing you to onramp, bridge, and swap over [3,200+ currencies](https://thirdweb.com/tokens) on over [85+ chains](https://thirdweb.com/chainlist?service=pay).
25
+
22
26
## Transak
23
27
24
28
[Transak](https://transak.com/) is a developer integration toolkit to let users buy/sell crypto in any app, website or web plugin. It is available across 170 cryptocurrencies on 75+ blockchains, including ETH on Base.
0 commit comments