Lending meets Account Abstraction: Gearbox V3

One of the outcomes of crypto being truly open is that an individual can decide how much risk they want exposure to. While choosing the kind of exposure one wants is upto them, it's important that the protocol is able to offer the choice to the user.

Gearbox V1 and V2 had this choice for borrowers (leverage Ninjas as we call them), but the same wasn't entirely available for lenders. Which is why we largely stuck to offering leverage on Bluechip assets, pools and protocols. With V3, we increase the range of choices and leave the decision up to you. V3 and onwards, you can select what you want from the risk buffet. All thanks to the Credit Account {Abstraction}.

Before we begin, we wrote a piece on why Gearbox aims for Onchain Credit as a primitive. You can read it below:

Why account abstraction?

Gearbox's goal is to create a credit primitive that enables you to get more capital, giving you leverage/margin. Got 1 ETH? Borrow 4 more and stake 5 ETH total on Lido or trade on Uniswap. Prime brokerage onchain effectively! This mechanism is a rather common way of securing credit in traditional finance and thus has significant demand. But before we can bring it onchain, there are a few questions that need to be answered.

How do you stay collateralised while doing this?
How do you ensure leverage takers don't rekt borrowed funds and create bad debt on Gearbox?
How do you ensure repayment of borrowed funds?

In the traditional world, legal mechanisms and credit scores try to create the pressure on the borrower to payback. But, that doesn't work onchain due to Credit scores' reliance on trust. DeFi is about reliance on code and math, not convoluted trust systems.

Gearbox's credit Account {abstraction}

Lending mechanisms in general are straightforward:

A user Borrows against collateral -> borrowed funds go to user wallet -> borrower does whatever they want

There are 3 key elements in this entire process: lending protocol, user wallet and protocols where utilisation happens. If we were to map all 3 of these bases to how they are governed, we understand what's required to make Gearbox's leverage through Credit Accounts possible.

The only part of the entire cycle that isn't code governed is the user wallet, which restricts us from delivering on the 3 questions we pointed out above.

Credit Account {abstraction} fixes this

Account abstraction enables users to use a smart contract as their address/account/wallet. It effectively adds a smart contract that holds the user collateral and borrowed funds, as shown below.

Since the contract is programmable, it becomes possible to govern the utilisation of funds by code. You can restrict the number of contracts to which the Credit Account can connect, ensuring borrowed funds only highly interact with liquid and safe contracts. You can even ensure through code that once the user collateral is exhausted or they decide to close an account, the borrowed funds are automatically returned to the Gearbox Lending contracts.

Since only the contracts in the Allowed List can be accessed by the CA, credit on Gearbox can seem more specific purposed. Which is partly true but as we grow the integrations we have, this becomes more generic. You can read more about how V3 pushes us towards this here.

To better it, account abstraction also ensures that the lenders' funds remain over-collateralised, significantly reducing risk of bad debt. In the case of Gearbox, your entire position is your collateral, and your initial collateral is not idle either - it can change if you desire to do so. Don't trust our words anon, verify the math below.

All this makes it possible for users to use other protocols with 5x or even 10x their size. But, that's on the leverage taker front. On the lenders' side, this gets even better...

Lending meets account abstraction

Gearbox V1 and V2 had a one asset-one pool mechanism. All the borrowing for a particular asset happened from 1 pool. But if we increase the number of assets for which funds can be lent, the risk across these assets will vary. Pooling in such a situation generalises the risk to all the lenders in the pool with little customisation. Like every V1 protocol has it in general. And this is where account abstraction delivers 2 key benefits.

Personalised Lending
Risk Adjusted Rates

Personalised lending with V3

Since Credit Accounts(more specifically, Credit Managers, but that’s a know-how under the hood you don’t have to think about too much) can determine where the funds are being utilised, they can categorise how risky the utilisation is. Lenders can thus now choose to personalise lending to their needs.

Here is a cool thread that can shed some more light:

To pool or not to pool, that is the question.

Some thoughts on evolution of crypto lending 🧵 pic.twitter.com/y9tt9ee2aK
— apeir99n ⚙️📦 (@apeir99n) November 1, 2023

