Aavenomics: What are the intentions of DeFi borrowers, and are decentralized lending protocols scalable?
Table of Contents
Important Disclaimer
1. Introduction
The public outcry for the blockchain technology to be brought to the masses is louder than ever, and there are two viewpoints that contemplates on the matter: A consumer-first view, recently popularized by 1kx’s Consumer Thesis, and an infrastructure-first view, detectable in a16z’s Nakamoto Challenge. The consumer-first view optimizes for developing the “consumer apps” that directly interact with the end-users to stir up the actual demand for the Web3 tech stack, whereas the infrastructure-first approach assumes the demand is guaranteed to come at any rate in the future thus prioritizes on improving the technology that can accommodate the millions of users.
Based on the former perspective, we have published a research paper counting the active users of DeFi derived from wallets interacting with Uniswap contracts in Aug 2023 to check how many end-users do exist globally, and as expected, we arrived at an estimate of 6,000 – we still have a long way to pave.
However, although we prefaced our previous work with ‘DeFi,’ we do acknowledge that our paper was only half-complete, as we ignored the other twin pillar of blockchain finance that ignited the DeFi Summer: Lending protocols, which would be the subject of research this time.
By looking at the data of the lending protocols, we hope to answer the core question of ‘are lending protocols scalable in its current shape?’
2. Data Specification
Table 1 – Data Description of Data Set 1
Table 2 – Data Description of Data Set 2
We defined the subsequent transactions of a borrowing transaction as ‘transactions that are sent from the borrowing address, within 7,200 blocks from the borrowing transaction, and involving the same token addresses as the borrowed token.’
We introduced the 7,200 blocks condition, which roughly equates to 24 hours, as most subsequent transactions occur within a day, which we learned after manually inspecting sample borrowing addresses.
3. Data Challenges
3.1. aToken (aUSDC, aUSDT, etc.) Transfers
The Aave smart contract records minting of an aToken (ex. aUSDC) as a deposit, and redemption as withdrawal. If Alice deposits USDC into Aave, on the backend she transfers her USDC to Aave and mints aUSDC representing her receipt of the deposited USDC. If she burns aUSDC and redeems her USDC, her deposited balance would be zero, simple as that.
The problem arises as the aTokens, or aUSDC in this case, are programmed under transferable ERC-20 token standards. In the above example, Alice could easily transfer her aUSDC to Ben, and Ben could redeem the received aUSDC into USDC.
Only looking at the transaction history of Aave smart contracts could yield positive balance for Alice, when she has no deposit left, and a negative balance for Ben, which is simply illogical.
Solution : Our solutions prescribed in 3.2. – 3.6. removed most of the aToken transfers, so we did not take additional steps here.
3.2. Smart contracts calling Aave smart contracts
Thanks to the composability of dApps, projects frequently utilize Aave (or more specifically, aToken) to their advantage. One primary example would be Yearn Finance that aggregates yielding assets from various sources.
If Alice deposited her USDC into Yearn vaults, and Yearn Finance redeposits the USDC into Aave on behalf of Alice, then the Aave smart contract transaction history would record the depositor as Yearn, while obviously the money is owned by Alice.
3.3. Other smart contracts calling Aave smart contracts
However, not only yield aggregators rely on Aave for composability; swap aggregators, such as 1inch or Paraswap, also utilize Aave to provide the best route for swaps. If we identify the sender of the transaction as the depositor as we did in 3.2., then we would end up labeling the ‘swappers’ as the ‘depositors,’ thus tainting our database.
An example would be 0x702e24f29c61f21b088f15575123ada7468360ea295943f5c065be4f0068757e, in which 1inch executes a DAI-USDT swap for a swapper via the following route: Deposit DAI to mint aDAI in Aave, swap aDAI to aUSDT in Curve, redeem aUSDT for USDT in Aave, and returns the swapper with USDT.
The Aave smart contract would show the 1inch Router contract as the depositor, and applying our method in 3.2. would identify the swapper as the depositor — both results are not optimal for our purpose.
3.4. Yet other smart contracts calling Aave smart contracts
GnosisSafeProxy contracts also call Aave smart contracts. Although the sender of the transaction in this case is indeed the ultimate owner of the fund, however often a GnosisSafeProxy contract is governed with a multi-sig. Thus, assigning each sender as a depositor could give a faulty picture as the GnosisSafeProxy contract should be viewed as a joint asset manager.
3.5. Still yet other smart contracts calling Aave smart contracts
Some protocols help end users to automatically swap into different assets before they deposit into Aave. In this case, although the transactions involve a ‘swap’ function, the end users should be counted as depositors, not swappers.
3.6. Flash loans
Flash loans, albeit a useful feature, is somewhat beyond the scope of study for this paper. Unless otherwise specified, all data shown below illustrates the filtered database for flash loans.
3.7. Interest rates
As the Aave smart contract only records point-in-time events such as repayment, it does not record the interest accrued during the loan period. If Alice borrowed 100 USDC and repaid 105 USDC after a year, simply using the balance calculated from the Aave smart contracts would show Alice having a negative loan balance of -5 USDC.
Solution : We disregarded all effects from the interest rates as we deemed the expected increment in the resolution of our database for our purpose is minimal.
The real problem of 3.7. is that it makes cross-examination of the finalized data set difficult, as negative signs of data usually means wrong data preprocessing, since you cannot repay more than you borrowed, but the existence of interest rates make negative signs possible.
3.8. Identifying the ‘intents’
Unless the borrower spends the exact same amount of tokens as it borrowed to 18 decimal places, we cannot be sure how the borrower spent the borrowed funds.
3.9. Confirming the ‘intents’
For ERC-20 tokens transferred to smart contracts, we must check the transaction logs and the invoked functions to reveal the true intents. However, leaving no stones unturned for 1,000+ smart contracts and myriad functions is practically infeasible.
3.10. Native ETH problem
Up until 3.9., we mostly relied on ERC-20 transfer history to identify the intents. However, Aave does not only support ERC-20 standards; it also supports native ETH operations as well as WETH operations.
4. Aavenomics
4.1. The Current Landscape
Overview
Figure 1 – Monthly Net Borrowing Activities in Aave
Table 3 – Correlation Between Borrowed Asset Types
Figure 2 – Monthly Net Deposit Activities in Aave
Table 4 – Correlation Between Deposited Asset Types
Status Quo of the Borrowers
Figure 3 – Monthly Borrowers to Depositors
Out of all depositors, roughly 40% of them collateralized their deposits to borrow from Aave protocol, thus contributing to the profitability of Aave.
Figure 4 – Borrowed Assets of Stablecoin Depositors
Characteristics of the Borrowers
Figure 5 – Borrowing USD Amount (Top 30 Addresses vs Rest)
One concerning factor is that, as are most other blockchain projects, borrowing demands on Aave rely heavily on a few whales with 30 top whales comprising >40% of the total borrowing volume.
These top whales include trading firms and financial institutions such as Alameda Research and Celsius, KOLs such as Justin Sun and Tetranode, MEV bots, and also Aave itself.
Figure 6 – Lorenz Curve of Aave Borrowing vs US Wealth
Deciding Factors of Borrowing Demand
Table 5 – Correlation Between Borrowing Amount And External Variables
4.2. Funding ‘Intents’
Figure 7 – Expense Breakdown of Borrowed Funds
Most of the borrowed capitals are repaid within 24 hours (or 7,200 blocks), which could be a surprising insight. We removed the Repayment category in Figure 7 to avoid the confusion.
*We aggregated all transactions involving the borrowed token address within 7,200 blocks, thus if a user borrows USDC, sends it to CEX, executes a trade, and repays with the proceedings, then its actions would be double counted in CEX and in Repayment.
Table 6 – Intent Category Classification Standards
*Perp DEXes, on-chain casinos, privacy tools, etc. belong to this category.
Figure 8 – Monthly Expenditure Breakdown By Intent Category
As visible in Figure 7 and 8, the foremost use case of borrowed capitals is leveraging/trading purposes (Leverage, Flash Loan, CEX). Although some portion of CEX deposits could be for off-ramping purposes, yet empirically we acknowledge most of the deposits are for trading.
The runner-up is the Yield Farming category that lingers on the composability of DeFi.
5. Are Lending Protocols Scalable?
5.1. How to boost borrowing activities?
As on-chain borrowing demands mostly come from leveraging during a bull run which is an external cause, the internal solution in boosting demands mainly closes down to liquidity incentives.
Boosting borrowing activities is crucial for lending protocols to persevere, as borrowing interest is practically the only source of profit for the protocols under the current design where liquidations are outsourced to third parties.
From Section 4.1., we learned that bull markets and liquidity incentives work positively in boosting borrowing activities. The insight makes more sense if we look at the ‘intents’ from Section 4.2. – the foremost use case of the borrowed funds is to leverage, and market participants increase their leverage during a bull market, thus a higher demand for borrowing.
In other words, providing more intent categories could also lead to an increase in borrowing demand: More yield farming opportunities, or more expendable services available.
Figure 9 – Total Borrowing ($M) in Aave by Loan Type
A noticeable feature in Aave is the ‘stable’ loan type, that fixes the borrowing interest rate at the time of the transaction. The introduction of stable rates could add some growth to the borrowing demand, but we need to take into account that most of the stable (or fixed-rate) borrowing volume originates from borrowing ETH (unlike variable loans, which comes from stablecoins), and the borrowed ETH are mostly deposited into CEXes or other lending platforms including Aave v3, possibly for interest rate arbitrage opportunities.
5.2. Are lending protocols scalable?
In order for the lending protocols to scale, we need the Expenditure category to grow, under a realistic assumption that an everlasting persistent mega-bullish market does not exist.
Under the premise that blockchain economy is a replica of the real world economy, the scalability paths for the lending protocols must encompass tokenization of RWAs, as in RWA-collateralization for microloans in developing countries.
However, financing mortgages, education, and vehicles via on-chain banks requires sound, reputable off-ramping solutions and also a robust liquidation mechanism for RWAs. Unlike T-bills, which become the most popular target for real-world tokenizing, these necessities are heterogeneous in nature, thus rendering them into standardized ERC-20 tokens is impractical. Moreover, as most liquidations occur off-chain (most liquidators send the collaterals to CEXes), even if we do have reliable ERC-20 representations of residences in Singapore, the robustness of lending protocols are at jeopardy if all these tokenized RWAs are not listed on major CEXes. Considering all these, the landscape for RWA debts would be similar to the current NFT lending scheme, which is an extreme niche.
Therefore, it is plausible that the on-chain finance regarding RWAs would resort to standardizable tokenized securities, which again belongs to the leveraging intent category.
6. References
- The Federal Reserve Bulletin September 2020, The Federal Reserve, (2023, Oct 5), https://www.federalreserve.gov/publications/files/scf20.pdf
- OECD Data, OECD, (2023, Oct 10), https://data.oecd.org/inequality/income-inequality.htm
- Tokenization: Overview and Financial Stability Implications, The Federal Reserve, (2023, Sep 26), https://www.federalreserve.gov/econres/feds/tokenization-overview-and-financial-stability-implications.htm
