Nanyang Technological University, Singapore, Singapore National University of
Singapore, Singapore, Singapore Deakin University, Melbourne, Australia
National University of Singapore, Singapore, Singapore Lehigh University,
Bethlehem, Pennsylvania, USA Nanyang Technological University, Singapore,
Singapore D. Reijsbergen, B. Hajek, T.T.A. Dinh, J. Keppo, H. Korth, and A.
Datta [500]Security and privacy

#  CroCoDai: A Stablecoin for Cross-Chain Commerce

Daniël Reijsbergen  Bretislav Hajek  Tien Tuan Anh Dinh  Jussi Keppo  Hank
Korth  Anwitaman Datta

###### Abstract

Decentralized Finance (DeFi), in which digital assets are exchanged without
trusted intermediaries, has grown rapidly in value in recent years. The global
DeFi ecosystem is fragmented into multiple blockchains, fueling the demand for
cross-chain commerce. Existing approaches for cross-chain transactions, e.g.,
bridges and cross-chain deals, achieve atomicity by locking assets in escrow.
However, locking up assets increases the financial risks for the participants,
especially due to price fluctuations and the long latency of cross-chain
transactions. Stablecoins, which are pegged to a non-volatile asset such as
the US dollar, help mitigate the risk associated with price fluctuations.
However, existing stablecoin designs are tied to individual blockchain
platforms, and trusted parties or complex protocols are needed to exchange
stablecoin tokens between blockchains.

Our goal is to design a practical stablecoin for cross-chain commerce.
Realizing this goal requires addressing two challenges. The first challenge is
to support a large and growing number of blockchains efficiently. The second
challenge is to be resilient to price fluctuations and blockchain platform
failures. We present CroCoDai to address these challenges. The key insight is
to extend the existing Dai stablecoin system to a stablecoin that is backed
with collateral tokens from multiple blockchains. CroCoDai leverages the
system’s governance layer (which could be another blockchain) to exchange
tokens between different blockchains – this enables secure cross-chain
commerce and addresses the first challenge. Furthermore, the relatively low
correlation between the price of assets on different blockchains makes
CroCoDai more resilient to financial shocks than a single-chain stablecoin. We
demonstrate this advantage through an empirical analysis that uses real token
price data from a period that includes the collapse of the FTX exchange, which
caused high token price volatility. We present three prototype implementations
of our stablecoin system, and show that it incurs small execution overhead.

††footnotetext: This work was supported by Ministry of Education (MOE)
Singapore’s Tier 2 Grant Award No. MOE-T2EP20120-0003.

###### keywords:

Stablecoins, blockchains, interoperability, financial risk analysis

###### category:

##  1 Introduction

Decentralized Finance (DeFi) promises to revolutionize finance by removing the
need for trusted middlemen to process transactions. In DeFi, transactions
commonly involve a change of ownership of digital tokens that exist on a
distributed ledger such as a blockchain – e.g., one user sending bitcoins to
another [45]. Many blockchain platforms (e.g., Ethereum [8]) also support
smart contracts, which enable automated versions of financial concepts such as
auctions, loans, swaps, decentralized exchanges, and ownership shares. The
total value of the tokens held in DeFi smart contracts peaked at over $150
billion USD in late 2021 [53, 15], with at least $100 billion held in
decentralized exchanges alone [55], and has since fallen to around $45-50
billion as of June 2023 [15].

The DeFi ecosystem is currently fragmented over a multitude of blockchains
which each offer their own choices in terms of efficiency, security, and
functionality. For example, Cardano [28, 31], Solana [57], Avalanche [49], and
Algorand [24] each had a valuation of more than a billion USD in early 2023.
These blockchains are not designed to interoperate: i.e., there is no native
mechanisms for transferring tokens between chains. However, the recent
emergence of blockchain bridges [19] and dedicated interoperability platforms
such as Cosmos [7] and Polkadot [33] demonstrates an increasing demand for
cross-chain interoperability. A major challenge in cross-chain trades is
atomicity: the transactions in a trade must be committed on all blockchains,
or not at all. For example, in a cross-chain auction, the first party to
transfer tokens (e.g., the auctioneer) cannot be sure that the other party
will uphold their part of the trade in the absence of a cross-chain protocol.
This is of particular concern in DeFi, as individual blockchain transactions
are irreversible by design.

Existing solutions that provide cross-chain atomicity, including relays and
hashed time locks [27, 2, 50], essentially lock the assets involved in a trade
and only release (or return) them once the transactions in all of the
blockchains have been committed (or aborted). While ensuring atomicity, this
approach increases the financial risks for the users in the following ways:
1. the tokens held in escrow may lose value due to price fluctuations,  2. one
party may abort the transaction, leading to an opportunity cost for the other
parties, and  3. the DeFi platforms that facilitate the trade may be faulty or
malicious . These risks are interrelated: if there is a significant change in
the value of the tokens in escrow (1.), then this may cause a party to abandon
a trade (2.), creating an opportunity cost to the other users. The risks
identified above are a limitation of all cross-chain protocols that hold
tokens in escrow – the longer the tokens are held, the longer they are exposed
to DeFi’s notorious price volatility [1] and vulnerability to attacks [60].
Although the abandonment of trades can be disincentivized through the use of
premiums [56], price fluctuations can be mitigated in principle if the tokens
held in escrow are stablecoins [32, 9, 44] whose value is pegged to a less
volatile real-world asset (e.g., the US dollar). However, a flawed stablecoin
design can itself put users’ tokens at risk, as witnessed by the collapse of
the Terra/Luna stablecoin in May 2022 [6], in which stablecoins worth 60
billion USD lost nearly all of their value.

Our goal is to design a practical stablecoin as a central point of exchange
for cross-chain commerce. Realizing this goal requires that two main
challenges are addressed. The first challenge is to support a large and
growing number of blockchains efficiently, including new and relatively low-
use platforms. For established platforms, Automated Market Makers (AMMs, [17])
such as Uniswap can be used to exchange tokens for stablecoins within minutes,
and the stablecoins can be transferred between blockchains using a wallet on a
cryptocurrency exchange such as Coinbase or Binance. However, the latter step
may take several hours before the withdrawal on the receiving chain is
processed (e.g., 2-3 hours on Crypto.com [12]), is subject to the exchange’s
transaction fees, and the exchange is a single point of failure. Furthermore,
AMMs depend on depositors to deposit collateral for each supported pair of
cryptocurrencies, and this may not be available for smaller platforms –
similarly, centralized exchanges may not always support transfers on smaller
platforms. Just as an AMM requires depositors willing to create liquidity
pairs, Xclaim [58] requires the availability of a custodian who is willing to
put up collateral on the receiving chain, which can be a challenge for small
blockchains. Finally, secure bridges such as zkBridge [54] either require a
direct bridge to transfer stablecoins between two small blockchains, which may
again be unavailable, or require that they are sent via a larger blockchain in
a two-step process, which incurs additional time and transaction fee costs.
The second challenge in designing a cross-chain stablecoin is to ensure that
it is resilient to black swan events (e.g., 51% attacks) that affect
individual blockchain platforms, and to price fluctuations that affect
multiple blockchains simultaneously. This is particularly relevant if the
stablecoin’s peg is maintained through tokens held as collateral on different
blockchains. If the total value of the collateral drops below the intended
value of the issued stablecoins, then the stablecoin may lose its peg, forcing
holders to sell their tokens at a loss – we will refer to such an event as
system failure.

In this work, we present CroCoDai, a stablecoin for cross-chain commerce that
addresses the above challenges. The key insight is to back CroCoDai with
collateral tokens from a multitude of blockchains, using the same principles
as the existing Dai stablecoin system (DSS) [38] but without being restricted
to the Ethereum ecosystem. To that end, CroCoDai manages communication between
the different blockchains through a governance layer which can be implemented
through a quorum of trusted nodes, or on top of an existing blockchain. By
using the governance layer to create/destroy the same amount of stablecoins on
different chains, CroCoDai supports cross-chain transfers by design.
Crucially, CroCoDai allows tokens on smaller blockchains to be backed by
collateral on larger chains, thus providing stablecoin support to emerging
platforms and addressing the first challenge. Unlike Polkadot or Cosmos,
CroCoDai achieves its goal without requiring intrusive changes to existing
blockchains. To demonstrate how well CroCoDai addresses the second challenge,
we present a technical analysis that shows that attacks on a limited number of
blockchain platforms can be tolerated as long as the system is sufficiently
overcollateralized. We also show that attacks against a limited number of
price oracles (which determine the value of the collateral) can be tolerated –
this is not a challenge specific to multi-chain settings, so this security
property holds for the single-chain DSS as well. Next, we provide evidence for
the greater resilience of a multi-chain stablecoin to price fluctuations
through an empirical analysis based on the collected data from several
periods, including the collapse of the FTX exchange which led to severe
depreciation of the Solana cryptocurrency. Specifically, we compare (1) a
portfolio that approximates the current state of the DSS’ collateral to a
similar portfolio with tokens from multiple chains, and (2) a portfolio that
is optimized for low failure risk using the tokens supported by the DSS to one
with tokens from multiple chains. Finally, we provide a reference
implementation for CroCoDai that uses a dedicated relay chain, and use
experiments to show that the computational overhead of CroCoDai is small. The
code/data used in this work are publicly available via
https://doi.org/10.21979/N9/R60V8F.

#### Contributions

Our work makes the following contributions:

  * •

We present CroCoDai, a cross-chain stablecoin – we present two design
variants: one uses a quorum of nodes as a trust anchor; the other uses an
existing blockchain (Section 4).

  * •

We demonstrate CroCoDai’s security through a technical analysis that
demonstrates that CroCoDai can tolerate a limited number of compromised
blockchains or price oracles (Section 5.1), and an empirical analysis in which
we compare single-chain portfolios to portfolios that use collateral from
multiple chains, and find that the latter has lower failure probabilities.
Specifically, the failure probability is roughly a third lower for optimized
pure-crypto portfolios (Sections 5.2 and 5.3).

  * •

We present three implementations of CroCoDai subvariants that use the quorum-
based approach and compare their gas costs and processing times, to
demonstrate CroCoDai’s practicality and to make its generality/performance
trade-offs explicit (Section 6).

The remainder of the paper is structured as follows. Section 2 provides
background on DeFi and related work. Section 3 presents the system model.
Section 4 presents the design of CroCoDai. Section 5 contains the analysis of
CroCoDai’s resilience against black swan events and price fluctuations.
Section 6 details the three subvariant implementations and corresponding
experimental results. Section 7 discusses future work and concludes the paper.

##  2 Background

###  2.1 General Background

Blockchains & Tokens.  DeFi uses cryptographically secured, decentralized data
structures to replace trusted intermediaries. Blockchains are by far the most
prominent example of such data structures. A blockchain is an ordered list of
transactions grouped into blocks. The principal function of transactions in
DeFi is to transfer tokens, which represent ownership of assets. There are two
common types of tokens: fungible tokens – also commonly called
cryptocurrencies – and non-fungible tokens (NFTs) [13]. Fungible tokens of the
same type are identical, whereas each NFT represents a unique asset.

In the first cryptocurrency platform, Bitcoin [45], each transaction transfers
some amount of the native cryptocurrency (bitcoin, or BTC) between parties. In
Ethereum [8], transactions were extended from transferring the native
cryptocurrency (ETH) to the creation or execution of smart contracts, i.e.,
on-chain software programs. Smart contracts can store data, hold tokens, and
transfer tokens according to the contract’s internal logic, e.g., to implement
an auction. A major use case for smart contracts is to define new
cryptocurrencies that are different from the blockchain’s native
cryptocurrency. In Ethereum, this is particularly facilitated by the ERC20
token standard [51] which defines a common set of smart contract functions
required by any new cryptocurrency. Smart contracts can also support NFTs,
e.g., via OpenSea or Mintable.

Stablecoins.  A stablecoin is a cryptocurrency whose value is pegged to an
underlying fiat currency, e.g., the US dollar.111Cryptocurrencies whose value
is pegged to a real asset such as gold, e.g., the PAXG token, are typically
not considered stablecoins, e.g., they are not labelled as such by
CoinMarketCap. There are multiple types of stablecoins [44, 32], of which the
most common ones are:

  1. 1.

Fiat-backed stablecoins, which are backed by fiat currency held largely in
cash or cash equivalents. The essential guarantee that underpins the price
stability of a fiat-backed stablecoin is that in case of system shutdown, each
stablecoin can be used to redeem a corresponding amount of the pegged fiat
currency.

  2. 2.

Crypto-collateral-backed stablecoins (or crypto-backed stablecoins for
brevity), which are backed by other cryptocurrencies that are stored in one or
more smart contracts. In this case, the guarantee is that in case of system
collapse, each stablecoin can be redeemed for a basket of tokens whose value
equals one unit of the pegged currency.

  3. 3.

Algorithmic stablecoins, which do not use reserves or collateral and which
attempt to maintain a peg by adjusting the supply of a paired token [44].

A multitude of fiat-backed stablecoins exist, the most prominent (as of June
2023) being Tether (USDT), USD Coin (USDC), and Binance USD (BUSD). The
largest crypto-backed stablecoin is the Dai stablecoin (DAI), which is
maintained by the MakerDAO foundation and which we discuss in more detail in
Section 2.2. During our observation period (as discussed in Section 5), most
fiat- and crypto-backed stablecoins did an overall sound job in maintaining
their peg with the US dollar: the observed price ranges of DAI, USDT, USDC,
and BUSD were [0.9921, 1.0062], [0.9834, 1.0005], [0.9991, 1.0073] and
[0.9988, 1.0126] respectively. The analysis in [37] suggests that fiat-backed
stablecoins have a trade-off between price stability and risk of system
failure in the sense that better arbitrage improves the former at the cost of
increasing the latter.

