> ## Documentation Index
> Fetch the complete documentation index at: https://a-identity.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Circle CCTP

> Native USDC across chains by burn-and-mint, never wrapped.

**CCTP** (Cross-Chain Transfer Protocol) is Circle's canonical way to move USDC
between chains: USDC is **burned** on the source chain and **minted natively** on the
destination, never a wrapped or bridged variant. A-Identity drives it with Circle's
Bridge Kit (CCTPv2), so an agent's dollars can leave Arc and arrive as real USDC on
another chain.

This is the second cross-chain rail alongside [Circle Gateway](/chains/gateway). They
solve related problems differently: Gateway moves a **unified balance** via the
Forwarding Service; CCTP is the **burn-and-mint** primitive underneath native USDC
liquidity.

## The burn-and-mint lifecycle

**1. approve**

The bridge is approved to spend the USDC being moved.

**2. burn**

USDC is burned on Arc, emitting a cross-chain message.

**3. fetchAttestation**

Circle attests the burn. Because Arc has instant finality, the attestation is
reached fast.

**4. mint**

Native USDC is minted on the destination chain (Base Sepolia in our demo): the
same dollar, no wrapper.

> [!NOTE]
>
> Verified live on Arc testnet: a 1 USDC transfer ran the full `approve → burn →
>   fetchAttestation → mint` lifecycle in about 15 seconds, each step a real transaction,
> minting native USDC on Base Sepolia, on both the local and the live production
> backend. SDK: [`@circle-fin/bridge-kit`](https://developers.circle.com/cctp).

## Stellar

Stellar is on this rail too, and it is the one destination that needs its own paragraph.
Circle's Bridge Kit has no Stellar adapter, so [`mcp/src/cctp-stellar.ts`](https://github.com/getA-Identity/A-Identity/blob/main/mcp/src/cctp-stellar.ts)
drives the protocol directly: burn, Iris attestation, mint, in both directions.

* **A Stellar recipient must go through Circle's `CctpForwarder`.** The CCTP message format
  has no room for a StrKey type marker, so the `G...` account rides in the hook data and the
  forwarder mints and forwards in one atomic call. A direct mint to a `G...` account is
  unrecoverable.
* **Seven decimals on one side, six on the other.** Stellar assets carry 7 decimals and
  every EVM USDC carries 6, so an amount is converted rather than copied.
* **Testnet-proven both ways on 2026-09-10**: Arc testnet to Stellar testnet, and a Stellar
  testnet burn minted back on Arc. Both legs are on the proof pages.
* **Mainnet is opt-in only.** It runs behind `CCTP_STELLAR_ALLOW_MAINNET` with a
  single-digit USD cap (`CCTP_STELLAR_MAX_USD`, default 5), and the hosted deployment
  carries no CCTP Stellar keys, so production returns a labeled prepared no-op there.

More on the chain itself: [Build on Stellar](/chains/stellar).

## Gateway vs CCTP

| | Circle Gateway | CCTP |
| - | - | - |
| Model | Unified balance + Forwarding Service | Burn-and-mint |
| Destination gas | None (minted gaslessly) | Standard mint on destination |
| Best for | Chain-abstracted spending | Canonical native-USDC liquidity |
| In A-Identity | `mcp/src/gateway.ts` | `mcp/src/cctp.ts` |

> [!WARNING]
>
> Leaving Arc, the bridged amount must exceed the CCTPv2 max fee: tiny testnet
> transfers can revert with "Max fee must be less than amount". The demo defaults to
> 1 USDC.

> **[Build on Arc](/chains/arc)**
>
> Arc is the primary rail: gas in USDC, sub-second finality. CCTP and Gateway extend
> it across chains.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.