Introducing Sturdy V2

Sturdy V1 was a trendsetter for leveraged yield farming, reaching over $30m TVL and becoming the largest mainnet lending protocol with no token.

While leveraged yield farming is a powerful use case, it’s become increasingly saturated and, as a result, challenging to attract lenders. At the same time, we’ve observed many of the drawbacks existing lending protocols face and have a robust understanding of their shortcomings. Consequently, we propose that Sturdy V2 take on more than just leveraged yield farming by developing a new primitive for lending.

The DeFi lending landscape
In many ways, the purpose of DeFi is to empower users to manage funds with greater control and autonomy than TradFi. At the heart of this pursuit is sovereign risk management: as a user, it should be entirely up to you how much risk you tolerate and what you’re willing to lend against.

Today, this is not the case. When a protocol offers vaults with rigidly defined collateral types, they tell you how much risk you can take on.

Take Compound V3, for example. All Compound users lending USDC are earning ~3% APY and are exposed to a common set of collateral assets. Many prospective users would be willing to lend against additional collateral assets if they earned 4% APY, and others would accept 2% if it meant limiting their exposure. Yet neither party has a choice in the matter. It’s a one-size-fits-all design.

Of course, assets can be modified or added, but all that means is that either team members or governance votes decide which collateral types are available for you to lend against. Why are they telling you what you can do with your own money?

A handful of projects have tried to circumvent the rigidity of permissioned pooled lending by isolating risk through separate pools, but this approach comes with its own drawbacks. Lenders must actively manage their position to maximize yield as the pool rates fluctuate. Bootstrapping new pools becomes a chicken-and-egg problem, where borrowers are waiting for lenders, and lenders are waiting for borrowers. As a result, many pools tend to lie empty, with liquidity fragmented.

Users should be able to take risk management into their own hands rather than select from a multitude of isolated pools with fragmented liquidity or rely on the protocol to mitigate risk via selective onboarding. That’s why we’re introducing Sturdy V2, a brand-new primitive for DeFi lending.

Sturdy V2

Sturdy V2 introduces permissionless pooled lending, accomplished through a novel two-tier architecture. Here’s how it works:

Tier 1: Silos

Each silo will be a mini-lending market consisting of a single lending asset and a single collateral asset. For example, you could have a silo where users can only lend or borrow USDC and can only use ETH as collateral.

Each silo will be isolated, meaning a user who lends to silo X has no exposure to silo Y. They’ll also be simplistic, immutable, permissionless to create, and technically similar to Fraxlend. Silos themselves aren’t a new development and can be found in existing isolated lending protocols. What makes Sturdy V2 innovative is its novel method for preventing liquidity fragmentation. This is where the aggregation layer comes in.

Tier 2: Aggregators

The second layer of Sturdy V2 consists of aggregators that will move funds between these silos.
Users lend a single asset to a Yearn-style lending optimizer, which deposits the assets to whitelisted silos.

For example, imagine that there are five silos for lending USDC that use ETH, BTC, stETH, rETH, and cbETH as collateral, respectively. One could create an aggregator that only lends to the silos with ETH, BTC, and stETH as collateral. The aggregator automatically distributes lent assets among the whitelisted silos to maximize yield. Users lending to the aggregator would be exposed only to the collateral types they’ve chosen, with no exposure to other silos or collateral assets.

This is great for user autonomy and risk management, but the benefits extend much further. As we described earlier, isolated lending enables sovereign risk management but comes with its own set of problems. Sturdy V2’s aggregators solve them. Bootstrapping liquidity for a new silo would be easily accomplished by whitelisting it in an existing aggregator, creating instant, deep liquidity from the moment a silo is deployed. Aggregators also vastly improve the lender experience, enabling them to deposit to an aggregator instead of having to manage many different positions.

Aggregators will be built on top of Yearn V3, with several additions that enable them to be entirely permissionless and autonomous. Existing yield aggregators typically rely on manual allocation via multisigs, as determining the optimal allocation is too computationally expensive to be performed on-chain. Sturdy V2 solves this via zero-knowledge proofs, which enable the optimal allocation of assets to be computed off-chain.

We’ll introduce some more new features to DeFi, like atomic just-in-time liquidity for lending. Expect more info soon.

Preparing for Launch
Sturdy V2 introduces a novel primitive that will enable lenders to take control over their risk management and projects to permissionlessly create lending markets for their tokens without sacrificing on deep liquidity or the user experience.

