National Institute of Standards and Technology release Understanding Stablecoin Technology and Related Security ConsiderationsNational Institute of Standards and Technology

October 9, 2022 |

Regulation of crypto currency and other digital forms of exchange is coming but in in the meantime applying and understanding the technical details of the types of crypto currency is vital.

The National Institute of Standards and Technology (“NIST”) has prepared an analysis of Stablecoin technologies.  For lawyers the relevance goes to security and stability is of relevance.

Stablecoins are a type of cryptocurrency.  They aim to maintain a stable price relative to a specified asset, usually a fiat currency). There is little being written on the technical mechanisms and architectures used and related security considerations. NIST IR 8408 addresses this by providing an evaluation of the technical design of different stablecoin architectures along with related security analyses.

The abstract provides:

Stablecoins are cryptocurrencies whose price is pegged to that of another asset (typically one with low price volatility). The market for stablecoins has grown tremendously – up to almost $200 billion USD in 2022. These coins are being used extensively in newly developing paradigms for digital money and commerce as well as for decentralized finance technology. This work provides a technical description of stablecoin technology to enable reader understanding of the variety of ways in which stablecoins are architected and implemented. This includes a descriptive definition, commonly found properties, and distinguishing characteristics, as well as an exploration of stablecoin taxonomies, descriptions of the most common types, and examples from a list of top stablecoins by market capitalization. This document also explores related security, safety, and trust issues with an analysis conducted from a computer science and information technology security perspective as opposed to the financial analysis and economics focus of much of the stablecoin literature.

The NIST defines blockchains as:

Blockchains are distributed digital ledgers of cryptographically signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after validation and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify (creating tamper resistance). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules.

A crypto currency is:

digital asset/credit/unit within the system, which is cryptographically sent from one blockchain network user to another. In the case of cryptocurrency creation (such as the reward for mining), the publishing node includes a transaction sending the newly created cryptocurrency to one or more blockchain network users. These assets are transferred from one user to another by using digital signatures with asymmetric-key pairs.

There are two accounting mmeodels of blockchain:

  1. unspent transaction output (UTXO). individual coins (or fractions thereof) exist in unspent transactions.  Individual coins exist in unspent transactions. A user can spend these unspent coins by possessing the correct cryptographic key; and
  2. account balance.  the blockchain keeps track of how many coins individual accounts possess. The coins do not digitally exist as unique entities; they are just counters associated with accounts

A smart contract is:

a collection of code and data that is deployed using cryptographically signed transactions on the blockchain network. The smart contract is executed by nodes within the blockchain network; all nodes must derive the same results for the 368 execution, and the results of execution are recorded on the blockchain

Cryptocurrency tokens are units of cryptocurrency that are created and managed by smart contracts

A smart contract can create tokens, distribute tokens to users, transfer tokens between users, and burn tokens (i.e., delete them). All accounting is done by the smart contract with the state stored on the blockchain.

Centralized finance (CeFi) occurs when customer funds are held by a third-party entity as a custodian that manages the funds to provide a financial service

Decentralized finance (DeFi) refers to the lack of a non-blockchain third-party custodian for a provided financial service.  DeFi exchanges exist as smart contracts on a blockchain that enable users to trade between cryptocurrencies. A DeFi exchange is commonly referred to as DEX. They typically do not use an order book to connect buyers with sellers but instead use algorithms to determine the exchange rate to use between cryptocurrencies

A stablecoin:

  • is a cryptocurrency token that is a fungible unit of financial value pegged to:
    • a currency,
    • some other asset, or
    • index.
  • can be traded directly between parties and converted to other currencies or the pegged asset.
  • typically includes the following four properties.
    1. Property 1 (Tokenized): A stablecoin is a cryptocurrency token managed by a smart contract.
    2. Property 2 (Fungible): Stablecoins are fungible units of financial value with little to no pricing volatility relative to their pegged asset or index.
    3. Property 3 (Tradable): Stablecoins can be traded directly between parties.
    4. Property 4 (Convertible): Stablecoins can be converted to other currencies or the pegged asset.
  • has the following characteristics:
    • Characteristic 1 (Number of Coins): A stablecoin architecture may use multiple mutually supportive coins to maintain the peg for its stablecoin.
    • Characteristic 2 (Custodial Type): Stablecoins may use a centralized custodial finance  model (CeFi) or a decentralized non-custodial finance model (DeFi).
    • Characteristic 3 (Management Type): Stablecoins may have different management types: no management, a company, a known individual, an anonymous individual, or anonymous group owners who hold governance tokens.
    • Characteristic 4 (Blockchain Automation): Stablecoins may operate fully on-chain and  autonomously, on-chain and autonomously but with control hooks, or mostly off-chain and manually with a smart contract interface.
    •  Characteristic 5 (Coin Minting and Burning): Stablecoins have different policies for minting (coin creation) and burning (coin deletion).
    • Characteristic 6 (Collateral Type): Stablecoins may be collateralized using different  types of reserves.
    •  Characteristic 7 (Collateralization Level): Stablecoins may be collateralized at different levels.
    • Characteristic 8 (Stabilization Mechanism): Stablecoins may use different mechanisms to promote price stability.
    • Characteristic 9 (Oracle Dependence): Stablecoins may depend on “oracles” to provide on-blockchain data feeds for off-blockchain asset prices.
    • Characteristic 10 (Blockchain Independence): Stablecoins may be blockchain- independent and simultaneously instantiated on multiple blockchains.
    • Characteristic 11 (Regulatory Accessibility): Stablecoins may be implemented in a way that hinders government regulation, which might limit their use by citizens of particular countries.

A fiat currency-backed stablecoin:

  • is one whose value is backed through the cash-equivalent  reserves of a particular fiat currency or index of currencies.
  • is almost identical to non- currency asset-backed stablecoins except for the type of reserve.
  • uses a simple one-coin ecosystem where the managed coin is the stablecoin.
  • uses a CeFi approach, where customer funds are held off-chain by a third party. This then necessitates a centralized off-chain management entity (e.g., a company) to manage the off-chain investment of customer funds. Ordinarily, a single company owns the stablecoin and moves deposited customer funds off-chain and invests them.

The managing company uses a relatively simple smart contract as a gateway to receive and return customer funds. As the collateral is invested off-blockchain, there is very little smart contract automation. The smart contract is mostly an interface to connect users to the off-chain reserve pool which will accept deposits and mint tokens of equal value. It will also accept tokens for redemption. Coins are minted by the smart contract upon receipt of collateral from the purchaser. Coins are burned by the smart contract during the redemption process. A coin holder provides the coins to be burned, and the smart contract provides an equivalent amount of reserve funds in exchange, often denominated in some volatile cryptocurrency.

Price stability is maintained by the maintenance of full collateralization along with a smart contract purchase and redemption mechanism. Customers have confidence in the pegged price of the stablecoin because they can always redeem their coins for the fixed price using the smart contract since the manager holds enough reserves to cover all issued coins.

Fiat currency-backed stablecoins:

  • do not require interactions with oracles or need coin holders to vote on pricing information
  • exist simultaneously on multiple blockchains because the primary functionality of the stablecoin is not implemented on a blockchain.
  • are amenable to being regulated because an off-blockchain managing company registered in a particular country typically exists.

A cryptocurrency-backed stablecoin is backed through cryptocurrency reserves held on a blockchain. The coins function identically to coins from fiat-911 backed stablecoins, but the architecture supporting coin issuance and redemption is very different.

With cryptocurrency-backed stablecoins, all stablecoins issued are the result of loans taken out by borrowers. The borrowers provide collateral in the form of volatile cryptocurrency. They provide more collateral than the borrowed funds.

With cryptocurrency-backed stablecoins customer funds are held on chain by a third party.  The governance coins (if any) can be used to vote on proposals that modify the system.

Smart contract deposits receive collateral from a borrower into one or more accounts set up for the borrower.  A smart contact receives stablecoins and return collateral, eliminating debt positions. The received stablecoins are burned because they are no longer collateralized.

Most cryptocurrency-backed stablecoins require the borrower to repay their own debt positions, receiving their initial collateral in return. Some allow anyone to return stablecoins to the smart contract. This automatically wipes out other borrowers’ debt positions (eliminating debt equal to the received stablecoins). The positions with the lowest collateral percentage are eliminated, promoting a maximal level of over-collateralization for the system as a whole.
All minted coins must be over-collateralized with the locked funds. If a borrower’s debt position is involuntarily liquidated, any extra collateral may be returned to the borrower minus any fees and penalties.
All issued cryptocurrency-backed stablecoins are over-collateralized, which promotes the  maintenance of the stablecoin peg since stablecoins can always be redeemed from the issuer at their pegged price. The price is further stabilized through arbitrage.

If the price of the stablecoin on third-party markets falls below its peg, then borrowers of the stablecoin can purchase the stablecoin at a discount price and use it to pay off their debt positions (making a profit). When debt positions are paid off, the provided stablecoins are burned. This reduces the overall supply, which puts an upward pressure on the price. If the price of the stablecoin on third-party markets rises above its peg, then borrowers will take on additional debt positions, which results in the minting of additional stablecoins. The borrowers can then immediately sell the newly minted stablecoins on third-party markets for a profit. This increases the overall supply, which puts a 978 downward pressure on the price.
Another method to maintain stability is the use of the stability fee. This is a fee levied for borrowing, paying off a loan, or holding a loan. It can be implemented as a one-time fee or an ongoing interest rate. The rate can be changed to either encourage or discourage borrowing, thus indirectly affecting stablecoin supply and the 983 stablecoin price.

