The 7 Deadly Sins of Lending Protocols
#1 Collateral MUST Be Secure
The protocol will fail if it enables users to utilize illiquid or improper assets as collateral in order to borrow other desirable liquid assets. This was the case with Rari Capital and a few others. Protocols need to consider both normal conditions and extreme scenarios, as seen with the Luna hacks, where billions of dollars quickly forced the algo-stablecoin $UST to crash.
The collateral asset’s market capitalization can be one dollar or $10m, and it wouldn’t make a difference if the protocol’s oracles can be easily manipulated. Pump the collateral’s price, borrow liquid assets like $DAI, then exit the protocol. Aside from oracle attacks, collateral assets with low liquidity, high volatility, or complex economic designs, such as algorithmic stablecoins, are at risk of being manipulated.
To extend the economic designs part, it’s important to consider proper implementation of highly capital-efficient mechanisms and external integrations. Part of the Euler Finance hack utilized a function, which allowed users to clear “dust” from their accounts, essentially manipulating how users' debt health scores are checked. The hacker also used a flash loan to instantly borrow and withdraw $197m. Furthermore, other protocols that integrated with Euler were also at a loss, such as Idle Finance.
Traders with deep pockets could also easily manipulate collateral on a protocol simply by testing the extreme ends of the economic designs, as was the case for Mango Markets. Limitations on ‘whales’ will likely fail due to the possibility of a Sybil attack. This is the case even if the protocol were to forgo DeFi ideology by implementing ‘Know-Your-Customer’ requirements. KYC documents are incredibly cheap and easy to buy. Centralisation also equally possesses security problems, usually as a trade-off for convenience or flashy features. FTX is the latest in a very long line of examples.
Collateral assets de-pegging is also a concern regarding stablecoins and wrapped assets. Trusted stablecoin $USDC de-pegged from $1 after one of their major US banks, Silicon Valley Bank, announced it was insolvent. Users across all types of lending platforms experienced liquidation due to collateral assets dropping as low as $0.87 on the dollar. Stablecoins such as $FRAX and $DAI used $USDC as part of their backing value, so naturally these de-pegged as well.
Perhaps $WBTC is the best we’re going to get for an asset that is “unlikely” to de-peg. However, every lending protocol offers ‘safer’ assets as collateral and borrowable assets. Therefore, protocols will have the issue of competing in other areas such as APY. It’s also important to note the danger of adding new collateral assets, especially due to FOMO, as the project behind the token might not clearly explain it’s a rebase token that will quickly devalue. Clearly, due diligence needs to go into every collateral asset.
#2 Oracles MUST Be Accurate
Most platforms have concluded that Chainlink is the only or primary solution to determine asset prices. Some also utilise multiple oracles that have different setups. While the actual decentralisation aspect of Chainlink is sometimes debated, its near monopoly is not, which can create problems when it may fail or pause, even if it’s a rare occurrence. Venus Protocol lost $11m as Luna crashed, simply because Chainlink automatically paused the oracle due to the rapid change in price, as it was designed to do.
Using the Time Weighted Average Price (TWAP) of DEXs such as Uniswap can help to solve the oracle monopoly problem, but it greatly increases risk as a sole solution. The burden is placed on DEX liquidity, which can be more easily manipulated compared to using Chainlink. Indicating the level of risk, which should be implemented anyway, also forces another burden onto users to understand, thus creating a larger barrier of entry.
This is not as big of an issue if the protocol’s users are DeFi natives. However, if the protocol uses daily active users (DAU) as a vital metric, then it’ll eventually become a problem as the protocol grows and certainly during a bull market where ‘dumb money’ runs rampant. We’ve seen people ape their mortgages and life savings into random Doge forks, only to lose it all. Don’t assume retail users will read past the APY percentage.
Additionally, using a DEX TWAP is game-able. The value of borrowable assets must always be less than the cost of manipulating TWAP. It’s better to understand how and why attacks happen than to assume that they will simply be prevented because of the “dark forest”, arbitrage, front-runners, etc.
Uniswap-based TWAP attacks will get interrupted when there are other, more liquid pools than the one being used for pricing. A $7k TVL UniV3 pool being used for an asset's price looks prime for an attack, but another fee pool with $3m TVL would create arbitrage opportunity for bots, so the attack will likely fail.
Keep in mind, the cost of manipulating a TWAP is exponentially less when it’s an illiquid asset. It’s likely that no one will have a bot to arbitrage a token that trades once a month for $5 between low liquidity Uniswap and Sushiswap pools. They’d probably lose more in gas. What if there's $2k in liquidity spread over a wide range? It would appear quite costly for a one or two block attack to drop the price 98%. However, if the volume is non-existent, then the attacker could wait 10 or even 500 blocks for the oracle price to drop after dumping the tokens and completing the attack without worrying about arbitrage.
This is a bigger problem for Uniswap’s V3 TWAP compared to V2 since liquidity providers aren’t incentivised to provide full-range liquidity, in fact, they’re incentivised to put it in narrower ranges that can earn more fees. Exploiters can wait for a dump or pump that would place the current price past a concentrated mass of liquidity, and thus more easily push and pull the price in their preferred direction afterwards. More liquid tokens might have LPs who often rebalance, but illiquid token LPs seemingly don’t do this. Check out the analytic pages on Uniswap for comparisons.
The cost of an attack on oracles can also be much less in terms of labour. Not only are there plenty of examples that can be replicated under the appropriate circumstances, since many of these platforms make the same mistakes, but the task is less arduous than for novice programmers to find smart contract flaws in DeFi derivatives protocols, for example. It’s often simply the economics of the protocol design. Even more so, as the cost of an attack can be substantially reduced by borrowing tokens used in the attack instead of buying them.
Aside from Chainlink and DEX-based oracles, there are still a few protocols that seem to think they’re brilliant by hard-coding the prices of assets. Mirror protocol was a stock synth protocol that hard-coded $UST to equal one dollar. Of course, this didn’t work, as $UST dramatically crashed. I won’t mention the other protocols, but time will tell if they’re correct or just lucky in this approach.
#3 Governance Is Dangerous
Decentralisation often comes at the cost of security. This is not a matter of nature, it’s a matter of not understanding basic economic designs or incentives. Giving the “community” direct control over the treasury, security parameters, or important smart contracts as part of the effort to decentralize will lead to disaster.
Protocols must assume whatever they give to the community to control, they are also giving attackers the opportunity to control. For an exploiter, how much would it cost to buy or borrow just enough governance tokens to vote on transferring the treasury to themselves? This is what happened to Beanstalk, which lost $182m.
Currently, most protocols put a barrier between DAO governance and execution, thinking that is good enough. However, governance tokens can still pose an enormous risk to protocols when they’re designed to do anything other than vote. If the governance token plays an important part in the protocol’s design in such a way that users would leave the platform if the token were to drop to a price of zero, then the governance token delivers risk equal to the total failure of the protocol.
Additionally, this indirectly incentivizes a “financial security” feature that may be regulated in many countries, i.e., the US Security Exchange Commission (SEC). This indirect incentive forces the protocol to be supportive of the token’s price and deliver value to its holders or else the platform fails, while also potentially being subject to regulations. This could be something to think about for SEC averse projects.
The protocol must design fundamentally valuable applications that can utilize the token. Some might call this ‘real yield’, but this just needs to be nearly anything that doesn’t rely solely on inflationary tricks. For example, the protocol shares revenue to governance token liquidity providers. GMX is an example of this. However, this may also be considered as a security by certain regulators.
Why not just separate the governance token and the ‘dividend’ token? Vote-only tokens are generally seen as less valuable since they don’t do anything substantial to give value to holders. Without demand, liquidity plummets since no one wants to LP a token that doesn’t attract trading volume in DEX pools, which generates more fees distributed back to LPs.
This comes back to the low liquidity problem of an attacker being able to buy or borrow just enough governance tokens to manipulate governance. Perhaps a protocol can support its own liquidity, whether on a DEX or its own bonding curve. However, that’s also an opportunity cost for the paired LP token, such as $WETH or $USDC. This also might not even remedy the situation, but just offer another off-ramp to sellers.
Going back to the fact that most protocols put a barrier between governance and execution begs the question, is it really DAO governance and decentralization? These tokens are more of a ‘community suggested vote’ (CSV) than actual decentralized governance votes.
Assume a low-value proposal is accepted. When does it get implemented, and how is it prioritized? Even if these two questions are outlined in the proposal, what are the clawbacks if it just gets forgotten? Probably none. Is that any different if it’s a high-value proposal? The protocol’s development team can ignore what the community wants, especially if the token is just a vote-only token. If everyone dumps it, so what?
A response to this web3 rendition of the classic principal–agent problem is that the team is compensated with the CSV token, so they ought to care. However, most projects set a horizon of three to five years on their fully vested tokens, and they would rightfully sell during this time. Team members also receive a stablecoin and/or fiat salary, so they may not be incentivized to manage in favor of token holders, especially as they sell their allocations.
Management decisions would more likely benefit VCs who fund their salaries over community holders in this alignment. This may lead to VCs creating or voting on proposals that benefit their investment strategies rather than the long-term health of the protocol. While there are many novel governance mechanisms being designed to remedy this situation, such as private voting on Aztec, there isn’t a one-size-fits-all solution just yet.
Sushiswap could be considered as one example of the general problem, as they’ve already reached well over 75% of the max tokens already in circulation. CEO Jared Grey's plan for the new tokenomics highlighted burns, locked liquidity, time locks, and low emissions. Will it be competitive enough compared to newer protocols that can unleash a fresh supply of emissions and incentives? Sushi will have a comparably harder time anyway.
Without real yield, protocols end up relying on inflation to incentivize borrowing. This often works in the short term, but consider that a fully vested and offloaded token from the team, investors, emissions, etc., without any mechanism to burn or lock-up tokens, would likely lose value relative to everything else in the long term.
All the tokens are in circulation and there is no demand apart from governance, which probably doesn’t even have many proposals at this later stage anyway. One might imagine low trading volume, so perhaps there’s the low liquidity problem again. One might also imagine tons of tokens in sell orders on CEXs, so perhaps there’s one-sided liquidity there. At this point, the only thing remaining is a platform with basic market demand and supply for borrowing and lending, struggling to compete against lending platforms that offer real yield, token burns, lockups, or other incentives to attract greater demand.
For these reasons, governance tokens should not be seen as a way around regulations, or to offload team/investor allocations onto the public, or to create “decentralization”. It’s simply an incentive in economic design, and nothing more.
If the only way to gain and keep users on your lending protocol is with inflationary incentives, make a mental note that you’re only renting those users. It doesn’t matter if you launch on a layer two to bring in retail users who want cheaper transaction fees. There must always be real demand for borrowing. It would be more advantageous to develop strategies where users borrow tokens on your platform to use on another platform than it is to simply pay them to recursively borrow to dump the governance tokens.
#4 Liquidations MUST Be Profitable
If a borrower’s loan falls into liquidation, who will pay the difference? If the collateral is $WETH or $DAI, it's more than likely that someone will, as most lending protocol liquidations offer a bonus or discount to liquidators. If collateral is worthless, no one will liquidate the position, and the protocol and lenders are left with bad debt.
What if the collateral is good, but the discount or bonus is insignificant? Hypothetically, someone might decide to liquidate as an alternative to buying from the market for a variety of reasons, one being simply to support the protocol. Otherwise, it’ll likely become bad debt.
If the protocol doesn’t pay out of their reserves to cover the bad debt, then the lenders are at a loss, which would obviously damage the protocol in many ways, reputation and otherwise. Aave suffered from a bad debt situation after the Eisenberg attack but repaid it from reserve purchases. This attack also introduced another issue where the position was so large, that it was impossible to directly and instantly liquidate it. There are more examples of bad debt on RiskDAO as well.
#5 APY MUST Be Competitive
When a user lends, they earn interest. Without interest, they’re losing money due to opportunity cost, inflation, etc. If a user borrows, their strategy must be more profitable than the cost of the borrowed tokens’ interest rate. If the interest rates of lending markets are zero, the protocol can’t compete. If the interest rates of borrowing markets are always sky-high, lenders must deposit more, or users will get liquidated. The latter usually gets resolved if the protocol is trustworthy.
A fair number of innovative projects have launched, created markets, but then shut down simply because they couldn’t find borrowers or lenders. For new protocols, they need to offer higher-than-market-rate lending interest rates. If a new protocol offers the same lending or borrowing interest rates as Aave or Compound, users will rather borrow or lend on the time-tested platform.
This means that new protocols must offer a premium for the risk delivered to users as a new platform. If a protocol has sufficient marketing to make users aware of the higher-than-average APY, and yet TVL does not increase, then it’s likely that users do not trust the platform enough to deposit and earn at those rates.
#6 Custody Is a Risk
As noted earlier from the Luna and FTX events, black swans can wipe out lending protocols fairly easily. Imagine if Vitalik abandoned Ethereum, or someone somehow found a double-spend exploit on Ethereum mainnet. Sure, these events could be ‘fixed’ in the long term, but in the short term, it’s a massive disaster. Decentralized custody could have saved many funds from these tragedies
How much autonomy does the user have over their deposited assets? FTX had zero, and platforms on Luna effectively became zero when they couldn’t move their assets. As much as I like platforms like Goldfinch, these protocols force users to lock in their deposits for weeks or months at a time. Think of time locks as a risk in the protocol’s incentive models.
Utilization rates can technically be another form of custody for non-fixed rate platforms where interest rates depend on demand and supply. Users cannot withdraw their deposits if utilization is at 100%. Many users’ deposits would be at risk of liquidation, as the borrowing interest rate would be higher than the lending rate. Their only choice would be to deposit more tokens or supply more collateral.
Hypothetically, a wealthy exploiter could find a token with an extremely low circulating supply but high in utilization on a protocol. They would borrow enough tokens to reach full utilization, and drive users to either deposit more collateral or more tokens. If this exploiter has enough collateral, chances are they could drive users to liquidation while perhaps even pumping the price while doing so.
The trick here might be that this exploiter is also the liquidator, so hopefully, they could offset any losses from the borrowing interest rate. I don’t think this is very feasible, as something similar happened to what Avraham Eisenberg tried on Aave and failed, but stranger things have happened in crypto.
Instead of enabling borrowing to directly reach 100% utilization, a protocol could set a utilization cap. This could start at 80% and progressively restrict additional borrowing upwards to 100%. Borrowers would be able to borrow fewer tokens against their collateral, while allowing users to withdraw their funds without interest rates liquidating them so quickly. Not a fool-proof plan, but it could help with the risk.
#7 Misconceptions Are the Protocol’S Risk
Users who do not know how to use the platform will ruin it. Under the premise they aren’t turned away by their lack of understanding, their unfamiliarity may lead to dire consequences. Firstly, the protocol will have to deal with users who do not understand simple operations and bankrupt themselves. This is entirely realistic for a lending protocol, and it has happened. These users will leverage up to heaven’s gates and get liquidated without understanding the daily interest rate was a quick ticket to hell.
Certainly, there are other aspects of the platform that can liquidate an ignorant user. This is a problem for the protocol because these users can become desperate. Desperate users start FUD campaigns, try to hack and steal or destroy the platform in other ways. Do not underestimate the length desperate users will go to get revenge.
Protocols also need to fully consider the codebase they're working with, especially if it’s a fork of another protocol. A common issue that stems from lending protocol code is the use of hookable tokens, which can lead to reentrancy attacks. Daniil Ogurtsov does a fantastic job of detailing the methods in his article on lending protocols. These attacks are quite common, like Cream, Fei Rari, and many others have fallen victim to this problem.
Lastly, another issue is user's perspective on paired denominations. Most protocols display prices in USD and sometimes in $ETH. What does the oracle use? Probably $ETH, especially if it’s a DEX TWAP. This matters because users may set limit orders (if applicable) or leverage with one pair but not the other in mind. A user might be bullish on ETH/BTC, but bearish on ETH/USD and BTC/USD.
This can be a more profound issue when assets like $LINK or $UNI are used for collateral and another asset like $BNB or stETH is borrowed. Users might assume a leveraged position on a lending protocol is directly shorting or longing these two assets, but the platform is only considering the $USD or $WETH value relative to the collateral and borrowed asset. This misconception might not be as directly troubling to the protocol as it is for the user, but clarity here would prevent making users unhappy and perhaps attract new ones to the platform.
There are many other aspects that can cause grievances for users. How interest rates are calculated, especially in a user's loan health score. If collateral can be isolated for a user’s position or borrowed by other users. Displaying the APY from staked tokens like stETH where the APY isn't wholly from the lending protocol itself. Hidden fees that can alter a user’s expected profits or losses. Documentation needs to make no assumptions and fully address all aspects of the protocol so that non-technical users can understand the risks.
Hopefully, this article has been enlightening to those unfamiliar with the various problems in DeFi borrowing and lending. I understand there are plenty of protocols that do these things and are very successful, however, that’s not the point. A protocol can operate with more risk than SBF’s casino and remain solvent. This is to highlight general issues and risks where things can go wrong so that users and founders can develop better protocols in the future.