Skip to main content
This package contains core business logic for the CDP Frontend SDK. It is intended for non-React applications that use pure Typescript.

Quickstart

This guide will help you get started with @coinbase/cdp-core. You’ll learn how to install the package, initialize the SDK, and make your first API call.

Installation

First, add the package to your project using your preferred package manager.

Gather your CDP Project information

  1. Sign in or create an account on the CDP Portal
  2. On your dashboard, select a project from the dropdown at the at the top, and copy the Project ID

Allowlist your local app

  1. Navigate to the Embedded Wallet Configuration in CDP Portal, and click Add origin to include your local app
  2. Enter the origin of your locally running app - e.g., http://localhost:3000
  3. Click Add origin again to save your changes

Initialize the SDK

Before calling any methods in the SDK, you must first initialize it:

Analytics Opt-Out

By default the SDK will emit usage analytics to help us improve the SDK. If you would like to opt-out, you can do so by setting the disableAnalytics configuration option to true.

Account Configuration

You can configure the SDK to create different types of accounts for new users: Smart Account Configuration:
When ethereum.createOnLogin is set to "smart", the SDK will:
  1. Automatically create an EOA (Externally Owned Account) as the owner
  2. Create a Smart Account owned by that EOA
  3. Both accounts will be available on the user object
Solana Account Configuration:
When solana.createOnLogin is set to true, the SDK will:
  1. Create a Solana account for new users
  2. The Solana account will be available on the solanaAccounts property

Deferred Account Creation

You can omit createOnLogin entirely to prevent automatic account creation and instead create accounts manually when needed:
When createOnLogin is omitted, the SDK will:
  1. Not create any accounts automatically upon user login
  2. Require manual account creation using the account creation actions (see below)
  3. Give you full control over when and what types of accounts to create

Multi-Account Support

Users can have multiple accounts of each type:
  • Up to 10 EVM EOA accounts
  • Up to 10 Solana accounts
  • Up to 10 EVM Smart Accounts (each EVM EOA can own one Smart Account)
Using Account Objects (Recommended): The SDK provides rich account objects with additional metadata like creation timestamps and owner relationships:
Legacy Account Arrays (Deprecated): For backward compatibility, the SDK still provides simple address arrays, but these are deprecated:

Sign In a User

You’re now ready to start calling the APIs provided by the package! The following code signs in an end user:
Once a user is authenticated, you can link additional authentication methods to their account. This allows users to sign in using multiple methods (email, SMS, OAuth providers) with the same embedded wallet.

Sign In with Custom Authentication

If you’re using a third-party identity provider (Auth0, Firebase, AWS Cognito, or any OIDC-compliant provider), you can authenticate users with JWTs from your provider.

Prerequisites

