Lender Beware Pt. 2 - Shared-Pools

The previous article explored some of the risks that a lender needs to navigate in choosing a lending platform that suits their risk tolerance. Of these, systemic risk is the one most easily modified by simply selecting a platform that does not employ a shared-pool approach.

TL;DR

Features	Pure Shared-Pool	Isolated Shared-Pool
Example	Aave, Compound	Rari
Impact of Token Exploit	Affects entire protocol	Only affects pool(s) allowing exploited token
Token Availability	Requires whitelisting	Permission-less
Concentrated Liquidity	Yes	No, split between pools
Pool Management	Decentralized governance, interests aligned with users	Pool creator, interests may not be aligned with users

---

What is a shared-pool lending platform?

A shared-pool lending platform has a defined list of tokens that users can lend, borrow, or use as collateral. Lenders that want to lend will deposit their tokens into the pool and borrowers can deposit collateral to borrow any asset from the pool. In general, shared-pools concentrate liquidity into a single pool which results in higher utilization rates and more predictable interest returns for lenders. However, since all deposits go into a single pool, lender deposits are exposed to systemic risk — an exploit of a single token in a pool puts all other tokens within that pool at risk of bad debt.

---

Pure Shared-Pool Approach

First-generation shared-pool platforms such as Aave consists of a single pool composed of white-listed assets only. It currently has $20 billion total value locked (TVL) which is spread throughout 31 different tokens. Any lender that has one of the listed tokens can deposit it on the platform and start earning interest.

Pure Shared-Pools have high liquidity and are secure as long as only ‘safe’’ tokens are whitelisted

Whilst 31 tokens might seem like a lot, in a cryptocurrency space consisting of thousands of different tokens, only a tiny portion of all tokens actually has lending capability on Aave. This is to protect against systemic risk — an exploit in any single token which is accepted as collateral may cause bad debt to all lenders meaning inclusion of highly volatile assets is excessively risky. Aave’s protects users through governance whereby $AAVE holders can vote to support or oppose the addition of new tokens to the pool. The consequences of including high volatility assets have been seen in exploits of other shared-pool lending platforms such as Venus Protocol, which saw price manipulation of its native token ($XVS) resulting in the accrual of $100m bad debt.

Whilst whitelisting provides a layer of security for lenders, it limits the tokens that a lending market can be created for in the first place. For holders of those 31 tokens, lenders can feel free to earn interest on Aave. For the rest, however, they must wait for their tokens to pass the vigorous whitelisting process (if ever) or they must look elsewhere for opportunities. This creates a void in the lending space for other competitors that can support long-tail assets.

---

Isolated Shared-Pool Approach

A seemingly paradoxical concept, the isolated shared-pool approach introduced by Rari expands upon the shared-pool approach of Aave and makes it permission-less. Users can create a shared-pool that allows lending of virtually any asset, filling the void created by Aave’s vigorous whitelisting approach. The isolated nature of each pool means that exploited tokens will only affect pools that accept them as collateral whilst funds in other pools are unaffected. In this regard, Rari can create a home for long-tail assets provided there are other lenders willing to deposit into pools accepting them.

Rari uses multiple shared-pools where risk is isolated to each individual pool, allowing lending, borrowing, and collateralization of long-tail assets

The responsibility of fund protection is passed from the protocol to the individual lenders — it is their responsibility to be aware of the risk of every token in their pool of choice to ensure their funds are safe. This was evident in the recent sell-off of OHM which triggered a cascade of liquidations across various Rari pools. Fortunately, OHM has high liquidity which allows for smooth liquidations — if this sell-off had occurred on a less liquid token, liquidation may have been insufficient to fully repay lenders, resulting in bad debt. This was seen in a previous exploit of Rari Pool #23 involving VUSD.

The permission-less nature of pool creation means that anyone can create a pool. Rari categorizes pools as either verified or unverified and uses a scoring system to signal to users how safe the pools are. One pool of note is the unverified DefiGeek Community Pool which houses TXJP, USDC, ETH, USDT, and DAI. Whilst the last 4 tokens are quite well known, a quick glance at TXJP on etherscan reveals that ~68% of its total supply is held by a single account named defigeek.eth split between TXJP and TXJP/ETH or TXJP/USDC LP Tokens. A rational person may assume that no lender would deposit funds into a pool like this yet it still houses $3m worth of deposits which would all be at risk from exploitation of TXJP. Oddly enough it has a ‘C’ risk score from Rari which is the second highest currently available on the platform.

Since tokens are not white-listed, users must make sure they check every token in the pool or risk being in for a bad time — in the shared-pool case, risk of bad debt.

---

Tips for Selecting a Shared-Pool Lending Platform

1. Be aware of all assets in the pool: It does not matter what token was originally deposited, an exploit in any token inside your chosen pool can expose your deposit to bad debt. Lenders should especially take note of how liquid each listed token is and whether liquidity is high enough to facilitate liquidations.

2. Be aware of lending factors: lending factors such as oracle choice, LTV, and tokens inside the pool can be controlled by decentralized (Aave) or centralized (Rari) governance — typically decentralized governance is more aligned with user interest. High LTV’s may precipitate over-leveraging and inadequate liquidations if the token is insufficiently liquid. Poor oracle choices may allow for easy exploitations.

3. Get insured: Insurance funds such as Nexus Mutual can provide compensation for lenders in the event of smart contract bugs, economic attacks (e.g. oracle exploits), and governance attacks. However, choice in lending platform should not be decided based on having an insurance policy — the first layer of protection should always be to select a platform which is safe by design.

Parting Words

The current iteration of shared-pool platforms leaves something to be desired as a safe and inclusive lending process. The next article will explore the innovation of Lending Pairs that develop on the constraints of previous platforms to make them accessible to a wider audience in a lower risk manner

Read more in this series (Lender Beware):

• Lending Risk

• Lending Pairs

• The Siloed Solution

Find us: Twitter | Discord| Governance |Docs | Website