Share Dialog

Every financial system or application comes its own set of risks. DeFi protocols are no exception and the amount of money lost through hacks, stablecoins depegging or other exploits is a good reminder of the fact that you're never 100% safe. The advantage of financial systems built on blockchains is that the blockchain standard enables a full transparency of how they operate. The issue is that this transparency element is very rarely exploited as an advantage by DeFi protocols to communicate about their risks.
In fact, I've seen very few protocol do this introspection and provide the adequate tools and pages to assess the risks involved when you deal with them. It's normal to have risks. What is not fine is not communicating transparently about these risks and having stakeholders surprised when one of these risks materialize.
How can we reasonably expect DeFi to scale beyond where it is if we're not being 100% clear and honest with the risks within DeFi systems?
Decentralized stablecoin protocols tend to be more or less structured equivalently. The risks they involve are also similar with what you see in many other protocols (lending, AMMs, …).
A risk overview of Angle is therefore a good occasion to understand the risks at stake when you play around with decentralized stablecoins and more generally with other DeFi protocols.
In an article I wrote last week, I mentioned how to analyze a balance sheet of a stablecoin protocol to get a better insight on the economical risks associated with a protocol. This however covers only one category of risks. For systems operating on blockchains, I like to distinguish three main categories:
infrastructure risks
assets risk
and design risks
Let's break this all down.
These are the risks associated to the technical stack that DeFi protocols leverage.
This is the most important risk in any blockchain system and for me the only thing that could hinder the adoption of blockchain systems at a larger scale by institutional players.
Blockchain protocols rely on smart contracts which control money. A single flaw in a smart contract could lead to all the assets to go to zero. The tricky thing with smart contract systems is that the time horizon of hackers looking for flaws to exploit is infinite. So it's not because a contract has been live for years without any exploit that it will always be safe.
Usually external audits like the ones we do at Angle reduce this risk, but there is never any risk zero. A good way to mitigate this is to multiply efforts in unit testing, fuzzing and invariant testing of the code.
It hasn't always proven to be the best proxy in the past, the more audits and tests, the smaller this risk is.
While it's often smart contracts that get hacked, it's not impossible to see a hack at the blockchain level (e.g consensus exploit). It's often taken for granted that blockchains are bullet proof but they're not and they also can be exploited.\
In the end, to quantify the exposure of a system to a blockchain hack, it all comes down to whether the protocol controls some assets on a chain. If a chain where a protocol has some assets gets hacked, the protocol may go bankrupt.
For stablecoins there is a nuance to keep in mind: there are some chains where the stablecoin may exist but where there is no native issuance. If such a chain gets hacked, it may result in a temporary loss for those who bridged their stablecoins into the chain, but not for the protocol in itself which still has enough assets to back all stablecoins in circulation.
This blockchain risk brings me to another risk common to all cross chain protocols that is the bridge risk. Bridge hacks have historically been the biggest hacks across the whole industry. When you build a cross-chain protocol around bridges you need to do it with the mindset of not asking yourself if the bridge is going to be hacked but rather when this is going to happen.
At Angle we have developed a unique security system to mitigate this risk, but the protocol would still lose a bit from a LayerZero hack for instance.
While bridges are some of the major providers for DeFi protocols, another key infrastructure provider that is a vector of risks is oracles. An oracle failure, without the proper safeguards in place, can have dramatic effects.
An oracle mistakenly reporting a price of 100$ for an asset which is in fact only worth 1$ could lead the reserves of a stablecoin protocol to be drained in a second.
The exposure of DeFi protocols to this oracle risk is then all about these safeguards. Oracle redundancy and external consistency checks of the values reported are common ways to mitigate this.
We partly covered this class of risks in my previous article, but let's still go over what assets risks refer to in the context of DeFi protocols. Here assets refers to everything that is held by the protocol to back the claims of its stakeholders.

