> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cdp.coinbase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Payments transfers travel rule completed
> Triggered when the `payments.transfers.travel_rule_completed` webhook event is emitted. Your API will receive a POST request at the webhook URL you configured.
## OpenAPI
````yaml webhook paymentsTransfersTravelRuleCompleted
openapi: 3.1.0
info:
title: Coinbase Developer Platform APIs
description: >-
The Coinbase Developer Platform APIs - leading the world's transition
onchain.
license:
name: MIT
url: https://opensource.org/licenses/MIT
version: 2.0.0
contact:
name: Coinbase Developer Platform
email: cdp@coinbase.com
url: https://cdp.coinbase.com
servers:
- url: https://api.cdp.coinbase.com/platform
description: The production server of the CDP APIs.
security:
- apiKeyAuth: []
tags:
- name: Accounts
x-audience: public
x-slo-tier:
tier: beta
description: >-
The Accounts APIs enable developers to create and manage accounts for
their Entity. An Account is a container that holds assets and can be used
for transacting. Accounts can be of different types including entity
accounts, prime accounts, and business accounts. Support for
Customer-owned accounts is in development.
- name: Deposit Destinations
x-audience: public
x-slo-tier:
tier: beta
description: >-
Deposit Destinations allow you to manage where funds can be deposited into
your accounts.
## Crypto Deposit Destinations
Crypto deposit destinations are cryptocurrency addresses that you can
generate and fetch via the API. Once created, these addresses can receive
cryptocurrency payments on their specified network and will settle in your
account balance.
**Metadata:**
You can attach metadata to any deposit destination you create to track the
purpose or source of deposits.
**Example:**
```json
{
"depositDestinationId": "depositDestination_123",
"accountId": "account_456",
"type": "crypto",
"crypto": {
"network": "base",
"address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e"
},
"target": {
"accountId": "account_789",
"asset": "usd"
},
"status": "active",
"metadata": {
"customer_id": "cust_789",
"reference": "order-12345"
}
}
```
Use the list endpoint to retrieve all deposit destinations.
- name: End User Account Management
x-audience: public
x-slo-tier:
tier: ga
description: >-
The End User Account Management APIs enable developers to manage the
accounts belonging to their end users. End user accounts are typically
created by end users themselves when they sign in to the developer's
application via the CDP Web SDK. However, developers also have the option
of creating end user accounts on behalf of their end users. Critically,
developers do not have the ability to sign transactions or messages on
behalf of the end user; only end users can do this.
End User Account Management APIs are accessed by the developer's servers
and authenticated by the developer's CDP API key.
- name: End User Accounts
x-audience: public
x-slo-tier:
tier: ga
description: >-
The End User Accounts APIs enable end users to directly create, manage,
and use their accounts. They are typically accessed via the CDP Web SDK,
which handles end-user authentication and Temporary Wallet Secret
management on behalf of the developer. The End User Accounts APIs offer
end users full control over their accounts, including the ability to sign
transactions and messages, and to export their accounts' private keys.
## Delegated Signing
Delegated signing allows developers to sign and send transactions on
behalf of an end user without requiring the end user to be present at
signing time. This is useful for background operations, automated
workflows, and scenarios where the developer's server needs to act on the
end user's behalf.
To use delegated signing, the end user must first create a short-lived
**delegation grant** by authenticating with their access token and
Temporary Wallet Secret. The grant specifies an `expiresAt` timestamp that
defines how long the developer is authorized to sign on the end user's
behalf.
Once a delegation grant is active, the developer's server can use its CDP
API key to perform signing operations for that end user. The delegation
middleware transparently validates that an active (non-expired,
non-revoked) grant exists for the `{project, user}` pair before allowing
the operation to proceed.
**Grant lifecycle:**
- Delegation grants are scoped to a single project and end user pair.
- Grants are time-bounded by the `expiresAt` timestamp and are automatically cleaned up after expiration.
- Grants can be revoked early by either the end user (using their access token and TWS) or the
developer (using their API key), via the `RevokeDelegationForEndUser` endpoint.
- Only one active grant can exist per `{project, user}` pair at a given time.
- name: EVM Accounts
x-audience: public
x-slo-tier:
tier: ga
description: >-
The EVM Account APIs enable you to create and use accounts across
blockchains that are compatible with the Ethereum Virtual Machine (EVM).
An **account** is a private/public key pair that is used to sign
transactions and messages. The private key is generated and used only in
CDP's Trusted Execution Environment (TEE), and never exposed to Coinbase
or the developer.
An EVM account is identified by its **address**, which is a 0x-prefixed
hexadecimal string. The same address can be used across multiple EVM
networks.
Accounts can optionally be assigned an **account name** at creation time
for easier identification in subsequent API calls. EVM account names must
be globally unique across all EVM accounts in the developer's CDP Project.
## Authentication
The EVM Account API uses two layers of authentication to ensure the
security of your accounts' private keys:
- **CDP Secret API Key**: This key is used to authenticate all requests to
the entire suite of
REST APIs offered on Coinbase Developer Platform.
- **Wallet Secret**: This secret is used specifically to authenticate
sensitive wallet operations
to `POST` and `DELETE` endpoints in the EVM and Solana Account APIs.
To learn more about creating and using these keys, visit our
[Authentication
docs](https://docs.cdp.coinbase.com/api-reference/v2/authentication).
**Use our SDK**
The [CDP SDK](https://github.com/coinbase/cdp-sdk) automatically
authenticates requests using your CDP Secret API Key and Wallet Secret.
Use the CDP SDK for a more convenient access to our APIs.
- name: EVM Smart Accounts
x-audience: public
x-slo-tier:
tier: ga
description: >-
The EVM Smart Account APIs enable you to create and manage Smart Account
wallets across EVM-compatible blockchains.
A **Smart Account** is an EVM account that enables enhanced functionality
such as account abstraction, batched transactions, and gas sponsorship
through [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337). Smart
Accounts allow users to create and manage "user operations" instead of
traditional EVM transactions.
Smart Accounts are identified by their **address**, which is a 0x-prefixed
hexadecimal string.
Smart Accounts can be assigned an optional **name** at creation time for
easier identification in subsequent API calls.
A Smart Account has a single owner, which is another EVM Account which
signs the Smart Account's transactions. The owner can be a CDP EVM
account, or an account managed solely by the developer.
- name: EVM Swaps
x-audience: public
x-slo-tier:
tier: beta
description: >-
A swap refers to the act of exchanging one token for another. The EVM Swap
APIs enable you to create and manage swaps. A swap process involves:
1. A user approves token spending via smart contract.
2. The smart contract determines the exchange rate and facilitates the swap between the two tokens.
3. The transaction is completed atomically and the tokens are transferred to the user's wallet.
The Swap API supports:
- **Getting a price**: Estimate the amount of tokens you will receive for a given amount of exchanged tokens.
- **Creating a swap quote**: Return a swap transaction payload that you can use to sign and submit in order to execute the swap.
For the easiest experience creating, signing, and submitting a swap, we
recommend using the [CDP SDK](https://github.com/coinbase/cdp-sdk/).
- [Python SDK
examples](https://github.com/coinbase/cdp-sdk/tree/main/python#evm-swaps)
- [TypeScript SDK
examples](https://github.com/coinbase/cdp-sdk/tree/main/typescript#evm-swaps)
To read more about using the EVM Swap APIs, please see our [Swap API
docs](https://docs.cdp.coinbase.com/swaps/docs/welcome).
- name: EVM Token Balances
x-audience: public
x-slo-tier:
tier: ga
description: >-
The EVM Token Balances APIs enable you to retrieve the balances of EVM
addresses.
This includes tokens (i.e. ERC-20s) and the native gas token of the
network.
## Denomination
- 'amount' is denominated in the smallest indivisible unit of the token.
For ETH, the smallest indivisible unit is Wei (10^-18 ETH). For ERC-20s,
the smallest unit is the unit returned from `function totalSupply() public
view returns (uint256)`.
- 'decimals' is the exponential value N that satisfies the equation
`amount * 10^-N = standard_denomination`. The standard denomination is the
most commonly used denomination for the token.
- In the case of the native gas token, `decimals` is defined via convention. As an example, for ETH of Ethereum mainnet, the standard denomination is 10^-18 the smallest denomination (Wei). As such, for ETH on Ethereum mainnet, `decimals` is 18.
- In the case of ERC-20 tokens, `decimals` is defined via configuration. `decimals` will be the number returned by `function decimals() public view returns (uint8)` on the underlying token contract.
- name: Faucets
x-audience: public
x-slo-tier:
tier: ga
description: >-
The Faucet APIs enable you to request funds on supported test networks.
Faucets are for testing purposes and make development easier by providing
a source of funds.
- name: Onchain Data
x-audience: public
x-slo-tier:
tier: ga
description: >-
Query and analyze blockchain data with high performance and reliability.
Features include real-time token balances, token discovery, and
transaction history with freshness, accuracy, and completeness like never
before.
- name: Onramp
x-audience: public
x-slo-tier:
tier: ga
description: >-
The v2 Onramp APIs are an evolution of our [v1
APIs](https://docs.cdp.coinbase.com/api-reference/rest-api/onramp-offramp/),
designed to make the fiat-to-crypto experience feel native to your
applications for higher conversion and less friction. These APIs only
cover a subset of Coinbase Onramp functionality as described below, for
all other use cases please refer to our [v1
APIs](https://docs.cdp.coinbase.com/api-reference/rest-api/onramp-offramp/).
## Supported Use Cases
#### Apple Pay Onramp
This use case allows you to offer an Apple Pay onramp experience with
debit cards in your app without users needing to create or log into a
Coinbase account. Our API returns a `paymentLink` URL that renders an
Apple Pay button for you to load in a webview or iframe in your app,
making the onramp experience feel native to your application.
Refer to our [detailed integration
guide](https://docs.cdp.coinbase.com/onramp-&-offramp/onramp-apis/apple-pay-onramp-api)
for more information on the limitations and requirements of this use case.
See our [onramp mobile demo
app](https://github.com/coinbase/onramp-demo-mobile) for a reference
implementation.
#### Hosted UI Onramp
This use case enables you to offer a full-featured onramp experience by
redirecting users to a Coinbase-hosted page where they can choose to log
into their existing Coinbase account or proceed as a guest. The Onramp
Session API generates secure, single-use Onramp URLs with customizable
parameters, allowing you to control available payment methods, preset
transaction amounts, and cryptocurrencies for a tailored user experience.
Refer to our
[guide](https://docs.cdp.coinbase.com/onramp-&-offramp/onramp-apis/generating-onramp-url)
for implementation details and customization options for this use case.
- name: Payment Methods
x-audience: public
x-slo-tier:
tier: beta
description: >-
The Payment Methods APIs enable you to create and manage payment methods
for accounts. Payment methods represent ways to send and receive payments,
such as ACH transfers and Fedwire transfers. These APIs allow you to
create, list, and retrieve payment method details for use in payment
transfers and transactions.
- name: Policy Engine
x-audience: public
x-slo-tier:
tier: ga
description: >-
The Policy Engine APIs evaluate policies (a set of rules) to govern the
behavior of accounts or projects, such as enforce allowlists and
denylists.
- A **policy** is a collection of `rules` with defined criteria.
- Each **rule** contains a specified `action`, `operation`, and
`criteria`:
- An `action` can either `accept` or `reject` a transaction if the criteria in the rule are met.
- `criteria` is an array of logical expressions. All parameters must evaluate to true for the action to be applied.
- An `operation` corresponds to a CDP v2 API:
- `signEvmTransaction` or `signSolTransaction` for signing transactions (to set a transaction limit).
- `sendEvmTransaction` for signing a transaction, and sending it to a supported network.
- `signEvmHash` for signing an arbitrary 32 byte hash.
- `signEvmMessage` for signing an [EIP-191](https://eips.ethereum.org/EIPS/eip-191) message.
- `prepareUserOperation` for preparing user operations on a smart account.
- `sendUserOperation` for sending user operations using a smart account.
- `signEndUserEvmTransaction` or `signEndUserSolTransaction` for signing end user transactions (to set a transaction limit).
- `sendEndUserEvmTransaction` for signing an end user transaction, and sending it to a supported EVM network.
- `sendEndUserSolTransaction` for signing an end user transaction, and sending it to a supported Solana network.
- `signEndUserEvmMessage` for signing an end user [EIP-191](https://eips.ethereum.org/EIPS/eip-191) message.
- `signEndUserEvmTypedData` for signing end user [EIP-712](https://eips.ethereum.org/EIPS/eip-712) typed data.
- `signEndUserSolMessage` for signing an end user Solana message.
- A **rule** indicates how an operation should behave, specifying whether
a request with defined criteria should be accepted or rejected.
## Policy Scope
Policies can be applied at the project and/or account level:
- **Project-level policy**: A `project`-level policy applies to all
accounts in a CDP Project. Only one project-level policy can be applied to
accounts within a CDP Project at any given time.
- **Account-level policy**: An `account`-level policy applies to one or
more accounts. An account
can have at most one account-level policy at any given time.
Thus, a single account can be assigned at most two policies at any given
time: one project-level policy and one account-level policy.
**Note:** End user operation rules (e.g., `signEndUserEvmTransaction`,
`sendEndUserSolTransaction`) currently only apply for policies with the
`project` scope.
Scope is specified in the `scope` field of a policy:
```json {
"description": "Project-level policy",
"scope": "account",
...
```
## Policy Evaluation
**Project-level policies** are evaluated first, followed by
**account-level policies**.
The Policy Engine will process the request against each rule in the order
it is defined within the `rules` array:
1. If the rule's `criteria` (processed as a logical **AND** operation applied to a list of independently evaluated boolean expressions) are met, `accept` or `reject` behavior is applied immediately and the engine stops further evaluation of the policy.
1. If after policy evaluation, no rule's `criteria` are met, the engine moves to processing the next policy (i.e., an `account`-level policy).
1. If no further policies exist, the request is rejected.
For example, the following policy is a project-level policy with two
rules. The Policy Engine will:
1. **Evaluate the first rule:** For a `signEvmTransaction` request, accept the request if the transaction is less than or equal to 1000000000000000000 wei OR
1. **Evaluate the second rule:** if the request is a `signEvmTransaction` request, accept the request if the transaction is less than or equal to 2000000000000000000 wei AND the request is made to the address `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`.
1. **If the request does not meet the criteria of either rule**, the engine will move on to evaluate an `account`-level policy (if one exists).
1. Otherwise, the request is rejected.
Rules are processed in the order they are defined. Once a rule applies to
an operation, subsequent rules are ignored.
```json
{
"description": "Project-level policy",
"scope": "project",
"rules": [
{
"action": "accept",
"operation": "signEvmTransaction",
"criteria": [
{
"type": "ethValue",
"ethValue": "1000000000000000000",
"operator": "<="
}
]
},
{
"action": "accept",
"operation": "signEvmTransaction",
"criteria": [
{
"type": "ethValue",
"ethValue": "2000000000000000000",
"operator": "<="
},
{
"type": "evmAddress",
"addresses": [
"0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"
],
"operator": "in"
}
]
}
]
}
```
## Policy Application
Project-level policies are applied to all accounts in a CDP Project. They
will apply retroactively even if the project-level policy is created after
the account was created. To disable a project-level policy, you must
remove the project-level policy from the CDP Project using the
`deletePolicy` operation.
Account-level policies can be applied in two ways:
- By specifying the `accountPolicy` field in the request body of the
`createEvmAccount` and
`createSolAccount` operations.
- By specifying the `accountPolicy` field in the request body of the
`updateEvmAccount` and
`updateSolanaAccount` operations.
## Criteria
The following criteria are supported:
### SignEvmTransaction Criteria
#### ethValue
A criterion based on the value of the transaction. The transaction's
`value` field is compared to the criterion's `ethValue` field using the
`operator` field.
#### evmAddress
A criterion based on the recipient address of the transaction. The
transaction's `to` field is compared to the criterion's `addresses` field
using the `operator` field.
#### evmData
A criterion based on encoded transaction data that evaluates the function
being called, as well as any number of arguments accessed by either name
or index. Currently this criterion only supports primitive types;
`string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`,
`address`, and both fixed and dynamic length `bytes`.
#### netUSDChange
A criterion based on the USD denominated market value of assets being
transferred, or exposing the sender to. The types of assets included in
the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155`
tokens. The sum total USD amount of assets being transferred and exposed
is compared to the criterion's `changeCents` field using the `operator`
field. If signing a testnet transaction, then this criterion configuration
will be ignored.
### SendEvmTransaction Criteria
#### ethValue
A criterion based on the value of the transaction. The transaction's
`value` field is compared to the criterion's `ethValue` field using the
`operator` field.
#### evmAddress
A criterion based on the recipient address of the transaction. The
transaction's `to` field is compared to the criterion's `addresses` field
using the `operator` field.
#### evmNetwork
A criterion based on the intended network of the transaction. The
`network` field in the `sendEvmTransaction` request body is compared to
the criterion's `networks` field using the `operator` field.
Valid networks for this criterion include:
- `base`
- `base-sepolia`
- `ethereum`
- `ethereum-sepolia`
- `avalanche`
- `polygon`
- `optimism`
- `arbitrum`
- `arbitrum-sepolia`
- `world`
- `world-sepolia`
#### evmData
A criterion based on encoded transaction data that evaluates the function
being called, as well as any number of arguments accessed by either name
or index. Currently this criterion only supports primitive types;
`string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`,
`address`, and both fixed and dynamic length `bytes`.
#### netUSDChange
A criterion based on the USD denominated market value of assets being
transferred, or exposing the sender to. The types of assets included in
the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155`
tokens. The sum total USD amount of assets being transferred and exposed
is compared to the criterion's `changeCents` field using the `operator`
field. If sending a testnet transaction, then this criterion configuration
will be ignored.
### SendUserOperation Criteria
#### ethValue
A criterion based on the value of the user operation. The operation's
`value` fields are compared to the criterion's `ethValue` field using the
`operator` field.
#### evmAddress
A criterion based on the recipient address of the operation. The
operation's `to` fields are compared to the criterion's `addresses` field
using the `operator` field.
#### evmData
A criterion based on encoded transaction data that evaluates the function
being called, as well as any number of arguments accessed by either name
or index. Currently this criterion only supports primitive types;
`string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`,
`address`, and both fixed and dynamic length `bytes`.
### PrepareUserOperation Criteria
#### ethValue
A criterion based on the value of the user operation. The operation's
`value` fields are compared to the criterion's `ethValue` field using the
`operator` field.
#### evmAddress
A criterion based on the recipient address of the user operation. The
operation's `to` fields are compared to the criterion's `addresses` field
using the `operator` field.
#### evmNetwork
A criterion based on the intended network of the user operation. The
`network` field in the `prepareUserOperation` request body is compared to
the criterion's `networks` field using the `operator` field.
Valid networks for this criterion include:
- `base-sepolia`
- `base`
- `arbitrum`
- `optimism`
- `zora`
- `polygon`
- `bnb`
- `avalanche`
- `ethereum`
- `ethereum-sepolia`
#### evmData
A criterion based on encoded transaction data that evaluates the function
being called, as well as any number of arguments accessed by either name
or index. Currently this criterion only supports primitive types;
`string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`,
`address`, and both fixed and dynamic length `bytes`.
### SignEvmHash Criteria
The `signEvmHash` operation does not accept any criteria. To prevent this
operation from being executed by any account, specify a rule with
`signEvmHash` as the operation, and `reject` as its action.
### SignEvmMessage Criteria
#### evmMessage
A criterion based on the intended message to be signed. The `match` field
in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax)
compliant regular expression that will be executed against the message in
the API request.
### SignSolMessage Criteria
#### solMessage
A criterion based on the intended message to be signed. The `match` field
in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax)
compliant regular expression that will be executed against the message in
the API request.
### SignSolTransaction Criteria
#### solAddress
A criterion based on the recipient addresses of the transaction. The
criterion's `address` field is compared to the list of addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### solValue
A criterion based on the value of the transaction. The criterion's
`solValue` field is compared to the transaction's `value`, which is the
amount of SOL in lamports being transferred, using the `operator` field.
#### splAddress
A criterion based on the recipient addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of SPL token transfer recipient addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### splValue
A criterion based on the SPL token value of SPL token transfer
instructions in the transaction. The criterion's `splValue` field is
compared to the transaction instruction's `value` field, which is the
amount of the SPL token being transferred, using the `operator` field.
#### mintAddress
A criterion based on the token mint addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of token mint addresses in the transaction's
`accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0
transactions) array using the `operator` field.
#### solData
A criterion based on Solana transaction instruction data. The criterion
uses Interface Definition Language (IDL) specifications to decode and
validate instruction data against specific rules. The `idls` field
specifies which Solana programs to validate against (either known program
names like "SystemProgram" and "TokenProgram", or custom IDL objects), and
the `conditions` field defines instruction-specific validation rules
including instruction names and parameter constraints.
#### programId
A criterion based on the program IDs of a transaction's instructions. The
criterion's `programIds` field is compared to the list of program IDs in
the transaction's instructions using the `operator` field.
### SendSolTransaction Criteria
#### solAddress
A criterion based on the recipient addresses of the transaction. The
criterion's `address` field is compared to the list of addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### solValue
A criterion based on the value of the transaction. The criterion's
`solValue` field is compared to the transaction's `value`, which is the
amount of SOL in lamports being transferred, using the `operator` field.
#### splAddress
A criterion based on the recipient addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of SPL token transfer recipient addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### splValue
A criterion based on the SPL token value of SPL token transfer
instructions in the transaction. The criterion's `splValue` field is
compared to the transaction instruction's `value` field, which is the
amount of the SPL token being transferred, using the `operator` field.
#### mintAddress
A criterion based on the token mint addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of token mint addresses in the transaction's
`accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0
transactions) array using the `operator` field.
#### solData
A criterion based on Solana transaction instruction data. The criterion
uses Interface Definition Language (IDL) specifications to decode and
validate instruction data against specific rules. The `idls` field
specifies which Solana programs to validate against (either known program
names like "SystemProgram" and "TokenProgram", or custom IDL objects), and
the `conditions` field defines instruction-specific validation rules
including instruction names and parameter constraints.
#### programId
A criterion based on the program IDs of a transaction's instructions. The
criterion's `programIds` field is compared to the list of program IDs in
the transaction's instructions using the `operator` field.
#### solNetwork
A criterion based on the intended network of the transaction. The
`network` field in the `sendSolanaTransaction` request body is compared to
the criterion's `networks` field using the `operator` field.
Valid networks for this criterion include:
- `solana-devnet`
- `solana`
## End User Criteria for User Wallets
End user criteria apply to operations performed by end users via user
wallets. These criteria are only evaluated for policies with the `project`
scope. The supported criterion types for each end user operation mirror
their non-end-user counterparts.
### SignEndUserEvmTransaction Criteria
#### ethValue
A criterion based on the value of the transaction. The transaction's
`value` field is compared to the criterion's `ethValue` field using the
`operator` field.
#### evmAddress
A criterion based on the recipient address of the transaction. The
transaction's `to` field is compared to the criterion's `addresses` field
using the `operator` field.
#### evmData
A criterion based on encoded transaction data that evaluates the function
being called, as well as any number of arguments accessed by either name
or index. Currently this criterion only supports primitive types;
`string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`,
`address`, and both fixed and dynamic length `bytes`.
#### netUSDChange
A criterion based on the USD denominated market value of assets being
transferred, or exposing the sender to. The types of assets included in
the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155`
tokens. The sum total USD amount of assets being transferred and exposed
is compared to the criterion's `changeCents` field using the `operator`
field. If signing a testnet transaction, then this criterion configuration
will be ignored.
### SendEndUserEvmTransaction Criteria
#### ethValue
A criterion based on the value of the transaction. The transaction's
`value` field is compared to the criterion's `ethValue` field using the
`operator` field.
#### evmAddress
A criterion based on the recipient address of the transaction. The
transaction's `to` field is compared to the criterion's `addresses` field
using the `operator` field.
#### evmNetwork
A criterion based on the intended network of the transaction. The
`network` field in the `sendEndUserEvmTransaction` request body is
compared to the criterion's `networks` field using the `operator` field.
Valid networks for this criterion include:
- `base`
- `base-sepolia`
- `ethereum`
- `ethereum-sepolia`
- `avalanche`
- `polygon`
- `optimism`
- `arbitrum`
#### evmData
A criterion based on encoded transaction data that evaluates the function
being called, as well as any number of arguments accessed by either name
or index. Currently this criterion only supports primitive types;
`string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`,
`address`, and both fixed and dynamic length `bytes`.
#### netUSDChange
A criterion based on the USD denominated market value of assets being
transferred, or exposing the sender to. The types of assets included in
the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155`
tokens. The sum total USD amount of assets being transferred and exposed
is compared to the criterion's `changeCents` field using the `operator`
field. If sending a testnet transaction, then this criterion configuration
will be ignored.
### SignEndUserEvmMessage Criteria
#### evmMessage
A criterion based on the intended message to be signed. The `match` field
in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax)
compliant regular expression that will be executed against the message in
the API request.
### SignEndUserEvmTypedData Criteria
#### evmTypedDataField
A criterion based on the fields of the
[EIP-712](https://eips.ethereum.org/EIPS/eip-712) typed data being signed.
The `types` field specifies the EIP-712 type definitions and primary type,
while the `conditions` field defines validation rules for specific fields
within the typed data message. Conditions can target address fields,
numerical fields, or string fields, and can reference deeply nested values
using dot-separated paths.
#### evmTypedDataVerifyingContract
A criterion based on the verifying contract address in the
[EIP-712](https://eips.ethereum.org/EIPS/eip-712) domain separator. The
domain's `verifyingContract` field is compared to the criterion's
`addresses` field using the `operator` field.
### SignEndUserSolTransaction Criteria
#### solAddress
A criterion based on the recipient addresses of the transaction. The
criterion's `address` field is compared to the list of addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### solValue
A criterion based on the value of the transaction. The criterion's
`solValue` field is compared to the transaction's `value`, which is the
amount of SOL in lamports being transferred, using the `operator` field.
#### splAddress
A criterion based on the recipient addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of SPL token transfer recipient addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### splValue
A criterion based on the SPL token value of SPL token transfer
instructions in the transaction. The criterion's `splValue` field is
compared to the transaction instruction's `value` field, which is the
amount of the SPL token being transferred, using the `operator` field.
#### mintAddress
A criterion based on the token mint addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of token mint addresses in the transaction's
`accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0
transactions) array using the `operator` field.
#### solData
A criterion based on Solana transaction instruction data. The criterion
uses Interface Definition Language (IDL) specifications to decode and
validate instruction data against specific rules. The `idls` field
specifies which Solana programs to validate against (either known program
names like "SystemProgram" and "TokenProgram", or custom IDL objects), and
the `conditions` field defines instruction-specific validation rules
including instruction names and parameter constraints.
#### programId
A criterion based on the program IDs of a transaction's instructions. The
criterion's `programIds` field is compared to the list of program IDs in
the transaction's instructions using the `operator` field.
### SendEndUserSolTransaction Criteria
#### solAddress
A criterion based on the recipient addresses of the transaction. The
criterion's `address` field is compared to the list of addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### solValue
A criterion based on the value of the transaction. The criterion's
`solValue` field is compared to the transaction's `value`, which is the
amount of SOL in lamports being transferred, using the `operator` field.
#### splAddress
A criterion based on the recipient addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of SPL token transfer recipient addresses in the
transaction's `accountKeys` (for legacy transactions) or
`staticAccountKeys` (for V0 transactions) array using the `operator`
field.
#### splValue
A criterion based on the SPL token value of SPL token transfer
instructions in the transaction. The criterion's `splValue` field is
compared to the transaction instruction's `value` field, which is the
amount of the SPL token being transferred, using the `operator` field.
#### mintAddress
A criterion based on the token mint addresses of SPL token transfer
instructions in the transaction. The criterion's `addresses` field is
compared to the list of token mint addresses in the transaction's
`accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0
transactions) array using the `operator` field.
#### solData
A criterion based on Solana transaction instruction data. The criterion
uses Interface Definition Language (IDL) specifications to decode and
validate instruction data against specific rules. The `idls` field
specifies which Solana programs to validate against (either known program
names like "SystemProgram" and "TokenProgram", or custom IDL objects), and
the `conditions` field defines instruction-specific validation rules
including instruction names and parameter constraints.
#### programId
A criterion based on the program IDs of a transaction's instructions. The
criterion's `programIds` field is compared to the list of program IDs in
the transaction's instructions using the `operator` field.
#### solNetwork
A criterion based on the intended network of the transaction. The
`network` field in the `sendEndUserSolTransaction` request body is
compared to the criterion's `networks` field using the `operator` field.
Valid networks for this criterion include:
- `solana-devnet`
- `solana`
### SignEndUserSolMessage Criteria
#### solMessage
A criterion based on the intended message to be signed. The `match` field
in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax)
compliant regular expression that will be executed against the message in
the API request.
## Restricting Contract Interactions on Ethereum
Smart contract function restrictions serve as a critical security and
governance mechanism in decentralized applications, allowing developers
and organizations to implement fine-grained access controls over their
protocol interactions.
One of the primary use cases for function restrictions is protecting
high-risk operations from unauthorized access such as:
- Fund transfers - Contract upgrades - Parameter modifications - Emergency
pauses
Policy Engine supports such restrictions that evaluate against transaction
data with the `evmData` criterion for the `signEvmTransaction`, and
`sendEvmTransaction` operations.
## Examples
### USD Limits
The following example demonstrates a policy that only allows transactions
to transfer, or expose the sender to, less than $100.00 worth of assets at
a time. This USD denominated amount includes native assets, `ERC20`,
`ERC721`, and `ERC1155` tokens calculated using current market prices.
```json {
"scope": "account",
"description": "Reject assets out over 100 USD",
"rules": [
{
"action": "reject",
"operation": "sendEvmTransaction",
"criteria": [
{
"type": "netUSDChange",
"changeCents": 10000,
"operator": ">",
},
],
},
{
"action": "reject",
"operation": "signEvmTransaction",
"criteria": [
{
"type": "netUSDChange",
"changeCents": 10000,
"operator": ">",
},
],
},
],
} ```
### Limiting USDC Spend
This policy restricts USDC transactions on the Base network to transfers
of 10,000 tokens or less. It applies to both signing and sending
transactions to the USDC contract address, using the ERC20 ABI to validate
that only `transfer` function calls with a `value` parameter under the
specified limit are permitted.
```json {
"description": "Limit USDC Spend",
"scope": "account",
"rules": [
{
"action": "accept",
"operation": "sendEvmTransaction",
"criteria": [
{
"type": "evmNetwork",
"networks": ["base"],
"operator": "in"
},
{
"type": "evmAddress",
"addresses": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"],
"operator": "in"
},
{
"type": "evmData",
"abi": "erc20",
"conditions": [
{
"function": "transfer",
"params": [
{
"name": "value",
"operator": "<=",
"value": "10000"
}
]
}
]
}
]
},
{
"action": "accept",
"operation": "signEvmTransaction",
"criteria": [
{
"type": "evmAddress",
"addresses": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"],
"operator": "in"
},
{
"type": "evmData",
"abi": "erc20",
"conditions": [
{
"function": "transfer",
"params": [
{
"name": "value",
"operator": "<=",
"value": "10000"
}
]
}
]
}
]
}
]
} ```.
- name: Solana Accounts
x-audience: public
x-slo-tier:
tier: ga
description: >-
The Solana Account APIs enable you to create and use Solana accounts
across SVM-compatible blockchains.
An **account** is a private/public key pair that is used to sign
transactions and messages. The private key is generated and used only in
CDP's Trusted Execution Environment (TEE), and never exposed to Coinbase
or the developer.
A Solana account is identified by its **address**, which is a base-58
encoded string.
Accounts can optionally be assigned an **account name** at creation time
for easier identification in subsequent API calls. Solana account names
must be globally unique across all Solana accounts in the developer's CDP
Project.
## Authentication
The Solana Account APIs use two layers of authentication to ensure the
security of your accounts' private keys:
- **CDP Secret API Key**: This key is used to authenticate all requests to
the entire suite of
REST APIs offered on Coinbase Developer Platform.
- **Wallet Secret**: This secret is used specifically to authenticate
sensitive wallet operations
to `POST` and `DELETE` endpoints in the EVM and Solana Account APIs.
To learn more about creating and using these keys, visit our
[Authentication
docs](https://docs.cdp.coinbase.com/api-reference/v2/authentication).
**Use our SDK**
The [CDP SDK](https://github.com/coinbase/cdp-sdk) automatically
authenticates requests using your CDP Secret API Key and Wallet Secret.
Use the CDP SDK for a more convenient access to our APIs.
- name: Solana Token Balances
x-audience: public
x-slo-tier:
tier: ga
description: >-
The Solana Token Balances APIs enable you to retrieve the balances of
Solana addresses.
This includes SPL tokens and the native SOL token of the network.
## Denomination
- 'amount' is denominated in the smallest indivisible unit of the token.
For SOL, the smallest indivisible unit is lamports (10^-9 SOL). For SPL
tokens, the smallest unit is defined by the token's decimals
configuration.
- 'decimals' is the exponential value N that satisfies the equation
`amount * 10^-N = standard_denomination`. The standard denomination is the
most commonly used denomination for the token.
- For native SOL, `decimals` is 9 (1 SOL = 10^9 lamports).
- For SPL tokens, `decimals` is defined in the token's mint configuration.
- name: SQL API
x-audience: public
x-slo-tier:
tier: ga
description: >-
The SQL API enables you to write performant, high-freshness, and endlessly
flexible SQL queries against onchain data.
- name: Transfers
x-audience: public
x-slo-tier:
tier: beta
description: >-
**Transfers** represent both the request and execution of fund transfers
from a source to a target. They provide upfront fee quotes and track the
complete lifecycle from initiation through completion, failure, or
reversal.
## Fee Quotes
Every transfer provides a comprehensive fee quote in the `fees` array.
This allows you to show users exactly what they'll pay before any money
moves.
To review fees before execution:
1. Create a transfer with `execute: false`
2. Review the `fees` array in the response
3. Call `POST /transfers/{transferId}/execute` when ready to proceed
For automatic execution without fee review, create a transfer with
`execute: true`.
**Fee Expiration**: Fee quotes are valid for a limited time (typically
10-15 minutes from creation). The `expiresAt` field shows exactly when the
fee quote will expire. If you don't execute before this time, you'll need
to create a new transfer to get updated fees.
## Fees
Transfer fees vary by source, target, amount and transfer type:
* **Bank fees** - Traditional banking fees for depositing funds (e.g.,
$15.00 wire transfer fee)
* **Conversion fees** - Fees for exchanging between different assets
* **Network fees** - Onchain transaction costs to complete the transfer
(e.g., ETH gas fees)
All fees are disclosed upfront in the `fees` array when you create a
transfer.
## Transfer Lifecycle
When you create a transfer, it will be in one of these statuses that
determine what action you need to take:
* **`quoted`** - Transfer is ready but requires manual execution via the
`/execute` endpoint
* **`processing`** - Transfer is being executed (no action needed - poll
for completion)
* **`completed`** - Transfer completed successfully
* **`failed`** - Transfer failed (see `failureReason` for details)
## Execution Control
* **`execute: true`**: Transfer will automatically attempt to execute
* **`execute: false`**: Transfer will be created in `quoted` status and
you must call the `/execute` endpoint. Use this to obtain a fee quote or
validate a transfer destination before deciding whether to execute the
Transfer.
## Sources and Targets
* A **source** can be an Account or a Payment Method
* A **target** can be an Account, Payment Method, Onchain Address, or
Email Address
## Transfer Execution
When a transfer reaches `completed` status, it contains the final
execution details that delivered funds to the target and completion
timestamps.
## Failure Reasons
When a transfer fails, the `failureReason` field provides a human-readable
description of what went wrong.
Common failure reasons include:
* "Insufficient balance to complete this transfer."
* "The recipient address is invalid for the selected network."
* "The recipient address failed security validation checks."
* "Unable to send to this recipient."
Failure reason is only present when the transfer's status is `failed`.
- name: Wallet Webhooks
x-audience: public
x-slo-tier:
tier: ga
description: >-
The `wallet.activity.*` webhook payloads describe wallet activity,
transaction, delegation, and signing events emitted by CDP.
- name: Webhooks
x-audience: public
x-slo-tier:
tier: ga
description: >-
Subscribe to real-time events across CDP products. Monitor onchain
activity on Base mainnet, track onramp/offramp transactions, and receive
instant notifications for wallet events.
- name: x402 Facilitator
x-audience: public
x-slo-tier:
tier: beta
description: >-
The x402 payment protocol is an HTTP-based payment protocol that enables
developers running resource servers to accept payments from users using a
variety of payment methods.
For more details on the x402 payment protocol, please see the [x402
specification](https://www.x402.org/).
The x402 Facilitator APIs enable you to facilitate payments using the x402
payment protocol by exposing two APIs:
- `POST /v2/x402/verify`: Verify a payment with a supported scheme and
network.
- `POST /v2/x402/settle`: Settle a payment with a supported scheme and
network.
paths: {}
components:
securitySchemes:
apiKeyAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: >-
A JWT signed using your CDP API Key Secret, encoded in base64. Refer to
the [Generate Bearer
Token](https://docs.cdp.coinbase.com/api-reference/v2/authentication#2-generate-bearer-token)
section of our Authentication docs for information on how to generate
your Bearer Token.
````