Gauntlet's USDC.e Initial Migration Report

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)

Untitled (2)

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]
arb1
(B) Complete Migration Market State (< 1% probability) [unattained on AVAX]
arb2
(C) Equivalence Market State (40-60% probability) [~2 months on AVAX]
arb3
(D) Native Asset Preference State (20-40% probability) [~4 months on AVAX]
arb5
(E) Bridged Asset Preference Market State (0-40% probability) [~1.5 months on AVAX]
arb6

On Market Risk(s)

Relevant Dimension(s)

  1. Price: Risk of asset prices moving unfavorably.
  2. Liquidity: Risk of being unable to buy/sell assets in expected fashion.
  3. Volatility: Risk of unexpected price changes.
  4. Flow: Risk related to asset flow and redemption requests.
  5. 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)

  1. 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
  2. Bridging Problems
    a. CCTP has unexpected behavior
    b. Unexpected Lag(s) in Risk Transfer(s)
  3. USDC.e asset(s) being unbridged from Arbitrum without being onboarded back onto the L2
  4. 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”
  5. Faulty mechanism or system design causing either (A) Circle, (B) ARB users or (C) protocols on ARB to unnecessarily lose collateral
  6. Complicated UX dis-incentivizing USDC.e laggards from adopting USDC

Micro Risk(s)

  1. Stable Asset(s) / Exchange Rate(s) becoming Unstable
    a. 2023Q1 Gauntlet USDC De-Peg Analysis can be found in §A.10
  2. Cross-Protocol Pricing Discrepancies due to Nonstandard Oracle Usage (§A.11)
  3. 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”
  4. Elevated likelihood of both liquidations and insolvencies if protocol parameters are not suitably conditioned on volatility expectations in context of public and private liquidity
  5. 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.
    • 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.
  • 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.
    • 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.
  • 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.
    • 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.
  • 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.
    • 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.
  • 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)

  1. Many-to-Many
    • n asset(s) to m asset(s) with n deadline(s)
  2. Many-to-One
    • n asset(s) to 1 asset with n deadline(s)
  3. One-to-One
    • 1 asset to 1 asset with 1 deadline
  4. 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

  1. Transfer of D from user to custodian
  2. 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

  1. Transfer of D from user to custodian
  2. Redemption of D into C
  3. Creation of T from C
  4. 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):

  1. 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.
  2. 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.
    1. Reason(s) to generalize Killswitch Methodology from existing protocols like Aave

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.
20 Likes

Am I missing something here, or is there no actionable or any actual outcome suggested?

This just seems like a bunch of words and some screenshots forcing basic logical reasoning into mathemetical equations.

Would love to see some suggestions from the gauntlet team as well.

2 Likes

Hi @JoakimEQ, this initial migration report is meant to provide context and a framework for conducting migration on an ecosystem-wide level. We are planning on releasing a methodology and recommendations report within the next week which will include next steps on solutions.

5 Likes

Cool! Reminds me of my academia days of just filling in lots and lots of pagecount but only getting to any actual useful conclusions in the final pages of the paper. Looking forward to seeing those next steps!

4 Likes

Gauntlet Methodology & Recommendations Report


Abstract (TL;DR)

This report outlines a three-fold focus:

  1. A framework for lending protocols that aligns with the changes in liquidity pool (LP) positions as a result of the initial recommendations

    a. For Radiant & Aave: Reduce LTV & LT for USDC.e by 3% weekly after initial liquidity analysis is conducted

  2. Initial recommendations for liquidity requirements, including suggestions about liquidity pools and GMX recommendations.

    a. For GMX: Decrease Target Allocation for USDC.e (numbers below)
    b. For GMX: Increase Target Allocation for USDC (number below)
    c. (Not in Scope) For Arbitrum: Incentivize liquidity for a USDC/USDC.e pool

  3. An alerting plan around USDC.e and USDC given the prescribed deprecation plan for USDC.e in lending protocols, aiming to ensure a smooth transition for users and providers.

Protocol Recommendations

GMX Tranching Recommendations

USDC.e Target Allocation 30.0% → 27.5%