DeFi protocols are machines that accept various assets as inputs to produce a different financial product as an output (e.g a stablecoin for stablecoin protocols).
Sometimes they're built with the assumption that the assets they control will retain certain properties at all times (like keep a price of $1), but this cannot always be true.
Let's take the case of USDC. If Circle ended up leaving with all the funds backing USDC, the protocols holding USDC would face a loss because USDC would be worthless. This counterparty risk is present in every asset managed in a centralized way.
This risk also applies to protocols managed in a decentralized way. Let's say I'm holding DAI for my protocol and Maker gets hacked, well my protocol and therefore my stakeholders will lose money out of DAI becoming worthless.
There are assets for which this counterparty risk can be seen lower. And when looking into the assets that make up a stablecoin protocol, it's important to evaluate all of them individually and look for whether they provide bankruptcy remoteness guarantees or if they come from regulated entities.
There is the quality of the assets held by DeFi protocols and their liquidity. Very often the issue is not in the quality of the assets, but in their underlying liquidity.
There are some situations in which stablecoin and lending protocols need to liquidate on the market the assets they control (because their value is decreasing). If you control assets worth $1m collateralizing a $800k loan, but you're only able to recover less than $800k when you sell the assets in the market then you end up badly collateralized with some bad debt.
It's not a problem to be exposed to less liquid assets. Where this can be problematic is if you're over exposed to these assets (too big debt ceiling) or if liquidation or loan-to-value parameters are not properly set.
Automated and parametrization based on real-time market data are ways to exactly control and adjust to the ever-evolving liquidity of the assets used as collateral.
Even without going as far as complex illiquidity issues in congested markets, a significant issue that could arise in stablecoin and more generally in all DeFi protocols is if the collateral assets are too volatile and can lose in value for some exogenous reasons.
Some protocols bear a significant exchange risk. They own assets denominated in ETH when their liabilities are in USD. In the absence of proper and bullet proof hedging mechanisms, this means that they may suffer from every negative ETH price variation: this is a huge risk.
Angle only supports in its price stability module Euro denominated assets and low-volatility securities. The value of the securities could in rare cases decrease which means that Angle is exposed to this collateral volatility risk in some way, but the expected volatility is minimal with respect to what the protocol can safely absorb.
Stablecoins and DeFi systems in general all leverage applied market design ideas. Designing a protocol is like putting a set of rules that create incentives for participants to take specific actions in some conditions that are going to make the protocol converge towards a desired set.
It's possible that this set of incentives do not work as planned and that the actor's behavior in the face of these incentives is poorly anticipated.
Let's consider a derivatives backed stablecoin waiting for external stakeholders to come and hedge the protocol against its volatility risk: well there is a significant risk that external stakeholders do not react well to these incentives, leaving the protocol in a bad state.
It's generally hard to anticipate when these failures can happen and how to quantify their outcomes, but any kind of experimental DeFi system comes with this risk.

The governance risk is another risk common to all decentralized protocols.
Decentralized protocols are very often parametrizable systems with admin functions controlled by a decentralized set of voters, either directly or indirectly through a multisig.
Depending on the setup, a coalition of multisig signers or a majority attack on a protocol governance could lead many poorly setup protocols to lose a portion if not all their funds.
It's then all a matter of making sure that multisig signers have enough skin in the game (reputational, legal, …) to disincentivize them from such wrongdoings, or that majority attacks are too expensive (because token distribution is already well decentralized for instance).
A neat way to mitigate that is to put all key parameter update behind a timelock which in the worst case would leave enough time in case this happens to all stakeholders to rage quite their protocol. This is the direction that Angle is currently taking.
In DeFi protocols, fees are often variable and depend on market conditions. There is in fact how they look like during the normal course of operations and how they may look like in extreme cases.
This creates a risk for every DeFi protocol stakeholders which cannot get a 100% guarantee that they will at all times be handled with the fees they faced when they got in.
On Aave for instance it's not rare to see on some assets a borrowing cost as high as more than 100% in periods of extreme volatility. Within Angle, the costs to mint and burn agEUR may vary depending on the exposure of the protocol to the assets it has in reserves, and without notice.
Knowing the risks of a protocol or an asset you interact with should really be the first step before depositing any capital. On our end at Angle, we have a page in our documentation which essentially goes over all these points.
What I'm still unsure of though is about the best way to communicate about these risks. Does risk communication need to happen on the frontends that people use to interact with protocols? Or can it go through third-party rating agencies/platforms which goal is to provide an unbiased assessment of every significant protocol in the industry?
One issue I see with these platforms is that it's going to be hard for them to keep a full coverage of every protocol, and they may often be lagging behind. To this extent, it's easier to ask protocols or frontends to also provide another layer of risk communication directly on their frontend.
Our take at Angle is that in the absence of a widespread rating solution, it's our job to do our best to make this risk intelligible, transparent and seizable by any protocol stakeholder. That's also one of the reasons why we wrote this article.
Another thing I want to point out is that we've been able to communicate here about some of the major risks within Angle protocol. The reason why we've been able to do this is because Angle is built on a blockchain standard that enable us to handle such communications transparently and in a verifiable manner.
There are of course other risks at stake and I could have gone further in their quantification (we have an analytics designed for this by the way), but at least we've been able to lay out what I guess many people who had their account with the Silicon Valley Bank wished they had known before the bank went bankrupt.
We have all the necessary elements to turn this aspect of risk, which is often used by institutional players as an argument against adopting DeFi systems, into an unfair killer advantage that we will utilize over financial applications that do not leverage the blockchain standard.
No comments yet