/0/private funding endpoints with stable IDs, reusable
address scopes, and fee pinning. Relative to v0, the main gains are:
- Stable IDs for methods, networks, and addresses. Integrations are not tied to fragile display-name strings
- Reusable withdrawal addresses. Save once at network or network-group scope and use across methods
- Fee pinning. Lock a quoted fee rate with a fee token so automated withdrawals are insulated from fee changes between quote and submit
- Simpler Query Funds permissioning for read-only endpoints. Monitoring keys no longer need compound Withdraw or Deposit permissions (a Query Funds-only key can therefore access more via these endpoints than it could on the legacy API, including withdrawal addresses and history). See New Funding Endpoints - Permission Changes From Legacy.
- Adding a withdrawal address
- Creating a withdrawal
- Claiming a deposit address and depositing crypto
api-key, api-sign, and api-nonce headers as shown in the helper below (the
signed path includes the query string). Schemas are in the
Funding API reference.
Prerequisites
- A Kraken account with an API key that includes the funding permissions you need. See Permission Changes From Legacy for how those permissions differ from the legacy endpoints, and Withdrawal addresses API permission Risks for the risks of Add withdrawal addresses.
- Your API secret for request signing
- For withdrawals: a funded balance and a verified destination address
Shared Python helper
The examples below call this helper. Nested query objects are encoded asasset[class]=…
style parameters, matching what these Funding API endpoints expect.
Section 1: Adding a withdrawal address
In the new Funding API, each saved withdrawal address is stored against exactly one scope: a funding method, a network, or a network group. The scope you choose controls which withdrawals can use that address later.How networks and methods group together
Funding methods sit under networks, and related networks sit under network groups:Addresses saved against a
network or network_group scope are fully usable through the API
today, but they do not yet appear in the Kraken website withdrawal address book. Frontend
support for these broader scopes is planned soon.Managing fiat withdrawal addresses through the Funding API is not available at this time. The
address book endpoints support crypto withdrawal addresses only. Fiat withdrawals can still be
submitted with
Create Funding Withdrawal using fiat
addresses added via the Kraken UI.Which addresses are returned when you list
Listing expands upward only. The filter you pass decides how far up the tree the response looks:- List by method returns addresses saved on that method, its network, and its network group.
- List by network returns addresses saved on that network and its network group, not method-only addresses under the network.
- List by network group returns only group-scoped addresses.
method_id: group-, network-, or method-scoped. That list is the complete set of
destinations valid for the withdrawal.
Endpoints in this flow
Use these endpoints to discover IDs, create an address, and confirm what is usable:Saving a withdrawal address
The following example saves a reusable Ethereum address for withdrawals.Step 1: List funding networks
discovernetwork_id and network_group_id values:
Step 2: List funding methods
Select the withdraw method for your asset and note its network. Filter by asset using a nestedasset object. In the query string that becomes
asset[class]=currency&asset[name]=USDC:
method_id=67b765fd-4efd-42dc-8ce7-63352971d566network_id=d9d375da-44b7-4be1-8a00-8b281acfe366(Ethereum)network_group_id=f95acdb7-48fb-4441-b5b4-843d3bf60e61(EVM)
Step 3: Create funding address
Save the address at network scope so any funding method on Ethereum can use it:scope.method_id or scope.network_group_id instead when you want narrower or broader
reuse. On blockchains that allow a tag or memo, you can include an optional tag or memo
under address_details.crypto. Either field is accepted.
If you save an address with
tag but the method or network uses memo,
List Funding Addresses returns the value
as memo. The same applies in reverse.Step 4: List funding addresses
List by method to see every address usable forUSDC - Ethereum:
address_id when
you create a withdrawal for that method.
Section 2: Creating a withdrawal
Workflow
- List funding methods: choose the withdraw
method_id. - Calculate funding fees: quote the fee and receive a
withdrawal_fee_token. - Create funding withdrawal: submit with
address_idand the fee token.
Step 1: List funding methods
Reuse the methods call from Section 1. In this example we withdraw 5 USDC on Arbitrum One (USDC - Arbitrum One):
method_id:d4ec4d52-b159-428e-ba64-f45455a978a1address_id:ABR6SXP-SF6CY-VJMONY(EVM network-group scoped address, valid for Arbitrum)
Step 2: Calculate funding fees
fee_included=true means the amount you pass is the total debit from your balance.
The withdrawal_fee_token is an unique quote token returned with the fee calculation. It locks
in the quoted fee rate (the base fee and any percentage component) so a later withdrawal can
charge that rate instead of whatever the live fee happens to be at submit time. The token is
valid for 5 minutes from when it was issued, and you can reuse the same token on multiple
withdrawals during that window. After it expires, request a new quote.
When you withdraw with a token, use the same fee_included setting you used for the quote. If
you withdraw the same amount you quoted, the fee matches the quote exactly. If the method charges
a percentage and you withdraw a different amount, that percentage is reapplied to the new amount
while still using the locked-in rate.
Step 3: Create funding withdrawal
Submit the fee token underfee.quoted_fee.token:
scopeselects the withdraw method. You can passnetwork_idinstead only when that network has exactly one available method for the asset; otherwise the request is ambiguous.- The destination
address_idmay be method-, network-, or network-group-scoped, as long as it is compatible with the method you selected. - Instead of a fee token, you can accept the current fee and optionally set a maximum:
- Optional
expected_addresslets you confirm the on-chain destination still matches the saved address before the withdrawal proceeds.
Section 3: Depositing funds
Deposit addresses belong to a funding method: one way to move one asset on one network, for example depositing USDC on Ethereum. You always claim and list with amethod_id. You do
not choose a network or network-group scope the way you do for withdrawal addresses.
Workflow
- List funding methods: choose a deposit
method_id. - List claimed deposit addresses: reuse an existing address if one is returned.
- Claim funding deposit address: only when you need another address.
Step 1: List funding methods
address_generation tells you whether you can create more unused addresses for this method
(unlimited, limited plus limit, or unsupported). If shares_addresses_with_method_id
is present, this method reuses another method’s addresses. You can ignore that field for the
walkthrough below and still list or claim with this method_id.
Step 2: List claimed deposit addresses
This is the call to make when a user selects a deposit method and you need the address (and any tag or memo) to display. Pass the method asscope.method_id.
tag or memo is present, include it with the address. Deposits sent without a required
tag or memo may not be credited.
If the list is empty, claim an address in Step 3. Deposit claimed-address listing is separate
from the withdrawal address book in Section 1.
Step 3: Claim funding deposit address
Claim with themethod_id you want to deposit to. That does not have to be the method the
address is stored against. If the method shares addresses, Kraken returns the shared address.
address_generation is limited (typically limit: 5), you may hold up to five unused
claimed addresses for that method at a time. If you are already at the limit, claim returns
TooManyDepositAddresses. List existing addresses instead. Once one of those addresses has
received a deposit, you can claim another; the oldest unused address then begins expiring and
is removed after 7 days.
Shared deposit addresses
On many networks, token deposit methods use the same on-chain address as the network’s native asset. Kraken stores that address against the native method. The token methods reuse it.
Ethereum looks like this:
The same pattern applies on Tron (TRC-20s stored against TRX) and Solana (SPLs stored against
SOL). List Funding Methods tells you this with
deposit.shares_addresses_with_method_id. The
field is omitted when a method has its own addresses.
You still list and claim with the method the user selected. For USDC on Ethereum, pass the
USDC method_id. Kraken returns the shared ETH address. You do not look up or claim against
ETH on Ethereum first. The same is true for a TRC-20 on Tron or an SPL on Solana.
Not all networks that have an EVM deposit address share addresses. Methods on the same network
can share (ERC-20s with ETH on Ethereum, TRC-20s with TRX on Tron, SPLs with SOL on Solana).
Methods in the same network group do not always share. Trust
shares_addresses_with_method_id rather than assuming two methods share because they look
related.The same address, two method_id values
method_id on a claimed address is not always the method the address is stored against. It
depends on the list filter.
Listed for USDC (scope.method_id = USDC on Ethereum), as in Step 2. Use this when you are
showing the user where to send USDC:
method_id is ETH on Ethereum, because that is where the
address is stored:
The same split happens on other networks. A TRC-20 listed by its own
method_id reports that
token method; listed with no method filter it reports TRX on Tron. An SPL listed by its own
method reports the SPL; unscoped it reports SOL on Solana.
If you list every claimed address and then keep rows whose method_id is USDC, you will miss
this address. Put USDC in scope.method_id on the request instead.