Fiat-backed stablecoins introduce a trust assumption, namely on the agents who
handle and store the fiat currency. In Tether, this trust assumption has been
widely questioned – accusations include Tether using fiat collateral to buy
high-risk assets [20] and creating unbacked stablecoins to prop up the price
of bitcoins [25]. Furthermore, algorithmic coins have nothing to underpin them
in case of a death spiral [44, 6], as witnessed by the loss of over 60 billion
USD when the Terra/Luna stablecoin system failed. As such, in the rest of this
paper we will focus on crypto-backed stablecoins such as Dai.

###  2.2 The Dai Stablecoin System (DSS)

In this section, we describe the core features of the existing single-chain
DSS. Although there are documents and code repositories that describe the DSS
in its various stages of evolution, e.g., [38, 39, 40, 44, 3, 10], we focus on
the GitHub code [40] and the description of the multi-collateral DSS [39].

Dai Tokens. In the DSS, Dai tokens are minted by users who deposit
cryptocurrency tokens as collateral. In the first iteration of the Dai
stablecoin (the single-collateral Dai or “Sai”), only ETH tokens could be
deposited for this purpose. The procedure for a user, Alice, who wants to mint
new Sai tokens is as follows. First, Alice must send a transaction to a Dai
vault to create a Collateralized Debt Position (CDP) [38]. Next, Alice must
send ETH tokens as collateral to the contract to fund the CDP. If the CDP is
funded, then Alice can use it to create Dai stablecoins and withdraw them from
the CDP to her wallet, incurring debt. At any later time, she can send Dai
tokens back to the CDP to repay her debt. The above can be generalized to a
multi-collateral (but single-chain) DSS by associating each CDP with a token
type. Debt increases exponentially over time, and the rate at which it
increases is a system parameter called the stability fee.

Liquidations. At all times, Dai CDPs must be overcollateralized, i.e., the
ratio of the total value of the Alice’s collateral to her debt must exceed
some threshold called the liquidation ratio [3, 38]. By default, the
liquidation ratio in Dai is set to $1.5$ – i.e., Alice can withdraw Dai
stablecoins worth at most $\frac{2}{3}$ of the total value of the collateral
in their CDP [44]. Similarly, Alice can return Dai and withdraw collateral
from her CDP as long as the above condition holds. If a CDP has no associated
debt, then it can be closed and all remaining collateral can be withdrawn. If,
at any time, a CDP’s ratio of its collateral value to its debt is
insufficient, then Alice’s CDP is underwater and can be liquidated. CDPs can
go underwater either because the value of the collateral has dropped due to
price fluctuations, or because the stability fee has caused the debt to become
too high. To avoid liquidation, Alice must either deposit additional
collateral, or raise Dai to clear the position when it is at risk – if this
fails, a collateral auction can be started by other users. During a collateral
auction, other users can bid to buy (portions of) Alice’s collateral using Dai
stablecoins. Once enough Dai has been raised to repay the CDP’s total debt,
the remaining collateral (if any) is sent back to Alice, minus a penalty.

Price Feeds. To determine the value of deposited collateral, MakerDAO uses
information from price feeds supplied by oracles [35]. The number of price
feeds used by the DSS has increased from 14 between 2017 and November 2019
[26] to 20 currently [43]. Smart contracts that maintain CDPs – vaults –
periodically update token prices by setting each price equal to the median of
a set of recent prices for the associated token.

Dai Savings Rate. Due to the stability fee, the total amount of debt in the
protocol may grow to exceed the total number of stablecoins in circulation.
For example, if Alice’s debt of 100 Dai has grown to 105 Dai, then clearing
her debt and closing the CDP would (in principle) leave 5 Dai in the vault.
These surplus Dai are part of the Dai Savings Rate (DSR) mechanism, which
allows users who deposit stablecoins in a DSR contract to periodically
withdraw surplus Dai tokens from associated vaults. The DSR helps MakerDAO to
keep the value of Dai soft-pegged to the dollar by reducing or decreasing the
interest rate: if Dai becomes less valuable than the dollar, then the interest
rate is increased to incentivize users to buy Dai to deposit in the DSR
contract (and decreased for higher Dai values).

Governance. All major decisions about the functioning of the protocol are
taken by users who hold MKR, which is MakerDAO’s governance token. Such
decisions include 1) verifying and adding smart contracts that implement any
of the functionalities above, 2) changing the Dai savings rate, and 3)
occasionally changing other system-level parameters. The following are the
main system-level parameters (see page 15 of [39]):  1. the debt ceiling for
each token type, i.e., the maximum amount of total debt that can be created
using a given collateral type,  2. the stability fee,  3. the liquidation
ratio,  4. the liquidation penalty,  5. the duration of collateral auctions,
6. the duration of auction bids, and  7. the minimum auction step size (which
prevents bids that are only marginally above the previous bid, which would
waste transaction fees).

Out-of-Scope Concepts. Some of the concepts in the DSS are beyond the scope of
this paper. In particular, these are 1) debt auctions, which occur when a
collateral auction fails to raise enough Dai to cover the CDP’s debt, 2)
surplus auctions, which occur when the amount of Dai left in vaults due to
auctions and stability fees exceeds some threshold, and 3) (emergency)
shutdowns, which can be triggered after a catastrophic event (e.g., system
failure) and during which the total remaining collateral is distributed to Dai
holders.

###  2.3 Existing Cross-Chain Approaches

Cross-chain deals [27] provide a modeling framework to describe sequences of
cross-chain token transfers. A cross-chain deal consists of five phases:
clearing, escrow, transfer, validation, and commitment. The goal of cross-
chain deals is to guarantee atomicity, i.e., that either all transfers occur
or none do. In [27], two frameworks for cross-chain deals are proven to
satisfy technical safety (all honest users end up with an acceptable payoff)
and liveness (no assets are escrowed forever, and if all users are honest then
all transfers eventually happen):  1. hashed time lock contracts,  2.
dedicated blockchains for commit messages . In cross-chain deals, the cost of
a participant abandoning the protocol before completion (sore-loser attacks
[56]) can be made explicit – this form of misbehavior can be disincentivized
through a premium [18] paid by the parties that abandon the protocol before
termination.

Cosmos [7] and Polkadot [33] are blockchain platforms that were specifically
developed with blockchain interoperability in mind, but which do not trivially
interoperate with existing blockchains outside their ecosystems. Furthermore,
Xclaim [58] and zkBridge [54] claim to provide secure cross-chain transfers,
but have limitations when transferring to/from smaller blockchain platforms as
discussed in the introduction.

##  3 System Model

###  3.1 Entities

Our system model has the following types of entities. In the following, we use
the notation $[n]$ for $\\{1,\ldots,n\\}$. A list of symbols can be found in
Table 4 in Appendix A.

  * •

Token: a type of cryptocurrency or an NFT (although typically the former due
to the better availability of price information for cryptocurrencies). We
denote the number of different tokens in the system by $M\geq 2$.

  * •

Governance Token: this is a type of cryptocurrency that gives holders the
right to vote on decisions that affect the functioning of the crypto-backed
stablecoin. The governance token cannot be used as collateral for the
stablecoin.

  * •

Blockchain (or chain): an immutable, distributed ledger that tracks the
ownership of its tokens. We assume that each chain either supports smart
contracts or that a wrapped version of its native tokens exist on a chain that
does (e.g., WBTC [53]). We denote the number of supported chains by $B\geq 2$,
and the chain of token $m\in[M]$ by $b_{m}\in[B]$.

  * •

Consensus Node: is responsible for maintaining the blockchain, e.g., through
the creation and/or validation of new blocks. The nature of the consensus
nodes depends on the blockchain’s consensus protocol – examples include
variations of proof-of-work, proof-of-stake, or Byzantine Fault Tolerance
(BFT) protocols. Each consensus node has some amount of consensus power –
e.g., processing power in proof-of-work, staked tokens in proof-of-stake, or a
private key in a BFT protocol.

  * •

User: owns blockchain tokens and seeks to exchange them for tokens on another
chain. We denote the number of users in our system by $U\geq 1$.

  * •

Smart contract: a software program on a blockchain that may hold tokens which
can be sent to other contracts or wallets depending on the program’s internal
logic.

  * •

Vault: a smart contract or address that holds tokens as collateral, and
to/from which tokens can be sent/received leading to the possible
creation/destruction of stablecoins managed by another smart contract.

  * •

Price Oracle: a type of user who provides price information to the system
[35], e.g., Chainlink [5]. We denote the number of price oracles in our system
by $O\geq 1$. Each oracle $o\in[O]$ can provide price information for any
selection of tokens. Let $p_{m\,o\,t}$ be the price of token $m\in[M]$
reported by oracle $o\in[O]$ at time $t\geq 0$. A price feed is a sequence of
prices for a given token $m$ reported by an oracle $o$.

###  3.2 Token Price Model

In our model, token prices are represented in terms of their exchange rate
with a non-volatile base asset, e.g., the US dollar (the numéraire). We denote
the base price of token $m\in[M]$ at time $t>0$ given by $p_{m\,t}$, and the
initial base price of token $m$ by $p_{m\,0}$. (Here, $t=0$ represents an
arbitrary start point of time.) Given a batch of $k\geq 0$ tokens of type $m$,
the value of this batch at time $t$ is given by $kp_{m\,t}$. We assume that
the price of token $m$ at time $t$ returned by an honest price oracle
$o\in[O]$ equals $p_{m\,o\,t}\triangleq p_{m\,t}+\Delta_{m\,o}$, where
$\Delta_{m\,o}$ is a random variable with a normal/Gaussian distribution [47]
with mean $\mu_{m\,o}\in\mathbb{R}$ and variance $\sigma^{2}_{m\,o}>0$. This
assumption is motivated by the common assumption that measurement errors have
a normal distribution, e.g., in linear regression [16].

To model the evolution of token prices over time, we use Geometric Brownian
Motion (GBM). This is a common choice in the financial literature on asset
prices [47] and related work on stablecoins, e.g., by Salehi et al. [48],
particularly due to the GBM’s role in the Black-Scholes formula for option
prices. A stochastic process $S_{t}$ that follows GBM is defined using a
stochastic differential equation:

$dS_{t}=\mu S_{t}dt+\sigma S_{t}dW_{t},$ (1)

where $\mu$ determines the drift of $S_{t}$ (i.e., its expected change per
unit of time), $\sigma$ represents the volatility of $S_{t}$ (i.e., the
variance of the change), and $W_{t}$ is the Wiener process that represents
standard Brownian motion [47]. In this model, each token price process
$p_{m\,t}$, $t\geq 0$, can be represented using a process defined as in
Equation 1. Essentially, this means that the logarithm of the relative
difference of token prices, $\log\left(p_{m\,t+t^{\prime}}/p_{m\,t}\right)$,
is normally distributed for all $t^{\prime}>0$ with mean and variance
dependent on $t^{\prime}$. Unlike [48], we consider a setting with multiple
assets; i.e., we have a stochastic process $S_{m\,t}$ for each token $m$ with
its own mean $\mu_{m}$ and variance $\sigma^{2}_{m}$. In this setting, we must
also consider the covariance between the token prices [47], as cryptocurrency
prices are often highly correlated – we will discuss this in more detail in
Section 5. More details about how the standard GBM can be used to simulate
asset prices can be found in Appendix B.

The standard GBM as decribed above is based on the normal distribution, i.e.,
$\log(S_{t+t^{\prime}}/S_{t})$ has a normal distribution. However, it is known
from the academic literature that the probability distribution of stock price
fluctuations is usually more heavy-tailed and that Student’s $t$-distribution
is often a better fit [29, 34]. This is also visible in the data for price
changes in our dataset – see Figure 5 in Appendix C. As such, we will focus on
the $t$-distribution in our analysis. Although the $t$-distribution does not
allow for an analytical solution for the asset price change after each
individual time slot (e.g., as per (5) in Appendix B), we can use Monte Carlo
simulation to analyze its behavior, as we discuss in more detail in Section 5.

###  3.3 DSS Execution Model

Let $\mathcal{J}_{t}$ denote the set of all CDPs at time $t$, and $c_{j\,t}$
the total number of collateral tokens held in CDP $j\in\mathcal{J}_{t}$ at
time $t$. Let $D_{j\,t}$ be the outstanding debt resulting from Dai
withdrawals/deposits from/to CDP $j\in\mathcal{J}_{t}$. Each CDP is associated
with a specific token type – let $y_{j}$ be the token type of CDP $j$. Debt is
subject to fees, i.e., $D_{j\,t+1}=(D_{j\,t})^{1+\delta}$, where $\delta$
represents the stability fee. We denote the number of stablecoins held by user
$u\in[U]$ at time $t$ by $h_{u\,t}$. We note that, in principle,
$\sum_{u\in[U]}h_{u}\leq\sum_{j\in\mathcal{J}}D_{j\,t}$, as stablecoins are
created and transferred to a user account either through withdrawal from a CDP
(in which case the created stablecoins and debt are equal) or from a vault
through the Dai savings rate (in which case the created stablecoins cannot
exceed the excess debt). However, we will consider attacks in Section 3.4 that
can cause this assumption to be violated.

