Kraken enables USDC deposits and withdrawals on Arc

A new route for moving USDC

Kraken enabled USDC deposits and withdrawals on Arc on 16 September 2026. This was a funding announcement: eligible customers could move USDC between Kraken and the Arc network. It did not turn every USDC balance on every blockchain into an Arc balance. The release also described Arc as using USDC for network fees and cautioned customers to use the supported network when transferring. Product access remains subject to geographical restrictions.

Why the network selector matters

Kraken’s support explanation distinguishes a network, the blockchain on which an asset exists, from a transaction method available on that network. A token may have several supported networks or forms. The deposit instructions must match the network used to send it; a matching ticker alone is insufficient. Kraken warns that unsupported-network deposits will not be credited through the ordinary process. That warning is not a promise that an incorrect transfer can later be recovered.

The same documentation says withdrawal fees can differ by network and should be checked in the withdrawal preview. A new deposit option therefore does not establish identical costs across every route. These help-page details explain the mechanics around the release without assuming that a particular account, recipient or third-party wallet supports every option shown elsewhere.

Trace a six-hundred-USDC payment

Imagine a designer who is to receive an invoice payment of six hundred USDC. For this invented example, the payer holds the funds on Arc and the designer wants the payment credited to an eligible Kraken account. Before a transfer exists, there are two separate facts to establish: where the payer’s funds currently sit, and which deposit instructions the recipient has generated. The amount and the ticker do not answer either question.

Suppose the designer accidentally copies instructions labelled for a different network. Asking the payer to type the same six-hundred amount does not repair the mismatch. In this example, the missing step is to obtain deposit instructions for the actual intended route. No payment needs to be sent while that uncertainty remains. This is a compatibility problem before it is a question about confirmation speed.

Now assume both ends explicitly show Arc and the address has been checked. The payer’s transaction and the eventual exchange credit are still two observations. A wallet showing a submitted transaction tells us what the payer attempted. The recipient’s credited balance tells us what arrived and became available at the other end. For the fictional invoice, those observations should reconcile before either party treats the payment as completed.

The amount sent is not always the amount available for the next step

Use a separate arithmetic example with completely invented charges. A person has a six-hundred-unit budget and a sending service charges one unit in addition to the amount transferred. If the budget must cover both, the largest amount available to send is five hundred ninety-nine units. If the person instead enters six hundred, the total requirement becomes six hundred one. Neither figure is a Kraken or Arc fee quote.

The example explains why a transfer preview deserves more attention than a network’s general reputation for low costs. A fee can be charged on top of an amount or deducted from it, and the intended recipient may care about the net arrival. For a payment agreement specifying an exact received amount, the parties need to work backwards from that amount using the actual preview, rather than copying the wallet’s total balance into the send field.

Funding and trading are different actions

After the fictional payment arrives, the designer may simply leave the USDC balance untouched. Alternatively, the designer might decide to exchange it for another asset or move it onward. Those are additional decisions, each with a new destination, quote or order. The existence of a deposit route does not itself carry out those decisions, establish a sale price, or prove that another service accepts the same network.

This distinction makes the announcement easier to use. Someone already working on Arc gains a more direct route to evaluate. Someone holding USDC somewhere else first needs to identify that starting network and consider a compatible path. The valuable change is an additional connection between two places, rather than a change in what the USDC ticker means everywhere.