Where a volatile cryptocurrency used for collateral loses enough value that some debt positions become under-collateralized the stablecoin architecture obtains additional funds to cover the losses through a a separate reserve pool of assets.  If the reserve pool empties during the process of eliminating under-collateralized debt positions, some stablecoins will mint and sell governance or reward tokens to cover the losses. Minting additional coins with no collateral backing them devalues the minted coins
Cryptocurrency-backed stablecoins may require data from one or more oracles. The oracles provide exchange rate data so that the smart contracts can regularly update the collateralization level of each borrower account (since the value of the collateral relative to the pegged asset will 1001 change). Some stablecoin architectures will rely on a set of trusted oracles that are hard-coded by 1002 the stablecoin manager. Others determine the set of oracles through a voting mechanism using 1003 governance tokens. Others do not use oracles but have a group of users (e.g., those that stake 1004 tokens to receive a portion of the collected fees) periodically submit their votes on the correct 1005 exchange rate [15]. The exchange rate used is an average of the voted rates. Submitters of outlier 1006 votes may be penalized with fewer rewards from the system (or even lose coins), while those 1007 with more accurate votes are rewarded. 1008
Cryptocurrency-backed stablecoins typically exist on just one blockchain due to their DeFi 1009 nature (e.g., the holding of reserve funds on the blockchain). Such a stablecoin could be 1010 implemented on multiple blockchains. However, each implementation would have its own 1011 reserve fund and its own set of governance tokens (when using decentralized governance). Such 1012
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
19
stablecoins might then have the same name and use the same code but would be unique and 1013 independent (just as human twins are unique individuals). 1014
Lastly, some cryptocurrency-backed stablecoins focus on having “censorship resistance” (e.g., 1015 Liquity). This means that no administrator account can control the smart contracts, and the front-1016 end off-chain user-facing services are implemented by third parties. Such cryptocurrencies seek 1017 to be fully DeFi with no off-chain governance body or owner. This architecture may pose 1018 challenges for regulators from different countries because there would not be any legal entity 1019 with which to enforce compliance. The governance of the cryptocurrency would be a set of 1020 anonymous and ever-changing holders of the governance tokens. This said, the third-party 1021 companies that provide the user-facing services on behalf of the cryptocurrency might be 1022 regulatable legal entities.

A non-currency asset-backed stablecoin is one whose value is backed through reserves that are 1047 non-currency assets or financial vehicles that track the price of such assets. They are essentially 1048
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
20
identical to fiat currency-backed stablecoin except for differences in the type of reserves held. 1049 Like fiat-backed stablecoins, the reserve is usually held in the form of the targeted pegged asset. 1050 The asset itself might be physically held in a reserve pool. Alternatively, a financial vehicle 1051 might be used for the reserve pool that is designed to closely mimic the asset price. The 1052 stablecoin managers might use an asset-tracking mutual fund or ETF or directly trade in futures 1053 and options. For example, non-currency asset-backed stablecoins that peg to the value of gold 1054 typically hold gold as reserves. While gold is common, the reserves could be anything that 1055 investors may want to track. A stablecoin could peg to a stock, index of stocks, commodity, or 1056 real estate. Remember that stablecoins are only stable relative to their pegged asset. They 1057 typically achieve this peg by holding enough assets in reserve to cover the issued coins or even 1058 just a significant fraction of the value of the coins. The asset itself may vary in value relative to 1059 other assets, and the liquidity may be less than with currency. 1060
A challenge with non-currency asset-backed stablecoins is that it can be difficult for the 1061 stablecoin issuer to provide a redemption method whereby stablecoin holders can redeem coins 1062 for the reserve asset. This is important because non-currency asset-backed stablecoins rely on the 1063 ability of investors performing arbitrage to burn tokens to reclaim the funds represented by the 1064 assets. It would require having a physical presence to distribute the asset. Though rare, this 1065 capability is provided for by some stablecoins. Ideally, but unlikely in practice, there would be 1066 physical presences worldwide since anyone on the internet can purchase the stablecoins, and it 1067 would be burdensome to require stablecoin holders to travel internationally in order to perform 1068 redemptions. Complicating matters further, some stablecoins may be pegged to assets that are 1069 less redeemable in physical form, such as barrels of oil. Thus, such stablecoin providers may 1070 process redemptions by selling the asset for fiat currency and then performing the redemption in 1071 fiat currency. The stablecoin issuer may not even directly hold the physical asset but instead use 1072 a financial market vehicle that represents the asset and can be readily traded for fiat currency. If 1073 the currency maintainer redeems in currency equivalency, then they must keep a small currency 1074 reserve for redemptions while simultaneously managing the buying and selling of the asset to 1075 maintain their stated level of collateral (partial or full). 1076
The following is a summary of the typical characteristics found in non-currency asset-backed 1077 stablecoins (these characteristics are identical to fiat-backed stablecoins except for the collateral 1078 type):

An algorithmic stablecoin is one that maintains its price peg by independently shrinking or 1097 expanding the supply of the coin. The algorithm is encoded within the stablecoin smart contract 1098 and automatically acts without human intervention. The “pure” algorithmic stablecoins discussed 1099 in this section maintain no collateral to back their currency. This means that the coins cannot be 1100 directly redeemed for coinage not involved in the stablecoin architecture. In practice, the 1101 majority are hybrid coins that mix the algorithmic approach with a partial collateralization. 1102
Since there is no collateral, the coin price depends on a consistent demand for the coin. Its price 1103 is maintained with the continued confidence that the “system will survive [and] that belief can 1104 lead to a virtuous cycle that ensures its survival” [14]. There are potential pitfalls with using this 1105 stability mechanism [2], which may be why many of them are hybrid coins that include some 1106 level of collateralization. 1107
There are two main types of algorithmic coins: seigniorage and rebasing. Other types exist in the 1108 20 studied stablecoins, but they are categorized as hybrid coins because they rely on collateral 1109 and are not discussed here (e.g., Fei coin and “direct incentives”).

Rebasing involves shrinking and expanding the coin supply by periodically modifying the 1112 balance of coins in user accounts. In rebasing systems, there is typically just one coin. They use a 1113 DeFi approach as customer funds are held in accounts on a smart contract. There may be an 1114 owning or managing entity, but the smart contracts autonomously make decisions to influence 1115 the stablecoin price by minting and burning coins based on an input feed from an oracle without 1116 maintaining any sort of collateral. Coins are minted to increase supply if the coin price is too 1117 high, and coins are burned to reduce supply if the coin price is too low. In this way, the coin 1118 price trends toward its peg, but atypically to most stablecoins, the user balances vary. Any 1119 created coins are added to user accounts, and any burned coins are removed from user accounts 1120 (relative to the number of coins each user holds). The price of the coin ends up being more or 1121 less stable, but the instability of the coin price is shifted to the instability of the value of the user 1122 wallets that hold the coin. 1123
For this reason, some of the literature and some issuers do not consider rebasing coins to be 1124 stablecoins. Readers are urged not to use the definition provided in this paper to delineate 1125 between what is and is not a stablecoin. Rather, the definition here discusses a stablecoin as a 1126 unit of financial value. This is true for rebasing coins at a specific moment in time. However, 1127
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
22
over time, that single unit value may, for example, turn into 1.1 units of value (if the stablecoin 1128 price is above its peg) or 0.9 units of value (if the stablecoin price is below its peg). 1129
Rebasing coins, unlike fiat currency stablecoins, may be available on just a single blockchain. 1130 This is because the user account information is tied to that blockchain and rebases occur relative 1131 to the account balances of the users on that blockchain. A rebasing stablecoin could be 1132 instantiated on multiple blockchains, but they might behave as independent coins with each 1133 instantiation having a different third-party market price. 1134
Lastly, the regulatory accessibility of rebasing stablecoins may be low. This is because they can 1135 be instantiated as automated algorithms that do not necessarily need human intervention (except 1136 for dependence on an oracle feed). As with all smart contracts, they cannot be terminated or 1137 modified except by authorized users. Such a system may not need authorized users or could rely 1138 on a voting scheme of anonymous account holders. 1139
The following is a summary of the typical characteristics

