# Transfer USDC with Data Source: https://docs.chain.link/ccip/evm/tutorials/application-developers/usdc Last Updated: 2026-09-19 > For the complete documentation index, see [llms.txt](/llms.txt). USDC is a digital dollar backed 100% and is always redeemable 1:1 for US dollars. The [stablecoin](https://chain.link/education-hub/stablecoins) is issued by [Circle](https://www.circle.com/en/usdc) on multiple blockchain platforms. This guide will first explain how CCIP enables native USDC transfers when both the source and destination blockchains support [Circle's Cross-Chain Transfer Protocol (CCTP)](https://www.circle.com/en/cross-chain-transfer-protocol). Additionally, it will outline how CCIP also supports transferring Bridged USDC on blockchains that **are not** CCTP-enabled, allowing projects to later migrate to CCTP-enabled transfers if approved by Circle. The hands-on tutorial at the end demonstrates how to use Chainlink CCIP to transfer USDC and arbitrary data from a smart contract on *Ethereum Sepolia* to *Arbitrum Sepolia*. > **NOTE: CCIP 2.0 supports Faster-Than-Finality (FTF)** ## Architecture Native USDC transfers through CCIP use Circle's [Cross-Chain Transfer Protocol (CCTP)](https://www.circle.com/en/cross-chain-transfer-protocol) when both the source and destination chains support it. Both chains on this lane: - *Ethereum Sepolia*, - and *Arbitrum Sepolia*, run CCTP-enabled USDC token pools, so this tutorial moves **native USDC**: burned on the source chain, minted on the destination. > For chains without native CCTP, Circle's [Bridged USDC Standard](https://www.circle.com/blog/bridged-usdc-standard) lets teams deploy USDC early, with a seamless upgrade path to Native USDC later. CCIP maintains a consistent [API](/ccip/evm/api-reference/v2.0.0/i-router-client) regardless of whether the transfer involves Native USDC or Bridged USDC: - The sender interacts with the CCIP router to initiate a cross-chain transaction, just like any other token transfer. See the [Transfer Tokens](/ccip/evm/tutorials/application-developers/transfer-tokens-from-contract) guide to learn more. - The process uses the same onchain components including the Router, OnRamp, OffRamp, and Token Pool. - Offchain, messages are verified by independent Cross-Chain Verifiers (CCVs). Every lane runs a default, decentralized Committee Verifier, and USDC transfers are additionally verified by a CCTP Verifier that checks Circle's own attestation for the burn. - Once the required verifiers have attested, the message is delivered on the destination chain through the OffRamp, which verifies each attestation before the USDC token pool mints USDC using Circle's attestation. - Execution on destination is permissionless, as in, anyone can submit an attested message for execution, and the Chainlink Executor does so by default. - All lanes remain protected by the Risk Management Network, which can halt sends and executions on a lane through its cursing mechanism if a safety issue is detected. The diagram below shows the native USDC flow: the USDC token pool burns tokens on the source chain via CCTP, the CCTP Verifier checks Circle's attestation for the burn, and the destination token pool mints USDC using that attestation once all required verifiers have signed off. To learn more about these components, read the [CCIP architecture overview](/ccip/concepts/architecture/overview). ![Chainlink CCIP Detailed Architecture for USDC](/images/ccip/usdc-diagram.png) ## Before you begin 1. You should understand how to write, compile, deploy, and fund a smart contract. Go through this [tutorial](/quickstarts/deploy-your-first-contract) to get started. 2. Your account must have some `ETH` and `LINK` tokens on *Ethereum Sepolia*, and `ETH` on *Arbitrum Sepolia* for deploying the destination contracts and redeeming `STK`. Learn how to [Acquire testnet LINK](/resources/acquire-link). 3. Check the [CCIP Directory](/ccip/directory) if you want to configure a different set of source and destination chains/tokens. 4. Acquire USDC tokens from the [Circle faucet](https://faucet.circle.com/) on *Ethereum Sepolia*. ## Examine the code Three contracts make this work, spread across two chains. \ `USDCSender` sits on *Ethereum Sepolia* and starts the transfer. On *Arbitrum Sepolia*, `USDCReceiver` catches the incoming message and hands the USDC to `USDCStaker`, which mints a receipt token to whoever the sender nominated. ## Tutorial Let's get started! Choose your preferred development environment below. ### Foundry Best for **Solidity-native** workflows that prefer a modular, powerful scripting framework. > **NOTE: Want to set up a dev environment from scratch? ** > > Check out the [Getting started page](/ccip/evm/getting-started#foundry) for detailed instructions on setting up a > Foundry dev environment from scratch. ### Hardhat Best for developers who want a mature, TypeScript-based smart contract development framework. > **NOTE: Want to set up a dev environment from scratch? ** > > Check out the [Getting started page](/ccip/evm/getting-started#hardhat-3) for detailed instructions on setting up a > Hardhat dev environment from scratch. > **CAUTION: Educational Example Disclaimer** > > Please note, this page contains community examples only — these are not Chainlink products or services and are not > supported or maintained by Chainlink. This code represents an example of using a Chainlink product or service, and is > intended for demonstration and educational purposes only. It is provided "AS IS" and "AS AVAILABLE" without warranties > of any kind, may not have been audited, and may omit checks or error handling. Each party intending to use this > example code does so entirely at their own risk and must perform its own audits, security and code review, key > management, and testing before any production deployment and ensure the operation and performance of such code matches > expectations. Neither Chainlink Labs nor the Chainlink Foundation deploys, operates, monitors, maintains or endorses > any deployment of this code. Note that this is not a Chainlink product, feature or service, and there are no > commitments made with respect to the code, including compatibility with future Chainlink releases. You should not rely > on this code without first conducting your own technical, engineering, and security review. This code is also outside > the scope of any Chainlink bug bounty programs. Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node > operators are responsible for outcomes due to errors in this example or how it is deployed or operated, or liable for > any resulting claims or damages. Use of the Chainlink Network is subject to the Chainlink Foundation [Terms of > Service](https://chain.link/terms), which provides important information and disclosures. By using this code, you > acknowledge and agree to these terms.