The Stablecoin Vulnerability that Needs More Attention
By: Daanish Khazi
Tags: Oracle, Ethereum, Cryptocurrency, Bitcoin, Blockchain

The Stablecoin Vulnerability that Needs More Attention

It’s the Oracle Problem

Stablecoin Landscape

Stablecoins offer a simple yet compelling value prop: digital currencies without price volatility. There are a number of projects attempting to create price-stable currencies, and each varies in scope and design. For the most part, the goal is to be pegged to or have parity with a fiat currency like the USD. Some projects consider being pegged to the consumer price index (CPI) itself as a long term goal.

Ignoring fiat-collateralized stablecoins (Tether, TrueUSD, etc.), there are two design patterns currently being leveraged to produce stable cryptocurrencies: crypto-collateralized and seigniorage shares.

In the first, other crypto-assets serve as collateral, and they are usually over-collateralized to compensate for the volatility in crypto markets. MakerDAO utilizes this model by allowing anyone to generate a stablecoin (Dai) from Collateralized Debt Positions (CDPs) that are made up of other crypto-assets (only ETH for now). Maker has a number of mechanisms in place to ensure the stability of Dai, including protocol governance by MKR holders and automated liquidations of risky CDPs (sort of like a margin call) that are worth reading about in their white paper.

For stablecoins that subscribe to the seigniorage shares model, the coin is not backed by anything. Instead, an elastic coin supply, that expands at high prices by minting more coins and contracts at lower prices by selling a sort of zero coupon bond in exchange for burning coins, facilitates price stability. There is a good amount of skepticism as to whether or not this model is sustainable, and debate about whether it is susceptible to black swan events and Soros attacks. Basis and Carbon are two projects that use the seigniorage shares model. Overall, the debate is largely centered around whether or not they make economic sense.

There are many great resources out there that give an overview of the landscape and the tradeoffs associated with each design choice.

The Oracle Problem

Regardless of whether or not either model makes economic sense, there is a bigger, more persistent vulnerability lurking. How do we know when to do what? That is, changes in the protocol have to be precipitated by changes in the price of the currency. If a Basis coin is trading at $1.05, the protocol mints tokens to push the price downward. But the more primary question is, how do they know what the price is? Of course, this question is not peculiar to stablecoins. The matter of bringing off-chain data on-chain via an oracle is something that should trouble any blockchain project that attempts to interface with the real world. The reason this problem is a little more important for stablecoins is that it opens up an attack vector for speculators. For example, if I can reliably take a short position on a stablecoin that is actually trading at $1, and “confuse” the blockchain into thinking that it is trading at $1.05 by attacking the oracle, the protocol will automatically mint more tokens and give me guaranteed profit at the expense of every other coin holder. The exact nature of such an attack would depend on how often the protocol makes such decisions, etc., but the vector is always open.

Current Oracle Solutions

Carbon measures its exchange rate via a decentralized Schelling point scheme. Every 24 hours, nodes submit bids, where each bid is weighted by staked collateral, and then the protocol tallies the votes to get a weighted average. Afterwards, any node that submitted a bid outside the 25th and 75th percentiles gets a portion of their collateral slashed and the nodes within the range receive a normal distribution of the loser’s balances.

This kind of model is also echoed as one of the three options in the Basis white paper (except it runs on a 5 minute time scale there), and it is the most decentralized of the three. One of the other options is a single trusted source, and the other is semi-decentralized feed, which is also fairly similar except coin holders “elect” a few delegates in a DPoS-esque manner to determine the median price, and these delegates can be voted off if determined to be malicious. Ultimately, I think this delegated system exhibits similar incentives except instead of just losing stake the delegates also risk their reputaiton.

Maker, which is live, uses a trusted third party / semi-decentralized model and takes the median of a number of different feeds, as submitted by price feed operators. This still represents a huge centralization risk, and “if MKR holders are also CDP holders,” or “Dai holders,” they have substantial incentive to manipulate the feed.

Vulnerabilities of the Decentralized Schelling Point Scheme

It’s obvious that the more centralized oracles could work very well with trusted (read: like really trusted) third parties, but there is always a risk when financial incentives are present. So, in the spirit of decentralization, lets take a better look at this Schelling point scheme model. Why does it work? The argument is that it is much harder to coordinate on a lie than on a truth. If you look at the image below and asked people to choose a square, and also told them that they would receive a reward if they choose the same square as the majority of other people asked the same question, it’s obvious that most people would choose the red square. It’s not that the red square is the “truth” per se, but it stands out, as a focal point. In cases where there is a true value, the true value will stand out from the false values. Thus, if the price of the coin is $1.03, the Schelling point will be $1.03, and most bidders, wanting to get compensated, will coordinate around this price rather than some other arbitrary price. In this way, the Schelling point scheme seems like it should work. But it’s not attack proof.

Coordination game example. Source: By Superbobmanguy — Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=64769370

In this attack, a reliable briber can adjust the payoff matrix as shown below. The payoff matrix gives two options, 0 and 1, and is binary instead of granular like the price, but the incentives would be the same if you generalized the game. In the original payoff matrix, you can choose between 0 and 1 and if you are in the majority you get a reward of p. However, if a briber says they will pay you p+epsilon if you vote 1 and aren’t in the majority and nothing if you are in the majority, then you now have a dominant strategy to vote 1 no matter what you believe. Furthermore, since this is now the dominant strategy, everyone will vote for 1, and the attacker won’t have to pay you anything. So, at essentially 0 cost, the attacker is able to shift people away from the Schelling point to some other value. Still, this attack seems difficult to pull off logistically and there are a number of possible (albeit incomplete) solutions that Vitalik discusses (read more: here).

Original Payoff Matrix

Payoff Matrix with Briber

2. Vote Meming

This happens when the bidders become lazy. Instead of coordinating around a focal point, they coordinate around something simple. Members of the community might realize that bidding $1 always gets you within the 25–75 percentile range and simply always bid $1 to make a guaranteed profit, leading to a rather non-informative oracle.

3. 51% Attack

This attack is simple. Just buy enough tokens to dictate the price. In designing consensus mechanisms, many people assume a certain threshold of honest participants. Bitcoin Gold, Monacoin, and this website, https://www.crypto51.app/, tell a very different story. Furthermore, since each network is secured by its own token, Basis by Basis holders and Carbon by Carbon holders, the amount that could be staked for collateral is always a subset of the total market cap since the rest of the tokens should ideally be used for other purposes such as payments. Furthermore, given the cumbersomeness of the user experience (submit a bid every day or every 5 minutes or whatever), one cannot expect that voter turnout be particularly high. Thus, the size of the network will always be a tiny subset of the coin itself, making the incentive to attack all the more enticing. This is probably the most damning critique of decentralized schemes: they are too small to be secure. If we take blockchain security as an analogy, it’s clear that Bitcoin’s security owes a lot to its sheer size.

Conclusion

The oracle problem is a big bottleneck for any blockchain project that needs to get real word information onto the blockchain to function. In applications where external financial incentives can conflict with the game theoretic assumptions of the oracle (stablecoins, derivatives markets, etc.), it is absolutely essential that the oracle problem is solved before these ventures are deployed. Current centralized solutions demand too much trust in individuals and third parties, and current decentralized solutions demand too much trust in protocol security. Semi-decentralized solutions such as MakerDAO’s current oracle and Basis’s delegated oracle solution require you to trust the third party and the protocol security, albeit a little less for both. As such, the hard problem of oracles remains an open one.

Please feel free to respond with any questions, comments or criticisms on Twitter: https://twitter.com/daanish_khazi