Migration to CCTP
Across is migrating to Native USDC via CCTP for faster, cheaper bridging with no extra trust. Expect lower fees and better capital efficiency.
Last updated
Across is migrating to Native USDC via CCTP for faster, cheaper bridging with no extra trust. Expect lower fees and better capital efficiency.
Last updated
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.
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 crosschain swaps
Native USDC to Native USDC crosschain transfers
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.
Relayers and integrations must migrate from Across V2 to V3 as a pre-requisite.
Depositors will be able to use the smart 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 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.
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.
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 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.
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.
Whenever the Across 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 .
By reducing the time that USDC is held in canonical token bridges, USDC utilization should be reduced on average, thereby reducing the of bridge fees.
Across only uses 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.