Written by: linguine (Marlin), krane (Asula) and prince
Thanks to tarun, emperor, ren, rajiv, jim, and sam hart for their comments and feedback
Preamble
Constant Function Automated Market Makers (AMMs) are the most common format of liquidity provision on blockchains. AMMs specify the shape of liquidity around the current price using an invariant function. On the other hand, order books (OBs) or central limit order books (CLOBs) are widely used in traditional finance and on centralized crypto exchanges. CLOBs allow market makers to define the shape of liquidity they want to provide around the mid-price (the mid-price is the midpoint price between the highest bid and the lowest ask).
Newer AMM designs like Concentrated Liquidity Market Makers (CLMMs) allow liquidity providers (LPs) in DEX protocols to provide liquidity within a range, helping the aggregate liquidity in a pool take many shapes. This capacity brings CLMMs closer to CLOBs with respect to the overall shape of liquidity that can be provided to any given asset pair. The shape of the liquidity (NB: shape encompasses both the spread and the depth of liquidity across price levels) is the only thing that truly matters when it comes to execution quality for traders on a venue. In fact, since an AMM, in the literal sense, is just parameterizing liquidity provided to an asset pair with a specific shape, an AMM-like market-making strategy can be deployed on top of OBs by using an overlay pooling contract and approximating the shape with limit orders (NB: there would be some differences like liquidity not flipping on being filled but this can be rectified with new order types, like a flip-on-fill order on OBs). Whilst CLMMs and CLOBs are similar at a high level, there are some meaningful differences that we’ll point out for the sake of completeness:
- Liquidity and fees earned on CLMMs are pro rata, i.e. when a trade gets executed at a specific price, every dollar of liquidity provided at that price earns its pro rata share of fees. On the other hand, OBs generally follow a price-time priority design where the first maker to provide liquidity at a specific price fills taker orders at that price. The maker earns no fees for making a trade (some exchanges have rebate programs that are outside the scope of this discussion).
- Liquidity providers on CLMMs generally expect to be somewhat passive. In contrast, liquidity provision on OBs is driven by active market makers. Typically, passive liquidity providers, due to a lack of machinery to adapt their quotes to new information, are regarded as unsophisticated.
- OBs, due to the constant requirement of creating and canceling orders, are not practical on slow or expensive chains. AMMs, on the other hand, pre-specify the shape of liquidity, making them feasible on slower blockchains.
Despite some differences, the general closeness of CLMMs and CLOBs allows us to abstract the specifics of underlying data structures away and think of markets in terms of the shape of liquidity provided to them. This will become relevant as we start discussing lending markets.
Introduction
As fast chains with low transaction fees become the norm we expect order books to become ubiquitous within both trading and lending in DeFi. Today, Phoenix is the only onchain order book that is being used widely and its primary use is trading. While the idea of using order books for lending has existed for a long time (in fact the first version of Aave/ETHLend was a p2p system not very different from an order book), we’re only now seeing implementations of order book-based lending in the wild.
In this piece we take inspiration from ideas in the preamble to suggest an order book-based lending protocol that can be augmented with pool-based extensions. The main points from the preamble we use are:
- The shape of the liquidity is what matters in providing traders optimal execution.
- AMMs are parameterized trading strategies.
The goal of this design is to provide a primitive that can disentangle lender strategy and lender-borrower matching. If the matching engine is able to aggregate liquidity from multiple lending sources, borrowers should theoretically be able to get lower interest rates. The design should also be general enough to accommodate many different lender types without modifying the core matching algorithm. This will be important as more assets become available onchain and lender profiles for each new asset makes it difficult to generalize through governance.
Lending Protocols
Almost all onchain lending protocols follow a pool-based design. The protocols allow passive lenders to deposit collateral into an asset-specific liquidity pool wherein they can earn interest. The interest is earned by lending these assets to potential borrowers based on a predefined interest rate curve (similar to an AMM where LPs agree to follow a predefined trading strategy). Since onchain lending is largely over-collateralized, often lenders on lending protocols also act as a source of demand by behaving as borrowers.
In this piece we’ll describe a simple pool-based lending protocol and try to adapt it to an order book (this description is adapted from Morpho’s documentation):
- A Collateral Asset that acts as the liquidatable asset against which the user borrows the Borrow Asset. Let’s call this $C.
- A Borrow Asset defines the asset the user can borrow against $C. Let’s call the Borrow Asset $B.
- A predefined Loan-to-Value (LTV) ratio defines how much the user can borrow against a given amount of collateral. For example, an LTV of 0.7 would imply that for every $100 worth of _$C*, the user can borrow up to $70 worth of *$B_.
- Lenders are holders of the $B asset who want to lend their capital and earn yield on their holdings.
- Borrowers are users of the lending platform that are willing to pay an interest rate to borrow $B (which lenders earn).
- A Lending Pool is a pool to which passive lenders provide capital. The pool acts as the central point of interaction with borrowers. This pool pro rates interest earned across all users based on the amount of capital the user provides.
- An interest rate curve is a function that defines how the interest rate paid by borrowers evolves. This is usually based on the utilization of $B in the lending pool. Utilization is simply the percentage of $B in the lending pool that is borrowed at any given time.
In a simple pool-based lending protocol lenders deposit $B into the protocol and a risk/strategy curator (which could be a smart contract or an entity) governs the strategy with which this capital is lent out to potential borrowers. This model allows any curator to create a new market by defining a collateral asset, a borrow asset, an LTV, an interest rate curve and an oracle.
Other lending market designs don’t just allow lenders to pool $B against $C but also allow borrowing against multiple collateral tokens through cross-collateralization or cross-margining (see Aave documentation for more details). In such models, borrowers could deposit any asset from a whitelist of assets to the protocol and borrow any other asset in the protocol against their deposits. The set of assets that could be pooled together is normally a function of protocol governance. Given the significant increase in the number of onchain assets, it becomes difficult for governance to continuously list new assets at the pace that the market demands. Being able to create isolated asset-specific markets allows protocols to side-step these issues. This was the basis for isolation mode in Aave v3 and Morpho’s current offering (fka Morpho Blue). In this piece we’ll restrict our discussion to lending models that contain one collateral asset, $C, and one borrow asset $B for the sake of simplicity.
It’s important to note that if there are many markets for $C-$B, each with its own LTV and/or interest rate curve then a borrower has to check across all of these markets to find the best rates to borrow against. Moreover, the ideal strategy may involve borrowing piecewise from multiple markets. (NB: When we say “ideal strategy,” we mean one that minimizes the instantaneous cost for the user to borrow capital; this is expressed as minimizing the interest rate the borrower pays)
Order Book Lending
We expect much of the world’s credit to move onchain over the next several decades. As this phenomenon unfolds, onchain lending platforms will need to support different variations of lending across various asset classes and counterparties. To do this we need flexible primitives that can adapt to different lending formats. Through the next few sections, we propose an order book-based lending market design with pool-based extensions that we feel may be flexible enough to provide many properties different asset classes require.
Fixed-term fixed-rate
First, let’s describe how a simple CLOB-based model would function when interest rates and lending terms are fixed. There is no pool involved in this design, just an order book matching lenders and borrowers:
- The crux of the protocol is an order book where borrowers of capital match with lenders. A collateral asset and a borrow asset parameterize the order book.
- The order book matches borrowers with lenders against the interest rate, the LTV and the borrowing period. Order books, when used for trading, match buyers and sellers against prices. Order books for lending are more complicated and need to match against multiple criteria. Two orders get matched if the borrowers_interest_rate >= lenders_interest_rate and lending_term >= borrowing_term and borrowers_LTV >= lenders_LTV. (NB: we do not discuss the amount of collateral deposited here since any match will have compatible LTVs between borrowers and lenders. During order creation, the protocol should just make sure borrower’s LTV is less than the collateral they are depositing; any valid order will thus, have sufficient collateral).
The design described above is an example of onchain fixed-term lending using an order book. The $C-$B pair parameterize an order book. The interest rate and borrowing term can vary from order to order but are fixed upon match. This is the right lending venue design for many real-world financial instruments like bonds or term loans. Moreover, as onchain identity becomes commonplace, credit scores could replace asset-based collateral. But fixed-term, fixed-rate lending hasn’t taken off in DeFi.
Variable-rate variable-term
Almost all DeFi loans are variable-term and use variable interest rates to modulate borrower demand. Given a $C-$B pair, we would like to accommodate indefinite borrowing periods and variable interest rates.
Below, we try to reason about what happens if we just remove the lending term:
- The book is parameterized by the $C-$B pair as desired. Matching happens based on LTV (if borrower_minimum_LTV >= lender_maximum_LTV) and interest rate (if borrow_interest_rate >= lender_interest_rate). The big difference here is the lack of a term for loans.
- Similar to the example above, lenders can create a limit lending order by providing a maximum acceptable LTV and the interest rate at which they want to quote potential borrowers. Depending on their lending strategy, lenders can run programs to cancel and requote on the order book continuously.
- Similarly, borrowers can enter a collateral amount, minimum LTV, and size they want to borrow to “market borrow” from available book liquidity. We call this order a “market borrow” since the borrower accepts the best prices lenders provide on the order book. This is basically how all onchain lending is done today.
The order book system described above has the same core primitive of a multi-dimensional matching algorithm, but pattern matches the shape of onchain lending markets much better than our first example. There is one crucial issue though: the interest rate is variable, so there has to be a robust way for the borrower to manage their ongoing positions (especially since the borrower can be matched with many different lenders). Moreover, matching happens based on the instantaneous interest rate provided by the lender. One griefing vector might be that the lender provides competitive interest rates when matching with borrowers and then steeply increases interest rates once they get matched with sufficient amounts of borrowers. In a pool-based design, the strategy of the lender is public, and thus, borrowers can audit the lender’s strategy. This is not the case in an order book.
The other limitation of the design is that lenders have to be active market participants. They must requote on the book as they receive new information, making it hard for passive lenders to participate in lending markets.
To partially alleviate both of these problems, we introduce lending pools but with a small twist.
Lending Pools
Lending pools are extensions to our order book that allow passive lenders to participate in our OB-based lending markets. Our lending pools are quite similar to single asset pools on traditional onchain lending platforms. Lending pools act as wrappers around the core matching engine to give passive lenders a simple way to interact with the matching engine. The lending pool creator, who we refer to as the Pool Manager, can set some basic parameters for the pool. They specify the LTV, the interest rate curve, and the $C-$B pair. The biggest point to note about our lending pools is that they don’t interact with borrowers themselves, they quote on an order book to interact with them. This is inspired from our understanding that AMMs are parameterized trading strategies that can be built on top of any data structure. Our lending pools are parameterized lending strategies that can be built on top of the OB matching engine. Moreover, since lending markets are a lot less dynamic than trading, we expected parameterized strategies to still be competitive compared to sophisticated lending strategies.
To participate, passive lenders just need to pick a lending pool to invest their capital. The pool’s smart contracts manage interactions with the order book to:
- Provide liquidity to the book. For example, the pool might make 20 orders each with different sizes and at different interest rates corresponding to the interest rate curve it wants to follow.
- As capital moves in and out of the pool, interest rate quotes by the pool must match updated utilization so the pool must requote to maintain its interest rate curve (NB: This is because the interest rate is usually a function of pool utilization. In general, as the inputs to the interest rate curve change, the order set required to continue following the interest rate curve would also change)
A rough depiction of these interactions is provided below:
Some points to note about the above design:
- Multiple lending pools and sophisticated lenders can compete to provide liquidity on the same $C-$B pair. This system can be imagined as an order book aggregating lender liquidity across many Morpho markets in the most basic sense.
- As a borrower, you can borrow at the lowest rate possible due to liquidity aggregation from different pools. Even if you make a market borrow order (as all borrowers do today), your instantaneous borrow rate will be minimized across different pools. The depth and spread provided by the aggregation should provide the best execution for borrowers prompting them to use these markets to trade.
- Borrow management systems can be built on this design to allow the borrower to effectively repay their loan and open a new loan if lower rates are available on the order book. The borrow management system can also foot the repayment amount for the borrower in exchange for a small fee.
Using lending pools gives passive lenders the capacity to participate in the order book-based design, but do we solve the interest-rate curve-based griefing vector? A straightforward solution would be to whitelist lending pools which are allowed to quote on a specific $C-$B pair. Another solution could be to whitelist the interest rate curves and only allow pools following specific interest rate curves. This is effectively how Morpho prevents borrower griefing today. However, this would prevent sophisticated lenders from participating in lending, reducing the overall liquidity available to borrowers. To solve this, we could allow sophisticated lenders to participate in the protocol by putting their lending strategy on a secure enclave or a TEE. This strategy would have strict checks on the interest rate curve, and a test bench could be used to guarantee that the interest rate formula used is within certain bounds. Moreover, sophisticated lenders may only be allowed to quote when fixed-terms and fixed-interest rates are used. While we feel like some of these solutions are acceptable, there are likely more interesting solutions that can be implemented as extensions to the OB as we explore this design space.
This combination of lending pools with order books provides a very nice separation of responsibilities. The order book is responsible for matching borrowers and lenders but does no risk management itself. On the other hand, the pool’s job is to manage risk on the capital it manages from its depositors. The order book can generate revenue by taking fees on any matches that happen on the protocol, and the lending pool can take a cut of the fees on the yield generated by the pool.
This combination of order books with lending pools also provides generalization to lending protocols today. Every lending protocol with one collateral and borrow asset can be considered a special case of this design. With some work, we expect this design to be extendable to multiple collateral assets and potentially even borrower assets. Moreover, the design can also accommodate margin trading for spot assets similar to Gearbox.
Conclusion
Above we presented a design for lending markets that uses an order book to match lenders with borrowers and allows for pool-based extensions to enable passive lenders to participate. We expect such models to become more common across DeFi as order books become more ubiquitous. We also think that separating the business of matching from the business of running a lending strategy can enable more expressive lending markets and also allow for each business to be sustainable by itself. Moreover, since liquidity is aggregated across different lenders, new lending pools don’t have to go through the cold start problem of needing distribution, they can simply quote on the order book and access borrowers if their prices end up being competitive with other lenders.