> ## Documentation Index
> Fetch the complete documentation index at: https://developers.circle.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CCTP for non-USDC compared to CCTP

> Key integration differences for developers already familiar with CCTP who want to transfer existing registered tokens.

Integrating CCTP for non-USDC when you already know CCTP for USDC is mostly a
matter of switching entry contracts and adjusting for a different fee model. The
following sections document the key differences for developers integrating
pre-registered or third-party-registered tokens.

## What stays the same

This layer shares CCTP's core infrastructure:

* **Message transmitter**: Both use `MessageTransmitterV2`. Attestations are
  delivered to the same contract on the destination.
* **Attestation service**: Both use Iris (Circle's attestation API). Polling
  `/v2/messages/{sourceDomain}` works the same way.
* **Finality thresholds**: `minFinalityThreshold = 2000` for standard, `1000`
  for fast. Same semantics as CCTP fast transfers.
* **Hooks**: Available on both protocols. The `CrossChainTokenExecutable`
  interface is analogous to CCTP's `IMessageHandlerV2`.

## Key integration differences

### Entry contract and approval target

|                 | CCTP               | CCTP for non-USDC                          |
| --------------- | ------------------ | ------------------------------------------ |
| Source entry    | `TokenMessengerV2` | `CrossChainTokenService`                   |
| Approval target | `TokenMessengerV2` | Per-token `TokenManager` (not the service) |

For CCTP, you approve `TokenMessengerV2` and call `depositForBurn`. For non-USDC
transfers, resolve the per-token `TokenManager` address from
`CrossChainTokenService` using `resolveTokenManager(tokenId)`, approve that
address, then call `crossChainTransfer` on the service.

Approving the service contract directly does not work; the approval must go to
the `TokenManager`.

### Fee model

CCTP deducts its fee from the transferred USDC amount; the recipient receives
slightly less than the sender transferred. Non-USDC fees are paid in native gas
on the source blockchain at transfer time, so the recipient receives the full
transferred amount.

### Forwarding

CCTP forwarding (auto-delivery of the destination mint) is compulsory whenever
the forwarding service is used. For non-USDC transfers, forwarding is opt-in:
include a `FORWARD` entry in the `requests` array when you fetch the Iris fee
quote. Transfers that omit `FORWARD` require you or the recipient to submit
`receiveMessage` on the destination `MessageTransmitterV2` manually.

### Allowance pools for fast transfers

Both protocols support fast transfers, but they track allowance separately. USDC
fast transfers consume the USDC allowance; non-USDC fast transfers consume a
per-token allowance maintained by Circle. Check the per-token allowance using
`GET /v2/cctpx/allowances` before initiating a fast transfer; if the allowance
is insufficient or FX pricing is not configured for the token, the quote returns
`FX_SYMBOL_NOT_CONFIGURED` and the fast transfer cannot proceed.

### Token prerequisite

USDC works on CCTP without setup. Non-USDC transfers require the token to be
registered before it can be transferred. If you are using a pre-registered token
(such as EURC), the token is already available and no registration step is
needed on your end. To check which tokens are pre-registered, see
[Supported blockchains](/cctp/expanded-assets/concepts/supported-chains-and-domains).