USDC Target Allocation 3.0% → 5.5%

As the largest liquidity source for USDC.e in the Arbitrum ecosystem, this initial recommendation will serve two purposes:

  1. Initialize the transition away from USDC.e in the GMX V1 pool
  2. Provide data on how liquidity providers and trading volume respond to protocol changes.

We will monitor the changes and fold the analysis into our future recommendations based on the methodology below. We are also planning to review the buffer amounts for each of these assets on GMX V1 in the near future.

Liquidity Pool Considerations and Recommendations

USDC/USDC.e swaps on ETH.ARB should be stable, cost-effective and have low volatility.

(Not in scope, NIS) Gauntlet recommends to incentivize a liquidity pool [ which we will refer to as POOL ] with a robust set of lever(s) to adjust liquidity provider fee(s), in order to facilitate the USDC/USDC.e swap for global users. We recommend the Arbitrum Foundation and broader community push towards a concentrated, one-stop, solution to establish the market depth and mechanisms needed to successfully facilitate the migration from USDC.e on ARB. The example linked below is a current USDC.e/USDC pool with approximately 4.5M of TVL.

https://info.uniswap.org/#/arbitrum/pools/0x8e295789c9465487074a65b1ae9ce0351172393f

Aave and Radiant recommendations

We propose a weekly 3% reduction in the Loan-to-Value (LTV) and Liquidation Threshold (LT) for USDC.e on both the Aave and Radiant platforms, aiming to encourage users to switch to USDC. Alongside these adjustments, we plan to communicate with the respective communities in advance of any expected liquidations due to these changes. These recommendations will be made after collecting and analyzing preliminary data on changes in liquidity. Please take a look at the methodology section below for more details.

Introduction & Summary of Previous Report

In our Initial Migration Report, we outlined the following as the most relevant dimensions of market risks in context of the active ARB.USDC.e migration:

  1. Price: Risk of asset prices moving unfavorably.
  2. Liquidity: Risk of being unable to buy/sell assets in expected fashion.
  3. Volatility: Risk of unexpected price changes.
  4. Flow: Risk related to asset flow and redemption requests.
  5. Credit: Risk of counterparty failure.

For this methodology and recommendations report, we want to highlight the trade-offs between a fast vs. slow migration, provide explicit bounds for liquidity, and identify user migrations to consider.

Towards a Proposal: Additional Detail

Some Prescription(s)

While these recommendations are ultimately up to the community to agree on, we want to highlight that the intention of these mechanisms is to ensure the net edge of asset swaps remains around 1 basis points (bps) (100 bps = 1%). While incentive optimization is out of scope of Gauntlet’s current engagement with the Arbitrum Foundation, we note to the community that edge levels in crypto (especially for stablecoin transfers) are often thought of in % when they should be thought of in bps. The issue is often the lack of competition that allows liquidity providers to charge more than they should. From an ecosystem perspective, a necessary condition of a globally optimal asset migration is minimized transaction cost. Put simply, ARB users shouldn’t have to pay much net-net to transfer USDC.e risk into USDC. As a consequence, liquidity provision of the USDC/USDC.e swap shouldn’t have that much “juice.”

What do we mean by “Juice”?

Juice is edge capture. Markets are profit-driven and the entities that provide liquidity to them do so for profit-driven intents (or they blow-up). As a result, an activity like asset swap liquidity provisioning needs to be profitable for the entities engaging in it [usually market makers, but we can’t deny that retail flow loves to punt here]. Game theoretically, these entities want their businesses to be as profitable as possible. As a result, they will “charge a lot” (e.g. wide spreads, front-running, other forms of indirect market impact, etc.) until someone else comes in specifically to compete against them. This emergence of competition and eventual “race to the bottom” (Howard Marks Memo) shows up in all liquid asset classes (Stocks, Bonds, Commodities, FX, Derivatives &c). There is no reason to expect anything different in cryptocurrency markets [SEE: US ETF Market Structure].

If the Arbitrum community wants to be forward-looking, it should condition expectations about market maker(s) and transaction cost(s) accordingly.

Localizing to the USDC/USDC.e Asset Swap

