AL #40: Will Starport aggregate onchain lending?
The differences between modularity and aggregation and the new "Uniswap V4 for lending".
✨ TL:DR; Starport is much more interesting than the whitepaper affords at first glance. Read on for my interpretation.
Thanks to Alberto Cuesta Cañada for reviewing this article.
One of the earliest modular protocols was Trident, a framework for building AMMs using a standard pool interface which allowed Sushi to implement a number of different AMMs using the same model.
Due to political issues at Sushi, Joseph Delong (then CTO at Sushi) left early and Trident was eventually succeeded by Uniswap V4.
We've covered the merits of using V4 for developers in How to Compete with Uniswap V4 and the Dangers of Concentrated Liquidity.
But it’s worth recounting some of the major benefits here:
A strongly audited concentrated liquidity primitive at the foundation of every pool
Clear entry points to custom functionality in the form of hooks
Cheaper routing together with other V4 pools due to the “singleton” architecture
More reliable order flow due to routers, aggregators and fillers integrating with V4 in a comprehensive way.
It’s only fitting that Joseph Delong is now announcing the first serious attempt at a modular lending protocol:
And not to leave out the boldest statement of all: Astaria declared Starport as creating a Uniswap V4 moment for lending.
So let’s break it down…
How Starport works
I'm not going to go in complete detail here as the Whitepaper can be consulted for that but it's important to highlight some nuances to support later analysis.
The Whitepaper claims that Starport handles data availability and agreement enforcement for lending protocols.
Let’s unpack what that means.
Every loan in Starport follows the loan lifecycle. A lending protocol uses 5 contracts: 2 core contracts and 3 modules that entirely define its behavior.
Consider an algorithmic lending market like Compound or AAVE.
It could be implemented in Starport as follows:
Core contracts
New and refinanced loans always go through the Starport contract
Each borrower’s collateral ends up in the Custodian contract. The default Custodian contract could be used to save gas.
Modules
A dedicated Pricing module would determine the utilization based interest rate
Collateral ratios for assets could be referenced from the Status module to identify positions that can be liquidated
Finally, the Settlement module would define how a liquidation can be executed.
Other important details:
Loan enforcement is largely built into the Custodian contract as informed by the Pricing and Settlement modules;
The term data availability usually applies to rollups, not individual protocols, however, it makes sense here due to a gas optimization strategy called representment. Representment is used to hash loan information and ask for transactors to provide it to authorize actions. In this way Starport uses calldata and events for data availability;
Starport supports an intent-like system, allowing fulfillers to execute actions based on approvals or signatures. This will prove to be an important detail for the aggregation properties.
For more details on Starport, I recommend this excellent piece by Arhat.
How Starport can implement all lending protocols
Note that the primary distinction between different types of lending protocols are how borrowers/lenders are grouped and how they discover each other.
Everything else like pricing and liquidation rules is already representable in the modules.
Regular algorithmic lending
In AAVE/Compound-style protocols, lenders are all grouped together for a given market and all receive effectively the same interest rate.
This means that lending pool will act jointly as a “lender” in the Starport protocol while borrowers will still hold individual loan positions due to their ability to hold a unique mixture of collateral.
AMM-based lending protocols
Recent AMM-based lending protocols have recognized that the 7% liquidation incentive usually provided to liquidators in lending protocols could be radically reduced if the spot price change of an AMM pool could instead be used to trigger liquidations.
This requires the linearization of lending positions into a single collateral and borrow asset but as a result allows borrowers to be grouped in liquidity ticks according to their borrower threshold.
These protocols are highly confusing so if you’re not familiar with how they work, you're welcome to skip this section or watch my YouTube video explaining it:
Peer-to-peer lending
More recent peer-to-peer lending protocols like Wildcat are emerging which allow borrowers to control who has the ability to lend to them.
This is where Starport can shine at the maximum granularity level, the system is flexible enough to easily represent 1-to-1 lending relationships.
But it doesn't stop there…
How to aggregate lending
If the aggregation point for AMMs is mainly order flow since swap intents are so simple, the aggregation points for lending protocols are much more nuanced.
However, I'd like to argue that an intent-centric protocol like Starport could aggregate both borrowers and liquidators successfully.
Borrowers
There are nuances in token ownership incentives (Bond Protocol) or regulatory/institutional restrictions (Wildcat) that lead some borrowers to discriminate who can lend to them.
But especially for smaller retail borrowers, this really shouldn't matter. At the end of the day, a borrower should be able to present clear terms for their loan and request this to be filled with the best interest rate.
This is where it becomes useful that Starport supports intent-centricity through EIP-712 signatures.
In particular, they could develop a Uniswap X style system to help certain borrowers and lenders be matched. While Uniswap X suffers from the transient nature of swaps and eventually incentivizes order flow to go to other AMMs, a lending focused Uniswap X-style product needn't have this problem.
Lending DOES require a persistent loan agreement enforcement vehicle even after the original borrower intent has been settled. For security reasons, “Starport X” (for lack of a better word) could mandate that all loans settle on Starport.
This points at potentially a stronger liquidity flywheel combining onchain and offchain liquidity.
Liquidators
On one hand, liquidations can be quite different depending on the lending protocol. On another, there are some synergies in the parties (searchers, solvers) that want to be liquidators.
Liquidation is nothing more than an intent to execute a certain swap to deleverage a position. While traditional liquidation systems have relied on an encoded onchain trading source (like an AMM), an intent-centric liquidation system may be able to service liquidations through batch auctions for example (latency and risk tradeoff has to be carefully considered of course).
To conclude, while on first glance, the Starport protocol offers less for developers of lending protocols than Uniswap V4 offers for hook developer – concentrated liquidity is harder to implement and secure than lending market logic – Starport potentially has a way to offset that by providing the benefit of attracting borrowers and liquidators which are fundamental and difficult/expensive to bootstrap roles in lending protocols.
A new design space
At the end of the day, I've had to be quite speculative with this piece given the high-level nature of the whitepaper.
The Astaria team will make a major announcement on January 10 – a protocol on top of Starport – which should offer more insight.
It’s entirely possible that unlike with V4 their focus is not on being an aggregator but perhaps as competing with other aggregators on their own platform to drive down the engineering and security costs of a common lending platform.
But if they are doing an aggregation play AND creating a protocol that will be predatory to other Starport users on day 1: that would be an exciting path to analyze
I'm sure there will be more to say about it.