We formalize the liquidation criterion as follows: for each CDP
$j\in\mathcal{J}_{t}$ and $t\geq 0$, it must hold that
$p_{y_{j}\,t}c_{j\,t}/y_{j\,t}>\gamma,$ where $\gamma$ is the liquidation
ratio – if this condition does not hold, then CDP $j$ can be liquidated
through a collateral auction. We assume that under standard conditions (i.e.,
the absence of an attack or sudden price collapse), collateral auctions are
concluded successfully, i.e., a sufficient amount of stablecoins is raised to
close the position. No user can create debt if the result would violate the
liquidation criterion. We also note that price fluctuations do not affect the
liquidation criterion, nor does the Dai savings rate as the proportional
effect on all CDP debts is the same.

We denote the debt ceiling for each token type $m\in[M]$ by a fraction
$\zeta_{m}\in[0,1]$, i.e., the total debt in CDPs of type $m$ relative to the
system’s total debt cannot exceed $\zeta_{m}$. (Debt ceilings are specified in
absolute terms in DSS contracts, but we assume that the difference is
negligible for short periods, e.g., for escrow.) The debt ceilings are used to
enforce $\sum_{\begin{subarray}{c}j\in\mathcal{J}_{t}\\\
y_{j}=m\end{subarray}}D_{j\,t}<\zeta_{m}\sum_{j\in\mathcal{J}_{t}}D_{j\,t}$
for all $m\in[M]$. Let $D_{t}^{*}=\sum_{j\in\mathcal{J}_{t}}D_{j\,t}$ and
$C^{*}_{t}=\sum_{j\in\mathcal{J}_{t}}p_{y_{j}\,t}c_{j\,t}$ denote the total
debt and the total collateral value across the system at time $t$,
respectively.

###  3.4 Threat Model

We make the following assumptions about the system entities. We assume that a
majority of the governance token holders are honest. For each underlying
blockchain, we assume that it is either compromised or not. If it is not
compromised, we assume that it guarantees safety and liveness for all of its
transactions. However, both safety and liveness can be violated in a
compromised blockchain – in particular, transactions in which collateral is
sent to/from a CDP can be overturned. For the price oracles, we assume that a
majority is online and honest at all times, but that dishonest oracles can
report arbitrary prices.

###  3.5 System Requirements

The central requirement that we focus on in this paper is the following:

  1. (*)

Full Backing. At any time $t\geq 0$, the ratio of the value of the collateral
tokens to the total number of stablecoins in the system exceeds a safety
threshold $\theta$, i.e.,

$C^{*}_{t}/D^{*}_{t}>\theta.$ (2)

We assume that $\theta>1$, i.e., system failure occurs when the ratio of the
collateral value to the debt gets sufficiently close enough to $1$. The
motivation behind this requirement is as follows: the fundamental guarantee
that underpins crypto-backed stablecoins is that in the event of a system
shutdown, there is enough collateral in the vaults to refund each user who
holds $h$ stablecoins with a basket of tokens whose value equals $h$ units of
the pegged asset. If price fluctuations or an attack would cause this
requirement to be violated, then we can reasonably expect the stablecoin to
lose its peg. This would be detrimental to the user experience as their tokens
held in escrow would depreciate, causing financial losses.

Due to random price fluctuations, we cannot guarantee with absolute certainty
that (2) will hold in all circumstances. However, we use our analysis to show
that for reasonable choices of $\theta$ and the liquidation ratio $\gamma$,
the probability that (2) is violated after a medium-length period (i.e., one
day) is very small for historical data. We do this both for portfolios that
approximate the current state of the DSS (as of late April 2023), and
portfolios that are optimized for minimal risk given a selection of possible
single-chain or cross-chain tokens. In Section 5, we also investigate under
which conditions (2) continues to hold in the event of a black swan event such
as a sudden token price collapse or a 51% attack on a blockchain.

Furthermore, we require the following properties under the threat and token
price model.

  1. 1.

Safety. Users do not lose tokens during stablecoin transfers.

  2. 2.

Liveness. Stablecoin transfers eventually happen.

  3. 3.

Safety of Collateral (informal). The probability that a minority of corrupted
oracles cause a CDP that is not underwater to be inadvertently liquidated is
small.

More formally, for the last property we consider a minority of corrupted price
oracles whose goal is to convince the protocol to accept a price $p^{*}$
instead of a true base price $p$ – safety of collateral then holds if their
probability of success vanishes exponentially as $|p-p^{*}|$ increases (see
also Theorem 5.3 in Section 5.1).

As we will see in Section 5, the former two properties largely follow from
results in the existing scientific literature. The latter is a result that we
prove for the multi-chain setting in Section 5, but which is also applicable
in the single-chain setting.

##  4 CroCoDai: A Cross-Chain Stablecoin

Figure 1: Overview of the single-chain DSS.

In this section, we present CroCoDai, which extends the functionality of the
single-chain DSS (depicted in Figure 1) to a multi-chain setting (depicted in
Figure 2). Our main design goal is to have stablecoin tokens that are backed
by collateral on multiple blockchains, and which can be moved securely and
efficiently between the different chains. This is non-trivial as transactions
between different blockchains are not atomic by default, so our design
incorporates a secure cross-chain protocol. In the following, we will refer to
blockchains that store tokens as coin chains (as per [27]). The communication
between the different blockchains is managed by a relay chain, which may be a
coin chain or a separate chain. The main difference between the single-chain
DSS and CroCoDai is the inclusion of relay nodes – depicted with double
circles in Figure 2 – which is a non-intrusive change as the other DSS
contracts remain unchanged.

In the following, we first discuss in detail which components as discussed in
Section 2.2 remain local to each chain and which require interaction with the
relay chain. We then discuss the essential components of the smart contracts
on the coin chains and the relay chain. Finally, we discuss two ways to
implement the relay chain: one that relies on a quorum of trusted nodes, and
one that uses an existing blockchain. We will present three implementations of
the former in Section 6.

###  4.1 Overview

Local Operations. In CroCoDai, each coin chain keeps track of the balance of
stablecoins in accounts on that chain. The stablecoins can be exchanged
locally between accounts. Furthermore, each coin chain has its own vaults that
allow users to create CDPs using tokens on that blockchain. Since CDPs are
local, liquidation auctions and savings rate mechanisms are also processed
locally. Finally, price feeds are still predominantly local, although price
feeds from the relay chain can add an additional source of price information.

Cross-Chain Operations. The relay chain has four main functions in CroCoDai.
The first is to enable cross-chain transactions. In a cross-chain transaction,
stablecoins are burned on one coin chain and an equivalent number is minted on
another chain. The second function is to add/remove addresses that are
authorized to call security-critical functions such as mint or burn on another
contract – we call such addresses wards as per DSS terminology. Periodically,
smart contracts may be added or deprecated – e.g.,  1. to add support for an
emerging blockchain platform,  2. because a critical bug has been found in an
existing smart contract,  3. because a chain has undergone a hard fork that
interferes with the functioning of the contract, or  4. to implement a more
efficient version of a component (e.g., upgrading the collateral auction
mechanism from Cat.sol to Dog.sol in the DSS).  The third function is to
update the system parameters discussed in Section 2.2. The final function is
to provide an additional source of token price information to vaults through
relay chain oracles – this may particularly benefit smaller blockchains that
lack a mature DeFi ecosystem.

The mechanism for cross-chain transfers is as follows: a node that holds
stablecoins on a coin chain must create a transaction that stores the tokens
to be transferred in escrow – furthermore, the transaction takes as input two
strings to represent the target blockchain and the address on the target
blockchain. This is then added to a list where it awaits commitment. The nodes
in the relay network monitor the coin chains, and once they detect a cross-
chain transfer request, they will sign a commit message. When the coin chain
receives the commit message, it will commit the transaction and burn the
tokens held in escrow. A commit message is also sent to the target blockchain,
upon which it will mint an equivalent number of stablecoins. If the
transaction is aborted for any reason, then the stablecoins in escrow are
returned to the sender.

Figure 2: Overviews of CroCoDai, a multi-chain stablecoin system based on the
DSS. The relays (double circle) are components that are not shared with the
single-chain DSS.

###  4.2 Coin Chain Components

Each coin chain has the following components. Coin: implements a contract that
is similar to Dai.sol in the DSS, and processes transfers of stablecoins
between users on the coin chain. There is only one coin contract per chain.
Vault: implements contracts that are similar to Vat.sol and Join.sol in the
DSS, which allow users to create CDPs and withdraw/deposit collateral and
stablecoins. There can be multiple vaults per chain. Auction: implements
auction contracts that liquidate the collateral of underwater CDPs, with any
appropriate auction logic (not necessarily limited to Cat.sol or Dog.sol) in
the DSS. There can be multiple auction contracts per chain. Savings:
implements a savings rate contracts that are similar to Pot.sol and Jug.sol in
the DSS. Bottom-Level Oracle: implements a price feed using a contract similar
to Spot.sol in the DSS, combined with a Medianizer. Bottom-Level Relay:
validates messages from the relay chain. It processes  1. adding wards to each
of the aforementioned smart contracts,  2. incoming cross-chain transfers,  3.
commitments of outgoing cross-chain transfers, and  4. updates of system
parameters.

###  4.3 Relay Chain Components

The relay chain has the following components. Governance: allows users to
transfer governance tokens. Users who hold governance tokens can vote on
system-level actions such as adding wards, processing cross-chain transfers,
and updating system-level parameters. Top-Level Oracle: The relay chain may
implement system-level price feeds to complement the price feeds on the coin
chains. Top-Level Relay: To process cross-chain transfers, the relay network
must be able to read the state of the coin chains, in particular the list of
cross-chain transfer requests.

###  4.4 Relay Chain Designs

In this section, we discuss two possible implementation designs of the relay
chain. The first relies on a quorum of trusted nodes with known public keys –
each trusted node runs an off-chain (full or light) blockchain client for each
of the underlying chains to check the validity of cross-chain transfers, and
the nodes maintain a distributed ledger for governance decisions. The second
uses an existing blockchain, and uses smart contracts that implement the
consensus logic of the underlying chains on-chain to verify cross-chain
operations.

Off-Chain Blockchain Clients. In this approach, the stablecoin system is
maintained by $n$ relay nodes with known public keys. The relay nodes use
their (light) clients to detect and validate cross-chain transactions, and
generate signatures using their private/public key pair to commit cross-chain
transfers and approve governance decisions. In this setting, the only
functionality of the bottom-chain relay contracts is to verify digital
signatures. If different chains use different built-in signature schemes, or
the same scheme with a different parametrization, then the relay nodes may
need to generate multiple signatures for a single cross-chain transfer (this
is safe if the threat model of Section 3.4 holds when each signature is
generated). We discuss three different implementations of this approach in
Section 6.

To ensure security, we note that it is vital that the relay nodes are
controlled by independent entities: e.g., in the attack against the Ronin
bridge, 5 out of 9 validators were successfully attacked [30], of which 4
belonged to the same entity [36].

On-Chain Consensus Logic. In this approach, the consensus logic of the coin
chains is implemented in the top-level relay contracts, and the consensus
logic of the relay chain is implemented in the bottom-level relay contracts.
Essentially, the functionality of a light client – i.e., validating block
headers and proving the state of a contract using the header – is implemented
inside the smart contracts. This is the approach taken in, e.g., Xclaim [58].
For example, in Bitcoin’s Nakamoto Consensus [45] this means the ability to
compute header hashes and compare them to the proof-of-work difficulty,
whereas in Ethereum’s proof-of-stake it means validating that nodes who
control a sufficient amount of stake have approved a block. Techniques to
increase the efficiency of light clients have been proposed in the literature
for both proof-of-work (e.g., Bitcoin [14]) and proof-of-stake blockchains
(e.g., Algorand [42] and Mina [4]). Another variation of this approach is to
encode the consensus logic of the blockchains in a zero-knowledge proof, e.g.,
using the zkBridge protocol [54]. Finally, the data on the different coin
chains can be integrated using TrustBoost [52].

Although this design avoids a trust assumption on a quorum of relay nodes,
current iterations of such designs have a large computational overhead,
typically requiring several kilobytes of data sent to relay contracts and more
than 10 seconds to generate signatures [42, 54]. As such, we focus on the off-
chain design in Section 6.

##  5 Analysis

In this section, we analyze whether our system satisfies the requirements of
Section 3.5. In Section 5.1, we focus on the technical properties of safety
and liveness, full backing under the threat model, and safety of collateral.
We then focus on full backing under the price fluctuation model: we present
our approach in Section 5.2, and the evaluation using empirical data in
Section 5.3. The proofs of the theorems in this section can be found in
Appendix D.

Our analysis shows that CroCoDai is resilient to serious failures of multiple
coin chains, as long as the over-collateralization of the CDPs, $\gamma$, is
high compared to the total debt ceiling of the affected chains (which we will
denote by $\zeta^{\prime}$). We emphasize that CroCoDai is therefore
fundamentally more resilient than a single-chain stablecoin such as the DSS,
which cannot tolerate the failure of its single coin chain. Our analysis also
shows that a broader selection of collateral tokens leads to a lower
probability of system failure than a single-chain system such as the DSS.
Although the findings of our price analysis strongly depend on the choice of
data, we emphasize that we included a period of notoriously high volatility
(i.e., the FTX collapse) and that the risks would appear smaller if we used a
less volatile period.

###  5.1 Safety Analysis

