bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 75쪽 중 25쪽
ere recipients
prefer to receive funds.
</Accordion>
<Accordion title="Composable crosschain applications" icon="layer-group">
Use CCTP hooks to chain together crosschain actions. Transfer assets across
blockchains and automatically deposit them into DeFi protocols, purchase NFTs,
or execute smart contract logic.
</Accordion>
</AccordionGroup>
## Get started
<CardGroup>
<Card title="Transfer USDC from Ethereum to Arc" icon="rocket" href="/cctp/quickstarts/transfer-usdc-ethereum-to-arc">
Build a script to transfer USDC between EVM blockchains using CCTP
</Card>
<Card title="Transfer USDC from Solana to Arc" icon="rocket" href="/cctp/quickstarts/transfer-usdc-solana-to-arc">
Transfer USDC from Solana to an EVM blockchain using CCTP
</Card>
<Card title="Transfer USDC between Stellar and Arc" icon="rocket" href="/cctp/quickstarts/transfer-usdc-stellar-arc">
Transfer USDC between Arc and Stellar using CCTP
</Card>
<Card title="Transfer USDC between Starknet and Arc" icon="rocket" href="/cctp/quickstarts/transfer-usdc-starknet-arc">
Transfer USDC between Arc and Starknet using CCTP
</Card>
<Card title="Transfer USDC between Sui and Arc" icon="rocket" href="/cctp/quickstarts/transfer-usdc-sui-arc">
Transfer USDC between Arc and Sui using CCTP
</Card>
</CardGroup>
## CCTP for non-USDC assets
CCTP natively transfers USDC across blockchains using burn-and-mint. For EURC or
other registered ERC-20 assets, see
[CCTP for non-USDC assets](/cctp/expanded-assets), which extends CCTP's
attestation infrastructure to support EURC burn-and-mint and permissionless
wrapping of third-party assets (including pre-registered tokens like WETH).
| Feature | CCTP | CCTP for non-USDC |
| - | - | - |
| Token scope | USDC | EURC and any configured ERC-20 |
| Entry contract | `TokenMessengerV2` | `CrossChainTokenService` |
| Fee model | Fee deducted from the transferred amount | Fee paid in native gas on the source blockchain |
| Forwarding | Compulsory when used | Optional; requested at quote time |
| Attestation | Iris | Iris (shared with CCTP) |
| Hooks | Yes | Yes, with atomic on-arrival execution |
| Audiences | Anyone moving USDC or EURC | Token issuers, RWA platforms, and apps integrating third-party assets |
## Related products
CCTP and Gateway offer different approaches to crosschain transfers. This table
compares the two approaches.
| Attribute | CCTP | Gateway |
| - | - | - |
| **Use case** | Transfer USDC, EURC, or registered third-party assets from one blockchain to another | Hold a unified USDC balance accessible on any supported blockchain |
| **Transfer speed** | Fast Transfer: \~8-20 seconds<br />Standard Transfer: 15-19 minutes (Ethereum/L2s) | Instant (\<500 ms) after balance is established |
| **Balance model** | Point-to-point transfers | Unified crosschain balance |
| **Custody** | Non-custodial | Non-custodial with 7-day trustless withdrawal option |
| **Supported blockchains** | [View list](/cctp/concepts/supported-chains-and-domains) | [View list](/gateway/references/supported-blockchains) |
# CCTP-enabled HyperCore transfers
Source: https://developers.circle.com/cctp/concepts/cctp-on-hypercore
CCTP lets you transfer USDC from all supported CCTP domains to HyperCore using a
`CoreDepositWallet` contract deployed on HyperEVM. The `CoreDepositWallet`
handles depositing and withdrawing USDC between HyperEVM and HyperCore. This
topic explains how the HyperCore workflow works and covers HyperCore-specific
considerations.
<Note>
**Note:** HyperCore balances reflect protocol-level credits, not Circle-issued
USDC. Native USDC remains in the `CoreDepositWallet` contract on HyperEVM and
withdrawals are required to [redeem native USDC from
HyperEVM](/cctp/howtos/withdraw-usdc-from-hypercore-to-evm).
</Note>
## How it works
The HyperCore workflow from source chains that are not HyperEVM is a two-step
process: funds are transferred in the standard CCTP workflow to HyperEVM, then
forwarded to HyperCore by depositing them into the `CoreDepositWallet` contract.
The burn transaction uses one of three contracts depending on the source chain
and integration pattern:
* `TokenMessengerV2` contract
* `CctpExtension` contract
* `CctpExtensionV2` contract (Arbitrum only; sponsored / relayer-submitted
deposits)
The burn transaction includes a hook that calls the `CctpForwarder` contract on
HyperEVM to forward the USDC to the recipient address on HyperCore.
Here's how the HyperCore deposit workflow works:
1. Check the CCTP API for fees. Fast transfers from Arbitrum with a HyperCore
destination have no fast transfer fee. Using Circle's Forwarder Service to
forward to HyperCore is optional and has a dynamic destination chain gas fee.
2. Calculate the USDC amounts minus fees.
3. Approve the contract to spend the amount of USDC you want to burn. If you are
interacting with the `TokenMessengerV2` contract, you can do this with a call
to the `approve` function on the USDC contract. If you are interacting with
the `CctpExtension` contract on Arbitrum, you sign a
`ReceiveWithAuthorization` message.
4. Sign and broadcast a burn transaction. The type depends on the source domain:
* **CctpExtension contract on Arbitrum**: Sign and broadcast a
`batchDepositForBurnWithAuth` transaction. Set HyperEVM as the destination.
Include hook data to call the `CctpForwarder` contract on HyperEVM.
* **TokenMessengerV2 contract**: Sign and broadcast a `depositForBurn`
transaction. Set HyperEVM as the destination. Include hook data to call the
`CctpForwarder` contract on HyperEVM.
### Sponsored deposits on Arbitrum
`CctpExtensionV2` is a separate Arbitrum contract from `CctpExtension`. It
enables gas-sponsored CCTP burns: the end user signs a single EIP-3009
`ReceiveWithAuthorization` offchain, and a relayer submits the Arbitrum
transaction via `batchSponsorDepositForBurn`, paying ETH gas on the user's
behalf.
Use this path when your users hold USDC on Arbitrum but not native gas (for
example, email-login or CEX-funded wallets). Most integrators who control their
own wallet and gas should continue using `CctpExtension` or `TokenMessengerV2`
as documented in
[Transfer USDC from Arbitrum to HyperCore](/cctp/howtos/transfer-usdc-from-arbitrum-to-hypercore).
Key differences from `CctpExtension`:
1. The relayer, not the depositor, broadcasts the burn transaction.
2. The EIP-3009 authorization nonce is deterministically derived from the
deposit parameters (destination, recipient, fees, hook data), which binds the
user's signature to the intended CCTP transfer.
3. The relayer may batch multiple user deposits in one transaction.
After the burn, the crosschain path is the same as other Arbitrum → HyperCore
transfers: CCTP attestation, mint on HyperEVM, optional `CctpForwarder` hook to
HyperCore.
For contract addresses, see
[HyperCore CCTP-Enablement Contract Addresses](/cctp/references/hypercore-contract-addresses).
For the contract interface, see
[CctpExtensionV2 Contract Interface](/cctp/references/cctp-extension-v2-contract-interface).
For integration steps, see
[Transfer USDC from Arbitrum to HyperCore with CctpExtensionV2](/cctp/howtos/transfer-usdc-from-arbitrum-to-hypercore-with-cctp-extension-v2).
HyperCore deposits and withdrawals are supported to/from any CCTP-supported
blockchain. Forwarding for these transfers is optional and is supported for all
[Forwarder-supported blockchains](/cctp/concepts/supported-chains-and-domains#supported-blockchains)
except for withdrawals to Solana.
## Important considerations
Keep these things in mind when using CCTP with HyperCore.
### Testnet recipient address limitations
When you test USDC transfers to HyperCore on testnet, the recipient address has
limits:
* The recipient address must already exist on HyperCore mainnet.
* Addresses that already exist on mainnet can only receive up to \$1000 testnet
USDC.
* Transfers to addresses without mainnet state fail silently.
To check if an address exists on mainnet, use Hyperliquid's info API:
```shell theme={null}
curl -X POST https://api.hyperliquid.xyz/info \
-H "Content-Type: application/json" \
-d '
{
"type": "userRole",
"user": "${USER_ADDRESS}"
}
'
```
### Account activation fee on HyperCore
New HyperCore accounts are subject to a one-time 1 USDC activation fee, managed
entirely by the Hyperliquid protocol. Circle's `CoreDepositWallet` contract does
not collect or enforce this fee.
When a new user first deposits USDC to HyperCore, the full deposit amount is
credited to their tradable balance. The 1 USDC activation fee is earmarked at
the account level and charged on the user's first outbound action, such as a
withdrawal or `SendAsset` transfer. Until that first outbound action, the
account is considered unactivated and cannot perform
[CoreWriter actions](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/activation-gas-fee).
This means:
* There is no minimum deposit amount. Deposits of any size, including less than
1 USDC, will succeed.
* The user's first outbound action (withdrawal, transfer, etc.) requires a
balance of at least 1 USDC. If the balance is below 1 USDC at that time, the
action will fail.
* After the activation fee is paid, subsequent outbound actions are not subject
to it.
<Note>
The activation fee is separate from CCTP forwarding fees. When calculating
total costs for a new user's first withdrawal, account for both the 1 USDC
activation fee (charged by Hyperliquid) and any applicable CCTP forwarding
fee.
</Note>
### Best practices for new account deposits
When your integration deposits USDC to a new HyperCore account:
* Ensure the deposit is large enough that the recipient will have at least 1
USDC available for their first outbound action.
* Inform end users that their first withdrawal or transfer from HyperCore
includes a one-time 1 USDC activation fee deducted by the Hyperliquid
protocol.
* If your integration creates accounts programmatically (for example, contract
addresses), you can pre-activate the account by sending an activation
transaction to the EVM contract address on HyperCore, as described in
[Hyperliquid's documentation](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/activation-gas-fee).
# Fast transfer allowance
Source: https://developers.circle.com/cctp/concepts/fast-transfer-allowance
Understanding Circle's Fast Transfer allowance mechanism
The Fast Transfer allowance is Circle's mechanism for providing
faster-than-finality USDC transfers. It limits the total value of USDC that can
be minted through Fast Transfer before related burns reach hard finality.
## How it works
Circle maintains a Fast Transfer allowance pool that backs all in-process CCTP
Fast Transfers. The following steps describe how the allowance works:
1. **Initial state**: Circle maintains a Fast Transfer allowance pool (for
example, 10 million USDC).
2. **Fast Transfer initiated**: When you burn USDC on the source blockchain with
Fast Transfer:
* The burn amount temporarily debits the allowance
* Circle's Attestation Service issues an attestation after
[soft finality](/cctp/concepts/finality-and-block-confirmations)
* You can immediately mint USDC on the destination blockchain
3. **Allowance depleted**: If the allowance reaches zero, Fast Transfers are
temporarily unavailable until the allowance replenishes.
4. **Allowance replenished**: Once burns reach hard finality on source
blockchains, the corresponding amounts are credited back to the allowance.
<Note>
**Note:** The Fast Transfer allowance is global across all supported
blockchains. It's not specific to a particular source or destination blockchain,
but rather tracks the total value of in-process Fast Transfers.
</Note>
## Check the current allowance
To check the remaining Fast Transfer allowance, call the
[`GET /v2/fastBurn/USDC/allowance`](/api-reference/cctp/all/get-fast-burn-usdc-allowance)
endpoint. For a detailed guide on checking the allowance, see
[Get the Fast Transfer allowance](/cctp/howtos/get-fast-transfer-allowance).
## When allowance is insufficient
If the Fast Transfer allowance is insufficient for your transfer, you have two
options:
### Option 1: Wait for replenishment
The allowance automatically replenishes as pending Fast Transfers reach hard
finality.
Monitor the allowance until sufficient capacity is available:
```ts TypeScript theme={null}
async function waitForAllowance(requiredAmount: bigint, timeoutMs = 1200000) {
const startTime = Date.now();
while (Date.now() - startTime < timeoutMs) {
const response = await fetch(
"https://iris-api-sandbox.circle.com/v2/fastBurn/USDC/allowance",
);
const { allowance } = await response.json();
// Convert USDC string to 6-decimal subunits without float precision loss
const [whole, frac = ""] = String(allowance).split(".");
const allowanceSubunits =
BigInt(whole) * 1_000_000n + BigInt((frac + "000000").slice(0, 6));
if (allowanceSubunits >= requiredAmount) {
console.log("Sufficient allowance available");
return true;
}
console.log(`Current allowance: ${allowance} USDC, waiting...`);
await new Promise((resolve) => setTimeout(resolve, 30000)); // Check every 30 seconds
}
throw new Error("Timeout waiting for allowance replenishment");
}
```
### Option 2: Use Standard Transfer
Change `minFinalityThreshold` to 2000 or higher to use
[Standard Transfer](/cctp/concepts/finality-and-block-confirmations#standard-transfer-attestation-times),
which doesn't consume the Fast Transfer allowance.
## Allowance lifecycle
Understanding what happens during each phase of the allowance lifecycle helps
you build more robust applications:
<Steps>
<Step title="Burn initiated">
The user calls `depositForBurn` with `minFinalityThreshold` ≤ 1000. The
transaction confirms on the source blockchain, and the allowance is debited by
the burn amount.
</Step>
<Step title="Soft finality reached">
Circle's Attestation Service issues an attestation, and the attestation becomes
available through the API. The user can now mint USDC on the destination
blockchain.
</Step>
<Step title="Hard finality reached">
The burn transaction reaches hard finality on the source blockchain. The
allowance is credited back by the burn amount, and capacity is restored for new
Fast Transfers.
</Step>
</Steps>
# CCTP fees
Source: https://developers.circle.com/cctp/concepts/fees
Understanding CCTP transfer fees for Fast and Standard transfers
CCTP charges fees on Fast Transfers only. Standard Transfers are free.
[Fast Transfer](/cctp/concepts/finality-and-block-confirmations#fast-transfer-attestation-times)
enables USDC transfers at faster-than-finality speeds by leveraging Circle's
[Fast Transfer allowance](/cctp/concepts/fast-transfer-allowance). These
transfers incur a fee that varies by route.
* **Fee range**: 0-13 basis points depending on source blockchain, for example
\$0–\$1.30 per \$1,000 transferred
* **When and how the fee is collected**: The fee is deducted from the
transferred amount when USDC is minted on the destination blockchain
<Note>
Instead of having the Fast Transfer fee deducted at mint, you can pay it upfront
on the source blockchain so the recipient receives the full transferred amount
on the destination blockchain. See [Upfront fees](/cctp/concepts/upfront-fees).
</Note>
## Get the current fee
To retrieve the current Fast Transfer fee for your route, call the
[`GET /v2/burn/USDC/fees`](/api-reference/cctp/all/get-burn-usdc-fees) endpoint.
For more details, see
[Get the fee for your transfer](/cctp/howtos/get-transfer-fee).
## Maximum fee parameter
When calling
[`depositForBurn`](/cctp/references/contract-interfaces#depositforburn), you
specify a `maxFee` parameter that sets the maximum fee you're willing to pay:
```ts TypeScript theme={null}
await tokenMessenger.depositForBurn(
amount,
destinationDomain,
mintRecipient,
burnToken,
destinationCaller,
500n, // maxFee: 500 subunits (0.0005 USDC)
1000, // minFinalityThreshold: Fast Transfer
);
```
If the actual fee exceeds your specified `maxFee`, the transaction will revert
on the source blockchain, and no USDC will be burned.
To avoid transaction failures:
1. Retrieve the current fee before initiating a transfer
2. Add a small buffer (for example, 10-20%) to account for potential fee
fluctuations
3. Set `maxFee` to this buffered amount
Example:
```ts TypeScript theme={null}
async function calculateMaxFee(
sourceDomain: number,
destDomain: number,
transferAmountUSDC: string, // USDC amount like "1" or "10.5"
) {
// Convert USDC to subunits (6 decimals)
const [whole, decimal = ""] = transferAmountUSDC.split(".");
const decimal6 = (decimal + "000000").slice(0, 6);
const transferAmount = BigInt(whole + decimal6);
// Get current fee
const response = await fetch(
`https://iris-api-sandbox.circle.com/v2/burn/USDC/fees/${sourceDomain}/${destDomain}`,
);
const fees = await response.json();
// Extract minimumFee for Fast Transfer (finalityThreshold 1000)
const minimumFee = fees[0].minimumFee; // Fee in basis points
// Calculate fee as percentage of transfer amount
const protocolFee =
(transferAmount * BigInt(Math.round(minimumFee * 100))) / 1_000_000n;
// Add 20% buffer to protocol fee (protocolFee × 1.2) - result in subunits
const maxFee = (protocolFee * 120n) / 100n;
return maxFee; // denominated in USDC subunits (6 decimals)
}
// Use in your burn call
const maxFee = await calculateMaxFee(0, 1, "10.5");
```
## Fee tables
The following tables show the current fee rates by source blockchain for Fast
and Standard Transfers. Fees are subject to change at any time.
<Warning>
**Do not hardcode fee values.** Fees can change at any time. Always retrieve the
current fee by calling the [fee API](/api-reference/cctp/all/get-burn-usdc-fees)
at least once per week. Hardcoding fees can cause:
* **Insufficient fees**: If fees increase, your Fast Transfers may be degraded
to Standard Transfers when the provided `maxFee` is below the required
threshold.
* **Overstated fees**: If fees decrease, users may see higher fees than
necessary in your UI, even though the excess is refunded during minting.
</Warning>
<Tabs>
<Tab title="Fast Transfer fee">
| Source blockchain | Fee |
| - | - |
| Arbitrum | 1.4 bps (0.014%) |
| Base | 1.3 bps (0.013%) |
| Codex | 1.5 bps (0.015%) |
| EDGE | 1.5 bps (0.015%) |
| Ethereum | 1 bps (0.01%) |
| Ink | 2 bps (0.02%) |
| Linea | 13 bps (0.13%) |
| Morph | 4 bps (0.04%) |
| OP Mainnet | 1.3 bps (0.013%) |
| Plume | 2 bps (0.02%) |
| Solana | 1 bps (0.01%) |
| Starknet | 12 bps (0.12%) |
| Unichain | 2 bps (0.02%) |
| World Chain | 1.3 bps (0.013%) |
| X Layer | 1.3 bps (0.013%) |
<Note>
**Blockchains without Fast Transfer fees**
Some blockchains don't appear in the Fast Transfer fee table because their
standard attestation times are already fast enough. Consequently, Fast Transfer
is not applicable when these blockchains are used as the source blockchain for
burns. For affected blockchains, see
[CCTP supported blockchains](/cctp/concepts/supported-chains-and-domains).
</Note>
</Tab>
<Tab title="Standard Transfer fee">
| Source blockchain | Fee |
| - | - |
| Aptos | 0 bps (0%) |
| Arbitrum | 0 bps (0%) |
| Arc | 0 bps (0%) |
| Avalanche | 0 bps (0%) |
| Base | 0 bps (0%) |
| Codex | 0 bps (0%) |
| Cronos | 0 bps (0%) |
| EDGE | 0 bps (0%) |
| Ethereum | 0 bps (0%) |
| HyperEVM | 0 bps (0%) |
| Injective | 0 bps (0%) |
| Ink | 0 bps (0%) |
| Linea | 0 bps (0%) |
| Monad | 0 bps (0%) |
| Morph | 0 bps (0%) |
| OP Mainnet | 0 bps (0%) |
| Pharos | 0 bps (0%) |
| Plasma | 0 bps (0%) |
| Plume | 0 bps (0%) |
| Polygon PoS | 0 bps (0%) |
| Sei | 0 bps (0%) |
| Solana | 0 bps (0%) |
| Sonic | 0 bps (0%) |
| Starknet | 0 bps (0%) |
| Sui | 0 bps (0%) |
| Unichain | 0 bps (0%) |
| World Chain | 0 bps (0%) |
| X Layer | 0 bps (0%) |프로젝트로 돌아가기