Seigniorage involves the arbitrary printing and burning of coins. The word “seigniorage” refers 1155 to the profit made from printing currency and originates in the physical world with the printing 1156 of fiat bills by governments. There is a great variety of seigniorage architectures. This section 1157 discusses how these architectures work in general. 1158
Seigniorage stablecoin architectures typically use a two- or three-coin system. In a two-coin 1159 system, one coin is the stablecoin and the other is a paired volatile token. The volatile token 1160 often represents ownership in the stablecoin architecture and may provide governance/voting 1161 rights or a portion of stablecoin proceeds (especially when staked for such purposes). These 1162 tokens may be referred to as “share” or “balancer” tokens [16]. They hold value that may 1163 appreciate like a non-stablecoin cryptocurrency (e.g., Bitcoin). Thus, the share token may also be 1164
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
23
referred to as a “value-accruing” token that is traded on third-party exchanges like the stablecoin. 1165 If the value of the share token drops too much, the stablecoin will lose value and potentially 1166 become worthless. In a three-coin system, the additional coin (compared to the two-coin system) 1167 might be a governance coin or a “bond/coupon” coin. This latter type is bought by users when 1168 the stablecoin price is below its peg and redeemed with a bonus once the stablecoin retains its 1169 price peg. 1170
Seigniorage stablecoin are DeFi as there is no third-party off-blockchain custodian of collateral, 1171 and all stablecoin functionality is handled on-blockchain by smart contracts. They can be 1172 managed using many different models. One approach is to enact on-chain management by the 1173 anonymous holders of the stablecoin architecture’s governance token, which may serve multiple 1174 purposes depending on the architecture. The governance token holders might then periodically 1175 vote to update the smart contracts as a vehicle by which to manage the stablecoin development. 1176 This functions because the smart contracts are the foundational structure, working autonomously 1177 and using their algorithms to manage the stablecoin. 1178
Stability is achieved by the stablecoin through algorithmic minting and burning and the 1179 purchasing and selling of coins. In a pure algorithmic stablecoin (as opposed to a hybrid), there is 1180 no collateral held by the smart contracts. The smart contract will mint stablecoins when the 1181 stablecoin price is too high, selling those stablecoins in exchange for the share coin. This will 1182 lower the price of the stablecoin by increasing supply while adding value to the share coins by 1183 reducing supply. Bought share coins are often burned, but a portion might be stored in a fund for 1184 a special purpose (e.g., funding stablecoin-related projects). If the price is too low, the smart 1185 contract may buy stablecoins at the pegged price in exchange for newly minted share coins. This 1186 creates an arbitrage opportunity for investors make a quick profit on the price differential of the 1187 stablecoin in third-party markets and the pegged price offered by the smart contract. The smart 1188 contract may also attempt to raise the stablecoin price by selling the bond or coupon tokens. This 1189 performs a similar function of taking stablecoins out of circulation to raise the price. However, 1190 the user receives bond/coupon tokens that are only of value if and when the stablecoin regains its 1191 peg. In contrast, there are no restrictions on buying or selling them with the share coin approach. 1192 Like with the rebasing coins, oracles are often needed so that the algorithms know where the 1193 stablecoin is trading relative to its pegged price on third-party markets. An alternative is to use a 1194 voting mechanism among the governance coin holders to regularly inform the smart contracts of 1195 third-party market exchange rates. 1196
Given the smart contract automation of the stablecoin, algorithmic stablecoins are generally 1197 implemented on a single blockchain. In other words, the same stablecoin is not usually 1198 instantiated simultaneously on multiple blockchains (as is often the case with fiat currency-1199 backed coins). Lastly, their regulatory accessibility may be low for the same reasons as described 1200 for the rebasing coins.

Hybrid stablecoins are stablecoins whose value is stabilized through a combination of methods 1222 drawn from fiat, cryptocurrency, non-currency asset, and algorithmic-backed stablecoins. All 1223 hybrid stablecoins in the top 20 list use a combination of algorithmic and cryptocurrency-backed 1224 methods. The typical hybrid stablecoin is an algorithmic-backed stablecoin that keeps 1225 cryptocurrency reserves. One could also consider a cryptocurrency-backed stablecoin that mints 1226 volatile cryptocurrency during emergencies (e.g., governance or reward tokens) as a hybrid 1227 system. 1228
An example is the now-failed IRON coin. It was managed algorithmically but kept a partial 1229 reserve of $0.75 per $1.00 value in stablecoin USDC [18] [19]. When the price peg failed, the 1230 coin price rationally dropped to approximately $.075 to match the reserve level. 1231
Below are the hybrid stablecoins in the top 20 stablecoins by market capitalization list, all of 1232 which are algorithmic coins that keep cryptocurrency reserves

Private institutional stablecoins are issued for the execution of “internal account transactions, 1239 liquidity management, and transactions between user accounts” between the financial customers 1240 of the issuer [1]. Such a stablecoin is implemented on a private blockchain (i.e., the public does 1241 not have access). The issuer thus knows all network participants and acts as the custodian of the 1242
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
25
participants’ financial accounts. Stability is achieved by the issuer guaranteeing a specific 1243 redemption price for the coins, backed by the deposits of the customers and issuer. Only the 1244 issuer has visibility into the customer accounts that act together as a reserve for the coin 1245 (although periodic attestations or audits could confirm this). 1246
A simple one-coin architecture is used with CeFi custodial management of all customer deposits 1247 by a single company. The blockchain serves as a secure append-only financial ledger with little 1248 need for smart contract automation. Coins are minted as desired with customer deposits of fiat 1249 currency collateral and burnt upon withdrawal. Full collateral is required in order to guarantee 1250 confidence in the fixed price. The implementation is done on a single blockchain because the 1251 customers of the issuing institution will have access to that private blockchain. Lastly, this 1252 stablecoin architecture does not present any unique regulatory accessibility issues for regulators 1253 of the issuing institution because there is a clear ownership of the stablecoin by a single 1254 institution that can be under the purview of a regulator.