Technical Safety and Liveness. For local operations, the consensus protocol of
the coin chain on which the local transfer occurs ensures the safety and
liveness of operations on this chain – see, e.g., [22]. This includes local
stablecoin transfers, operations on collateral, auctions, and interest
withdrawals. For cross-chain operations, safety is violated if tokens in a
bottom-level relay are burnt without a corresponding amount being minted on
the receiving chain, and liveness is violated if tokens are held in escrow
forever. However, the relay chain satisfies safety and liveness in our threat
model, i.e., the transfer is eventually committed and coins are burned and
minted on the outgoing and incoming chains, respectively. An alternative way
to reach this conclusion is to view cross-chain transfers in CroCoDai as
simple cross-chain deals [27] with the sender as the only party who votes, and
the relay chain as a certified blockchain – depending on the design (as
discussed in Section 4.4), either $2f+1$ nodes or the smart contracts on the
relay chain sign the commit vote.

To ensure safety and liveness, we emphasize that it is essential that the
relay network is not compromised. A compromised relay network can burn coins
without creating a corresponding amount on the receiving chain, violating user
safety. Likewise, if the relay network is unable to process requests because
more than $f$ relay nodes are offline or malicious, then the system does not
satisfy liveness as cross-chain transfer requests may never happen. We also
note that if the relay network is compromised, then full backing can be
violated by creating an incoming transfer request without a matching outgoing
transfer request, thus creating tokens without collateral. Although the
security of the relay chain is therefore essential to CroCoDai, we investigate
the impact of compromised coin chains on full backing below.

Sudden Crash of Tokens. Occasionally, the price of a cryptocurrency token may
suddenly collapse, e.g., because of the discovery of a serious bug in one of
its smart contracts, or because of off-chain events such as a bankruptcy or a
legal inquiry into the organization responsible for its maintenance. As an
example: the bankruptcy of Celsius caused the value of the CEL token to
collapse, whereas the inquiry into FTX did the same for the FTT token and
Serum (SRM). In this case, the collateral auctions are likely to fail to
generate enough revenue and the system’s over-collateralization is under
threat. In the following, we consider a worst-case scenario: the price of some
tokens falling to zero within a single time slot, i.e., between a given time
slot $t^{\prime}$ and time slot $t^{\prime\prime}$ – for simplicity, we assume
$t^{\prime}=0$ and $t^{\prime\prime}=1$. We show that CroCoDai remains fully
backed at time $t^{\prime\prime}$ if it is sufficiently over-collateralized
and if the total debt created using tokens on the affected chains is limited.

Formally, let $M^{\prime}\subset[M]$ denote the set of affected tokens, and
$\zeta^{\prime}=\sum_{m\in M^{\prime}}\zeta_{m}$ the total debt ceiling of
these tokens. Let

$C^{-}_{t}=\sum_{\begin{subarray}{c}j\in\mathcal{J}_{t}\\\ y_{j}\in
M^{\prime}\end{subarray}}p_{y_{j}\,t}c_{j\,t},\;\;\;\;\;C^{+}_{t}=\sum_{\begin{subarray}{c}j\in\mathcal{J}_{t}\\\
y_{j}\notin M^{\prime}\end{subarray}}p_{y_{j}\,t}c_{j\,t}$

i.e., $C^{-}_{t}$ represents the total value of the collateral tokens affected
by the collapse, and $C^{+}_{t}$ the total value of the unaffected tokens.
Similarly, let

$D^{-}_{t}=\sum_{\begin{subarray}{c}j\in\mathcal{J}_{t}\\\ y_{j}\in
M^{\prime}\end{subarray}}D_{j\,t},\;\;\;\;\;D^{+}_{t}=\sum_{\begin{subarray}{c}j\in\mathcal{J}_{t}\\\
y_{j}\notin M^{\prime}\end{subarray}}D_{j\,t}$

so that $D^{-}_{t}$ represents the debt associated with affected CDPs and
$D^{+}_{t}$ the debt of unaffected CDPs at time $t$. We consider an attack
that occurs at time $1$, so that $C^{-}_{1}=0$, $C^{+}_{1}=C^{+}_{0}$,
$D^{-}_{1}=D^{-}_{0}$, and $D^{+}_{1}=D^{+}_{0}$. We can then prove the
following theorem (see Appendix D):

######  Theorem 5.1.

Let $C^{-}_{1}=0$, $C^{+}_{1}=C^{+}_{0}$, $D^{-}_{1}=D^{-}_{0}$, and
$D^{+}_{1}=D^{+}_{0}$. If $p_{y_{j}\,0}c_{j\,0}/y_{j\,0}>\gamma$ for all
$j\in\mathcal{J}_{0}$, then $C^{*}_{1}/D^{*}_{1}>\gamma(1-\zeta^{\prime})$,
i.e., full backing holds at time $t=1$ if $\theta<\gamma(1-\zeta^{\prime})$.

Individual Compromised Coin Chain. If a majority of consensus power on a coin
chain $b^{\prime}\in[B]$ is compromised then the consensus nodes could perform
a 51% attack in the following way: send some amount of stablecoins to another
chain, wait for the transaction to be committed by the relay network, then
fork the compromised coin chain and undo the outgoing transfer request and the
burning of the blockchain tokens. Similarly, they could undo the funding of a
CDP. As a consequence, stablecoins are created on another chain without
backing collateral. In the worst case, this attack would be performed
simultaneously on all of the token types supported by the compromised chain
$b^{\prime}$. Let $M^{\prime}=\\{m\in[M]:b_{m}=b^{\prime}\\}$ be the set of
affected tokens. We again consider a worst-case attack that has been completed
at $t=1$. Let $h^{\prime}$ be the total amount of stablecoins created in the
attack, so that $D^{-}_{1}=D^{-}_{0}+h^{\prime}.$ We can then prove the
following theorem (see Appendix D):

######  Theorem 5.2.

Let $C^{-}_{1}=C^{-}_{0}$, $C^{+}_{1}=C^{+}_{0}$,
$D^{-}_{1}=D^{-}_{0}+h^{\prime}$, and $D^{+}_{1}=D^{+}_{0}$. If
$p_{y_{j}\,0}c_{j\,0}/y_{j\,0}>\gamma$ for all $j\in\mathcal{J}_{0}$, then
$C^{*}_{1}/D^{*}_{1}>\gamma(1-\zeta^{\prime})$, i.e., full backing holds at
$t=1$ if $\theta<\gamma(1-\zeta^{\prime})$.

Compromised Price Feeds. Finally, we consider an attack in which a dishonest
minority of price oracles tries to corrupt the price maintained by a vault.
This could cause CDPs to be liquidated even if they are not underwater, thus
violating safety of collateral.

Let $p$ be the base price for token $m\in[M]$ at time $t\geq 0$ (we omit $m$
and $t$ from the notation in this section as they are not relevant to the
analysis). Let $p_{o}$ be the price returned by oracle $o\in[O]$, so that
$p_{o}=p+\Delta_{o}$ as discussed in Section 3.2. In the following, we assume
some subset $O^{\prime}\subset[O]$ is controlled by malicious parties who aim
to convince a vault in CroCoDai that of a price $p^{\prime}$ that is different
from the base price $p$. Let $p^{*}$ be the actual median price among all
price feeds, including those that have been distorted. We can then prove the
following theorem (see Appendix D):

######  Theorem 5.3.

If $|O^{\prime}|<M/2$, then the probability that the difference between the
base price $p$ and the median price $p^{*}$ exceeds a constant $c>0$ vanishes
exponentially as $c$ increases.

###  5.2 Financial Analysis: Approach

In this section, we investigate the probability that CroCoDai remains fully
backed even in the presence of standard price fluctuations. In particular, we
will estimate this probability for several choices of supported collateral
tokens: 1) a single token type, 2) tokens that exist on the Ethereum
blockchain, and 3) tokens that exist on a variety of independent blockchains.
The second probability corresponds to the safety of the single-chain DSS,
whereas the third option corresponds to the safety of CroCoDai. The purpose of
this section is to demonstrate that the third option has considerably lower
risk than the second, using multi-chain collateral baskets that are similar to
those observed for the DSS in practice (see Table 8 in Appendix E). We discuss
our approach in Section 5.2 and present our empirical results in Section 5.3.

As is common in financial analysis, we will refer to a basket of collateral
tokens as a portfolio, and to the relative increase in value of a token type
over one time slot as a return. We will also discuss a method based on convex
optimization that allows protocol engineers to set the system parameters such
that the risk of system failure is minimized.

Problem Statement. Let $\mathcal{J}_{m\,t}=\\{j\in\mathcal{J}_{m}:y_{j}=m\\}$
be the set of CDPs at time $t$ whose token type is $m$, and
$\alpha_{m\,t}=\sum_{j\in\mathcal{J}_{m\,t}}c_{j\,t}$ be the total number of
collateral tokens of type $m$ at time $t$. In the following, we assume for
simplicity that $\alpha_{m\,t}\equiv\alpha_{m}$, i.e., that the composition of
the portfolio does not change during the observation period. This is a
reasonable assumption as interactions with CDPs do not occur frequently. In
our model, failure of the stablecoin system occurs if, for any $t$ we have

$\sum_{m\in[M]}\alpha_{m}p_{m\,t}\leq\theta D^{*},$ (3)

where $\theta$ is the required over-collateralization and $D^{*}$ is the total
amount of stablecoin issued at time $t=0$. We introduce a new variable
$\gamma^{\prime}$ that denotes the initial over-collateralization calculated
as $\gamma^{\prime}=\frac{\sum_{m\in[M]}\alpha_{m}p_{m\,t}}{D^{*}}.$ Based on
that, we can reformulate the failure condition as:
$\frac{\sum_{m\in[M]}\alpha_{m}p_{m\,t}}{\sum_{m\in[M]}\alpha_{m}p_{m\,0}}\leq\frac{\gamma^{\prime}}{\theta}.$
As one would expect, failure does not depend on the absolute size of the
portfolio, but on its relative composition. Our first goal is then to estimate
the probability of failure for a choice of $\alpha_{1},\ldots,\alpha_{M}$,
$\gamma^{\prime}$, and $\theta$.

In our simulation, we represent the portfolio as relative proportions of
different assets. We define a vector $\vec{v}$ that denotes the value of
individual assets in the portfolio as
$\textbf{v}=(v_{1},v_{2},\ldots,v_{M})^{T},$ where $v_{i}$ is value of asset
$i$. Similarly, we define a vector of random variables for log returns of
individual assets $\textbf{X}=(X_{1},X_{2},\ldots,X_{M})^{\intercal},$ where
$X_{m}$ is the random variable for log returns of asset $m$. We then simulate
the price of each asset as an individual GBM with Student’s $t$-distribution
for the return after each time slot, as discussed in Section 3.2. To
accurately simulate price fluctuations, we must consider the correlation
between the prices – to do so, we use Cholesky decomposition to compute a
matrix $\mathbf{L}$ that satisfies
$\textnormal{Cov}(\mathbf{X})=\mathbf{L}\mathbf{L}^{T}$. A matrix of random
samples $\mathbf{R}$ can then be generated as $\mathbf{R}=\mathbf{LT}$, where
the matrix $\mathbf{T}$ contains a $t$-distributed random sample for each
asset type and simulated time slot. In Appendix B we discuss alternative
simulation methods based purely on historical data and the standard GBM.

Choosing the System Parameters. In CroCoDai, the values $\alpha_{m}$,
$m\in[M]$, which represent the fraction of each asset $m$ in the total
portfolio, are not set by the protocol engineers – instead, they emerge
naturally as users create CDPs and withdraw stablecoins using the currencies
of their choosing. However, protocol engineers can influence the range of
potential portfolios by adjusting the debt ceiling $\zeta_{m}$ for each token
$m$.

When optimizing the portfolio of cryptocurrencies for a stablecoin, the
protocol engineers’ main goal should be to minimize the portfolio’s
volatility. In principle, a positive mean drift in the returns is beneficial,
as that would imply that the over-collateralization grows naturally over time.
However, the mean return over our observation period was close to zero, and
for risk analysis, with cross-chain commerce as our driving use case, we focus
mainly on short-term price changes. In this context, the mean return is not a
meaningful optimization criterion, so we focus on minimizing the volatility
instead.

Assuming a normal or $t$-distribution of returns, we can calculate the
covariance matrix $\text{Cov}(\mathbf{X})$ as discussed previously. We can
then use convex optimization to find a portfolio that minimizes total
volatility. We can write this optimization problem as

$\begin{array}[]{rcl}\displaystyle\min_{\textbf{v}}&\textbf{v}^{T}\text{Cov}(\mathbf{X})\textbf{v},&\\\\[5.69046pt]
\text{s.t.}&\displaystyle\sum_{i=1}^{M}v_{i}=1,&\\\\[5.69046pt] &\displaystyle
0\leq v_{i}\leq\lambda_{i}&\forall i\in[M],\end{array}$ (4)

where we consider $M$ different cryptocurrencies and $v_{i}$ denotes the
fraction of the portfolio invested in asset $i\in[M]$. The bounds
$0\leq\lambda_{i}\leq 1$ enforce maximum contributions for the different
individual asset types, to avoid portfolios with a small number of low-
volatility tokens (such portfolios would be vulnerable to black-swan events as
discussed in Section 5.1). Given a solution $v_{1},\ldots,v_{M}$ to (4), we
can enforce the optimal portfolio up to some margin by setting
$\zeta_{m}=(1+\beta)v_{m}$ where $\beta>0$ is the flexibility margin: a higher
margin encourages more users to create CDPs, but also allows for larger
deviations from the optimal portfolio.

###  5.3 Financial Analysis: Evaluation

