Migration to CCTP

Introduction

Across' intent protocol relies on canonical bridges to lend LP capital to third party relayers, who in turn fast fill user orders. CCTP is the canonical bridge of Native USDC. While CCTP is much faster than the latency of optimistic L2 canonical bridges, it is still comparatively slow (on the order of minutes) relative to users expectations (on the order of seconds). Across is migrating to use CCTP as the canonical bridge for USDC, but not simply as a pass-through service.

Through its network of fast relayers and aggregated settlement, Across will offer faster and cheaper bridging of USDC and leverage CCTP to rebalance USDC at the protocol level with less latency, thus increasing capital efficiency and reducing fees for users without increasing trust assumptions.

Currently, Across only supports setting Bridged USDC as the inputToken when specifying an L2 deposit. Post migration, Across will only allow Native USDC as the inputToken in deposits, with support for Bridged USDC possible via a swap on origin, prior to deposit.

Summary of Product Changes

Currently, for L2 origin or destinations, Across only supports Bridged USDC (on the origin) to Bridged USDC (on the destination) transfers. Post migration, Across will no longer support Bridged USDC to Bridged USDC routes, and will support the following new routes:

• On Ethereum, Polygon, Optimism, Arbitrum, Base:

  • Native USDC to Bridged USDC cross-chain swaps

  • Native USDC to Native USDC cross-chain transfers

The Across dApp will also support Bridged-to-Native and Bridged-to-Bridged USDC swaps and transfers by swapping from the users' input asset of Bridged USDC to Native USDC on the origin chain, then depositing Native USDC into Across contracts. But this functionality will not be embedded in across contracts or API.

Eventually, all current L2's with Bridged USDC support on Across migrate to Native USDC support via Circle's Cross Chain Transfer Protocol (CCTP).

This migration will require temporary downtime for USDC deposit routes for each chain where CCTP is being added. The end effect of the migration is that all Bridged USDC deposit routes will be replaced by Native USDC deposit routes on the CCTP-enabled chains.

There are non-breaking changes for Relayers and partners who call the API and Smart Contracts

Relayers and integrations must migrate from Across V2 to V3 as a pre-requisite.

Depositors will be able to use the depositV3smart contract function to bridge Native USDC to Bridged USDC, but setting Bridged USDC as the inputToken will no longer be supported. This might require integrators to upgrade smart contracts to get access to the Native USDC to Bridged USDC routes. The deposit function will continue to work as normal but Bridged USDC routes will no longer be available. Relayers should be prepared to handle the case where Native USDC is bridged to Bridged USDC. The suggested fees API endpoint will add parameters to support the new routes, and all changes will be backwards compatible. Please see the Relayer Migration Guide and API Migration Guide for more details.

Finally, API users must update to reference host of app.across.to/api and reference the new fees object in the response of the /suggested-fees endpoint.

Why should Across migrate to CCTP?

Sending bridged USDC between the L1 HubPool and L2 SpokePools is subject to the same liveness period as the L2's canonical messaging bridge, which is seven days for optimistic rollups and several hours for ZK-rollups. Sending native USDC via CCTP will be much faster, completing in minutes. This has several key benefits for the Across protocol.

CCTP increases capital efficiency of LP funds

Whenever the Across proposes sending L2 tokens to the L1 HubPool, those L2 tokens are sent over the L2's canonical bridge and are effectively frozen and unable to be used by Across until they are released following a liveness window. These funds cannot be used to to repay relayers or execute Slow Fills.

Using CCTP to send USDC between L2 and L1 system contracts, Across can more frequently recycle USDC to repay relayers and execute slow fills. This means that less USDC needs to be deposited by LPs to support the same volume of USDC over some time period pre and post CCTP migration.

CCTP will reduce LP fees on average for end users

By reducing the time that USDC is held in canonical token bridges, USDC utilization should be reduced on average, thereby reducing the LP fee component of bridge fees.

CCTP does not introduce new trust assumptions for LPs or users

Across only uses canonical bridges to send tokens and messages between its L1 and L2 contracts. This means that when Across' LP funds are transferred between L1 and L2, those funds are exposed only to the same security assumptions that users would face if they simply held those funds on the L2. These canonical bridges are secured by the same mechanism that any user submitting a transaction or holding an asset on the L2 faces.

CCTP is the canonical token bridge for Native USDC. Any holder of USDC implicitly trusts Circle, the issuer of USDC, to not censor their transaction or otherwise "misbehave". CCTP is run by Circle, so sending USDC over CCTP does not add additional trusted actors to the Across system.

How will the CCTP Migration be executed?

To upgrade any chain from supporting Bridged USDC to Native USDC, USDC deposits to and from that chain will have to be paused temporarily.

Next, all Bridged USDC should be returned to the HubPool. The Across owner account will then need to upgrade the HubPool's PoolRebalanceRoutes to point from Bridged to Native USDC for the given chain. The chain's SpokePool and L1 Adapter will also need to be upgraded by the owner to send USDC over CCTP using an adapter like this.

Once all contracts and pool rebalance routes are upgraded, deposits can be resumed for the selected chain. After this point, the only type of USDC to be held on the chain's SpokePool will be Native USDC.