CCTP v2 Integration #1215

Closed
opened 2026-09-08 15:23:32 +00:00 by LVS · 1 comment

This issue is to look into the feasibility to integrate CCTP v2 with CL8Y Dex, CL8Y Bridge and Luna Classic to bring native USDC to Luna Classic chain.

CTP is explicitly permissionless: an app, DEX, bridge, exchange, or wallet can integrate the existing CCTP contracts and APIs.

https://help.circle.com/support?id=kb_article_view&sysparm_article=KB0010608

Circle Help Centre
The basic flow is:

  1. Source chain: your DEX calls TokenMessengerV2.depositForBurn(...).
  2. CCTP burns the user's native USDC and emits a cross-chain message.
  3. Circle's attestation service observes the message and signs an attestation.
  4. Your infrastructure obtains that attestation from Circle.
  5. Destination chain: your DEX submits it to MessageTransmitterV2.receiveMessage(...).
  6. TokenMessengerV2/TokenMinterV2 causes native USDC to be minted to the recipient.
  7. Circle Docs

For a DEX, you can go further and use Hooks so that the incoming USDC immediately triggers something like a swap, deposit, or other destination-chain action.

You can also use Fast Transfer by setting the appropriate finality threshold and maxFee; this gives much faster settlement on chains where Fast Transfer is supported.

Circle Docs
So, for example, a DEX on Base <-> Arbitrum doesn't need Base or Arbitrum to "get CCTP." Both chains already have CCTP V2 contracts; the DEX simply integrates with them.
For a new chain this is different - A new chain cannot simply deploy the CCTP contracts itself and declare that it has CCTP. Circle has to add the chain to the CCTP-supported network and deploy/configure the appropriate CCTP infrastructure.

This issue is to look into the feasibility to integrate CCTP v2 with CL8Y Dex, CL8Y Bridge and Luna Classic to bring native USDC to Luna Classic chain. CTP is explicitly permissionless: an app, DEX, bridge, exchange, or wallet can integrate the existing CCTP contracts and APIs. https://help.circle.com/support?id=kb_article_view&sysparm_article=KB0010608 Circle Help Centre The basic flow is: 1. Source chain: your DEX calls TokenMessengerV2.depositForBurn(...). 2. CCTP burns the user's native USDC and emits a cross-chain message. 3. Circle's attestation service observes the message and signs an attestation. 4. Your infrastructure obtains that attestation from Circle. 5. Destination chain: your DEX submits it to MessageTransmitterV2.receiveMessage(...). 6. TokenMessengerV2/TokenMinterV2 causes native USDC to be minted to the recipient. 7. Circle Docs For a DEX, you can go further and use Hooks so that the incoming USDC immediately triggers something like a swap, deposit, or other destination-chain action. You can also use Fast Transfer by setting the appropriate finality threshold and maxFee; this gives much faster settlement on chains where Fast Transfer is supported. Circle Docs So, for example, a DEX on Base <-> Arbitrum doesn't need Base or Arbitrum to "get CCTP." Both chains already have CCTP V2 contracts; the DEX simply integrates with them. For a new chain this is different - A new chain cannot simply deploy the CCTP contracts itself and declare that it has CCTP. Circle has to add the chain to the CCTP-supported network and deploy/configure the appropriate CCTP infrastructure.

Moved to cl8y-bridge-monorepo: code/cl8y-bridge-monorepo#169

Moved to cl8y-bridge-monorepo: https://git.cl8y.com/code/cl8y-bridge-monorepo/issues/169
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
code/cl8y-dex-terraclassic#1215
No description provided.