Should stablecoins be first class citizens?

MakerDAO had a bad day, this thread turned my thoughts to stablecoins: makerdao black thursday thread

Clearly a smart contract platform needs native stablecoins. Any cashflow inside the system relating to the world outside needs to be done using a stablecoin. Because of the way crypto currencies have developed, stablecoins are thought of as a secondary feature. I wonder if this is a mistake, both from a utilitarian and technical point of view.

Utility – quality of available stablecoins defines usefulness of the network

The initial thought behind bitcoin was as a replacement for fiat currencies, but it seems to be at best a niche alternative in that regard. A lot of the work around Ethereum labeled “DeFi” is an attempt to recreate existing financial instruments and markets using crypto, naturally a lot of these ventures use USD stablecoins. It is becoming obvious how important it is to have a way of representing value “outside” the system, inside the system.

Although predicting the future is difficult, we should think about how many use-cases will utilise a stablecoin rather than the native crypto asset in their final incarnation. So for example, the Ethereum network has been used extensively for fundraising via ICOs, this fund raising (in it’s embryonic form) used the native asset Ether – yet fundraisers, who’s cashflows are typically in USD, would have preferred to receive funds in a USD stablecoin. When we think through other use-cases most would be equally or better served using a stablecoin. Stablecoins of course do not need to be pegged to currencies, they can be pegged to any asset, or even a synthetic. In the end, probably very few use-cases would be best stated in terms of the native crypto asset.

If you agree with me that in 5 years smart contracts will be mainly consuming stablecoins, then the quality and selection of the stablecoins in a network becomes very important, perhaps even the primary differentiator.

At some point in the future central banks may issue their currencies in a format the blockchains can consume, however this is not presently the case, and probably won’t be the case for quite some time. Therefore stablecoins will continue to be engineered.

Desirable features

The simplest and initially most useful stablecoin is a USD token, so let’s think in terms of that. The 1st important feature is that the stablecoin maintains it’s peg, on all crypto-fiat markets 1 USDSC should trade for 1 USD. It should maintain it’s peg as close to real-time as possible, and do this consistently and in every eventuality. The 2nd important feature is that it should be as decentralised as possible, trust should be minimised, and it is undesirable that transactions in the system using the stablecoin should be subject to censorship, reversal, or some other control by legal jurisdiction. There are other features that add value, but these two seem the most important to me.

Stablecoin implementations

Broadly there are currently three types of stablecoins; fiat collateralised, crypto collateralised, algorithmic:

The most straightforward implementation is a fiat collateralised stable coin. You have a USD bank account, 1 USD goes in, 1 USDSC gets issued. Although this implementation is straightforward conceptually, it is infact fraught with difficulty and complexity; it requires lawyers, regulatory approval, constant auditing. This approach meets the 1st requirement very well in most circumstances, the peg is perfectly maintained, because a holder can redeem their token for fiat at any time. However, it requires trust that the bank account operator is honest (the audits), and a regulated bank account, which is subject to all the laws in it’s jurisdiction (lawyers, regulators). It is easy to imagine a transaction on the blockchain, or some political event, causing the bank account to be frozen; totally destroying the stablecoin.

Implementations (almost) entirely within the network avoid the regulatory problems. They still require a “touch” from the outside world, a price oracle, but that’s about it. There are two flavours:

You can collateralised the stablecoin using crypto. This is the arrangement with MakerDAO and the DAI (USD) token. This system requires oracles supply the ETH/USD price. The DAI token is created when Ether is locked in a contract (over collateralised), the Ether can be redeemed for DAI, or the Ether can be liquidated (to purchase DAI) should the price of Ether fall, in the event that contract liquidations do not cover it, the Maker token holders themselves are “liquidated”. The system is very complicated, and while it scores well on the 2nd requirement of a stablecoin, i.e. isoutside of jurisdictions, it brings the 1st requirement into question; will 1 DAI always equal 1 USD? The main issue is solvency, the value of the collateral plus the “shareholder capital” must exceed the USD obligation. It is pretty similar to a commercial bank.

The other flavour of on-chain schemes is algorithmic stablecoins, there is no collateral, a smart contract maintains the peg. If the price of the token goes over it’s peg, the smart contract mints and sells tokens into the market (thereby reducing the price). If the price of the token goes below it’s peg, the smart contract buys and removes tokens from the market (thereby increasing the price). Of course this assumes demand for the token will increase, otherwise the smart contract will be broke – another solvency issue.

One key difference between fiat collateralised and on-chain, is that the on-chain works via a feedback mechanism, which will take a certain amount of time to actualise. In fiat-collateralised, the peg is maintained by confidence that a token is redeemable for a certain amount of fiat. But the on-chain protocol’s feedback mechanism will be subject to the delays of the network, especially during high traffic periods.

More than that, the Achilles-heel of the on-chain implementations is solvency. They give us pretty much everything on the 2nd requirement (provided the oracle is sound) but we are left wondering on the 1st; will the peg hold in every situation?

Technical – maximising solvency

If the stablecoin is a secondary add-on, a “layer-two” solution, then it is as solvent as the people who have paid into it, plus the people who fronted the capital for it. This arrangement makes it decoupled from the network, which seems attractive; why should a failure in the USD stable coin fail the network? But if you accept that the utility of the network is directly related to the quality of the stablecoin, then perhaps you want to back it with the entire network.

On a fiat-crypto exchange, a sanctioned smart contract offers/bids the token at 1 USD for whatever the native crypto asset is worth, without reservation. Either the smart contract is given a massive balance at network formation, or it literally mints and burns on demand.

This system would still require an oracle, a very secure oracle, but it is much much simpler than existing layer-two solutions. There could still be an element of decoupling, for example the peg is guaranteed only while the native token is above some USD value. There could be a per transaction redemption limit. There could be a bunch of things.

I haven’t really thought it through fully. The layer-two solutions out there all seem very complex, far too complex. The fiat collateralised stuff will break on a court ruling. The on-chain layer-two solutions will suffer from insolvency or a hack because of their complexity. Obviously building a stablecoin directly into the network introduces risk. It’s only worth it if you believe a network without a USD stablecoin isn’t worth much. If you do believe that, why not back it with the entire solvency of the network?

Assuming it’s possible to somehow make this safe, I don’t think the solvency issue goes away. Issuing more consensus coins to cover the run on the bank will lead to the same liquidity crunch we saw with Maker.

I’ve been thinking more about how to fix the marketplace that Maker was running its trades in.

1 Like

Sure, even with a huge economy, the UK couldn’t maintain its ERM peg in 1992. If you are pegging to something you don’t have any control over there is always the solvency issue, it’s just to what extent you are prepared to go in backing it. Thx for the link will read.