Skip to main content

Wallet API

Manage wallets for on-chain transactions and payments. Supports session-based wallets, Coinbase Developer Platform (CDP) wallets, and Base network balance queries.
The platform uses Coinbase Smart Wallet as its only wallet connector on Base (coinbaseWallet({ preference: 'smartWalletOnly' })). Injected wallets such as MetaMask are not supported. All wallet interactions on the Base network require a Coinbase Smart Wallet.

Get wallet

Returns wallet information. Behavior depends on whether an address query parameter is provided and on your server configuration.

Base network balance query

When the address query parameter is present, the endpoint queries the Base network for the wallet’s native ETH balance and USDC token balance. The address must be a valid EVM address (0x-prefixed, 42 characters).

Query parameters

Tracked assets

The endpoint returns balances for the following assets on Base:

Response

Response fields

The wallet API has migrated from the Tempo network to Base. The previous Tempo-specific response fields (totalUsd and per-token hasBalance) have been removed. The response now includes explorerUrl, nativeBalance, and assets fields. The primaryToken now always refers to USDC on Base. Update any integrations that relied on the Tempo response shape.
The allTokens array only includes assets with a non-zero balance. The assets array always includes both ETH and USDC regardless of balance. The nativeBalance is always the first entry in the assets array, and primaryToken is always USDC (the second entry).

Errors

CDP / session wallet query

When no address parameter is provided, the endpoint returns CDP or session-based wallet information. When CDP is configured, returns CDP status without authentication. Otherwise, requires session authentication.

Response (CDP configured)

Response (user wallet exists)

Response (no wallet)

Errors

Wallet actions

Requires session authentication.

Request body

Action: create

Creates a new wallet for the authenticated user.
Returns 400 if a wallet already exists.

Action: get_seed

Returns wallet metadata. Private keys are stored encrypted server-side and are never exposed.

Action: export_seed

Seed export is disabled for security. Returns 403.

Errors

Get wallet address

Returns the wallet address for the authenticated user. Prioritizes Base network wallets. When no managed wallet exists in the database, the endpoint falls back to the session-based Base wallet address (from Coinbase Smart Wallet sign-in). Requires session authentication.

Response (managed wallet)

When a Base wallet is found in the database:

Response (session wallet)

When no managed wallet exists but the user signed in with a Base wallet:

Response (no wallet)

When no wallet is linked:

Errors

Create CDP wallet

Requires session authentication. Creates a new wallet using the Coinbase Developer Platform SDK.

Request body

Response

Errors

CDP wallet status

Returns supported chain information for the CDP wallet.

Create CDP wallet client

Creates a viem wallet client on Base Sepolia.

Request body

Response

Wallet top-up

Fund your wallet using a credit card via Stripe checkout. Choose from preset amounts and complete payment through Stripe’s hosted checkout page. On successful payment, your wallet is credited automatically.

Create top-up checkout session

Creates a Stripe checkout session for the specified top-up amount. The caller identifies the wallet to credit by passing the wallet address as a query parameter.

Query parameters

Top-up options

Response

Response fields

On successful payment, the user is redirected to /dashboard/wallet?top_up=success. On cancellation, the user is redirected to /dashboard/wallet?top_up=cancelled.

Errors

Example

Top-up webhook

Stripe webhook endpoint that processes checkout.session.completed events for wallet top-ups. When a payment completes, the webhook verifies the Stripe signature and logs the credit event.
Wallet crediting is not yet fully automated. The webhook records the payment event, but the actual balance update is applied when you next interact with your wallet. This is a known limitation pending indexer integration.
This endpoint is called by Stripe, not by your application directly. You must configure the webhook URL in your Stripe dashboard to point to this endpoint. The request must include a valid stripe-signature header.

Headers

Webhook behavior

The webhook processes events where metadata.type equals wallet_top_up. On a matching checkout.session.completed event, it reads the following metadata fields from the checkout session:

Response

Errors

Transaction history

Returns recent wallet activity for an address on Base. The endpoint returns both USDC token transfers and recent native ETH transactions in a single merged timeline, sorted by timestamp (newest first).

Query parameters

Response

Response fields

USDC transactions are retrieved from ERC-20 Transfer event logs over the most recent 50,000 blocks. ETH transactions are found by scanning the most recent 180 blocks for native value transfers involving the queried address. Older transactions outside these windows are not returned. For complete history, use the explorerUrl from the wallet balance endpoint to link users to Basescan.
The indexedAsset and windowBlocks top-level fields have been removed. Use the sources object to see scan window details. Each transaction now includes an asset field ("USDC" or "ETH") and a source field indicating how it was discovered. The previous symbol field on transactions has been replaced by asset.

Errors

USDC transfer validation

When transferring USDC through the wallet service, the following validation rules apply:
  • The transfer amount must be a positive finite number. Values such as NaN, Infinity, negative numbers, and zero are rejected.
  • Amounts are rounded to 6 decimal places (USDC precision). If the rounded value equals zero, the transfer is rejected.
These checks run before any on-chain transaction is initiated.
When payments are initiated through the x402 pay action, additional protections apply: a per-payment maximum of $100, recipient address format validation (EVM or Solana), and audit logging of every payment attempt. See the x402 gateway reference for details.

Sending USDC

USDC sends from the wallet use a sponsored-first strategy. The wallet attempts a gas-sponsored send before falling back to a standard ERC-20 transfer, so users do not need ETH for gas when sponsorship is available.

Send flow

  1. Sponsored send (preferred) — The wallet first attempts a gas-sponsored USDC send using the Base paymaster. If the sponsored send succeeds, the resulting identifier is returned and the transaction status is polled for up to 30 seconds.
  2. Standard send (fallback) — If the sponsored send fails for any reason, the wallet falls back to a standard on-chain ERC-20 transfer call on the Base USDC contract. This path requires the sender to have ETH for gas.
The send mode is determined automatically. You do not need to specify which path to use.

Send state

After initiating a send, the wallet returns a state object with the following fields:
Sponsored send identifiers are not standard transaction hashes. Do not use them for on-chain receipt polling via RPC methods like eth_getTransactionReceipt. The wallet polls the sponsored payment status internally and updates the send state when the transaction confirms.
When sponsorship is available, no ETH balance is required to send USDC. The gas fee is covered by the platform paymaster. If sponsorship is unavailable, the wallet falls back to a standard send that requires ETH for gas.

Supported assets

MPP payment sessions

Payment sessions enable off-chain, per-call billing for agent requests. Instead of settling every call on-chain, you deposit funds into a session and sign lightweight vouchers that are batched and settled periodically. See MPP payments — sessions for the full protocol description.

List sessions

Returns all sessions (active and closed) for the given wallet address.

Query parameters

Response

Get session

Returns a single session by ID.

Query parameters

Response

Errors

Session fields

Voucher object fields

Each entry in the vouchers array has the following shape: When a session has active vouchers, they appear in the wallet activity feed showing the plugin name, timestamp, and amount for each pending voucher.

Create session

Opens a new payment session. If the wallet already has an active session, the existing session is returned instead.

Request body

Response (201 Created)

Response (existing session)

Errors

Close session

Closes an active session. Any pending vouchers are settled on-chain first, and the remaining balance is returned to the user.

Query parameters

Response

Errors

Submit voucher

Submits a signed voucher to debit the session balance off-chain. This is the primary billing mechanism during an active session — each agent call produces one voucher.

Request body

The voucher amount is determined automatically from the plugin’s pricing. See plugin pricing for current rates.

Response

Response fields

Errors