Our top priority is to ensure that Sturdy V2’s code is bulletproof. To that end, we are in the process of auditing the protocol thoroughly.

In the meantime, we want to hear from you!

Any thoughts are appreciated.

Here are a few specific points we’d love additional feedback on:

What tokens would you most like to lend?
What tokens would you most like to use as collateral?
In theory, aggregators could expand to supply assets to third-party protocols (e.g. Aave, Compound, Yearn, third-party isolated lending pools) instead of being limited to just Sturdy’s silos. Would you like to see third-party protocols integrated into the aggregator?
Are there any other features you’d like to see as part of V2?

Be sure to hop in the Discord and follow Sturdy on Twitter to join the discussion and follow Sturdy’s progress!


I think the idea is good, but one huge drawback that is immediately visible is the unattractive (volatile) credit line for borrowers. If liquidity is constantly moved around in search of the highest yield, credit terms (borrowing rates) are sure to increase for borrowers since idle (unborrowed) liquidity will move away from the silo in search of being utilized (borrowed to generate interest), so utilization rates in said silo will increase, driving up interest rates. But due to the dynamics of the money market, liquidity will soon be injected again, and the cycle will restart from there. But in the meantime, the rates are significantly more volatile as compared to other lending markets like Fraxlend, Aave, Compound, and other incumbents.

People do not like variable interest rates, especially very variable ones.

While that may or may not be a reason for the protocol not to get traction, I think a Pendle-type (think interest rate swap) protocol could be built on top of this protocol to really harness the idea you proposed.

1 Like

Great point! This was something we were initially concerned with, but after modeling it out it looks like the optimization will actually have the opposite effect and dampen interest rate volatility.

For example, if an aggregator feeds to three silos that have APRs of 2%, 3%, and 7%, it would increase asset allocation to the 7% silo, and decrease allocation to the 2% and 3% silos. The end result would be that all three silos have an APR of, say, 4-5%.

You can think about it like an equilibrium; the aggregator will always want to deposit assets to the silo with highest rate, naturally bringing down the interest rate for borrowers.

We’re still working out the implementation details of exactly how the proposed allocation algorithm will work, but I’m confident that this is a tractable problem. We’ve also architected the aggregators in such a way that the optimization is a separate component, so there’s plenty of opportunities for experimentation (e.g., the aggregator manager could try plugging in different algorithms to see which performs the best).

Thanks for the reply. Do you mind if I have a look at the modeling (you know my Discord). Also will displayed APYs for borrowing and lending be an average? I think that makes sense in an instance like this.

P.S.: Another cool addition to this product could also be lending out (or earning some other yield) on the collateral asset, but I’m sure there are many nuances when it comes to that (liquidation could be an issue if the collateral is utilized or illiquid; borrowers, i.e., collateral posters, don’t want that risk; even lenders might not, etc.). but just an idea I’m curious if you’ve given any thought to.

P.P.S.: Do you think v2 marks a point where $STRDY is to be used to incentivize product usage as a cold-start mechanism? I know you guys are doing a cool KPI-esque liquidity incentivization program on v1, but maybe it’s time to allow users to get liquid rewards? The thing that I love about Sturdy is that there is a genuine product-market fit. Many other dApps only get usage due to hyper-inflating token emission programs that make it look like there’s organic demand, which there usually isn’t, and this is not at all the case for Sturdy. But at some point, $STRDY has to be made transferrable, since governance with no financial incentive is just a shitshow. A v2 was literally announced, and only both of us are talking about it on the forum—case in point. I obviously have a bias here because I got the $STRDY airdrop (I was using Sturdy back when you guys launched on Fantom), but maybe this is where a path forward to making $STRDY is laid out… just a thought, though.

We’ll be sharing more info on the zk-optimization soon. And yeah users will be able to see both current APY and average.

Probably not initially. One of our key goals for V2 is technical simplicity. That said, users will definitely be able to use interest-bearing assets as collateral. This was really popular in V1, and will continue to be a focus going forward.

I know some community members have discussed some ideas around $STRDY in the past, I’d love to see these discussions reopened now that V2 is on the horizon.

1 Like

Are you guys in touch with the chads from Pendle? As I said before, I think v2 could significantly benefit from a Pendle layer built on top of v2.

We’re not, but could definitely be a good integration down the road

1 Like