Gauntlet is excited to announce an engagement with the Arbitrum Foundation to support the migration from bridged USDC.e to native USDC on the network. As part of this project, we created this initial report to summarize the problem and our approach. In the coming weeks, we will publish a full methodology and recommendations for the migration and discuss these with the community in a live AMA.
Overview
- This document serves as a starting point for the Arbitrum community to reach consensus around the risk(s) and tool(s) needed to support the USDC.e migration.
- The framework developed in this document is expected to lay the foundation for future methodology on systematic way(s) to think about asset migration(s).
How to Conduct a $1B [or larger] Risk Transfer of Stable Asset(s)
- $1B of ARB.USDC.e is nothing like $1B of Dogecoin.
- [at least] 750X this volume trades on a daily basis in the FX Market.
- You could find market maker(s) willing to quote entire blocks of a similar risk profile.
- The big difference here is the underlying liquidity.
- USDC.e doesnât possess the market depth that exists in FX either publicly or privately.
Problem Statement
The Arbitrum community is seeking to transition its USDC.e stablecoin usage into USDC. In effect, it seeks to deprecate bridged tokens in favor of native tokens. While Circle has released the CCTP protocol to facilitate risk transfer(s), uncertainties remain around the success of this asset migration / stablecoin deprecation. This report outlines a universal framework for thinking about risk(s) at the ecosystem level to better guide the community. Success equates to both the minimized use of bridged tokens in favor of native USDC on the Arbitrum L2 going forward and protecting the community throughout this process.
âTable of Contentsâ
1. Historical Background on the USDC.e Migration(s)
2. Why Native Token(s)?
3. Success Criteria & Characterization of ARB.USDC.e
4. A Framework for Analyzing Market Risk(s)
5. Measuring âEcosystem Riskâ
6. Tool(s) to Manage at the âEcosystem Levelâ
7. What can go wrong? Where do we go from here?
X. Appendix
USDC v. USDC.e [ or: native v. bridged ]
All else equal, we should prefer native USDC to bridged USDC.e.
Itâs simpler and more secure.
What are Bridged Tokens?
Bridging technologies, such as the Avalanche Bridge, facilitate the transfer of assets between chains. For instance, the AVAX bridge allows risk to transfer between Ethereum and Avalanche. If a user has stablecoin sitting on ETH i.e. ETH.USDC, that user can [via the simultaneous creation of an asset and a liability through ledgers on the backend] spawn AVAX.USDC.e collateral which is equivalent (barring pricing and liquidity consideration(s) among other things) to the original asset in the sense that it can be unbridged back to ETH.USDC.
Simple how?
Native tokens reduce dependencies. Instead of collateral depending on the dynamics driving another chain, it only depends on Circle and the management of the reserves. Further, USDCe. is deployed by the Arbitrum Foundation, while USDC is deployed by CENTRE.
Secure how?
Native tokens do not have the same risks that arise from cross-chain dependencies.
Whatâs with the Get-Up, Chump?
The Avalanche Bridge uses a set of validators that approve transactions before they are finalized on the Avalanche network. The transition to native USDC required a reconfiguration of the Avalanche ecosystemâs infrastructure and a reassessment of the methodologies employed in stablecoin integration. This transition involved not only technical adjustments but also strategic decision(s) regarding liquidity management, tokenomics, and ecosystem development.
As events like the Multichain MPC bridge hack make apparent, there are many technical and security risks around bridged assets. These incidents underscore the importance of not only robust security measures, but also comprehensive risk management in the migration process. While the AVAX migration is not fully successful [yet], this historical precedent shows the opportunity to consolidate liquidity, streamline stablecoin usage, and enhance the overall utility of USDC within the Arbitrum ecosystem. The community can take lessons from the AVAX situation when thinking about the deprecation of bridged tokens.
On Success & âThe Migrationâ
Adoption Curve(s)
ARB.USDC.e [on a 2-9 month horizon]
Since Gauntlet began monitoring the one-to-one, unbounded migration of USDC.e on ARB (§A.1), nearly $150M (17%) of the USDC.e has been unbridged. By âunbridgedâ we mean the USDC.e collateral that has been removed from the Arbitrum L2 and been restored to the Ethereum L1. While most of this collateral (75+%) has shifted back into the ecosystem in the form of ARB.USDC, some has transitioned to different ecosystems. **This is expected. Unbridging is validation that early adopters see the value of transacting in native token vs. bridged token.
While we expect this trend to continue in the short term, there is a natural limit to this process. There is substantial uncertainty on the specific path that the Arbitrum community will decide upon regarding the deprecation of USDC.e collateral. As a result, we must condition expectations accordingly. For the purposes at hand, we benchmark against AVAX.USDC.e while still considering the trend of adoption in technologies over the last 100 years (§A.2).
The success of this migration will depend on the security of the bridging platforms, the liquidity of the assets being migrated and the overall market conditions. The migration also highlights the need for ongoing research and development in the areas of stablecoin integration, blockchain interoperability, and DeFi ecosystem risk management.
Aligning Expectation(s)
(A) Initial Market State - [Snapshot on 2023-08-16]
(B) Complete Migration Market State (< 1% probability) [unattained on AVAX]
(C) Equivalence Market State (40-60% probability) [~2 months on AVAX]
(D) Native Asset Preference State (20-40% probability) [~4 months on AVAX]
(E) Bridged Asset Preference Market State (0-40% probability) [~1.5 months on AVAX]
On Market Risk(s)
Relevant Dimension(s)
- Price: Risk of asset prices moving unfavorably.
- Liquidity: Risk of being unable to buy/sell assets in expected fashion.
- Volatility: Risk of unexpected price changes.
- Flow: Risk related to asset flow and redemption requests.
- Credit: Risk of counterparty failure.
There were shortfalls in the USDC.e migration on Avalanche across several dimensions of risk. While we will go in more detail in our future methodology report, the main drivers of bridged token migration(s) are price and liquidity. As we investigate the safety of the ecosystem with an eye towards minimizing the negative impacts on LPâs, we find that the community needs to come to agreement on broader aspects of system, incentive and mechanism design.
On Metric(s)
There are two initial directions on which we can analyze the state of the migration: (A) the dynamics that drive the USDC/USDC.e. exchange rate (B) user level behavior around token adoption. We provide an initial outline of (A) in §A.3 and an initial outline of (B) in §A.4 as well as ways to think about the mechanism(s) of risk transfer in §A.5. In view of leaving technical and mathematical detail(s) for later community engagement(s), we outline the central question(s) that our framework has been designed to answer:
- Is the relationship between USDC and USDC.e on Arbitrum stable?
- Are users able to transact both tokens for size?
- Has a given user interacted with USDC yet?
- Has a given user begun migrating from USDC.e to USDC?
- How far along the USDC migration is a given user?
On Challenge(s)
Without seeking to spread FUD, we outline several challenges the community could face as it seeks to migrate USDC.e collateral into USDC on Arbitrum. In view of looking at risk at both the ecosystem and microstructure level, we can separate between âMacroâ and âMicroâ risks.
Macro Risk(s)
- Disjoint Migration Process
a. Stop(s) / Start(s) relative to rapidly changing liquidity conditions
b. Halt(s) due to risk management around concentrated protocol exposure(s)
c. Uncertainty of user behavior due to insufficient metadata - Bridging Problems
a. CCTP has unexpected behavior
b. Unexpected Lag(s) in Risk Transfer(s) - USDC.e asset(s) being unbridged from Arbitrum without being onboarded back onto the L2
- Knock-on effect(s) of asset flow in the context of unbalanced ecosystem incentive design
a. âBlowing out your shorts in an attempt to help out your longsâ - Faulty mechanism or system design causing either (A) Circle, (B) ARB users or (C) protocols on ARB to unnecessarily lose collateral
- Complicated UX dis-incentivizing USDC.e laggards from adopting USDC
Micro Risk(s)
- Stable Asset(s) / Exchange Rate(s) becoming Unstable
a. 2023Q1 Gauntlet USDC De-Peg Analysis can be found in §A.10 - Cross-Protocol Pricing Discrepancies due to Nonstandard Oracle Usage (§A.11)
- Liquidity Drying Up / Pools Becoming Unbalanced
a. Users being liquidated / unable to transfer assets
i. Distribution of liquidations on Arbitrum can be found in §A.9
b. Protocols may preemptively liquidate given implied market depth
c. No âlender of last resortâ - Elevated likelihood of both liquidations and insolvencies if protocol parameters are not suitably conditioned on volatility expectations in context of public and private liquidity
- Token Transfer Issue(s) / Cross-Chain Asset-Liability Mismatch(es)
On Ecosystem Lever(s)
Protocols in Scope
- Radiant
- USDC.e Pool
- Levers
- Max LTV
- Liquidation Threshold
- Liquidation Bonus
- Monitoring Schema
- Identify risky borrowers (borrowers within X% of liquidation)
- Alerting around USDC.e collateral amount as a percentage of USDC.e TVL on Arbitrum.
- Alerting around USDC.e borrow amount as a percentage of USDC.e TVL on Arbitrum.
- Levers
- USDC Pool (not currently deployed)
- Levers
- Max LTV
- Liquidation Threshold
- Liquidation Bonus
- Monitoring Schema
- Identify risky borrowers (borrowers within X% of liquidation)
- Alerting around USDC.e collateral amount as a percentage of USDC.e TVL on Arbitrum.
- Alerting around USDC.e borrow amount as a percentage of USDC.e TVL on Arbitrum.
- Levers
- USDC.e Pool
- GMX
- Bridged USDC (USDC.e)
- Levers
- fundingFactorPerSecond
- fundingExponentFactor
- borrowingFactor
- borrowingExponentFactor
- maxLongOpenIntereset
- reserveFactor
- positionFeeFactorPositive
- positionFeeFactorNegative
- Monitoring Schema
- Alerting around USDC.e pool size as a percentage of USDC.e TVL on Arbitrum.
- Alerting around USDC.e pool utilization rate.
- Alerting around USDC.e target weight, current weight, and the ratio.
- Levers
- USDC
- Levers
- fundingFactorPerSecond
- fundingExponentFactor
- borrowingFactor
- borrowingExponentFactor
- maxLongOpenIntereset
- reserveFactor
- positionFeeFactorPositive
- positionFeeFactorNegative
- Monitoring Schema
- Alerting around USDC pool size as a percentage of USDC TVL on Arbitrum.
- Alerting around USDC pool utilization rate.
- Alerting around USDC target weight, current weight, and the ratio.
- Levers
- Bridged USDC (USDC.e)
- Aave
- USDC.e Pool
- Levers
- LTV
- Liquidation Threshold
- Liquidation Bonus
- IR Curve
- Reserve Factor
- Isolation Mode / Emode Parameters
- Borrow and Supply Cap
- Monitoring Schema
- Identify risky borrowers (borrowers within X% of liquidation)
- Alerting around USDC.e collateral amount as a percentage of USDC.e TVL on Arbitrum.
- Alerting around USDC.e borrow amount as a percentage of USDC.e TVL on Arbitrum.
- Levers
- USDC Pool
- Levers
- LTV
- Liquidation Threshold
- Liquidation Bonus
- IR Curve
- Reserve Factor
- Isolation Mode / Emode Parameters
- Borrow and Supply Cap
- Monitoring Schema
- Identify risky borrowers (borrowers within X% of liquidation)
- Alerting around USDC collateral amount as a percentage of USDC TVL on Arbitrum.
- Alerting around USDC borrow amount as a percentage of USDC TVL on Arbitrum.
- Levers
- USDC.e Pool
- Uniswap
- Top 5 USDC.e Pool
- Levers
- Deploy a new pool with X% fees.
- [New incentive program] - Not in scope of current engagement.
- Monitoring Schema
- Alerting around USDC.e trade volume (for each pool) as a percentage of USDC.e TVL on Arbitrum.
- Alerting around USDC.e trade volume (for each pool) as a percentage of USDC.e total liquidity (in each corresponding pool) on Arbitrum.
- Alerting around USDC.e total liquidity (for each pool) as a percentage of USDC.e TVL on Arbitrum.
- Levers
- Top 5 USDC Pool
- Levers
- Deploy a new pool with X% fees.
- [New incentive program] - Not in scope of current engagement.
- Monitoring Schema
- Alerting around USDC.e trade volume (for each pool) as a percentage of USDC.e TVL on Arbitrum.
- Alerting around USDC.e trade volume (for each pool) as a percentage of USDC.e total liquidity (in each corresponding pool) on Arbitrum.
- Alerting around USDC.e total liquidity (for each pool) as a percentage of USDC.e TVL on Arbitrum.
- Levers
- Top 5 USDC.e Pool
- Vertex (§A.11)
On Future Work
Ecosystem risk management is a game of (A) identifying, (B) analyzing, (C) communicating and (D) adjusting the relevant protocol levers to minimize holistic negative impacts on LPâs. While the early adopters of the migration continue to shift collateral into the new USDC, the community needs to take further action needs taken to further action to facilitate the rest of the process. As we have outlined above, the primary gradient(s) of market risk are (1) price and (2) liquidity. However, the community needs to make considerations about (3) volatility, (4) flow and (5) credit in the context of suitable design to comprehensively map out risk(s) at the ecosystem level. Incentives shapes adoption likelihood, mechanisms shape adoption success, and system design shapes feasibility.
Community Engagement
In view of supporting this framework, Gauntlet will be doing an AMA with the Arbitrum Foundation in the next couple weeks. Further, we will release a Methodology Report that extends this framework to a comprehensive analysis after community feedback. Further announcements coming.
Appendix
§A.1: Individual Class(es) of Deprecation Model(s)
- Many-to-Many
- n asset(s) to m asset(s) with n deadline(s)
- Many-to-One
- n asset(s) to 1 asset with n deadline(s)
- One-to-One
- 1 asset to 1 asset with 1 deadline
- One-to-One, Unbounded
- 1 asset to 1 asset without a deadline
§A.2: Adoption Curve Slope(s)
Adoption curves are getting steeper over time due to increased network effects. However, not all adoption curve converge to 100%. While some curves converge to 100 - e, others converge to 100 - c where 0 < e << c < 100. This is due to structural constraints around adoption for a given technology (you canât build fiber wires everywhere). While these constraints vary with the product [e.g. GPT vs. electricity], there are reasons to believe - in general - that we should align expectations based on what adoption curve(s) are expected to look like given technological constraints and forward looking view(s) on network effects.
§A.3: Exchange Rate(s)
§A.3.1: Definition(s)
§A.3.2: Context
The âexchange rateâ is to be understood in the same way as exchange rates in the FX market. The most important dimension is stability. Stability can be characterized by (A) the relative prices and (B) the volatility of the rate. When deprecating volatile assets, we need to adjust expectations accordingly. Further, liquidity considerations are implicit in exchange rate stability. A necessary condition of exchange rate stability is the ability to transact the relevant collateral in a stable fashion for size. This can be (A) fully automated or (B) done via the backing of market-makers. If a fully automated solution is decided upon, some entity must be assigned the equivalent capacity of âCentral Bankerâ to ensure there is sufficient collateral [of either token] in the pool. If liquidity dries up and there is no entity and/or mechanism to backstop liquidity, the migration can fail. This is why in traditional financial system(s) there is usually a âlender of last resort.â
§A.4: Some Atomic User Characteristic(s)
§A.4.1: Definition(s)
§A.4.2: Context
A more precise characterization would index on time, factor in dynamic prices/liquidity and analyze transactions atomically. We abstract from these dynamics in the initial migration report, but may add complexity depending on future Arbitrum community consensus.
§A.5: Mechanism(s) to Support Migration(s)
Implicit in a migration is some mechanism that facilitates risk transfer(s). There are two main ways that this mechanism can be backed. §A.5.1 is via an implicit extension of credit. §A.5.2 is via the creation and redemption of the assets into common liquidity. We go into more detail on these market mechanisms below. Let D be the deprecating collateral, T the target collateral and C common liquidity [usually, C = USD, but C can be ETH].
§A.5.1: Extension(s) of Credit
§A.5.1.1: A Useful Analogy
When you sit down at a restaurant and run up a tab, that restaurant is implicitly extending you short duration credit. That is, they underwrite the debt until you pay for the meal.
§A.5.1.2: A Mechanism Specification
- Transfer of D from user to custodian
- Transfer of T from custodian to user
§A.5.1.3: Context
In the ARB.USDC.e situation, [credit] risk is being specifically underwritten given the dependency between counterparties. If the custodian fails to transfer back T, the user is subject to counterparty failure. If an adversarial user sends defective units of D and the custodian does not detect its insufficiency before sending back T, the custodian is subject to counterparty failure. In most situations, the asset transfer(s) in this framework would be (relatively) instantaneous and the risk is primarily on the custodian who creates a synthetic long D / short T position that is flattened once the custodian receives the D collateral in its account.
§A.5.2: Creation(s) / Redemption(s) [CR/RD]
§A.5.2.2: A Mechanism Specification
- Transfer of D from user to custodian
- Redemption of D into C
- Creation of T from C
- Transfer of T from custodian to user
§A.5.2.3: Context
The tradeoff here is that the we give up instantaneous transfer for minimized credit risk. While the collateral still goes from user â custodian â user, instead of D being instantaneously swapped for T (from the userâs perspective), we introduce some lag and a mechanism that can spawn and collapse collateral of heterogeneous type(s). This mechanism [CR/RD] converts D into common liquidity C and then uses that to create units of T that are sent back to the user. As removing risk is generally more complicated than adding risk, the bottleneck for most assets is (2) particularly when there are features like bridging that need to be undone from the standpoint of the custodian.
While this may seem like an tangential set of concepts more tied to ETF Arbitrage in TradFi than Asset Migration(s) in Web3, it is particularly important in the case of bridged assets. In particular, we cannot assume in general that the un-bridging of assets will occur instantaneously. Rather, we should expect a lag (which can be variable depending on smart contract design). Due to this lag, we should not think of credit provision in the atomic sense like we can do for things like Flash Loans on Aave. Instead, we should think of credit provision on a longer horizon. As a result, the community needs to achieve consensus on how it plans to manage credit risk(s).
§A.6: Metadata
Beyond transparency, distributed consensus & anti-censorship among other useful properties, Web3 infrastructure allows ecosystems and protocols to spin up new assets to track metadata. A concrete example is an LST like stETH where that token tracks the metadata tied to the staking of ETH with LIDO DAO. It is a contingent claim, not a first class citizen as far as collateral goes. Given this powerful ability to spawn tokens to track metadata, the community should think more deeply about what they would like to track about their users and how tokens tracking metadata can be used to get a more robust picture of ecosystem asset migration.
§A.7: Incentive Optimization(s)
Positions have inertia. By default, we should expect risk to remain where it is absent outside incentives. While superior technological innovation (e.g. native vs. bridged tokens) is one such incentive, in general this will not be sufficient for 100% adoption. In a Web3 context, adoption is a function of decentralized coordination. In addition to metadata, the community should investigate other dimensions of smart contract design that can be used to speed up adoption (e.g. IR research, structured rewards / airdrops, rebates, community equity tokens, etc.)
§A.8: Recursive Strategies & âTrappedâ Collateral
Images taken from this Gauntlet medium post
§A.9: Liquidation(s) on ARB
§A.10: USDC De-Peg Event of 2023Q1
§A.10.1 Real-Time Gauntlet Analysis
[ARC] Stablecoin Volatility Risk Parameter Recommendations
§A.10.2 USDC/USDT 3Pool Liquidity Drying Up
§A.10.3 Slippage on USDC/USDT swaps on ETH , AVAX & MATIC
§A.10.4 Mark-to-Market (MTM) Insolvency on AVAX Aave V3
§A.11: Vertex
As seen by the TVL in the pools described in the figure below, this protocol still in its infancy.
However, the protocol shows steady growth similar to other projects in the Arbitrum ecosystem.
Vertex offers 3 categories of markets: (A) Spot, (B) Perpetual Futures and (C) Money Markets. While some of the initial parameters for Spot and Futures markets have been documented, risk management of this protocol is more complex for two main design reason(s):
- Vertex aims to achieve 10-30 ms transaction speeds (competitive with CEX). To facilitate high-frequency marking of positions on the platform, it intends to use Stork as a pricing oracle.
- Vertex offers âUniversal Cross Marginâ which is similar in principle to E-Mode in Aave V3 but a larger diversity of collateral is involved. We need to factor in additional risk dimensions like flow.
Spot Market
- Levers
- Small Cap
- Large Cap
- Floor
- Inflection
- Interest Fee
- Monitoring Schema
- Alerting around USDC trade volume (for each pool) as a percentage of USDC TVL on Arbitrum.
- Alerting around USDC trade volume (for each pool) as a percentage of USDC total liquidity (in each corresponding pool) on Arbitrum.
- Alerting around USDC total liquidity (for each pool) as a percentage of USDC TVL on Arbitrum.
Perpetual Futures Markets
- Levers
- Price Increment
- Min Size
- Size Increment
- LP Spread
- Initial Margin
- Maintenance Margin
- Maker Fee
- Taker Fee
- Rewards
- Min Depth
- Max Spread - Monitoring Schema
- Identify risky LPs (users within X% of liquidation based on their Health Battery)
- Alerting around funding rates for each market containing USDC.
. In the context of the Arbitrum USDC.e migration, what we are particularly concerned with is the USDC/USDC.e exchange rate which will be referred to as ER. In an ideal case, ER = 1 at all times. Not only would this require an ungodly amount of liquidity (more than needed for migration success), but in the same way as expecting 100% USDC.e deprecation on a medium term timeline is unreasonable, so is expecting ER = 1 at all times. A more suitable target is 
where
. In effect, we expect the exchange rate between USDC and USDC.e to be normally distributed around 1 with variance to the tune of a 5 vol asset.