White Paper

Case Study: USDC & SVB Failure 3-10-23

March 10, 2023

Executive Summary of Market Surveillance

As high-velocity real-world events happen impacting tokens like USDC, real-time market surveillance can provide early warning signals. These signals must also deal with providers like Coinbase, Binance, etc potentially using preventative measures to slow contagion and diminish indicators. In fact, efforts to slow impact will often increase more difficult to monitor activity within blockchains. As LWorks collects and creates metrics on every transaction on monitored chains, these events remain clear and as the SVB failure illustrates, effective market surveillance can provide an important early warning capability.

High-level timeline SVB Failure

The surveillance of transfer events

On March 7th there was effectively no significant or abnormal USDC transfer activity on the Avalanche C Chain. Then on March 8th we saw 11 thousand events, which grew to 42 thousand events by March 9th. These events transpired ahead of general public awareness of the USDC related SVB issues becoming widely known on Friday March 10th, as illustrated by a series of high-impact tweets, e.g.:

  • @nic  carter: "Circle's exposure to SVB is a major risk to the crypto market. If SVB were to fail, it could lead to a run on USDC, which could devalue the entire crypto market."
  • @bybt: "Circle's exposure to SVB is unsustainable. Circle is overexposed to SVB, and this could lead to a collapse of the stablecoin."
  • @CoinDesk: "Circle says it has $3.3 billion in exposure to SVB, which was placed into receivership by the FDIC on Friday."
  • @TheBlock: "Circle says it is working with regulators to ensure that USDC holders are not impacted by SVB's failure."
  • @CoinTelegraph: "Circle's exposure to SVB could lead to a run on USDC, which could devalue the entire crypto market."

More interesting was that the activity preceding March 10th largely came from indirect transfers of USDC, meaning activity not involving a Circle Smart Contract, and more specifically from just two accounts:

  1. https://snowtrace.io/address/0x544cd3865b1f44166d8f5117f78144a923681980
  2. https://snowtrace.io/address/0x7ba19bb2a58557cb3c17e9a91e383114452f8541

And the two accounts invoking transfers only invoked a single recipient, a smart contract called multisender1:

And that single recipient was created by one of the accounts that same day2:

USDC transaction volume and Depeg

1 What is the multisender contract used for?

  1. Reduced gas costs: When sending tokens to multiple recipients, each transaction incurs a gas fee. By using a multisender smart contract, users can save on gas costs by bundling together multiple transactions into a single one.
  2. Improved efficiency: Sending tokens to multiple recipients can be time-consuming and manual. By using a multisender smart contract, users can automate the process and save time.
  3. Increased security: When sending tokens to multiple recipients, there is always the risk of human error. By using a multisender smart contract, users can reduce the risk of errors by automating the process.

2 Note that most of these transfer values are 0, suggesting at the time that someone was testing code

Relationship between USDC and USDT (Tether)

Similar to USDC activity, Tether movement began early, before much public information had become available on Silicon Valley Bank and its relationship with Circle.

Final Observations3

In developing market surveillance, a series of rules can provide alerts as signals both at the micro and macro economic levels. These clear signals include monitoring the following activity and dynamically analyzing that activity to develop market intelligence in real-time. Signals include:

  1. Increased swaps
  2. Increased diversity of swappers, i.e. more market participants as opposed to the activity of a whale
  3. Removal of liquidity, i.e. both Liquidity pools and lending pools
  4. Increased transfer calls and parameter references, e.g. multi-sender
  5. Any time-based mathematics can be done at virtually any level including (1) Sender (address), (2) recipient (contract or address), (3) function, i.e. transfer, swap, addLiquidity, etc, and (4) parameter,

i.e. integers, addresses, bytes, etc