Can you create order from chaos? Stability from volatility?
Previously, when talking about achieving stability for stablecoins, I have primarily discussed changing supply in response to changes in demand (or more specifically, in response to your stability measurement, whatever that is). But there are other frameworks that can help in stablecoin design. I describe some interesting things we can do with simple risk allocation.
Main result: We can create a protocol that takes in any volatile asset and spits out fungible stablecoins along with super-volatile (but still fungible) volatility coins.
To start, let’s talk about a few basic concepts.
Expected Value and Volatility
Imagine you have a volatile asset, A, whose price is currently $10. In the next period, the price can either go up $1, down $1, or stay the same (with equal probability). The expected value of A after one period is still $10, calculated as:
Now let’s define a volatility function, V(A), as the expected value of the difference between the value of A now and period from now. Remember that the value of A can either go up one, stay the same, or go down one. So the expected value of the difference is:
So how can we reduce the volatility, V, without cheating by changing the expected value, E? One method is diversification, which we will leave to the appendix, and another method is risk allocation.
Risk Allocation
Diversification involves taking two (or more) independent assets and combining them into a single product. Risk allocation involves taking a single asset and breaking it down into multiple pieces with different risk profiles. These two concepts were famously combined to create the mortgage backed securities that contributed to the financial crisis of 2007–2008.
Let’s take a look at a simple example. Imagine that Alice and Bob each put in one A token into the box. But Alice is risk averse and Bob likes to gamble. So they agree to the following arrangement: Alice gets the right to take $10 from the box and Bob gets the right to the rest.
Alice is going to get $10 no matter what so her expected value remains $10. But Bob could have three different outcomes. The three possible values in the box are $18 (of which he gets $8), $20 ($10), and $22 ($12). His expected value is:
So his overall expected value hasn’t changed. But Alice has 0 volatility, and Bob’s is given by:
So their expected values didn’t change, but Bob took on all of Alice’s volatility.
Even More Volatility
Of course, our example was pretty contrived. Asset prices aren’t limited to going up or down by 1. So what happens if we let the price range anywhere from 0 to 20 (i.e., 21 different possible outcomes instead of 3)?
The expected value doesn’t change because the price can go up by the same amount that it can go down. However, the volatility of A over one period becomes:
Intuitively, this means that on average we expect to either gain or lose about $5. We just don’t know which.
We also run into the problem that if Alice and Bob both put one A token into the box like last time, we aren’t guaranteed to have at least $10 in the box after one period. The arrangement has to be modified a little. So let’s say that Alice get’s to take up to $10 from the box, and then Bob gets to take the rest.
This means that we haven’t completely eliminated Alice’s volatility. If the price of A goes below $5, there will be less than $10 in the box. This isn’t really a fair deal for her, as her expected value is now:
But her volatility has gone from $5.24 to:
Again, the volatility has gone away, it has just been passed from Alice to Bob. Maybe Alice values the reduction in volatility to make the deal, or maybe we could increase the amount she can take before Bob takes the rest. If we allow Alice to take up to $12, her expected value would go back up to $10.
Stablecoins and Volatility tokens
We have shown that we can move a lot of volatility from one party to another, but can we remove all of it? If so, we can take a volatile asset and split it into one completely stable asset (i.e., a stablecoin) and one really volatile asset (i.e., a volatile token). The nice thing about the stablecoins is that they always represents a claim on $1, so they are fungible.
We can make the volatility of the stablecoin arbitrarily low simply by reducing the amount of value put into stablecoins compared to volatility tokens. If Alice takes $10, there is a 76% chance she will get the whole amount. If she agreed to only take $2, there would be a 95% chance that she would get the agreed upon amount.
But arbitrarily low isn’t zero. Can we do better?
Yes, it turns out we can, if we use a little trick. Suppose Alice gets to take $10 out of the box and that Bob gets the rest on the following condition: if the price of A ever goes down by 20% or more, they will renegotiate their deal based on the current price to ensure Alice can still safely take out $10. Specifically, Bob must put in more assets so that the value in the box is get’s back up to $20.
Again, they each put in one A token worth $10. In return, Alice gets 10 stablecoins, S. Each stablecoin entitles her to take out $1 worth of A from the box. Bob gets 10 volatile tokens, U, that entitle him to take out the remaining tokens. Specifically, each U token entitles him to take an amount of A tokens equal in value to:
where P is the current price of A and P_0 is the initial price, 10. Because Bob’s tokens need to remember the initial price, P_0, they are not fungible.
Also, if the price of A goes down to 20% (i.e., to $8), we have to readjust to make sure we still have $20 in the box. At a price of $8, the box currently holds $16 in value, so Bob has to put in an additional $4 or .5A. If Bob refuses to put in the additional capital we can just open the box, give Alice $10 and Bob $6 and be done with it.
Vaults, Tokens, Coins
Mathematically, the combination of the box, the stablecoins, and the volatility tokens is really just another way to describe the vaults traditionally used to mint stablecoins in protocols like Maker.
The vault is like the box, and the stablecoins are just the stablecoins but what is the analog of the volatility tokens? They represent the right to take excess collateral from a vault.
The exercise highlights two things:
- Stablecoin vaults can be implemented as tradeable tokens, and
- Stablecoin vaults are highly volatile assets
Instead of a vault associated with a particular address, you just have a protocol that takes in one asset A and spits out two other tokens, S and U that add up to the same value that was put in.
Making vaults into tokens is a nice result, but can we do better? Can we transform non-fungible volatility tokens into fungible volatility coins? Fungible coins are nice because they can be exchanged and priced more easily, but they have the obvious limitation that they can’t carry coin-specific information.
To serve their purpose, our volatility tokens have to carry some information about the original price when they were minted. To make them fungible, we have to eliminate the need to carry that information. One way to do this is to have multiple volatility tokens available at incremental prices, say, every $2.
So what happens if the tokens are created when the price of A isn’t exactly at the current price basis? We just make them mint at a lower effective price (i.e., so the volatility token starts off with more value as if there were an immediate price jump.
For example, imagine the price of A is $9. If someone put in two A tokens then would previously get 9 stablecoins and 9 volatility tokens with a basis of $9. The value of each volatility token would be:
So they put in $18 in value and get back $18 in value. However, we now pretend that the price of A is $8. So they only get 8 stablecoins and 8 volatility tokens with a basis of $8. However, each of the volatility tokens now has a value given by:
Since we have 8 stablecoins and 8 volatility coins the total value is:
This method allows us to transition from an infinite number of different non-fungible tokens to a finite number of fungible token classes (i.e., one for each cost basis increment). But this could lead to an unbounded number of different fungible token classes, which isn’t great either.
Symmetric Conversion
However, it is possible to avoid the fate of having a huge number of fungible token classes floating around. To do this, remember that whenever the price got too low, we had to convert the volatility tokens to a lower collateral asset price basis and add more collateral. To limit the number of token classes, we can also encourage conversions to a higher cost basis as the price goes up.
That is, if the price goes down to much, you encourage people to convert their tokens to a lower cost basis by adding collateral and if the price goes up too much you can encourage them to convert their tokens to a higher cost basis and extract collateral.
Depending on how strict your conversion incentives, you may only need to keep track of a single active volatile token class. Voila! We have created fungible volatility coins (vaultcoins?) in addition to fungible stablecoins from an arbitrary asset! Ordo ab Chao.
Appendix
Diversification
Diversification isn’t important to this particular post, but it is worth running through an example of how it works. Imagine we have another coin, B, that is exactly like A, but whose price moves independently of A. So let’s say one person puts A in a box and another person puts B in the box, and they agree to split the total value after one period. There are 9 possible results (remember that the formula for each entry is A + B divided by 2):
The expected value is given by:
This makes sense, since E(A) = 10 and E(B) = 10, adding them together and then dividing by two should still be 10.
But V is given by:
So we have reduced our volatility by more than half simply by combining two assets. This can be a useful method of reducing volatility. However, finding two assets whose values are independent is not so easy, especially in the crypto space.
Stability Measurement
In the discussion of stablecoins and volatility coins above, I measured the asset prices in dollars ($) for convenience. However, the unit of account is arbitrary. The icewater protocol has it’s own unit of account, H2O (Ħ). We can measure the price of A in Ħ just as well as $.
