Payments
CCTP Cross-Chain USDC
Native USDC moves between chains with Circle's CCTP V2 burn-and-mint — no wrapped tokens, no bridge custody. Furlpay builds the calldata; your wallet signs and submits both legs, so funds never touch our keys.
Check the rail before signing
This is a client-signed flow: FurlPay builds transaction data and your wallet submits it. Availability depends on the deployment, supported network pair and current rail status. Check
/api/rails before asking a user to sign. A prepared burn is not a completed transfer; the destination mint must also be confirmed.How a transfer works
Rendering diagram…
Endpoints
| Method | Path | Description |
|---|---|---|
| POST | /api/intents/cctp | Build the burn bundle (approve + depositForBurn) or the mint transaction |
| GET | /api/intents/cctp/attestation | Poll Iris for the burn's message + attestation |
bash
curl -X POST https://furlpay.com/api/intents/cctp \
-H "content-type: application/json" \
-b "session" \
-d '{
"kind": "burn",
"amount": 25,
"sourceChain": "ethereum",
"destinationChain": "arbitrum",
"recipient": "0xYourAddressOnArbitrum",
"fast": true
}'Guarantees and limits
- V2 only — TokenMessengerV2 / MessageTransmitterV2 with addresses verified against Circle's registry; V1 is end-of-life and never used.
- Fast Transfers — 8–20s attestation with a fee ceiling of 1 basis point, paid from the transferred amount.
- Supported chains — Ethereum, Arbitrum, Base, Polygon (native Circle-issued USDC on each).
- Per-transaction cap — burns above the server-side limit (default $500,
FURLPAY_MAX_CCTP_USD) are refused withamount_over_limit. - Every prepared burn/mint and every attestation check feeds the ops event ledger and rail health.
The mint leg is yours to finish
After the burn confirms and the attestation lands, USDC exists nowhere until
receiveMessage executes on the destination. Keep the message + attestation until the mint confirms — they are your claim.Did this page help?
Edit this page on GitHub