Skip to main content
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: 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.

​
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.
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. 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. For the contract interface, see CctpExtensionV2 Contract Interface. For integration steps, see Transfer USDC from Arbitrum to HyperCore with CctpExtensionV2. 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 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:

​
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. 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.
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.

​
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.