Barring weird market events, stablecoin prices are generally within [0,1]. As a downstream consequence of real numbers (or division algebras, if you will), for any two stablecoins X, Y their exchange rate E = X / Y can be any non-negative real number E. 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.

State of the Migration

In this Methodology & Recommendations Report, we will consider these methodologies in context of the USDC.e Migration at both the protocol and ecosystem level. We begin with fresh mark(s).

2023-08-16 06:00 PM USDC.e USDC
Total Supply 772,142,584 192,426,060
Numbers of Addresses 609,825 52,092
2023-09-15 10:00 AM USDC.e USDC
Total Supply 658,522,640 (-14.71%) 184,852,466 (-3.94%)
Numbers of Addresses 620,574 (+1.76%) 68,697 (+31.88%)

Protocol Level Recommendations

Objective

The objective for this section of the report is concentrated around mitigating risks & ensuring the stability of the ecosystem throughout the migration from USDC.e to native USDC on the Arbitrum Layer 2.

Risk Mitigation in Lending Positions

Objective

To ensure that lending positions involving both USDC.e and native USDC do not expose the ecosystem to outsized risks.

Lending Protocol Methodology

Our recommendation framework is summarized below.

We will suggest decreasing LT and LTV on USDC.e by 3% per week on Aave and Radiant to promote the migration to USDC. To accompany these changes, we will message communities when liquidations are expected as a result of the proposed.

An example alert can be seen below:

Attention: As of date, the data shows that the following accounts would be liquidated if these param changes were adopted. The list below specifies the USD value of collateral that borrowers would need to supply to reach a health factor of 1.1, on the assumption that their account’s composition of collateral types remains fixed.

Supply and Borrow Cap Changes

For lending protocols with supply and borrow caps:

Depending on the community preference, we propose a conservative supply and borrow cap of 80% of the circulating token supply on-chain or an aggressive borrow cap will be 120% of the circulating token supply on-chain.

  • It should be noted that while the total_supply metric refers to the maximum number of tokens that can be generated, the circulating_supply metric provides a more accurate measure of the liquidity that is currently available in the market. This is due to the fact that the circulating_supply metric takes into account the tokens that are in circulation and readily accessible for trading, while the total_supply metric encompasses the entire quantity of tokens that can exist, regardless of whether they have been released to the market or not."

Liquidity constraints for liquidations

Of the 400+ liquidations that have happened on the Arbitrum blockchain since March 1, 2023 involving USDC.e, no significant liquidations have atomically swapped out of their positions. Below is an example of a liquidation that happened in June of this year. Below is the transaction flow of one of the largest liquidations of USDC.e in this time period. As a result, our borrow and supply cap changes are far more relaxed than Gauntlet’s general borrow and supply cap methodology. https://eigenphi.io/mev/eigentx/0xbfd3f31b9cb2e044e6be5303f0f683589fb47d7163f87f864eee4aa3e87fa4a6

Historic USDC price dislocation

See below for the price dislocation event and the corresponding impacts on liquidity for USDC.e on the Avalanche blockchain.

Liquidity Provisions and Support for Liquidity Providers

Objective

The objective for this section of the report is concentrated around identifying potential risks to liquidity providers and defining alerts for each potential risk when possible

Real-Time Monitoring

A real-time dashboard will be developed to monitor trade volumes, liquidity pools, and price discrepancies between USDC and USDC.e.

Notifications and Alerts

Alert mechanisms will be set up to notify liquidity providers of substantial shifts in trading volume or liquidity conditions, thereby enabling them to adjust their positions in a timely manner.

Prioritized Risks

Macro

  1. Complicated UX could dis-incentivize USDC.e laggards from adopting USDC
  2. USDC.e asset(s) being unbridged from Arbitrum might not return as USDC
  3. Bridging problems
  4. Disjointed migration process
  5. Any knock-on effect(s) of asset flow in the context of unbalanced ecosystem incentive design
  6. A faulty mechanism or system design causing either Circle, ARB users or protocols on ARB to unnecessarily lose collateral

