Skip to content

Order book-based lending

Published: at 01:00 PM

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:

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 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):

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 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 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:

A rough depiction of these interactions is provided below:

alt_text

Some points to note about the above design:

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.