If you start reading this article but don’t read it until the very end super carefully, your coins will never reach a billion, and crypto will never reach trillions. There, I said it. Now, the curse is forcing you to read the text below entirely. I am sorry, but this was necessary.

First of all, here is a quick recap: ezETH depegged. As a result, many ezETH leverage point farmers were liquidated across Gearbox and other protocols, which don’t have 1:1 trust assumptions. Gearbox Protocol suffered no losses in the process. There was no bad debt for passive lenders. At the end of the day, the protocol even made a profit.

However, “Gearbox worked as intended” (almost) is not the best thing to say to leverage users. Yes, they knew the risks and were smart, but they got liquidated - and caring about users is important. We can do better as a protocol. So, whatever profits the emergency liquidator made during the crash - will be voted to give back to the affected leverage users. This is not to be taken as a precedent, though.

“Caring about users” is a question that goes back to the fundamental design of lending primitives. The same way “intended” can also be objected because who is the intention in favor of? For example:

• Some lenders could be okay with borrowers having a 1:1 oracle for borrowing;
• Other lenders would run as fast as possible from such a protocol version.

The former is worse for lenders but better for borrowers.

So, which one do you pick?

Let’s debunk this topic. An autistic, incel, delicate long read ahead.

The need for modularity in lending

Let’s first go back to where it all began—but not quite to the dinosaur's time…

Compound and Aave sometimes get flack because the latter has a few big-brain opinionated contributors who try to steer the DAO in the direction they think is best. Their decisions have so far worked and protected users, but the perceived subjectivity arising from critical decisions makes some people uneasy. It’s not that the decisions are wrong. It’s not that they are centralized. It’s that the choices eventually have only one outcome, decided by the DAO. Even if it is the right outcome, some people love to see plurality, so they go on to explore.

Why? Modularity would allow for different risk opinions to materialize. Thus, a narrative was formed that being too much like a single product is not the best or at least should not be the only approach. Alternatively, a protocol approach could foster a lending primitive where different risk profiles and asset compositions could materialize.

Inspired by some teams, the “product vs protocol” debate has already been discussed here and here. It’s a fancy narrative, but the challenges are in the implementation. That’s when we got interesting innovations like Rari, Silo, Ajna, and a few others.

However, everyone quickly understood that fully isolated pools have difficulties with UX and capital efficiency. Users aren’t going to check 50 different USDC pools and pick where they would deposit. And if you have the DAO connecting some of the integrations together, there is practically no different risk curation, so you end up with the same paradigm as you started with.

That’s where we get to the beginning of this article with “caring about users.”

Even with the utmost modularity enabled, this design choice stays; you can’t ever eliminate it. After all, lending protocols are essentially two-sided marketplaces. And with those, one side always ends up slightly better. That doesn’t mean it’s zero-sum, but you must make use case driven decisions when building a protocol to make it work. 

The same is true for Uniswap. Even though people like to use it as the most impartial protocol with no governance and full immutability, different versions are tailored toward specific user groups. For example, V2 made it easy to LP but made capital usage pretty inefficient. V3 increases the capital efficiency, especially for pegged assets, but forces LPs to be more active.

So, which user side do YOU care about as a protocol?

Cohesive modularity in lending

There is a false dichotomy that you can distill any complex product into 100 different protocol pieces, call it modular, and it will start working. Sadly, no. That simply creates 100 hardly-composable pieces. Those pieces don’t assemble back into a cohesive system. They are segregated. It’s not the same debate where you have monolithic vs microservices from web2. 

This may be a lazy viewpoint, but lending is magnitudes more complex than AMMs. Token contracts, token liquidity, and many other things can change. Lending needs to be able to adjust them. And on top of that, someone also needs to decide the direction of adjustments.

After all, look at something as foundational as Ethereum. It has EIPs that change its underlying consensus, the way transactions work, and the way fees work. You’d expect something as gigantic as Ethereum to be immutable, but even Ethereum has to change from within.

Hardcoding in lending is a one-way street.

We believe that today's approaches to modular lending can be improved. Although we are biased, we welcome discussion and opinions from other builders.

Why is hardcoded immutability not just inefficient but outright risky? Finance is not deterministic. It’s not a brick. Hardcoded parameters bring additional risks for passive lenders, like deadlock (when capital is locked by borrowers), etc. You can hardcore it for something like LUSD of Liquity, where people always expect a dollar to be a dollar or almost that. However, with lending, all values change; you can’t run the same story there.

An example of why hardcoding can be harmful or not as efficient:

