GOVERNANCE
Protocol Information
Security
Risk Framework
Silo Community
Knowledge Center
Why Secure Money Markets
Silo creates secure and efficient money markets for all token assets through a permissionless, risk-isolating lending protocol.
Secure, efficient, and permissionless money markets are characterized by:
- Compartmentalizing risk through design, not through watchdogs tracking risk for each token
- Minimizing governance; governance is not needed to whitelist assets
- Accepting all token assets Being highly liquid and fluid.
- Liquidity is concentrated and bridged, accepting any token as collateral
- Liquidity constraints are set by the market, not governance. An asset ability to be used as collateral is only determined by its ability to find counter-parties.
In May 2021, the DeFi community realized that shared-pool lending protocols were in fact vulnerable to market-related risks when Venus -- the biggest lending protocol running on Binance Smart Chain -- experienced insolvency as a result of the price manipulation of a collateral asset ($XVS). With $100M of bad debt accrued, many users in the protocols lost their deposits. (1).
When a shared-pool lending protocol whitelists a token as collateral, the entire protocol is exposed to the risk posed by the token. Lending protocols such as Aave, Compound, and CREAM have this flaw baked into their design; they are as secure and strong as their weakest collateral asset. Therefore, as they expand lending support for long tail assets, their entire protocol inherently becomes less credit worthy. When CREAM whitelisted the then illiquid token, $FTT, the community understood the protocol’s security had been weakened by this expansion. The community acted swiftly upon discovery, requesting the token be delisted, but not before the token had been heavily used to short many assets (4).
Aave and Compound, unlike CREAM, mitigate market risks through implementation of rigid risk policies that account for factors such as liquidity, centralization, and volatility of the token being considered as collateral. But even comprehensive risk policies cannot entirely mitigate the systemic risk inherent to their design.
For example, what if the liquidity of a collateral token plummets before governance could deactivate its borrow function in time? The majority of governance models implement a timelock before a passed proposal is enacted, meaning that this hypothetical is a real possibility.
In November 2021, Aave’s community (5), in the aftermath of the CREAM misfortune exploit, proposed to deactivate borrow markets for $DPI and $xSushi, fearing an exploit might take place. Two days elapsed between the creation of the proposal and its execution. The CREAM flash loan attack took place in less than a few hours. The exploit could have been conducted because it was identified by the proposal and because of the slowness of governance to act.
In short, shared-pool lending protocols always trade off asset support and safety of deposits. The lending protocols of today are designed for efficiency at the expense of scalability.
Isolated lending protocols offer a better design for money markets. There are several protocols that implement them today through various mechanisms. Among the implementations, two extremes emerge:
- Isolated markets, such as Kashi’s fragmented markets: Kashi creates a money market for any pair imaginable. For Dai alone, Kashi has over 30 markets. This implementation achieves high security through extreme isolation of markets. Markets are spread too thin; they cannot perform efficiently.
- Isolated pools, such as Rari’s Fuse pools. To solve for efficiency, a Fuse pool functions like Aave or Compound; it can consist of many tokens rather than a pair. However, because a pool can consist of many tokens, the entire pool is rendered risky when one of the token assets cannot be trusted for any reason -- as seen with Rari’s Tetranode pool 6 (6). In this situation, if a user doesn’t trust one of Tetranode’s ~19 token assets, the entire pool is rendered worthless to them. Solving this problem requires Rari to create an infinite number of pools that match the risk profile of a large user base. In addition, each fuse pool has a manager that can change the parameters of the pool unilaterally, thus placing the security of a pool on a single point of failure. In other lending protocols, we see governance perform this functionality.
Last modified 6mo ago
Copy link