Native USDC and CCTP Integration

Author(s): RL Status: Proposed Related Discussions: https://forum.across.to/t/native-usdc-and-cctp-integration/1911/1

Summary:

Two versions of USDC exist on many L2s that Across supports: a “bridged” version via a chains’ bridge and a “native” version via Circle’s CCTP. Of the chains Across currently supports, both versions currently exist on Arbitrum, Optimism, Polygon, Base, and ZkSync, with Linea being the only chain with solely bridged USDC.

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

Motivation:

Currently, the Across USDC LP functions as a lending facility for relayers to take repayment quickly without waiting on the latency of a chain’s “canonical” bridged, which can be up to 7 days for optimistic rollups (ORUs). This functions well but requires a relatively large USDC LP and during times of imbalanced flow, utilization can increase which ultimately increases costs for end-users.

Moreover, the adoption of native USDC is growing on all L2s where it exists, and over the long term we expect the market to migrate from bridged USDC to native USDC fully.

To address the above, Across will integrate CCTP and native USDC, using it as the “canonical” bridge for USDC between mainnet and all L2s with CCTP support. This will enable Across to offer the fastest and cheapest method for native USDC bridging and bridged <> native USDC cross-chain swaps.

Specification & Implementation:

This proposal will include making the following changes to the protocol:

On all L2s: Update L2_SpokePool implementations to use CCTP On L1: Update L2_Adapter implementation to use CCTP Update deposit routes and pool rebalance routes to native USDC

Upon successful vote, Risk Labs will implement these contract changes, using a phased rollout to one L2 first, such as Polygon, and then expanding to all L2s where CCTP is available.

Downtime:

The above migration will require temporary downtime of USDC bridging.

Rationale:

This migration presents a valuable opportunity for Across to capture native USDC volume while maintaining our market position for bridged USDC and improving capital efficiency and LP utilization.

Capital Efficiency

CCTP’s latency (the time to bridge native USDC between chains) is on the order of 10-20 minutes vs. 7 days for current ORU bridges. By migrating to native USDC and using CCTP to rebalance, Across avoids the 7-day latency of ORUs, thus significantly reducing the need and cost of external LP and virtually preventing any periods of increased utilization.

Cheaper and Faster vs. pass-through CCTP integration

Many providers integrate CCTP as a pass-through service by providing a front-end that points directly at Circle CCTP contracts to bridge USDC. This suffers from two drawbacks: 1) increased gas costs of interacting with CCTP contracts and 2) fill times on the order of 10-20 minutes. Across’ intent protocol enables cheaper and faster native USDC bridging vs. a pass-through CCTP integration by enabling relayers to fast-fill users with native USDC in seconds. Later, relayers get repaid by Across’s aggregated and gas-optimized settlement process, which will leverage CCTP to rebalance USDC to repay relayers. The net effect is lower fees and faster speeds to bridge most sizes of native USDC Across users.

Cross-chain Swaps of Native and Bridged USDC

While we eventually expect the market to migrate to native USDC fully, this will take time, and bridged USDC is still heavily used. Therefore, we want to maintain our ability to offer the cheapest and fastest service for bridged USDC and offer cross-chain swapping between bridged and native USDC. With Across V3, deposits can specify an output token that differs from the input token, and this functionality enables cross-chain swaps of bridged<>native USDC. Post-migration, on Ethereum, Polygon, Optimism, Arbitrum, Base, and Across will offer:

The Across dApp will 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. However, this functionality will not be embedded in Across contracts or APIs.

Key Takeaways

By supporting both bridged and native USDC, Across can cater to a wider array of user needs and use cases, enhancing user satisfaction and engagement. It also helps in attracting a diverse user base who might require different versions of USDC for their specific on-chain activities.

Finally, as Across currently only supports bridged USDC, the system capital efficiency is constrained due to locking funds in the canonical bridge in L2 to L1. This constraint is removed once Across migrates to using CCTP as the “canonical” bridge for USDC. This will minimize the need for USDC LP, which will reduce the need to pay ACX emissions

Downside (Cons):

This migration presents the following risks:

Downtime We expect minimal downtime (of only USDC bridging), but if issues are encountered, downtime could be extended, impacting user experience.

Bridged USDC Competitiveness Today, Across enjoys a dominant share of bridged USDC bridging volume due to its superiority in cost and speed. Post migration, the Across dApp will maintain support for bridged USDC volume, however with slightly increased costs as an origin-chain swap from bridged to native USDC is required. This additional cost could cause Across to be priced higher vs. competitors for bridged USDC, putting pressure on Across’s market share and volume. Risk Labs’ internal analysis suggests Across should gain as much market share of native USDC as we lose from bridged USDC, signalling a no-loss decision to migrate.

Voting:

If this vote is to go through, Across will integrate CCTP and support for Native USDC on the following chains,

• Optimism
• Arbitrum
• Base
• Polygon
• ZkSync A “FOR” vote would result in the integration of CCTP and Native UDSC on Optimism, Arbitrum, Base, Polygon, ZkSync and future chains where CCTP becomes available, with the upgrade process and contract changes exclusively managed by Risk Labs without further governance involvement.

An “AGAINST” vote would result in no changes to the protocol at this time.