In this section, we analyze the risk of system failure in both single-chain
and multi-chain settings using the approach described above. We first describe
the data for our model, then the portfolio compositions, and finally the
results of our analysis.

Description of Data. We have collected data using the CoinMarketCap API over
six different periods that span a total of 1264 hours of data, separated into
5-minute slots. The duration of these periods can be found in Table 9 in
Appendix F. The final period includes the collapse of the FTX exchange on
November 11, 2022. In each time slot, we collected price information of 100
tokens, namely those that were the 100 largest in terms of market
capitalization during the first time slot. A complete list of the included
token symbols, and the observed correlation between them, can be found in
Figure 6 in Appendix F.

DSS-Based Portfolios. For our analysis, we have considered single-asset
portfolios consisting of Bitcoin and several of the highest-value smart
contract platforms, namely: Ethereum, Cardano, Solana, Polkadot, Tron,
Avalanche, Algorand, and EOS – their cryptocurrency symbols are: BTC, ETH,
ADA, SOL, DOT, TRX, AVAX, ALGO, and EOS. The results are displayed in Table 1
(single-asset). We use the following multi-asset portfolios:

  1. 1.

D-All, which approximates the collateral portfolio of the DSS as of early 2023
(see Table 8 in Appendix E). (We replace GUSD, which was not in our dataset,
with another fiat-backed stablecoin (USDT), and Maker’s real-world assets with
gold-backed PAXG.)

  2. 2.

D-ERC, which approximates the DSS portfolio after removing all fiat-backed
assets.

  3. 3.

D-Mix1 and D-Mix2, which use the same tokens as D-ERC but which increase the
proportion of the minor ERC-20 tokens.

  4. 4.

C-Mix1 and C-Mix2, which replace the ERC-20 tokens in D-Mix1 and D-Max2 with
tokens from other popular blockchain platforms: ADA, DOT, TRX, and SOL.

The exact compositions of these portfolios can be found in Table 10 in
Appendix G.

In our experiments, the expected over-collateralization to avert system
failure is $\theta=1.1$. For each table entry, we calculate the probability of
failure within 1 day, i.e., 288 5-minute time slots, using 100 000 simulation
runs. In each run, we simulate the evolution of token prices by randomly
drawing, in each consecutive time slot, the price change for each token type
in the portfolio. We then compute the risk of failure as the fraction of runs
that resulted in failure among the total number of runs. The results are
displayed in Table 1 – Appendix B includes similar tables with different
simulation methods and confidence interval widths.

Table 1: Chance of failure for single asset portfolios and initial over-
collateralization.

single-asset multi-asset $\gamma^{\prime}$ BTC ETH ADA SOL DOT TRX AVAX ALGO
EOS D-All D-ERC D-Mix1 D-Mix2 C-Mix1 C-Mix2 1.2 0.021 0.047 0.078 0.228 0.063
0.018 0.126 0.166 0.097 0.001 0.051 0.040 0.050 0.030 0.029 1.3 0.003 0.008
0.014 0.093 0.012 0.003 0.029 0.051 0.016 0.000 0.007 0.005 0.006 0.003 0.003
1.4 0.001 0.003 0.005 0.059 0.004 0.001 0.009 0.019 0.004 0.000 0.002 0.002
0.002 0.001 0.001 1.5 0.001 0.001 0.002 0.041 0.002 0.001 0.004 0.007 0.002
0.000 0.001 0.001 0.001 0.001 0.001

From Table 1, we observe a considerable difference between the failure
probabilities of the single-token portfolios. The most high-risk portfolio was
Solana (SOL), which was severely affected by the collapse of FTX, since it was
one of FTX’s most prominent backers [11]. Even for an initial
collateralization $\gamma^{\prime}=1.5$, a pure SOL portfolio would have a
failure probability of more than $4\%$ after a day, given the data from our
observation period. In contrast, BTC and TRX were the most stable
cryptocurrencies over this period.

(a)

(b)

Figure 3: Correlation between the different token types.

Furthermore, we observe from Table 1 that the DSS’s approximate portfolio has
a very low probability of failure due to $80\%$ of its collateral being
stablecoins and other pegged assets. In fact, for $\gamma^{\prime}=1.2$, its
observed failure probability (0.001 for D-All) was roughly 40-50 times lower
than for the pure crypto-backed portfolios (0.051, 0.040, and 0.050
respectively for D-Erc, D-Mix1, and D-Mix2). For the pure crypto-backed
portfolios, we find that D-ERC has slightly lower failure probabilities than a
pure ETH portfolio, which can be explained by the higher share of low-
volatility WBTC in the portfolio. Similarly, C-Mix1 and C-Mix2 portfolios have
lower risk than the D-ERC due to the inclusion of more WBTC. We do not observe
much benefit from the inclusion of more different asset types due to the high
correlation between the included tokens. However, when comparing the C-Mix1
and C-Mix2 portfolios we do note that C-Mix2 has a lower failure probability
despite the inclusion of less low-volatility WBTC. The reason is the inclusion
of TRX, which is not only similarly low-risk as WBTC, but which also has a
relatively low correlation with the other asset types – this can be seen in
Figure 3(a). We also note that the relative differences become starker when
$\gamma^{\prime}$ increases – e.g., for $\gamma^{\prime}=1.2$, the risk of
D-Mix1 is roughly a third higher than C-Mix2 (4.0% vs. 2.9%), whereas for
$\gamma^{\prime}=1.3$ the risk is two thirds higher (0.5% vs. 0.3%).

Optimized Portfolios. The portfolios in the previous section approximated the
existing DSS portfolio, which is aligned with the willingness of real-world
users to deposit collateral of the various types. Although we did observe a
slightly lower risk probability for the best multi-chain portfolio (C-Mix2)
than for the best single-chain portfolio (D-Mix1), the underlying fundamental
issue is how they compare if we were to use the convex optimization method
based on (4) to determine low-volatility portfolios.

A first question in understanding this is whether to include stablecoins in
the portfolio. If we use convex optimization across the entire dataset of 100
token types, we obtain the portfolio from Table 12 in Appendix G. With the
exception of BTT (the BitTorrent token), this portfolio only includes USD- or
gold-pegged assets. A crypto-backed stablecoin system that only uses fiat-
backed stablecoins as collateral has trivially low price volatility, yet would
share most of the drawbacks of a fiat-backed stablecoin as discussed in
Section 2 (i.e., higher vulnerability to black swan events that involve off-
chain entities). As such, we will also consider a stablecoin that purely uses
unpegged cryptocurrency assets as collateral. This represents a worst-case
scenario in terms of volatility risk: in practice, an appropriate mixture of
stablecoins and unpegged cryptocurrencies can be chosen. If we restrict the
portfolios to the same tokens as the portfolios of Table 10, we obtain the
optimal portfolios D-Opt and C-Opt of Table 11 (both in Appendix G). We also
include the portfolio A-Opt which may contain any of the Top 100 tokens except
those already pegged to a real-world asset. Since we observe that the optimal
portfolios tend to restrict themselves to a handful of tokens (e.g., only WBTC
and GNO/TRX for D-Opt and C-Opt), we also set a threshold of $\lambda=0.2$ for
D-Opt and C-Opt and $0.1$ for A-Opt to avoid high exposure to events on a
single blockchain.

Table 2: Chance of failure for given portfolio and initial over-
collateralization.

| D-Opt | C-Opt | A-Opt | risk vs. D-Opt
---|---|---|---|---
$\gamma^{\prime}$ | $\lambda=0.2$ | $\lambda=1$ | $\lambda=0.2$ | $\lambda=1$ | $\lambda=0.1$ | $\lambda=0.2$ | $\lambda=1$ | C-Opt | A-Opt
1.2 | 0.03419 | 0.01423 | 0.02103 | 0.00934 | 0.00895 | 0.00624 | 0.00617 | -38.49% | -81.75%
1.3 | 0.00397 | 0.00133 | 0.00232 | 0.00131 | 0.00076 | 0.00055 | 0.00081 | -41.56% | -86.14%
1.4 | 0.00115 | 0.00058 | 0.00087 | 0.00056 | 0.00030 | 0.00020 | 0.00024 | -24.34% | -82.61%
1.5 | 0.00057 | 0.00027 | 0.00037 | 0.00024 | 0.00014 | 0.00008 | 0.00012 | -35.08% | -85.97%

The results of our optimal portfolio simulations are displayed in Table 2. The
final (bold) column displays the decrease in terms of failure risk estimates
for C-Opt and A-Opt versus D-Opt for $\lambda=0.2$. In general, we find that
the optimized portfolios have slightly lower failure probabilities than the
DSS-based ones from the previous section (e.g., for $\gamma^{\prime}=1.1$ and
$\lambda=0.2$, we obtain 0.034 for D-Opt vs. 0.040 for D-Mix1, and 0.021 for
C-Opt vs. 0.029 for C-Mix2). The C-Opt portfolios again outperform D-Opt
portfolios by roughly a third, confirming our expectation that a multi-chain
stablecoin is less vulnerable to price fluctuations than a single-chain one.
Furthermore, we find even lower failure probabilities for A-Opt, although this
portfolio contains many tokens on blockchains that are not as high-use as the
tokens in the other portfolios – e.g., BSV or KLAY vs. BTC and ETH in other
portfolios. Less-used tokens may be more likely to experience black swan
events as there are fewer incentives to scrutinize smart contract code or the
identity of the consensus nodes. In any case, we find that even for pure
crypto-backed portfolios (C-Opt) and sufficient over-collateralization
($\gamma^{\prime}=1.4$, which is similar to $\gamma=1.5$ in the DSS and
$\theta=1.1$) CroCoDai’s estimated system failure (i.e., de-peg) risk after a
day is less than one in a thousand, which may be acceptable for low-to-medium-
value commerce (e.g., a ticket auction).

##  6 Implementation

In this section, we discuss the technical details of three prototype
implementations of our stablecoin system. We compare them in terms of the on-
chain processing cost (gas) and the off-chain computation time. Both are
essential to system performance and thus usability: if the on-chain cost is
too high then each transfer will incur large fees, whereas if the computation
time is too high then there is a large delay for cross-chain transactions. We
focus on the implementation of the relay nodes, because all other components
depicted in Figure 2 (the coin, vault, auction, savings, and oracle contracts)
can be re-used from the DSS without modification – we only add the relay
contracts as wards for the coin contract. As such, we cannot provide a
straightforward comparison with the DSS, as the performance of CroCoDai
contracts is either exactly the same or there is no DSS equivalent. However,
we will discuss the comparison with alternatives from the scientific
literature, e.g., zkBridge.

Each of our three designs uses a quorum of trusted nodes, but has a different
tradeoff in terms of scalability and generality. Each implementation consists
of two smart contracts written in Ethereum’s Solidity language: Relay.sol and
CCTransfer.sol, although only Relay.sol differs between implementations. The
Relay and CCTransfer contracts interact with an ERC-20 compliant contract for
token transfers, Coin.sol, which re-uses the code from the Dai.sol contract in
the DSS [41]. Our experiments were run on a Lenovo IdeaPad with an Intel(R)
Core(TM) i5-1035G1 CPU (1.00GHz) and 8GB RAM (although the gas costs are
machine-independent). The scripts that performed off-chain computations were
written in Python and used the Web3 package for most cryptographic operations,
while the underlying blockchain was simulated using Truffle’s Ganache tool
[21]. For communication about cross-chain transfers, the relay nodes can use a
private blockchain, e.g., a private Go-Ethereum blockchain, or a bespoke
cross-chain communication framework such as [46].

###  6.1 Smart Contracts

CCTransfer. This contract stores cross-chain transfer requests as a hashmap of
Request instances, which are implemented as a Solidity struct. Each CCTransfer
contract is linked to a specific Coin and Relay contract pair, and must be
made a Coin contract ward to allow it to mint or burn stablecoins upon the
commitment of cross-chain transfers.

Relay. In the first design, a hashmap of relay node addresses in Solidity’s
address format is stored in the contract. For each cross-chain transfer, at
least $2f+1$ relay nodes must call the Relay node’s approve function using
their stored address. This design exploits the EVM’s built-in signature
verification, and generalizes trivially to other blockchain platforms.
However, the downside is that each relay node must have an account and spend
gas on each supported blockchain for every cross-chain transfer. In the second
design, a hashmap of relay node public keys is stored in the contract, and a
batch of $2f+1$ 32-byte signatures is passed in the form of a byte array as a
function parameter for each transaction. These signatures are then validated
one by one by repeatedly calling the built-in ecrecover function. Although
this is not as generic as the previous approach (e.g., each chain with its
different cryptographic primitives would require its own off-chain signature
generation script) it is more efficient and does not require each individual
relay node to maintain an account. In the third design, we use a $t$-out-
of-$n$ threshold signature scheme (where in our case $t=2f+1$) to produce a
single 32-byte signature for the relay node quorum, e.g., using the procedure
of [23]. The resulting signature is a standard ECDSA signature that can be
verified using ecrecover. For our implementation we have used the multi-party
ECDSA library by ZenGo X [59].

Table 3: Performance comparison of the three implementation designs.

| gas cost |  $T_{\textnormal{proc}}$ (s)
---|---|---
design | $n=4$ | $n=10$ | $n=16$ | $n=4$ | $n=10$ | $n=16$
(1) $n$/$n$ | 171791 | 511473 | 977350 | — | — | —
(2) $n$/$1$ | 214373 | 430690 | 647118 | 0.025 | 0.071 | 0.091
(3) $1$/$1$ | 53112 | 53117 | 53110 | 1.101 | 7.780 | 34.513

