> ## 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. # Simulate policies > Simulates policy evaluation for one operation against the project's current policies and returns the `action` the real operation would take, the rule that decided it, and the first unmet criterion of every rule that did not match. Nothing is signed, broadcast, or persisted, and gas and nonce are not populated: the transaction is evaluated as submitted. Each unmet criterion (`observed`) and each matched-rule criterion (`observations`) can include the value observed in the request, with messages and decoded arguments returned up to their documented size limits. Rate-limiting criteria are read but not consumed. `netUSDChange` criteria run transaction simulation, and pass successfully on testnets, as in the real operation. The result is a snapshot: policies, rate-limit counters, or chain state may change before a real call. A policy rejection returns `200` with `action: reject`; this endpoint never returns `policy_violation`. A criterion that cannot be evaluated for this input returns `422`. ## OpenAPI ````yaml post /v2/policy-engine/simulate 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 and for their Customers. 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. Use `GET /v2/accounts/{accountId}/products` to discover the spot products available to trade for an account (valid `productId`s to pass when creating an order). - name: Customers x-audience: public x-slo-tier: tier: beta description: >- The Customers APIs enable developers to create and manage their end-user customers. Customers can be individuals or businesses and have various capabilities like sending/receiving fiat and crypto, trading, etc. Customer information includes KYC/compliance data, verification requirements, and capability management. - 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. By default, incoming funds are credited to your account balance (`target.accountId`); you can instead route funds directly to an external onchain address by setting `target` to an onchain address (`target.address`, `target.network`, `target.asset`, and optionally `target.destinationTag`). **Metadata:** You can attach metadata to any deposit destination you create to track the purpose or source of deposits. **Example (target: account balance):** ```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" } } ``` **Example (target: onchain address):** ```json { "depositDestinationId": "depositDestination_123", "accountId": "account_456", "type": "crypto", "crypto": { "network": "base", "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e" }, "target": { "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "network": "base", "asset": "usdc" }, "status": "active", "metadata": { "customer_id": "cust_789", "reference": "order-12345" } } ``` Use the list endpoint to retrieve all deposit destinations. ## Fiat Deposit Destinations Fiat deposit destinations are currently in **private beta** and require account enablement. Contact your Coinbase representative for access. Fields and behavior may change before general availability. Fiat deposit destinations are bank accounts provisioned on your behalf that let an account receive USD deposits over a supported payment rail (for example, ACH). Each fiat deposit destination represents a single bank account at a single banking partner and is keyed by `accountType` (for example, `us_bank`). **Example:** ```json { "depositDestinationId": "depositDestination_cf4958d2-b068-6bf9-da01-eee44f157336", "accountId": "account_af2937b0-9846-4fe7-bfe9-ccc22d935114", "type": "fiat", "status": "pending", "fiat": { "accountType": "us_bank", "currency": "usd", "bankName": "Citibank N.A.", "beneficiaryName": "John Smith", "routingNumber": "987654321", "accountNumber": "123456789", "bankAddress": "399 Park Avenue, New York, NY 10022", "supportedRails": ["ach", "fedwire"] }, "target": { "accountId": "account_af2937b0-9846-4fe7-bfe9-ccc22d935114", "asset": "usdc" } } ``` Use the create endpoint to provision a fiat deposit destination for an account. - name: Disbursements x-audience: public x-slo-tier: tier: ga description: >- Send funds from a CDP account you own to a Coinbase user account or an onchain address. Use disbursements for standalone refunds, rebates, and other payouts that are not associated with a payment session. ## Lifecycle Disbursements are created with `pending` status and transition to `succeeded` or `failed`. Successful disbursements include `onchainTransactions`; failed disbursements include `error` details. Subscribe to `acceptance.disbursement.pending`, `acceptance.disbursement.succeeded`, and `acceptance.disbursement.failed` webhook events to receive status updates. - 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: Health x-audience: public x-slo-tier: tier: beta description: >- The `health.*` webhook payloads describe health status changes and maintenance window events for a CDP service or operation. - name: Mandates x-audience: public x-slo-tier: tier: beta description: >- A mandate is a durable, revocable standing authorization to debit a funding `source`. It lets a merchant debit the same source repeatedly without the customer present, which suits recurring payments and usage-based billing. A mandate does not move funds itself; a payment session authorizes against it via **Authorize a payment session with a mandate**, and capture, void, and refund then work as they do for any other session. For the full flow, spending limits, and integration options, see the [Recurring Payments guide](https://docs.cdp.coinbase.com/payments/payment-acceptance/recurring-payments). Access to the Mandates APIs requires enablement by Coinbase. **Who does what.** Approving a mandate and revoking its on-chain spending allowance are customer-initiated: the customer signs the payload, so **Approve a mandate with a wallet** and **Revoke a mandate with a wallet** are unauthenticated. Creating, canceling, and reading mandates are merchant actions authenticated with your API key. **Canceling vs. revoking.** These are independent. **Cancel a mandate** is an off-chain merchant action and does not touch the on-chain allowance (`canceledAt` is set). **Revoke a mandate with a wallet** removes the on-chain allowance (`revokedAt` is set). A `canceled` mandate can still have a live allowance until the customer revokes it. `status` records only the most recent transition; the timestamps are the durable record. - 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 #### Guest Checkout Onramp (Apple Pay & Google Pay) This use case allows you to offer an Apple Pay or Google 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 or Google 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/headless-onramp/overview) 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. #### App2App Onramp This use case lets a partner mobile app hand the user off into the Coinbase retail app to complete an onramp, then return them to the partner app. Your backend mints a short-lived challenge with a CDP API key; the mobile app submits that challenge with platform attestation (iOS App Attest or Android Play Integrity) and receives a ready-to-use onramp URL. See the Onramp (App2App) APIs for the registration and session handoff endpoints, starting with [Create Onramp Mobile Challenge](#operation/createOnrampMobileChallenge). These APIs are consumed by the CDP React Native SDK. - name: Onramp (App2App) x-audience: public x-slo-tier: tier: ga description: >- Onramp APIs used by partner mobile apps for the app-to-app handoff into the Coinbase retail app. Both flows have the same shape: your backend mints a short-lived challenge with a CDP API key (`apiKeyAuth`), then the mobile app submits that challenge back with platform attestation and no API key. **Device registration** runs once per app install, before the first handoff. Mint a challenge with `POST /v2/onramp/mobile/attestation/challenges`, then register the device key with `POST /v2/onramp/mobile/attestation/registrations`. iOS only; Android validates Play Integrity inline and has no registration step. **Session handoff** runs once per onramp transaction. Mint a challenge with `POST /v2/onramp/mobile/sessions/challenges`, then exchange it for a ready-to-use onramp URL with `POST /v2/onramp/mobile/sessions`. Never ship a CDP API key in the mobile app: mint the challenge on your backend and pass it to the device. These APIs are consumed by the CDP React Native SDK. - 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: Payment Sessions x-audience: public x-slo-tier: tier: ga description: >- Payment Sessions track the full lifecycle of a merchant payment, from authorization through capture, void, or refund. Each session records every operation and balance change across its lifecycle. **Who initiates an authorization.** A session can be authorized in four ways, split by who acts: - **Customer-initiated:** the payer authorizes at payment time by signing. Use **Authorize a payment session with a wallet** or **Authorize a payment session with x402**. These calls are unauthenticated because the payer's signature is the authorization. - **Merchant-initiated:** the merchant charges against an authorization the payer granted earlier, with the payer no longer present. Use **Authorize a payment session with a mandate** (draws on a mandate's standing spending allowance) or **Authorize a payment session with a Coinbase account** (charges a Coinbase account the payer linked over OAuth). Creating, listing, canceling, capturing, voiding, and refunding a session are merchant actions authenticated with your API key. - 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 A rule *targets* an operation when its `operation` field equals the requested operation. A rule *matches* when it targets the operation and all of its criteria are met (logical **AND**). Reject-over-accept precedence does not depend on rule order. For matching rules with the same action, the first in policy order applies. **Project-level policies** are evaluated first, followed by **account-level policies**. Within a policy, any matching `reject` rule rejects the request. Otherwise, any matching `accept` rule accepts it. If no rule in the project-level policy matches, the account-level policy is evaluated the same way, if one exists. A decision in the project-level policy is final. A `reject` rule overrides an `accept` rule only within the same policy, so an account-level `reject` rule does not override a matching project-level `accept` rule. If neither policy makes a decision, the request is accepted when no rule in either policy targets the operation, and rejected when at least one rule targets it. For example, this project-level policy accepts `signEvmTransaction` requests up to 2000000000000000000 wei, but rejects any request to `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`. A request to that address for 1 ETH matches both rules and is rejected regardless of their order. ```json { "description": "Project-level policy", "scope": "project", "rules": [ { "action": "accept", "operation": "signEvmTransaction", "criteria": [ { "type": "ethValue", "ethValue": "2000000000000000000", "operator": "<=" } ] }, { "action": "reject", "operation": "signEvmTransaction", "criteria": [ { "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: Top-Up Links x-audience: public x-slo-tier: tier: beta description: >- A Top-Up Link is a shareable hosted URL that lets a payer add funds to their balance. Create a link with **Create a Top-Up Link** and share the returned `topUpUrl` only with the intended payer. The URL identifies the link but does not authorize a top-up; the payer must authenticate and approve it. ## Lifecycle The resource is immutable once created. The link expires 24 hours after creation and funds a single purchase: once a purchase succeeds, the link is spent and cannot be used again. A purchase that fails does not consume the link, so the payer can retry until it expires. A link is not bound to a specific payer. There is no GET: the create response and the `acceptance.top_up_link.created` event are the full resource. ## Amounts - `topUpAmount` is the merchant's fixed suggested net amount for the link's single purchase. The payer can change it in the hosted flow. - `orderTotalAmount` is optional presentation context. It does not replace, change, or cap `topUpAmount`. - The funds-added event reports the actual net amount credited by the purchase that spent the link. It is never cumulative. ## Merchant name Supply `customerDisplay.merchantName` to choose the merchant name for a link's hosted page. The supplied value is limited to 128 Unicode code points before surrounding whitespace is removed. If the name is omitted or empty after trimming, the entity's profile name is used. The create response and creation webhook return the resolved name stored on the immutable link. Later profile changes do not change that name. ## Redirects When `redirectUrl` is supplied, its origin must exactly match an allowed origin. The query key `toppedUpAmount` is reserved because the hosted flow appends it before redirecting the payer. The redirect does not represent success or failure; `toppedUpAmount` may be zero, a partial amount, or the full `topUpAmount`. ## Webhooks Subscribers receive `acceptance.top_up_link.created` when the link is created and `acceptance.top_up_link.funds_added` when a purchase credits funds through the link. Because a link funds a single purchase, it produces at most one funds-added event; deliveries can repeat, so deduplicate on `eventId`. - 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: /v2/policy-engine/simulate: post: tags: - Policy Engine summary: Simulate policies description: >- Simulates policy evaluation for one operation against the project's current policies and returns the `action` the real operation would take, the rule that decided it, and the first unmet criterion of every rule that did not match. Nothing is signed, broadcast, or persisted, and gas and nonce are not populated: the transaction is evaluated as submitted. Each unmet criterion (`observed`) and each matched-rule criterion (`observations`) can include the value observed in the request, with messages and decoded arguments returned up to their documented size limits. Rate-limiting criteria are read but not consumed. `netUSDChange` criteria run transaction simulation, and pass successfully on testnets, as in the real operation. The result is a snapshot: policies, rate-limit counters, or chain state may change before a real call. A policy rejection returns `200` with `action: reject`; this endpoint never returns `policy_violation`. A criterion that cannot be evaluated for this input returns `422`. operationId: simulatePolicies requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/SimulatePoliciesRequest' examples: sign_evm_transaction: value: operation: signEvmTransaction address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' transaction: >- 0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0 responses: '200': description: Policy simulation result. content: application/json: schema: $ref: '#/components/schemas/PolicySimulationResult' examples: rule_rejected: value: action: reject reason: rule_rejected matchedRule: policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 1 rule: action: reject operation: signEvmTransaction criteria: - type: ethValue ethValue: '1000000000000000000' operator: '>' observations: - type: ethValue ethValue: '2500000000000000000' unmatchedRules: - policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 0 criterionIndex: 1 criterion: type: evmAddress addresses: - '0x000000000000000000000000000000000000dEaD' operator: in observed: type: evmAddress address: '0x1234567890123456789012345678901234567890' evaluatedPolicies: - id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' no_rule_matched: value: action: reject reason: no_rule_matched unmatchedRules: - policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 0 criterionIndex: 0 criterion: type: ethValue ethValue: '1000' operator: <= observed: type: ethValue ethValue: '1000000000000000' - policy: id: 223e4567-e89b-12d3-a456-426614174000 scope: account updatedAt: '2026-09-02T12:00:00Z' ruleIndex: 2 criterionIndex: 1 criterion: type: evmNetwork networks: - base operator: in observed: type: evmNetwork network: base-sepolia chainId: 84532 evaluatedPolicies: - id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' - id: 223e4567-e89b-12d3-a456-426614174000 scope: account updatedAt: '2026-09-02T12:00:00Z' rule_accepted: value: action: accept reason: rule_accepted matchedRule: policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 0 rule: action: accept operation: signEvmHash criteria: [] observations: [] unmatchedRules: [] evaluatedPolicies: - id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' rate_limit_exceeded: summary: >- An ACCEPT rule is unmatched because its rateLimiting criterion exceeds maxCount. value: action: reject reason: no_rule_matched unmatchedRules: - policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 0 criterionIndex: 0 criterion: type: rateLimiting window: 24h maxCount: 10 observed: type: rateLimiting scope: project usage: type: count windowCount: 10 pendingCount: 0 evaluatedPolicies: - id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' no_rule_for_operation: value: action: accept reason: no_rule_for_operation unmatchedRules: [] evaluatedPolicies: - id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' '400': description: Invalid simulation request. content: application/json: schema: $ref: '#/components/schemas/Error' examples: invalid_request: value: errorType: invalid_request errorMessage: An operation and its required inputs must be provided. malformed_transaction: value: errorType: malformed_transaction errorMessage: Malformed unsigned transaction. '401': $ref: '#/components/responses/UnauthorizedError' '404': description: Account, end user, or prepared user operation not found. content: application/json: schema: $ref: '#/components/schemas/Error' examples: not_found: value: errorType: not_found errorMessage: Account with the given address not found. end_user_not_found: value: errorType: not_found errorMessage: End user not found. user_operation_not_found: value: errorType: not_found errorMessage: User operation not found. '422': description: >- A criterion could not be evaluated for this input, so the real operation would fail closed. content: application/json: schema: $ref: '#/components/schemas/Error' examples: transaction_simulation_failed: value: errorType: transaction_simulation_failed errorMessage: >- Transaction simulation failed while evaluating the netUSDChange criterion at /rules/0/criteria/0 of policy 123e4567-e89b-12d3-a456-426614174000. '429': $ref: '#/components/responses/RateLimitExceeded' '500': $ref: '#/components/responses/InternalServerError' '502': $ref: '#/components/responses/BadGatewayError' '503': $ref: '#/components/responses/ServiceUnavailableError' security: - apiKeyAuth: [] components: schemas: SimulatePoliciesRequest: description: >- Inputs for one operation, without signing credentials. `operation` is the policy rule operation name (for example `signSolTransaction`), not the HTTP operation ID (`signSolanaTransaction`). oneOf: - $ref: '#/components/schemas/SignEvmTransactionSimulationInput' - $ref: '#/components/schemas/SendEvmTransactionSimulationInput' - $ref: '#/components/schemas/SignEvmHashSimulationInput' - $ref: '#/components/schemas/SignEvmMessageSimulationInput' - $ref: '#/components/schemas/SignEvmTypedDataSimulationInput' - $ref: '#/components/schemas/PrepareUserOperationSimulationInput' - $ref: '#/components/schemas/SendUserOperationSimulationInput' - $ref: '#/components/schemas/SignSolTransactionSimulationInput' - $ref: '#/components/schemas/SendSolTransactionSimulationInput' - $ref: '#/components/schemas/SignSolMessageSimulationInput' - $ref: '#/components/schemas/SignEndUserEvmHashSimulationInput' - $ref: '#/components/schemas/SignEndUserEvmTransactionSimulationInput' - $ref: '#/components/schemas/SendEndUserEvmTransactionSimulationInput' - $ref: '#/components/schemas/SignEndUserEvmMessageSimulationInput' - $ref: '#/components/schemas/SignEndUserEvmTypedDataSimulationInput' - $ref: '#/components/schemas/SendEndUserOperationSimulationInput' - $ref: '#/components/schemas/SignEndUserSolTransactionSimulationInput' - $ref: '#/components/schemas/SendEndUserSolTransactionSimulationInput' - $ref: '#/components/schemas/SignEndUserSolMessageSimulationInput' - $ref: '#/components/schemas/SendEndUserEvmAssetSimulationInput' - $ref: '#/components/schemas/SendEndUserSolAssetSimulationInput' - $ref: '#/components/schemas/CreateEndUserEvmSwapSimulationInput' discriminator: propertyName: operation mapping: signEvmTransaction: '#/components/schemas/SignEvmTransactionSimulationInput' sendEvmTransaction: '#/components/schemas/SendEvmTransactionSimulationInput' signEvmHash: '#/components/schemas/SignEvmHashSimulationInput' signEvmMessage: '#/components/schemas/SignEvmMessageSimulationInput' signEvmTypedData: '#/components/schemas/SignEvmTypedDataSimulationInput' prepareUserOperation: '#/components/schemas/PrepareUserOperationSimulationInput' sendUserOperation: '#/components/schemas/SendUserOperationSimulationInput' signSolTransaction: '#/components/schemas/SignSolTransactionSimulationInput' sendSolTransaction: '#/components/schemas/SendSolTransactionSimulationInput' signSolMessage: '#/components/schemas/SignSolMessageSimulationInput' signEndUserEvmHash: '#/components/schemas/SignEndUserEvmHashSimulationInput' signEndUserEvmTransaction: '#/components/schemas/SignEndUserEvmTransactionSimulationInput' sendEndUserEvmTransaction: '#/components/schemas/SendEndUserEvmTransactionSimulationInput' signEndUserEvmMessage: '#/components/schemas/SignEndUserEvmMessageSimulationInput' signEndUserEvmTypedData: '#/components/schemas/SignEndUserEvmTypedDataSimulationInput' sendEndUserOperation: '#/components/schemas/SendEndUserOperationSimulationInput' signEndUserSolTransaction: '#/components/schemas/SignEndUserSolTransactionSimulationInput' sendEndUserSolTransaction: '#/components/schemas/SendEndUserSolTransactionSimulationInput' signEndUserSolMessage: '#/components/schemas/SignEndUserSolMessageSimulationInput' sendEndUserEvmAsset: '#/components/schemas/SendEndUserEvmAssetSimulationInput' sendEndUserSolAsset: '#/components/schemas/SendEndUserSolAssetSimulationInput' createEndUserEvmSwap: '#/components/schemas/CreateEndUserEvmSwapSimulationInput' PolicySimulationResult: type: object description: >- The action the real operation would take and why. `matchedRule` is present exactly when `reason` is `rule_accepted` or `rule_rejected`. example: action: reject reason: no_rule_matched unmatchedRules: - policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 0 criterionIndex: 0 criterion: type: ethValue ethValue: '1' operator: <= observed: type: ethValue ethValue: '500000000000000000' evaluatedPolicies: - id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' properties: action: type: string description: Whether the real operation would be accepted or rejected. enum: - accept - reject x-go-type: string example: reject reason: type: string description: >- Why the operation got its `action`. Each value implies exactly one `action`. Within a policy, a matching `reject` rule overrides any matching `accept` rule, regardless of rule order. With `accept`: `rule_accepted` means `matchedRule` matched all of its criteria, its action is `accept`, and no `reject` rule in the same policy matched. `no_rule_for_operation` means no rule targeted the operation, so it was accepted by default. With `reject`: `rule_rejected` means `matchedRule` matched all of its criteria and its action is `reject`, so the rejection is caused by the entire rule. `no_rule_matched` means at least one rule targeted the operation but none matched, so it was rejected by default; `unmatchedRules` shows the criterion that disqualified each one. enum: - rule_accepted - rule_rejected - no_rule_matched - no_rule_for_operation example: no_rule_matched matchedRule: $ref: '#/components/schemas/MatchedPolicyRule' unmatchedRules: type: array description: >- Rules targeting the operation that were evaluated and did not match. Within a policy, `reject` rules are evaluated before `accept` rules, and evaluation stops at `matchedRule`. Rules that were not evaluated are omitted. When there is no `matchedRule`, every rule that targeted the operation appears here. Among matching rules with the same action, the first in policy order is `matchedRule`. items: $ref: '#/components/schemas/UnmatchedPolicyRule' evaluatedPolicies: type: array description: >- Policies iterated, in order: the project policy, then the account policy. Evaluation stops at the policy containing `matchedRule`. End-user operations consult only the project policy. items: $ref: '#/components/schemas/EvaluatedPolicy' evaluatedUnit: $ref: '#/components/schemas/EvaluatedUnit' required: - action - reason - unmatchedRules - evaluatedPolicies Error: description: >- An error response including the code for the type of error and a human-readable message describing the error. type: object properties: errorType: $ref: '#/components/schemas/ErrorType' errorMessage: description: The error message. type: string example: Unable to create EVM account correlationId: description: >- A unique identifier for the request that generated the error. This can be used to help debug issues with the API. type: string example: 41deb8d59a9dc9a7-IAD errorLink: allOf: - $ref: '#/components/schemas/Url' description: A link to the corresponding error documentation. example: >- https://docs.cdp.coinbase.com/api-reference/v2/errors#invalid-request unauthorizedCapabilities: description: > The capability code(s) that were not authorized for the customer on this request. Present only when `errorType` is `customer_not_authorized`; absent for every other error type. Use this list to render onboarding UX for the listed capabilities, or fetch `GET /v2/customers/{customerId}` and inspect each entry's `status` / `requirements` to discover what (if anything) can be submitted to resolve the block. type: array items: $ref: '#/components/schemas/CapabilityName' x-error-types: - customer_not_authorized required: - errorType - errorMessage example: errorType: invalid_request errorMessage: Invalid request. correlationId: 41deb8d59a9dc9a7-IAD errorLink: https://docs.cdp.coinbase.com/api-reference/v2/errors#invalid-request SignEvmTransactionSimulationInput: type: object title: SignEvmTransactionSimulationInput example: operation: signEvmTransaction address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' transaction: >- 0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0 properties: operation: type: string description: Rule operation to simulate. enum: - signEvmTransaction x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed address of the EVM account. transaction: type: string description: >- The RLP-encoded transaction to evaluate, as a 0x-prefixed hex string. example: >- 0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0 required: - operation - address - transaction additionalProperties: false SendEvmTransactionSimulationInput: type: object title: SendEvmTransactionSimulationInput example: operation: sendEvmTransaction address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' network: base transaction: >- 0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0 properties: operation: type: string description: Rule operation to simulate. enum: - sendEvmTransaction x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed address of the EVM account. transaction: type: string description: >- The RLP-encoded transaction to evaluate, as a 0x-prefixed hex string. network: type: string description: The network to send the transaction to. enum: - base - base-sepolia - ethereum - ethereum-sepolia - avalanche - polygon - optimism - arbitrum - arbitrum-sepolia - world - world-sepolia example: base-sepolia required: - operation - address - transaction - network additionalProperties: false SignEvmHashSimulationInput: type: object title: SignEvmHashSimulationInput example: operation: signEvmHash address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' hash: '0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef' properties: operation: type: string description: Rule operation to simulate. enum: - signEvmHash x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed address of the EVM account. hash: type: string description: The arbitrary 32 byte hash to evaluate. required: - operation - address - hash additionalProperties: false SignEvmMessageSimulationInput: type: object title: SignEvmMessageSimulationInput example: operation: signEvmMessage address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' message: Hello, world! properties: operation: type: string description: Rule operation to simulate. enum: - signEvmMessage x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed address of the EVM account. message: type: string description: The message to evaluate. required: - operation - address - message additionalProperties: false SignEvmTypedDataSimulationInput: type: object title: SignEvmTypedDataSimulationInput example: operation: signEvmTypedData address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' domain: name: Permit2 chainId: 1 verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' types: EIP712Domain: - name: name type: string - name: chainId type: uint256 - name: verifyingContract type: address PermitTransferFrom: - name: permitted type: TokenPermissions - name: spender type: address - name: nonce type: uint256 - name: deadline type: uint256 TokenPermissions: - name: token type: address - name: amount type: uint256 primaryType: PermitTransferFrom message: permitted: token: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' amount: '1000000' spender: '0x1111111254EEB25477B68fb85Ed929f73A960582' nonce: '0' deadline: '1716239020' properties: operation: type: string description: Rule operation to simulate. enum: - signEvmTypedData x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed address of the EVM account. domain: $ref: '#/components/schemas/EIP712Domain' types: $ref: '#/components/schemas/EIP712Types' primaryType: type: string description: >- The primary type of the message. This is the name of the struct in the `types` object that is the root of the message. message: type: object description: >- The message to evaluate. The structure of this message must match the `primaryType` struct in the `types` object. required: - operation - address - domain - types - primaryType - message additionalProperties: false PrepareUserOperationSimulationInput: type: object title: PrepareUserOperationSimulationInput example: operation: prepareUserOperation address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' network: base calls: [] properties: operation: type: string description: Rule operation to simulate. enum: - prepareUserOperation x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The Smart Account address. network: $ref: '#/components/schemas/EvmUserOperationNetwork' calls: type: array description: The list of calls to make from the Smart Account. items: $ref: '#/components/schemas/EvmCall' paymasterUrl: allOf: - $ref: '#/components/schemas/Url' description: The URL of the paymaster to use for the user operation. paymasterContext: $ref: '#/components/schemas/PaymasterContext' dataSuffix: type: string pattern: ^0x[0-9a-fA-F]+$ description: >- The EIP-8021 data suffix (hex-encoded) that enables transaction attribution for the user operation. required: - operation - address - network - calls additionalProperties: false SendUserOperationSimulationInput: type: object title: SendUserOperationSimulationInput example: operation: sendUserOperation address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' userOpHash: '0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef' properties: operation: type: string description: Rule operation to simulate. enum: - sendUserOperation x-go-type: string address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The Smart Account address. userOpHash: type: string pattern: ^0x[0-9a-fA-F]{64}$ description: The hash of the prepared user operation. required: - operation - address - userOpHash additionalProperties: false SignSolTransactionSimulationInput: type: object title: SignSolTransactionSimulationInput example: operation: signSolTransaction address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT transaction: >- AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8CBgMBAQAAAAIBAwQAAAAABgIAAAAAAAYDBQEBAAAGBAgAAAAABgUAAAAA6AMAAAAAAAAGBgUBAQEBBgcEAQAAAAYICgMBAQIDBgkCBgAAAAYKAwABAQEGCwMGAQEBBgwDAAABAQAAAAA= properties: operation: type: string description: Rule operation to simulate. enum: - signSolTransaction x-go-type: string address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The base58 encoded address of the Solana account. network: type: string description: >- The Solana network the transaction targets. Required when using versioned transactions that reference address lookup tables, since resolving those tables requires querying a specific network. Optional otherwise. enum: - solana - solana-devnet example: solana-devnet transaction: type: string description: The base64 encoded transaction to evaluate. required: - operation - address - transaction additionalProperties: false SendSolTransactionSimulationInput: type: object title: SendSolTransactionSimulationInput example: operation: sendSolTransaction network: solana-devnet transaction: >- AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8CBgMBAQAAAAIBAwQAAAAABgIAAAAAAAYDBQEBAAAGBAgUAAAAA6AMAAAAAAAAGBgUBAQEBBgcEAQAAAAYICgMBAQIDBgkCBgAAAAYKAwABAQEGCwMGAQEBBgwDAAABAQAAAAA= properties: operation: type: string description: Rule operation to simulate. enum: - sendSolTransaction x-go-type: string network: type: string description: The Solana network to send the transaction to. enum: - solana - solana-devnet example: solana-devnet transaction: type: string description: >- The base64 encoded transaction to evaluate. This transaction can contain multiple instructions for native Solana batching. useCdpSponsor: type: boolean description: >- Whether transaction fees should be sponsored by CDP. When true, CDP sponsors the transaction fees on behalf of the server wallet. When false, the server wallet is responsible for paying the transaction fees. required: - operation - network - transaction additionalProperties: false SignSolMessageSimulationInput: type: object title: SignSolMessageSimulationInput example: operation: signSolMessage address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT message: Hello, world! properties: operation: type: string description: Rule operation to simulate. enum: - signSolMessage x-go-type: string address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The base58 encoded address of the Solana account. message: type: string description: The arbitrary message to evaluate. encoding: type: string description: >- The encoding of the message. Use `utf8` to evaluate the literal UTF-8 bytes of the message, or `base64` to decode an RFC 4648 standard Base64 string before evaluating. Base64 input must use the standard `+` and `/` alphabet with `=` padding where required. If omitted, the message is interpreted as UTF-8. enum: - utf8 - base64 x-go-type: string example: utf8 required: - operation - address - message additionalProperties: false SignEndUserEvmHashSimulationInput: type: object title: SignEndUserEvmHashSimulationInput example: operation: signEndUserEvmHash userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' hash: '0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef' properties: operation: type: string description: Rule operation to simulate. enum: - signEndUserEvmHash x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed address of the EVM account belonging to the end user. hash: type: string description: The arbitrary 32 byte hash to evaluate. required: - operation - userId - address - hash additionalProperties: false SignEndUserEvmTransactionSimulationInput: type: object title: SignEndUserEvmTransactionSimulationInput example: operation: signEndUserEvmTransaction userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' transaction: >- 0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0 properties: operation: type: string description: Rule operation to simulate. enum: - signEndUserEvmTransaction x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed address of the EVM account belonging to the end user. transaction: type: string description: >- The RLP-encoded transaction to evaluate, as a 0x-prefixed hex string. required: - operation - userId - address - transaction additionalProperties: false SendEndUserEvmTransactionSimulationInput: type: object title: SendEndUserEvmTransactionSimulationInput example: operation: sendEndUserEvmTransaction userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' network: base transaction: >- 0x02f082210580843b9aca00847735940082520894123456789012345678901234567890123456789087038d7ea4c6800080c0 properties: operation: type: string description: Rule operation to simulate. enum: - sendEndUserEvmTransaction x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed address of the EVM account belonging to the end user. network: type: string description: The network to send the transaction to. enum: - base - base-sepolia - ethereum - ethereum-sepolia - avalanche - polygon - optimism - arbitrum - arbitrum-sepolia - world - world-sepolia example: base-sepolia transaction: type: string description: >- The RLP-encoded transaction to evaluate, as a 0x-prefixed hex string. required: - operation - userId - address - network - transaction additionalProperties: false SignEndUserEvmMessageSimulationInput: type: object title: SignEndUserEvmMessageSimulationInput example: operation: signEndUserEvmMessage userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' message: Hello, world! properties: operation: type: string description: Rule operation to simulate. enum: - signEndUserEvmMessage x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed address of the EVM account belonging to the end user. message: type: string description: The message to evaluate. required: - operation - userId - address - message additionalProperties: false SignEndUserEvmTypedDataSimulationInput: type: object title: SignEndUserEvmTypedDataSimulationInput example: operation: signEndUserEvmTypedData userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' typedData: types: {} primaryType: Mail domain: {} message: {} properties: operation: type: string description: Rule operation to simulate. enum: - signEndUserEvmTypedData x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed address of the EVM account belonging to the end user. typedData: $ref: '#/components/schemas/EIP712Message' required: - operation - userId - address - typedData additionalProperties: false SendEndUserOperationSimulationInput: type: object title: SendEndUserOperationSimulationInput example: operation: sendEndUserOperation userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' network: base calls: [] useCdpPaymaster: false properties: operation: type: string description: Rule operation to simulate. enum: - sendEndUserOperation x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The Smart Account address. network: $ref: '#/components/schemas/EvmUserOperationNetwork' calls: type: array description: The list of calls to make from the Smart Account. items: $ref: '#/components/schemas/EvmCall' useCdpPaymaster: type: boolean description: Whether to use the CDP Paymaster for the user operation. example: true paymasterUrl: allOf: - $ref: '#/components/schemas/Url' description: >- The URL of the paymaster to use for the user operation. If using the CDP Paymaster, use the useCdpPaymaster option. paymasterContext: $ref: '#/components/schemas/PaymasterContext' dataSuffix: type: string pattern: ^0x[0-9a-fA-F]+$ description: >- The EIP-8021 data suffix (hex-encoded) that enables transaction attribution for the user operation. required: - operation - userId - address - network - calls - useCdpPaymaster additionalProperties: false SignEndUserSolTransactionSimulationInput: type: object title: SignEndUserSolTransactionSimulationInput example: operation: signEndUserSolTransaction userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT transaction: >- AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8CBgMBAQAAAAIBAwQAAAAABgIAAAAAAAYDBQEBAAAGBAgUAAAAA6AMAAAAAAAAGBgUBAQEBBgcEAQAAAAYICgMBAQIDBgkCBgAAAAYKAwABAQEGCwMGAQEBBgwDAAABAQAAAAA= properties: operation: type: string description: Rule operation to simulate. enum: - signEndUserSolTransaction x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The base58 encoded address of the Solana account belonging to the end user. network: type: string description: >- The Solana network the transaction targets. Required when using versioned transactions that reference address lookup tables, since resolving those tables requires querying a specific network. Optional otherwise. enum: - solana - solana-devnet example: solana-devnet transaction: type: string description: The base64 encoded transaction to evaluate. required: - operation - userId - address - transaction additionalProperties: false SendEndUserSolTransactionSimulationInput: type: object title: SendEndUserSolTransactionSimulationInput example: operation: sendEndUserSolTransaction userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT network: solana-devnet transaction: >- AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8CBgMBAQAAAAIBAwQAAAAABgIAAAAAAAYDBQEBAAAGBAgUAAAAA6AMAAAAAAAAGBgUBAQEBBgcEAQAAAAYICgMBAQIDBgkCBgAAAAYKAwABAQEGCwMGAQEBBgwDAAABAQAAAAA= properties: operation: type: string description: Rule operation to simulate. enum: - sendEndUserSolTransaction x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The base58 encoded address of the Solana account belonging to the end user. network: type: string description: The Solana network to send the transaction to. enum: - solana - solana-devnet example: solana-devnet transaction: type: string description: >- The base64 encoded transaction to evaluate. This transaction can contain multiple instructions for native Solana batching. useCdpSponsor: type: boolean description: >- Whether transaction fees should be sponsored by CDP. When true, CDP sponsors the transaction fees on behalf of the end user. When false, the end user is responsible for paying the transaction fees. required: - operation - userId - address - network - transaction additionalProperties: false SignEndUserSolMessageSimulationInput: type: object title: SignEndUserSolMessageSimulationInput example: operation: signEndUserSolMessage userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT message: SGVsbG8sIHdvcmxk properties: operation: type: string description: Rule operation to simulate. enum: - signEndUserSolMessage x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The base58 encoded address of the Solana account belonging to the end user. message: type: string description: The base64 encoded arbitrary message to evaluate. required: - operation - userId - address - message additionalProperties: false SendEndUserEvmAssetSimulationInput: type: object title: SendEndUserEvmAssetSimulationInput example: operation: sendEndUserEvmAsset userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' asset: usdc to: '0x1234567890123456789012345678901234567890' amount: '1.50' network: base properties: operation: type: string description: Rule operation to simulate. enum: - sendEndUserEvmAsset x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: allOf: - $ref: '#/components/schemas/BlockchainAddress' pattern: ^0x[0-9a-fA-F]{40}$ description: The EVM account address to send USDC from. asset: allOf: - $ref: '#/components/schemas/Asset' enum: - usdc description: The asset to send. to: allOf: - $ref: '#/components/schemas/BlockchainAddress' pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed address of the recipient. amount: type: string minLength: 1 maxLength: 32 description: >- The amount of USDC to send as a decimal string (e.g. "1.5" or "25.50"). network: type: string description: The EVM network to send USDC on. enum: - base - base-sepolia - ethereum - ethereum-sepolia - avalanche - polygon - optimism - arbitrum - arbitrum-sepolia - world - world-sepolia example: base-sepolia useCdpPaymaster: type: boolean description: >- Whether to use CDP Paymaster for gas sponsorship on Smart Accounts. Ignored for EOAs; cannot be used with paymasterUrl. paymasterUrl: allOf: - $ref: '#/components/schemas/Url' description: >- Optional custom Paymaster URL for gas sponsorship on Smart Accounts. Cannot be used with useCdpPaymaster. paymasterContext: $ref: '#/components/schemas/PaymasterContext' required: - operation - userId - address - asset - to - amount - network additionalProperties: false SendEndUserSolAssetSimulationInput: type: object title: SendEndUserSolAssetSimulationInput example: operation: sendEndUserSolAsset userId: e051beeb-7163-4527-a5b6-35e301529ff2 address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT asset: usdc to: ExXhNkgYf6efh7YyqDRVxPZuzafobao1A74drUdp8trd amount: '1.50' network: solana-devnet properties: operation: type: string description: Rule operation to simulate. enum: - sendEndUserSolAsset x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. address: allOf: - $ref: '#/components/schemas/BlockchainAddress' pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The Solana account address to send USDC from. asset: allOf: - $ref: '#/components/schemas/Asset' enum: - usdc description: The asset to send. to: allOf: - $ref: '#/components/schemas/BlockchainAddress' pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The base58 encoded address of the recipient. amount: type: string minLength: 1 maxLength: 32 description: >- The amount of USDC to send as a decimal string (e.g. "1.5" or "25.50"). network: type: string description: The Solana network to send USDC on. enum: - solana - solana-devnet example: solana-devnet createRecipientAta: type: boolean description: >- Whether to automatically create an Associated Token Account (ATA) for the recipient if it doesn't exist. When true, the sender pays the rent-exempt minimum to create the recipient's USDC ATA. When false, the transaction will fail if the recipient doesn't have a USDC ATA. useCdpSponsor: type: boolean description: >- Whether transaction fees should be sponsored by CDP. When true, CDP sponsors the transaction fees on behalf of the end user. When false, the end user is responsible for paying the transaction fees. required: - operation - userId - address - asset - to - amount - network additionalProperties: false CreateEndUserEvmSwapSimulationInput: type: object title: CreateEndUserEvmSwapSimulationInput example: operation: createEndUserEvmSwap userId: e051beeb-7163-4527-a5b6-35e301529ff2 taker: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' network: base fromToken: '0x4200000000000000000000000000000000000006' toToken: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913' fromAmount: '100000000000000000' properties: operation: type: string description: Rule operation to simulate. enum: - createEndUserEvmSwap x-go-type: string userId: type: string pattern: ^[a-zA-Z0-9-]{1,100}$ description: The ID of the end user. taker: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The end user's EVM address (EOA or smart account) that will send fromToken. Must belong to this end user. network: $ref: '#/components/schemas/EvmSwapsNetwork' fromToken: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed contract address of the token to sell. toToken: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The 0x-prefixed contract address of the token to buy. fromAmount: type: string pattern: ^[1-9]\d*$ description: >- The amount of `fromToken` to sell, in atomic units. For example, `100000000000000000` when selling WETH equates to 0.1 WETH. slippageBps: type: integer minimum: 0 maximum: 10000 default: 100 description: >- Maximum slippage in basis points (100 = 1%). Sets the minimum output floor baked into the transaction calldata. If the onchain price moves beyond this tolerance, the transaction reverts. Default is 100 (1%). useCdpPaymaster: type: boolean description: Whether to use the CDP Paymaster for the user operation. paymasterUrl: allOf: - $ref: '#/components/schemas/Url' description: >- The URL of the paymaster to use for the user operation. If using the CDP Paymaster, use the useCdpPaymaster option. required: - operation - userId - taker - network - fromToken - toToken - fromAmount additionalProperties: false MatchedPolicyRule: type: object description: The rule whose action decided the evaluation. example: policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 1 rule: action: reject operation: signEvmTransaction criteria: - type: ethValue ethValue: '1000000000000000000' operator: '>' observations: - type: ethValue ethValue: '2500000000000000000' properties: policy: $ref: '#/components/schemas/EvaluatedPolicy' ruleIndex: type: integer minimum: 0 description: Zero-based index into the policy's `rules`. example: 1 rule: allOf: - $ref: '#/components/schemas/Rule' description: >- The full rule as defined at the evaluated policy version (`policy.updatedAt`). observations: type: array description: >- The value each criterion was compared against, index-aligned with `rule.criteria`: `observations[i]` belongs to `rule.criteria[i]` and has the same `type`. Either every criterion has an entry or the field is omitted. Empty when the rule has no criteria. items: $ref: '#/components/schemas/PolicyCriterionObservation' required: - policy - ruleIndex - rule UnmatchedPolicyRule: type: object description: >- A rule that targeted the operation but did not match. Criteria are evaluated in order and evaluation stops at the first unmet one, so later criteria were not evaluated. `observed` is present when the service captured the value `criterion` was compared against. example: policy: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' ruleIndex: 0 criterionIndex: 1 criterion: type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in observed: type: evmAddress address: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913' properties: policy: $ref: '#/components/schemas/EvaluatedPolicy' ruleIndex: type: integer minimum: 0 description: Zero-based index into the policy's `rules`. example: 0 criterionIndex: type: integer minimum: 0 description: >- Zero-based index into the rule's `criteria` of the first unmet criterion. example: 1 criterion: $ref: '#/components/schemas/PolicyCriterion' observed: $ref: '#/components/schemas/PolicyCriterionObservation' required: - policy - ruleIndex - criterionIndex - criterion EvaluatedPolicy: type: object description: A policy consulted during evaluation, at the version evaluated. example: id: 123e4567-e89b-12d3-a456-426614174000 scope: project updatedAt: '2026-09-01T12:00:00Z' properties: id: type: string description: The ID of the policy. pattern: >- ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$ example: 123e4567-e89b-12d3-a456-426614174000 scope: type: string description: The scope of the policy. enum: - project - account x-go-type: PolicyScope example: project updatedAt: type: string format: date-time description: >- The version of the policy evaluated. Rule and criterion indices refer to this version. example: '2026-09-01T12:00:00Z' required: - id - scope - updatedAt EvaluatedUnit: type: object title: EvaluatedUnit description: >- The unit this result describes. Present only when the operation was evaluated as more than one unit: one unit per call for user operations, and one unit per signing account for Solana transactions. Each unit is evaluated against the policies separately, and `matchedRule`, `unmatchedRules`, `evaluatedPolicies`, and every observed value describe this unit only. When `action` is `reject`, this is the first unit that was rejected. When `action` is `accept`, every unit was accepted and this is the last one. example: index: 2 count: 3 properties: index: type: integer minimum: 0 description: >- Zero-based index of the unit. For user operations, this is the index into the operation's `calls`. example: 2 count: type: integer minimum: 2 description: The number of units the operation was split into. example: 3 address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The Solana signing account of the unit. Omitted for user operations. example: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT required: - index - count additionalProperties: false ErrorType: description: >- The code that indicates the type of error that occurred. These error codes can be used to determine how to handle the error. type: string example: invalid_request enum: - already_exists - authorization_expired - bad_gateway - capture_expired - client_closed_request - customer_not_authorized - endpoint_unavailable - faucet_limit_exceeded - forbidden - idempotency_error - incompatible_event_types - internal_server_error - invalid_request - invalid_webhook_headers - invalid_webhook_url - invalid_sql_query - invalid_signature - malformed_transaction - not_found - operation_in_progress - payment_method_required - payment_required - settlement_failed - rate_limit_exceeded - request_canceled - service_unavailable - subscription_limit_exceeded - timed_out - unauthorized - unsupported_tos_language - policy_violation - policy_in_use - account_limit_exceeded - network_not_tradable - guest_permission_denied - guest_region_forbidden - guest_transaction_limit - guest_transaction_count - phone_number_verification_expired - otp_verification_code_invalid - otp_verification_destination_mismatch - otp_verification_expired - otp_verification_invalid - otp_verification_not_found - otp_verification_required - document_verification_failed - recipient_allowlist_violation - recipient_allowlist_pending - refund_expired - travel_rules_recipient_violation - source_account_invalid - target_account_invalid - source_account_not_found - target_account_not_found - source_asset_not_supported - target_asset_not_supported - target_email_invalid - target_onchain_address_invalid - transfer_amount_invalid - transfer_asset_not_supported - transfer_quote_expired - insufficient_balance - metadata_too_many_entries - metadata_key_too_long - metadata_value_too_long - travel_rules_field_missing - asset_mismatch - mfa_already_enrolled - mfa_invalid_code - mfa_challenge_not_found - mfa_flow_expired - mfa_required - mfa_not_enrolled - order_quote_expired - order_already_filled - order_already_canceled - account_not_ready - insufficient_liquidity - insufficient_allowance - transaction_simulation_failed - delegation_not_found - delegation_expired - delegation_revoked - delegation_not_authorized - delegation_not_enabled - network_mismatch - already_enabled - payment_session_already_canceled - payment_session_already_authorized - payment_session_action_pending - no_capturable_balance - no_voidable_balance - no_refundable_balance - entity_not_configured_for_payment_acceptance - entity_not_configured_for_top_up - daily_transaction_limit_exceeded - daily_amount_limit_exceeded - stale_attestation - moderation_rejected - mandate_action_pending - mandate_policy_violation - mandate_expired - mandate_canceled - mandate_revoked - mandate_invalid_status x-error-instructions: incompatible_event_types: >- The `eventTypes` in a webhook subscription belong to different scopes that cannot be combined in a single subscription. **Steps to resolve:** 1. Group `eventTypes` by compatible label requirements. 2. Create a separate webhook subscription for each group. invalid_webhook_headers: >- One or more custom webhook target headers have invalid names or values, duplicate names with different capitalization, or names reserved for delivery metadata and HTTP routing. **Steps to resolve:** 1. Check `target.headers` for invalid names, values, and case-insensitive duplicates. 2. Remove blocked headers such as `Cookie`, `Host`, and `X-Webhook-*`, then retry. invalid_webhook_url: >- The webhook target URL did not pass scheme, host, address, or endpoint checks. **Steps to resolve:** 1. Verify `target.url` uses HTTPS and responds to HEAD requests with a 200. 2. Confirm the endpoint is reachable and responds without a server error, then retry. subscription_limit_exceeded: >- The project or entity has reached the maximum number of webhook subscriptions allowed (100). **Steps to resolve:** 1. Delete any webhook subscriptions that are no longer needed. 2. Retry creating the subscription. already_exists: >- This error occurs when trying to create a resource that already exists. **Steps to resolve:** 1. Check if the resource exists before creation 2. Use GET endpoints to verify resource state 3. Use unique identifiers/names for resources authorization_expired: >- Returned when an authorization attempt is made after the payment session's authorization deadline has passed. Create a new payment session with a later authorization deadline. bad_gateway: >- This error occurs when the CDP API is unable to connect to the backend service. **Steps to resolve:** 1. Retry your request after a short delay 2. If persistent, contact CDP support with: - The timestamp of the error - Request details 3. Consider implementing retry logic with an exponential backoff **Note:** These errors are automatically logged and monitored by CDP. capture_expired: >- Returned when a capture attempt is made after the payment session's capture deadline has passed. The payment session can no longer be captured. client_closed_request: >- This error occurs when the client closes the connection before the server can send a response. **Common causes:** - The client timed out waiting for the server response - The client application was terminated during a pending request - Network interruption caused the client connection to drop **Steps to resolve:** 1. Increase client-side timeout settings if applicable 2. Implement retry logic with exponential backoff for long-running queries 3. Consider optimizing the request to reduce server processing time endpoint_unavailable: >- This error occurs when a specific endpoint has been temporarily disabled by an operator (e.g. a kill switch). The CDP API as a whole is still healthy; only this endpoint is unavailable. Distinct from `service_unavailable`, which indicates the API itself is down. Re-enabling is a manual operator action, so the endpoint may remain unavailable for an extended period. **Steps to resolve:** 1. Check the [CDP status page](https://cdpstatus.coinbase.com/) for an active incident. 2. If persistent, contact CDP support with: - The timestamp of the error - Request details faucet_limit_exceeded: >- This error occurs when you've exceeded the faucet request limits. **Steps to resolve:** 1. Wait for the time window to reset 2. Use funds more efficiently in your testing For more information on faucet limits, please visit the [EVM Faucet endpoint](https://docs.cdp.coinbase.com/api-reference/v2/rest-api/faucets/request-funds-on-evm-test-networks) or the [Solana Faucet endpoint](https://docs.cdp.coinbase.com/api-reference/v2/rest-api/faucets/request-funds-on-solana-devnet). customer_not_authorized: >- This error occurs when the customer is not currently authorized for one or more capabilities required to perform the requested action. This can happen at any point in the customer's lifecycle and may or may not be resolvable by the developer. The response includes an `unauthorizedCapabilities` field listing the capability code(s) that were not authorized on this request. **Steps to resolve:** 1. Fetch the customer with `GET /v2/customers/{customerId}` and inspect the `requirements` field. If `requirements.due` is non-empty, submit the listed fields via `PUT /v2/customers/{customerId}` and retry. 2. If `requirements.due` is empty, no further action is available — the customer is not currently eligible for this action. forbidden: >- This error occurs when you don't have permission to access the resource. **Steps to resolve:** 1. Verify your permissions to access the resource 2. Ensure that you are the owner of the requested resource idempotency_error: >- This error occurs when an idempotency key is reused with different parameters. **Steps to resolve:** 1. Generate a new UUID v4 for each unique request 2. Only reuse idempotency keys for exact request duplicates 3. Track used keys within your application **Example idempotency key implementation:** ```typescript lines wrap import { v4 as uuidv4 } from 'uuid'; function createIdempotencyKey() { return uuidv4(); } ``` internal_server_error: >- This indicates an unexpected error that occurred on the CDP servers. **Important**: If you encounter this error, please note that your operation's status should be treated as unknown by your application, as it could have been a success within the CDP back-end. **Steps to resolve:** 1. Retry your request after a short delay 2. If persistent, contact CDP support with: - Your correlation ID - Timestamp of the error - Request details 3. Consider implementing retry logic with an exponential backoff **Note:** These errors are automatically logged and monitored by CDP. invalid_request: >- This error occurs when the request is malformed or contains invalid data, including issues with the request body, query parameters, path parameters, or headers. **Steps to resolve:** 1. Check all required fields and parameters are present 2. Ensure request body (if applicable) follows the correct schema 3. Verify all parameter formats match the API specification: - Query parameters - Path parameters - Request headers 4. Validate any addresses, IDs, or other formatted strings meet requirements **Common validation issues:** - Missing required parameters - Invalid parameter types or formats - Malformed JSON in request body - Invalid enum values #### Transfer-specific validation errors The following transfer validation scenarios return `errorType: "invalid_request"`. Use the `errorMessage` field to identify the specific case. | Scenario | Example `errorMessage` | |----------|----------------------| | Source account ID is malformed | `"source is invalid."` | | Target account ID is malformed | `"target is invalid."` | | Source account does not exist | `"source not found."` | | Target account does not exist | `"target not found."` | | Asset not supported at source | `"source is not supported."` | | Asset not supported at target | `"target is not supported."` | | Target email address is malformed | `"target has an invalid email format."` | | Target onchain address is invalid for network | `"The recipient address is invalid for the selected network."` | | Asset not supported for this transfer route | `"Transfer asset pair is not supported."` | | Insufficient balance | `"Insufficient funds to complete this transfer."` | | Asset mismatch between request fields | `"Currency mismatch in request."` | | Metadata has too many keys | `"Metadata has too many keys. Up to 10 key/value pairs are permitted."` | | Metadata key exceeds length limit | `"Metadata key is too long. Each key must be less than or equal to 40 characters."` | | Metadata value exceeds length limit | `"Metadata value is too long. Each value must be less than or equal to 500 characters."` | | Travel rule fields missing | `"Travel rule information is incomplete. Missing fields: ..."` | | Recipient address not in account allowlist | `"Your coinbase account allowlist does not include this address. Please update your allowlist at https://www.coinbase.com/settings/allowlist"` | invalid_sql_query: |- This error occurs when the SQL query is invalid or not allowed. **Common causes:** - Using non-SELECT SQL statements (INSERT, UPDATE, DELETE, etc.) - Invalid table or column names - Syntax errors in SQL query - Query exceeds character limit - Too many JOIN operations invalid_signature: >- This error occurs when the signature provided for the given user operation is invalid. **Steps to resolve:** 1. Verify the signature was generated by the correct owner account 2. Ensure the signature corresponds to the exact user operation hash 3. Check that the signature format matches the expected format 4. Confirm you're using the correct network for the Smart Account **Common causes:** - Using wrong owner account to sign - Signing modified/incorrect user operation data - Malformed signature encoding - Network mismatch between signature and broadcast malformed_transaction: >- This error occurs when the transaction data provided is not properly formatted or is invalid. **Steps to resolve:** 1. Verify transaction encoding: - **EVM networks**: Check RLP encoding is correct - **Solana**: Validate base64 encoding 2. Ensure all required transaction fields are present 3. Validate transaction parameters are within acceptable ranges 4. Check that the transaction type is supported on the target network **Common causes:** - Invalid hex encoding for EVM transactions - Missing required transaction fields - Incorrect parameter formats - Unsupported transaction types - Network-specific transaction format mismatches not_found: >- This error occurs when the resource specified in your request doesn't exist or you don't have access to it. **Steps to resolve:** 1. Verify the resource ID/address/account exists 2. Check your permissions to access the resource 3. Ensure you're using the correct network/environment 4. Confirm the resource hasn't been deleted **Common causes:** - Mistyped addresses - Accessing resources from the wrong CDP project - Resource was deleted or hasn't been created yet operation_in_progress: >- This error occurs when another operation of the same kind is already in progress for the resource, and the request must wait for it to complete. **Steps to resolve:** 1. Wait for the in-progress operation to complete (typically under 30 seconds) 2. Once complete, use the resource's GET endpoint to read its state instead of retrying the create **Common causes:** - Retrying a create whose previous attempt is still being processed - Concurrent duplicate requests for the same resource payment_method_required: >- This error occurs when a payment method is required to complete the requested operation but none is configured or available. **Steps to resolve:** 1. Add a valid payment method to your account using the [CDP Portal](https://portal.cdp.coinbase.com) 2. Ensure your payment method is valid and not expired **Common causes:** - No payment method configured on the account - Payment method is expired payment_required: >- This error occurs when an x402 payment is required to access the requested resource. **Steps to resolve:** 1. Include a valid x402 payment header in your request 2. Ensure the payment meets the resource's pricing requirements settlement_failed: >- This error occurs when an x402 payment was verified but settlement on-chain failed. **Steps to resolve:** 1. Retry the request with a new payment 2. Ensure the payment asset has sufficient balance for settlement rate_limit_exceeded: |- This error occurs when you've exceeded the API rate limits. **Steps to resolve:** 1. Implement exponential backoff 2. Cache responses where possible 3. Wait for rate limit window to reset **Best practices:** ```typescript lines wrap async function withRetry(fn: () => Promise) { let delay = 1000; while (true) { try { return await fn(); } catch (e) { if (e.errorType === "rate_limit_exceeded") { await sleep(delay); delay *= 2; continue; } throw e; } } } ``` request_canceled: >- This error occurs when the client cancels an in-progress request before it completes. **Steps to resolve:** 1. Check client-side timeout configurations 2. Review request cancellation logic in your code 3. Consider increasing timeout thresholds for long-running operations 4. Implement request tracking to identify premature cancellations **Best practices:** ```typescript lines wrap async function withTimeout(promise: Promise, timeoutMs: number): Promise { const timeout = new Promise((_, reject) => { setTimeout(() => { reject(new Error("Operation timed out")); }, timeoutMs); }); try { return await Promise.race([promise, timeout]); } catch (error) { // Handle timeout or cancellation throw error; } } ``` service_unavailable: >- This error occurs when the CDP API is temporarily unable to handle requests due to maintenance or high load. **Steps to resolve:** 1. Retry your request after a short delay 2. If persistent, contact CDP support with: - The timestamp of the error - Request details 3. Consider implementing retry logic with an exponential backoff **Note:** These errors are automatically logged and monitored by CDP. timed_out: >- This error occurs when a request exceeds the maximum allowed processing time. **Steps to resolve:** 1. Break down large requests into smaller chunks (if applicable) 2. Implement retry logic with exponential backoff 3. Use streaming endpoints for large data sets **Example retry implementation:** ```typescript lines wrap async function withRetryAndTimeout( operation: () => Promise, maxRetries = 3, timeout = 30000, ): Promise { let attempts = 0; while (attempts < maxRetries) { try { return await Promise.race([ operation(), new Promise((_, reject) => setTimeout(() => reject(new Error("Timeout")), timeout) ), ]); } catch (error) { attempts++; if (attempts === maxRetries) throw error; // Exponential backoff await new Promise(resolve => setTimeout(resolve, Math.pow(2, attempts) * 1000) ); } } throw new Error("Max retries exceeded"); } ``` unauthorized: |- This error occurs when authentication fails. **Steps to resolve:** 1. Verify your CDP API credentials: - Check that your API key is valid - Check that your Wallet Secret is properly configured 2. Validate JWT token: - Not expired - Properly signed - Contains required claims 3. Check request headers: - Authorization header present - X-Wallet-Auth header included when required **Security note:** Never share your Wallet Secret or API keys. unsupported_tos_language: >- A submitted Terms of Service acceptance used a `language` that is not published for the referenced `versionId`. **Steps to resolve:** 1. Read `Customer.requirements.tos.tosVersions[]` and find the entry whose `versionId` matches your acceptance. 2. Choose a `language` from that entry's `languages` list (BCP 47 tags). 3. Retry with `tosAcceptances[].language` set to a supported tag. policy_in_use: >- This error occurs when trying to delete a Policy that is currently in use by at least one project or account. **Steps to resolve:** 1. Update project or accounts to remove references to the Policy in question. 2. Retry your delete request. network_not_tradable: >- This error occurs when the selected asset cannot be purchased on the selected network in the user's location. **Steps to resolve:** 1. Verify the asset is tradable on the selected network 2. Check the user's location to ensure it is allowed to purchase the asset on the selected network **Common causes:** - Users in NY are not allowed to purchase USDC on any network other than Ethereum guest_permission_denied: >- This error occurs when the user is not allowed to complete onramp transactions as a guest. **Steps to resolve:** 1. Redirect the user to create a Coinbase account to buy and send crypto. guest_region_forbidden: >- This error occurs when guest onramp transactions are not allowed in the user's region. **Steps to resolve:** 1. Redirect the user to create a Coinbase account to buy and send crypto. guest_transaction_limit: >- This error occurs when the user has reached the weekly guest onramp transaction limit. **Steps to resolve:** 1. Inform the user they have reached their weekly limit and will have to wait until next week. guest_transaction_count: >- This error occurs when the user has reached the lifetime guest onramp transaction count limit. **Steps to resolve:** 1. Redirect the user to create a Coinbase account to buy and send crypto. phone_number_verification_expired: >- This error occurs when the user's phone number verification has expired. Use of guest Onramp requires the user's phone number to be verified every 60 days. **Steps to resolve:** 1. Re-verify the user's phone number via OTP. 2. Retry the request with the phoneNumberVerifiedAt field set to new verification timestamp. otp_verification_destination_mismatch: >- The `phoneNumber` or `email` on the order does not match the `destination` that was verified. **Steps to resolve:** 1. Ensure the `phoneNumber` or `email` field on the order matches the `destination` used during verification. 2. If the value changed, complete a new verification for the updated phone number or email. otp_verification_expired: >- The `smsVerificationId` or `emailVerificationId` provided has expired. Verification IDs are valid for 60 days after successful OTP submission. **Steps to resolve:** 1. Complete a new verification flow for the user. 2. Use the new verification ID when creating orders. otp_verification_code_invalid: >- This error occurs when the OTP code submitted to complete a verification is incorrect or has expired (the 10-minute OTP window has elapsed). **Steps to resolve:** 1. Ask the user to re-enter the code. 2. If the OTP window has expired, start a new verification flow. otp_verification_invalid: >- This error occurs when the verification record exists but is not in a usable state for the requested operation. **Common causes:** - The verification is still pending (OTP not yet submitted successfully). - The verification has been revoked. - The verification channel does not match the expected field (`smsVerificationId` or `emailVerificationId`). **Steps to resolve:** 1. Complete a new verification flow and retry. otp_verification_not_found: >- The provided SMS or email verification ID does not correspond to any verification record. **Steps to resolve:** 1. Ensure you are passing the correct verification ID as `smsVerificationId` or `emailVerificationId`. 2. If the issue persists, complete a new verification flow. otp_verification_required: >- An SMS or email verification ID is required on order creation but none was provided. **Steps to resolve:** 1. Verify the user's phone number and email before creating an order. 2. Pass the returned verification IDs as `smsVerificationId` and `emailVerificationId` when creating orders. document_verification_failed: >- This error occurs when the user has not verified their identity for their coinbase.com account. **Steps to resolve:** 1. Verify your coinbase account identity with valid documents at https://www.coinbase.com/settings/account-levels. recipient_allowlist_violation: >- This error occurs when the user is not allowed to receive funds at this address, according to their coinbase account allowlist. **Steps to resolve:** 1. Either disable the allowlist or add the wallet address at https://www.coinbase.com/settings/allowlist 2. Wait approximately 2 days for updates to take effect. recipient_allowlist_pending: >- This error occurs when the user is not allowed to receive funds at this address, because changes to their coinbase account allowlist are pending. **Steps to resolve:** 1. Wait approximately 2 days for updates to take effect. refund_expired: >- Returned when a refund attempt is made after the payment session's refund deadline has passed. The payment session can no longer be refunded. travel_rules_recipient_violation: >- This error occurs when the user is not allowed to receive funds at this address, because it violates travel rules. **Steps to resolve:** 1. Ensure your desired transfer is not blocked by local travel regulations. mfa_already_enrolled: >- This error occurs when attempting to enroll in an MFA method that the user has already enrolled in. **Steps to resolve:** 1. Check if the user is already enrolled in the MFA method before initiating enrollment 2. To update or reset MFA, remove the existing enrollment first (if supported) 3. Use a different MFA method if multiple options are available mfa_invalid_code: >- This error occurs when the MFA code provided is incorrect or has already been used. **Steps to resolve:** 1. Verify the user entered the correct code from their authenticator app 2. Ensure the code is current (TOTP codes expire after 30 seconds) 3. Check that the device time is synchronized correctly 4. Ask the user to generate a new code and try again **Common causes:** - Typing errors in the 6-digit code - Using an expired TOTP code - Device clock drift on user's authenticator app - Attempting to reuse a previously submitted code mfa_challenge_not_found: >- This error occurs when the challenge named by `X-Mfa-Challenge-Id` is unknown to the server or was already consumed by a failed submit attempt. This is distinct from `mfa_flow_expired`, which indicates the flow timed out. **Possible resolutions** - Pass the exact challenge ID from the `X-Mfa-Challenge-Id` header of the prior `403 mfa_required` response - If the user failed MFA verification (e.g. by entering the wrong OTP), re-initiate the MFA flow to obtain a fresh challenge **Common causes:** - Reusing a challenge after a failed submit attempt - A client bug sending a challenge from a different flow or user mfa_flow_expired: >- This error occurs when the MFA enrollment or verification session has expired. **Steps to resolve:** 1. Restart the MFA enrollment or verification flow 2. Complete the flow within the allowed time window (typically 5 minutes) 3. Ensure the user doesn't leave the flow idle for extended periods **Note:** MFA sessions expire automatically for security purposes. mfa_required: >- This error occurs when attempting to perform a sensitive operation that requires MFA verification, but the user has not completed MFA verification. **Steps to resolve:** 1. Initiate the MFA verification flow using the `/mfa/verify/{mfaMethod}/init` endpoint 2. Prompt the user to enter their MFA code 3. Submit the verification using the `/mfa/verify/{mfaMethod}/submit` endpoint 4. Use the returned access token with MFA claim for the sensitive operation 5. Retry the original request with the new MFA-verified token **Operations requiring MFA:** - Transactions Sign/Send - Key export - Account management actions (when configured) mfa_not_enrolled: >- This error occurs when attempting to verify MFA for a user who has not enrolled in any MFA method. **Steps to resolve:** 1. Check if the user has enrolled in MFA before attempting verification 2. Guide the user through MFA enrollment first using the `/mfa/enroll/{mfaMethod}/init` endpoint 3. Complete enrollment before requiring MFA verification source_account_invalid: >- This error occurs when the source account specified in the transfer request is invalid or malformed. **Steps to resolve:** 1. Verify the account ID format is correct (e.g., `account_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`) 2. Ensure the account ID belongs to your CDP entity 3. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` **Common causes:** - Malformed account ID - Typo in the account ID target_account_invalid: >- This error occurs when the target account specified in the transfer request is invalid or malformed. **Steps to resolve:** 1. Verify the account ID format is correct (e.g., `account_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`) 2. Ensure the account exists and can receive funds 3. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` **Common causes:** - Malformed account ID - Typo in the account ID source_account_not_found: >- This error occurs when the source account specified in the transfer does not exist. **Steps to resolve:** 1. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` target_account_not_found: >- This error occurs when the target account specified in the transfer does not exist. **Steps to resolve:** 1. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` source_asset_not_supported: >- This error occurs when the asset specified in the transfer source is not supported for this transfer type. **Steps to resolve:** 1. Check the list of supported assets for the source account type 2. Verify the asset symbol is correctly specified (e.g., `usdc`, `usdt`) **Common causes:** - Unsupported asset for the transfer route - Incorrect asset symbol target_asset_not_supported: >- This error occurs when the asset specified in the transfer target is not supported for this transfer type. **Steps to resolve:** 1. Check the list of supported assets for the target 2. Verify the asset symbol is correctly specified (e.g., `usdc`, `usdt`) 3. Ensure the target can receive this asset type **Common causes:** - Asset not supported by the target - Unsupported conversion between source and target assets target_email_invalid: >- This error occurs when the email address specified as the transfer target is invalid. **Steps to resolve:** 1. Verify the email address format is valid (e.g., `user@example.com`) 2. Check for typos in the email address 3. Ensure the email domain is valid **Common causes:** - Invalid email format - Missing @ symbol or domain - Typo in the email address target_onchain_address_invalid: >- This error occurs when the onchain address specified as the transfer target is invalid for the specified network. **Steps to resolve:** 1. Ensure the network is supported for the transfer type 2. Verify the address format matches the target network 3. Ensure you haven't mixed up addresses from different networks **Common causes:** - Network not supported for the transfer type - Address format doesn't match network - Address from a different blockchain network transfer_amount_invalid: >- This error occurs when the transfer amount is invalid. **Steps to resolve:** 1. Ensure the amount is a positive number and greater than $1 USD equivalent amount 2. Verify the amount format is a valid decimal string (e.g., `"100.50"`) 3. Check the number of decimal places for the asset **Common causes:** - Zero or negative amount - Too many decimal places for the asset - Amount below minimum threshold ($1 USD equivalent amount) transfer_asset_not_supported: >- This error occurs when the asset specified for the transfer is not supported. **Steps to resolve:** 1. Check the list of supported assets for transfers 2. Verify the asset symbol is correctly specified 3. Ensure the asset is supported for the transfer route (source → target) **Common causes:** - Asset not supported for transfers - Incorrect asset symbol transfer_quote_expired: >- This error occurs when the transfer quote has expired. Quotes are valid for a limited time. **Steps to resolve:** 1. Create a new transfer to obtain a fresh quote 2. Execute the transfer promptly after creation **Common causes:** - Too much time elapsed between creating and executing the transfer insufficient_balance: >- This error occurs when the source account does not have enough funds to complete the transfer including fees. **Steps to resolve:** 1. Check the source account balance 2. Ensure the balance covers both the transfer amount and any fees 3. Consider using `amountType: "source"` to transfer the maximum available amount minus fees 4. Add funds to the source account if needed **Common causes:** - Transfer amount exceeds available balance - Not accounting for transfer fees - Pending transactions reducing available balance metadata_too_many_entries: >- This error occurs when the transfer metadata contains more entries than allowed. **Steps to resolve:** 1. Reduce the number of metadata entries (maximum 10 allowed) 2. Consolidate related data into fewer keys 3. Store additional data externally and reference it with a single metadata entry **Limits:** - Maximum entries: 10 metadata_key_too_long: >- This error occurs when a metadata key exceeds the maximum allowed length. **Steps to resolve:** 1. Shorten the metadata key to 40 characters or less 2. Use abbreviations or shorter naming conventions 3. Consider using a key-value structure where the value contains the longer identifier **Limits:** - Maximum key length: 40 characters metadata_value_too_long: >- This error occurs when a metadata value exceeds the maximum allowed length. **Steps to resolve:** 1. Shorten the metadata value to 500 characters or less 2. Store longer data externally and reference it with a shorter identifier 3. Consider compressing or encoding the data if appropriate **Limits:** - Maximum value length: 500 characters travel_rules_field_missing: >- This error occurs when required travel rule fields are missing from the transfer request. **Steps to resolve:** 1. Include the `travelRule` object in your transfer request 2. Supply the required missing fields prompted by the error message 3. Review the travel rule requirements for your jurisdiction Note: Required fields may vary by region. asset_mismatch: >- This error occurs when the assets specified in the transfer are incompatible or don't match expected values. **Steps to resolve:** 1. Ensure the `asset` field matches either the source or target asset 2. Verify that the source and target assets are compatible for conversion (if different) 3. Check that the asset symbols are correctly specified **Common causes:** - Transfer asset doesn't match source or target - Attempting an unsupported asset conversion - Typo in asset symbols order_quote_expired: >- This error occurs when attempting to execute an order whose quote has expired. **Steps to resolve:** 1. Create a new order with `execute: false` to get an updated quote. 2. Execute the new order before the quote expires (check the `expiresAt` field). 3. Alternatively, create a new order with `execute: true` to skip the quote step and execute immediately. order_already_filled: >- This error occurs when attempting to cancel or modify an order that has already been filled. **Steps to resolve:** 1. Check the current status of the order using `GET /v2/orders/{orderId}`. 2. A filled order cannot be canceled or re-executed. order_already_canceled: >- This error occurs when attempting to cancel or execute an order that has already been canceled. **Steps to resolve:** 1. Check the current status of the order using `GET /v2/orders/{orderId}`. 2. Create a new order if you still want to trade. account_not_ready: >- This error occurs when an operation is attempted on an account that is still being provisioned. **Steps to resolve:** 1. Wait a few moments and retry the request 2. If the error persists, the account may still be completing setup — retry with exponential backoff insufficient_liquidity: >- This error occurs when no swap route is available for the requested token pair or amount. **Steps to resolve:** 1. Try a smaller `fromAmount` — large orders may exceed available liquidity 2. Try a different token pair 3. Retry after a short delay; liquidity conditions change with market activity insufficient_allowance: >- This error occurs when the taker has not approved the Permit2 contract to spend the `fromToken` on their behalf. ERC-20 swaps require a Permit2 allowance. Native ETH swaps do not. **Steps to resolve:** 1. Submit an ERC-20 `approve` transaction on the `fromToken` contract, granting the Permit2 contract (`0x000000000022D473030F116dDEE9F6B43aC78BA3`) an allowance of at least `fromAmount` 2. Wait for the approval transaction to be confirmed on-chain 3. Retry the swap **Example:** ```typescript lines wrap // Approve Permit2 to spend fromToken await walletClient.writeContract({ address: fromToken, abi: erc20Abi, functionName: "approve", args: ["0x000000000022D473030F116dDEE9F6B43aC78BA3", fromAmount], }); ``` transaction_simulation_failed: >- This error occurs when the pre-broadcast simulation of the swap transaction predicted a revert. No transaction was submitted and no gas was spent. **Common causes:** - The on-chain price moved past the `slippageBps` tolerance between the price estimate and execution - Taker balance changed between the price estimate and execution **Steps to resolve:** 1. Retry immediately — prices change quickly and a new quote may succeed 2. Increase `slippageBps` if retries continue to fail (e.g. from 100 to 200) 3. For large swaps, consider splitting into smaller amounts to reduce price impact delegation_not_found: >- This error occurs when a delegated signing operation is attempted but no active delegation grant exists for the end user (or account). **Steps to resolve:** 1. Create a delegation grant using `createDelegationForEndUser` (user-scoped) or `createDelegationForEndUserAccount` (account-scoped) before calling the signing or sending operation 2. If you previously created a grant, it may have expired or been revoked — in those cases you would receive a `delegation_expired` or `delegation_revoked` error instead 3. For account-scoped grants, verify the address in the request matches the granted address (EVM addresses are compared case-insensitively; Solana addresses must match exactly) delegation_expired: >- This error occurs when the delegation grant used for signing has expired. Delegation grants have a limited lifetime set at creation. **Steps to resolve:** 1. Create a new delegation grant using `createDelegationForEndUser` or `createDelegationForEndUserAccount` 2. Retry the signing operation with the new grant active 3. Consider creating grants with a longer TTL if expiry is frequent delegation_revoked: >- This error occurs when the delegation grant has been explicitly revoked. **Steps to resolve:** 1. Create a new delegation grant using `createDelegationForEndUser` or `createDelegationForEndUserAccount` 2. Confirm with the end user before recreating, since revocation is typically intentional delegation_not_authorized: >- This error occurs when a delegation grant exists but does not authorize the requested operation. **Steps to resolve:** 1. For account-scoped grants, verify the signing address matches the address the grant was created for 2. Check that the operation is permitted for delegated signing on your project 3. Create a grant with the correct scope if needed delegation_not_enabled: >- This error occurs when delegated signing is attempted on a project that has not enabled the feature. **Steps to resolve:** 1. Enable delegated signing in your project configuration via the CDP Portal 2. Contact support if you believe delegated signing should already be enabled for your project network_mismatch: >- This error occurs when the requested operation specifies a network on which the target resource is not deployed or not available. **Steps to resolve:** 1. Use the network the resource was originally created or deployed on 2. Check the resource metadata to confirm the correct network **Common causes:** - Specifying `base` for a resource that only exists on `base-sepolia` (or vice versa) - Cross-network operation attempted on a resource scoped to a single network already_enabled: >- This error occurs when the requested operation cannot be performed because the capability is already in the desired state. **Steps to resolve:** 1. Check the current state of the resource before attempting the operation 2. No action is needed if the resource is already in the desired state **Common causes:** - Calling an enable endpoint on a resource that already has the feature enabled payment_session_already_canceled: >- This error occurs when an action is attempted on a payment session that has already been canceled. **Steps to resolve:** 1. Create a new payment session to proceed with the payment flow payment_session_already_authorized: >- This error occurs when attempting to authorize a payment session that has already been authorized. **Steps to resolve:** 1. Check the payment session status — it is already authorized 2. Proceed to capture, void, or other post-authorization actions as needed payment_session_action_pending: >- This error occurs when another action is already in progress for the payment session. **Steps to resolve:** 1. Wait for the current action to complete before retrying 2. Check the payment session status to confirm the current action result no_capturable_balance: >- This error occurs when there is no remaining balance available to capture on the payment session. **Steps to resolve:** 1. Verify the payment session status and previously captured amounts 2. Ensure the session was authorized and has uncaptured funds remaining no_voidable_balance: >- This error occurs when there is no held balance remaining to void on the payment session. **Steps to resolve:** 1. Verify the payment session has an authorized but uncaptured balance 2. Check whether the session has already been fully captured or voided no_refundable_balance: >- This error occurs when the payment session has no captured amount available to refund. **Steps to resolve:** 1. Verify the payment session has been previously captured 2. Check that the session has not already been fully refunded entity_not_configured_for_payment_acceptance: >- This error occurs when the entity is not configured to accept payments. **Steps to resolve:** 1. Contact support to enable payment acceptance for the entity entity_not_configured_for_top_up: >- This error occurs when Top-Up is disabled for the entity or required Top-Up configuration is missing or invalid. **Steps to resolve:** 1. Contact support or your Coinbase representative to enable Top-Up or correct the entity's Top-Up configuration daily_transaction_limit_exceeded: |- This error occurs when the daily transaction limit has been exceeded. **Steps to resolve:** 1. Wait until the next day when the daily limit resets 2. Contact support for questions about your limit daily_amount_limit_exceeded: >- This error occurs when the daily authorization amount limit has been exceeded. **Steps to resolve:** 1. Wait until the next day when the daily limit resets 2. Contact support for questions about your limit stale_attestation: >- The platform attestation (iOS App Attest assertion or Android Play Integrity token) was generated against a challenge that has since expired. The request was well-formed, but the challenge is no longer valid. **Steps to resolve:** 1. Call [Create Onramp Mobile Challenge](#operation/createOnrampMobileChallenge) to obtain a fresh challenge. 2. Re-run the platform attestation flow against the new challenge. 3. Submit the new attestation to [Create Onramp Mobile Session](#operation/createOnrampMobileSession) promptly — challenges are short-lived. **Common causes:** - Too much time elapsed between obtaining the challenge and submitting the attestation. moderation_rejected: |- The uploaded image failed content moderation and will not be served. **Steps to resolve:** 1. Upload a different image that complies with content policies. mandate_action_pending: >- This error occurs when an approval or revocation is already in progress for the mandate. Get wallet approval options, approve a mandate, get wallet revocation options, revoke a mandate, and authorize a payment session with a mandate all return this while an action is in flight. **Steps to resolve:** 1. Wait for the in-flight approval or revocation to succeed or fail 2. Check the mandate `status`, then retry the request mandate_policy_violation: >- This error occurs only when the request breaches the mandate policy: the charge exceeds `maxPerAuthorization` or `maxPerPeriod`, or an approval is rejected because the payer's available balance is below `minSetupBalance`. **Steps to resolve:** 1. Lower the charge, raise the mandate policy, or fund the payer above `minSetupBalance` 2. Retry the request mandate_expired: >- This error occurs when the mandate is past its `expiresAt` and can no longer be used. Authorization, approve a mandate, and get wallet approval options return this error. **Steps to resolve:** 1. Create a new mandate if the customer should continue 2. Do not retry the request against the expired mandate mandate_canceled: >- This error occurs when `canceledAt` is set. Authorization, approve a mandate, and get wallet approval options return this. If `revokedAt` is also set, those operations return `mandate_revoked` instead. **Steps to resolve:** 1. Create a new mandate if the customer should continue 2. Do not retry the request against the canceled mandate mandate_revoked: >- This error occurs when the mandate's on-chain spending allowance has been removed (`revokedAt` is set, status `revocation_succeeded`). Authorization, approve a mandate, and get wallet approval options return this when `revokedAt` is set, including when `canceledAt` is also set. Get wallet revocation options and revoke a mandate also return this when the allowance was already removed. Cancel a mandate returns this: a fully revoked mandate cannot be canceled. Canceling an already-canceled mandate is a no-op and returns the mandate. **Steps to resolve:** 1. Create a new mandate if the customer should continue 2. Do not retry the request against the revoked mandate mandate_invalid_status: >- This error occurs when the mandate's status does not satisfy the operation, and a more specific code does not apply. `errorMessage` names the status the operation expected. Check the specific codes first: `mandate_canceled`, `mandate_revoked`, `mandate_expired`, and `mandate_action_pending`. Approve a mandate and get wallet approval options require `created` or `approval_failed` after those checks. `approval_succeeded`, `revocation_failed`, and any other remaining status return this. Authorize a payment session requires `approval_succeeded`. Revoke a mandate and get wallet revocation options return this when `approvedAt` was never set, so no spending allowance exists. That is separate from `mandate_revoked`, which applies only after `revokedAt` is set. **Steps to resolve:** 1. Read `errorMessage` for the status this operation requires 2. Move the mandate to that status, or create a new mandate Url: type: string format: uri minLength: 11 maxLength: 2048 pattern: ^https?://.*$ description: A valid HTTP or HTTPS URL. example: https://example.com CapabilityName: type: string description: > The name of a capability. Capabilities represent granular functional permissions that determine what actions a customer can perform. Each capability must be explicitly requested before use. enum: - custodyCrypto - custodyFiat - custodyStablecoin - tradeCrypto - tradeStablecoin - transferCrypto - transferFiat - transferStablecoin x-enum-varnames: - CustodyCrypto - CustodyFiat - CustodyStablecoin - TradeCrypto - TradeStablecoin - TransferCrypto - TransferFiat - TransferStablecoin example: custodyCrypto EIP712Domain: type: object description: The domain of the EIP-712 typed data. properties: name: type: string description: The name of the DApp or protocol. example: Permit2 version: type: string description: The version of the DApp or protocol. example: '1' chainId: type: integer format: int64 description: The chain ID of the EVM network. example: 1 verifyingContract: type: string pattern: ^0x[a-fA-F0-9]{40}$ description: The 0x-prefixed EVM address of the verifying smart contract. example: '0x000000000022D473030F116dDEE9F6B43aC78BA3' salt: type: string pattern: ^0x[a-fA-F0-9]{64}$ description: The optional 32-byte 0x-prefixed hex salt for domain separation. example: '0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef' example: name: Permit2 chainId: 1 verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' EIP712Types: type: object description: > A mapping of struct names to an array of type objects (name + type). Each key corresponds to a type name (e.g., "`EIP712Domain`", "`PermitTransferFrom`"). example: EIP712Domain: - name: name type: string - name: chainId type: uint256 - name: verifyingContract type: address PermitTransferFrom: - name: permitted type: TokenPermissions - name: spender type: address - name: nonce type: uint256 - name: deadline type: uint256 TokenPermissions: - name: token type: address - name: amount type: uint256 EvmUserOperationNetwork: type: string description: The network the user operation is for. enum: - base-sepolia - base - arbitrum - optimism - zora - polygon - bnb - avalanche - ethereum - ethereum-sepolia example: base EvmCall: type: object properties: to: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The address the call is directed to. example: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' value: type: string description: The amount of ETH to send with the call, in wei. example: '0' data: type: string pattern: ^0x[0-9a-fA-F]*$ description: >- The call data to send. This is the hex-encoded data of the function call consisting of the method selector and the function arguments. example: >- 0xa9059cbb000000000000000000000000fc807d1be4997e5c7b33e4d8d57e60c5b0f02b1a0000000000000000000000000000000000000000000000000000000000000064 overrideGasLimit: type: string description: >- The override gas limit to use for the call instead of the bundler's estimated gas limit. example: '100000' required: - to - value - data PaymasterContext: type: object additionalProperties: true description: >- The ERC-7677 `context` object forwarded to the paymaster service as part of the `paymasterService` capability. The fields in this object are defined by the paymaster service provider; CDP forwards them to the paymaster unchanged. This field is only valid when a paymaster is configured for the request. Providing `paymasterContext` without a paymaster configured results in an `invalid_request` error. example: policyId: 962b252c-a726-4a37-8d86-333ce0a07299 EIP712Message: type: object description: The message to sign using EIP-712. properties: domain: $ref: '#/components/schemas/EIP712Domain' types: $ref: '#/components/schemas/EIP712Types' primaryType: type: string description: >- The primary type of the message. This is the name of the struct in the `types` object that is the root of the message. example: PermitTransferFrom message: type: object description: >- The message to sign. The structure of this message must match the `primaryType` struct in the `types` object. example: permitted: token: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' amount: '1000000' spender: '0x1111111254EEB25477B68fb85Ed929f73A960582' nonce: '0' deadline: '1716239020' required: - domain - types - primaryType - message example: domain: name: Permit2 chainId: 1 verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' types: EIP712Domain: - name: name type: string - name: chainId type: uint256 - name: verifyingContract type: address PermitTransferFrom: - name: permitted type: TokenPermissions - name: spender type: address - name: nonce type: uint256 - name: deadline type: uint256 TokenPermissions: - name: token type: address - name: amount type: uint256 primaryType: PermitTransferFrom message: permitted: token: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48' amount: '1000000' spender: '0xFfFfFfFFfFFfFFfFFfFFFFFffFFFffffFfFFFfFf' nonce: '123456' deadline: '1717123200' BlockchainAddress: type: string minLength: 1 maxLength: 128 description: >- A blockchain address. Format varies by network (e.g., 0x-prefixed for EVM, base58 for Solana). example: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' Asset: type: string minLength: 1 maxLength: 42 description: The symbol of the asset (e.g., eth, usd, usdc, usdt). example: usd EvmSwapsNetwork: type: string enum: - base - ethereum - arbitrum - optimism - polygon description: The network on which to perform the swap. example: base Rule: type: object description: A rule that limits the behavior of an account. oneOf: - $ref: '#/components/schemas/SignEvmTransactionRule' - $ref: '#/components/schemas/SendEvmTransactionRule' - $ref: '#/components/schemas/SignEvmMessageRule' - $ref: '#/components/schemas/SignEvmTypedDataRule' - $ref: '#/components/schemas/SignSolTransactionRule' - $ref: '#/components/schemas/SendSolTransactionRule' - $ref: '#/components/schemas/SignSolMessageRule' - $ref: '#/components/schemas/SignEvmHashRule' - $ref: '#/components/schemas/PrepareUserOperationRule' - $ref: '#/components/schemas/SendUserOperationRule' - $ref: '#/components/schemas/SignEndUserEvmTransactionRule' - $ref: '#/components/schemas/SendEndUserEvmTransactionRule' - $ref: '#/components/schemas/SignEndUserEvmMessageRule' - $ref: '#/components/schemas/SignEndUserEvmTypedDataRule' - $ref: '#/components/schemas/SignEndUserEvmHashRule' - $ref: '#/components/schemas/SignEndUserSolTransactionRule' - $ref: '#/components/schemas/SendEndUserSolTransactionRule' - $ref: '#/components/schemas/SignEndUserSolMessageRule' - $ref: '#/components/schemas/SendEndUserEvmAssetRule' - $ref: '#/components/schemas/SendEndUserSolAssetRule' - $ref: '#/components/schemas/SendEndUserOperationRule' - $ref: '#/components/schemas/CreateEndUserEvmSwapRule' example: action: accept operation: signEvmTransaction criteria: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in PolicyCriterionObservation: description: >- The value taken from the operation that a criterion was compared against, discriminated by the criterion's `type`. Amounts use the criterion's units: integer strings of base units (wei, lamports, or token atomic units) and USD in integer cents, so a unit mistake in a rule shows as a difference in magnitude. A field is omitted when the operation has no such value; each field says when that happens. Values come only from the request, the prepared user operation it names, transaction simulation, and the rate-limit counters the criterion reads. These are never returned: signatures, raw transaction bytes, calldata or instruction data beyond the decoded selector, instruction and arguments, the operations or accounts that make up a rate-limit total, and simulation results other than the net USD change. A string longer than its `maxLength` is cut to its first `maxLength` characters and marked `truncated: true`. example: type: evmAddress address: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913' oneOf: - $ref: '#/components/schemas/EthValueObservation' - $ref: '#/components/schemas/EvmAddressObservation' - $ref: '#/components/schemas/EvmNetworkObservation' - $ref: '#/components/schemas/EvmDataObservation' - $ref: '#/components/schemas/EvmMessageObservation' - $ref: '#/components/schemas/EvmTypedDataFieldObservation' - $ref: '#/components/schemas/EvmTypedDataVerifyingContractObservation' - $ref: '#/components/schemas/NetUSDChangeObservation' - $ref: '#/components/schemas/SolAddressObservation' - $ref: '#/components/schemas/SolValueObservation' - $ref: '#/components/schemas/SplAddressObservation' - $ref: '#/components/schemas/SplValueObservation' - $ref: '#/components/schemas/MintAddressObservation' - $ref: '#/components/schemas/SolDataObservation' - $ref: '#/components/schemas/SolMessageObservation' - $ref: '#/components/schemas/ProgramIdObservation' - $ref: '#/components/schemas/SolNetworkObservation' - $ref: '#/components/schemas/RateLimitingObservation' discriminator: propertyName: type mapping: ethValue: '#/components/schemas/EthValueObservation' evmAddress: '#/components/schemas/EvmAddressObservation' evmNetwork: '#/components/schemas/EvmNetworkObservation' evmData: '#/components/schemas/EvmDataObservation' evmMessage: '#/components/schemas/EvmMessageObservation' evmTypedDataField: '#/components/schemas/EvmTypedDataFieldObservation' evmTypedDataVerifyingContract: '#/components/schemas/EvmTypedDataVerifyingContractObservation' netUSDChange: '#/components/schemas/NetUSDChangeObservation' solAddress: '#/components/schemas/SolAddressObservation' solValue: '#/components/schemas/SolValueObservation' splAddress: '#/components/schemas/SplAddressObservation' splValue: '#/components/schemas/SplValueObservation' mintAddress: '#/components/schemas/MintAddressObservation' solData: '#/components/schemas/SolDataObservation' solMessage: '#/components/schemas/SolMessageObservation' programId: '#/components/schemas/ProgramIdObservation' solNetwork: '#/components/schemas/SolNetworkObservation' rateLimiting: '#/components/schemas/RateLimitingObservation' PolicyCriterion: description: >- The unmet criterion, exactly as defined in the rule, discriminated by `type`. example: type: evmAddress addresses: - '0x000000000000000000000000000000000000dEaD' operator: in oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/EvmMessageCriterion' - $ref: '#/components/schemas/SignEvmTypedDataFieldCriterion' - $ref: '#/components/schemas/SignEvmTypedDataVerifyingContractCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' - $ref: '#/components/schemas/SolAddressCriterion' - $ref: '#/components/schemas/SolValueCriterion' - $ref: '#/components/schemas/SplAddressCriterion' - $ref: '#/components/schemas/SplValueCriterion' - $ref: '#/components/schemas/MintAddressCriterion' - $ref: '#/components/schemas/SolDataCriterion' - $ref: '#/components/schemas/SolMessageCriterion' - $ref: '#/components/schemas/ProgramIdCriterion' - $ref: '#/components/schemas/SolNetworkCriterion' discriminator: propertyName: type mapping: ethValue: '#/components/schemas/EthValueCriterion' evmAddress: '#/components/schemas/EvmAddressCriterion' evmNetwork: '#/components/schemas/EvmNetworkCriterion' evmData: '#/components/schemas/EvmDataCriterion' evmMessage: '#/components/schemas/EvmMessageCriterion' evmTypedDataField: '#/components/schemas/SignEvmTypedDataFieldCriterion' evmTypedDataVerifyingContract: '#/components/schemas/SignEvmTypedDataVerifyingContractCriterion' netUSDChange: '#/components/schemas/NetUSDChangeCriterion' solAddress: '#/components/schemas/SolAddressCriterion' solValue: '#/components/schemas/SolValueCriterion' splAddress: '#/components/schemas/SplAddressCriterion' splValue: '#/components/schemas/SplValueCriterion' mintAddress: '#/components/schemas/MintAddressCriterion' solData: '#/components/schemas/SolDataCriterion' solMessage: '#/components/schemas/SolMessageCriterion' programId: '#/components/schemas/ProgramIdCriterion' solNetwork: '#/components/schemas/SolNetworkCriterion' SignEvmTransactionRule: title: SignEvmTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEvmTransaction enum: - signEvmTransaction criteria: $ref: '#/components/schemas/SignEvmTransactionCriteria' required: - action - operation - criteria SendEvmTransactionRule: x-audience: public title: SendEvmTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendEvmTransaction enum: - sendEvmTransaction criteria: $ref: '#/components/schemas/SendEvmTransactionCriteria' required: - action - operation - criteria SignEvmMessageRule: x-audience: public title: SignEvmMessageRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEvmMessage enum: - signEvmMessage criteria: $ref: '#/components/schemas/SignEvmMessageCriteria' required: - action - operation - criteria SignEvmTypedDataRule: x-audience: public title: SignEvmTypedDataRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEvmTypedData enum: - signEvmTypedData criteria: $ref: '#/components/schemas/SignEvmTypedDataCriteria' required: - action - operation - criteria SignSolTransactionRule: title: SignSolTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signSolTransaction enum: - signSolTransaction criteria: $ref: '#/components/schemas/SignSolTransactionCriteria' required: - action - operation - criteria SendSolTransactionRule: x-audience: public title: SendSolTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendSolTransaction enum: - sendSolTransaction criteria: $ref: '#/components/schemas/SendSolTransactionCriteria' required: - action - operation - criteria SignSolMessageRule: x-audience: public title: SignSolMessageRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signSolMessage enum: - signSolMessage criteria: $ref: '#/components/schemas/SignSolMessageCriteria' required: - action - operation - criteria SignEvmHashRule: x-audience: public title: SignEvmHashRule properties: action: type: string description: >- Whether any attempts to sign a hash will be accepted or rejected. This rule does not accept any criteria. example: accept enum: - reject - accept operation: type: string description: The operation to which the rule applies. example: signEvmHash enum: - signEvmHash required: - action - operation PrepareUserOperationRule: x-audience: public title: PrepareUserOperationRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: prepareUserOperation enum: - prepareUserOperation criteria: $ref: '#/components/schemas/PrepareUserOperationCriteria' required: - action - operation - criteria SendUserOperationRule: x-audience: public title: SendUserOperationRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendUserOperation enum: - sendUserOperation criteria: $ref: '#/components/schemas/SendUserOperationCriteria' required: - action - operation - criteria SignEndUserEvmTransactionRule: x-audience: public title: SignEndUserEvmTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEndUserEvmTransaction enum: - signEndUserEvmTransaction criteria: $ref: '#/components/schemas/SignEndUserEvmTransactionCriteria' required: - action - operation - criteria SendEndUserEvmTransactionRule: x-audience: public title: SendEndUserEvmTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendEndUserEvmTransaction enum: - sendEndUserEvmTransaction criteria: $ref: '#/components/schemas/SendEndUserEvmTransactionCriteria' required: - action - operation - criteria SignEndUserEvmMessageRule: x-audience: public title: SignEndUserEvmMessageRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEndUserEvmMessage enum: - signEndUserEvmMessage criteria: $ref: '#/components/schemas/SignEndUserEvmMessageCriteria' required: - action - operation - criteria SignEndUserEvmTypedDataRule: x-audience: public title: SignEndUserEvmTypedDataRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEndUserEvmTypedData enum: - signEndUserEvmTypedData criteria: $ref: '#/components/schemas/SignEndUserEvmTypedDataCriteria' required: - action - operation - criteria SignEndUserEvmHashRule: x-audience: public title: SignEndUserEvmHashRule properties: action: type: string description: >- Whether any attempts to sign a hash will be accepted or rejected. This rule does not accept any criteria. example: accept enum: - reject - accept operation: type: string description: The operation to which the rule applies. example: signEndUserEvmHash enum: - signEndUserEvmHash required: - action - operation SignEndUserSolTransactionRule: x-audience: public title: SignEndUserSolTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEndUserSolTransaction enum: - signEndUserSolTransaction criteria: $ref: '#/components/schemas/SignEndUserSolTransactionCriteria' required: - action - operation - criteria SendEndUserSolTransactionRule: x-audience: public title: SendEndUserSolTransactionRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendEndUserSolTransaction enum: - sendEndUserSolTransaction criteria: $ref: '#/components/schemas/SendEndUserSolTransactionCriteria' required: - action - operation - criteria SignEndUserSolMessageRule: x-audience: public title: SignEndUserSolMessageRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: signEndUserSolMessage enum: - signEndUserSolMessage criteria: $ref: '#/components/schemas/SignEndUserSolMessageCriteria' required: - action - operation - criteria SendEndUserEvmAssetRule: x-audience: public title: SendEndUserEvmAssetRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendEndUserEvmAsset enum: - sendEndUserEvmAsset criteria: $ref: '#/components/schemas/SendEndUserEvmAssetCriteria' required: - action - operation - criteria SendEndUserSolAssetRule: x-audience: public title: SendEndUserSolAssetRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendEndUserSolAsset enum: - sendEndUserSolAsset criteria: $ref: '#/components/schemas/SendEndUserSolAssetCriteria' required: - action - operation - criteria SendEndUserOperationRule: x-audience: public title: SendEndUserOperationRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: sendEndUserOperation enum: - sendEndUserOperation criteria: $ref: '#/components/schemas/SendEndUserOperationCriteria' required: - action - operation - criteria CreateEndUserEvmSwapRule: x-audience: public title: CreateEndUserEvmSwapRule properties: action: type: string description: >- Whether matching the rule will cause the request to be rejected or accepted. example: accept enum: - reject - accept operation: type: string description: >- The operation to which the rule applies. Every element of the `criteria` array must match the specified operation. example: createEndUserEvmSwap enum: - createEndUserEvmSwap criteria: $ref: '#/components/schemas/CreateEndUserEvmSwapCriteria' required: - action - operation - criteria EthValueObservation: type: object title: EthValueObservation description: The transaction `value` an `ethValue` criterion compared. example: type: ethValue ethValue: '500000000000000000' properties: type: type: string description: The criterion type. enum: - ethValue x-go-type: string example: ethValue ethValue: type: string pattern: ^[0-9]+$ maxLength: 78 description: >- The transaction `value`, in wei. `0` when the transaction transfers no ETH. example: '500000000000000000' required: - type - ethValue additionalProperties: false EvmAddressObservation: type: object title: EvmAddressObservation description: >- The transaction `to` address an `evmAddress` criterion compared. For a token transfer, this is the token contract, not the token recipient; use an `evmData` criterion to constrain the recipient. example: type: evmAddress address: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913' properties: type: type: string description: The criterion type. enum: - evmAddress x-go-type: string example: evmAddress address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The transaction `to` address. Omitted for a contract-creation transaction, which has none. example: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913' required: - type additionalProperties: false EvmNetworkObservation: type: object title: EvmNetworkObservation description: The network an `evmNetwork` criterion compared. example: type: evmNetwork network: base-sepolia chainId: 84532 properties: type: type: string description: The criterion type. enum: - evmNetwork x-go-type: string example: evmNetwork network: type: string description: >- The network the operation targets, from the request's `network` or derived from the transaction's chain ID. Omitted when the chain ID is not a supported network. example: base-sepolia chainId: type: integer minimum: 0 description: >- The chain ID from the transaction. Omitted when the network came from the request's `network`. example: 84532 required: - type additionalProperties: false EvmDataObservation: type: object title: EvmDataObservation description: >- The call an `evmData` criterion decoded from the transaction `data` with the criterion's `abi`. Parameters are checked against the first of the criterion's `conditions` whose `function` equals `function`. example: type: evmData selector: '0xa9059cbb' function: transfer arguments: - name: to type: address value: '0x1111111254EEB25477B68fb85Ed929f73A960582' truncated: false - name: value type: uint256 value: '25000000' truncated: false properties: type: type: string description: The criterion type. enum: - evmData x-go-type: string example: evmData selector: type: string pattern: ^0x[0-9a-f]{8}$ description: >- The 4-byte function selector. Omitted when `data` is shorter than 4 bytes. example: '0xa9059cbb' function: type: string maxLength: 256 description: >- The name of the ABI function with this selector. Omitted when no function in the `abi` has it. example: transfer arguments: type: array maxItems: 32 description: >- The decoded arguments of `function`, in ABI order. Empty when `function` is omitted. Only the first 32 arguments are returned. items: $ref: '#/components/schemas/ObservedArgument' required: - type - arguments additionalProperties: false EvmMessageObservation: type: object title: EvmMessageObservation description: >- The message an `evmMessage` criterion matched its `match` expression against. example: type: evmMessage message: |- example.com wants you to sign in with your Ethereum account: 0x742d35Cc6634C0532925a3b844Bc454e4438f44e Sign in to Example. encoding: utf8 truncated: false properties: type: type: string description: The criterion type. enum: - evmMessage x-go-type: string example: evmMessage message: $ref: '#/components/schemas/ObservedMessageText' encoding: $ref: '#/components/schemas/ObservedMessageEncoding' truncated: type: boolean description: >- Whether `message` was cut to its first 2048 characters. The expression was matched against the whole message. example: false required: - type - message - encoding - truncated additionalProperties: false EvmTypedDataFieldObservation: type: object title: EvmTypedDataFieldObservation description: >- The typed data fields an `evmTypedDataField` criterion compared. The message's types must match the criterion's `types` before any condition is checked. example: type: evmTypedDataField typesMatched: true fields: - conditionIndex: 1 value: '40' truncated: false properties: type: type: string description: The criterion type. enum: - evmTypedDataField x-go-type: string example: evmTypedDataField typesMatched: type: boolean description: >- Whether the message's types matched the criterion's `types`. When `false`, no condition was checked and `fields` is empty. example: true fields: type: array maxItems: 64 description: >- The fields that decided the criterion. When the criterion is unmet, this is the field of the first failing condition only. When it is met, this is the field of every condition, in `conditions` order. items: $ref: '#/components/schemas/ObservedTypedDataField' required: - type - typesMatched - fields additionalProperties: false EvmTypedDataVerifyingContractObservation: type: object title: EvmTypedDataVerifyingContractObservation description: >- The domain `verifyingContract` an `evmTypedDataVerifyingContract` criterion compared. example: type: evmTypedDataVerifyingContract address: '0x000000000022D473030F116dDEE9F6B43aC78BA3' properties: type: type: string description: The criterion type. enum: - evmTypedDataVerifyingContract x-go-type: string example: evmTypedDataVerifyingContract address: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: The domain's `verifyingContract`. Omitted when the domain has none. example: '0x000000000022D473030F116dDEE9F6B43aC78BA3' required: - type additionalProperties: false NetUSDChangeObservation: type: object title: NetUSDChangeObservation description: The simulated net USD change a `netUSDChange` criterion compared. example: type: netUSDChange skipped: false changeCents: 12550 properties: type: type: string description: The criterion type. enum: - netUSDChange x-go-type: string example: netUSDChange skipped: type: boolean description: >- Whether simulation was skipped because the operation targets a testnet. A skipped criterion is treated as met, as in the real operation, and `changeCents` is omitted. example: false changeCents: type: integer description: >- The net USD change, in cents, of the transaction's asset transfers and exposure, as simulated at evaluation time. Present exactly when `skipped` is `false`. example: 12550 required: - type - skipped additionalProperties: false SolAddressObservation: type: object title: SolAddressObservation description: The native SOL transfer recipients a `solAddress` criterion compared. example: type: solAddress addresses: - ExXhNkgYf6efh7YyqDRVxPZuzafobao1A74drUdp8trd properties: type: type: string description: The criterion type. enum: - solAddress x-go-type: string example: solAddress addresses: type: array maxItems: 128 description: >- The recipient of each System Program transfer, in instruction order. Empty when the transaction has none. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: A transfer recipient. example: - ExXhNkgYf6efh7YyqDRVxPZuzafobao1A74drUdp8trd required: - type - addresses additionalProperties: false SolValueObservation: type: object title: SolValueObservation description: The native SOL transfer amounts a `solValue` criterion compared. example: type: solValue solValues: - '1500000000' properties: type: type: string description: The criterion type. enum: - solValue x-go-type: string example: solValue solValues: type: array maxItems: 128 description: >- The amount of each System Program transfer, in lamports, in instruction order. Empty when the transaction has none. items: type: string pattern: ^[0-9]+$ maxLength: 20 description: A transfer amount in lamports. example: - '1500000000' required: - type - solValues additionalProperties: false SplAddressObservation: type: object title: SplAddressObservation description: >- The SPL token transfer recipients an `splAddress` criterion compared. For a raw transaction these are the recipients' token accounts (usually associated token accounts), not their wallet addresses. For `sendEndUserSolAsset` they are wallet addresses. example: type: splAddress addresses: - 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM properties: type: type: string description: The criterion type. enum: - splAddress x-go-type: string example: splAddress addresses: type: array maxItems: 128 description: >- The recipient of each SPL token transfer, in instruction order. Empty when the transaction has none. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: A token transfer recipient. example: - 9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM required: - type - addresses additionalProperties: false SplValueObservation: type: object title: SplValueObservation description: The SPL token transfer amounts an `splValue` criterion compared. example: type: splValue splValues: - '1500000' properties: type: type: string description: The criterion type. enum: - splValue x-go-type: string example: splValue splValues: type: array maxItems: 128 description: >- The amount of each `TransferChecked` instruction, in the token's atomic units (not scaled by decimals), in instruction order. Empty when the transaction has none. items: type: string pattern: ^[0-9]+$ maxLength: 20 description: A transfer amount in atomic units. example: - '1500000' required: - type - splValues additionalProperties: false MintAddressObservation: type: object title: MintAddressObservation description: >- The token mints of the SPL token transfers a `mintAddress` criterion compared. example: type: mintAddress addresses: - EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v properties: type: type: string description: The criterion type. enum: - mintAddress x-go-type: string example: mintAddress addresses: type: array maxItems: 128 description: >- The mint of each SPL token transfer, in instruction order. Empty when the transaction has none. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: A token mint. example: - EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v required: - type - addresses additionalProperties: false SolDataObservation: type: object title: SolDataObservation description: >- The instructions a `solData` criterion decoded with the criterion's `idls`. The criterion is met when every instruction matches at least one of its `conditions`. example: type: solData instructions: - index: 1 programId: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA instruction: transfer_checked arguments: - name: amount type: u64 value: '2000000' truncated: false - name: decimals type: u8 value: '6' truncated: false truncated: false properties: type: type: string description: The criterion type. enum: - solData x-go-type: string example: solData instructions: type: array maxItems: 64 description: >- The instructions that decided the criterion. When the criterion is unmet, this is the first instruction that matched no condition, only. When it is met, this is every instruction, in transaction order. items: $ref: '#/components/schemas/ObservedInstruction' truncated: type: boolean description: Whether `instructions` was cut to its first 64 entries. example: false required: - type - instructions - truncated additionalProperties: false SolMessageObservation: type: object title: SolMessageObservation description: >- The message a `solMessage` criterion matched its `match` expression against, after decoding the request's base64 `message` when its `encoding` is `base64`. example: type: solMessage message: Hello, world encoding: utf8 truncated: false properties: type: type: string description: The criterion type. enum: - solMessage x-go-type: string example: solMessage message: $ref: '#/components/schemas/ObservedMessageText' encoding: $ref: '#/components/schemas/ObservedMessageEncoding' truncated: type: boolean description: >- Whether `message` was cut to its first 2048 characters. The expression was matched against the whole message. example: false required: - type - message - encoding - truncated additionalProperties: false ProgramIdObservation: type: object title: ProgramIdObservation description: The instruction program IDs a `programId` criterion compared. example: type: programId programIds: - '11111111111111111111111111111111' - TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA properties: type: type: string description: The criterion type. enum: - programId x-go-type: string example: programId programIds: type: array maxItems: 128 description: The program ID of each instruction, in instruction order. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: An instruction program ID. example: - '11111111111111111111111111111111' - TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA required: - type - programIds additionalProperties: false SolNetworkObservation: type: object title: SolNetworkObservation description: The network a `solNetwork` criterion compared. example: type: solNetwork network: solana-devnet properties: type: type: string description: The criterion type. enum: - solNetwork x-go-type: string example: solNetwork network: type: string description: >- The request's `network`. Omitted when the request has none, which no `networks` value matches. example: solana-devnet required: - type additionalProperties: false RateLimitingObservation: type: object title: RateLimitingObservation description: >- The rate-limit usage a `rateLimiting` criterion compared, read without being consumed. The criterion is met when the projected usage stays within the limit and unmet when it exceeds the limit. Totals can change before a real call. example: type: rateLimiting scope: project usage: type: count windowCount: 10 pendingCount: 0 properties: type: type: string description: The criterion type. enum: - rateLimiting x-go-type: string example: rateLimiting scope: type: string description: >- Whose operations the counter totals. `project` counts operations of every account in the project, not only the account in the request. `end_user` counts operations of the end user in the request. enum: - project - end_user x-go-type: string example: project usage: $ref: '#/components/schemas/RateLimitUsage' required: - type - scope - usage additionalProperties: false EthValueCriterion: type: object title: EthValueCriterion description: >- A schema for specifying a criterion for the `value` field of an EVM transaction. properties: type: type: string description: The type of criterion to use. This should be `ethValue`. example: ethValue enum: - ethValue ethValue: type: string pattern: ^[0-9]+$ maxLength: 78 description: >- The amount of ETH, in wei, that the transaction's `value` field should be compared to. example: '1000000000000000000' operator: type: string description: >- The operator to use for the comparison. The transaction's `value` field will be on the left-hand side of the operator, and the `ethValue` field will be on the right-hand side. enum: - '>' - '>=' - < - <= - '==' example: <= required: - type - ethValue - operator EvmAddressCriterion: type: object x-audience: public title: EvmAddressCriterion description: >- A schema for specifying a criterion for the `to` field of an EVM transaction. properties: type: type: string description: The type of criterion to use. This should be `evmAddress`. example: evmAddress enum: - evmAddress addresses: type: array description: >- A list of 0x-prefixed EVM addresses that the transaction's `to` field should be compared to. There is a limit of 300 addresses per criterion. items: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed EVM address that the transaction's `to` field should be compared to. example: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' - '0x1234567890123456789012345678901234567890' operator: type: string description: >- The operator to use for the comparison. The transaction's `to` field will be on the left-hand side of the operator, and the `addresses` field will be on the right-hand side. enum: - in - not in example: in required: - type - addresses - operator EvmNetworkCriterion: type: object x-audience: public title: EvmNetworkCriterion description: >- A schema for specifying a criterion for the intended `network` of an EVM transaction. properties: type: type: string description: The type of criterion to use. This should be `evmNetwork`. example: evmNetwork enum: - evmNetwork networks: type: array description: >- A list of EVM network identifiers that the transaction's intended `network` should be compared to. items: type: string description: The network the transaction is for. enum: - base-sepolia - base - ethereum - ethereum-sepolia - avalanche - polygon - optimism - arbitrum - arbitrum-sepolia - zora - bnb - world - world-sepolia example: base-sepolia example: - base - ethereum operator: type: string description: >- The operator to use for the comparison. The transaction's intended `network` will be on the left-hand side of the operator, and the `networks` field will be on the right-hand side. enum: - in - not in example: in required: - type - networks - operator EvmDataCriterion: type: object x-audience: public title: EvmDataCriterion description: >- A schema for specifying a criterion for the `data` field of an EVM transaction. properties: type: type: string description: The type of criterion to use. This should be `evmData`. example: evmData enum: - evmData abi: description: >- The ABI of the smart contract being called. This can be a partial structure with only specific functions. oneOf: - $ref: '#/components/schemas/KnownAbiType' - $ref: '#/components/schemas/Abi' example: erc20 conditions: type: array description: >- A list of conditions to apply against the function and encoded arguments in the transaction's `data` field. Each condition must be met in order for this policy to be accepted or rejected. items: $ref: '#/components/schemas/EvmDataCondition' example: - function: approve - function: transfer params: - name: value operator: <= value: '10000' - name: to operator: in values: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' required: - type - abi - conditions EvmMessageCriterion: type: object x-audience: public title: EvmMessageCriterion description: A schema for specifying a criterion for the message being signed. properties: type: type: string description: The type of criterion to use. This should be `evmMessage`. example: evmMessage enum: - evmMessage match: type: string description: >- A regular expression the message is matched against. Accepts valid regular expression syntax described by [RE2](https://github.com/google/re2/wiki/Syntax). example: ^hello ([a-z]+)$ required: - type - match SignEvmTypedDataFieldCriterion: x-audience: public type: object title: SignEvmTypedDataFieldCriterion properties: type: type: string description: The type of criterion to use. This should be `evmTypedDataField`. example: evmTypedDataField enum: - evmTypedDataField types: type: object description: >- An object containing EIP-712 type definitions, as well as a primary type for the root message object. example: primaryType: Mail types: Person: - name: name type: string - name: wallet type: address - name: score type: uint256 Mail: - name: from type: Person - name: to type: Person - name: contents type: string properties: types: type: object description: EIP-712 compliant map of model names to model definitions. additionalProperties: type: array description: >- Object containing names and types for fields within structured data. items: type: object properties: name: type: string description: The name of a key within an EIP-712 data structure. type: type: string description: >- The Solidity type of a value within an EIP-712 data structure. primaryType: type: string description: >- The name of the root EIP-712 type. This value must be included in the `types` object. required: - types - primaryType conditions: type: array items: oneOf: - $ref: '#/components/schemas/EvmTypedAddressCondition' - $ref: '#/components/schemas/EvmTypedNumericalCondition' - $ref: '#/components/schemas/EvmTypedStringCondition' description: >- A list of conditions to check against the data being signed. Each condition must be met for the rule to take effect. example: - addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in path: to.wallet - value: '50' operator: '>=' path: to.score - match: ^hello ([a-z]+)$ path: contents required: - type - types - conditions SignEvmTypedDataVerifyingContractCriterion: type: object x-audience: public title: SignEvmTypedDataVerifyingContractCriterion description: A schema for specifying criterion for a domain's verifying contract. properties: type: type: string description: >- The type of criterion to use. This should be `evmTypedDataVerifyingContract`. example: evmTypedDataVerifyingContract enum: - evmTypedDataVerifyingContract addresses: type: array description: >- A list of 0x-prefixed EVM addresses that the domain's verifying contract should be compared to. There is a limit of 300 addresses per criterion. items: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed EVM address that the domain's verifying contract should be compared to. example: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' - '0x1234567890123456789012345678901234567890' operator: type: string description: >- The operator to use for the comparison. The domain's verifying contract will be on the left-hand side of the operator, and the `addresses` field will be on the right-hand side. enum: - in - not in example: in required: - type - addresses - operator NetUSDChangeCriterion: type: object title: NetUSDChangeCriterion description: >- A schema for specifying a criterion for the USD denominated asset transfer or exposure for a transaction. This includes native transfers, as well as token transfers. properties: type: type: string description: The type of criterion to use. This should be `netUSDChange`. example: netUSDChange enum: - netUSDChange changeCents: type: integer description: >- The amount of USD, in cents, that the total value of a transaction's asset transfer should be compared to. example: 10000 operator: type: string description: >- The operator to use for the comparison. The total value of a transaction's asset transfer will be on the left-hand side of the operator, and the `changeCents` field will be on the right-hand side. enum: - '>' - '>=' - < - <= - '==' example: <= required: - type - changeCents - operator SolAddressCriterion: type: object title: SolAddressCriterion description: >- The criterion for the recipient addresses of a Solana transaction's native transfer instruction. properties: type: type: string description: The type of criterion to use. This should be `solAddress`. example: solAddress enum: - solAddress addresses: type: array description: >- The Solana addresses that are compared to the list of native transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The Solana address that is compared to the list of native transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array. example: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: type: string description: >- The operator to use for the comparison. Each of the native transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array will be on the left-hand side of the operator, and the `addresses` field will be on the right-hand side. enum: - in - not in example: in required: - type - addresses - operator SolValueCriterion: x-audience: public type: object title: SolValueCriterion description: >- The criterion for the SOL value in lamports of a native transfer instruction in a Solana transaction. properties: type: type: string description: The type of criterion to use. This should be `solValue`. example: solValue enum: - solValue solValue: type: string description: >- The amount of SOL in lamports that the transaction instruction's `value` field should be compared to. example: '1000000000000000000' operator: type: string description: >- The operator to use for the comparison. The transaction instruction's `value` field will be on the left-hand side of the operator, and the `solValue` field will be on the right-hand side. enum: - '>' - '>=' - < - <= - '==' example: <= required: - type - solValue - operator SplAddressCriterion: x-audience: public type: object title: SplAddressCriterion description: >- The criterion for the recipient addresses of a Solana transaction's SPL token transfer instructions. properties: type: type: string description: The type of criterion to use. This should be `splAddress`. example: splAddress enum: - splAddress addresses: type: array description: >- The Solana addresses that are compared to the list of SPL token transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The Solana address that 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. example: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: type: string description: >- The operator to use for the comparison. Each of the SPL token transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array will be on the left-hand side of the operator, and the `addresses` field will be on the right-hand side. enum: - in - not in example: in required: - type - addresses - operator SplValueCriterion: x-audience: public type: object title: SplValueCriterion description: >- The criterion for the SPL token value of a SPL token transfer instruction in a Solana transaction. properties: type: type: string description: The type of criterion to use. This should be `splValue`. example: splValue enum: - splValue splValue: type: string description: >- The amount of the SPL token that the transaction instruction's `value` field should be compared to. example: '1000000000000000000' operator: type: string description: >- The operator to use for the comparison. The transaction instruction's `value` field will be on the left-hand side of the operator, and the `splValue` field will be on the right-hand side. enum: - '>' - '>=' - < - <= - '==' example: <= required: - type - splValue - operator MintAddressCriterion: x-audience: public type: object title: MintAddressCriterion description: >- The criterion for the token mint addresses of a Solana transaction's SPL token transfer instructions. properties: type: type: string description: The type of criterion to use. This should be `mintAddress`. example: mintAddress enum: - mintAddress addresses: type: array description: >- The Solana addresses that are compared to the list of token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The Solana address that is compared to the list of token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array. example: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: type: string description: >- The operator to use for the comparison. Each of the token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array will be on the left-hand side of the operator, and the `addresses` field will be on the right-hand side. enum: - in - not in example: in required: - type - addresses - operator SolDataCriterion: x-audience: public type: object description: >- A schema for specifying criterion for instruction data in a Solana transaction. properties: type: type: string description: The type of criterion to use. This should be `solData`. example: solData enum: - solData idls: type: array description: >- List of IDL specifications. Can contain known program names (strings) or custom IDL objects. items: oneOf: - $ref: '#/components/schemas/KnownIdlType' - $ref: '#/components/schemas/Idl' example: - SystemProgram - TokenProgram - address: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA instructions: - name: transfer_checked discriminator: - 119 - 250 - 202 - 24 - 253 - 135 - 244 - 121 args: - name: amount type: u64 - name: decimals type: u8 conditions: type: array description: >- A list of conditions to apply against the transaction instruction. Only one condition must evaluate to true for this criterion to be met. items: $ref: '#/components/schemas/SolDataCondition' example: - instruction: transfer_checked params: - name: lamports operator: <= value: '1000000' - name: space operator: '==' value: '64' required: - type - idls - conditions SolMessageCriterion: x-audience: public type: object title: SolMessageCriterion description: The criterion for the message of a Solana transaction. properties: type: type: string description: The type of criterion to use. This should be `solMessage`. example: solMessage enum: - solMessage match: type: string description: A regular expression the field is matched against. example: ^hello ([a-z]+)$ required: - type - match ProgramIdCriterion: x-audience: public type: object title: ProgramIdCriterion description: >- The criterion for the program IDs of a Solana transaction's instructions. properties: type: type: string description: The type of criterion to use. This should be `programId`. example: programId enum: - programId programIds: type: array description: >- The Solana program IDs that are compared to the list of program IDs in the transaction's instructions. items: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: >- The Solana program ID that is compared to the list of program IDs in the transaction's instructions. example: - TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA - '11111111111111111111111111111112' operator: type: string description: >- The operator to use for the comparison. Each of the program IDs in the transaction's instructions will be on the left-hand side of the operator, and the `programIds` field will be on the right-hand side. enum: - in - not in example: in required: - type - programIds - operator SolNetworkCriterion: x-audience: public type: object title: SolNetworkCriterion description: The criterion for the Solana network of a transaction. properties: type: type: string description: The type of criterion to use. This should be `solNetwork`. example: solNetwork enum: - solNetwork networks: type: array description: >- The Solana networks that the transaction's intended network should be compared to. items: type: string description: The Solana network the transaction is for. enum: - solana-devnet - solana example: solana-devnet example: - solana-devnet - solana operator: type: string description: >- The operator to use for the comparison. The transaction's intended network will be on the left-hand side of the operator, and the `networks` field will be on the right-hand side. enum: - in - not in example: in required: - type - networks - operator SignEvmTransactionCriteria: type: array description: A schema for specifying criteria for the SignEvmTransaction operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in SendEvmTransactionCriteria: x-audience: public type: array description: A schema for specifying criteria for the SignEvmTransaction operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in SignEvmMessageCriteria: x-audience: public type: array description: >- A schema for specifying the rejection criteria for the SignEvmMessage operation. items: oneOf: - $ref: '#/components/schemas/EvmMessageCriterion' example: - type: evmMessage match: ^hello ([a-z]+)$ SignEvmTypedDataCriteria: x-audience: public type: array description: A schema for specifying criteria for the SignEvmTypedData operation. items: oneOf: - $ref: '#/components/schemas/SignEvmTypedDataFieldCriterion' - $ref: '#/components/schemas/SignEvmTypedDataVerifyingContractCriterion' example: - type: evmTypedDataField types: types: Person: - name: name type: string - name: wallet type: address - name: score type: uint256 Mail: - name: from type: Person - name: to type: Person - name: contents type: string primaryType: Mail conditions: - addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in path: to.wallet - value: '50' operator: '>=' path: to.score - match: ^hello ([a-z]+)$ path: contents - type: evmTypedDataVerifyingContract addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in SignSolTransactionCriteria: type: array x-audience: public description: A schema for specifying criteria for the SignSolTransaction operation. items: oneOf: - $ref: '#/components/schemas/SolAddressCriterion' - $ref: '#/components/schemas/SolValueCriterion' - $ref: '#/components/schemas/SplAddressCriterion' - $ref: '#/components/schemas/SplValueCriterion' - $ref: '#/components/schemas/MintAddressCriterion' - $ref: '#/components/schemas/SolDataCriterion' - $ref: '#/components/schemas/ProgramIdCriterion' example: - type: solAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in SendSolTransactionCriteria: x-audience: public type: array description: A schema for specifying criteria for the SendSolTransaction operation. items: oneOf: - $ref: '#/components/schemas/SolAddressCriterion' - $ref: '#/components/schemas/SolValueCriterion' - $ref: '#/components/schemas/SplAddressCriterion' - $ref: '#/components/schemas/SplValueCriterion' - $ref: '#/components/schemas/MintAddressCriterion' - $ref: '#/components/schemas/SolDataCriterion' - $ref: '#/components/schemas/ProgramIdCriterion' - $ref: '#/components/schemas/SolNetworkCriterion' example: - type: solAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: solValue solValue: '1000000000000000000' operator: <= SignSolMessageCriteria: x-audience: public type: array description: A schema for specifying criteria for the SignSolMessage operation. items: oneOf: - $ref: '#/components/schemas/SolMessageCriterion' example: - type: solMessage match: ^hello ([a-z]+)$ PrepareUserOperationCriteria: x-audience: public type: array description: A schema for specifying criteria for the PrepareUserOperation operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in SendUserOperationCriteria: x-audience: public type: array description: A schema for specifying criteria for the SendUserOperation operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in SignEndUserEvmTransactionCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the signEndUserEvmTransaction operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in - type: evmData abi: erc20 conditions: - function: transfer params: - name: value operator: <= value: '10000' - type: netUSDChange changeCents: 10000 operator: <= SendEndUserEvmTransactionCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the sendEndUserEvmTransaction operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in - type: evmNetwork networks: - base - ethereum operator: in - type: evmData abi: erc20 conditions: - function: transfer params: - name: value operator: <= value: '10000' - type: netUSDChange changeCents: 10000 operator: <= SignEndUserEvmMessageCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the signEndUserEvmMessage operation. items: oneOf: - $ref: '#/components/schemas/EvmMessageCriterion' example: - type: evmMessage match: ^hello ([a-z]+)$ SignEndUserEvmTypedDataCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the signEndUserEvmTypedData operation. items: oneOf: - $ref: '#/components/schemas/SignEvmTypedDataFieldCriterion' - $ref: '#/components/schemas/SignEvmTypedDataVerifyingContractCriterion' example: - type: evmTypedDataField types: types: Person: - name: name type: string - name: wallet type: address - name: score type: uint256 Mail: - name: from type: Person - name: to type: Person - name: contents type: string primaryType: Mail conditions: - addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in path: to.wallet - value: '50' operator: '>=' path: to.score - match: ^hello ([a-z]+)$ path: contents - type: evmTypedDataVerifyingContract addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in SignEndUserSolTransactionCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the signEndUserSolTransaction operation. items: oneOf: - $ref: '#/components/schemas/SolAddressCriterion' - $ref: '#/components/schemas/SolValueCriterion' - $ref: '#/components/schemas/SplAddressCriterion' - $ref: '#/components/schemas/SplValueCriterion' - $ref: '#/components/schemas/MintAddressCriterion' - $ref: '#/components/schemas/SolDataCriterion' - $ref: '#/components/schemas/ProgramIdCriterion' example: - type: solAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: solValue solValue: '1000000000000000000' operator: <= - type: splAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: splValue splValue: '1000000000000000000' operator: <= - type: mintAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: solData idls: - SystemProgram conditions: - instruction: transfer_checked params: - name: lamports operator: <= value: '1000000' - type: programId programIds: - TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA operator: in SendEndUserSolTransactionCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the sendEndUserSolTransaction operation. items: oneOf: - $ref: '#/components/schemas/SolAddressCriterion' - $ref: '#/components/schemas/SolValueCriterion' - $ref: '#/components/schemas/SplAddressCriterion' - $ref: '#/components/schemas/SplValueCriterion' - $ref: '#/components/schemas/MintAddressCriterion' - $ref: '#/components/schemas/SolDataCriterion' - $ref: '#/components/schemas/ProgramIdCriterion' - $ref: '#/components/schemas/SolNetworkCriterion' example: - type: solAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: solValue solValue: '1000000000000000000' operator: <= - type: splAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: splValue splValue: '1000000000000000000' operator: <= - type: mintAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: solData idls: - SystemProgram conditions: - instruction: transfer_checked params: - name: lamports operator: <= value: '1000000' - type: programId programIds: - TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA operator: in - type: solNetwork networks: - solana-devnet - solana operator: in SignEndUserSolMessageCriteria: x-audience: public type: array description: >- A schema for specifying criteria for the signEndUserSolMessage operation. items: oneOf: - $ref: '#/components/schemas/SolMessageCriterion' example: - type: solMessage match: ^hello ([a-z]+)$ SendEndUserEvmAssetCriteria: x-audience: public type: array description: A schema for specifying criteria for the sendEndUserEvmAsset operation. items: oneOf: - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in - type: evmNetwork networks: - base - ethereum operator: in - type: evmData abi: erc20 conditions: - function: transfer params: - name: value operator: <= value: '10000' - type: netUSDChange changeCents: 10000 operator: <= SendEndUserSolAssetCriteria: x-audience: public type: array description: A schema for specifying criteria for the sendEndUserSolAsset operation. items: oneOf: - $ref: '#/components/schemas/SplAddressCriterion' - $ref: '#/components/schemas/SplValueCriterion' - $ref: '#/components/schemas/SolDataCriterion' - $ref: '#/components/schemas/SolNetworkCriterion' example: - type: splAddress addresses: - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT operator: in - type: splValue splValue: '1000000000000000000' operator: <= - type: solData idls: - SystemProgram conditions: - instruction: transfer_checked params: - name: lamports operator: <= value: '1000000' - type: solNetwork networks: - solana-devnet - solana operator: in SendEndUserOperationCriteria: x-audience: public type: array description: A schema for specifying criteria for the sendEndUserOperation operation. items: oneOf: - $ref: '#/components/schemas/EthValueCriterion' - $ref: '#/components/schemas/EvmAddressCriterion' - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: ethValue ethValue: '1000000' operator: '>=' - type: evmAddress addresses: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' operator: in - type: evmNetwork networks: - base - ethereum operator: in - type: evmData abi: erc20 conditions: - function: transfer params: - name: value operator: <= value: '10000' - type: netUSDChange changeCents: 10000 operator: <= CreateEndUserEvmSwapCriteria: x-audience: public type: array description: A schema for specifying criteria for the createEndUserEvmSwap operation. items: oneOf: - $ref: '#/components/schemas/EvmNetworkCriterion' - $ref: '#/components/schemas/EvmDataCriterion' - $ref: '#/components/schemas/NetUSDChangeCriterion' example: - type: evmNetwork networks: - base - ethereum operator: in - type: evmData abi: erc20 conditions: - function: transfer params: - name: value operator: <= value: '10000' - type: netUSDChange changeCents: 10000 operator: <= ObservedArgument: type: object title: ObservedArgument description: A decoded function or instruction argument. example: name: value type: uint256 value: '25000000' truncated: false properties: name: type: string maxLength: 256 description: >- The argument name from the ABI or IDL. Empty when the ABI leaves it unnamed. example: value type: type: string maxLength: 256 description: The argument type from the ABI or IDL. example: uint256 value: type: string maxLength: 256 description: >- The decoded value as text: integers in decimal base units, EVM addresses 0x-prefixed, Solana public keys in base58, bytes 0x-prefixed hex, booleans `true` or `false`, strings as-is, and arrays, tuples, and structs as compact JSON. example: '25000000' truncated: type: boolean description: Whether `value` was cut to its first 256 characters. example: false required: - name - type - value - truncated additionalProperties: false ObservedMessageText: type: string maxLength: 2048 description: >- The message exactly as matched, including line breaks. When `encoding` is `hex`, the message bytes are not valid UTF-8 and are shown as a 0x-prefixed hex string instead. example: Hello, world ObservedMessageEncoding: type: string description: >- How `message` represents the matched bytes: `utf8` for the text itself, or `hex` for a 0x-prefixed hex string when the bytes are not valid UTF-8. enum: - utf8 - hex x-go-type: string example: utf8 ObservedTypedDataField: type: object title: ObservedTypedDataField description: >- The value an `evmTypedDataField` condition read from the typed data message. example: conditionIndex: 1 value: '40' truncated: false properties: conditionIndex: type: integer minimum: 0 description: Zero-based index into the criterion's `conditions`. example: 1 value: type: string maxLength: 256 description: >- The value at the condition's `path`, as text in the same format as `ObservedArgument.value`. Omitted when the message has no value at that path. example: '40' truncated: type: boolean description: Whether `value` was cut to its first 256 characters. example: false required: - conditionIndex - truncated additionalProperties: false ObservedInstruction: type: object title: ObservedInstruction description: A Solana instruction as decoded by a `solData` criterion. example: index: 1 programId: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA instruction: transfer_checked arguments: - name: amount type: u64 value: '2000000' truncated: false properties: index: type: integer minimum: 0 description: Zero-based index of the instruction in the transaction. example: 1 programId: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The program the instruction invokes. example: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA instruction: type: string maxLength: 256 description: >- The instruction name from the IDL. Omitted when no IDL in the criterion decodes the instruction. example: transfer_checked arguments: type: array maxItems: 32 description: >- The decoded arguments, in IDL order. Empty when `instruction` is omitted. Only the first 32 arguments are returned. items: $ref: '#/components/schemas/ObservedArgument' required: - index - programId - arguments additionalProperties: false RateLimitUsage: description: >- The usage totals the criterion compared, discriminated by `type`: `count` when the criterion sets `maxCount`, `value` when it sets `maxValueCents`. example: type: count windowCount: 10 pendingCount: 0 oneOf: - $ref: '#/components/schemas/RateLimitCountUsage' - $ref: '#/components/schemas/RateLimitValueUsage' discriminator: propertyName: type mapping: count: '#/components/schemas/RateLimitCountUsage' value: '#/components/schemas/RateLimitValueUsage' KnownAbiType: type: string title: KnownAbiType description: >- A reference to an established EIP standard. When referencing a `KnownAbiType` within a policy rule configuring an `EvmDataCriterion`, criteria will only decode function data officially documented in the standard. For more information on supported token standards, see the links below. - [erc20 - Token Standard](https://eips.ethereum.org/EIPS/eip-20). - [erc721 - Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721). - [erc1155 - Multi Token Standard](https://eips.ethereum.org/EIPS/eip-1155). enum: - erc20 - erc721 - erc1155 Abi: x-audience: public type: array description: >- Contract ABI Specification following Solidity's external JSON interface format. items: oneOf: - $ref: '#/components/schemas/AbiFunction' - $ref: '#/components/schemas/AbiInput' example: - type: function name: approve inputs: - name: spender type: address internalType: address - name: amount type: uint256 internalType: uint256 outputs: - name: null type: bool internalType: bool stateMutability: nonpayable - type: event name: Transfer inputs: - name: from type: address indexed: true internalType: address anonymous: false - type: error name: ERC20InvalidSpender inputs: - name: spender type: address internalType: address EvmDataCondition: type: object x-audience: public description: >- A single condition to apply against the function and encoded arguments in the transaction's `data` field. Each `parameter` configuration must be successfully evaluated against the corresponding function argument in order for a policy to be accepted. properties: function: type: string example: transfer description: The name of a smart contract function being called. params: type: array description: >- An optional list of parameter conditions to apply against encoded arguments in the transaction's `data` field. items: description: >- A list of parameter conditions to apply against encoded arguments in the transaction's `data` field. oneOf: - $ref: '#/components/schemas/EvmDataParameterCondition' - $ref: '#/components/schemas/EvmDataParameterConditionList' example: - name: value operator: <= value: '10000' - name: to operator: in values: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' example: function: transfer params: - name: value operator: <= value: '10000' - name: to operator: in values: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' required: - function EvmTypedAddressCondition: type: object x-audience: public title: EvmTypedAddressCondition description: >- A schema for specifying criterion for an address field of an EVM typed message. The address can be deeply nested within the typed data's message. properties: addresses: type: array description: >- A list of 0x-prefixed EVM addresses that the value located at the message's path should be compared to. There is a limit of 300 addresses per criterion. items: type: string pattern: ^0x[0-9a-fA-F]{40}$ description: >- The 0x-prefixed EVM address that the value located at the message's path should be compared to. example: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' - '0x1234567890123456789012345678901234567890' operator: type: string description: >- The operator to use for the comparison. The value located at the message's path will be on the left-hand side of the operator, and the `addresses` field will be on the right-hand side. enum: - in - not in example: in path: type: string description: >- The path to the field to compare against this criterion. To reference deeply nested fields within the message, separate object keys by `.`, and access array values using `[index]`. If the field does not exist or is not an address, the operation will be rejected. example: targets[0].address required: - addresses - operator - path EvmTypedNumericalCondition: type: object x-audience: public title: EvmTypedNumericalCondition description: >- A schema for specifying criterion for a numerical field of an EVM typed message. The value can be deeply nested within the typed data's message. properties: value: type: string pattern: ^[0-9]+$ description: >- The amount that the value located at the message's path should be compared to. example: '1000000000000000000' operator: type: string description: >- The operator to use for the comparison. The value located at the message's path will be on the left-hand side of the operator, and the `value` field will be on the right-hand side. enum: - '>' - '>=' - < - <= - '==' example: <= path: type: string description: >- The path to the field to compare against this criterion. To reference deeply nested fields within the message, separate object keys by `.`, and access array values using `[index]`. If the field does not exist or is not an address, the operation will be rejected. example: targets[0].amount required: - value - operator - path EvmTypedStringCondition: type: object x-audience: public title: EvmTypedStringCondition description: >- A schema for specifying criterion for a string field of an EVM typed message. The value can be deeply nested within the typed data's message. properties: match: type: string description: A regular expression the field is matched against. example: ^hello ([a-z]+)$ path: type: string description: >- The path to the field to compare against this criterion. To reference deeply nested fields within the message, separate object keys by `.`, and access array values using `[index]`. If the field does not exist or is not an address, the operation will be rejected. example: targets[0].message required: - match - path KnownIdlType: type: string x-audience: public title: KnownIdlType description: >- A reference to an established Solana program. When referencing a `KnownIdlType` within a policy rule configuring an `SolDataCriterion`, criteria will decode instruction data as documented in the programs. For more information on supported programs, see the links below. - [SystemProgram](https://docs.rs/solana-program/latest/solana_program/system_instruction/enum.SystemInstruction.html). - [TokenProgram](https://docs.rs/spl-token/latest/spl_token/instruction/enum.TokenInstruction.html). - [AssociatedTokenProgram](https://docs.rs/spl-associated-token-account/latest/spl_associated_token_account/instruction/index.html). enum: - SystemProgram - TokenProgram - AssociatedTokenProgram Idl: x-audience: public type: object description: IDL Specification following Anchor's IDL format v0.30+. required: - address - instructions properties: address: type: string description: The program address. example: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA instructions: type: array description: List of program instructions. example: - name: transfer_checked discriminator: - 119 - 250 - 202 - 24 - 253 - 135 - 244 - 121 accounts: - name: mint writable: true - name: rent args: - name: amount type: u64 - name: decimals type: u8 items: type: object required: - name - discriminator - args properties: name: type: string description: The instruction name. example: transfer_checked discriminator: type: array description: Array of 8 numbers representing the instruction discriminator. items: type: integer minimum: 0 maximum: 255 minItems: 8 maxItems: 8 example: - 119 - 250 - 202 - 24 - 253 - 135 - 244 - 121 args: type: array description: List of instruction arguments. items: type: object required: - name - type properties: name: type: string description: The argument name. example: amount type: type: string description: The argument type. example: u64 accounts: type: array description: Optional list of accounts required by the instruction. items: type: object required: - name properties: name: type: string description: The account name. example: mint writable: type: boolean description: Whether the account is writable. example: true signer: type: boolean description: Whether the account must be a signer. example: false metadata: type: object description: Optional metadata about the IDL. example: name: system_program version: 0.1.0 spec: 0.1.0 properties: name: type: string description: The program name. example: system_program version: type: string description: The program version. example: 0.1.0 spec: type: string description: The IDL specification version. example: 0.1.0 types: type: array description: >- Optional type definitions for custom data structures used in the program. items: type: object example: - name: MyStruct type: struct fields: - name: id type: u64 - name: owner type: pubkey SolDataCondition: type: object x-audience: public description: >- A single condition to apply against a specific instruction type and its parameters. properties: instruction: type: string description: The instruction name. example: transfer_checked params: type: array description: Parameter conditions for the instruction. items: description: >- A list of parameter conditions to apply against a specific instruction's data. oneOf: - $ref: '#/components/schemas/SolDataParameterCondition' - $ref: '#/components/schemas/SolDataParameterConditionList' example: - name: amount operator: <= value: '1000000' - name: decimals operator: '==' value: '6' - name: owner operator: in values: - TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA - So11111111111111111111111111111111111111112 required: - instruction RateLimitCountUsage: type: object title: RateLimitCountUsage description: >- Operation counts for a `maxCount` criterion. The criterion is met when `windowCount + pendingCount + 1 <= maxCount` and unmet when the sum exceeds `maxCount`, where `1` is this operation. example: type: count windowCount: 10 pendingCount: 0 properties: type: type: string description: The usage type. enum: - count x-go-type: string example: count windowCount: type: integer minimum: 0 description: Operations counted in the current `window`. example: 10 pendingCount: type: integer minimum: 0 description: >- Operations added by earlier units of this simulation request. They are not persisted. Always `0` when `evaluatedUnit` is absent. example: 0 required: - type - windowCount - pendingCount additionalProperties: false RateLimitValueUsage: type: object title: RateLimitValueUsage description: >- USD totals, in cents, for a `maxValueCents` criterion. The criterion is met when `windowCents + pendingCents + operationCents <= maxValueCents` and unmet when the sum exceeds `maxValueCents`. example: type: value windowCents: 95000 pendingCents: 0 operationCents: 12550 properties: type: type: string description: The usage type. enum: - value x-go-type: string example: value windowCents: type: integer minimum: 0 description: USD value, in cents, counted in the current `window`. example: 95000 pendingCents: type: integer minimum: 0 description: >- USD value, in cents, added by earlier units of this simulation request. It is not persisted. Always `0` when `evaluatedUnit` is absent. example: 0 operationCents: type: integer minimum: 0 description: The absolute USD value, in cents, of this operation. example: 12550 required: - type - windowCents - pendingCents - operationCents additionalProperties: false AbiFunction: x-audience: public type: object title: AbiFunction description: ABI function type for contract functions. required: - type - name - inputs - outputs - stateMutability properties: type: description: The type of the ABI item, must be `function`. type: string enum: - function example: function name: type: string description: The name of the ABI function. example: approve inputs: type: array description: The list of ABI parameters used for this function. items: $ref: '#/components/schemas/AbiParameter' example: - name: spender type: address internalType: address outputs: type: array description: The values returned by this function. items: $ref: '#/components/schemas/AbiParameter' example: name: '' type: bool internalType: bool constant: type: boolean description: Deprecated. Use pure or view from stateMutability instead. example: false payable: type: boolean description: >- Deprecated. Use payable or nonpayable from `stateMutability` instead. example: false stateMutability: $ref: '#/components/schemas/AbiStateMutability' gas: type: integer description: Deprecated. Vyper used to provide gas estimates. example: 0 example: type: function name: balanceOf inputs: - name: owner type: address internalType: address outputs: - name: null type: uint256 internalType: uint256 stateMutability: view AbiInput: x-audience: public type: object title: AbiInput description: Generic ABI item type encapsulating all other types besides `function`. required: - type properties: type: description: The type of the ABI item. type: string enum: - constructor - error - event - fallback - receive example: constructor additionalProperties: description: >- For additional information on the ABI JSON specification, see [the Solidity documentation](https://docs.soliditylang.org/en/latest/abi-spec.html#json). example: type: error name: ERC20InvalidSpender inputs: - name: spender type: address internalType: address EvmDataParameterCondition: x-audience: public type: object title: EvmDataParameterCondition properties: name: type: string example: to description: >- The name of the parameter to check against a transaction's calldata. If name is unknown, or is not named, you may supply an array index, e.g., `0` for first parameter. operator: type: string enum: - '>' - '>=' - < - <= - '==' description: >- The operator to use for the comparison. The value resolved at the `name` will be on the left-hand side of the operator, and the `value` field will be on the right-hand side. example: '==' value: type: string example: '100000' description: >- A single value to compare the value resolved at `name` to. All values are encoded as strings. Refer to the table in the documentation for how values should be encoded, and which operators are supported for each type. required: - name - operator - value EvmDataParameterConditionList: x-audience: public type: object title: EvmDataParameterConditionList properties: name: type: string example: to description: >- The name of the parameter to check against a transaction's calldata. If name is unknown, or is not named, you may supply an array index, e.g., `0` for first parameter. operator: type: string enum: - in - not in description: >- The operator to use for the comparison. The value resolved at the `name` will be on the left-hand side of the operator, and the `values` field will be on the right-hand side. example: in values: type: array items: type: string example: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' description: >- A single potential value to compare against the resolved `name` value. All values are encoded as strings. Refer to the table in the documentation for how values should be encoded, and which operators are supported for each type. description: >- Values to compare against the resolved `name` value. All values are encoded as strings. Refer to the table in the documentation for how values should be encoded, and which operators are supported for each type. example: - '0x742d35Cc6634C0532925a3b844Bc454e4438f44e' required: - name - operator - values SolDataParameterCondition: type: object x-audience: public title: SolDataParameterCondition description: >- A single parameter condition to apply against a specific instruction's parameters. properties: name: type: string description: The parameter name. example: amount operator: type: string enum: - '>' - '>=' - < - <= - '==' description: >- The operator to use for the comparison. The value resolved at the `name` will be on the left-hand side of the operator, and the `value` field will be on the right-hand side. example: '==' value: type: string description: The value to compare against. example: '1000000' required: - name - operator - value SolDataParameterConditionList: type: object x-audience: public title: SolDataParameterConditionList description: >- A single parameter condition to apply against a specific instruction's parameters. properties: name: type: string description: The parameter name. example: amount operator: type: string description: >- The operator to use for the comparison. The value resolved at the `name` will be on the left-hand side of the operator, and the `value` field will be on the right-hand side. enum: - in - not in example: in values: type: array description: The values to compare against. items: type: string description: >- A single potential value to compare against the resolved `name` value. example: '1000000' example: - '1000000' - HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT - '6' required: - name - operator - values AbiParameter: x-audience: public type: object description: Parameter definition for ABI functions, errors, and constructors. required: - type properties: name: type: string description: The name of the parameter. example: tokenId type: type: string description: The canonical type of the parameter. example: uint256 internalType: type: string description: The internal Solidity type used by the compiler. example: uint256 components: type: array description: Used for tuple types. items: $ref: '#/components/schemas/AbiParameter' example: - name: x type: uint256 example: name: tokenId type: uint256 internalType: uint256 AbiStateMutability: x-audience: public type: string description: State mutability of a function in Solidity. enum: - pure - view - nonpayable - payable example: view responses: UnauthorizedError: description: Unauthorized. x-error-types: - unauthorized content: application/json: schema: $ref: '#/components/schemas/Error' examples: unauthorized: $ref: '#/components/examples/Unauthorized' RateLimitExceeded: description: Rate limit exceeded. x-error-types: - rate_limit_exceeded content: application/json: schema: $ref: '#/components/schemas/Error' examples: rate_limit_exceeded: $ref: '#/components/examples/RateLimitExceeded' InternalServerError: description: Internal server error. x-error-types: - internal_server_error content: application/json: schema: $ref: '#/components/schemas/Error' examples: internal_server_error: $ref: '#/components/examples/InternalServerError' BadGatewayError: description: Bad gateway. x-error-types: - bad_gateway content: application/json: schema: $ref: '#/components/schemas/Error' examples: bad_gateway: $ref: '#/components/examples/BadGateway' ServiceUnavailableError: description: Service unavailable. x-error-types: - service_unavailable content: application/json: schema: $ref: '#/components/schemas/Error' examples: service_unavailable: $ref: '#/components/examples/ServiceUnavailable' examples: Unauthorized: value: errorType: unauthorized errorMessage: The request is not properly authenticated. RateLimitExceeded: value: errorType: rate_limit_exceeded errorMessage: Rate limit exceeded. InternalServerError: value: errorType: internal_server_error errorMessage: An internal server error occurred. Please try again later. BadGateway: value: errorType: bad_gateway errorMessage: Bad gateway. Please try again later. ServiceUnavailable: value: errorType: service_unavailable errorMessage: Service unavailable. Please try again later. 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. ````