Given that no software is without defects, there may arise a situation or combination of situations 1283 that may allow for the creation of stablecoins outside of the intended process. The improperly 1284 minted stablecoins, if sold by the acquirer, will increase the overall supply and put a downward 1285 pressure on the stablecoin price. Quickly selling the coins is likely since the created coins would 1286 still be managed by the accounting code within the stablecoin smart contract and thus be subject 1287 to freezing, confiscation, or destruction. 1288
Once the exploit has been detected and the unauthorized coins identified, the stablecoin system 1289 has several options for mitigation: 1290
• Denylist: The accounts receiving the improperly minted coins can be added to a denylist, 1291 which will prevent them from receiving, exchanging, or sending any stablecoin (isolating 1292 the malicious accounts). 1293
• Confiscation: The unauthorized coins can be unilaterally transferred by the stablecoin 1294 smart contract to another account owned by the stablecoin system (isolating the coins so 1295 that they cannot be spent). 1296
• Burning: The unauthorized coins could simply be destroyed (removing the coins that 1297 should exist from circulation). 1298
This is very different from how traditional cryptocurrency systems must handle similar issues. 1299 Traditional cryptocurrency systems lack the built-in capability to freeze accounts, confiscate 1300 coins, and burn coins owned by others. Typically, a traditional cryptocurrency system (after a 1301 lengthy debate among users and in agreeance

Stablecoin systems that use collateral store a portion of it within the smart contract. At a 1311 minimum, this includes newly deposited collateral and a reserve sufficient to fulfill short-term 1312 stablecoin redemption requests. Since it is held within the smart contract and not in a separate 1313 account or out of the system entirely, the collateral may be subject to theft should an attacker 1314 discover and leverage a vulnerability in the smart contract code. 1315
For fiat and non-currency asset-backed stablecoin systems, only the collateral still held by the 1316 smart contract on chain would be accessible; anything moved off-chain should not be. Stablecoin 1317 managers only keeping the minimum amount available to run the stablecoin system would 1318 prevent the bulk of the collateral from being stolen. Stablecoin managers can add and remove to 1319 the on-chain collateral as necessary. 1320
For cryptocurrency-backed stablecoin systems, the entire reserve is likely held by the smart 1321 contract. The reserve value is also likely greater than that of the value of all issued stablecoins, 1322 making this reserve pool a significant target for attackers. If an attacker successfully manages to 1323 exploit the smart contract, there is likely no means to recover the stolen cryptocurrency once it 1324 has been transferred to another account. 1325
For algorithmic stablecoins, the smart contract may hold an amount of the stablecoin and the 1326 paired companion tokens even though they may not possess collateral. The theft of such reserves 1327 can be managed using the approaches discussed in Section 5.2 (i.e., denylist, confiscation, and 1328 burning) provided that the stolen coins have not yet been sold. 1329
Malicious Smart Contract Update and Hijack 1330
It may be possible for malicious users to engineer a scenario (e.g., via social engineering to 1331 obtain credentials or exploiting a weakness in the software development environment or 1332 deployment software) in which they obtain the ability to deploy updated versions of the 1333 stablecoin’s smart contract. In such a scenario, as the attacker gains full control, they remove the 1334 ability for the original smart contract managers to further modify the smart contract – essentially 1335 hijacking the stablecoin system. 1336
During the interim between the hijacking and user’s reaction to it (especially as there may be no 1337 good method of alerting every user, thus increasing the time of attack), the attacker can perform 1338 any number of malicious actions that a smart contract can allow, such as increasing current fees 1339 or adding additional fees to be paid directly to the attacker and arbitrarily minting coins. They 1340 may even shut the system down entirely. 1341
Data Oracles 1342
Data oracles often play a significant role in blockchain applications and smart contracts, and 1343 some stablecoins utilize them as well. Stablecoin smart contracts typically use oracles to keep 1344 updated on the exchange rates between the coins it manages and other cryptocurrencies. Data 1345 oracles allow for data to be submitted to a blockchain application or smart contract in an 1346 automated fashion. Data oracles do not have the same decentralized nature that blockchains do 1347 and are often single entities that can be more easily compromised. Data oracle attacks can take 1348
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
28
several forms, which are discussed below. All of these potential vulnerabilities might be 1349 mitigated by having a system of redundant data oracles providing the same information. 1350
An attacker could disrupt the data used as input to the oracle, thereby disrupting all services 1351 down the line that rely on the oracle data. The attacker could also compromise the oracle itself 1352 with a denial-of-service attack or penetration to shut it down to achieve the same purpose. An 1353 attacker could also take advantage of a vulnerability in an oracle to learn what data it is about to 1354 submit. The attacker could use that knowledge to buy or sell the stablecoin to their advantage, 1355 knowing in advance how the oracle’s data will affect the exchange rates used by the stablecoin 1356 smart contract. 1357
A more significant vulnerability might allow the attacker to alter the data provided by the oracle 1358 or impersonate the oracle. Alternatively, the attacker may intercept the data before it reaches the 1359 oracle and substitute legitimate data with malicious data. This would enable the attacker to profit 1360 from manipulating the exchange rates used by the smart contract through orchestrated buy and 1361 sell orders. The attacker may provide data that would cause a stablecoin to drop in value, 1362 allowing them to purchase it at a cheaper price, or they may provide data that would cause a 1363 stablecoin to rise in value, allowing them to sell it at a higher price. An an effort to maximize 1364 their profit, the attacker may also perform a combination of lowering then raising a stablecoin’s 1365 price. Such manipulation would likely be quickly noticed, so the attacker would only have a 1366 short window of time in which to carry out such an attack. That said, such types of events could 1367 cause user panic and result in the failure of the stablecoin. 1368
Exploiting the Underlying Blockchain 1369
It is possible for well-resourced attackers to take over the blockchain underlying a stablecoin 1370 implementation, as described in [NIST blockchain pub]. Attackers might do this through 1371 controlling a majority of the mining hardware used in a proof-of-work consensus algorithm or 1372 stake a majority of funds in a proof-of-stake system. This is unlikely for large blockchain 1373 systems given the size of the community that maintains them. Part of the security of Bitcoin and 1374 Ethereum is that an attacker would need a sustained rate of computation that is greater than those 1375 of legitimate miners in order to complete a successful attack. 1376
However, this “large community” security may come at the cost of increased transaction fees and 1377 a higher cost of execution for the stablecoin smart contracts. To mitigate this, some stablecoin 1378 developers utilize smaller blockchains that have lower costs of execution. Less popular 1379 blockchains may have lower fees, but it may also be more tractable for attackers to maliciously 1380 control the blockchain. If the attacker targets a blockchain that utilizes the same hashing 1381 algorithms for consensus and that has only a fraction of the users that Bitcoin or Ethereum does, 1382 it may be possible to exploit the smaller blockchain. Because of this, smaller blockchain systems 1383 may become attractive targets, especially if those blockchains host high market capitalization 1384 stablecoins from which large reserves can be stolen. 1385
Should a smaller blockchain be attacked by a large, coordinated force, the ramifications would 1386 affect all users of that blockchain. If they attacked with a significantly disproportionate 1387 computing power, the blockchain difficulty adjustment algorithm would work as intended and 1388 make it harder to solve. Afterward, the attacker (possibly stealing funds from the stablecoin) 1389 could then leave the smaller blockchain in a state that could take days to create a new block. 1390
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
29
Transaction processing would stop, existing smart contract systems would stall, and users may 1391 lose confidence in the system and abandon it. 1392
The loss of users may also affect stablecoins on that blockchain. Users on their way out will 1393 likely attempt to redeem any stablecoin they can, creating another bank run scenario and 1394 negatively affecting the system and users who react more slowly. Users of the same stablecoin 1395 that is implemented on other blockchains may lose faith in that stablecoin and attempt to leave. 1396 This would create instability for the stablecoin platform overall. 1397
Writing Secure Software and Vulnerabilities 1398
Several of the possible security issues discussed relate to an attacker finding a vulnerability in 1399 smart contract code. Writing secure software is difficult; it requires planning security features 1400 and diligent testing throughout the entire process. Unfortunately, many developers are focused 1401 on providing the core functionality of their software and view security measures as a feature that 1402 can be added on later. Many developers strive to be first to market, and in their haste, developers 1403 deliver software that provides the core features necessary to accomplish the software’s intended 1404 goals but may be not fully tested. In his book, Code Complete [20], Steve McConnell estimated 1405 an industry average of about 15-50 errors per 1000 lines of delivered code. Not every bug will 1406 result in a catastrophic failure or allow for exploitation, and bugs often go unnoticed for years. 1407 No software is immune to defects in code, regardless of whether it is open or closed source or 1408 used by one person or millions of companies worldwide. 1409
One method of reducing software defects is to use a third-party auditor. When developing 1410 software, developers will often fall into a set routine (whether intentional or not) that may 1411 preclude them from triggering a fault in the software. Developers may also only test a small 1412 range of possible inputs (or combination of inputs) and exclude edge cases that may trigger a 1413 fault. Third-party auditors have the benefit of a fresh viewpoint devoid of any prior experience 1414 with the software under audit and the sole goal of discovering defects. Even if software 1415 compiles, runs, and acts as intended, there may still be undetected defects. 1416
An example of software that suffered from a lack of third-party auditing was OpenSSL, which 1417 was used by millions of people worldwide for years. However, it contained a flaw that would 1418 later be exploited in what would be known as Heartbleed. Once the flaw was fixed, the entire 1419 OpenSSL codebase underwent an audit. The results of the audit found several additional flaws 1420 [21] that could have been exploited. 1421
1422
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
30
Stability Issues 1423
Stability for stablecoins usually refers to the ability of stablecoin prices to have accuracy, 1424 predictability, and low volatility. Most important for this is the success of the mechanism used to 1425 peg its price to the price of the target asset. However, such a discussion is primarily in the realm 1426 of economics and out of scope for this paper (e.g., [6]). This section focuses on other stability 1427 issues that may occur with stablecoins. In some cases, the stablecoin architecture promotes 1428 deliberate instability in certain areas as a mechanism to promote the stability of the stablecoin 1429 price. 1430
Dynamic Interest Rates 1431
Some cryptocurrency-backed stablecoins are issued through loan issuance (Section 4.2). The 1432 interest rate used for these loans is generally not fixed but varies in an attempt to maintain 1433 overall price stability for the stablecoin. These rates are different for each stablecoin, may be 1434 significantly different between apparently similar stablecoins, and may be volatile as they 1435 respond to changes in stablecoin price. Typically, a borrower will lock in a rate when they take 1436 out a loan and are not subject to changing interest rates for the duration of their loan. 1437
This technical mechanism of automatically varying interest rates based on coin price fluctuations 1438 can result in a stablecoin ecosystem in which users who attempt to mint coins find significantly 1439 different interest rates between lenders or rapid interest rate fluctuations. This instability in 1440 interest rates is built into the stablecoin lending architecture in order to promote stability in the 1441 coin value and is, thus, unavoidable. 1442
The rate volatility will not normally be noticed by most users as they do not mint stablecoins 1443 through borrowing but simply buy and sell the stablecoin on exchanges. However, too much 1444 volatility or an exorbitant interest rate could potentially cause users to lose confidence in the 1445 system overall and lead to rapid fund withdrawals and a potential break from the pegged price. 1446
Floating Collateral Requirements 1447
The cryptocurrency-backed stablecoins minted through loan issuance (Section 4.2) require users 1448 to post cryptocurrency as collateral when borrowing. This mitigates the cryptocurrency losing its 1449 price peg since enough collateral should be maintained to cover all issued stablecoins. However, 1450 since the posted collateral is in the form of cryptocurrency, it may be extremely volatile. Thus, 1451 borrowers are required to over-collateralize. When borrowing, the stablecoin system will specify 1452 a minimum required collateral ratio. That is, the user must maintain a certain value of 1453 cryptocurrency collateral to cover the price of the borrowed stablecoins. If the user falls below 1454 that ratio (through the posted cryptocurrency losing value), then the user is required to post more 1455 collateral, or their collateral may be subject to liquidation. This is very similar to the 1456 maintenance of margin loans in the stock market. Margin investors in the stock market may be 1457 required to post additional collateral to cover stock market loses. 1458
However, some cryptocurrency-backed stablecoins will change the thresholds at which 1459 customer-posted collateral is dynamically liquidated in order to promote stability in the 1460 stablecoin price. Even customers who post more than the minimum required collateral may see 1461 their collateral liquidated without warning or an opportunity to post additional collateral. This is 1462
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
31
another example of instability being deliberately created in one part of the system to promote 1463 stability in maintaining the stablecoin price peg. 1464
An example system where this can occur is Liquity (LUSD) [https://docs.liquity.org], which 1465 describes itself as: 1466
Liquity is a decentralized borrowing protocol that allows you to draw 0 % interest loans 1467 against Ether used as collateral. Loans are paid out in LUSD – a USD pegged 1468 stablecoin, and need to maintain a minimum collateral ratio of only 110%. 1469
Liquity allows borrowers to exchange Ether (the volatile cryptocurrency) for LUSD (the 1470 stablecoin) at an over-collateralization of at least 110 % but recommends collateralizing over 150 1471 %. Liquity has an additional mechanism for creating stability: the “Stability Pool,” which is 1472 funded by users (known as Stability Providers) transferring their LUSD to it. 1473
In addition to the collateral, the loans are secured by a Stability Pool containing LUSD 1474 and by fellow borrowers collectively acting as guarantors of last resort. 1475
When Liquity users borrow LUSD, they create a Trove, which is linked to an Ethereum address 1476 and contains a balance of the collateral (in Ether) as well as the debt borrowed (in LUSD). Users 1477 can adjust their collateralization percentage by adding more collateral to the Trove or reducing 1478 the amount of debt. If their collateral to debt ratio falls below the minimum 110 %, the Trove can 1479 be liquidated. 1480
Liquidating the trove will burn the corresponding amount of debt out of the stability pool (e.g., 1481 destroy the LUSD) and transfer the entire collateral from the Trove to the Stability Pool to be 1482 divided amongst the Stability Providers. The owner of the liquidated trove keeps the amount of 1483 LUSD they borrowed, but since they provided an over-collateralization of at least 110 % and 1484 their collateral was liquidated, they will have lost 10 % (or whatever percentage over 100 % that 1485 was provided) when they ultimately repay their LUSD debt. 1486
Liquity also has a Recovery Mode, which occurs when the system’s Total Collateral Ratio falls 1487 below 150 %. During Recovery Mode, Troves under 150 % collateral to debt ratio can be 1488 liquidated. The closer a Trove is to 150 %, the lower the likelihood that it will be liquidated. 1489 Liquity also caps the liquidation at 110 % of the collateral. 1490
Liquity mentions: 1491
The best way to avoid being redeemed against is by maintaining a high collateral ratio 1492 relative to the rest of the Trove’s in the system. Remember: The riskiest Troves (i.e., 1493 lowest collateralized Troves) are first in line when a redemption takes place. 1494
Oracle Responsiveness to Rapid Price Fluctuation 1495
Many stablecoins use data oracles to determine the price of their stablecoins and pegged assets. 1496 This information is then used to adjust stablecoin parameters in order to minimize volatility and 1497 peg the stablecoin price to the target asset. 1498
Data Oracles often operate under either a pull or a push-based data gathering scheme. In a pull-1499 based scheme, a smart contract can request that a data oracle obtain and provide fresh data from 1500 its sources. In a push-based scheme, the data oracle proactively obtains data from sources and 1501 makes it available to the smart contract. These data-gathering schemes can either run on a time-1502
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
32
based schedule (e.g., happening every X number of seconds) or on an event-based schedule (e.g., 1503 when Y event occurs, obtain new data). Regardless of what methods are used – push or pull, 1504 time-based or event-based – any system latency in relaying information back to the smart 1505 contract can potentially result in price mismatching. 1506
For stablecoin systems that utilize data oracles to maintain a parity with their chosen assets, 1507 finding the optimal method and frequency for updating the price is critical. If the stablecoin falls 1508 out of sync for too long of a period, the system may – in its attempt to correct – overcompensate 1509 and cause large price swings. For example, the failure of the IRON stablecoin and its associated 1510 $2.2 billion investor loss was that the oracle only updated every 10 minutes, which was not 1511 sufficient during a period of rapid volatility [https://ciphertrace.com/analysis-of-the-titan-token-1512 collapse-iron-finance-rugpull-or-defi-bank-run/]. Additionally, users may profit by leveraging 1513 the latency in the system and knowing how the stablecoin system will react to price updates. 1514
Governance Token Devaluation 1515
Many stablecoins offer governance tokens that enable the token holders to manage the 1516 cryptocurrency. The governance tokens grant privileges for voting on changes to the stablecoin 1517 (e.g., updating a smart contract to instantiate new features). Often, the governance tokens are 1518 also the volatile cryptocurrency tokens used to provide reserve funds for the associated 1519 stablecoin. 1520
A devaluation of the governance tokens could spark a lack of confidence in the stablecoin, 1521 resulting in mass user withdrawals. It could also enable anonymous entities to cheaply buy 1522 control of the stablecoin, and the change of ownership could cause stability concerns. In the 1523 worst case, the new owner might abscond with reserves and run the stablecoin to ruin if a 1524 profitable path can be found in doing so. 1525
Another issue is with stablecoin deployers maintaining control while giving the appearance of 1526 decentralized management. Often, when new stablecoins that are planning to utilize a 1527 governance token are deployed, the stablecoin manager creates and allocates a significant 1528 amount of the governance token for themselves so that they can retain as much power as 1529 possible. 1530
Occasionally, the system will be deployed as a “fair launch,” where no governance coins are 1531 allotted to the stablecoin system manager. In the fair launch scenario, it is possible that many 1532 users purchase a small amount of governance tokens, resulting in a wide distribution. It may also 1533 be possible that only a few users purchase a large amount of governance tokens, resulting in an 1534 uneven distribution. If a few users purchase a large amount of governance tokens in the fair 1535 launch scenario (so-called “whales,” or people who own large amounts of cryptocurrency), they 1536 will have a large control of the system. In addition to the technical control that the large amount 1537 of governance tokens grants them, these whales will also hold a significant influence over the 1538 entire stablecoin system’s userbase and the general opinion people hold about the stablecoin 1539 system. If the whales continue to invest in the system by purchasing additional governance 1540 tokens, other users will see the system as stable and thriving. Should the whales decide to sell off 1541 governance tokens, they may generate user concern about the system’s stability. If a whale 1542 decides to liquidate their governance tokens completely, users may assume that the stablecoin is 1543 failing and panic sell their tokens. With the resulting sudden influx of governance coins, the 1544
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
33
governance coin price will plummet, and the stablecoin itself might lose its peg as users sell their 1545 stablecoins en masse. 1546
Share and Reward Token Devaluation 1547
Some stablecoins use share coins as volatile cryptocurrency collateral. Users are often required 1548 to buy share coins in order to interact with the system. Users who sell their stablecoins back to 1549 the smart contract are typically paid in share coins. A drop in price of the share coin represents a 1550 decrease in collateral in the system. Hypothetically, as long as the share coin has some value, 1551 then an algorithmic stablecoin can always mint and sell more share coins to cover stablecoin 1552 withdrawals. In practice, large sales of share coins can cause the price to plummet, resulting in 1553 people panicking to sell back their stablecoins to the smart contract at the pegged price. They are 1554 paid in the share coin, which increases the supply and further plummets the price. This is one 1555 scenario for the failure of algorithmic and hybrid coins (e.g., Luna and TerraUSD 1556 [https://www.bloomberg.com/graphics/2022-crypto-luna-terra-stablecoin-explainer/]). 1557
Reward tokens are often used to incentivize users to act in a certain manner or to perform 1558 specific activities, typically positive and productive behaviors and activities for the system. Some 1559 reasons to earn a reward token may be active participation in the system’s functions (as opposed 1560 to passively allowing the system to work), providing key assets for proper functionality (e.g., 1561 liquidity or acting as a data oracle), or simply maintaining a long-term investment in the system. 1562
Regardless of the earning mechanism, reward tokens typically have some value to the holder. 1563 This value may be for utilizing functionality within the system or simply monetary. Should the 1564 value decrease and users exchange their reward tokens for less, they may begin to reconsider the 1565 amount of effort or quality of work that they put into the system. This could result in less 1566 liquidity for users in the system, poorer quality (perhaps even incorrect) of data being submitted 1567 into the system (e.g., pricing estimates), or less use overall. Any of these could then negatively 1568 affect the stablecoin architecture as a whole. 1569
Native Cryptocurrency Devaluation 1570
Stablecoins are tokens that reside on a blockchain with its own native cryptocurrency (discussed 1571 in Section 2). The native cryptocurrencies usually have great volatility due to a lack of reserve 1572 funds to back them. As discussed previously, stablecoins are an answer to this volatility as they 1573 normally provide price stability. As a token running on a blockchain, they should not be affected 1574 by the price swings of the underlying blockchain’s cryptocurrency. However, there may be 1575 scenarios in which a devaluation of the underlying native cryptocurrency may affect the 1576 stablecoin system. While it might seem unlikely that a smart contract-based cryptocurrency 1577 would completely fail (i.e., its price go to zero), such systems have no monetary backing. 1578
If the native cryptocurrency devalued to the point where it failed, users would migrate en masse 1579 off of that blockchain. Since the stablecoin token lives on the blockchain, this could precipitate 1580 users to sell all of their stablecoins (not because of a loss of confidence in the stablecoin but 1581 because of the impending failure of the underlying blockchain). Stablecoins instantiated on 1582 multiple blockchains with full reserves would likely survive with a possible temporary loss of 1583 their price peg on the failing blockchain (due to panic selling and the inability of the stablecoin 1584 to quickly provide enough reserves for the redemption requests). Other types of stablecoins 1585
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
34
would fail in this scenario and quickly become insolvent. Algorithmic stablecoins, in particular, 1586 usually depend on steady, continuous growth and can break down if there are sudden massive 1587 withdrawals. 1588
Stablecoins may also use the native cryptocurrency as a reserve asset. If the price of the native 1589 cryptocurrency plummets, this would significantly reduce the stablecoin reserves. For 1590 cryptocurrency-backed stablecoins, this would trigger the liquidation of loan positions, resulting 1591 in investor loss. Users who bought their stablecoins on third-party exchanges would not be 1592 affected or even notice that anything was wrong. 1593
Lastly, a large price drop in the native cryptocurrency (without a complete failure) is likely to 1594 result in a smaller user base on the blockchain and fewer possible investors to contribute to 1595 stablecoin reserves. If the stablecoin is present on multiple blockchains, then users leaving one 1596 blockchain should not have much effect. For algorithmic coins, a diminished user base on the 1597 blockchain could trigger instability as the usual constant stablecoin demand might be interrupted. 1598
Transaction Price Increase 1599
Smart contract pricing is dynamic and subject to the rising cost of the underlying blockchain’s 1600 native digital asset (cryptocurrency) price as well as the demand for computing resources. As the 1601 price of the cryptocurrency rises, the cost of execution rises proportionally since those fees are 1602 paid with a unit of the cryptocurrency. As demand increases and computational resources are 1603 used, users who seek shorter wait times will offer more money to process their transactions 1604 sooner. This can lead to a scenario of one-upmanship, where users continuously pay more than 1605 others to be processed faster. This price increase affects the entire blockchain’s ecosystem of 1606 smart contracts. 1607
As the price per transaction increases, the number of smaller value transactions decreases. This 1608 should reduce the demand for computing resources and the cost of execution. These systems also 1609 see a pattern of high usage with an increased cost and low usage with a decreased cost that users 1610 should take advantage of. 1611
By using smart contracts, stablecoins are subject to this variable pricing. Generally, however, 1612 they also have higher transaction fees than a typical cryptocurrency transfer because of their 1613 additional complexity. For example, with Ethereum, any computation done by a smart contract 1614 on top of the general minimum gas charged for any transaction (21,000 gas) will cost more. 1615
The following are two randomly chosen examples: 1616
1. A purchase of the Tether stablecoin on Uniswap [22] 1617
• A Uniswap purchase of Tether (USDT) – 1.960518020960446923 Ether 1618 ($2,093.17) was used to buy 2100 USDT. 1619
• The Gwei amount offered to the miner was 44.814490035 per gas used 1620 (0.000000044814490035 Ether). 1621
• The amount of Gas used was 201,759. 1622
• The transaction fee for this was 0.009041726694971565 Ether ($9.66). 1623
2. A general transfer of Ether [23] 1624
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
35
• A general Ether transfer of 2.2 Ether ($2,345.22) 1625
• The Gwei amount offered to the miner was 52.128800586 per gas used 1626 (0.000000052128800586 Ether). 1627
• The amount of gas used was 21,000. 1628
• The transaction fee for this was 0.001094704812306 Ether ($1.17). 1629
Even though the amount transferred via a general Ether transaction has more value and the price 1630 per gas offered was higher than the Uniswap purchase of Tether, the transaction fee was higher 1631 because of the increased complexity, causing more gas to be used to execute the transaction. 1632
Trading Curb/Circuit Breaker 1633
To help bolster the stability of a stablecoin price, it has been proposed that stablecoin smart 1634 contracts implement logic to discourage bank runs [24]. Such mechanisms could take the form of 1635 traditional stock market circuit breakers [25]. In the traditional financial system, when a circuit 1636 breaker is triggered, there is either a short-term stop on trading or an early closing of the market 1637 for the day. This period allows for an assessment of the market and for people to make more 1638 financially responsible decisions. 1639
Smart contracts could implement a similar behavior to prevent the panic selling of stablecoins 1640 (i.e., creating a bank run) and allow the system to return to normal operations. The stablecoin 1641 circuit breaker could be manually triggered by the stablecoin manager or be automatically 1642 triggered under certain conditions (e.g., massive spike in stablecoin redemptions, external data 1643 fed by oracle, losing its peg). An automatic mechanism has the advantage of being hard-coded, 1644 and everyone would know the conditions for it to be triggered. A manual mechanism could be 1645 useful, but users might assume that the stablecoin has failed if the manager triggers the circuit 1646 breaker. This is not an unreasonable assumption as many DeFi failures begin with the manager 1647 “temporarily” halting withdrawals. 1648
1649
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
36
Trust Issues 1650
Trust, as defined by ISO/IEC, is the “degree to which a user or other stakeholder has confidence 1651 that a product or system will behave as intended” [ISO/IEC 25010:2011(en), 4.1.3.2]. Trust plays 1652 a large role in any currency – fiat, digital, or crypto. This section focuses on possible trust issues 1653 with the creators, maintainers, and managers of stablecoin systems and how they could use their 1654 privileged status to be deceptive or malicious. Issues related to stablecoin users’ need to trust 1655 other users is also included. 1656
Stablecoin Manager Deception 1657
Stablecoin managers may deceive the users of the stablecoin by not maintaining the stated level 1658 of reserves or not holding those reserves in the stated financial vehicles. 1659
7.1.1. Insufficient Reserves 1660
Trust may be lost if the stablecoin manager does not maintain the promised level of off-chain 1661 reserves and only provides partial collateral. In this scenario, the stablecoin users trust that there 1662 is a certain level of fiat, or non-currency assets, backing the stablecoin as specified by the 1663 stablecoin manager. That trust is broken when the actual level of reserves does not meet the 1664 specified level. This breach of trust can be difficult to determine (e.g., [26]). 1665
Third-party audits of reserves are typically used to provide user confidence that the reserves 1666 exist. Sometimes, a lighter form of audit called an attestation is used. With an attestation, an 1667 auditor confirms that a certain quantity of funds exists in a particular account at a given point in 1668 time. Both may be subject to deceptive tactics by a stablecoin manager attempting to hide that 1669 they have not maintained a fully collateralized position. 1670
One tactic may be to refuse to fully cooperate with the auditors and not provide the information 1671 necessary for them to understand the full financial picture. There have been instances of auditors 1672 quitting stablecoin audits out of frustration with a lack of cooperation by the stablecoin 1673 management. 1674
Another tactic is for the stablecoin manager to leverage assets from other reserves to temporarily 1675 boost the reserve pool during the audit and return them after the audit has completed. This type 1676 of deception is especially vulnerable to the attestation approach, which only evaluates the 1677 stablecoin reserves at a single point in time. The stablecoin manager might borrow the funds 1678 needed to appear fully collateralized on a short-term basis. Alternatively, the stablecoin 1679 management might be part of a larger company (e.g., a cryptocurrency exchange) whose funds 1680 could be used to temporarily bolster the balance sheet of the stablecoin. 1681
Since the reserves are often held in accounts that are not publicly visible and audits are typically 1682 scheduled well in advance, the stablecoin manager may be able to continue this deceptive 1683 practice for some time. Large asset transfers comprising a large percentage of the reserve assets 1684 could be a sign that this kind of deception is taking place. 1685
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
37
7.1.2. Reserve Type Mismatch 1686
Trust may be lost if the stablecoin manager does not hold the reserves in the specified financial 1687 vehicles. In this scenario, the stablecoin users trust that the reserves are in specific assets. That 1688 trust is broken when the stablecoin manager has the reserves in assets outside of the specified 1689 ones for whatever reason, such as an attempt to boost profits. Such alternative financial vehicles 1690 may be more volatile and less liquid. This can expose the stablecoin’s reserves to undocumented 1691 risk and the potential loss of value. The stablecoin company may lose money and be unable to 1692 recover, leading to the loss of the stablecoin peg and resulting in users unexpectedly losing 1693 money. As with the Insufficient Funds breach of trust, this can be difficult to determine since 1694 reserve asset accounts are not publicly visible. 1695
Stablecoin Manager Actions 1696
7.2.1. Account Denylisting 1697
Since stablecoins are often built on top of an underlying blockchain system with smart contracts, 1698 they can offer features that are not present or even possible within the underlying blockchain. 1699 These additional features may be implemented to allow the stablecoin system to respond to law 1700 enforcement requests. CeFi organizations that maintain stablecoin smart contracts are more 1701 likely to implement these features than DeFi organizations because the managers are known. 1702 However, there is nothing to prevent a third party from developing similar systems for DeFi to 1703 offer as an add-on service to end user application developers [27]. 1704
Upon request by law enforcement, a smart contract may maintain a denylist to prevent accounts 1705 from sending or receiving coins. One such example of this can be found in the CENTRE 1706 Consortium, which issues the USDC stablecoin [28]. Another example would be Tether [29]. 1707
A stablecoin denylist can both increase and decrease users’ trust in the system, depending on 1708 how the individual user views the denylist. Some users may view it as a benefit that keeps 1709 malicious actors from interacting with law-abiding users. Other users may view the denylist as a 1710 potential for exploitation and overreach by the stablecoin managers. 1711
7.2.2. Managing Organization Dissolution 1712
There are many reasons why an organization may stop supporting a project, including financial, 1713 legal, or ethical concerns. The reason is typically not as important as the repercussions. With 1714 systems such as stablecoins, the managing organization may dissolve and step away from the 1715 project, but the project itself may live on without them, albeit in an unmanaged state. 1716
While in an unmanaged state, the system may slowly destabilize, and users may lose trust in the 1717 unmanaged system. Users who exit quickly would be the most likely to suffer minimal losses. 1718 Users who delay in exiting might have heavy losses. The stablecoin will not be able to handle 1719 defects or upgrade itself. It may be more likely that vulnerabilities will be discovered and 1720 exploited. Even though the smart contract systems may still be running and semi-functional, the 1721 system eventually stagnates, and users leave. 1722
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
38
If the smart contracts were designed to be fully autonomous, it is theoretically possible that the 1723 stablecoin could maintain its peg without human management. However, such systems are 1724 usually algorithmic-based and keep their value through continued user confidence. Without a 1725 managing entity, user confidence would likely be lost, the companion volatile coin would lose 1726 value, and the stablecoin would subsequently fail. 1727
7.2.3. Mass User Departure 1728
Typically, in response to some incident, users of a stablecoin may decide to leave en masse. Like 1729 a traditional bank run, users will attempt to withdraw whatever money they are able to from the 1730 system, thus weakening the system even further. Stablecoins that maintain full reserves may see 1731 their price peg fail as they may not be able to quickly produce enough reserve funds to cover 1732 withdrawals. However, this would be a temporary problem if they have maintained full 1733 collateralization. 1734
With coins that do maintain partial collateral, a mass user departure can lower the pegged price 1735 down to the level of partial reserves. For example, a stablecoin pegged to the dollar with 75 % 1736 collateralization might see its value drop to $0.75. 1737
For algorithmic coins, a mass user departure can be devastating as these coins do not maintain 1738 collateral (in the normal form) and rely on continuous investor interest in the system to raise 1739 collateral as needed. Such coins can collapse as the value of the volatile companion coin (used as 1740 collateral) drops to zero. Without the companion coin as collateral, the algorithmic stablecoin 1741 loses value, possible zeroing out. This results in a complete collapse of the stablecoin system and 1742 an absolute loss of trust by the users. This was recently seen in the 2022 collapse of TerraUSD 1743 after it lost its peg [30]. This event was significant beyond the $60 billion investor loses [17] as 1744 trust in the overall ecosystem of algorithmic stablecoins was severely damaged. 1745
7.2.4. Rug Pulls 1746
A rug pull is when a cryptocurrency project manager hypes up their project via social media and 1747 marketing, obtains many new users, and then absconds with the deposited funds and abandons 1748 the project, leaving the users with nothing. Rug pulls can occur with stablecoins, obviously 1749 resulting in a total loss of trust for the stablecoin but also impacting overall trust in crypto 1750 systems. 1751
There are several methods with which a rug pull can be achieved: 1752
If the reserve assets for the stablecoin are outside of any blockchain system, the stablecoin 1753 manager could potentially withdraw them and leave, preventing users from redeeming their 1754 stablecoin. 1755
If the reserve assets for the stablecoin are held within a smart contract, the stablecoin manager 1756 may have obscure or obfuscated functions that allow them to withdraw the reserve. 1757
For completely smart contract-based stablecoins in which the reserves are held by the contract, 1758 there are mitigations that can help prevent rug pulls. The smart contract should be written to 1759 explicitly prevent the manager from withdrawing the reserves, and there should be a process in 1760 place to evaluate smart contract code updates to ensure that this functionality is not added later. 1761 There should not be an arbitrary code update mechanism that can update the functionality of the 1762
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
39
smart contract. Additionally, independent third-party audits should be used to evaluate the smart 1763 contracts updates prior to deployment to help mitigate the introduction of exploits and 1764 unintended functionality. 1765
1766
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
40
Exchanges and Fund Movement 1767
This section discusses how centralized and decentralized cryptocurrency exchanges work from a 1768 technical perspective and how stablecoins can be transferred between different non-interoperable 1769 blockchains. 1770
Centralized Exchanges 1771
CeFi exchanges resemble a combination of a brokerage firm and a stock market exchange that 1772 deals only in cryptocurrencies. Users can create custodial accounts on CeFi exchanges just like 1773 they can with brokerage firms (often only after providing identity-proofing information). Each 1774 account may have two sub accounts that operate differently: one for fiat currency and one for 1775 cryptocurrency. Each fiat currency account acts like a typical cash account with a brokerage 1776 firm. The exchange is the custodian (i.e., they possess the currency) and uses an internal database 1777 to record the level of currency in each user account. 1778
Each cryptocurrency account has a private/public keypair like a typical account created with a 1779 cryptocurrency wallet. However, in this case, the exchange holds the private key and only 1780 provides the users with their public key/account number. Using this information, a user can 1781 transfer cryptocurrency into their account but not out of it. To transfer funds out of it (e.g., to a 1782 wallet account that the user controls, to an account on another exchange, or to make a direct 1783 payment), the user authenticates to the exchange (e.g., using a multi-factor authentication 1784 approach) and requests that the exchange initiate the transfer with the user’s private key. 1785
Users can trade the fiat currency and cryptocurrency in their accounts on the exchange for other 1786 cryptocurrencies (similar to using a stock market exchange). The exchange keeps an “order 1787 book” [31] that shows the active buy and sell orders of the users on the exchange. These orders 1788 contain the price at which the buyers and sellers are willing to trade and the quantity of coin to 1789 be traded. This constantly changing information feed dynamically sets the price. The market is 1790 run continuously as, unlike many traditional exchanges, the exchanges are usually always 1791 operational and never close. 1792
On the back end, several architectures are possible. An exchange could centralize all user 1793 cryptocurrencies into a single custodial account and track how many coins are virtually in each 1794 user account with an internal database. This eliminates the need for blockchain transactions and 1795 associated gas fees for transactions between customers of the exchange. However, this 1796 architecture has a significant disadvantage as user transfers out of the exchange would require 1797 two transactions: one that moves coins from the exchange’s custodial account to the user’s 1798 account and one that processes the user’s transfer request. This two-transaction process would be 1799 necessary so that the source of the user’s requested transfer could be shown on the blockchain as 1800 being from the correct user account (assuming that is a desired feature). To eliminate this double 1801 transfer process, an exchange could keep coins in various user accounts rather than a central 1802 custodial account. This approach also has the advantage of enabling users to check their balances 1803 through direct inspection of the blockchain. However, all transfers of coins (even between users 1804 of the same exchange) would then necessitate transactions on the blockchain, consuming gas. A 1805 hybrid approach is possible in which an exchange uses both a centralized custodial account and 1806 also keeps some funds in the user accounts. This might enable an exchange to minimize 1807 blockchain gas fees while adding additional accounting complexity and possibly user confusion. 1808
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
41
Decentralized Exchanges 1809
A DeFi exchange (commonly referred to as a DEX) is a set of contracts that implement a 1810 cryptocurrency exchange that enables the conversion of assets between cryptocurrencies. Since it 1811 is smart contract-based, it does not handle fiat currencies. Users must already own 1812 cryptocurrency in order to use a decentralized exchange, which they can obtain from a CeFi 1813 exchange. 1814
The DeFi exchange does not act as a custodian of user assets. The cryptocurrency owned by 1815 users stays within the user accounts, and the users – not the exchange – hold the private key. The 1816 advantage of this architecture is that users of DeFi exchanges do not need to trust a third party to 1817 act as a custodian of their funds. However, this does not make DeFi exchanges immune from 1818 security issues (see Section 5). 1819
Unlike centralized exchanges and non-blockchain stock exchanges, decentralized exchanges do 1820 not connect buyers and sellers through the maintenance of an order book. Instead, users make all 1821 trades directly with the exchange’s smart contracts. More specifically, a user makes a trade with 1822 something called a liquidity pool. 1823
8.2.1. Liquidity Pools and Yield Farming 1824
A liquidity pool is a smart contract that maintains a pool of two or more cryptocurrencies and 1825 enables users to trade between them. The user provides one of the supported coins, and the smart 1826 contract returns some amount of the other coin, minus a transaction fee. The liquidity pool will 1827 likely not run out of one of the coins because the exchange rate will change dynamically so that 1828 the scarcer coins are always more expensive (and become increasingly more expensive as the 1829 coin stock is depleted). 1830
This capability is only possible if the liquidity pool always maintains stores of both 1831 cryptocurrencies. To accomplish this, the liquidity pool needs investments by users in order to 1832 function; this type of user investment is referred to as “yield farming.” Users stake both coins at 1833 the same time (in proportions dictated by the exchange rate) with the smart contract. This staking 1834 is especially important when a liquidity pool is being stood up in order for it to have sufficient 1835 funds to provide its service. Users can usually withdraw their staked funds at any time. Excessive 1836 yield farmer withdrawals could inhibit the liquidity pool’s ability to perform exchanges. Users 1837 are motivated to leave their funds invested with the liquidity pool since they receive a portion of 1838 the transaction fees. The amount they receive is proportional to the percentage of invested funds 1839 that they have invested. This means that as more people invest over time, each investor receives 1840 a lower percentage of the transaction fees for their staked funds. As investors withdraw staked 1841 funds, each remaining investor receives a greater percentage of the transaction fees. 1842
8.2.2. Automated Market Maker Equations 1843
An automated market maker (AMM) equation determines the current exchange rate given the 1844 changing demand for different coins [https://arxiv.org/abs/2009.01676]. The constant product 1845 AMM is often used for DeFi exchanges (e.g., Uniswap [https://uniswap.org/whitepaper.pdf]). 1846
Assume that a liquidity pool offers to exchange cryptocurrency A and B. Let N(x) be a function 1847 that indicates the number of coins of type x held by the smart contract. The constant product 1848
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
42
AMM equation simply enforces that N(A)*N(B)=k, where k is a constant. If a user deposits n 1849 coins of cryptocurrency A, the liquidity pool will provide the user m coins of cryptocurrency B 1850 in exchange. m is calculated with the equation (N(A)+n)*(N(B)-m)=k. All terms are known 1851 except for m. This simplifies to m=N(B)-k/(N(A)+n). As N(B) becomes smaller through users 1852 trading A for B, the user will receive fewer B coins for the same number of A coins. This 1853 function is not linear with the exchange rate increasing rapidly at both extremes (the liquidity 1854 pool store of A being low and the store of B being low). This property helps to ensure that the 1855 liquidity pool always has some of both coins and is available to make exchanges. 1856
8.2.3. Liquidity Pool Security Concerns 1857
• Rug Pulls 1858
Liquidity pools may be subject to a “rug pull” attack, in which the owner of the liquidity 1859 pool simply transfers all of the user-invested staked coins to a personally owned account. 1860 This shuts down the liquidity pool, and the funds are irrecoverably transferred to a 1861 pseudonymous account. The smart contract might allow the owner such permissions, 1862 enabling an overt rug pull. This could be an obvious transfer feature or some more subtle 1863 permission for the smart contract owner that might not be noticed. For example, the 1864 ability for the owner to upgrade the smart contract could enable the owner to grant 1865 themselves this permission in a future version of the smart contract. Alternatively, the 1866 owner may have embedded a vulnerability into the smart contract code to enable a rug 1867 pull that appears like a hack (with the risk, of course, that someone else discovers the 1868 vulnerability prior to the rug pull being executed). 1869
• Transfer Vulnerabilities 1870
A liquidity pool smart contract may also simply have a vulnerability that exists by 1871 accident. A hacker can then inspect the publicly posted smart contract code on the 1872 blockchain, find the vulnerability, and utilize it to drain the staked funds. In such cases, it 1873 may not be clear whether or not the owner was involved in the attack. 1874
• Flash Loan Attacks 1875
Flash loans are loans where the customer withdraws the borrowed funds and repays them 1876 within the same blockchain block (plus a transaction fee) [32]. If the funds are not repaid, 1877 the transactions are reverted (not executed) because the repayment condition has not been 1878 met. They are, thus, risk-free for the borrower but of zero duration. The lender does not 1879 suffer from any default risk (e.g., borrower does not repay) or liquidity risk (e.g., running 1880 out of funds to borrow). The loans can be used for arbitrage trading where the customer 1881 attempts to profit from price inconsistencies in multiple DeFi exchanges. They can also 1882 be misused to execute flash loan attacks. 1883
In a flash loan attack, the attacker borrows a large amount and uses it to manipulate 1884 prices in order to make a gain at the expense of other users (essentially stealing coins) 1885 [33] [34]. For example, an attacker could flash loan borrow a large amount of coin A and 1886 then swap it for coin B on a DeFi exchange. This would activate the AMM equation 1887 (discussed in Section 8.2.2), lower the price of coin A, and raise the price of coin B. 1888 Given that flash loan borrowers can borrow very large amounts, the exchange rates can 1889 be significantly manipulated. Then the attacker deposits coin B as collateral with a DeFi 1890
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
43
lender and borrows coin A. Since the lender uses the exchange rate of the DeFi exchange 1891 to determine how much of coin B can be borrowed (enforcing over-collateralization; see 1892 section
4.2), the attacker is able to borrow much more of coin A than they provided as 1893 collateral with coin B (using the actual non-manipulated exchange rate). The attacker 1894 uses the borrowed coin A to pay off the flash loan and pockets the rest of the borrowed 1895 coins. The lender is never repaid, does not have enough collateral from the attacker to 1896 cover the loan (once the exchange rates readjust to the true rate through arbitrage), and 1897 loses funds. Note that this attack worked because the DeFi lender used the DeFi exchange 1898 as its sole price oracle. 1899
Other more complicated types of flash loan attacks that take advantage of vulnerabilities 1900 in smart contracts (e.g., re-entrance attacks) exist. 1901
• Automated Money Market Attacks 1902
The miners of blockchain blocks can take advantage of liquidity pools using an AMM 1903 equation. The transaction pool of transactions waiting to be placed on the blockchain is 1904 public. Traders can attempt to place buy and sell orders before and after a large DeFi 1905 transaction to take advantage of the AMM changing the exchange rate. Blockchain 1906 miners can order the transactions in a block that they are publishing to benefit from this 1907 pre-knowledge of the exchange rate price movement. This is called “miner extractable 1908 value” [42]. 1909
Cross Chain Bridges 1910
Since many stablecoins are simultaneously instantiated on multiple blockchains, it is important 1911 for users be able to transfer coins between blockchains. This is accomplished through cross-chain 1912 bridges [35]. These bridges are implemented by CeFi exchanges and by swapping services. The 1913 concept is very simple. A service buys a quantity of stablecoins on two blockchains. When a user 1914 wants to transfer coins from one blockchain to another, the user sends coins to the service on one 1915 blockchain, and the service sends the user’s account an equal number of coins on the other 1916 blockchain (likely minus a transaction fee). 1917
If the service is a CeFi exchange, the exchange may be able to handle the transaction within their 1918 internal database (with no actual blockchain transactions happening). The CeFi exchange already 1919 owns the stablecoins on both blockchains and might just record which coins from each 1920 blockchain are allocated to which users. Alternatively, the exchange could initiate actual 1921 blockchain transfers and keep the coins in the user accounts. 1922
With a swapping service, the user transfers coins to the service’s account on one blockchain 1923 (using a normal blockchain transaction). Then, the service’s account on the other blockchain 1924 transfers coins to the user’s account on the other blockchain. A single cross-chain transfer then 1925 takes two blockchain transactions – one on each of the two blockchains. 1926
Both types of services can potentially become imbalanced and own too many of a stablecoin on 1927 one blockchain and too little on another. This can be remediated by selling stablecoins on one 1928 blockchain for fiat currency and then using that fiat currency to purchase the same stablecoin on 1929 the other blockchain. This process can take time and involve additional expense, which is why 1930 cross-chain bridges are offered to users. 1931
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
44
An alternative for very large transfers is for the service to work with the stablecoin owner. Using 1932 this approach, the service sends a large quantity of stablecoins to the stablecoin smart contract on 1933 one blockchain. These stablecoins are burned (i.e., destroyed). The stablecoin owner then has the 1934 stablecoin smart contract on the other blockchain mint the same number of stablecoins and send 1935 them to the service’s account on the other blockchain. 1936
While not available at the time of the writing of this publication, research is being performed to 1937 perform these transfers without needing to trust a third-party swapping service or exchange [35]. 1938 This would move stablecoin inter-blockchain swaps into the decentralized finance (DeFi) space 1939 from the current centralized finance (CeFi) space. In addition to possibly removing third-party 1940 involvement, such a move might limit the ability of regulators to regulate such transfers 1941 (depending on the implementation). 1942
1943
NIST IR 8408 ipd (Initial Public Draft) Stablecoin Technology and
October 2022 Security Considerations
45
Conclusion 1944
Stablecoin architectures can be understood and explained using the descriptive definition in this 1945 document. The provided “properties” highlight areas of commonality among most stablecoins, 1946 while the provided “characteristics” highlight distinctions between the various architectures. The 1947 stablecoins all behave similarly from the perspective of the user who possesses and trades them. 1948 However, they are very different when evaluating the differing architectures. This publication 1949 also provided a taxonomy of stablecoin types, which describe commonly used approaches. This 1950 taxonomic discussion demonstrates how groups of settings of characteristics work together to 1951 form different architectures. 1952
This security analysis found that two stablecoins that function almost identically in third-party 1953 markets and enable the buying and selling of goods with coins at a pegged price can have vastly 1954 different risk profiles. Security, stability, and trust issues vary between architectures, although 1955 there are common concerns with all of them. CeFi architectures can be more vulnerable to trust 1956 issues due to a greater reliance on human trustworthiness, while DeFi can be more vulnerable to 1957 security issues due to increasing smart contract code complexity and critical functionality. When 1958 all is well, they all function almost identically from the point of view of a consumer trading with 1959 them. When there are security, trust, or stability issues, stablecoins may be stolen, lose value, or 1960 completely fail. 1961
Lastly, this paper focused on technical analyses of the architectures rather than financial 1962 modeling analyses. That said, referenced financial analyses show that the algorithmic non-1963 collateralized coins and partially collateralized coins have increased challenges in maintaining 1964 their price

Leave a Reply





Verified by MonsterInsights