###  6.2 Experimental Results

Table 3 compares the different designs in terms of the gas cost and the
processing time at the relay nodes, $T_{\textnormal{proc}}$. We observe that
the first design is the worst in terms of performance, which is the cost of
its generality and ease of implementation. The second design is more efficient
in terms of gas cost for large relay node quora, and only has little
processing time at the relay nodes. The third design is the most efficient in
terms of gas cost, but at the cost of considerable processing time at the
relay nodes, especially for large quora. For the first ($n/n$) design, we
could not distinguish $T_{\textnormal{proc}}$ from the transaction processing
time in Ganache as both happen in a single step in Python’s Web3 package –
however, these are assumed to be similar to signing in the $n/1$ design, and
are indicated with ‘—’ in the table.

By comparison, zkBridge [54] reports a gas cost of $\approx$230k gas for on-
chain verification, but with a processing cost of $\approx$18 seconds to
generate a proof with 32 high-end Amazon Web Services machines (c5.24xlarge).
This lower performance is to be expected, as the additional complexity of
zkBridge removes the need for a trusted quorum of relay nodes.

##  7 Conclusions and Future Work

In this work we have presented CroCoDai, a stablecoin system for cross-chain
commerce. CroCoDai facilitates cross-chain transfers by design, and is more
resilient than a single-chain system to black swan events and price
fluctuations. Our empirical analysis shows that with sufficient
overcollateralization, the probability of system failure can be made small
even under a model whose price data includes the highly volatile period after
the collapse of the FTX exchange. We have presented three prototype
implementations that rely on a quorum of relay nodes for cross-chain transfers
and governance decisions.

For future work, a first interesting direction is to implement a version of
CroCoDai that performs all relay operations on-chain, as per the second design
of Section 4.4. Promising directions to achieve such a design would be to use
trustless bridges as proposed in zkBridge, or succinct proofs of state such as
those proposed for Algorand or Mina. This would remove the need for a trusted
quorum of relay nodes, while maintaining CroCoDai’s advantages over the
single-chain DSS, i.e., higher resilience to black swan events and price
fluctuations. A second interesting direction is to further investigate
alternative collateral liquidation mechanisms – for example, Salehi et al.
[48] propose to mitigate liquidations from the DSS or remove them completely.
For example, collateral of the same token type in a vault could be pooled
together and liquidated only when the entire pool is underwater – however,
this would remove an incentive from users to overcollateralize. A third and
final interesting research direction is system recovery after a 51% attack on
a coin chain. As we discussed in Section 5, such an attack could create
stablecoins without matching collateral on a different chain. This is similar
to the situation after a failed collateral auction in the DSS, so it may be
possible to resolve it similarly – i.e., with the governance token holders
absorbing the losses.

## References

  * [1] Mohamed Al Guindy.  Cryptocurrency price volatility and investor attention.  International Review of Economics & Finance, 76:556–570, 2021\.
  * [2] Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia.  A survey on blockchain interoperability: Past, present, and future trends.  ACM Computing Surveys (CSUR), 2021.
  * [3] Shreyas Bhat, Ayten Kahya, Rohit Kumar, and Bhaskar Krishnamachari.  Simulating the MakerDAO stablecoin.  In 2021 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 1–2. IEEE, 2021.
  * [4] Joseph Bonneau, Izaak Meckler, Vanishree Rao, and Evan Shapiro.  Mina: Decentralized cryptocurrency at scale.  https://docs.minaprotocol.com/assets/technicalWhitepaper.pdf, 2020\.
  * [5] Lorenz Breidenbach, Christian Cachin, Benedict Chan, Alex Coventry, Steve Ellis, Ari Juels, Farinaz Koushanfar, Andrew Miller, Brendan Magauran, Daniel Moroz, et al.  Chainlink 2.0: Next steps in the evolution of decentralized oracle networks.  Chainlink Labs, 1, 2021.
  * [6] Antonio Briola, David Vidal-Tomás, Yuanrong Wang, and Tomaso Aste.  Anatomy of a stablecoin’s failure: The Terra-Luna case.  Finance Research Letters, 51:103358, 2023.
  * [7] Jeff Burdges, Alfonso Cevallos, Peter Czaban, Rob Habermeier, Syed Hosseini, Fabio Lama, Handan Kilinc Alper, Ximin Luo, Fatemeh Shirazi, Alistair Stewart, and Gavin Wood.  Overview of Polkadot and its design considerations.  arXiv 2005.13456, 2020.
  * [8] Vitalik Buterin.  A next-generation smart contract and decentralized application platform, 2014.
  * [9] Yizhou Cao, Min Dai, Steven Kou, Lewei Li, and Chen Yang.  Designing stable coins.  Available at SSRN 3856569, 2021.
  * [10] Jason Chen, Kathy Fogel, and Kose John.  Understanding the Maker protocol.  arXiv preprint arXiv:2210.16899, 2022.
  * [11] Morgan Chittum.  Sam Bankman-Fried championed Solana. Now, execs are trying to break the connection as FTX’s implosion weighs on the blockchain’s reputation.  https://markets.businessinsider.com/news/currencies/sam-bankman-fried-ftx-solana-blockchain-crypto-sol-damage-reputation-2023-1, 2023 (last accessed).
  * [12] Crypto.com.  https://help.crypto.com/en/articles/2500695-crypto-withdrawals-general-information, 2023 (last accessed).
  * [13] Dipanjan Das, Priyanka Bose, Nicola Ruaro, Christopher Kruegel, and Giovanni Vigna.  Understanding security issues in the NFT ecosystem.  In ACM CCS, pages 667–681, 2022.
  * [14] Stelios Daveas, Kostis Karantias, Aggelos Kiayias, and Dionysis Zindros.  A gas-efficient superlight Bitcoin client in Solidity.  In ACM AFT, 2020.
  * [15] DefiLlama.  https://defillama.com, 2023 (last accessed).
  * [16] Annette J. Dobson and Adrian G. Barnett.  An introduction to generalized linear models.  CRC press, 2018.
  * [17] Daniel Engel and Maurice Herlihy.  Composing networks of automated market makers.  In ACM AFT, pages 15–28, 2021.
  * [18] Daniel Engel, Maurice Herlihy, and Yingjie Xue.  Failure is (literally) an option: Atomic commitment vs optionality in decentralized finance.  In SSS 2021, 2021.
  * [19] Ethereum.org.  Blockchain bridges.  https://ethereum.org/en/bridges/, 2023 (last updated).
  * [20] Zeke Faux.  Anyone seen Tether’s billions?  Bloomberg, 2021.  https://fortune.com/2021/10/15/tether-crypto-stablecoin-fined-reserves.
  * [21] Ganache.  https://trufflesuite.com, 2023 (last accessed).
  * [22] Juan Garay, Aggelos Kiayias, and Nikos Leonardos.  The Bitcoin backbone protocol: Analysis and applications.  In EuroCrypt, pages 281–310. Springer, 2015.
  * [23] Rosario Gennaro and Steven Goldfeder.  Fast multiparty threshold ECDSA with fast trustless setup.  In ACM CCS, pages 1179–1194, 2018.
  * [24] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich.  Algorand: Scaling byzantine agreements for cryptocurrencies.  In ACM SOSP, 2017.
  * [25] John M Griffin and Amin Shams.  Is Bitcoin really untethered?  The Journal of Finance, 75(4):1913–1964, 2020.
  * [26] Wanyun Catherine Gu, Anika Raghuvanshi, and Dan Boneh.  Empirical measurements on pricing oracles and decentralized governance for stablecoins.  Available at SSRN 3611231, 2020.
  * [27] Maurice Herlihy, Barbara Liskov, and Liuba Shrira.  Cross-chain deals and adversarial commerce.  The VLDB Journal, 2021.
  * [28] Charles Hoskinson.  Why we are building Cardano.  https://whitepaper.io/document/581/cardano-whitepaper, 2017.
  * [29] Bryan Kelly and Hao Jiang.  Tail risk and asset prices.  The Review of Financial Studies, 27(10):2841–2871, 2014.
  * [30] Olga Kharif.  Hackers steal about $600 million in one of the biggest crypto heists.  Bloomberg, 2022.  https://www.bloomberg.com/news/articles/2022-03-29/hackers-steal-590-million-from-ronin-in-latest-bridge-attack.
  * [31] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov.  Ouroboros: A provably secure proof-of-stake blockchain protocol.  In CRYPTO. Springer, 2017.
  * [32] Ariah Klages-Mundt, Dominik Harz, Lewis Gudgeon, Jun-You Liu, and Andreea Minca.  Stablecoins 2.0: Economic foundations and risk-based models.  In ACM AFT, 2020.
  * [33] Jae Kwon and Ethan Buchman.  Cosmos whitepaper: A network of distributed ledgers.  https://wikibitimg.fx994.com/attach/2020/12/16623142020/WBE16623142020_55300.pdf, 2020\.
  * [34] Rui Li and Saralees Nadarajah.  A review of Student’s $t$ distribution and its generalizations.  Empirical Economics, 58:1461–1490, 2020.
  * [35] Bowen Liu, Pawel Szalachowski, and Jianying Zhou.  A first look into DeFi oracles.  In 2021 IEEE International Conference on Decentralized Applications and Infrastructures (DAPPS), pages 39–48. IEEE, 2021.
  * [36] Jordan Lyanchev.  The biggest ever crypto hack: What happened in the Ronin bridge attack.  CryptoPotato, 2022.  https://cryptopotato.com/the-biggest-ever-crypto-hack-what-happened-in-the-ronin-bridge-attack.
  * [37] Yiming Ma, Yao Zeng, and Anthony Lee Zhang.  Stablecoin runs and the centralization of arbitrage.  Available at SSRN 4398546, 2023.
  * [38] Maker Team.  The Dai stablecoin system: Whitepaper.  https://makerdao.com/whitepaper/DaiDec17WP.pdf, 2017.
  * [39] Maker Team.  The Maker protocol: MakerDAO’s multi-collateral Dai (MCD) system.  https://makerdao.com/whitepaper/White%20Paper%20-The%20Maker%20Protocol_%20MakerDAO%E2%80%99s%20Multi-Collateral%20Dai%20(MCD)%20System-FINAL-%20021720.pdf, 2017\.
  * [40] Maker Team.  https://github.com/makerdao/dss/tree/fa4f6630afb0624d04a003e920b0d71a00331d98, 2022 (last updated).
  * [41] Maker Team.  https://github.com/makerdao/dss/blob/master/src/dai.sol, 2022 (last updated).
  * [42] Silvio Micali, Leonid Reyzin, Georgios Vlachos, Riad S Wahby, and Nickolai Zeldovich.  Compact certificates of collective knowledge.  In IEEE S&P, pages 626–641. IEEE, 2021.
  * [43] MIP10c5: List of Active Oracles.  https://mips.makerdao.com/mips/details/MIP10c5SP#sentence-summary, 2023 (last accessed).
  * [44] Amani Moin, Kevin Sekniqi, and Emin Gün Sirer.  SoK: A classification framework for stablecoin designs.  In Financial Crypto, pages 174–197. Springer, 2020.
  * [45] Satoshi Nakamoto.  Bitcoin: A peer-to-peer electronic cash system, 2008.
  * [46] Daniel Reijsbergen, Aung Maw, Jingchi Zhang, Tien Tuan Anh Dinh, and Anwitaman Datta.  PIEChain - a practical blockchain interoperability framework.  In ICDCS (demo), 2023.
  * [47] Sheldon M. Ross.  An elementary introduction to mathematical finance.  Cambridge University Press, 2011.
  * [48] Mehdi Salehi, Jeremy Clark, and Mohammad Mannan.  Red-black coins: Dai without liquidations.  In DeFi Workshop, Financial Crypto ’21, pages 136–145. Springer, 2021.
  * [49] Team Rocket, Maofan Yin, Kevin Sekniqi, Robbert van Renesse, and Emin Gün Sirer.  Scalable and probabilistic leaderless BFT consensus through metastability.  arXiv preprint arXiv:1906.08936, 2019.
  * [50] Sri AravindaKrishnan Thyagarajan, Giulio Malavolta, and Pedro Moreno-Sanchez.  Universal atomic swaps: Secure exchange of coins across all blockchains.  In 2022 IEEE S&P, pages 1299–1316. IEEE, 2022.
  * [51] Fabian Vogelsteller and Vitalik Buterin.  ERC-20 token standard, 2015.  https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md.
  * [52] Xuechao Wang, Peiyao Sheng, Sreeram Kannan, Kartik Nayak, and Pramod Viswanath.  Trustboost: Boosting trust among interoperable blockchains.  arXiv preprint arXiv:2210.11571, 2022.
  * [53] Sam M. Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J Knottenbelt.  SoK: Decentralized finance (DeFi).  arXiv preprint arXiv:2101.08778, 2021.
  * [54] Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, and Dawn Song.  zkBridge: Trustless cross-chain bridges made practical.  ACM CCS, 2022.
  * [55] Jiahua Xu, Krzysztof Paruch, Simon Cousaert, and Yebo Feng.  SoK: Decentralized exchanges (DEX) with automated market maker (AMM) protocols.  ACM Computing Surveys, 55(11):1–50, 2023.
  * [56] Yingjie Xue and Maurice Herlihy.  Hedging against sore loser attacks in cross-chain transactions.  In ACM PODC, pages 155–164, 2021.
  * [57] Anatoly Yakovenko.  Solana: A new architecture for a high performance blockchain.  2018\.
  * [58] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais, and William Knottenbelt.  Xclaim: Trustless, interoperable, cryptocurrency-backed assets.  In IEEE S&P, 2019.
  * [59] ZenGo X.  https://github.com/ZenGo-X/multi-party-ecdsa, 2023 (last updated).
  * [60] Liyi Zhou, Xihan Xiong, Jens Ernstberger, Stefanos Chaliasos, Zhipeng Wang, Ye Wang, Kaihua Qin, Roger Wattenhofer, Dawn Song, and Arthur Gervais.  SoK: Decentralized finance (DeFi) attacks.  Cryptology ePrint Archive, 2022.