Before using custom authentication:
  1. Configure your identity provider in the CDP Portal:
    • Navigate to Embedded Wallet Configuration
    • Click on the Custom auth tab
    • Add your JWKS endpoint URL (e.g., https://your-domain.auth0.com/.well-known/jwks.json)
    • Configure your JWT issuer and audience
  2. Provide a customAuth.getJwt callback when initializing the SDK:

Authenticate a User

Once configured, call authenticateWithJWT() to authenticate the user:

How it Works

  1. Your user signs in to your identity provider (Auth0, Firebase, Cognito, etc.)
  2. You call authenticateWithJWT() which internally calls your customAuth.getJwt callback
  3. The SDK sends the JWT to CDP’s backend, which validates it against your configured JWKS
  4. If valid, the user is authenticated and wallets are auto-created based on your configuration
  5. The customAuth.getJwt callback is called automatically whenever the SDK needs a fresh token

View User Information

Once the end user has signed in, you can display their information in your application:

Multi-Factor Authentication

The SDK supports two methods of multi-factor authentication to add an extra layer of security to your application:
  • TOTP (Time-based One-Time Password): Users enroll using authenticator apps like Google Authenticator or Authy
  • SMS: Users receive verification codes via text message to their phone number
Important: Users must be authenticated (signed in) before they can enroll in MFA or perform MFA verification.

MFA Enrollment Flow

The enrollment flow consists of two steps:
  1. Initiate enrollment - For TOTP: generate a secret and QR code. For SMS: send OTP to phone number
  2. Submit enrollment - Verify the user’s code to complete enrollment
TOTP Enrollment
SMS Enrollment

MFA Verification Flow

When performing sensitive operations that require MFA verification, use the verification flow:
TOTP Verification
SMS Verification

Complete Example: MFA Setup and Usage

Handling Multiple MFA Methods

When users have multiple MFA methods enrolled, use helper functions to check enrollment status and let users choose their preferred method:

Phone Number Validation

When enrolling in SMS MFA, phone numbers must be in E.164 format. The SDK provides strict validation:

Check MFA Configuration

Check whether MFA is enabled for your project and view configuration settings:

Track MFA Enrollment Prompts

Record when users are shown the MFA enrollment prompt to track enrollment opportunities:
Use Cases for Tracking Enrollment Prompts:
  • Track when users skip MFA enrollment
  • Implement smart re-prompting logic (e.g., don’t prompt again for 30 days)
  • Analyze MFA adoption rates
  • Identify users who have been prompted but haven’t enrolled

Create Accounts Manually

If you configured your SDK without createOnLogin, you can manually create accounts for authenticated users when needed. This gives you full control over when accounts are created.

Create an EVM EOA Account

Note: createEvmEoaAccount() will throw an error if the user already has an EVM EOA account.

Create an EVM Smart Account

Note: By default, createEvmSmartAccount() always creates a new EOA to serve as the Smart Account owner. You can also enable spend permissions when creating a Smart Account:
Using a Specific Owner: You can specify an existing EOA address to use as the owner instead of creating a new one:

Create a Solana Account

Note: createSolanaAccount() will throw an error if the user already has a Solana account.

Send an EVM Transaction

We support signing and sending an EVM transaction in a single call on the following networks:
  • Base
  • Base Sepolia
  • Ethereum
  • Ethereum Sepolia
  • Avalanche
  • Arbitrum
  • Optimism
  • Polygon
For EVM networks other than those supported by the CDP APIs, your end user must sign the transaction, and then you must broadcast the transaction yourself. This example uses the public client from viem to broadcast the transaction.

Smart Account Operations

Smart Accounts provide advanced account abstraction features, including user operations and paymaster support.

Create Spend Permissions

Spend permissions allow Smart Accounts to delegate spending authority to other accounts within specified limits and time periods. This enables use cases like subscription payments, automated DeFi strategies, and automatic topping up of AI agent funds.
You can also use periodInDays for a more human-friendly API:

List Spend Permissions

Retrieve all spend permissions for a Smart Account:

Revoke Spend Permissions

Revoke a spend permission for a Smart Account:

Sign a Solana Transaction

When your application is configured with solana: { createOnLogin: true }, you can sign Solana transactions:

Sign a Solana Message

You can also sign arbitrary messages with Solana accounts:

Send a Solana Transaction

You can sign and send a Solana transaction in a single call on the following Solana networks:
  • Solana Mainnet
  • Solana Devnet

Send User Operations

Send user operations from a Smart Account:
Transaction Attribution with EIP-8021: You can add attribution data to user operations for tracking app usage and revenue sharing:
The dataSuffix is a hex-encoded string that follows the EIP-8021 standard for transaction attribution. It allows apps to track usage and enable revenue sharing mechanisms. The suffix is automatically appended to the user operation’s callData before submission.

Get User Operation Status

After sending a user operation, you can get its status and retrieve the result:

Sign Messages and Typed Data

End users can sign EVM messages, hashes, and typed data to generate signatures for various onchain applications.

Export Private Keys

End users can export their private keys from their embedded wallet, allowing them to import them into compatible wallets of their choice. The secure iframe approach is the recommended way to export private keys. It creates a secure iframe that copies the private key directly to the user’s clipboard without ever exposing it to your application’s JavaScript context.
Export EVM Private Key via Iframe
Export Solana Private Key via Iframe

Direct Export (Deprecated)

⚠️ Deprecated: The direct export functions expose the private key to your application’s JavaScript context and will be removed soon. Use the secure iframe approach above instead.
Export EVM Private Key (Deprecated)
Export Solana Private Key (Deprecated)
When your application is configured with solana: { createOnLogin: true }, you can export Solana private keys:

X402 Payment Protocol Support

The SDK includes built-in support for the X402 payment protocol, which enables HTTP requests with micropayments. This allows accessing paid APIs and services that require payment for each request.

Installation

Ensure you have separately installed the x402-fetch package:

Basic Usage

The fetchWithX402 function provides a wrapped fetch API that automatically handles X402 payment requests:

Advanced Configuration

You can customize the X402 behavior with options:

How It Works

  1. When you make a request to an X402-protected resource, the server responds with a 402 Payment Required status
  2. The wrapped fetch function automatically:
    • Extracts payment details from the server’s response
    • Creates and signs a payment transaction using the user’s wallet
    • Includes the payment proof in a retry request
  3. The server validates the payment and returns the requested resource

Smart Account Support

By default, fetchWithX402 will use the user’s Smart Account if available, falling back to their regular EVM account:

Solana Support

Solana is supported out of the box with fetchWithX402. If your end user has both an EVM and Solana account, the EVM account will be used by default. You can pass a Solana address to fetchWithX402 to use the Solana account instead.

EIP-1193 Provider

The core package includes an EIP-1193 compatible provider. This provider can be used to sign and send transactions. The provider is created by calling createCDPEmbeddedWallet, which exposes a .provider attribute. createCDPEmbeddedWallet must be called with the desired chains to support as well as the transports for these chains. The provider will initially connect to the first chain in the chains array. The transports are typically HTTP RPC endpoints, which are used internally for broadcasting non-Base transactions. For more information on transports, see Wagmi’s createConfig setup.

Viem Accounts

The core package includes a toViemAccount utility function that enables wrapping an embedded wallet into a Viem account compatible interface. This allows the account to act as a drop-in replacement for any library or framework that accepts Viem accounts.