Micro

  1. Liquidity could dry up or pools could become unbalanced
  2. Stable Asset(s) / Exchange Rate(s) could become Unstable
  3. Likelihood of both liquidations and insolvencies could increase if protocol parameters are not suitably conditioned on volatility expectations in the context of public and private liquidity
  4. Potential cross-protocol pricing discrepancies caused by nonstandard oracle usage
  5. Token Transfer Issue(s) / Cross-Chain Asset-Liability Mismatch(es)

Preliminary Definition(s)

NIS: “NOT-IN-SCOPE”

SWAP: USDC/USDC.e ; ER: the “effective price” of SWAP

TOKEN: the “effective price” of asset T {USDC, USDC.e}

For a given asset T:

DPGT is the de-peg threshold.

LIQT is the liquidity threshold.

BUFT is the liquidity buffer.

POOLT is the current amount of tokens in POOL

Methodology

Below we summarize strategies for responding to potential risks as they pertain to the dimensions of market risk identified above.

Price

Event(s)

  • USDC.e goes below 1
  • USDC goes below 1
  • ER trades above 1 towards $\infty$

Response(s)

  • If TOKEN < (1- DPGT) for asset T, alert that T is de-pegging
  • If ER >> 1 and ER’ > 0, identify if there is a pricing issue that is increasing demand (at the microstructure level) for the USDC leg of SWAP then alert accordingly
  • If TOKEN >> 1 and TOKEN’ > 0, identify if there is a pricing issue that is increasing demand (at the microstructure level) for TOKEN then alert accordingly
  • [NIS] If ER << 1 and ER’ < 0 and there is no heightened credit risk to Circle, conduct automated creation of USDC collateral and supply liquidity to deepen SWAP depth in POOL
  • [NIS] Design embedded reactive mechanism like Aave Killswitch

Liquidity

Event(s)

  • USDC liquidity in POOL dries up
  • USDC.e liquidity in POOL dries up
  • Relative liquidity between USDC and USDC.e get “out of whack”
  • Liquidity Providers pull out of POOL

Response(s)

  • If POOLT << LIQT, alert that T’s liquidity in POOL has dried up
  • If POOLTLIQT AND POOLT < (1+BUFT)LIQT, alert that T’s liquidity in POOL is in the process of drying up
  • [NIS] Liquidity Provider / Liquidity Taker Wallet-Level Tracking & Analytics
  • If POOLT > (1+2*BUFT)LIQT, alert that POOL has excess T collateral
  • [NIS] Dynamic fee adjustment in context of maker/taker behavior
  • [NIS] Queuing Structure of Liquidity Provision (viz. price-time v. price-pro-rata)

Volatility

Event(s)

  • USDC volatility spikes
  • USDC.e volatility spikes
  • Liquidity providers pull out from POOL due to heightened forward variance expectations regarding USDC, USDC.e and/or SWAP

Response(s)

  • Market alerts in Telegram

Flow [NIS]

Event(s)

  • Spike in volume flowing from USDC —> USDC.e
  • Spike in volume flowing from USDC.e —> USDC
  • Liquidity Providers pull out from POOL due to aggressive liquidity taking
  • Liquidity Takers don’t utilize POOL due to UX complexity
  • Liquidity Takers don’t utilize POOL due to maker impact /transaction cost expectations

Response(s)

  • [NIS] Market-Condition-Dependent “White Glove” Risk Management

Credit [NIS]

Event(s)

  • Circle defaults on its USDC and/or USDC.e liabilities
  • Market Risk(s) damaging the value and/or access to Circle’s collateral (e.g. TradFi Banking insolvencies, funky duration + curvature moves in the risk-free world, repo market stress, government seizure, etc.)
  • Liquidity Providers are short USDC and cannot deliver collateral
  • Liquidity Providers are short USDC.e and cannot deliver collateral
  • Liquidity providers pull out from POOL due to collateral delivery issues

Response(s)

  • Market-Condition-Dependent “White Glove” Risk Management

Next Steps

  • Share GMX, Aave, and Radiant recommendations to their respective communities
  • Deploy alerting & real-time dashboards for scenarios covered in the Ecosystem Risks section
5 Likes