##  Appendix A List of Symbols

A list of symbols used in this paper can be found in Table 4.

Table 4: List of symbols. symbol | description
---|---
$p_{m\,t}$ | base price of token $m$ at time $t$
$p_{m\,o\,t}$ | price of token $m$ at time $t$, as reported by oracle $o$
$\mu_{m}$ | mean drift of the stochastic process $p_{m\,t}$
$\sigma^{2}_{m}$ | variance of the stochastic process $p_{m\,t}$
$\mu_{m\,o}$ | mean of the random variable $p_{m\,o\,t}-p_{m\,t}$
$\sigma^{2}_{m\,o}$ | variance of the random variable $p_{m\,o\,t}-p_{m\,t}$
$y_{j}$ | collateral token type of CDP $j$
$c_{j\,t}$ | number of collateral tokens held in CDP $j$ at time $t$
$D_{j\,t}$ | debt of CDP $j$ at time $t$
$\zeta_{m}$ | debt ceiling of token type $m$
$\zeta^{\prime}$ | total debt ceiling of the failed/compromised asset types
$\gamma$ | liquidation ratio
$\lambda$ | maximum contribution of each individual asset type during convex optimization
$\theta$ | system failure threshold
$\mathcal{J}_{t}$ | set of all CDPs at time $t$
$M$ | number of tokens
$O$ | number of price feeds
$U$ | number of users

##  Appendix B Alternative Simulation Methods

In the following, we discuss two alternative methods for estimating failure
risks through simulation: using pure historical data (without an underlying
price model), and with a standard GBM as discussed in Section 3.2.

For the first method, we assume for each time slot that our portfolio had a
given overcollateralization at the start of the slot and check if system
failure occurs within a period of interest (e.g., one day). We repeat this
process for all time steps in our dataset. The downside of this approach is
that our dataset captures a period with many sharp price drops, which results
in a somewhat pessimistic outlook on the failure risk – on the other hand, it
captures realistically the limitations of stablecoins that rely on crypto-
assets.

For the second method, we generate correlated, normally distributed samples
that have the same covariance matrix as the original prices. To achieve this,
let $\mathbf{L}$ be computed as
$\textnormal{Cov}(\mathbf{X})=\mathbf{L}\mathbf{L}^{T}$ using Cholesky
decomposition. Random samples can then be generated as
$\mathbf{LW}=\mathbf{R}$, where the matrix $\mathbf{W}$ contains random values
sampled from the standard normal distribution. We can then calculate the
returns of the assets in portfolio as

$S_{t}=S_{0}\cdot\left\\{\left(\mu-\frac{\sigma^{2}}{2}\right)+\sigma
W_{t}\right\\}.$ (5)

We emphasize that the method used in Section 5.2 is the same as the second
method, with the exception being that we use the multivariate $t$-distribution
to represent the returns instead of the multivariate normal distribution.

Tables 5, 6, and 7 display the failure probability estimations using the
historical, GMB, and $t$-distribution models, respectively. We also display
the width of the 95$\%$ confidence intervals for the estimates. Table 7 and
Table 1 were generated using the same model, and are therefore highly similar.
We note that the historical simulation method often has higher estimated
failure probabilities than the $t$-distribution method for low
$\gamma^{\prime}$, but that the reverse is true for high values of
$\gamma^{\prime}$ (i.e., $\gamma^{\prime}=1.4$ or $\gamma^{\prime}=1.5$).

Table 5: Estimated portfolio failure probabilities - historical method.

single-asset multi-asset $\gamma^{\prime}$ BTC ETH ADA SOL DOT TRX AVAX ALGO
EOS D-All D-ERC D-Mix1 D-Mix2 C-Mix1 C-Mix2 1.2 0.052 $\pm$0.0057 0.072
$\pm$0.0067 0.060 $\pm$0.0062 0.198 $\pm$0.0103 0.048 $\pm$0.0056 0.040
$\pm$0.0051 0.134 $\pm$0.0088 0.135 $\pm$0.0089 0.089 $\pm$0.0074 0.000
$\pm$0.0000 0.067 $\pm$0.0065 0.060 $\pm$0.0062 0.060 $\pm$0.0062 0.058
$\pm$0.0061 0.052 $\pm$0.0058 1.3 0.002 $\pm$0.0012 0.024 $\pm$0.0040 0.003
$\pm$0.0013 0.054 $\pm$0.0059 0.006 $\pm$0.0020 0.002 $\pm$0.0012 0.020
$\pm$0.0036 0.037 $\pm$0.0049 0.022 $\pm$0.0038 0.000 $\pm$0.0000 0.024
$\pm$0.0039 0.022 $\pm$0.0038 0.024 $\pm$0.0039 0.019 $\pm$0.0035 0.006
$\pm$0.0020 1.4 0.000 $\pm$0.0000 0.004 $\pm$0.0016 0.000 $\pm$0.0000 0.037
$\pm$0.0049 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.003 $\pm$0.0015 0.019
$\pm$0.0035 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.001 $\pm$0.0010 0.001
$\pm$0.0010 0.001 $\pm$0.0010 0.000 $\pm$0.0000 0.000 $\pm$0.0000 1.5 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.030 $\pm$0.0044 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.003 $\pm$0.0015 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000

Table 6: Estimated portfolio failure probabilities - standard GBM.

single-asset multi-asset $\gamma^{\prime}$ BTC ETH ADA SOL DOT TRX AVAX ALGO
EOS D-All D-ERC D-Mix1 D-Mix2 C-Mix1 C-Mix2 1.2 0.024 $\pm$0.0005 0.046
$\pm$0.0007 0.043 $\pm$0.0006 0.147 $\pm$0.0011 0.036 $\pm$0.0006 0.024
$\pm$0.0005 0.073 $\pm$0.0008 0.124 $\pm$0.0010 0.069 $\pm$0.0008 0.000
$\pm$0.0000 0.045 $\pm$0.0007 0.037 $\pm$0.0006 0.042 $\pm$0.0006 0.034
$\pm$0.0006 0.031 $\pm$0.0005 1.3 0.001 $\pm$0.0001 0.005 $\pm$0.0002 0.003
$\pm$0.0002 0.070 $\pm$0.0008 0.002 $\pm$0.0001 0.001 $\pm$0.0001 0.010
$\pm$0.0003 0.025 $\pm$0.0005 0.007 $\pm$0.0003 0.000 $\pm$0.0000 0.004
$\pm$0.0002 0.002 $\pm$0.0001 0.003 $\pm$0.0002 0.002 $\pm$0.0001 0.001
$\pm$0.0001 1.4 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.038
$\pm$0.0006 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.001 $\pm$0.0001 0.004
$\pm$0.0002 0.000 $\pm$0.0001 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 1.5 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.019 $\pm$0.0004 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0001 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000 0.000
$\pm$0.0000 0.000 $\pm$0.0000 0.000 $\pm$0.0000

Table 7: Estimated portfolio failure probabilities - Student’s $t$ GBM.

single-asset multi-asset $\gamma^{\prime}$ BTC ETH ADA SOL DOT TRX AVAX ALGO
EOS D-All D-ERC D-Mix1 D-Mix2 C-Mix1 C-Mix2 1.2 0.022 $\pm$0.0005 0.047
$\pm$0.0007 0.077 $\pm$0.0008 0.227 $\pm$0.0013 0.062 $\pm$0.0008 0.019
$\pm$0.0004 0.126 $\pm$0.0010 0.164 $\pm$0.0012 0.099 $\pm$0.0009 0.001
$\pm$0.0001 0.050 $\pm$0.0007 0.040 $\pm$0.0006 0.048 $\pm$0.0007 0.028
$\pm$0.0005 0.029 $\pm$0.0005 1.3 0.003 $\pm$0.0002 0.008 $\pm$0.0003 0.014
$\pm$0.0004 0.092 $\pm$0.0009 0.012 $\pm$0.0003 0.003 $\pm$0.0002 0.029
$\pm$0.0005 0.051 $\pm$0.0007 0.015 $\pm$0.0004 0.000 $\pm$0.0000 0.007
$\pm$0.0003 0.005 $\pm$0.0002 0.007 $\pm$0.0003 0.003 $\pm$0.0002 0.003
$\pm$0.0002 1.4 0.001 $\pm$0.0001 0.003 $\pm$0.0002 0.005 $\pm$0.0002 0.059
$\pm$0.0007 0.004 $\pm$0.0002 0.001 $\pm$0.0001 0.009 $\pm$0.0003 0.019
$\pm$0.0004 0.005 $\pm$0.0002 0.000 $\pm$0.0000 0.002 $\pm$0.0001 0.001
$\pm$0.0001 0.002 $\pm$0.0001 0.001 $\pm$0.0001 0.001 $\pm$0.0001 1.5 0.001
$\pm$0.0001 0.002 $\pm$0.0001 0.002 $\pm$0.0001 0.042 $\pm$0.0006 0.002
$\pm$0.0001 0.001 $\pm$0.0001 0.004 $\pm$0.0002 0.008 $\pm$0.0003 0.002
$\pm$0.0002 0.000 $\pm$0.0000 0.001 $\pm$0.0001 0.001 $\pm$0.0001 0.001
$\pm$0.0001 0.001 $\pm$0.0001 0.001 $\pm$0.0001

We visualize the difference between the standard and $t$-distribution GBM for
10 separate simulation runs in Figure 4(a) and Figure 4(b), respectively. The
$t$-distribution GBM runs are visibly more likely to experience sharp jumps
than the standard GBM runs.

(a)

(b)

Figure 4: For 10 separate asset price simulation runs, the total value of the
portfolio 50% BTC and 50% ETH) over a 1 day period, using the standard GBM (a)
and the GBM with the $t$-distribution (b). The dashed line represents the
system failure threshold for $\gamma$ = 1.2 and $\theta$ = 1.1.

##  Appendix C Distribution Fitting Examples

The GBM is usually assumed to follow a normal distribution. In previous
simulations we used normal distributions to simulate the returns. As mentioned
by many papers, distribution of stock returns is usually more heavy-tailed and
Student’s t-distribution is better fit (see, e.g., [34, 29]). When comparing
residual sum of squares for normal and t-distribution on returns of ETH, we
get a residual sum of squares (RSS) that is approximately equal to 31900 and
14000 for the normal and $t$\- distribution, respectively. Moreover, the
fitted $t$-distribution has a lower RSS for all other assets as well. In
Figure 5, we have displayed a comparison of the normal and $t$-distribution
fitted on Ethereum and Solona returns. As such, we prefer to use the
$t$-distribution for the risk analysis in this paper.

Figure 5: Comparison between t-distribution and normal distribution fitted on
historical returns.

##  Appendix D Proofs of Theorems 5.1 – 5.3

Before we prove the main theorems, we need the following technical lemmas. We
need the first to prove that if all CDPs are over-collateralized, then so is
system as a whole.

######  Lemma D.1.

If $a_{i}/b_{i}>c$ for $i=1,\ldots,n$, then
$\frac{\sum_{i=1}^{n}a_{i}}{\sum_{i=1}^{n}b_{i}}>c$.

######  Proof D.2.

Note that
$\frac{\sum_{i=1}^{n}a_{i}}{\sum_{i=1}^{n}b_{i}}=\sum_{i=1}^{n}\frac{a_{i}}{b_{i}}\frac{b_{i}}{\sum_{j=1}^{n}b_{j}}$.
Since $\sum_{i=1}^{n}\frac{b_{i}}{\sum_{j=1}^{n}b_{j}}=1$,
$\frac{\sum_{i=1}^{n}a_{i}}{\sum_{i=1}^{n}b_{i}}$ is a convex combination of
$a_{i}/b_{i},\ldots,a_{n}/b_{n}$. As such, it cannot be smaller than
$\min_{i=1,\ldots,n}a_{i}/b_{i}$, which is greater than $c$ by the statement
of the lemma.

The second lemma is a commonly-known result, but we include the proof here for
completeness.

######  Lemma D.3.

If $X$ has a normal distribution with mean $0$ and variance $1$, then

$R(x)=\mathbb{P}(X>x)\leq\frac{e^{-x^{2}/2}}{x\sqrt{2\pi}}.$

######  Proof D.4.

Since for $y\geq x\geq 0$ we have that $1\leq\frac{y}{x}$, we have that

$\begin{split}\mathbb{P}(X>x)&=\frac{1}{\sqrt{2\pi}}\int_{x}^{\infty}e^{-y^{2}/2}dy\\\
&\leq\frac{1}{\sqrt{2\pi}}\int_{x}^{\infty}\frac{y}{x}e^{-y^{2}/2}dy=\frac{e^{-x^{2}/2}}{x\sqrt{2\pi}}.\end{split}$

With these lemmas, we are ready to prove the three theorems from Section 5.

######  Proof D.5 (Proof of Theorem 5.1).

