Still on that DEFI kick.
One of the best ways to add value to a DEFI coin is to create a derivative stable coin that uses the main token as collateral for the derivative. I have done a lot of research on these things and I know many of the ins and outs of the system. Unfortunately, while creating an algorithmic stable coin brings very bountiful rewards to the network, that high reward is littered with high risk.
All of the implied risks of collateralized stable coins reside within the collateral itself. These CDPs (collateralized debt position) smart-contracts are the crux of the entire system.
But wait, I thought you said DEFI tokens themselves should be stable coins... why would we need two stable coins?
Ah, yes, good catch. There is a big difference between an DEFI stable coin that manipulates price with yields and inflation vs an algorithmic stable coin based on CDP contracts. The range of acceptable volatility of the DEFI token is much much higher than the CDP token.
If I were to guess I'd say that the difference between the two would be like a factor of ten. So if we were trying to peg the CDP token inside a 2% range ($0.98-$1.02) then an acceptable range for the DEFI token would be more like 20% ($0.80-$1.20).
In addition, a CDP token can not experience supply-shock, while a DEFI token that's supposed to be stable absolutely can. To bring down the price of a DEFI token we have to reduce yield in the correct areas to incentivize farmers to dump their tokens on the market and increase the supply to account for increased demand. However, if we keep decreasing yield and price keeps going up regardless of the bad yields, this results in supply-shock, and might even be a money attack (big whale trying to scoop up all the tokens for cheap).
When a supply shock happens on a DEFI token, we have to go back into price discovery mode, jack up inflation across the board to the moon, and then pump/dump the token on purpose to mitigate the money attack (be it legitimate demand or a bad-actor). A new price point will have to be discovered in this process, and the network goes back to trying to stabilize that price point with 20% variance in either direction.
This problem doesn't happen with CDP tokens, because CDP tokens have theoretical infinite supply due to the collateral itself having theoretical infinite value. If more supply is needed, they will simply be printed "out of thin air" aka using more collateral from the DEFI token itself. In fact, high demand for the CDP token can create the supply-shock scenario of the DEFI token described above because it takes x2 to x3 over-collateralization to mint them on average.
So what is the attack vector of CDP?
As the title implies: Oracles. The problem with CDPs is that the network can not divine the USD value of the collateral from within the system, and it needs to trust a price feed coming in from the outside in order to maintain the CDP token's peg to the dollar.
Think about it:
How do we know how much Bitcoin is worth? The only way to know how much Bitcoin is worth is to go to a centralized exchange and see what people are paying for it. That is literally the only way to do it: to trust centralized exchange API. As you can imagine this attack vector is a huge one that most crypto purists would tell you is a recipe for disaster, and they are probably correct on a long enough timeline when the stakes become too high for failure. "Too big to fail," comes to mind.
You can't use a DEX to find this number.
There are ZERO DEXs with a BTC/USD pair. You can easily find a BTC/USDT pair or BTC/USDC pair or whatever else, but then you are not only trusting the external DEX API but also that the pegged coin in question is actually pegged to USD. That's even worse than trusting a handful of centralized exchange APIs and averaging the data.
Uh... I still don't get it.
Yeah I haven't even explained how this actually works yet. lol... it's pretty complicated.
So if I put $2000 worth of DEFI token into a CDP and extract 1000 stable-coins out of it, the network needs to make sure to liquidate my collateral if it becomes worth less than the 1000 stable-coins I borrowed from it. If the network doesn't accomplish this task, then bad debt is created and it's possible the entire system would collapse from systemic failure.
We can't assume that the stable-coin we built has an intrinsic value of $1 because the entire point of the system is to jump through several hoops to accomplish that goal. The only way to do it is to get information from another source that will tell us how good or bad we are doing so we can pivot accordingly.
Witnesses as Oracles: Vastly Underutilized Resource
The way Hive accomplishes these feats of strength is actually pretty interesting. Unfortunately, HBD has zero liquidity because thus far witnesses refuse to acknowledge that our internal market is almost worthless compared to an AMM upgrade with associated high yields, but that is beyond the scope of this post and has nothing to do with the mitigated attack vectors.
Attack vector #1: Price Feed
Every witness on Hive has a price feed that tells the network how much Hive is worth. We can see this price feed directly on the frontends.
https://peakd.com/me/witnesses
Most people see this variable and they don't give it a second thought, but it is a very big deal. Witness nodes can set this number to literally whatever they want, and we can see that the vast majority of witnesses report slightly different numbers, because they are all coming up with that number in a slightly different way. The fact that they all do it in a different way increases the robustness of the system and mitigates failure.
This price feed is directly responsible for how much HBD gets printed every day. If the top 20 witnesses just decided to report a Hive value of $100 per token, around 100 times more HBD would end up getting printed. Because HBD can be converted back into $1 worth of Hive, this feed can be used to dynamically alter our inflation on the fly if we so choose to use it that way.
Hive's solution to this problem of oracles is actually pretty damn solid compared to many other solutions. Who better to report information from the outside than the 20 elected representatives that secure the entire chain? In my opinion this price feed, and witnesses acting as oracles in general, is a vastly underutilized resource that we could be doing much more with, but again that topic is beyond the scope of this post.
Attack vector #2: Manipulation.
Imagine if I was using the Hive price feed to determine the value of collateral in a CDP. In this scenario I've created a second-layer (or centralized) solution that allows us to lock up our Hive and mint a derivative stable coin. So some whale comes in and locks up $200,000 Hive and mints 100k stable-coins... so far so good.
But what if someone else sees that huge CDP contract and decides they want to liquidate that position? The hard way to do this would be to dump Hive on the exchanges and get witnesses to report that the value of the collateral has gone down by 50% value and needs to be liquidated by the network immediately. The less expensive way of doing this is somehow hacking the price feed directly and simply making it look like the price has crashed when it actually hasn't.
If the system is decentralized and allows anyone to pay back the bad debt and scoop up the collateral into their own pocket, then this whale could dump Hive, liquidate the positions of everyone that falls below the requirement, steal their collateral, and then pump Hive right back up to where it was. This would be the ultimate long-squeeze manipulation and given certain situations it could be extremely financially viable.
Hive avoids manipulations like this by averaging the price feed over 3.5 days and using that number instead of the current value. This average is very important. Personally I think 3.5 days is a bit long because it makes the peg much more volatile. But again this is irrelevant, as we are talking about attack-vectors and not actual utility. Hive does a great job of mitigating the threats of having a stable coin in several ways.
Bad debt
The longer the price-feed average is, the greater the chance that bad-debt is created (IE peg breaks to downside). Many of these algorithmic stable coins think that having bad-debt on the network is like the worst thing in the world, but honestly I've seen SBD/HBD at 60 cents multiple times, and it's not nearly the boogieman that many make it out to be. I believe that sometimes bending over backwards to maintain the peg is the wrong move, and there are many other ways to stabilize these assets, especially on a high-yield DEFI token.
Exhibit A: DEFI/STABLE LP
Very rarely does a DEFI token actually list an LP in which both sides of that LP generate value for the network. If we look at CUB we see the CUB/BNB LP and the CUB/BUSD LP. This gives free value and liquidity to BNB and BUSD, even though we do not control those assets or gain any value from these listings. Of course without entrance or exit liquidity the token would be completely worthless, so we do need to have at least one exit/entry point. CUB and Polycub have two, and I'm still not sure if this is a mistake or not. It's probably fine because both these assets serve completely different purposes, but it's worth considering regardless.
The ultimate addition to these DEFI projects would be an algorithmic stable coin that replaces BUSD/USDC entirely. My vision of such a token was called SAV (short for savanna or save or savage or stable-asset-value), but again, trying to pull off such a thing on an EVM chain where there are hackers everywhere looking to exploit the price feed oracle makes it super risky.
Still, a CUB/SAV pair has massive value and would make it really easy to create price controls. Basically when yield goes up, demand for both CUB and the stable coin (that is on average 200%+ over-collateralized by CUB) goes up. Creating demand for the stable coin intrinsically creates more than double the demand for the collateral, and pairing them together in an LP like CUB/SAV theoretically creates three times the demand, x1 for CUB and x2 for SAV.
But again it all comes down to that oracle attack vector.
How does the network know when to liquidate collateral? It sounds like it should be easy, but it is not easy because bad-actors have a huge financial incentive to hack the system if they can get away with it.
Most obvious shortcut:
Simply trust a stable-coin pegged by dollars in a bank. This is something I'm starting to realize is totally viable for a small (currently centralized) project that just wants to get this thing up and running as quickly as possible while only incurring a small amount of risk.
Again, remember that creating demand for an over-collateralized derivative coin is twice as good as creating demand for the DEFI token itself, because twice as much DEFI tokens need to be locked up to create the derivative on average (often x3 times as much; we see this on MAKERDAO all the time).
Thus a pairing from the algorithmic stable coin to the bank stable coin becomes the most appropriate and highest value. In this example it would be SAV/USDC or SAV/BUSD depending on if we are talking about CUB or Polycub.
This LP pool creates a virtual oracle that I am beginning to realize is likely more secure than many of the price feed solutions out there being used today. By assuming that BUSD/USDC = $1, this itself becomes the oracle, and we can use that information to derive the USD value of every single asset in the CPD collateral basket.
So rather than needing to get the information from outside the system from some random API (basket of centralized exchanges) all the information we need lies in the ratio of SAV/USDC. We "know" that USDC = $1, so if the ratio is 98000/100000 we would then "know" that the USD value of SAV was 98 cents. With that information we could then further derive the USD value of CUB with the CUB/SAV pair and now exactly how much CUB collateral was worth in the CDPs.
Worst case scenario:
USDC falls significantly under $1 and the entire system is pricing things incorrectly. Assuming USDC crashed to 50 cents, a 1:1 ratio assumes that SAV is worth $1 when it really can only be exchanged for 50 cents. Further, a 1:1 ratio in SAV/CUB assumes collateral in the CDP is worth twice as much as it actually is. Concerning liquidation: this is the real problem. Liquidations wouldn't be happening when they should be, creating bad debt.
Or would it?
Because if SAV's value is only half, then buying back bad debt is twice as easy. Thus, overestimating the collateral by x2 in this case seems to be a wash. The collateral is being overestimated, but also the value of the debt owed back is also being overestimated.
This is much different than a system like MAKERDAO and DAI because MAKER is not a yield farming token. MAKER uses ETH as collateral, and the protocol can not print ETH, nor can they print MAKER because the system is foolishly set up to by deflationary. They do not have any liquidity pools to infer any of this information, and instead opt for some other oracle solution that I know very little about.
The real pitfall to this system is that our algo stable-coin will at-best only be as stable as the bank-collateralized coin that we choose. Considering that no algorithmic stable-coins have succeed in having more stability than the centralized ones, I actually do not see a problem with this in the short term.
The real danger of bank stable-coins is a bank run: IE the token price drops to ZERO. But again, we haven't added anymore risk then we were already incurring before, because CUB and Polycub are already paired to BUSD and USDC to begin with. If one of those crashes to zero we are fucked either way, so creating our own coin that uses this as an oracle incurs no more risk than we were already incurring. If the stable coin drops to zero, we are going to lose an entire liquidity pool no matter if we have our own stable-coin or not.
Long-term solution:
Use an oracle system that's not going to get hacked. I'm actually kind of surprised that no one has even attempted this on Hive yet, even though the price feed that the witnesses provide is actually... pretty damn solid when combined with some kind of price-average over time. But hey, I guess that's just a testament to how early in the game we are.
Also outside protocols like ChainLink are working on oracle systems, and I'm sure those are worth looking into as well (especially if we are looking for an EVM solution). That being said I'm a bit of a Hive maximalist myself so I would never be looking for a third party solution to this problem when our witnesses can already easily solve it.
CUB/LEO Missed opportunity?
One last thing to mention is the concept of having an LP in which both sides of the LP feed into the value of the underlying token/network. CUB and Polycub miss their one and only opportunity of easily doing this with a CUB/gas LP. On BSC this would be CUB/bLEO and on Polygon this would be pCUB/pLEO. These are examples of LPs that don't bleed any value out into the void of crypto and instead retain it all within the LEO ecosystem.
So why opt for bLEO/BNB and pLEO/MATIC?
Quite simply: the bridge is deemed more important than conservation of value. Replacing bLEO/BNB with bLEO/CUB adds an extra jump in the chain of moves it takes to bridge value on one network with another.
For example, when we wrap LEO into bLEO, we've have to dump it for CUB, and then dump the CUB for either BUSD or BNB. The bLEO/BNB pool removes that extra step, allowing the bLEO to be immediately dumped into BNB, which has huge liquidity pools and low slippage compared to CUB.
If we did this on Polygon as well with pLEO/pCUB, this creates a lot more hoops that need to be jumped through, from gas fees to slippage of illiquid assets to high DEX exchange fees. It all adds up. But still it is good to consider how much value we could be keeping within the system if the bridge was a lower priority. I also have a feeling that a bLEO/CUB or pLEO/pCUB LP would have quite a lot of demand, so there is that to consider as well. Just spitballing here.
Conclusion
All in all, terrible post! This one lacks focus and theory-crafts too many complex topics at once. I might have to rehash this one later and create something a little more tenable.
The main point to be made here is that the crux of all algorithmic stable coins are the liquidation targets. With CDP loans this comes in the form of liquidating collateral to buy back bad debt. On Hive it's all about how much debt we are creating and how much Hive we will mint when that debt is converted back to the main token.
In all cases these targets seem to hinge on oracles and information coming in from the outside, which is a huge attack vector. Cryptocurrency doesn't like to rely on outside sources for information, as the entire point of cryptocurrency is to create and validate ledgers that can be trusted no matter what is happening outside the system. Algorithmic stable coins, while quite valuable, increase the chance of manipulation from the outside. One more reason to hold Bitcoin as the ultimate "oh-shit" reserve.
Posted Using LeoFinance Beta
Return from Oracles: Revisiting the main attack vector of algorithmic stable coins. to edicted's Web3 Blog