1. You make different pools with different LTs, rates, etc.;
2. Then the asset liquidity worsens, but LT stays the same since it’s immutable;
3. A lender now needs to act to move away from the pool. Under different circumstances, some delegates of their choice would have voted to update LT. But there is total immutability so nobody can replace things; it’s a brick.
4. The borrower wins in such an exchange because they were okay with the deal when they opened the position. When the risks get higher, their deal remains as good. And when risks get lower, they can always opt-out for a better deal elsewhere.

You have no proper way to force borrowers to repay capital. With hardcoding, capital is in a deadlock with worsening risks, and lenders can do nothing about it. Neither can the risk curators. Nobody can change the LT or the oracle; it becomes a deadlock for lenders. Curators could withdraw the capital up to the buffer, causing the borrow rates to spike, but that’s simply too much micromanagement for both sides.

Therefore, the question is—how can this be made more optimal?

We think there is a better way to realize modularity in lending.

Manifesting modular leverage with Gearbox

The challenge in lending protocol design is related to the nature of blockchain. That nature is deterministic, while financial risk and liquidity are probabilistic and could not be implemented using the EVM stack. © 0xmikko, inventor of Gearbox

The sauce is hidden in the product-protocol architecture, which purposefully distinguishes the type of users you expect to see on each side. It does not generalize to “it can be anyone, bro.”

Do you make the lending side passive? How much complexity do you abstract from it? How much complexity do you put on the borrower side? Do you make it safer for the lender side or the borrowing side? - These are some of the questions.

For example, the pain points you will be faced with are:

• On one side, lenders want higher safety. That means no 1:1 oracles or trust assumptions for collaterals, conservative LTVs, and perhaps not the best rates. Some collateral goes wrong? Liquidate that sh*t asap and have others protocols eat bad debt. 
• On the other hand, borrowers want high LTVs and low rates, and they are very fine with 1:1 trust assumptions because that means no liquidations for them. They also don’t want LTs or other numbers to change.

The more precise your protocol outlines USPs (unique selling points) for end users or risk curators who service end users, the better. Gearbox has a very clear architecture on it. If we distinguish three groups, Gearbox Protocol enables the following:

1. Passive Lenders: entirely passive, no need for curation (there are not going to be 20+ pools per curator, although there can be various curators);
2. Risk curators and their markets: only need to fix parameters, no engineering work;
3. Borrowers: they have to observe and be active, but the UX of position opening and management, as well as the predictability of borrow rates, has improved.

Gearbox makes the passive side truly passive, while risk curators and borrowers need to be active (abstracted complexity goes into them). That means only ⅔ groups need to be active. Those groups have both improved UX and tooling to smooth changes.

On the other hand, Morpho requires even the first group (passive lenders) to be active but has an abstraction design to manage the flow for passive lenders. That happens by introducing a fourth group into the mix, yet they cannot upgrade the integration level. Or rather, it abstracts risk curators onto a level above (lending) but can’t change things that require changing (oracle, LT, limits), which is where the deadlock happens.

There is only so much you can abstract before it gets too complex and saturated. Bricked permissionless markets in lending, without the ability to make updates, can be detrimental to changing risk environments for both sides. Why: we already discussed above. The downsides are semi-theoretical, but they are there nonetheless. 

Anyway, we don't want to pat ourselves on the shoulders preemptively. After all, many of these things are theoretical, and the space is moving toward modularity overall. Let's face it: many lending protocols are competent. We prefer to stay humble. Please, no bag fights.

Group 1: Passive lenders are always passive.

Again, Gearbox abstracts all of the work from the passive side. There is no need for any risk curator to move money around. Risk curators curate risk; they don’t move capital.

• You don’t need to make active decisions as a passive lender;
• You don’t need to pay fees or move your capital around;
• You can select different pools managed by different risk curators, but you don’t need to move places in case an oracle needs an adjustment, or an LTV needs to change.
• The system is fluid; it’s isolated within what you choose, but otherwise, it is fluid.

Lenders can choose which USDC pool to supply to, as there can be different risk brackets. They can also choose a generalized USDC pool with different integrations inside it managed by the party they choose (Gearbox DAO or someone else), similar to how you have it with an optimizer. However, lenders don’t rely on someone else moving their money around. 

All of the pools are isolated. Whatever integrations and Credit Managers are connected to USDC pool 1 have no spillover effect or cross-collateral with USDC pool 2 or other asset pools like ETH or WBTC. You can have different USDC pools that are fully isolated from another USDC pool and have different LTVs and assets connected to the same pool.

Credit Manager is the glue that ties things together. It allows for changing assets, LTVs, oracles, and all other variables, while the passive side doesn’t need to change pools. All pieces are standardized and tested as whole systems, not random.

Sometimes, passive lenders might be okay with some trust assumptions, but sometimes not. The differences should be realized to service both user sides. 

Group 2: Easier life for risk curators, governance abstraction

Risk curators or decentralized risk providers are how different lending models can appear. Gearbox enables this, letting them straightforwardly manage an array of options. Don’t like the decision of the main DAO? Sure, choose pools or integrations managed by someone else.

Let’s specify one of their tasks: they curate risk. They are not 10-person engineering teams that build protocols; that's not their profile. So you can’t abstract all the technical work to them, meaning your design needs to accommodate them to curate things easily. Abstracting the layer of optimization doesn’t solve the underlying issues. Let’s consider that an oracle needs to be adjusted. Risk curators won’t be able to do it in most cases.

1. If a risk curator already has a mandate to move your passive capital around passive pools, why not just let them manage LTs directly? There is no difference, and the perceived immutability has little benefit then.
2. Who decides when to replace an oracle, when to change an LT, and so on? It could be Gearbox DAO. You can also get an instance of Gearbox Protocol and have your DAO decide instead. Or a risk curator. You can hire a risk curator within your DAO or even a whitelist who can be a lender or a borrower. Mix this up however you want.

Too many choices? Yes, we know, so we don’t talk about them daily.

But so that you know, they are there.

Group 3: borrowers, improved UX, and semi-predictable rates

As all the complexity is abstracted away from the lender side, the protocol has built-in features that make life easier for curators or borrowers who must stay active. For example:

3.1 Multicall: allows borrowing, swapping, trading, and opening an entire position in one transaction, as well as changing a position and even exiting it. This saves borrowers a ton of gas and manual operations.

3.2 Gearbots: allow for on-chain bots that can obtain the logic of stopping losses, taking profits, or whatever other command you can give to your Credit Account.

Gearbox UX: Meet the Gearbots 🤖

Gearbox V2 was a milestone achievement for the DAO. Composable leverage in its true sense was finally brought to life with a massive…

Gearbox Protocol ⚙️🧰Mugglesect

3.3 More predictable rates: Gearbox's borrow fee structure is twofold. There is the regular utilization fee, which has a low slope up until the buffer. It only acts as a slightly volatile utilization rate and is mostly there to jack up the rates if utilization gets >90% into the buffer to free up capital for lenders. Otherwise, borrowers expect relatively static rates.

That comes from quota rates. Quota rates are extra interest rates for every asset that don’t change intra-week. They change every Monday but otherwise stay predictable within a week, so borrowers can at least have some predictability of rates. GEAR holders make all those decisions and have power over interest rate markets. That allows for bribe markets on top, incentive, and revenue streaming, etc. See some of the ideas:

The $GEAR Wars

Leveraged restaking has now brought in over $105M in restaked ETH. It all kicked off with Gearbox DAO introducing EtherFi’s weETH, which raced to a 10,000 ETH restaked mark, after which Renzo’s ezETH was added as well. Interestingly, since ezETH’s introduction, Renzo has added over 21.4K ETH, while

Gearbox Protocol Blogov3rkoalafied

Overall, we believe the design Gearbox contributors have chosen, which will be voted on in the coming weeks, presents a more cohesive modular system. It allows for complete risk isolation with minimal overhang, where the passive side truly can be passive. Meanwhile, it creates a system where risk curators can manage these things efficiently without engineering roles.

For Gearbox users: improving going further

I. Oracles: less liquidations in the future

Gearbox currently uses Chainlink and Redstone oracles for every asset. Their regular price feeds aggregate and calculate prices relative to the depth of different avenues they look at, avoiding most known manipulation attacks, if not all. That is arguably one of the safest setups for lenders unless your size is like Maker or Aave, where yu are systemically large to do so. 

Anyway, the less known thing is the different types of oracles. For example:

• Market price-dependent oracles (described above)
• Oracles looking at redemption values of pegged assets (fundamental oracles)
• TWAP or other easily manipulatable one-avenue oracles
• 1:1 hardcoding the price LOL

This is one of the avenues through which Gearbox could improve. Treating any asset as 1:1 is a terrible practice in most cases. It's a lender’s nightmare. However, looking inward at assets that have verifiable redemption is another topic. This is something Aave is resorting to using now in order not to get liquidation-hunted when liquid derivative assets depeg on exchanges. Switching to fundamental oracles that have redemptions in place reduces market volatility for liquidation yet doesn’t introduce hard trust assumptions. That would apply to LRTs, for example, that have redemptions. This is already being voted on where possible:

Snapshot

Gearbox DAO assuming 1:1 in the current environment would look weird. In the current stage, lenders are prioritized in DAO voting based on the voting history. The goal is to prevent it from becoming overly degenerate. However, different setups and risk curation can happen once curators are onboarded. Then, it’s up to lenders to determine what they are comfortable with.

II. Caring about degens: Pause post-effects

To avoid unknown hacking attacks, Gearbox DAO voted for a pause role that triggers under certain conditions. One of those conditions was triggered during the ezETH liquidation cascade on the 24th of April. It was a good thing from one perspective, but it’s also arguable. The unintended negative consequence was that users couldn’t top up their positions with collateral as all protocol functions were disabled, so some unnecessary liquidations could have been prevented. In reality, one can add collateral even during the pause by directly sending, for example, ezETH to the Credit Account address. Just make sure not to send random assets because the asset, to count towards HF, would need to be enabled collateral. So, if your position is ezETH farming, sending ezETH directly is better.

During such a pause, the emergency liquidator was the only one permitted to handle liquidations. The emergency liquidator was spawned from a DAO decision, so its profits belong to it, too, in the current structure. Now, the vote is made to “reimburse” affected leverage users who couldn't top up collateral during such a pause.

Interest rate fees = 45 ETH were usually to be collected anyway, so, at closure, they were collected outside the liquidation event's scope.

Liquidation event numbers are:

• liquidation fees = 90 ETH
• liquidation temporary downside = 25 ETH
• premium by emergency liquidators = 170 ETH

What can go in the vote to give back to the affected: 170+90-25=235 ETH. The protocol made whatever it would make—no bad debt and even a profit. The amount on Arbitrum was within 2 ETH and is also included in the proposal.

Snapshot

However, this practice should never happen again because leverage has risks. In case of pauses, emergency liquidations, or any other events - leverage users are aware of the structure - thus, such events can’t be treated as unexpected.

DYOR. Caring is sharing, but not forever.

III. Better UX: the ability to add collateral during a pause

The rules for such a function need to adapt and improve over time. Different monitoring systems are already being improved, and we have seen the systems respond much better during this liquidation cascade than in previous market flushes. One such improvement would be to allow collateral top-up during a pause.

IV. Less harmful liquidations: partial liquidations

One of the features that have been audited and were about to be integrated is already in voting: when your Credit Account Health Factor goes below 1, you won’t be liquidated fully. Only a portion of your position would be sold off into the underlying asset and repaid. That will make the process less painful and liquidations less market-impacting.  

That’s already coming this week:

Snapshot

V. Risk curator for the main pools: Chaos Labs

The DAO maintains its structure, being the only risk curator on top of Gearbox Protocol. As the TVL has grown north of $300,000,000, there is a growing need to make sure that the risks are managed by a more expert party while engineers take care of their tasks. Therefore, the DAO has passed a proposal to onboard Chaos Labs, starting in 4 weeks.

VI. Transparency: More risk dashboards

Gearbox developers have set up a transparency risk dashboard before, but the more, the merrier. Thanks to the cooperation with Into The Block, there shall be another in-depth overview of collateral assets and their safety.

See the proposal details here:

Snapshot

VII. Security: Audit number… 8 with Spearbit 

Audit the protocol once again and check its features ██████████████. Oh, and what is ██████████████? Give it time to unravel, but you can already spot many of this article's implementation details and features. See the proposal for the Spearbit audit:

Snapshot

Many amazing teams are building in the lending space. This article is not a diss at any of them. Still, an explanation of why Gearbox DAO and its contributors' narrative, architecture, and direction have currently been chosen - was needed. Any comparisons made are only to show the advantages of Gearbox based on what people are familiar with, not because we think we are the best per se. We welcome different implementations.

At the end of the day, Gearbox is truly modular. A plurality of opinions can be realized through isolated pools, different risk curators, and even different rate offerings within a similar risk structure. Stay safe, and don’t get liquidated. Or be, if that was your choice. 

Your choices stay yours. Onwards!

If you would like to join the DAO — just get involved on Discord. Discuss, research, lead and share. Call contributors out on their bullshit and collaborate on making things better. Here is how you can follow developments:

• Website: https://gearbox.fi/
• Farming dApp: https://app.gearbox.fi/
• PURE margin trading: https://pure.gearbox.fi/
• User Docs: https://docs.gearbox.finance/
• Developer Docs: https://dev.gearbox.fi/
• Github: https://github.com/Gearbox-protocol
• Telegram: https://t.me/GearboxProtocol
• Twitter: https://twitter.com/GearboxProtocol
• Snapshot page: https://snapshot.org/#/gearbox.eth
• And of course, Notion monthly reports:

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

A new tool that blends your everyday work apps into one. It’s the all-in-one workspace for you and your team

Notion