If $p_{y_{j}\,t}c_{j\,t}/y_{j\,t}>\gamma$ holds for all $j\in\mathcal{J}$,
then by Lemma D.1 it must hold that

$\frac{C^{+}_{0}}{D^{+}_{0}}>\gamma.$ (6)

Furthermore, we know from the definition of the debt ceiling that
$D^{-}_{0}<\zeta^{\prime}(D^{-}_{0}+D^{+}_{0})$, where $\zeta^{\prime}$ (as
defined in Section 5) is the total debt ceiling of the affected tokens. The
above can be rewritten to

$D^{-}_{0}<\zeta^{\prime}/(1-\zeta^{\prime})D^{+}_{0}.$ (7)

We therefore find that

$\frac{C^{*}_{1}}{D^{*}_{1}}=\frac{C^{+}_{0}}{D^{-}_{0}+D^{+}_{0}}>\frac{C^{+}_{0}}{\left(1+\frac{\zeta^{\prime}}{1-\zeta^{\prime}}\right)D^{+}_{0}}>\gamma(1-\zeta^{\prime})$

where the first inequality holds because of (7) and the second because of (6).

######  Proof D.6 (Proof of Theorem 5.2).

Because of the debt ceilings on the tokens, the total debt incurred for each
token type $m$ must still satisfy
$\sum_{\begin{subarray}{c}j\in\mathcal{J}_{t}\\\
y_{j}=m\end{subarray}}D_{j\,t}<\zeta_{m}\sum_{j\in\mathcal{J}_{t}}D_{j\,t}.$ –
as such, even after the attack, we must have
$D^{-}_{1}=D^{-}_{0}+h^{\prime}<\zeta^{\prime}(D^{+}_{0}+D^{-}_{0}+h^{\prime})$
or

$D^{-}_{0}+h^{\prime}<\zeta^{\prime}/(1-\zeta^{\prime})D^{+}_{0}$ (8)

where $D^{-}_{0}$, $D^{+}_{0}$, and $\zeta^{-}$ are as defined in the previous
section. We have that

$\frac{C^{*}_{1}}{D^{*}_{1}}=\frac{C^{-}_{0}+C^{+}_{0}}{D^{-}_{0}+D^{+}_{0}+h}>\frac{C^{-}_{0}+C^{+}_{0}}{\left(1+\frac{\zeta^{\prime}}{1-\zeta^{\prime}}\right)D^{+}_{0}}>\gamma(1-\zeta^{\prime})$

where the first inequality holds because of (8) and the second because
$C^{-}_{0}>0$ and because of (6). As such, we again find that the debt
ceilings ensure that CroCoDai remains fully backed if it is sufficiently over-
collateralized.

######  Proof D.7 (Proof of Theorem 5.3).

In the following, we first assume that $O$ is odd and that some subset
$O^{\prime}\subset[O]$ is controlled by malicious parties who aim to convince
a vault in CroCoDai that the price is at most than some $p^{*}>p$. In this
case, the median equals the $\frac{1}{2}(M+1)+|O^{\prime}|$ th order statistic
from a sample of $M-|O|$ normally distributed random variables with mean $p$
and standard deviation $\sigma_{o}^{2}$. This order statistic is greater than
the maximum of the $M-O^{\prime}$ random variables, which we denote by $Y$.
Let $\sigma_{*}=\min_{o\in[O]}\sigma_{o}$. $Y$’s cumulative distribution
function equals

$\begin{split}\mathbb{P}(Y\geq
p^{*})&=\mathbb{P}\left(\bigwedge_{o\in[O]\backslash
M^{\prime}}\Delta_{o}>p^{*}-p\right)=\prod_{o\notin
O^{\prime}}R\left(\frac{p^{*}-p}{\sigma_{o}}\right)\\\ &\leq
R^{M-|O|}\left(\frac{p^{*}-p}{\sigma_{*}}\right)\leq\frac{e^{-(M-|O^{\prime}|)(p^{*}-p)^{2}/2}}{(p^{*}-p)\sigma\sqrt{2\pi}},\end{split}$

where the first inequality holds because $R$ is a monotonically decreasing
function, and the second inequality follows from Lemma D.3. As such, the
probability $\mathbb{P}(Y\geq p^{*})$ vanishes exponentially as $p^{*}-p$
increases. The proof for $p^{*}<p$ is very similar and uses the symmetry of
the normal distribution.

##  Appendix E DSS Parametrization

The parameters of the various different vault types in the DSS can be found
here. A sample of parameter values as of 25 April 2023 (Ethereum block
17121982) can be found in Table 8. For each of the supported token type $j$,
we indicate the token name, total value of the collateral of CDPs of this type
$\sum_{j\in\mathcal{J}}p_{j\,t}c_{j\,t}$, total debt of the collateral of CDPs
of this type $\sum_{j\in\mathcal{J}}D_{j\,t}$, collateralization ratio, and
debt ceiling $\zeta_{j}$. Although the exact values vary throughout the day,
this table is meant to illustrate the typical composition of the collateral
type in the DSS.

The following token types were supported in the DSS, but were later
deprecated: AAVE, BAL, BAT, COMP, KNC, LRC, MANA, RENBTC, TUSD, UNI, USDT, and
ZRX. The following liquidity pool tokens were deprecated: AAVE/ETH, LINK/ETH,
UNI/ETH, wBTC/Dai, and wBTC/ETH.

Table 8: Information about the various collateral types used by the DSS (as of
Ethereum block 17121982).

| Name | Token/Asset Platform | debt | coll. value | overcoll. | debt ceil. | stab. fee | liq. rate | contrib.
---|---|---|---|---|---|---|---|---|---
Standard ERC-20 Tokens | ETH-A | Ether | 233580929 | 421276897 | 180% | 15000000000 | 1.50% | 145% | 4.69%
ETH-B | — | 45480335 | 67797760 | 149% | 250000000 | 3.00% | 130% | 0.91%
ETH-C | — | 306467435 | 407905059 | 133% | 2000000000 | 0.75% | 170% | 6.16%
WSTETH-A | Wrapped Ether | 105440104 | 123821333 | 117% | 500000000 | 1.50% | 160% | 2.12%
WSTETH-B | — | 198020222 | 212522461 | 107% | 500000000 | 0.75% | 185% | 3.98%
RETH-A | — | 3503590 | 6503590 | 186% | 20000000 | 0.50% | 170% | 0.07%
WBTC-A | Wrapped Bitcoin | 35684532 | 55869143 | 157% | 500000000 | 1.75% | 145% | 0.72%
WBTC-B | — | 22535846 | 32535847 | 144% | 250000000 | 3.25% | 130% | 0.45%
WBTC-C | — | 40106301 | 63565858 | 158% | 500000000 | 1.00% | 175% | 0.81%
LINK-A | ChainLink | 711324 | 3708567 | 521% | 5000000 | 2.50% | 165% | 0.01%
YFI-A | Yearn | 148553 | 1941526 | 1307% | 4000000 | 1.50% | 165% | 0.00%
MATIC-A | Polygon | 194080 | 5193556 | 2676% | 15000000 | 3.00% | 175% | 0.00%
GNO-A | Gnosis | 3020632 | 5000000 | 166% | 5000000 | 2.50% | 350% | 0.06%
| Total (ERC-20 tokens): | 994893882 | 1407641598 |  |  |  |  | 20.00%
LP Tokens | UNIV2USDCETH-A | USDC/ETH | 2139902 | 0 | 0% |  | 1.50% | 120% | 0.04%
UNIV2DAIUSDC-A | Dai/USDC | 23983390 | 0 | 0% |  | 0.02% | 102% | 0.48%
GUNIV3DAIUSDC1-A | Dai/USDC | 59841202 | 0 | 0% |  | 0.02% | 102% | 1.20%
GUNIV3DAIUSDC2-A | Dai/USDC | 104141233 | 0 | 0% |  | 0.06% | 102% | 2.09%
CRVV1ETHSTETH-A | ETH/wETH | 56643346 | 66542992 | 117% | 100000000 | 1.50% | 155% | 1.14%
| Total (Liquidity Pool ERC-20 tokens): | 246749074 | 66542992 |  |  |  |  | 4.96%
Real-World Assets | RWA001-A | 6s Capital | 14348036 | 15000000 | 105% |  | 3.00% |  | 0.29%
RWA002-A | Centrifuge | 6429638 | 20000000 | 311% |  | 3.50% |  | 0.13%
RWA003-A | — | 1824487 | 2000000 | 110% |  | 6.00% |  | 0.04%
RWA004-A | — | 1468187 | 7000000 | 477% |  | 7.00% |  | 0.03%
RWA005-A | — | 6076346 | 15000000 | 247% |  | 4.50% |  | 0.12%
RWA006-A | AEA | 0 | 0 |  |  | 2.00% |  | 0.00%
RWA007-A | Monetalis | 499950318 | 1250000000 | 250% |  | 0.00% |  | 10.05%
RWA008-A | SG Forge | 0 | 30000000 |  |  | 0.05% |  | 0.00%
RWA009-A | H. V. Bank | 100000000 | 100000000 | 100% |  | 0.00% |  | 2.01%
RWA010-A | Centrifuge | 0 | 20000000 |  |  | 4.00% |  | 0.00%
RWA011-A | — | 0 | 30000000 |  |  | 4.00% |  | 0.00%
RWA012-A | — | 13619456 | 30000000 | 220% |  | 4.00% |  | 0.27%
RWA013-A | — | 69525268 | 70000000 | 101% |  | 4.00% |  | 1.40%
| Total (Real-World Assets): | 713241736 | 1589000000 |  |  |  |  | 14.34%
PSMs | PSM-USDC-A | USD Coin | 2118503205 | 2608700392 | 123% | 10000000000 |  |  | 42.58%
PSM-USDP-A | Pax Dollar | 499997224 | 500000000 | 100% | 500000000 |  |  | 10.05%
PSM-GUSD-A | Gemini Dollar | 387538598 | 437538598 | 113% | 500000000 |  |  | 7.79%
| Total (Peg Stability Modules): | 3006039027 | 3546238990 |  |  |  |  | 60.42%

##  Appendix F Price Data Table

Table 9 contains a specification of the time periods duirng which we collected
price data for the empirical analysis of Section 5. Figure 6 visualizes the
correlations between the 100 tokens in our dataset.

Table 9: Data periods (times are in Greenwich Mean Time). | start | end | number of slots
---|---|---|---
Period 1 | 26-08-2022 02:16 | 30-08-2022 00:26 | 1131
Period 2 | 07-09-2022 03:15 | 15-09-2022 08:45 | 2371
Period 3 | 30-09-2022 07:37 | 02-10-2022 05:27 | 551
Period 4 | 07-10-2022 04:31 | 15-10-2023 22:46 | 2010
Period 5 | 17-10-2022 02:51 | 29-10-2022 16:26 | 3620
Period 6 | 04-11-2022 03:50 | 23-11-2022 05:15 | 5490
Figure 6: The correlations between all 100 tokens in our dataset.

##  Appendix G Portfolio Compositions

Table 10 displays the composition of the DSS-based simulation portfolios.
Table 11 displays the composition of the optimized portfolios. Table 12
displays the optimal portfolio can be constructed using the 100 tokens in our
dataset, if other stablecoins can be included.

Table 10: DSS-based portfolio compositions. portfolio name | token distribution
---|---
D-All | 47% USDC, 19% ETH, 14% PAXG
10% USDP, 8% USDT, 2% WBTC
D-ERC | 90.2% ETH, 9.4% WBTC, 0.2% GNO,
0.1% LINK, 0.05% MATIC, 0.05% YFI
D-Mix1 | 50% ETH, 30% WBTC, 5% GNO,
5% LINK, 5% MATIC, 5% YFI
D-Mix2 | 20% ETH, 20% WBTC, 15% GNO,
15% LINK, 15% MATIC, 15% YFI
C-Mix1 | 50% ETH, 30% WBTC, 5% ADA,
5% DOT, 5% TRX, 5% AVAX
C-Mix2 | 20% ETH, 20% WBTC, 15% ADA,
15% DOT, 15% TRX, 15% AVAX
Table 11: Optimal portfolio compositions. name | optimal token distribution
---|---
D-Opt | WBTC 74.015%, GNO 25.985%
D-Opt | WBTC 20%, ETH 20%
($\lambda=0.2$) | GNO 20%, LINK 20%, YFI 20%
C-Opt | WBTC 62.204%, TRX 37.796%
C-Opt | WBTC 20%, ETH 16.656%, ADA 14.493%
($\lambda=0.2$) | DOT 20%, TRX 20%, EOS 8.851%
A-Opt | BSV 8.728%, BTG 0.796%, BTT 36.821%,
DCR 4.357%, GNO 5.221%, HT 0.0762%
KCS 2.726%, KLAY 5.705%, LEO 17.568%
OKB 3.223%, TRX 13.017%, TWT 0.483%, XLM 0.593%
| BSV 10%, BTG 1.354%, BTT 10%,
A-Opt | CAKE 0.644%, DCR 7.278%, GNO 10%,
($\lambda=0.1$) | HT 1.742%, KCS 5.819%, KLAY 9.434%,
LEO 10%, NEXO 0.311%, OKB 5.604%,
| TRX 10%, TWT 8.61%, WBTC 10%, XLM 6.951%
Table 12: Optimal simulation portfolio if other stablecoins are included. BTT 0.34% | BUSD 0.1504% | PAXG 8.72%
---|---|---
USDC 35.90% | USDN 0.12% | USDT 39.89%