Risk Preferences

You decide what risks you want your lent funds to be exposed to. Low, med or high, all depends on the kind of assets you are okay to lend to. It's really as simple as the matrix shown below.

Bluechip Pool: This is the pool that Gearbox V2 has right now, largely used for majors and stables. Simple strategies, lowest risks. Been live for 2 years.
Alpha Pools: Slightly more volatile assets but nothing really extreme. The most volatile assets available on Gearbox at the moment are CRV/CVX/LDO. Which are low-med risk with the available liquidity. So while the risk relative to majors is higher, it's still safe and poses no bad debt issues.
KYC pools: It is possible to create the mechanisms to allow trusted third parties, like identity providers, to perform the KYC and verify the holder of a crypto wallet. The borrowers from these pools would also likely be KYCed leverage users. Narctech? Maybe.

NOTE: Alpha Pools can exist in multiples, and the liquidity they have can be “inherited” by the larger pool it is built upon. That is done to avoid liquidity fragmentation. What it means is that if you are in a risky pool which is built above the safer pool, you technically opt in with your safer pool LP tokens into the risker LP tokens. As such, the safer pool can utilize your liquidity but so can the riskier one. In case there is no demand currently for your liquidity in the riskier pool, your baseline APY is still earned from the main safer pool. That also avoids liquidity fragmentation!

The assets or risk profiles mentioned are an indicator of what's possible. These could increase if the DAO decides to add more assets to the lending market. OR if another DAO decides to have their own little Gearbox, with their own pros… Allowed List and LTVs.

Governance of pools

Governance of pools decides what contracts will the funds be allowed to interact with(managing AllowedList), what their LTVs will be, who can borrow from them and who can lend to them. And with V3, lenders decide what type of governance they want.

$GEAR Governed pools: The mechanism we have right now. Just want to earn passive yields without caring about setting up parameters? Leave up to the DAO, just opt in for your preferred risk and earn.
External DAO pools: Part of a DAO that wants to do treasury management on their own terms? Go ahead and set up your own lending pool. Define the assets and their LTVs that borrowers will be able to access and earn on your treasury, on your terms.
Third Party governed pools: Trust another party to set up pools for you? We don't mind. You can let them govern it
And more: Pools with no governance, automated governance and more would also be possible.

The goal to offer personalisation is to be able to serve more and more segments in lending. You decide HOW you want to lend, Gearbox V3's job is to offer you the modules to do so.

NOTE: Bluechip pools will remain as is but will move to a new architecture. This is required to ensure that the pools are able to function in sync with the other upgraded and new modules of V3. A simple “Migrate” option will be made available to move from current Pools to V3 Bluechip Pools. The protocol and devs have no access to your funds, so you’ll have to opt-in.

Risk adjusted rates

In traditional finance, lending rates rise as risk increases due to the fundamental principles of risk and reward. When lenders perceive a higher level of risk associated with a borrower, they seek a premium to mitigate potential losses and ensure an adequate return on their investment. Which makes logical sense.

With Credit Account {abstraction} enabling us to differentiate between risk profiles, it also enables us to create risk adjusted borrowing rates.

The lower risk Bluechip pool will be cheaper to borrow from while the Alpha pool will be slightly more expensive. This incentivises lenders to opt for the Alpha pool to earn more APYs for slightly higher risk. The borrowers meanwhile will be able to access assets and protocols where they can generate higher APYs and still earn more.

While risk related change in rates is guaranteed, how are the rates to be decided on?

Defining the range of rates

Borrow and Supply rates are crucial to determine the profitability concerned parties achieve. And this is where Gearbox's next big lending market change comes in. While it is closely related to lending, it is related to another key module of Gearbox V3 and we'll talk more about this as we introduce that module.

Let us say though, it's closely related to $GEAR and the tokenomics module. May be you can find some alpha in the larger V3 piece we did! 👀👀

Come join us if you would like to contribute or just vibe — just get involved on Discord or Telegram. Discuss, research, lead and share. Call contributors out on their bullshit and collaborate on making things better.

Website: https://gearbox.fi/
dApp: https://app.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 DAO reports: