forked from coinbase/cdp-sdk
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathopenapi.yaml
More file actions
10781 lines (10581 loc) · 429 KB
/
openapi.yaml
File metadata and controls
10781 lines (10581 loc) · 429 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
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: End User Accounts
x-audience: public
description: |-
The End User Accounts 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 Accounts APIs are accessed by the developer's servers and authenticated by the developer's CDP API key.
- name: EVM Accounts
x-audience: public
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).
<Tip>
**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.
</Tip>
- name: EVM Smart Accounts
x-audience: public
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
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
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
description: The Faucet APIs enable you to request funds on supported test networks. Faucets are for testing purposes and make development easier by providing a source of funds.
- name: Onchain Data
x-audience: public
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
description: |-
The v2 Onramp APIs are an evolution of our [v1 APIs](https://docs.cdp.coinbase.com/api-reference/rest-api/onramp-offramp/), designed to make the fiat-to-crypto experience feel native to your applications for higher conversion and less friction. These APIs only cover a subset of Coinbase Onramp functionality as described below, for all other use cases please refer to our [v1 APIs](https://docs.cdp.coinbase.com/api-reference/rest-api/onramp-offramp/).
## Supported Use Cases
#### Apple Pay Onramp
This use case allows you to offer an Apple Pay onramp experience with debit cards in your app without users needing to create or log into a Coinbase account. Our API returns a `paymentLink` URL that renders an Apple Pay button for you to load in a webview or iframe in your app, making the onramp experience feel native to your application.
Refer to our [detailed integration guide](https://docs.cdp.coinbase.com/onramp-&-offramp/onramp-apis/apple-pay-onramp-api) for more information on the limitations and requirements of this use case. See our [onramp mobile demo app](https://github.com/coinbase/onramp-demo-mobile) for a reference implementation.
#### Hosted UI Onramp
This use case enables you to offer a full-featured onramp experience by redirecting users to a Coinbase-hosted page where they can choose to log into their existing Coinbase account or proceed as a guest. The Onramp Session API generates secure, single-use Onramp URLs with customizable parameters, allowing you to control available payment methods, preset transaction amounts, and cryptocurrencies for a tailored user experience.
Refer to our [guide](https://docs.cdp.coinbase.com/onramp-&-offramp/onramp-apis/generating-onramp-url) for implementation details and customization options for this use case.
- name: Policy Engine
x-audience: public
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.
- 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.
Scope is specified in the `scope` field of a policy:
```json {
"description": "Project-level policy",
"scope": "account",
...
```
## Policy Evaluation
**Project-level policies** are evaluated first, followed by **account-level policies**.
The Policy Engine will process the request against each rule in the order it is defined within the `rules` array:
1. If the rule's `criteria` (processed as a logical **AND** operation applied to a list of independently evaluated boolean expressions) are met, `accept` or `reject` behavior is applied immediately and the engine stops further evaluation of the policy.
1. If after policy evaluation, no rule's `criteria` are met, the engine moves to processing the next policy (i.e., an `account`-level policy).
1. If no further policies exist, the request is rejected.
For example, the following policy is a project-level policy with two rules. The Policy Engine will:
1. **Evaluate the first rule:** For a `signEvmTransaction` request, accept the request if the transaction is less than or equal to 1000000000000000000 wei OR
1. **Evaluate the second rule:** if the request is a `signEvmTransaction` request, accept the request if the transaction is less than or equal to 2000000000000000000 wei AND the request is made to the address `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`.
1. **If the request does not meet the criteria of either rule**, the engine will move on to evaluate an `account`-level policy (if one exists).
1. Otherwise, the request is rejected.
Rules are processed in the order they are defined. Once a rule applies to an operation, subsequent rules are ignored.
```json
{
"description": "Project-level policy",
"scope": "project",
"rules": [
{
"action": "accept",
"operation": "signEvmTransaction",
"criteria": [
{
"type": "ethValue",
"ethValue": "1000000000000000000",
"operator": "<="
}
]
},
{
"action": "accept",
"operation": "signEvmTransaction",
"criteria": [
{
"type": "ethValue",
"ethValue": "2000000000000000000",
"operator": "<="
},
{
"type": "evmAddress",
"addresses": [
"0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"
],
"operator": "in"
}
]
}
]
}
```
## Policy Application
Project-level policies are applied to all accounts in a CDP Project. They will apply retroactively even if the project-level policy is created after the account was created. To disable a project-level policy, you must remove the project-level policy from the CDP Project using the `deletePolicy` operation.
Account-level policies can be applied in two ways:
- By specifying the `accountPolicy` field in the request body of the `createEvmAccount` and
`createSolAccount` operations.
- By specifying the `accountPolicy` field in the request body of the `updateEvmAccount` and
`updateSolanaAccount` operations.
## Criteria
The following criteria are supported:
### SignEvmTransaction Criteria
#### ethValue
A criterion based on the value of the transaction. The transaction's `value` field is compared to the criterion's `ethValue` field using the `operator` field.
#### evmAddress
A criterion based on the recipient address of the transaction. The transaction's `to` field is compared to the criterion's `addresses` field using the `operator` field.
#### evmData
A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`.
#### netUSDChange
A criterion based on the USD denominated market value of assets being transferred, or exposing the sender to. The types of assets included in the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155` tokens. The sum total USD amount of assets being transferred and exposed is compared to the criterion's `changeCents` field using the `operator` field. If signing a testnet transaction, then this criterion configuration will be ignored.
### SendEvmTransaction Criteria
#### ethValue
A criterion based on the value of the transaction. The transaction's `value` field is compared to the criterion's `ethValue` field using the `operator` field.
#### evmAddress
A criterion based on the recipient address of the transaction. The transaction's `to` field is compared to the criterion's `addresses` field using the `operator` field.
#### evmNetwork
A criterion based on the intended network of the transaction. The `network` field in the `sendEvmTransaction` request body is compared to the criterion's `networks` field using the `operator` field.
Valid networks for this criterion include:
- `base`
- `base-sepolia`
- `ethereum`
- `ethereum-sepolia`
- `avalanche`
- `polygon`
- `optimism`
- `arbitrum`
#### 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`
## 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
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).
<Tip>
**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.
</Tip>
- name: Solana Token Balances
x-audience: public
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 (Alpha)
x-audience: public
description: The SQL APIs enable you to write performant, high-freshness, and endlessly flexible SQL queries against onchain data.
- name: Webhooks
x-audience: public
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
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/end-users:
post:
summary: Create an end user
description: |-
Creates an end user. An end user is an entity that can own CDP EVM accounts, EVM smart accounts, and/or Solana accounts. 1 or more authentication methods must be associated with an end user. By default, no accounts are created unless the optional `evmAccount` and/or `solanaAccount` fields are provided.
This API is intended to be used by the developer's own backend, and is authenticated using the developer's CDP API key.
operationId: createEndUser
tags:
- End User Accounts
x-audience: public
security:
- apiKeyAuth: []
parameters:
- $ref: '#/components/parameters/XWalletAuth'
- $ref: '#/components/parameters/IdempotencyKey'
requestBody:
content:
application/json:
schema:
type: object
properties:
userId:
description: |-
A stable, unique identifier for the end user. The `userId` must be unique across all end users in the developer's CDP Project. It must be between 1 and 100 characters long and can only contain alphanumeric characters and hyphens.
If `userId` is not provided in the request, the server will generate a random UUID.
type: string
pattern: ^[a-zA-Z0-9-]{1,100}$
example: e051beeb-7163-4527-a5b6-35e301529ff2
authenticationMethods:
$ref: '#/components/schemas/AuthenticationMethods'
evmAccount:
type: object
description: Configuration for creating an EVM account for the end user.
properties:
createSmartAccount:
type: boolean
description: If true, creates an EVM smart account and a default EVM EOA account as the owner. If false, only a EVM EOA account is created.
default: false
example: true
solanaAccount:
type: object
description: Configuration for creating a Solana account for the end user.
properties:
createSmartAccount:
type: boolean
description: Only false is a valid option since currently smart accounts on Solana are not supported.
default: false
example: false
required:
- authenticationMethods
examples:
default_behavior:
summary: Default (no accounts created)
value:
authenticationMethods:
- type: email
email: user@example.com
evm_only:
summary: EVM account only
value:
authenticationMethods:
- type: email
email: user@example.com
evmAccount: {}
evm_with_smart_account:
summary: EVM only with smart account
value:
authenticationMethods:
- type: email
email: user@example.com
evmAccount:
createSmartAccount: true
solana_only:
summary: Solana account only
value:
authenticationMethods:
- type: sms
phoneNumber: '+15555551234'
solanaAccount:
createSmartAccount: false
evm_and_solana:
summary: Both EVM and Solana accounts
value:
authenticationMethods:
- type: sms
phoneNumber: '+15555551234'
evmAccount:
createSmartAccount: true
solanaAccount:
createSmartAccount: false
responses:
'201':
description: Successfully created end user.
content:
application/json:
schema:
$ref: '#/components/schemas/EndUser'
examples:
default_no_accounts:
summary: Default behavior - No accounts created
value:
userId: user-001
authenticationMethods:
- type: email
email: user@example.com
evmAccounts: []
evmAccountObjects: []
evmSmartAccounts: []
evmSmartAccountObjects: []
solanaAccounts: []
solanaAccountObjects: []
createdAt: '2025-11-17T10:00:00Z'
evm_smart_account_only:
summary: EVM smart account only
value:
userId: user-003
authenticationMethods:
- type: email
email: user@example.com
evmAccounts:
- '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
evmAccountObjects:
- address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
createdAt: '2025-11-17T10:00:00Z'
evmSmartAccounts:
- '0x842d35Cc6634C0532925a3b844Bc454e4438f55f'
evmSmartAccountObjects:
- address: '0x842d35Cc6634C0532925a3b844Bc454e4438f55f'
ownerAddresses:
- '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
createdAt: '2025-11-17T10:00:00Z'
solanaAccounts: []
solanaAccountObjects: []
createdAt: '2025-11-17T10:00:00Z'
solana_only:
summary: Solana account only
value:
userId: user-004
authenticationMethods:
- type: sms
phoneNumber: '+15555551234'
evmAccounts: []
evmAccountObjects: []
evmSmartAccounts: []
evmSmartAccountObjects: []
solanaAccounts:
- HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT
solanaAccountObjects:
- address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT
createdAt: '2025-11-17T10:00:00Z'
createdAt: '2025-11-17T10:00:00Z'
evm_no_smart_account:
summary: EVM without smart account
value:
userId: user-004
authenticationMethods:
- type: email
email: user@example.com
evmAccounts:
- '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
evmAccountObjects:
- address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
createdAt: '2025-11-17T10:00:00Z'
evmSmartAccounts: []
evmSmartAccountObjects: []
solanaAccounts: []
solanaAccountObjects: []
createdAt: '2025-11-17T10:00:00Z'
multiple_accounts:
summary: End user with multiple accounts created
value:
userId: user-005
authenticationMethods:
- type: email
email: user@example.com
evmAccounts:
- '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
- '0x8F2A9B5C3D4E6F7A8B9C0D1E2F3A4B5C6D7E8F9A'
- '0xA1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0'
evmAccountObjects:
- address: '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
createdAt: '2025-11-17T10:00:00Z'
- address: '0x8F2A9B5C3D4E6F7A8B9C0D1E2F3A4B5C6D7E8F9A'
createdAt: '2025-11-17T10:05:00Z'
- address: '0xA1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0'
createdAt: '2025-11-17T10:10:00Z'
evmSmartAccounts:
- '0x842d35Cc6634C0532925a3b844Bc454e4438f55f'
- '0x9D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B9C0D1E'
evmSmartAccountObjects:
- address: '0x842d35Cc6634C0532925a3b844Bc454e4438f55f'
ownerAddresses:
- '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'
createdAt: '2025-11-17T10:02:00Z'
- address: '0x9D3E4F5A6B7C8D9E0F1A2B3C4D5E6F7A8B9C0D1E'
ownerAddresses:
- '0x8F2A9B5C3D4E6F7A8B9C0D1E2F3A4B5C6D7E8F9A'
createdAt: '2025-11-17T10:07:00Z'
solanaAccounts:
- HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT
- 9ZN8wT6gKxLmJvP4rQnYt7VxKwL3mN9rT8Qx2WzJpK5s
solanaAccountObjects:
- address: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT
createdAt: '2025-11-17T10:15:00Z'
- address: 9ZN8wT6gKxLmJvP4rQnYt7VxKwL3mN9rT8Qx2WzJpK5s
createdAt: '2025-11-17T10:20:00Z'
createdAt: '2025-11-17T10:00:00Z'
'400':
description: Invalid request.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
invalid_request:
value:
errorType: invalid_request
errorMessage: At least one authentication method must be provided.
solana_smart_account_not_supported:
value:
errorType: invalid_request
errorMessage: The request contains one or more unsupported options.
'401':
description: Unauthorized.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
unauthorized:
value:
errorType: unauthorized
errorMessage: Wallet authentication error.
'402':
$ref: '#/components/responses/PaymentMethodRequiredError'
'422':
$ref: '#/components/responses/IdempotencyError'
'500':
$ref: '#/components/responses/InternalServerError'
get:
x-audience: public
summary: List end users
description: |-
Lists the end users belonging to the developer's CDP Project.
By default, the response is sorted by creation date in ascending order and paginated to 20 users per page.
operationId: listEndUsers
tags:
- End User Accounts
security:
- apiKeyAuth: []
parameters:
- name: pageSize
description: The number of end users to return per page.
in: query
required: false
schema:
type: integer
default: 20
minimum: 1
maximum: 100
example: 10
- name: pageToken
description: The token for the desired page of end users. Will be empty if there are no more end users to fetch.
in: query
required: false
schema:
type: string
example: eyJsYXN0X2lkIjogImFiYzEyMyIsICJ0aW1lc3RhbXAiOiAxNzA3ODIzNzAxfQ==
- name: sort
description: Sort end users. Defaults to ascending order (oldest first).
in: query
required: false
schema:
type: array
items:
type: string
enum:
- createdAt=asc
- createdAt=desc
example:
- createdAt=asc
style: form
explode: false
responses:
'200':
description: Successfully retrieved end users.
content:
application/json:
schema:
allOf:
- type: object
required:
- endUsers
properties:
endUsers:
type: array
description: The list of end users.
items:
$ref: '#/components/schemas/EndUser'
- $ref: '#/components/schemas/ListResponse'
'400':
description: Invalid request.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
invalid_request:
value:
errorType: invalid_request
errorMessage: Invalid project ID.
'401':
$ref: '#/components/responses/UnauthorizedError'
'500':
$ref: '#/components/responses/InternalServerError'
'502':
$ref: '#/components/responses/BadGatewayError'
'503':
$ref: '#/components/responses/ServiceUnavailableError'
/v2/end-users/auth/validate-token:
post:
x-audience: public
summary: Validate end user access token
description: |-
Validates the end user's access token and returns the end user's information. Returns an error if the access token is invalid or expired.
This API is intended to be used by the developer's own backend, and is authenticated using the developer's CDP API key.
operationId: validateEndUserAccessToken
tags:
- End User Accounts
security:
- apiKeyAuth: []
requestBody:
content:
application/json:
schema:
type: object
description: The request body for a developer to verify an end user's access token.
properties:
accessToken:
type: string
description: The access token in JWT format to verify.
example: eyJhbGciOiJFUzI1NiIsImtpZCI6IjA1ZGNmYTU1LWY1NzktNDg5YS1iNThhLTFlMDI5Nzk0N2VlNiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJjZHAtYXBpIiwiYXV0aF90eXBlIjoiZW1haWwiLCJleHAiOjE3NTM5ODAyOTksImlhdCI6MTc1Mzk3ODQ5OSwiaXNzIjoiY2RwLWFwaSIsImp0aSI6IjA3ZWY5M2JlLTYzMDQtNGQ1YS05NmE3LWJlMGI5MWI0ZTE3NCIsInByb2plY3RfaWQiOiJjNzRkOGI4OC0wOTNiLTQyZDItOGE4Yy1kZGM1YzVlMGViNDMiLCJzdWIiOiJjYTM4YTM4ZC0xNmE5LTRkMjYtYTcxZC0zOWY2NmY5YzZiN2UifQ.1SU0pOy-WR002qUw4hd_UmZWRSLz-ZL6v7PvQvZMKVE6a51x_tqeUeRGaTGuYl1whg0eccMObmK7FqXKRH6E4g
required:
- accessToken
responses:
'200':
description: Confirms that the access token is valid and returns the end user's information.
content:
application/json:
schema:
$ref: '#/components/schemas/EndUser'
'400':
description: Request body is invalid.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
invalid_request:
value:
errorType: invalid_request
errorMessage: Missing access token
'401':
description: Request is not properly authenticated, or the access token is invalid or expired.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
unauthorized:
value:
errorType: unauthorized
errorMessage: 'Invalid JWT issuer: not-cdp-api, expected: cdp-api'
'404':
description: End user not found.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
not_found:
value:
errorType: not_found
errorMessage: End user not found
'500':
$ref: '#/components/responses/InternalServerError'
/v2/end-users/{userId}:
get:
x-audience: public
summary: Get an end user
description: |-
Gets an end user by ID.
This API is intended to be used by the developer's own backend, and is authenticated using the developer's CDP API key.
operationId: getEndUser
tags:
- End User Accounts
security:
- apiKeyAuth: []
parameters:
- name: userId
in: path
required: true
description: The ID of the end user to get.
schema:
type: string
pattern: ^[a-zA-Z0-9-]{1,100}$
example: e051beeb-7163-4527-a5b6-35e301529ff2
responses:
'200':
description: Successfully got end user.
content:
application/json:
schema:
$ref: '#/components/schemas/EndUser'
'404':
description: Not found.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples:
not_found:
value:
errorType: not_found
errorMessage: End user with the given ID not found.
'500':
$ref: '#/components/responses/InternalServerError'
/v2/evm/accounts:
get:
x-audience: public
summary: List EVM accounts
description: |-
Lists the EVM accounts belonging to the developer's CDP Project.
The response is paginated, and by default, returns 20 accounts per page.
operationId: listEvmAccounts
tags:
- EVM Accounts
security:
- apiKeyAuth: []
parameters:
- $ref: '#/components/parameters/PageSize'
- $ref: '#/components/parameters/PageToken'
responses:
'200':
description: Successfully listed EVM accounts.
content:
application/json:
schema:
allOf:
- type: object
properties:
accounts:
type: array
items:
$ref: '#/components/schemas/EvmAccount'
description: The list of EVM accounts.
required:
- accounts
- $ref: '#/components/schemas/ListResponse'
'500':
$ref: '#/components/responses/InternalServerError'
'502':
$ref: '#/components/responses/BadGatewayError'
'503':
$ref: '#/components/responses/ServiceUnavailableError'
post:
x-audience: public
summary: Create an EVM account
description: Creates a new EVM account.
operationId: createEvmAccount
tags:
- EVM Accounts
security:
- apiKeyAuth: []
parameters:
- $ref: '#/components/parameters/XWalletAuth'
- $ref: '#/components/parameters/IdempotencyKey'
requestBody:
required: false
content:
application/json:
schema:
type: object
properties:
name:
type: string
description: |-
An optional name for the account.
Account names can consist of alphanumeric characters and hyphens, and be between 2 and 36 characters long.
Account names must be unique across all EVM accounts in the developer's CDP Project.
example: my-wallet
pattern: ^[A-Za-z0-9][A-Za-z0-9-]{0,34}[A-Za-z0-9]$
accountPolicy:
type: string
x-audience: public
description: The ID of the account-level policy to apply to the account.
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
responses:
'201':
description: Successfully created EVM account.
content:
application/json:
schema:
$ref: '#/components/schemas/EvmAccount'
'400':
description: Invalid request.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
examples: