# Gearbox Protocol core documentation full export > Full text export for agents and retrieval systems. Use https://docs.gearbox.finance/core/llms.txt for compact routing before loading this file. Source hierarchy and freshness rules: - Static documentation describes protocol mechanics, integration patterns, and operational procedures. - Mutable market facts such as APY, utilization, market availability, supported assets, supported chains, rates, addresses, or live incidents must be verified through Gearbox app, Gearbox Data, governance, security, deployment, or owner-reviewed sources before answering. - Legal, tax, investment, eligibility, suitability, compliance, and privacy questions require Terms, Privacy, Risks, or owner-reviewed materials. Documentation alone is not legal, financial, tax, or investment advice. - URLs shown in each section are canonical docs routes for this exported content. # Protocol concepts Protocol architecture, audiences, core mechanics, economics, governance, and risk references. ## Gearbox Protocol Source: https://docs.gearbox.finance/core/gearbox-protocol File: content/core/gearbox-protocol.mdx Welcome to your team’s developer platform Meet Gearbox ### Permissionless Lending Rails for Onchain Credit At Gearbox, we are making the transition to operating lending businesses onchain frictionless. Purpose built for institutions, asset-issuers and fintechs, our enterprise grade lending stack enables lenders to deploy no-code credit markets instantly. | | | | | Cover image | |---|---|---|---|---| | :toolbox: | Create Permissionless Markets | Build onchain lending businesses on best-in-class infrastructure. | [gearbox-permissionless-for-curators](https://docs.gearbox.finance/core/gearbox-permissionless-for-curators) | [gearboxdocscurate.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/03-gearbox-docs-curate-page.png) | | :money-bill-transfer: | Lend or Borrow | Learn how to make the most of curated opportunities. | [User docs](https://docs.gearbox.finance/core/for-borrowers-farmers) | [gearboxdocsborrow.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/04-gearbox-docs-borrow-page.png) | | :gear-complex: | Understanding Gearbox | Learn about unlocking onchain credit and Gearbox Permissionless. | [About Gearbox](https://docs.gearbox.finance/core/gearbox-protocol) | [gearboxdocsmain.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/01-gearbox-docs-main-page.png) | ![Figure](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/05-gearbox-docs-use-cases-page.png) #### Learn more about Gearbox's unique usecases RWAs, Vaults, Prediction Markets, Onchain Assets, No-DEX lending. Learn about the opportunities Gearbox unlocks. **Helping Mellow x P2P lrt grow 2x** ## Powered by Credit Accounts Source: https://docs.gearbox.finance/core/powered-by-credit-accounts File: content/core/powered-by-credit-accounts.mdx > Credit Accounts are user-owned smart-contract wallets. Add collateral to unlock a credit line and use that account to trade, invest, or stake across integrated protocols while keeping ownership and portability. The protocol checks solvency on every move so risk stays controlled. ## Fragmented UX vs. Wallet-Native Credit **Pool-based lending** Traditional lending protocols silo users' funds in protocol-global pools, limiting capabilities to actively operate with collateral. ![Figure](https://docs.gearbox.finance/assets/docs/shared/legacy-lending.png) **Credit Accounts** By putting collateral, debt, and execution routes inside a single smart contract wallet, users keep ownership while moving through swaps, farming, or RWA flows without repacking positions. Solvency checks sit behind every action so convenience stays aligned with risk controls. ![Figure](https://docs.gearbox.finance/assets/docs/shared/credit-account-lending.png) ### What Credit Accounts enable * **Wider reach to users for apps and institutions:** Complex multi-transaction operations gate non-professional users. Credit accounts abstract execution allowing to focus on effective use of capital. * **Fees and time saving for investors:** Direct redemptions of semi-liquid tokens preserve months of yield, and batched transactions cut gas cost. * **Largest set of supported collaterals:** redemption receipts or Convex-staked positions become usable in a non-custodial, programmable account instead of being limited to prime broker clients. ## Gearbox Protocol – Monad LP Opportunity Source: https://docs.gearbox.finance/core/gearbox-protocol-monad-lp-opportunity File: content/core/gearbox-protocol-monad-lp-opportunity.mdx ### Overview Gearbox is a composable leverage protocol enabling undercollateralized on-chain borrowing through Credit Accounts. Current focus: yield strategies via Midas-issued collateral. **Two ways to participate:** | | Lending | Leverage | | ------- | -------------------------------------------- | ------------------------------------------- | | APY | 6-9% | Up to 20% | | Role | Passive liquidity provider | Active carry trade | | Risk | Indirect exposure, protected by liquidations | Direct collateral exposure | | Lock-up | None | None (subject to Midas redemption schedule) | *** ### Lending Side (Passive) **How it works:** Deposit USDC into the Gearbox pool. Earn yield from borrowers who use Credit Accounts to execute carry trades, borrowing at pool rates to deploy into higher-yielding RWA collateral. Gearbox solvency guardrails protect against borrower default. **Deposit here:** [Gearbox USDC Pool](https://app.gearbox.finance/pools/143/0x6b343f7b797f1488aa48c49d540690f2b2c89751) *** ### Leverage Side (Active) **How it works:** Open a Credit Account, borrow USDC, and deploy into Midas collaterals. Capture the full carry trade spread with leverage. **Yield source:** Direct exposure to mEDGE yield minus borrow cost. Net APY can reach 20% at max leverage (\~7x). **Zero slippage execution:** Gearbox direct integration allows entry/exit without DEX slippage. Redemptions execute at NAV. → [How Direct Redemptions Work](https://docs.gearbox.finance/core/usecase-direct-redemptions) **Open position here:** [mEDGE Leverage Strategy](https://app.gearbox.finance/strategies/open/143/0x1c8ee940b654bfced403f2a44c1603d5be0f50fa) *** ### Risk Framework #### Collateral Exposure: mEDGE Both sides have exposure to mEDGE (Midas EDGE vault). Current composition: → [View mEDGE Holdings](https://midas.app/medge) #### What happens if mEDGE depegs? | Scenario | Lending Side | Leverage Side | | ----------------- | ------------------------------------------------------- | --------------------------- | | Depeg <13% | Protected: liquidations trigger, borrowers absorb loss. | Position may be liquidated. | | Orderly wind-down | Redemptions via direct integration at NAV | Exit at NAV, no slippage | #### Gearbox Solvency Guardrails * **LTV limits:** Credit Accounts enforce max leverage * **Liquidation threshold:** Positions liquidated before insolvency * **Price feeds:** Oracle-based with sanity checks * **Audits:** [Security repo](https://github.com/Gearbox-protocol/security/tree/main/audits) *** ### Summary | | Lending | Leverage | | --------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Target LP | Passive yield seekers | Active DeFi users | | APY | 6-9% | Up to 20% | | Risk | Lower (liquidation buffer) | Higher (direct exposure) | | Effort | Deposit & forget | Manage position | | Deposit | [Pool](https://app.gearbox.finance/pools/143/0x6b343f7b797f1488aa48c49d540690f2b2c89751) | [Strategy](https://app.gearbox.finance/strategies/open/143/0x1c8ee940b654bfced403f2a44c1603d5be0f50fa) | *** ## Gearbox LP Demo Day – Blurb **Project:** Gearbox Protocol **Project Description:** Composable leverage protocol with Credit Accounts enabling undercollateralized on-chain borrowing. Two LP opportunities on RWA yield strategies: * **Lending side:** Passive yield from borrower demand (6-9% APY) * **Leverage side:** Active carry trade via Credit Accounts (up to 20% APY) **Max TVL capacity:** 50M USDC in mid-term (nearest month) until considerable yield dilution.\ Further expansion driven by new collaterals addition. **Yield APY:** 6-9% (lending) / up to 20% (leverage) **Source of yield:** Carry trade between Gearbox borrow rates and Midas RWA collateral (mEDGE). Lenders earn borrow interest + MON incentives; leverage users capture full carry. **Duration of deal:** No lock-up **Audit link:** **Your contact:** Telegram - @OxIlya ## Unlocking credit for RWAs Source: https://docs.gearbox.finance/core/unlocking-credit-for-rwas File: content/core/unlocking-credit-for-rwas.mdx Purpose-built for RWAs, Gearbox’s lending infrastructure combines capital efficiency, compliance-aware execution, and institutional-grade leverage in a way no existing onchain lending protocol can. Most lending protocols treat RWAs like any other ERC-20 token. While this enables basic compatibility, it prevents enforcement of issuer-defined rules such as redemption, settlement, withdrawals, and deposits, leaving RWA credit structurally limited. Gearbox is built differently. Credit is extended at the RWA protocol level, not just the token level. Credit Accounts interact directly with issuer contracts, allowing purpose-specific rules to be enforced by design. This enables compliant, programmable leverage optimized for RWAs, without compromising issuer controls or asset mechanics. ## No DEX dependency Gearbox is built to work with RWA-specific on-chain logic. Credit Accounts interact directly with issuer contracts, ensuring leverage respects the asset’s native lifecycle by design. This direct integration allows credit users to mint and redeem RWAs with borrowed capital, bypassing secondary markets like DEXes altogether. **As a result:** * **Issuers save millions of dollars** for bootstrapping and subsidizing DEX liquidity * **Users save months of yield** by always redeeming at face value instead of selling at discount ## Launch faster, focus on distribution Traditional looping methods don’t suit RWA leverage. They fragment UX with multi-step, multi-protocol transactions and become highly capital-inefficient when redemption periods are long. Most lending protocols require 5+ transactions across the lending platform and the asset issuer to take a leverage on RWA token, effectively limiting access to advanced on-chain users only. #### Gearbox's Benefits: * **Zero DEX Liquidity Required:** With Gearbox, leverage can go live on day one. It eliminates the need for DEX liquidity seeding, working at any size. * **Improved distribution:** User can enter leveraged position in one transaction. * **Capital savings worth months of yield:** * Save time up to **8 periods** of native redemption. * Capital requirements are reduced by **10x**. * Save fees equal to a **month of farming yield**. * **Risk Control:** Automated deleverage reduces liquidation risk, capital stays in user-owned segregated wallet minimizing indirect exposure. ## Compliant interaction by Design It is almost impossible to enforce transfer-agent/compliance obligations on-chain in traditional pools-based lendings. Gearbox is designed for compliant access. * **Position Isolation:** Each user's position is fully isolated, preventing the mixing of assets or risk between accounts. * **Access Control:** Supports KYC- and rules-based access control, including per-account whitelists, jurisdiction filters, and configurable limits. * **On-Chain Enforcement:** Built-in position freezing and granular operation controls (what can be traded, where, and when) allows curator to enforce regulatory obligations on-chain. ***If you're building onchain RWA product, reach out to Gearbox to power it with Distribution-focused UX and capital-efficient execution.*** ## Learn in details | | | | Cover image | |---|---|---|---| | Improve UX and Capital EfficiencyUserbase growth without depending on liquidity | | [Usecase: Direct Redemptions](https://docs.gearbox.finance/core/usecase-direct-redemptions) | [gearboxdocsmain.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/01-gearbox-docs-main-page.png) | ## Credit for Prediction Markets Source: https://docs.gearbox.finance/core/credit-for-prediction-markets File: content/core/credit-for-prediction-markets.mdx Prediction-market shares remain an untapped opportunity for credit due to their unique mechanics, collateral behavior, and the need for optimized risk frameworks. Gearbox is built to support such novel use cases by design: Credit Accounts enable modular configuration of execution rules, while Lending Market parameters can be flexibly adjusted to meet evolving market needs. ## Modular execution rules Gearbox’s modular architecture unifies credit and execution, allowing custom logic to run directly within leveraged positions. The core money-market layer provides additional capital while ensuring positions remain fully collateralized, and specialized modules extend this base with any purpose-specific execution rules. ![Figure](https://docs.gearbox.finance/assets/docs/core/credit-for-prediction-markets/01-modular-execution-rules.png) ## Flexible Risk Controls Prediction-market outcome shares require additional risk oversight due to their unique behavior, such as sharp price movements near resolution. Gearbox’s risk framework is built to operate under uncertainty and adapt to market conditions that may not have been seen before. #### **Key challenges with prediction-market dynamics:** **Shallow liquidity:** Vulnerable to short-term price manipulation and arbitrage, though prices tend to stabilize over the medium term. **High volatility near resolution:** Makes pricing and liquidations significantly more difficult. #### **Gearbox provides a robust set of tools to address these challenges:** **Dual-oracle system** * Protects against short-term manipulation by cross-checking with an alternative source (e.g., a longer TWAP). * The primary oracle handles solvency checks and triggers liquidations. * The secondary oracle detects divergence and blocks sensitive operations when prices disagree. **LT ramping** * Gradually reduce exposure as markets approach maturity. * Adjustable slope and duration ensure borrowers deleverage in time, protecting LPs. **Loss policy** * Adds protective logic for liquidations that could create bad debt. * Prevents liquidation cascades and defends LPs against manipulation-driven loss scenarios. **If you’re building credit for prediction markets, reach out to Gearbox for the infrastructure so you can focus on product.** ## Manual Deleveraging When UI Actions Are Unavailable Source: https://docs.gearbox.finance/core/manual-deleveraging-when-ui-actions-are-unavailable File: content/core/manual-deleveraging-when-ui-actions-are-unavailable.mdx If the **Close** or **Swap** action is unavailable or fails, you can exit your position manually by following the steps below. ## Withdraw collateral Withdrawing collateral sends the token to your wallet, where you can swap it freely using external liquidity sources outside of Gearbox. > Withdrawing collateral reduces your position’s **Health Factor**. A large withdrawal may push the position into liquidation risk. \ \ Always check the projected **Health Factor** before each withdrawal.
Withdraw collateral in the UI ![Figure](https://docs.gearbox.finance/assets/docs/core/manual-deleveraging-when-ui-actions-are-unavailable/01-withdraw-collateral.png)
> If your current **Health Factor** does not allow for a safe withdrawal, repay part of your debt first using the Debt Token from your wallet (see **Step 3**). ## Swap collateral into the Debt Token Swap the withdrawn collateral into the Debt Token using external liquidity sources. Recommended options include: * DEX aggregators * Official liquidity venues provided by the collateral issuer ## Repay debt using Debt Token from your wallet > Repay the debt using the **same token the debt is denominated in**, directly from your wallet. > Check whether the updated **Health Factor** allows for further withdrawal.
Repay debt in the UI ![Figure](https://docs.gearbox.finance/assets/docs/core/manual-deleveraging-when-ui-actions-are-unavailable/02-repay-debt-using-debt-token-from-your-wallet.png)
## Repeat Steps 1-3 until your Credit Account reaches the desired state or is fully unwound ## Guide for Asset Issuers Source: https://docs.gearbox.finance/core/guide-for-asset-issuers File: content/core/guide-for-asset-issuers.mdx Most lending protocols treat complex DeFi asset like any other ERC-20 token. While this enables basic compatibility, it prevents enforcement of issuer-defined rules such as redemption, settlement, withdrawals, and deposits. Gearbox is built differently. Credit is extended at the asset's protocol level, not just the token level. Credit Accounts interact directly with issuer contracts, allowing purpose-specific rules to be enforced by design. ## No DEX dependency Gearbox is built to work with asset-specific on-chain logic. Credit Accounts interact directly with issuer contracts, ensuring leverage respects the asset’s native lifecycle by design. This direct integration allows credit users to mint and redeem assets with borrowed capital, bypassing secondary markets like DEXes altogether. This is especially important for assets with longer redemption periods, as DEX liquidity is costly and ineffective there. **As a result:** * **Issuers save millions of dollars** for bootstrapping and subsidizing DEX liquidity * **Users save months of yield** by always redeeming at face value instead of selling at discount ## Launch faster, focus on distribution Traditional looping methods don’t suit leverage for novel assets. They fragment UX with multi-step, multi-protocol transactions and become highly capital-inefficient when redemption periods are long. Most lending protocols require 5+ transactions across the lending platform and the asset issuer to take a leverage on asset, effectively limiting access to advanced on-chain users only. #### Gearbox's Benefits: * **Zero DEX Liquidity Required:** With Gearbox, leverage can go live on day one. It eliminates the need for DEX liquidity seeding, working at any size. * **Improved distribution:** User can enter leveraged position in one transaction. * **Capital savings worth months of yield:** * Save time up to **8 periods** of native redemption. * Capital requirements are reduced by **10x**. * Save fees equal to a **month of farming yield**. * **Risk Control:** Automated deleverage reduces liquidation risk, capital stays in user-owned segregated wallet minimizing indirect exposure. ## Widest collateral support & direct DeFi integration Credit Accounts accept nearly any on-chain position as collateral: LP tokens, staked assets, vault shares, and non-tokenized positions such as redemption receipts. This expands TVL, deepens liquidity, and unlocks leveraged versions of your asset’s native strategies. ***If you want to grow your DeFi product, whether it’s an LRT, vault, or any other productive collateral, reach out to Gearbox to power it with Distribution-focused UX and capital-efficient execution.*** ## Case studies | | | Cover image | |---|---|---| | P2P vault growthHow P2P's mellow LRT has grown from 25k to 45k restaked wstETH | [case-study-mellow-x-p2p-lrt-growth-powered-by-gearbox](https://docs.gearbox.finance/core/case-study-mellow-x-p2p-lrt-growth-powered-by-gearbox) | [gearboxdocsmain.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/01-gearbox-docs-main-page.png) | ## Learn in details | | Cover image | | |---|---|---| | Direct redemptionsUsers save months of yield; Asset issuers - millions on DEX incentives | [gearboxdocscurate.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/03-gearbox-docs-curate-page.png) | [Usecase: Direct Redemptions](https://docs.gearbox.finance/core/usecase-direct-redemptions) | | User-first executionIntegrate leverage into product offering as if it were there by design | [gearboxdocsborrow.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/04-gearbox-docs-borrow-page.png) | [Adapters & Integrations](https://docs.gearbox.finance/core/adapters-integrations) | ## Seamless LP migration Source: https://docs.gearbox.finance/core/seamless-lp-migration File: content/core/seamless-lp-migration.mdx ### Why migrate (what you gain as an LP) **In short:** better incentives and better market coverage. > As Gearbox transitions to the permissionless curation model, rewards and activity shift to the new pools. Old pools will stop receiving rewards and become non-competitive over time. New pools are where curators focus liquidity and opportunities. New Curator pools combine two reward streams: * baseline, time-weighted TVL incentives to bootstrap passive liquidity * performance-based rewards proportional to the Curator’s revenue share. In practice, the aggregate rewards allocated to the permissionless model are about 3x the legacy LM run-rate, with dilution tied more closely to real usage and protocol revenue (supporting buybacks). As a result, effective yield in new pools is expected to be higher than in legacy pools. *** ### Purpose This LP migration contract is designed to allow users migrate liquidity without monitoring the pools for available liquidity: * Designed for the case where immediate migration is not possible due to liquidity constraints. * Users can pre-sign their intention to migrate by granting allowance to the migration contract. * The migration will be executed by the instance owner multisig as soon as liquidity becomes available. In other words, this contract is a safe automation tool: * You lock in your intent to move from the old pool to the new one. * You don’t have to monitor liquidity or time the transaction yourself. * The migration will happen at the first opportunity. *** #### How it Works There are only two functions in the migration contract: 1. User function (allowance setup) * You give the migration contract allowance for your LP tokens in the old pool. * This does not move funds immediately — it only means: > “Whenever possible, please take my LP tokens from the old pool and put them into the new pool.” * After signing, you are done. 2. Instance owner function (execute migration) * Can only be called by the instance owner multisig (chain-specific). However, instance owner can't do anything except for migrating liquidity between the pools specified by user. * Once liquidity becomes available, they trigger the migration: * LP tokens are redeemed from the old pool. * Assets are deposited into the new pool on behalf of the user. * Both *old pool* and *new pool* are fixed parameters of the contract and cannot be changed. *** #### Safety of Allowance * **Immutable destination:** your funds can only move old pool → new pool. * **No arbitrary spending:** allowance is strictly limited to the old pool LP tokens. * **Controlled execution:** the migration logic is minimalistic and fixed in contract. Even if instance owner multisig goes malicious, its actions can't result in user losing money. *** #### Migration Lifecycle 1. User grants allowance * Approves their LP tokens to be used by migration contract. 2. Monitoring phase * Liquidity in old pools may be fully utilized (100%). * Gearbox contributors monitor until withdrawals are possible. 3. Execution phase * Instance owner calls the migration function at the first chance. * Funds are moved automatically on behalf of the user who granted the allowance. 4. Completion * Users now hold LP tokens in the new pool. * Yield continues seamlessly. *** ### Why now (governance & versions) Gearbox is moving from V3.0 to V3.1 to solidify the permissionless governance direction. Under permissionless curation, DAO-approved curators can configure markets and parameters, and the protocol can scale across networks without slow, centralized bottlenecks. **This migration is happening because:** * Maintaining two versions is technically **complex and fragments liquidity.**\ Supporting both legacy pools and new permissionless pools in parallel would complicate operations and potentially reduce yields for everyone. Consolidating liquidity in the new system is safer and more efficient. * Legacy pools had the **DAO as the sole curator - this is changing.**\ In the permissionless model, curators manage markets directly within clear, on-chain constraints. So legacy pools either need to be turned off or migrated to preserve TVL in the ecosystem. * It’s **better for LPs.**\ Rewards and curator attention move to the new pools. Old pools will become non-competitive over time. Specialized curators are expected to maintain attractive rates more consistently than DAO-only governance, because they operate faster and stay deeper in the market. *** #### Batching and timelines To reduce multisig overhead and make the best use of liquidity windows, we process migrations in batches. * **Positions up to $1,000,000.**\ Migrated in full within the nearest suitable batch. * **Positions above $1,000,000.**\ Moved in several chunks. This is normal and helps keep utilization healthy while your position transitions. * **Target batch size.**\ We aim to group requests into roughly $1,000,000 batches to execute efficiently when liquidity allows. * **FIFO queueing.**\ LP requests are processed in chronological order. This keeps the process transparent and predictable. * **Timing.**\ Your migration may wait while a batch fills. The maximum wait time will not exceed 14 days. #### FAQ * **Can the migration contract move my funds anywhere else?**\ No. It can only move LP from the specific old pool to the specific new pool you selected. * **Why would APY be higher in the new pools?**\ New pools stack baseline TVL incentives with performance-based rewards linked to real fee generation. The overall incentive budget for the permissionless phase is roughly 3x legacy LM, with dilution aligned to revenue (supports buybacks), so effective yields are expected to be superior versus legacy pools. * **What if utilization in the old pool is 100% for a while?**\ We keep your request in the FIFO queue and execute at the first safe window. Batching helps reduce delays. * **Do I keep earning yield?**\ Yes. After migration you hold LP in the new pool and continue earning according to its parameters and incentives. ## Credit Account migration Source: https://docs.gearbox.finance/core/credit-account-migration File: content/core/credit-account-migration.mdx ### Why migrate (what you gain as a Borrower) **In short:** incentives, better execution and more favorable rates. **Incentives:** * One-time fixed reward paid in GEAR. Distributed retroactively. **Better execution:** * Improved routing and support for new adapters increases capital efficiency and reduces costs. **Favorable rates:** * Vote-based collateral-specific rate discovery is depreciated in favor of curator-controlled rates. ### Requirements for allowing a migration into your Market 1. All the collaterals of old account should be allowed in a credit manager of target Market 2. The position can be only migrated as a whole, target Market should have appropriate debt limits and capacity. 3. If the underlying token is changed during migration, new market must support swaps from new underlying to old one.\ E.g. you can migrate rstETH from an old wstETH pool to a new WETH pool, but WETH -> wstETH swap must be allowed in the new pool. ### How it works 1. New credit account is opened in a target market 2. Amount of tokens enough to repay old account is borrowed from a new account 3. Newly-borrowed tokens are swapped into underlying tokens of old account 4. Old account's debt is repaid and its collateral is transferred to the new account ## Gearbox Permissionless for Curators Source: https://docs.gearbox.finance/core/gearbox-permissionless-for-curators File: content/core/gearbox-permissionless-for-curators.mdx Gearbox Permissionless provides the operational rails for institutions, asset managers, and fintechs to deploy onchain credit markets. **Curator**, acts as the operator of a standalone lending vertical. This role is designed for entities seeking to retain full ownership of their market's risk parameters and economic model, while leveraging Gearbox’s battle-tested settlement engine to handle execution, solvency, and compliance. This page outlines the operational model and strategic advantages of the Gearbox curation stack. ## Market Curation, Not Fund Management In many onchain lending models, curation requires active capital reallocation, manually moving funds between vaults to chase yield. This creates significant operational burden and can inadvertently classify operators as financial intermediaries or asset managers. **The Gearbox Approach:**\ Curators manage **Parameters**, not **Funds**. * **Non-Custodial:** Curator defines the rules (LTVs, Interest Rate Models), but never possesses or controls user funds. * **Automated Execution:** The protocol automatically allows credit usage within allowed limits and enforces solvency based on pre-defined logic. * **Compliance Benefit:** This passive model allows you to operate a lending business without engaging in active fund management activities. ## Structured Credit Products Standard lending markets are commoditized, offering simple borrowing against collateral. Gearbox enables Curators to structure complex **Credit Products**. * **Strategy Integration:** Deploy markets that offer native access to specific yield strategies (e.g., Leveraged Staking, Basis Trading, or RWA accumulation). * **Capital Efficiency:** By integrating execution directly into the credit account, Curators can offer higher leverage ratios with tighter risk controls than standard over-collateralized lending. ## Institutional-Grade Risk Framework For asset issuers and fund managers, security is the primary constraint. Gearbox provides a multi-layered safety stack designed for high-value deployments. * **Dual-Oracle Architecture:** Markets utilize a primary and secondary oracle source to prevent price manipulation and ensure accurate mark-to-market valuations. * **Automated Insolvency Resolution:** The "Loss Policy" mechanism provides pre-defined logic for handling bad debt events, protecting Liquidity Providers from black swan scenarios. * **Granular Access Control:** Curators can deploy permissioned instances, utilizing allowlists for borrowers or lenders to meet KYC/AML requirements. ***If you’re expanding your product offering, reach out to Gearbox to power your lending vertical with superior UX and a safety-first design.*** ![Figure](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/01-gearbox-docs-main-page.png) #### Get started Create a market and make first steps towards launching a lending product. **Become a Market Curator** ## Learn in details | | Cover image | | |---|---|---| | Collateral-specific ratesNon-custodial by design. Capital-efficient by default | [gearboxdocsmain.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/01-gearbox-docs-main-page.png) | [Collateral Limits & Specific Rates](https://docs.gearbox.finance/core/collateral-limits-specific-rates) | | Dual-oracle system & bad debt preventionA safety-first mechanisms for LP protection | [gearboxdocscurate.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/03-gearbox-docs-curate-page.png) | [Smart Oracles](https://docs.gearbox.finance/core/smart-oracles) | | Multichain ScalingGrow across ecosystems with ready-to-use infrastructure | [gearboxdocsborrow.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/04-gearbox-docs-borrow-page.png) | [Omni-EVM Architecture](https://docs.gearbox.finance/core/omni-evm-architecture) | | Native integrations for superior UXOffer users best-in-class capital-efficiency | [gearboxdocuses.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/05-gearbox-docs-use-cases-page.png) | [Adapters & Integrations](https://docs.gearbox.finance/core/adapters-integrations) | ## Quota increase fee Source: https://docs.gearbox.finance/core/quota-increase-fee File: content/core/quota-increase-fee.mdx When user increases Quota (Credit Account specific max amount of debt that can be backed by particular collateral), charge a fixed % fee on the quota difference: works like a one-time fee charged on swaps by exchanges. Added to account's Debt. Distributed as a DAO & Curator fee on repayment according to the fee split rules. ## Wallet-native Credit powered by Credit Accounts Abstraction Source: https://docs.gearbox.finance/core/wallet-native-credit-powered-by-credit-accounts-abstraction File: content/core/wallet-native-credit-powered-by-credit-accounts-abstraction.mdx > One Click, Infinite Utility: No more bridging to external dApps. No more locking assets in inaccessible vaults. Your wallet is the protocol. ## Transforming Wallets into Crypto Neobanks Imagine a bank account where you can only store money, not borrow or use credit. That’s what most crypto wallets look like today. Gearbox changes the landscape of decentralized finance by embedding a credit layer directly into wallets, turning them into “Crypto Neobanks”. Users gain access to credit lines against their existing collateral. Gearbox serves as the invisible “credit rails,” while the Wallet Provider acts as the user-facing financial app. ### Native Credit Integration via Account Abstraction The user doesn't see complex smart contract interactions. They simply toggle "Credit Mode" or switch to their "Credit Account" tab, just like switching between a Credit and Savings account ### Seamless DeFi compatibility Unlike traditional lending protocols that lock your assets away, the system recognizes tokens in the wallet as collateral automatically. Users don't just "borrow" funds; they use them. The credit line works across major DeFi protocols (Uniswap, Curve, Pendle). ### Two Modes, One Wallet **For the Spender (The "Crypto Credit Card"):** Integrate with Gnosis Pay/Holyheld or other crypto cards. Users can pay for groceries and daily needs using a stablecoin credit line. **For the Investor (The "DeFi Powerhouse"):** Execute complex strategies (e.g., "Invest into fixed-yield PT token with 5x leverage") directly from the wallet UI. No need for external operational overhead. ## Proof of concept **(Coinbase Wallet Example)** The integration requires no clunky approvals for every action. The wallet recognizes the Credit Account as a native environment, enabling a smooth, "Web2-like" financial experience. []() ***If you’re building wallet-native credit, reach out to Gearbox to power it with seamless execution and a superior UX.*** ## Learn in details | | Cover image | |---|---| | How it works | [gearboxdocsmain.png](https://docs.gearbox.finance/assets/docs/core/gearbox-permissionless-for-curators/01-gearbox-docs-main-page.png) | | | | ## Audits and Bug Bounty Source: https://docs.gearbox.finance/core/audits-and-bug-bounty File: content/core/audits-and-bug-bounty.mdx ## Case Study: Mellow x P2P LRT growth powered by Gearbox Source: https://docs.gearbox.finance/core/case-study-mellow-x-p2p-lrt-growth-powered-by-gearbox File: content/core/case-study-mellow-x-p2p-lrt-growth-powered-by-gearbox.mdx ## Summary The synergy between Gearbox’s distribution-focused UX and its tailored rewards structure enabled the creation of a balanced two-sided market, allowing depositors to boost their wstETH staking yield, while leverage users executed strategies that combined points rewards with realized, liquid returns. *These combined efforts helped the rstETH vault grow from 21k to 45k restaked wstETH.* ## Involved parties [**P2P.org**](https://p2p.org) is the leading institutional-grade staking provider providing a wide line of products for Asset Manager, Wallets, Banks and more. [**Mellow.finance**](https://mellow.finance) is a liquid vaults stack that enables permissionless creation of variety of products, including actively managed tokenized funds, LRTs, distributed validator vaults and more. [**Gearbox.finance**](https://gearbox.finance/) acting as a lending stack powering Deposit Pool for earning boosted wstETH yield and Leverage Strategy allowing to take leveraged exposure on Restaking rewards. ## Key features ### Gearbox's distribution-focused UX An intuitive UI and single-transaction execution let users open leveraged positions without slippage, with routing handled directly through the Mellow vault minting smart contract. Mellow, P2P clients, and broader DeFi participants including funds and individual farmers can access leveraged yield strategies through a simple, secure experience that preserves both security and capital efficiency.
![Image](https://docs.gearbox.finance/assets/docs/core/case-study-mellow-x-p2p-lrt-growth-powered-by-gearbox/01-intuitive-leverage-ui.png)
Intuitive leverage UI
### P2P & Mellow's structured product offering Rather than relying on unsustainable incentives or short-lived points valuations, P2P and Mellow adopted a balanced model that blends Symbiotic and Mellow points exposure with liquid incentives creating an attractive yield profile without sacrificing direct economic benefits. * **Leverage users earned points with a discounted multiplier**\ Instead of receiving 10× points for 10× leverage, users earned 40% of the total points, while the remaining 60% went to addresses supplied by P2P. * **Discounted points were offset with liquid wstETH rewards**\ Each leveraged rstETH position earned a fixed incentive APR paid in liquid tokens, balancing long-term reward exposure with realized profit. All key Gearbox usage metrics are fully transparent on-chain, enabling flexible, data-driven incentive campaigns tailored to real user needs. ## Outcome The campaign brought more than 24k new wstETH deposits into the rstETH vault, demonstrating the effectiveness of Gearbox’s powerful UX and the flexibility of its product engineering. ![Figure](https://docs.gearbox.finance/assets/docs/core/case-study-mellow-x-p2p-lrt-growth-powered-by-gearbox/02-p2p-lrt-growth-tvl.png) P2P LRT growth. TVL contribution is split between Mellow deposits and Gearbox-induced TVL Source query ***If you want to grow your DeFi product, whether it’s an LRT, vault, or any other productive collateral, reach out to Gearbox to power it with Distribution-focused UX and capital-efficient execution.*** ## About Gearbox Source: https://docs.gearbox.finance/core/about-gearbox File: content/core/about-gearbox.mdx Gearbox is onchain credit infrastructure for building lending and leverage products. It connects passive capital in pools with borrowers who use Credit Accounts to take positions across approved partner protocols. The core primitive is simple: a **Credit Account is a wallet with credit**. It can hold collateral, borrow from a pool, and execute approved actions, while every action must keep the account solvent under protocol rules. Gearbox started in 2021 as a protocol for DeFi investing with leverage. It then evolved through V2, V3, and V3.1 from a strategy-focused leverage product into infrastructure for purpose-built credit markets, RWA-backed debt positions, and wallet-native lending products. The current architecture combines two goals: - **Wallet-like UX:** users or products operate through an account that can hold assets, debt, and execution routes in one place. - **Lending-protocol efficiency:** capital is supplied by pools, priced through protocol parameters, and protected by solvency checks, liquidation rules, and debt ceilings. ## Two sides of the system ### Pool side: passive capital A pool is the savings product in Gearbox. Lenders deposit an asset into a pool and earn yield from interest paid by borrowers using that liquidity. The pool does not make strategy decisions for each borrower. It allows borrowing by Credit Accounts under explicit debt ceilings. This keeps passive capital aggregated while limiting how much exposure any one market or strategy can take from the pool. A pool is not a bank deposit or guaranteed yield product. It is an onchain lending position with protocol, market, liquidity, and liquidation risk. ### Credit Account side: wallet with credit A Credit Account is a user-controlled smart-contract account that combines collateral, debt, and approved execution routes. Borrowers do not receive unrestricted funds. They operate inside a Credit Account. The account can interact with approved partner protocols, but each action is checked against collateral values, Liquidation Thresholds, allowed assets, and market-specific rules. This lets a product expose a wallet-like experience while the protocol enforces credit boundaries in the background. ## How capital moves 1. Lenders deposit assets into a pool. 2. The pool allows borrowing by Credit Accounts within configured debt ceilings. 3. Borrowers open or use Credit Accounts. 4. Credit Accounts deploy borrowed liquidity into approved strategies or products. 5. Borrowers pay interest back to the pool. 6. Solvency checks and liquidation rules protect the pool when a Credit Account becomes unsafe. ## What this enables For lenders, Gearbox turns a pool into a passive lending product. The lender does not need to choose every borrower or strategy manually, while risk remains bounded by market configuration. For borrowers, Gearbox turns leverage into an account-level credit line. The borrower can use capital inside a Credit Account without repeatedly moving assets through separate lending, trading, and strategy interfaces. For curators and builders, Gearbox provides the infrastructure to create specialized credit products. A market can define supported assets, debt ceilings, rates, oracle rules, and liquidation parameters for a specific use case. ## Where to go next - [One Pool, Many Markets](https://docs.gearbox.finance/core/one-pool-many-markets): how one passive liquidity source can fund multiple isolated markets. - [Credit Accounts (The Primitive)](https://docs.gearbox.finance/core/credit-accounts-the-primitive): the account model that makes wallet-native credit possible. - [Pool (The Liquidity Vault)](https://docs.gearbox.finance/core/pool-the-liquidity-vault): how passive lending capital is deposited, represented, and used. - [Gearbox Permissionless for Curators](https://docs.gearbox.finance/core/gearbox-permissionless-for-curators): how curators create and operate markets. ## One Pool, Many Markets Source: https://docs.gearbox.finance/core/one-pool-many-markets File: content/core/one-pool-many-markets.mdx Gearbox Protocol separates the source of liquidity from the utilization of liquidity. This architecture allows a single passive liquidity source to fund diverse, isolated lending strategies simultaneously. ![Figure](https://docs.gearbox.finance/assets/docs/core/one-pool-many-markets/01-one-pool-many-markets.png) ### The Wholesale Bank Model To understand the flow of capital, view the architecture through the analogy of a banking system: #### 1. The Pool (The Wholesale Bank) The Liquidity Pool acts as a **Wholesale Bank**. It is a massive, passive reservoir of capital (e.g., USDC, WETH, or DAI). * **Role:** It accepts deposits from lenders and holds the funds securely. * **Mandate:** It does not lend directly to end-users. Instead, it lends capital to "Retail Branches" (Credit Suites) based on strict credit limits. #### 2. Credit Suites (The Retail Branches) Credit Suites (technically "Credit Managers") act as **Retail Branches**. Each branch is a specialized lending product with a specific mandate. * **Role:** They borrow liquidity from the Wholesale Bank (Pool) to fund Credit Accounts for users. * **Mandate:** Each suite defines a specific strategy, such as "Low-Risk Stablecoin Farming" or "High-Leverage ETH Staking." ![Figure](https://docs.gearbox.finance/assets/docs/core/one-pool-many-markets/02-2-credit-suites-the-retail-branches.png) This separation allows the protocol to offer low-risk and high-risk products side-by-side without fragmenting liquidity. ### Risk Isolation (Debt Ceilings) In a monolithic lending protocol, bad debt in one asset can drain the entire pool. Gearbox prevents this via **Risk Isolation**. The Pool assigns a **Debt Ceiling** to each Credit Suite. This is the maximum amount of capital that specific branch can borrow from the bank. * **Scenario:** A Pool holds $100M USDC. * **Allocation:** * $80M is allocated to a "Blue Chip Strategy" (Low Risk). * $10M is allocated to an "Emerging Asset Strategy" (High Risk). * **Isolation:** If the "Emerging Asset Strategy" suffers a catastrophic failure, the maximum loss to the Pool is capped at $10M. The remaining $90M is mathematically isolated from that specific risk vector. This ensures that lenders are protected from the tail risks of specific aggressive strategies, while still benefiting from the higher utilization they generate. ### The Diesel Token (Unified Yield) Lenders interact only with the Pool. When they deposit assets, they receive **Diesel Tokens** (e.g., dUSDC, dWETH). * **Unified Exposure:** The Diesel Token represents a pro-rata share of the entire Wholesale Bank's assets. * **Aggregated Yield:** The yield is generated by the interest paid by *all* connected Credit Suites. Whether the capital is used for staking, farming, or trading, the interest flows back to the Pool and appreciates the value of the Diesel Token. This abstracts the complexity of multiple markets away from the lender. The lender provides liquidity once and earns a blended yield from a diversified basket of on-chain credit strategies. ### Learn More * **Technical Implementation:** How the passive vault handles deposits and withdrawals. * [pool](https://docs.gearbox.finance/core/pool-the-liquidity-vault) * **Market Configuration:** How specific rules and strategies are defined for each branch. * [credit-suite](https://docs.gearbox.finance/developers/credit-suite) ## Credit Accounts (The Primitive) Source: https://docs.gearbox.finance/core/credit-accounts-the-primitive File: content/core/credit-accounts-the-primitive.mdx The Credit Account is the fundamental primitive of the Gearbox Protocol. It functions as a user-owned, isolated smart contract wallet that holds both collateral and borrowed funds, enabling leveraged execution across DeFi protocols. ### Core Concept: Isolated Smart Contract Wallet Unlike traditional lending protocols where user collateral is siloed in a global vault, Gearbox deploys a unique smart contract for each borrower. ![Figure](https://docs.gearbox.finance/assets/docs/shared/legacy-lending.png) The Credit Account serves as a container for the user's entire position. * **Segregated State:** Assets within the Credit Account are legally and technically distinct from the protocol's liquidity pools. * **User Ownership:** The user retains control over the account's operations, subject only to the solvency checks enforced by the Credit Manager. * **Portability:** Because the Credit Account is a standard smart contract, it can interact with external protocols as a distinct entity, preserving the identity of the position. ### Atomic Solvency Check The Credit Account operates on a "Check-on-Exit" architecture. The protocol does not restrict specific actions within a transaction bundle, provided the account remains solvent at the conclusion of the execution trace. Upon the completion of any interaction (e.g., a swap or deposit), the protocol calculates the account's **Health Factor**. * **If Health Factor > 1:** The transaction is finalized and recorded on-chain. * **If Health Factor < 1:** The entire transaction reverts, ensuring no bad debt can be created atomically. This mechanism allows users to perform complex, multi-step operations in a single transaction without requiring the protocol to understand the intermediate states, as long as the final state satisfies the risk parameters. ![Figure](https://docs.gearbox.finance/assets/docs/shared/credit-account-lending.png) ### Composability via Adapters The Credit Account interacts with the external DeFi ecosystem through **Adapters**. These are lightweight contract interfaces that translate generic user intents into protocol-specific function calls. From the perspective of an external protocol, the Credit Account appears as a standard user wallet. This enables: 1. **Native Execution:** Users interact directly with external contracts rather than through a protocol-specific abstraction layer. 2. **Programmable Credit:** Developers can compose credit logic into arbitrary workflows, treating the Credit Account as a programmable leverage module. *** ### Learn More * **Risk Enforcement:** the logic for calculating the Health Factor and enforcing solvency is managed by the Credit Manager and Credit Facade. * [credit-suite](https://docs.gearbox.finance/developers/credit-suite) * **External Interactions:** The mechanism for connecting Credit Accounts to external DeFi protocols is defined by the Adapter system. * [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) * **Liquidity Source:** The capital borrowed by the Credit Account is sourced from the passive Liquidity Pool. * [pool](https://docs.gearbox.finance/core/pool-the-liquidity-vault) ## Omni-EVM Architecture Source: https://docs.gearbox.finance/core/omni-evm-architecture File: content/core/omni-evm-architecture.mdx Gearbox Protocol is designed as a **Deployable Primitive** rather than a monolithic cross-chain application. It does not rely on bridges for message passing or state synchronization between chains. Instead, every deployment on a new chain is a standalone, self-contained **Instance**. This architecture ensures that risk is isolated to the specific chain and that the protocol can scale permissionlessly to any EVM-compatible network without waiting for centralized bridge infrastructure. ### Modular Instances An **Instance** is a complete, functional replica of the Gearbox Protocol deployed on a specific blockchain network. * **Independence:** Each Instance operates autonomously. A failure or pause on one chain does not propagate to others. * **No Bridge Dependency:** Core protocol functions (borrowing, lending, liquidations) do not require cross-chain messaging. * **Local Configuration:** Parameters are tuned specifically for the local ecosystem (e.g., block times, gas costs, and available liquidity) rather than inheriting global defaults that may not fit. This modularity allows the protocol to exist natively on high-speed L2s or sidechains while maintaining the security standards established on Mainnet. ### Bytecode Repository (Verifiable Deployment) To ensure security across many independent instances, Gearbox utilizes a **Bytecode Repository**. This acts as an onchain "Source of Truth" for protocol logic. 1. **Global Verification:** The Gearbox DAO votes to approve specific contract versions (e.g., `CreditFacade V3.1`) after audits are completed. 2. **Onchain Storage:** The compiled bytecode of these approved contracts is stored in the Bytecode Repository on the canonical chain. 3. **Trustless Deployment:** When a new Instance is deployed or updated, the factory contracts verify that the code being deployed matches the authorized bytecode in the repository. This mechanism guarantees that every Instance, regardless of who deployed it, runs the exact, audited code approved by the DAO. ### Governance Architecture Because Instances are independent, governance is split into **Global** (Code & IP) and **Local** (Configuration & Risk) layers. This separation of concerns allows for efficient scaling without creating a bottleneck at the DAO level. | Entity | Scope | Responsibility | | ------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------- | | **Protocol DAO** | Global (All Chains) | Manages the codebase, approves new versions, and governs the Bytecode Repository. | | **Instance Owner** | Local (One Chain) | A technical multisig responsible for chain-specific infrastructure, such as whitelisting local price feeds. | | **Market Curators** | Local (Specific Markets) | Independent operators who deploy lending markets and manage economic risk parameters (LTVs, Rates). | ### Learn More * **Protocol ownership:** How are the token holders' financial interests and the delivery of the core codebase managed? * [protocol-dao](https://docs.gearbox.finance/core/protocol-dao) * **Chain-specific oversight:** Safe operation within a chain. * [instance-owner](https://docs.gearbox.finance/core/instance-owner) * **Markets growth:** Who manages business building and specific risk parameters? * [market-curators](https://docs.gearbox.finance/core/market-curators) ## For Lenders & LPs Source: https://docs.gearbox.finance/core/for-lenders-lps File: content/core/for-lenders-lps.mdx #### Phase 1: Structural Risk Assessment (Mental Model) **User Intent:** Evaluate the fundamental architecture to determine if the risk segregation meets investment mandates. | Key Question | System Answer | Sitemap Component | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **"How is liability vs. asset risk structured?"** | **Segregated Risk Architecture.** The protocol decouples passive liquidity (Pool) from active risk strategies (Credit Managers). A failure in one strategy is contained by its specific debt ceiling, protecting the broader pool. | [one-pool-many-markets](https://docs.gearbox.finance/core/one-pool-many-markets) | | **"Is the deployment canonical?"** | **Omni-EVM Architecture.** Gearbox utilizes a modular deployment model. Each chain operates as an independent, verified instance rather than a bridged dependency. | [omni-evm-architecture](https://docs.gearbox.finance/core/omni-evm-architecture) | #### Phase 2: Yield Mechanics & Liquidity Risk **User Intent:** Analyze the mechanism of yield accrual and the constraints on capital withdrawal. | Key Question | System Answer | Sitemap Component | | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **"How does capital accrue interest?"** | **The Liquidity Vault.** Yield accrues via the Diesel Token (ERC-4626), a non-rebasing interest-bearing token. The exchange rate appreciates as interest is paid by borrowers. | [pool](https://docs.gearbox.finance/core/pool-the-liquidity-vault) | | **"What drives APY volatility?"** | **Interest Rate Model.** The base rate is dynamic, driven by the utilization curve. The "Kink" ($U\_{optimal}$) defines the target efficiency range before rates scale exponentially. | [interest-rate-model](https://docs.gearbox.finance/core/interest-rate-model) | | **"What is the liquidity risk?"** | **Utilization Caps.** High utilization can temporarily block withdrawals. The Interest Rate Model is designed to force borrower repayment during these periods to restore exit liquidity. | [interest-rate-model](https://docs.gearbox.finance/core/interest-rate-model) | #### Phase 3: Counterparty Risk & Solvency Enforcement **User Intent:** Assess the creditworthiness of the borrowers and the automated enforcement of debt obligations. | Key Question | System Answer | Sitemap Component | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **"What prevents fund misappropriation?"** | **Execution Guardrails.** Borrowers cannot access funds directly. They operate through **Credit Accounts** (smart contract wrappers) restricted to whitelisted interactions via Adapters. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) \ [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | | **"How is solvency enforced?"** | **Liquidation Dynamics.** Solvency is enforced mathematically via the Health Factor ($H\_f$). If $H\_f < 1$, the protocol incentivizes third-party liquidators to seize collateral and repay debt. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"How are assets valued?"** | **Price Oracle.** Asset valuation relies on normalized price feeds. Understanding the oracle source (Spot vs. TWAP) is critical for modeling liquidation triggers. | [price-oracle](https://docs.gearbox.finance/core/price-oracle) | #### Phase 4: Stress Testing & Failure Modes **User Intent:** Evaluate system resilience under adverse market conditions (Oracle attacks, Liquidity crunches). | Key Question | System Answer | Sitemap Component | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **"Is the system resilient to oracle manipulation?"** | **Smart Oracles.** The protocol employs a Dual-Feed architecture (Main vs. Reserve). Significant deviation between feeds blocks sensitive operations to prevent arbitrage. | [smart-oracles](https://docs.gearbox.finance/core/smart-oracles) | | **"How is concentration risk managed?"** | **Quota Keeper.** The protocol enforces **Asset-Side Limits**. Even if the pool has excess liquidity, exposure to specific volatile assets is capped globally. | [quota-controls](https://docs.gearbox.finance/core/collateral-limits-specific-rates) | | **"What happens if bad debt occurs?"** | **Insolvency Resolution.** The **Loss Policy** defines fallback logic (e.g., switching to fundamental pricing) to prevent selling collateral at distressed prices during flash crashes. | [smart-oracles](https://docs.gearbox.finance/core/smart-oracles) | #### Phase 5: Governance & Parameter Security **User Intent:** Verify that administrative privileges cannot be exploited to expropriate funds. | Key Question | System Answer | Sitemap Component | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | **"Who controls risk parameters?"** | **Market Curators.** Specific entities manage the risk parameters (LTVs, Limits) for their respective markets. | [market-curators](https://docs.gearbox.finance/core/market-curators) | | **"Are there protections against malicious updates?"** | **Timelock Constraints.** Critical parameter changes are subject to a mandatory 24-hour timelock, allowing LPs to withdraw capital before changes take effect. | [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) | | **"Who controls the technical infrastructure?"** | **Instance Owner.** A chain-specific multisig acts as the technical gatekeeper for the Price Feed Store, ensuring oracle integrity independent of Market Curators. | [instance-owner](https://docs.gearbox.finance/core/instance-owner) | ## For Borrowers & Farmers Source: https://docs.gearbox.finance/core/for-borrowers-farmers File: content/core/for-borrowers-farmers.mdx #### Phase 1: Feasibility & Capacity Analysis **User Intent:** Determine if the protocol can support the target strategy size and complexity. | Key Question | System Answer | Sitemap Component | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **"What constrains position size?"** | **Liquidity & Exposure Limits.** Capacity is bounded by two distinct factors: 1) Global liquidity availability in the Pool, and 2) Strategy-specific Debt Ceilings defined by the Curator. | [pool](https://docs.gearbox.finance/core/pool-the-liquidity-vault) \ [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) | | **"What are the primary risk vectors?"** | **Risk Vector Identification.** Borrowers face three primary threats: 1) **Market Risk** (Collateral volatility), 2) **Rate Risk** (Utilization-driven cost spikes), and 3) **Liquidity Risk** (Inability to exit via external DEX liquidity). | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"Is the target collateral eligible?"** | **Collateral Allowlist.** Each Credit Manager enforces a strict allowlist of assets. Tokens not explicitly whitelisted cannot be held within the Credit Account. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | #### Phase 2: Cost of Carry Modeling **User Intent:** Model the dynamic cost of capital to project net yield and volatility exposure. | Key Question | System Answer | Sitemap Component | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **"What drives the base rate?"** | **Interest Rate Model.** Rates are dynamic and determined by **Pool Utilization**. Large withdrawals by LPs can cause immediate utilization spikes, increasing the cost of capital. | [interest-rate-model](https://docs.gearbox.finance/core/interest-rate-model) | | **"Are there asset-specific premiums?"** | **Quota Rates.** Illiquid or high-volatility collateral assets may carry an *additional* interest premium (Quota Rate) imposed by the Quota Keeper, independent of the base pool rate. | [quota-controls](https://docs.gearbox.finance/core/collateral-limits-specific-rates) | | **"What is the protocol take rate?"** | **Interest Fee.** The Curator and DAO capture a fixed percentage of the interest paid. This markup is additive to the base rate paid to LPs. | [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) | #### Phase 3: Solvency & Liquidation Mechanics **User Intent:** Define the liquidation boundary and the economic consequences of insolvency. | Key Question | System Answer | Sitemap Component | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | **"What triggers liquidation?"** | **Liquidation Triggers.** Insolvency can result from: 1) Collateral depreciation, 2) Debt asset appreciation, or 3) **Accrued Interest** (Rate spikes eroding the Health Factor). | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"What is the penalty structure?"** | **Liquidation Premium.** Upon liquidation, the borrower forfeits a fixed percentage (e.g., 5%) of the liquidated collateral to the third-party liquidator. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"Are automated mitigations available?"** | **Partial Liquidation & Deleverage.** The protocol supports partial liquidations to restore solvency without full closure. Automated deleveraging tools can be utilized to maintain the Health Factor. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | #### Phase 4: Governance & Parameter Risk **User Intent:** Assess the risk of adverse parameter changes by the market operator. | Key Question | System Answer | Sitemap Component | | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **"Can parameters change mid-trade?"** | **Parameter Risk.** Yes. Curators can modify Liquidation Thresholds (LTVs). However, these changes are subject to a mandatory **Timelock**, providing a window for borrowers to adjust or exit. | [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) | | **"What are the operational circuit breakers?"** | **Smart Oracles & Pauses.** 1) Significant deviation between Main and Reserve price feeds will block operations. 2) Admins retain the ability to pause Credit Managers in emergency scenarios. | [smart-oracles](https://docs.gearbox.finance/core/smart-oracles) | | **"Can access be revoked?"** | **Access Control.** Curators can forbid specific tokens or adapters, preventing borrowers from increasing exposure to those assets. | [market-curators](https://docs.gearbox.finance/core/market-curators) | #### Phase 5: Position Unwind & Liquidity Dependencies **User Intent:** Evaluate the reliability of exit mechanisms under stress. | Key Question | System Answer | Sitemap Component | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **"What are the execution dependencies?"** | **External Liquidity.** The "Atomic Close" relies on external DEX liquidity (e.g., Curve/Uniswap) to swap collateral for the debt asset. Thin liquidity or high slippage can cause repayment transactions to revert. | [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | | **"What is the contingency procedure?"** | **Manual Unwind.** If atomic execution fails, the borrower must manually withdraw collateral (subject to solvency checks), execute swaps externally, and repay the debt. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | ## For Market Curators Source: https://docs.gearbox.finance/core/for-market-curators File: content/core/for-market-curators.mdx The Market Curator views Gearbox as a **Risk Parameterization Engine**, not a fund management tool. Unlike other lending primitives where curators actively allocate liquidity (e.g., Morpho), Gearbox Curators define the *boundary conditions* (LTVs, Limits, Rates) within which users autonomously execute strategies. #### Phase 1: The Operational Model (Mental Model Alignment) **User Intent:** Understand the legal and operational distinction between "Managing Funds" and "Managing Parameters." | Key Question | System Answer | Sitemap Component | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **"Do I manage the liquidity?"** | **Non-Custodial Curation.** Unlike Morpho, Curators do not actively rebalance funds between vaults. Curators set the *rules* and users/borrowers autonomously utilize the liquidity. This distinction is critical for entities avoiding custodial classification. | [one-pool-many-markets](https://docs.gearbox.finance/core/one-pool-many-markets) | | **"What is the deliverable?"** | **The Lending Product.** The Curator's product is a set of smart contracts with specific risk parameters. The "Product" is the *access* to leverage and earning under these specific terms, not the yield itself. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | | **"Who bears the economic risk?"** | **Risk Liability.** The Curator bears the reputational and economic risk of their configuration. Gearbox Protocol provides the *mechanism* for liquidation, but the *guarantee* of solvency depends entirely on the Curator's parameter selection (LTV vs. Volatility). | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | #### Phase 2: Infrastructure Dependencies (The "Full Stack" Reality) **User Intent:** Assess the reliance on Gearbox DAO for critical infrastructure vs. autonomous capabilities. | Key Question | System Answer | Sitemap Component | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **"Is it fully permissionless?"** | **Hybrid Governance.** While market creation is permissionless, critical infrastructure is gated. 1) **Chain Activation** requires DAO approval. 2) **Price Feed Whitelisting** is controlled by the Instance Owner multisig (though open to Curator participation). | [instance-owner](https://docs.gearbox.finance/core/instance-owner) | | **"Who runs the interface?"** | **UI & Tooling Dependency.** The official Gearbox App and Curation Interface are maintained by the DAO. While the protocol is onchain, practical operation relies on these offchain services unless the Curator builds their own frontend. | [protocol-dao](https://docs.gearbox.finance/core/protocol-dao) | | **"How are transactions generated?"** | **Operational Complexity.** Configuring a market involves complex transaction batches. Curators rely on the DAO-maintained **Curation Interface** to generate these payloads. Autonomous operation requires significant technical capability to replicate this tooling. | [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) | #### Phase 3: Product Structuring & Incentives **User Intent:** Define the commercial structure and align incentives with the DAO. | Key Question | System Answer | Sitemap Component | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **"How do I monetize?"** | **Fee Sharing.** Curators capture a configurable percentage of interest and liquidation fees. This revenue stream is programmatic and shared with the Protocol DAO. | [market-curators](https://docs.gearbox.finance/core/market-curators) | | **"Can I get token incentives?"** | **DAO Alignment.** GEAR token incentives are discretionary and voted on by the DAO. There is no programmatic guarantee of incentives; Curators must align their product with the DAO's strategic goals to receive support. | [protocol-dao](https://docs.gearbox.finance/core/protocol-dao) | | **"Can the DAO interfere?"** | **Sovereignty vs. Support.** The DAO cannot alter a Curator's parameters onchain. However, the DAO *can* delist a market from the official UI or cut incentives if the Curator's risk management endangers the protocol's reputation. | [protocol-dao](https://docs.gearbox.finance/core/protocol-dao) | #### Phase 4: Risk Parameterization (The Core Job) **User Intent:** Calibrate the system to balance capital efficiency with solvency protection. | Key Question | System Answer | Sitemap Component | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | **"How is leverage capped?"** | **Liquidation Thresholds.** Curators set the $LT$ for each asset. This is the primary lever for risk management. Setting this too high relative to asset volatility *will* result in bad debt, for which the protocol is not liable. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"How is concentration risk managed?"** | **Quota Limits.** Curators must set global caps on specific collateral assets via the Quota Keeper. This prevents the pool from becoming over-exposed to illiquid tokens. | [quota-controls](https://docs.gearbox.finance/core/collateral-limits-specific-rates) | | **"How are liquidators incentivized?"** | **Liquidation Premium.** Curators configure the premium paid to liquidators. If this is set too low, liquidators will not execute, and the system *will* fail. The protocol does not guarantee liquidation execution. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | #### Phase 5: Operational Governance **User Intent:** Understand the ongoing management and emergency procedures. | Key Question | System Answer | Sitemap Component | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **"How are updates executed?"** | **Timelock Constraints.** All critical parameter changes are subject to a 24-hour timelock. Curators must plan updates in advance. | [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) | | **"What are the emergency powers?"** | **Pause & Loss Policy.** In the event of an exploit or market failure, Curators (or their Emergency Admins) can pause borrowing or trigger the Loss Policy to prevent bad debt accumulation. | [smart-oracles](https://docs.gearbox.finance/core/smart-oracles) | ## For Ecosystems & Chains Source: https://docs.gearbox.finance/core/for-ecosystems-chains File: content/core/for-ecosystems-chains.mdx #### Phase 1: The Value Proposition (Composability Engine) **User Intent:** Understand how Gearbox enriches the existing DeFi ecosystem beyond simple lending. | Key Question | System Answer | Sitemap Component | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **"How does this benefit local apps?"** | **Unified Execution Layer.** Gearbox is not a silo. Through **Adapters**, Credit Accounts inject leverage directly into local protocols (e.g., Uniswap, Curve, Pendle). This turns a passive lending market into an active volume generator for the chain's DEXs and yield farms. | [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | | **"Is it compatible with our assets?"** | **Versatile Collateral.** Gearbox supports complex assets like LP tokens, Vault shares, and PTs. This allows the chain to offer leverage on its unique "Productive Assets," not just plain vanilla tokens. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | #### Phase 2: The Operating Model (Roles & Responsibilities) **User Intent:** Clarify the division of labor between the Chain, the Gearbox DAO, and the Market Operators. | Key Question | System Answer | Sitemap Component | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **"Who runs the markets?"** | **Service Provider vs. Operator.** Gearbox DAO provides the *technology stack* (Service Provider). **Curators** (Operators) run the actual business (Risk/Parameters). The Chain can bring its own trusted curators, or Gearbox can help facilitate introductions to existing active curators. | [market-curators](https://docs.gearbox.finance/core/market-curators) | | **"Who guarantees success?"** | **Shared Responsibility.** Gearbox DAO ensures the code functions correctly and provides operational support. However, the economic success of a market is a function of the Curator's strategy and the Chain's underlying liquidity depth. | [protocol-dao](https://docs.gearbox.finance/core/protocol-dao) | | **"Is deployment gated?"** | **Permissionless Architecture.** No. Once the protocol is deployed on the chain, market creation is permissionless. Curators do not need Gearbox DAO approval to launch new markets or list new assets, ensuring rapid integration with the chain's roadmap. | [market-curators](https://docs.gearbox.finance/core/market-curators) | #### Phase 3: Ecosystem Prerequisites (Economic Viability) **User Intent:** Determine the maturity level required to support leveraged markets. | Key Question | System Answer | Sitemap Component | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **"What is required for liquidations?"** | **Liquidity Enables Capacity.** Gearbox relies on swapping collateral on local DEXs. Deeper DEX liquidity allows for higher borrowing limits. We work with chains to identify the most liquid assets suitable for initial markets. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"How are liquidators onboarded?"** | **Collaborative Keeper Network.** Gearbox provides open-source liquidator bot infrastructure. We actively collaborate with the Chain to onboard local MEV searchers and keepers, ensuring a robust liquidation network is established pre-launch. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"What assets work best?"** | **Productive Collateral.** Gearbox shines when there are yield-bearing assets (LSTs, LRTs, Yield Vaults). Leverage on zero-yield assets is less attractive to borrowers in high-rate environments. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | #### Phase 4: Technical Requirements (Deployment Feasibility) **User Intent:** Verify technical compatibility to ensure a smooth launch. | Key Question | System Answer | Sitemap Component | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **"What are the hard constraints?"** | **Block Gas Limit.** Gearbox contracts are sophisticated. To deploy the core infrastructure, the chain should ideally support a Block Gas Limit of **>30 Million**. We can assist in evaluating chain parameters for compatibility. | [omni-evm-architecture](https://docs.gearbox.finance/core/omni-evm-architecture) | | **"What infrastructure is needed?"** | **RPC Reliability.** Robust offchain operations (Interface, Liquidator Bots) require stable RPC providers. Gearbox contributors can assist in testing and verifying infrastructure readiness. | [omni-evm-architecture](https://docs.gearbox.finance/core/omni-evm-architecture) | | **"Are oracles ready?"** | **Oracle Infrastructure.** Reliable oracle providers (Chainlink, Redstone, Pyth, or API3) are required for collateral assets. We can help coordinate with oracle partners to ensure coverage. | [price-oracle](https://docs.gearbox.finance/core/price-oracle) | #### Phase 5: Growth & Incentives (Go-to-Market) **User Intent:** Plan the launch strategy and incentive allocation. | Key Question | System Answer | Sitemap Component | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **"How do we attract liquidity?"** | **Co-Marketing & Grants.** The Chain can offer incentives to Curators to encourage market creation. Gearbox DAO frequently partners with chains to co-market these launches to existing user base. | [market-curators](https://docs.gearbox.finance/core/market-curators) | ## For Asset Issuers & Protocols Source: https://docs.gearbox.finance/core/for-asset-issuers-protocols File: content/core/for-asset-issuers-protocols.mdx #### Phase 1: The Value Proposition (Distribution & Efficiency) **User Intent:** Understand how Gearbox drives growth for the underlying protocol. | Key Question | System Answer | Sitemap Component | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **"How does this grow our TVL?"** | **Leverage as a Feature.** Gearbox acts as a multiplier on existing demand. By enabling users to mint/stake assets with leverage, issuers increase capital efficiency, attracting sticky, yield-focused capital that might otherwise go to competitors. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | | **"Does it require DEX liquidity?"** | **Zero-Slippage Execution.** Unlike standard lending markets, Gearbox does not strictly require deep DEX liquidity to enable leverage entry. Through **Direct Integration**, Credit Accounts can mint/redeem directly with protocol contracts, bypassing secondary market slippage entirely. | [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | | **"Can it handle complex flows?"** | **Purpose-Specific Execution.** Gearbox adapts to the asset's mechanics. Whether it's staking, locking, or vesting, the Credit Account executes the logic natively. This allows issuers to offer "Leveraged Staking" or "Leveraged RWA Vaults" as a seamless user experience. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | #### Phase 2: Solving the Liquidity Problem (RWAs & Vaults) **User Intent:** Address the specific friction points of illiquid or semi-liquid assets (RWAs, Private Credit). | Key Question | System Answer | Sitemap Component | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **"We have delayed settlement. Does it work?"** | **Async Redemption Support.** Yes. Standard lending protocols fail here, but Gearbox excels. Credit Accounts can initiate a redemption, hold the receipt token through the settlement period, and claim the underlying funds upon finalization—all while maintaining the credit position. | [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | | **"Do we need to pay for incentives?"** | **Capital Efficiency > Incentives.** By allowing users to mint assets at NAV (Net Asset Value) via leverage, issuers reduce the need to spend millions on incentives to deepen Curve/Uniswap pools just to support lending liquidations. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"Can we enforce KYC/Whitelists?"** | **Compliance Compatibility.** Yes. Because the Credit Account is a smart contract wallet, it can be compatible with protocol allowlists or transfer restrictions, ensuring that leveraged users meet compliance requirements. | [credit-suite](https://docs.gearbox.finance/core/credit-suite-the-strategy-module) | #### Phase 3: Technical Integration (Adapters) **User Intent:** Assess the engineering effort required to connect. | Key Question | System Answer | Sitemap Component | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | | **"How do we connect?"** | **The Adapter Model.** Integration requires building an **Adapter**—a lightweight wrapper contract that translates Gearbox's safety checks into the protocol's function calls (e.g., `deposit()`, `stake()`, `requestRedemption()`). | [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | | **"Who builds the adapter?"** | **Collaborative Development.** Gearbox DAO maintains a library of standard adapters (ERC-4626, Curve, Uniswap). For custom logic, teams can fork a template or collaborate with Gearbox contributors for guidance. | [adapters-integrations](https://docs.gearbox.finance/core/adapters-integrations) | #### Phase 4: Risk Underwriting (Getting Approved) **User Intent:** Understand how to satisfy the risk requirements of potential Curators. | Key Question | System Answer | Sitemap Component | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **"How is risk assessed?"** | **Curator Due Diligence.** There is no universal formula. Each Curator has a unique risk framework—some prioritize backing transparency, others prioritize secondary liquidity. Issuers should be prepared to provide data on volatility, redemption mechanics, and backing to facilitate this underwriting process. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | | **"How is the asset priced?"** | **Flexible Oracle Architecture.** Gearbox supports diverse pricing models (Spot, TWAP, Fundamental/NAV). The choice depends on what the Curator is comfortable with. Issuers should propose a pricing source that is robust against manipulation to increase the likelihood of listing. | [price-oracle](https://docs.gearbox.finance/core/price-oracle) | | **"How do we ensure solvency?"** | **Shared Assurance.** Curators need to know that liquidations will execute in bad market conditions. Issuers can significantly improve their listing chances by committing to run their own liquidator bots or providing a backstop for collateral liquidation. | [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) | #### Phase 5: Go-to-Market (Decentralized Listing) **User Intent:** Navigate the listing process in a permissionless environment. | Key Question | System Answer | Sitemap Component | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **"Who approves the listing?"** | **Marketplace of Risk.** Gearbox is a neutral infrastructure; there is no central "Listing Committee." Issuers must pitch **Market Curators**—independent operators who manage the liquidity. Curators decide what to list based on their own risk models and incentive requirements. | [market-curators](https://docs.gearbox.finance/core/market-curators) | | **"What drives Curator decisions?"** | **Incentive Alignment.** Different Curators have different mandates. Some prioritize high-yield assets and may require incentives (bribes/points) to list new tokens. Others prioritize safety and require strict audits. Success requires finding the right Curator for the asset profile. | [market-curators](https://docs.gearbox.finance/core/market-curators) | | **"How fast can we launch?"** | **Permissionless Agility.** Once a Curator agrees to underwrite the asset, the listing is permissionless. There is no DAO governance vote required to add a new collateral type to an existing Credit Manager. | [market-curators](https://docs.gearbox.finance/core/market-curators) | ## Pool (The Liquidity Vault) Source: https://docs.gearbox.finance/core/pool-the-liquidity-vault File: content/core/pool-the-liquidity-vault.mdx The **Liquidity Pool** serves as the liability side of the Gearbox Protocol balance sheet. It is a passive, ERC-4626 compliant smart contract where lenders deposit assets (e.g., USDC, WETH) to earn yield. Unlike traditional lending protocols where a pool interacts directly with individual borrowers, the Gearbox Pool operates on a **Wholesale Banking Model**. It does not lend directly to users; instead, it allocates capital to **Credit Suites** (Credit Managers), which act as specialized lending branches with distinct risk configurations. ### Core Mechanics #### 1. Passive Liquidity & ERC-4626 The Pool is strictly passive. It holds the underlying asset and issues **Diesel Tokens** (dTokens) to depositors as a receipt of liquidity provision. * **Standard:** Fully compliant with [ERC-4626](https://www.google.com/url?sa=E\&q=https%3A%2F%2Feips.ethereum.org%2FEIPS%2Feip-4626) (Tokenized Vault Standard). * **Fungibility:** Diesel Tokens are fungible and transferable, allowing them to be used as collateral in other DeFi protocols. * **Liquidity:** Deposits and withdrawals are instant subject to available amount of unborrowed liquidity. #### 2. Diesel Tokens (Non-Rebasing Yield) Yield accrual in Gearbox is reflected through the **Exchange Rate**, not through balance updates. * **Non-Rebasing:** Unlike aTokens (Aave), the wallet balance of Diesel Tokens does not increase over time. * **Value Accrual:** As borrowers pay interest, the amount of underlying assets in the Pool grows while the supply of Diesel Tokens remains constant. Consequently, the exchange rate increases.\ Borrow rates are determined using Utilization-based Interest Rate Model and collateral-specific rates. $$ Exchange\ Rate = \frac{Total\ Assets\ (Principal + Interest)}{Total\ Supply\ of\ dTokens} $$ #### 3. The Branch Model (Wholesale Lending) The Pool delegates the complexity of risk management and borrower interaction to **Credit Suites**. * **The Pool (Wholesale Bank):** Aggregates liquidity from lenders. It has no knowledge of individual borrowers, collateral types, or liquidation logic. Its only function is to lend capital to approved Credit Suites up to a defined limit. * **Credit Suites (Retail Branches):** Borrow liquidity from the Pool to fund Credit Accounts. Each Credit Suite enforces specific risk parameters (LTV, allowed assets, liquidation rules). This separation of concerns ensures that the Pool remains lightweight and secure, while complexity is pushed to the periphery (the Suites). ### Risk Isolation & Allocation A single Pool can fund multiple Credit Suites simultaneously. The Market Curator manages the Pool's risk exposure by setting a **Debt Ceiling** for each connected Credit Suite. * **Allocation Limits:** The Curator defines the maximum capital available to each CreditSuite (e.g., 80% to a Low-Risk Product, 20% to a High-Risk Product). * **Firewalling:** If a specific Strategy (Credit Suite) suffers a failure or bad debt, the loss is contained within that Creit Suite's allocation. The Pool's exposure is limited to the capital lent to that specific branch, protecting the remaining liquidity. ### Automated Insurance mechanism Gearbox V3 implements an automated **First-Loss Capital** buffer to protect Passive Lenders from bad debt. This mechanism prioritizes protocol solvency over profit distribution by strictly retaining revenue within the until specific safety targets are met. ### Learn More * **Yield source:** How is the utilization-driven interest rate calculated? * [interest-rate-model](https://docs.gearbox.finance/core/interest-rate-model) * **Yield optimization & risk control:** How are collateral-specific rates and collateral exposure limits handled? * [quota-controls](https://docs.gearbox.finance/core/collateral-limits-specific-rates) * **Deposits utilization:** Where is the liquidity actually used or lent to? * [credit-suite](https://docs.gearbox.finance/developers/credit-suite) * **Insurance from Bad debt:** Learn how the underlying mechanism works in detail. * [insurance-and-solvency-reserves](https://docs.gearbox.finance/core/insurance-solvency-reserves) ## Credit Suite (The Strategy Module) Source: https://docs.gearbox.finance/core/credit-suite-the-strategy-module File: content/core/credit-suite-the-strategy-module.mdx The Credit Suite is the architectural assembly responsible for managing the asset side of the protocol's balance sheet. While the Liquidity Pool manages passive capital (liabilities), the Credit Suite defines the logic, risk parameters, and execution boundaries for active borrowers (assets). A single Liquidity Pool can be connected to multiple Credit Suites, each representing a distinct **Credit Manager** with unique risk configurations, allowed collateral assets, and borrowing limits. This isolation allows the protocol to compartmentalize risk strategies without fragmenting underlying liquidity. ### Architectural Components The Credit Suite consists of three primary smart contracts, each with distinct responsibilities regarding accounting, execution, and configuration. #### 1. Credit Manager (The Accountant) The Credit Manager is the central logic container and state manager for a specific lending strategy. It acts as the "Accountant" of the system. * **State Management:** It maintains the ledger of all Credit Accounts associated with the strategy, tracking debt amounts and collateral values. * **Adapter Registry:** It stores the list of approved Adapters (integrations) and enforces the "Allowlist" of tokens that can be held as collateral. * **Solvency Logic:** It contains the mathematical logic for calculating the Health Factor (HF). #### 2. Credit Facade (The Entry Point) The Credit Facade serves as the primary entry point for borrower interactions. It abstracts the complexity of the Credit Manager and enforces execution safety. * **Multicall Execution:** The Facade allows users to bundle multiple operations (e.g., `borrow`, `swap`, `deposit_into_vault`) into a single atomic transaction. * **Check-on-Exit Solvency:** The Facade implements the protocol's optimistic execution model. It permits any sequence of whitelisted operations during a transaction but enforces a strict solvency check at the end. * If HF > 1 at the end of the transaction, the state changes are committed. * If HF < 1, the entire transaction reverts. * **Permissions:** It handles user permissions, ensuring that only the owner of a Credit Account can initiate transactions affecting that account. **HF** calculation is based on **Total Weighted Value (TWV)** of collateral. This is not just the market value; it is the market value *discounted* by the Liquidation Threshold (LT). If Account holds $100 of ETH with an LT of 90%, the system values it at $90 for solvency purposes. * [**Deep Dive: Full Liquidation Math & Formulas**](https://docs.gearbox.finance/core/liquidation-dynamics) #### 3. Credit Configurator (The Management Layer) The Credit Configurator provides the administrative interface for Market Curators to manage the Credit Suite. It decouples governance logic from the core accounting logic. * **Parameter Updates:** Curators interact with the Configurator to adjust risk parameters (e.g., Liquidation Thresholds, Fees, Limits) rather than interacting with the Credit Manager directly. * **Validation & Safety:** The Configurator validates inputs to prevent invalid states (e.g., setting a Liquidation Threshold > 100%) before applying changes to the Credit Manager. * **Timelock Enforcement:** It enforces mandatory delays for critical parameter changes, ensuring users have time to react to risk adjustments before they become active. ### Interaction Flow 1. **Configuration:** The Curator sets risk parameters via the **Credit Configurator**. 2. **Execution:** The Borrower submits a multicall transaction to the **Credit Facade**. 3. **Accounting:** The Facade routes instructions to the **Credit Manager**, which updates the Credit Account's state and interacts with the **Pool** or **Adapters**. 4. **Verification:** The Facade requests a final solvency check from the Credit Manager before finalizing the transaction. ### Learn More * **Solvency enforcement:** How liquidations work? * [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) * **Risk controls:** What is the complete list of parameters that define the strategy? * [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) ## Adapters & Integrations Source: https://docs.gearbox.finance/core/adapters-integrations File: content/core/adapters-integrations.mdx A Credit Account is a secure "Container." By default, it cannot interact with the outside world because the protocol cannot guarantee the safety of external smart contracts. **Adapters** are the solution. They are specialized "Translation Contracts" that allow Credit Accounts to interact with specific DeFi protocols (like Uniswap, Curve, or Lido) while maintaining the strict solvency checks required by Gearbox. ### Modular Execution: Purpose-Optimized UX Gearbox’s modular architecture unifies credit and execution. * **The Core Layer:** Provides the capital and enforces solvency (Health Factor). * **The Adapter Layer:** Extends this base with purpose-specific execution rules. This allows Curators to design Financial Products tailored for specific use cases. One product might be optimized for **Prediction Markets** (interacting with order books), while another is optimized for **Yield Farming** (interacting with vaults). ![Figure](https://docs.gearbox.finance/assets/docs/core/adapters-integrations/01-modular-execution-purpose-optimized-ux.png) ### The Security Problem: Unrestricted Execution A Credit Account holds leveraged funds. If users could interact directly with any smart contract, they could exploit complex DeFi mechanics to bypass solvency checks. **How Adapters Fix This:**\ Adapters act as a **Sanitized Interface**. They restrict interactions to a specific, pre-defined set of functions that have been audited for safety. 1. **Function Whitelisting:** Users cannot call `any` function on Uniswap; they can only call the specific `swap` functions defined in the Adapter. 2. **Result Verification:** The Adapter ensures that the outcome of the trade (the tokens received) matches the protocol's expectations, preventing complex state manipulation attacks. By forcing all interactions through these "Safe Tunnels," Gearbox ensures that the Credit Account's state remains predictable at all times. ### The Router: Intelligent Execution While Adapters provide the *connection*, the **Router** provides the *path*. DeFi strategies are rarely simple. A user might want to "Zap" from USDC directly into a Convex Curve-stETH position. This requires multiple steps: 1. Swap USDC -> WETH (Uniswap) 2. Deposit WETH -> stETH (Lido) 3. Deposit stETH + WETH -> steCRV (Curve) 4. Stake steCRV -> Convex The Gearbox Router calculates the optimal path across all enabled Adapters and bundles these steps into a single **Multicall**. ![Figure](https://docs.gearbox.finance/assets/docs/core/adapters-integrations/02-the-router-intelligent-execution.png) ### Curator Responsibilities As a Curator, the choice of Adapters defines the **Utility** of the market. 1. **Enable Liquidity:** If a market accepts `wstETH` as collateral, the Curator should enable DEX Adapters (e.g., Uniswap or Curve) that support `wstETH` trading. Without it, users cannot swap into the Debt token. Limited allowed adapters will result in high slippage losses. 2. **Enable Yield:** To offer a "Farming Strategy," the Curator must enable the specific Adapter for that farm (e.g., the Convex Adapter or Midas vault adapter). 3. **Risk Management:** If a specific external protocol is hacked or becomes risky, the Curator can **Disable** that specific Adapter instantly via the Emergency Admin, protecting the pool from further exposure. ### Learn More * **Solvency checks:** How accounts are kept overcollateralized after each operation? * [credit-suite](https://docs.gearbox.finance/developers/credit-suite) * **Unique usecases:** How Credit Accounts and adapters unlock new credit interactions. * [direct-redemptions](https://docs.gearbox.finance/core/usecase-direct-redemptions) ## Interest Rate Model Source: https://docs.gearbox.finance/core/interest-rate-model File: content/core/interest-rate-model.mdx The Interest Rate Model (IRM) functions as the protocol's algorithmic central bank. Its primary objective is to balance **capital efficiency** (maximizing yield for lenders) with **liquidity availability** (ensuring lenders can withdraw assets). It achieves this by dynamically adjusting the Base Borrow Rate based on the **Utilization Rate** of the Liquidity Pool. ### The Utilization Curve The cost of borrowing is a function of demand. As the pool becomes more utilized (more funds borrowed), the interest rate rises to incentivize repayments and attract new deposits. Gearbox employs a **Two-Kink Piecewise Linear Model**. This design creates a specific "Optimal Zone" where rates remain stable, preventing volatility during normal market activity while aggressively penalizing over-utilization. #### Mathematical Structure The curve is defined by two utilization thresholds (Kinks), denoted as U\_1 and U\_2, creating three distinct slope zones: 1. **Growth Zone (0% to U\_1):** * **Behavior:** Rates increase slowly. * **Intent:** Incentivize early borrowing and ramp up utilization to efficient levels. 2. **Optimal Zone (U\_1 to U\_2):** * **Behavior:** Rates remain relatively stable or rise moderately. * **Intent:** Create a predictable cost of capital for borrowers while ensuring sufficient yield for lenders. This is the target operating range of the pool. 3. **Liquidity Crunch Zone (> U\_2):** * **Behavior:** Rates spike exponentially (High Slope). * **Intent:** Force immediate deleveraging. When utilization breaches U\_2, the cost of capital exceeds market returns, compelling borrowers to close positions and restoring liquidity for lender withdrawals. #### Formula The Borrow Rate R(U) is calculated as: $$ R(U)= \begin{cases} R\_{\text{base}} + \dfrac{U}{U\_1} R\_{\text{slope1}}, & U \le U\_1 \\\[6pt] R\_{\text{base}} + R\_{\text{slope1}} * \dfrac{U - U\_1}{U\_2 - U\_1} R\_{\text{slope2}}, & U\_1 < U \le U\_2 \\\[6pt] R\_{\text{base}} + R\_{\text{slope1}} + R\_{\text{slope2}} * \dfrac{U - U\_2}{1 - U\_2} R\_{\text{slope3}}, & U > U\_2 \end{cases} $$ Where: * U: Current Utilization Rate (Total Debt / Total Assets). * R\_base: The minimum starting rate (y-intercept). * R\_slope: The rate of change in each zone. ***Reference:*** * [Desmos IRM visualizer](https://www.desmos.com/calculator/d281eeb4a9) ### Liquidity Reservation A critical feature of the Gearbox IRM is the enforcement of **Exit Liquidity**. In standard lending protocols, 100% utilization means lenders cannot withdraw their funds until a borrower repays. Gearbox mitigates this risk through **Liquidity Reservation**. #### The Reservation Cap Curators can configure the market to strictly forbid new borrowing once utilization reaches U\_2. * **Mechanism:** If `isBorrowingMoreU2Forbidden` is enabled, any transaction attempting to increase debt beyond the U\_2 threshold will revert. * **Result:** The remaining liquidity (from U\_2 to 100%) is effectively reserved for lender withdrawals. Even in periods of peak demand, a buffer of liquid assets remains available in the pool. ### Total Cost of Capital The Interest Rate Model determines the **Base Rate** of the pool. The final cost to a borrower includes additional collateral-specific rate. #### Learn More * **Asset-specific risk premiums:** Borrowers holding specific collateral assets may incur an additional Quota Rate on top of the base rate. * [quota-controls](https://docs.gearbox.finance/core/collateral-limits-specific-rates) * **Protocol fees:** A portion of the interest paid is captured as revenue for the Protocol DAO and the Market Curator. * [dao-and-curators-business-model](https://docs.gearbox.finance/core/dao-curators-business-model) ## Collateral Limits & Specific rates Source: https://docs.gearbox.finance/core/collateral-limits-specific-rates File: content/core/collateral-limits-specific-rates.mdx The Quota Control system is the protocol's mechanism for managing concentration risk and pricing asset-specific exposure. While the Liquidity Pool provides a shared source of capital, the Quota system enforces strict limits on how that capital can be allocated toward specific collateral assets and applies additional risk premiums where necessary. ### Asset-Side Caps (Concentration Limits) To protect Liquidity Providers (LPs) from over-exposure to specific assets, the protocol enforces **Quota Limits**. These are hard caps on the total amount of debt that can be collateralized by a specific token across all Credit Managers attached to a pool. #### Mechanism Unlike a global debt ceiling which limits the total size of the pool or Credit Manager limits which define maximum exposure to particular strategies, Quota Limits operate on the **collateral side**. * **Exposure Calculation:** The system tracks the total value of borrowing power currently backed by a specific asset (e.g., $WBTC). * **Enforcement:** If the total exposure reaches the defined Quota Limit, the system blocks any transaction that would further increase exposure to that asset. * New Credit Accounts cannot be opened with that collateral. * Existing accounts cannot increase the amount of debt that is backed by particular token. * Repayments and closures remain enabled to allow deleveraging. This architecture ensures that even if a pool has abundant idle liquidity, it cannot be drained into a single illiquid or high-risk strategy beyond the safety parameters defined by the Curator. ### Quota Rates (Risk Premium) The Quota system decouples the cost of liquidity from the cost of risk. It allows the protocol to charge an additional interest rate—the **Quota Rate**—based specifically on the collateral held by the borrower. #### The Additive Rate Model The total cost of borrowing before fees is the sum of the base cost of capital and the specific risk premium of the collateral. $$ \text{Total APR} = \text{Base Rate} + \text{Quota Rate} $$ * **Base Rate:** Determined by the utilization of the Liquidity Pool. This represents the opportunity cost of the underlying asset (e.g., USDC). * **Quota Rate:** Determined by the specific collateral asset (e.g., a volatile governance token). This represents the risk premium for holding that specific asset. #### Pricing Granularity This separation allows for granular risk pricing within a single pool: * **Low-Risk Collateral:** Borrowers using blue-chip assets (e.g., WETH) may pay only the Base Rate (Quota Rate = 0%). * **High-Risk Collateral:** Borrowers using volatile or less liquid assets must pay the Base Rate plus a significant Quota Rate (e.g., +5%). This ensures that borrowers using safe collateral do not subsidize the risk of those using volatile collateral, improving capital efficiency for low-risk strategies while properly pricing tail risk. #### Learn More * **Base interest calculation:** How does pool utilization determine the underlying cost of capital? * [interest-rate-model](https://docs.gearbox.finance/core/interest-rate-model) * **Parameter configuration:** Who configures these limits and what parameter ranges are allowed? * [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) * **Protocol fees:** How is interest revenue captured and shared between the Protocol DAO and the Market Curator? * [dao-and-curators-business-model](https://docs.gearbox.finance/core/dao-curators-business-model) ## Liquidation Dynamics Source: https://docs.gearbox.finance/core/liquidation-dynamics File: content/core/liquidation-dynamics.mdx The solvency of a Credit Account is determined deterministically on-chain. If an account's risk-adjusted value falls below its liabilities, the protocol enforces liquidation to protect liquidity providers. ### Solvency Definition: The Health Factor The core metric for solvency is the **Health Factor (HF)**. $$ HF = \frac{TWV}{Total Debt} $$ Where: * **TWV (Total Weighted Value):** The risk-adjusted, quota-limited value of the collateral assets, measured in the underlying token. * **Total Debt:** The total amount of underlying token owed, including principal, accrued interest, and quota interest. #### Total Weighted Value (TWV) TWV represents the maximum debt the current collateral portfolio can support. Unlike standard Net Asset Value, Gearbox discounts collateral based on its **Liquidation Threshold (LT)** and caps it by the **Quota** allocated to that asset. $$ TWV = \frac{\sum\_{i}^{MaxEnabledTokens}{\min{(Quota\_i, Balance\_i \times Price\_i \times LT\_i)}}}{Price\_{underlying}} $$ * **Quota\_i**: The specific portion of the account's debt limit allocated to token i. * **Balance\_i**: The balance of token i in the Credit Account. * **Price\_i**: The current oracle price of token i. * **LT\_i**: The Liquidation Threshold for token i. * **Price\_{underlying}**: The current oracle price of the underlying borrowed asset. > **Note:** The `min` function ensures that a specific collateral asset cannot secure more debt than its allocated Quota allows, regardless of its market value. #### Liquidation Condition An account is liquidatable if: 1. **HF < 1**: The TWV is less than the Total Debt. 2. **Expiration**: The Credit Manager has reached its maturity date (for fixed-term strategies). ### Partial Liquidation (Deleverage) To prevent total loss of user positions during minor market dips, the protocol supports **Partial Liquidation**. This mechanism sells only enough collateral to restore the Health Factor to a safe level, rather than closing the entire position. This process is typically executed by a specialized Deleverage Bot. #### Execution Logic When HF drops below a configured `minHF` (but is typically still > 1), the bot executes a deleveraging transaction: 1. Calculates the amount of collateral required to be sold to raise HF to `targetHF`. 2. Repays a portion of the debt. 3. Charges a reduced premium compared to full liquidation. #### Configuration Parameters | Parameter | Description | | ---------------- | --------------------------------------------------------------------------------------- | | **minHF** | The threshold triggering partial liquidation (e.g., 1.05). | | **maxHF** | The target Health Factor after deleveraging. | | **PremiumScale** | The percentage of the full Liquidation Premium charged (e.g., 50% of standard premium). | ### Full Liquidation If Partial Liquidation is insufficient or if HF drops significantly below 1, a **Full Liquidation** occurs. The liquidator repays the total debt and claims the collateral assets at a discount. #### Total Value Calculation Liquidation math relies on the **Total Value** of the account (undiscounted NAV), measured in the underlying token. $$ Total Value = \frac{\sum\_{i}^{MaxEnabledTokens}{Balance\_i \times Price\_i}}{Price\_{underlying}} $$ #### Liquidator Incentive The liquidator receives the collateral assets valued at a discount (the Liquidation Premium). $$ LiquidatorProfit = TotalValue \times LiquidationPremium - GasCost $$ #### Borrower Loss The borrower loses the collateral used to pay the debt, the premium, and the protocol fee. $$ AccountLoss = \min(TotalValue \times (LiquidationPremium + LiquidationFee), TotalValue - Total Debt) $$ * **Liquidation Premium:** Paid to the liquidator. * **Liquidation Fee:** Paid to the Protocol (Curator & DAO). ### Bad Debt & Socialization **Bad Debt** occurs when a Credit Account is liquidated while its **Total Value** is less than its **Total Debt**. #### Resolution Mechanism 1. **Fee Buffer:** Unclaimed protocol fees (Curator/DAO share) are burned to cover the deficit. 2. **Socialization:** If fees are insufficient, the remaining loss is socialized among Liquidity Providers by reducing the exchange rate of the Diesel Token (LP token). #### Learn More * **Data sources:** How does the protocol obtain asset prices for Total Weighted Value (TWV) calculations? * [price-oracle](https://docs.gearbox.finance/core/price-oracle) * **Parameter control:** Who sets liquidation thresholds (LT), premiums, and fees? * [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) * **Quota mechanics:** How are quota limits defined and adjusted? * [quota-controls](https://docs.gearbox.finance/core/collateral-limits-specific-rates) ## Deleverage bot Source: https://docs.gearbox.finance/core/deleverage-bot File: content/core/deleverage-bot.mdx ### Deleverage - protection against liquidations The deleverage bot is designed to protect Gearbox users from full liquidations by automatically reducing leverage when an account’s health factor (HF) falls below a safe threshold. It acts as an early warning mechanism selling a small portion of collateral to restore safety before liquidation conditions are met. By doing so, the bot helps maintain protocol stability, safeguards user positions, and ensures smooth, market-driven deleveraging without requiring manual intervention or external subsidies. ### How to connect a bot Any user can connect a bot directly through the UI. From a technical standpoint, bot deployment is fully permissionless, users do not need approval from the DAO or a curator to deploy or connect a bot. However, for a bot to appear and be connectable via the UI, it must first be whitelisted there. ### Bot fees When a deleveraging event occurs, two types of fees are distributed: * **Premium:** Paid to the liquidator (deleverager) who executes the deleverage transaction. This serves as the direct incentive for running a bot and maintaining system safety. * **Fee:** Sent to the protocol treasury as the protocol’s share from the operation. ### Bot parameters | minHF | The threshold at which the bot starts deleveraging. When a user’s HF falls below this value, the bot begins selling part of their collateral to restore stability. | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | maxHF | The upper limit to which the bot is allowed to increase a user’s HF during a deleveraging operation. The bot will not push the HF above this value. The target HF for each operation lies somewhere between minHF and maxHF, depending on market conditions and the available liquidity. | | PremiumScale | Defines how much of the Credit Manager’s liquidation premium is taken as the deleverage premium. A value of 100% means the bot receives the same premium as a liquidator would. | | FeeScale | Specifies the fraction of the protocol fee applied to deleveraging. Typically set to 100%, aligning it with the standard liquidation fee. | ### **Rationale Behind Selecting Bot Parameters** #### **1. Primary Goal – Prevent Full Liquidations** The main purpose of the deleverage bot is to **protect users from full liquidations**. * The `minHF` (health factor at which deleverage is triggered) should be high enough so that a sudden drop in collateral value doesn’t make an account liquidatable immediately. * This gives the bot a time window to act and deleverage before liquidation occurs. * **Example:** If **WETH** is the collateral and we want to protect users from a **10% short-term price drop**, then: ``` minHF = 1 + 0.10 = 1.1 ``` *** #### **2. Avoid Triggering Under Normal Conditions** Deleveraging should **not** happen during ordinary market fluctuations. * Therefore, `minHF` should be **as low as possible**, ensuring that minor price deviations do not trigger unnecessary deleveraging. *** #### **3. Minimize Collateral Sold Per Event** The amount of collateral sold in a single deleveraging event should be minimized. * To achieve this, `maxHF` should be set **as close as possible to `minHF`**, limiting the size of each operation. *** #### **4. Ensure Organic Profitability** Deleveraging operations should be **naturally profitable** to encourage participation from external bots without requiring subsidies. * Set `PremiumScale` and `FeeScale` to **100%**, meaning the **deleverage premium = liquidation premium**. * The scale defines how much of the Credit Manager’s liquidation premium is allocated to deleveraging. * `maxHF` should be high enough so that both the **liquidation size** and **premium** are meaningful in dollar terms. *** #### **5. Keep Minimal Position Size Reasonable** The minimum position size (Credit Manager’s minimum debt) should not be too large. * The target for the **minimum position size** is around **$10,000**. ## Price Oracle Source: https://docs.gearbox.finance/core/price-oracle File: content/core/price-oracle.mdx The Price Oracle serves as the protocol's central valuation engine. Its primary function is to ingest raw price data from diverse external sources and standardize it into a uniform format that the Credit Manager and Pool contracts can consume mathematically. ### Data Normalization DeFi assets vary significantly in their technical specifications, particularly regarding decimal precision (e.g., USDC uses 6 decimals, WETH uses 18). To prevent calculation errors and complexity within the risk engine, the Price Oracle enforces a strict normalization standard. **The 8-Decimal Standard**\ Regardless of the underlying token's decimals or the external feed's native precision, the Gearbox Price Oracle always returns prices scaled to **8 decimals**. * **Input:** Raw data from Chainlink (8 decimals), Uniswap (18 decimals), or USDC (6 decimals). * **Process:** The Oracle wrapper scales the value up or down mathematically. * **Output:** A standardized USD price where `1.00` is represented as `100,000,000`. This uniformity allows the Credit Manager to perform solvency checks ($HealthFactor > 1$) using a single, consistent formula across all collateral types. ### Staleness Enforcement To ensure solvency calculations reflect current market reality, the Price Oracle enforces strict data freshness constraints. Every price feed is configured with a specific `stalenessPeriod` (measured in seconds), typically derived from the feed provider's heartbeat or update frequency. * **The Check:** Upon every transaction requiring a price (e.g., borrowing, liquidating), the Oracle compares the current `block.timestamp` against the feed's `updatedAt` timestamp. * **The Revert:** If `block.timestamp - updatedAt > stalenessPeriod`, the transaction reverts immediately. This mechanism prevents the protocol from accepting invalid collateral or allowing under-collateralized borrowing during periods of oracle downtime or network congestion. ### Feed Types The protocol supports various data methodologies depending on the asset's liquidity profile and available onchain data. These are categorized into three primary mental models. #### 1. Spot Feeds Spot feeds provide the current market price based on off-chain aggregation or high-frequency on-chain updates. These are typically used for highly liquid "Blue Chip" assets where the price discovery happens on centralized exchanges or deep DEX pools. * **Push Models:** Traditional oracles where nodes push updates onchain at defined intervals or deviation thresholds (e.g., Chainlink, Redstone Push). * **Pull Models:** On-demand oracles where the price update is cryptographically signed off-chain and pushed onchain only when needed by a transaction (e.g., Pyth, Redstone Pull). This model reduces gas costs and allows for higher frequency updates. * **Use Case:** WETH, WBTC, USDC. #### 2. TWAP Feeds (Time-Weighted Average Price) TWAP feeds calculate the average price of an asset over a specific period (e.g., 30 minutes). This methodology dampens volatility and increases the cost of manipulation for assets that rely primarily on decentralized exchange liquidity. * **Mechanism:** Queries the cumulative price accumulator from an AMM (Automated Market Maker) and divides by the time elapsed. * **Use Case:** Curve LP Tokens, Pendle PTs, or long-tail assets where spot liquidity is thin. #### 3. Fundamental Feeds (Derived Value) Fundamental feeds determine value based on the on-chain backing or exchange rate of the asset, rather than secondary market trading activity. These feeds calculate what the asset is "worth" in terms of its underlying reserves. * **Mechanism:** Reads the `convertToAssets` or `getRate` function from the token contract and multiplies it by the underlying asset's USD price. * **Use Case:** ERC-4626 Vault Shares, Liquid Staking Tokens (LSTs), or Stablecoin peg-protection modules. ### Modular Pricing Architecture Beyond standard oracle integrations, Gearbox maintains a library of purpose-specific pricing contracts designed to collateralize complex DeFi positions. These modular feeds allow the protocol to support assets that lack direct secondary market feeds by programmatically deriving their value from the underlying protocol state: * **Curve & Balancer LPs:** Calculates the "Virtual Price" or fair value of the LP token based on the pool's invariant and the prices of the constituent tokens. * **Pendle PTs:** Derives the market price using a TWAP of the PT/SY exchange rate from the Pendle market contract. * **Bounded Feeds:** Wrappers that enforce upper or lower bounds on a price (e.g., capping a stablecoin at $1.00 or an LST at its backing ratio) to prevent manipulation during de-peg events. This architecture enables Curators to list productive assets (Vaults, LPs, Derivatives) as collateral without waiting for centralized oracle providers to support them. *** #### Learn More * **Safety & manipulation resistance:** How does the system protect against oracle manipulation and extreme market conditions? * [dual-oracle-system](https://docs.gearbox.finance/core/dual-oracle-system) ## Smart Oracles Source: https://docs.gearbox.finance/core/smart-oracles File: content/core/smart-oracles.mdx ## Safety-first design Gearbox oracle and solvency checks structure allows creating pricing methods with unique features: * Attract borrowers using hardcoded/ fundamental oracles + protect LPs by always taking market price into account.\ Read more: [dual-oracle-system](https://docs.gearbox.finance/core/dual-oracle-system) * Ensure timely liquidations using market oracles + protect LPs by always taking collateral fundamental value into account.\ Read more: [loss-policy](https://docs.gearbox.finance/core/loss-policy) ## Optimized for DeFi, scalable by default Gearbox supports major price feed providers, including Chainlink, Redstone (both pull and push models), and Pyth. Custom audited smart-contract feeds allow pricing of DeFi assets, including Pendle PT, Curve & Balancer LP tokens and more.\ Read more: [price-oracle](https://docs.gearbox.finance/core/price-oracle) ## Dual-Oracle System Source: https://docs.gearbox.finance/core/dual-oracle-system File: content/core/dual-oracle-system.mdx The Dual-Oracle System is the primary defense layer against price manipulation and oracle failure. By decoupling the valuation source used for liquidations from the source used for user operations, Gearbox ensures that short-term volatility or manipulation in one feed cannot be exploited to drain protocol liquidity. ### Dual-Feed Architecture Every asset in a Gearbox Market is configured with two independent price feeds. The protocol applies distinct logic to each feed depending on the context of the transaction. #### 1. Main Feed (Solvency & Liquidation) The **Main Feed** serves as the authoritative source for the system's internal accounting. * **Role:** Determines the Health Factor ($H\_f$) for liquidation triggers. * **Objective:** To reflect the asset's valuation for long-term solvency. #### 2. Reserve Feed (Safety & Operations) The **Reserve Feed** acts as a sanity check for user-initiated actions. * **Role:** Validates solvency during collateral withdrawals, debt increases, or complex multicall executions. * **Objective:** To prevent users from exploiting temporary price divergences to withdraw more collateral than they are entitled to. ### Pricing Methodologies To understand the utility of the Dual-Oracle system, one must first distinguish between the two primary methodologies for pricing DeFi assets. #### 1. Fundamental Price (Hardcoded / Backing Value) Prices the token based on the reserves that back it or its exchange rate (e.g., `1 stETH = 1 ETH` or `1 Stablecoin = $1`). | Stakeholder | Pros | Cons | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Borrowers** | Stability: Minimal risk of liquidation due to temporary market de-pegs. Accuracy: Reflects true staking appreciation immediately. | — | | **Lenders** | **Manipulation Resistance:** Immune to low-liquidity DEX manipulation. | Insolvency Risk: May overprice assets during real backing failures. Liquidity Lock: Funds may become stuck if the market price drops below the fundamental price, removing incentives for repayment. | #### 2. Secondary Market Price Prices the token based on buy/sell activity on DEXes or CEXes. | Stakeholder | Pros | Cons | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Borrowers** | — | Capital Inefficiency: Must maintain higher Health Factors to buffer against volatility. Liquidation Risk: Susceptible to cascading liquidations during market panic. | | **Lenders** | Pessimistic Pricing: Liquid tokens usually trade at a discount to backing, providing a safety buffer. Reactivity: Fast reaction to real market drops. | Manipulation Risk: Illiquid markets can be pumped to drain pool reserves at inflated valuations. Bad Debt: Liquidation cascades can lead to overselling collateral below debt value. | ### Comparison Logic: The "Safe Price" When a Credit Account executes a transaction that reduces its collateralization (e.g., withdrawing funds or borrowing more), the protocol calculates the account's value using the **Safe Price**. The Safe Price is derived dynamically for every asset in the portfolio: $$ P\_{Safe} = \min(P\_{Main}, P\_{Reserve}) $$ This `min()` logic creates an automatic circuit breaker. If the Main Feed and Reserve Feed diverge, the protocol enforces the lower (more pessimistic) valuation for all user operations, preventing the extraction of value during de-pegs or manipulation events. ### Scenario Analysis: The "Best of Both Worlds" By configuring the **Main Feed** as a Fundamental source and the **Reserve Feed** as a Market source, Gearbox protects lenders from manipulation while preserving capital efficiency for borrowers. The table below illustrates a scenario where a collateral token (e.g., sUSDe or deUSD) is used to borrow a stablecoin (USDC). | Scenario | Dual-Oracle System | Hardcoded Feed Only | Market Feed Only | | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Market price drops > 2.5% (Normal Volatility) | ✅ No Liquidations Main feed remains stable. | ✅ **No Liquidations** | ⚠️ Liquidations Triggered Risky positions are closed due to volatility. | | Market price drops > 10% (De-peg / Panic) | ⚠️ No Liquidations ✅ Withdrawals Blocked Safe Price uses the lower Market price ($0.90). Users cannot withdraw the "overvalued" asset, trapping liquidity in the protocol until solvency is resolved. | ⚠️ No Liquidations 🚨 Attack Vector: Attacker buys asset at $0.90, borrows $0.915 against it (at Face Value). Result: Protocol drained; Bad Debt created. | 🚨 Mass Liquidations Major portion of positions liquidated, potentially crashing price further. | | Market price pumps > 2.5% (Normal Volatility) | ✅ **No Liquidations** | ✅ **No Liquidations** | ✅ **No Liquidations** | | Market price pumps > 10% (Illiquid Market Manipulation) | ✅ No Liquidations ✅ Borrowing Blocked Safe Price uses the lower Fundamental price ($1.00). User cannot borrow against the inflated Market price ($1.10). | ✅ **No Liquidations** | ✅ No Liquidations 🚨 Attack Vector: Attacker mints asset at $1.00, pumps market to $1.10, borrows $1.02. Result: Protocol drained due to inflated valuation. | ### Circuit Breakers & Interaction Blocking The Dual-Oracle system enforces logic that effectively forbids interactions when data integrity is compromised. #### Transaction-Level Blocking The system does not require a global pause to stop exploits. It blocks individual transactions based on real-time data divergence: * **Withdrawal Block:** If $P\_{Main} \gg P\_{Reserve}$, the user's borrowing power is constrained by $P\_{Reserve}$. Users cannot withdraw funds based on the inflated Main price. * **Liquidation Protection:** Liquidations rely solely on the **Main Feed**. If the Main Feed is accurate but the Reserve Feed is broken/manipulated, liquidations can still proceed to keep the pool solvent, while user withdrawals (which require Reserve validation) are temporarily blocked to prevent capital flight. #### Divergence Thresholds While the protocol uses the `min()` logic continuously, significant divergence between Main and Reserve feeds serves as an off-chain signal for Risk Curators. * **Soft Breaker:** Small deviations are absorbed by the `min()` logic, simply reducing capital efficiency slightly. * **Hard Breaker:** Large deviations typically indicate a de-peg or oracle failure. In these scenarios, the `min()` logic effectively freezes new borrowing and withdrawals for that specific asset until the feeds converge or the Instance Owner updates the configuration. *** #### Learn More * **Bad debt handling:** How does the protocol handle bad debt if price safety mechanisms fail? * [loss-policy](https://docs.gearbox.finance/core/loss-policy) * **Price feed sources:** Where do the raw Main and Reserve price feeds originate? * [](https://docs.gearbox.finance/core/smart-oracles) ## Loss Policy Source: https://docs.gearbox.finance/core/loss-policy File: content/core/loss-policy.mdx ### The Problem: Market Price Cascades Using market oracles can sometimes trigger liquidation cascades, where a rapid price drop causes mass liquidations and further depresses the asset’s price. An example is the [ezETH cascading liquidations in April 2024](https://www.google.com/url?sa=E\&q=https%3A%2F%2Fprotos.com%2Fdepeg-of-3b-restaking-token-ezeth-causes-over-60m-in-defi-liquidations%2F). ![Figure](https://docs.gearbox.finance/assets/docs/core/loss-policy/01-the-problem-market-price-cascades.png) When prices fall too quickly, liquidators may be unable to react in time. As a result, positions can become insolvent before liquidation completes. In such scenarios, continuing to liquidate at the current market price may actually create bad debt, because collateral can be sold far below its fair or medium-term value. ### The Solution: Aliased Pricing To protect liquidity providers (LPs) in these situations, Gearbox implements a Loss Policy mechanism. **The logic is as follows:** 1. Positions are liquidated using market prices under normal conditions. 2. If a liquidation would create bad debt (Collateral Value < Debt), the protocol reprices the collateral using the **aliased price**, which can be configured to the asset’s fundamental value (e.g., Exchange Rate or 1.00 for stablecoins). 3. If the position is healthy under this fundamental pricing, the liquidation is halted. ![Figure](https://docs.gearbox.finance/assets/docs/core/loss-policy/02-loss-policy-protected-pool-flow.png) ### Execution Flow The Loss Policy acts as a conditional circuit breaker during the liquidation process. 1. **Standard Check:** Is Health Factor < 1 using the **Main Feed** (Market Price)? * **No:** Account is healthy. Do nothing. * **Yes:** Proceed to step 2. 2. **Bad Debt Check:** Does `Collateral Value < Debt`? * **No:** Liquidation proceeds normally. Liquidator repays debt and claims collateral. * **Yes:** The liquidation is flagged as a "Loss Liquidation". Proceed to step 3. 3. **Fundamental Check:** Is Health Factor < 1 using the **Aliased Feed** (Fundamental Price)? * **No:** The protocol assumes the market price is temporarily dislocated (flash crash). Liquidation is blocked to prevent realizing the loss at a distressed price. * **Yes:** The asset is fundamentally insolvent. Liquidation proceeds. #### Learn More * **Bad debt acknowledgment:** What happens when a liquidation proceeds under the Loss Policy and bad debt is realized? * [liquidation-dynamics](https://docs.gearbox.finance/core/liquidation-dynamics) ## DAO & Curators' business model Source: https://docs.gearbox.finance/core/dao-curators-business-model File: content/core/dao-curators-business-model.mdx ### Interest Fee (Revenue from Borrowing) The **Interest Fee** is the primary revenue source for the protocol and curators. It is a percentage markup applied to the borrowing interest paid by users. #### How It Works Unlike some protocols where the protocol fee is subtracted from the yield paid to liquidity providers (a “rake”), Gearbox uses an **additive model**. The fee is added on top of the base interest rate. * **Base & Collateral-specific Rate**\ The rate determined by the Interest Rate Model (IRM) plus any collateral-specific adjustments.\ \&#xNAN;*This portion is paid entirely to Liquidity Providers.* * **Interest Fee**\ A percentage markup applied to the Base Rate.\ \&#xNAN;*This portion is paid to the Market Curator and the Gearbox DAO.* #### Borrower Rate Formula $$ Rate\_{Borrower} = (Rate\_{Base} + Rate\_{Collateral-specific}) \times (1 + Fee\_{Interest}) $$ #### Example Calculation If market conditions dictate a base rate of **5%**, and the Curator has configured an Interest Fee of **20%**: 1. **Liquidity Providers earn:** 5.00% 2. **Protocol markup:** 5.00% x 20% = 1.00% 3. **Borrower pays:** 6.00% *** ### Revenue Split By default, all collected Interest Fees are split: * **50%** → Market Curator * **50%** → Gearbox DAO *** *** ### Liquidation Economics (Revenue from Risk) When a Credit Account becomes insolvent, it is liquidated. During liquidation, penalties are applied to the borrower for two purposes: * Incentivizing liquidators * Generating protocol revenue #### Components | Component | Recipient | Purpose | | ----------------------- | ------------- | -------------------------------------------------- | | **Liquidation Premium** | Liquidator | Incentive (“bounty”) for executing the liquidation | | **Liquidation Fee** | DAO & Curator | Protocol revenue from the liquidation | ## Insurance & Solvency Reserves Source: https://docs.gearbox.finance/core/insurance-solvency-reserves File: content/core/insurance-solvency-reserves.mdx The Gearbox Protocol employs an automated, on-chain reserve system designed to absorb bad debt and protect Passive Lenders. This mechanism functions not as an external insurance policy, but as a **retention buffer** on protocol revenue. Its primary objective is to ensure that the Liquidity Pool remains solvent even if a borrower's position is liquidated below the value of their debt. ### Conceptual Overview In traditional finance, this is analogous to a "First-Loss Capital" tranche. The protocol generates revenue through interest rates and liquidation fees. Rather than distributing 100% of this revenue to the DAO or Market Curators immediately, the system enforces a **mandatory savings threshold**. 1. **Revenue Accumulation:** All protocol fees flow into a specific contract (`TreasurySplitter`). 2. **The Safety Floor:** A target insurance amount is defined (e.g., 100,000 USDC). 3. **Conditional Distribution:** * **Below Target:** If reserves are below the target, **100% of revenue is retained**. No profit is distributed. * **Above Target:** Only the *excess* revenue (surplus) is distributed to the DAO and Curators. This ensures the protocol prioritizes solvency over profit extraction. *** ### Architecture: The Treasury Splitter The core component governing this logic is the `TreasurySplitter` contract. It acts as a gatekeeper between protocol fees and profit recipients. #### The Distribution Logic The `TreasurySplitter` holds assets (typically LP tokens of the pool it protects). When a distribution is attempted, the contract performs a logic check against the `tokenInsuranceAmount`. #### The Asset Composition The Insurance Fund does not sit idle. It is typically held in **LP Shares** (Diesel Tokens) of the pool it insures. This aligns the Treasury's interests with the Lenders' interests and allows the insurance capital to earn yield while waiting to be used. *** ### Bad Debt Coverage Mechanism "Bad Debt" occurs when a Credit Account is liquidated, but the collateral value is insufficient to repay the debt to the pool. Without insurance, this loss would be socialized among all Lenders (reducing the value of their LP tokens). The Insurance mechanism intervenes to prevent this socialization. #### The Coverage Flow 1. **Liquidation Event:** A liquidator closes a non-solvent Credit Account. The remaining collateral is sold, but a deficit remains (e.g., Debt: 100k, Collateral Value: 98k, Deficit: 2k). 2. **Loss Recognition:** The Credit Manager reports the loss to the Pool. 3. **Treasury Absorption:** The Pool burns **LP Shares held by the Treasury** equal to the value of the loss. By burning the Treasury's shares, the total supply of LP shares decreases, while the underlying assets in the pool remain (mostly) constant relative to the remaining Lenders. The Treasury effectively "pays" for the loss by giving up its claim on the pool's liquidity. *** ### On-Chain Verification Market participants can verify the solvency health of a pool by querying the `TreasurySplitter` contract directly. #### 1. Verify the Insurance Target (The Floor) To determine the minimum safety buffer the protocol enforces: * **Function:** `tokenInsuranceAmount(address token)` * **Interpretation:** This is the "water level." The protocol will not allow profit-taking if reserves drop below this value. #### 2. Verify Current Reserves (The Buffer) To determine the actual capital available to absorb losses: * **Function:** `IERC20(token).balanceOf(address treasurySplitter)` * **Interpretation:** * If `Balance > InsuranceAmount`: The pool is fully insured and generating surplus. * If `Balance < InsuranceAmount`: The pool is building reserves; all fees are currently being retained to increase safety. #### 3. Monitor Governance Changes Changes to insurance parameters require a dual-signature process (Curator + DAO). * **Function:** `activeProposals()` * **Interpretation:** Returns pending changes to the insurance floor or distribution logic. This allows Lenders to see if a Curator is attempting to lower safety parameters. *** ## Treasury-insured pools By default, all fees that the DAO receives from the protocol are made in dTokens. However, DAO can manage this by unwrapping part of the funds from the pools (thus, instead of dTokens, DAO will receive the usual underlying asset of the pool aka idle assets). This way, the DAO can limit its earnings from the Reserve Fund exposure. Essentially, the Gearbox dTokens inside this Fee Guard are the Insurance Fund. Anything that is not in dTokens has likely been voted to be unwrapped and kept as non Insurance Fund. Any non-dTokens are not counted towards the Insurance Fund size. And this only applies to V3 contracts. > > > This address holds all the fees accumulated. However, on the topic of the Reserve Fund, only look at the balances of dTokens. No other assets are relevant to the Reserve Fund. This Reserve Fund model doesn't relate to actual software hacks. It specifically covers cases of under-collateralization during liquidations. ### Learn more ## Audits & Bug Bounty Source: https://docs.gearbox.finance/core/audits-bug-bounty File: content/core/audits-bug-bounty.mdx Keep in mind that no number of audits can guarantee full safety. There are always high risks involved in DeFi, as many platforms are composable and depend on each other. There is no guaranteed return on Gearbox - you must **understand the risks involved**. ## Audits ![Figure](https://docs.gearbox.finance/assets/docs/core/audits-bug-bounty/01-gearbox-protocol-gear-audits-abdk-chain-security-sigma-prime.png) Gearbox protocol and its modules have been audited multiple times by top-tier security teams. For the full up-to-date list of contracts and reports please refer to [Bytecode Repository](https://permissionless.gearbox.foundation/bytecode), which acts as a source of truth for verification of each deployed contract. *** ## Bug Bounty The scope of the bug bounty refers to these contracts: []() Rewards are distributed according to the impact of the vulnerability. The final decision on the payout amount will be determined by the Gearbox DAO developers at their discretion. | Severity | Payment in USDC / other stablecoin | | |---|---|---| | Low | $100 - $1K | | | Medium | $1K - $5K | | | High | $5K - $20K | | | Critical | $20K - $200K (+ GEAR) | | For all assets labeled as “Gearbox v1” or "Gearbox v2" and deployed on the Ethereum network, only Critical and High impacts are in-scope. If you have found a bug that you think is within the security interests of the protocol but is outside of the scope of the repository above, please do notify us then anyway. We can decide ad-hoc together with you. 1/1 payouts have been done before based on this. Join the Bug Bounty with Immunefi! Help Gearbox stay safe and be rewarded for it. ![Figure](https://docs.gearbox.finance/assets/docs/core/audits-bug-bounty/02-bug-bounty.png) https://immunefi.com/bounty/gearbox/ If you need more information on the protocol, please check: * Regular protocol docs: [/ ](/) * Developer docs: **NOTE**: for bugs related to the interface which are just referring to typos and non-security related issues, please feel free to report them in a community [Discord](https://discord.gg/5YuHH9tvms) pro bono - and Gearbox community can maybe send nice GIFs your way. In case a bug you found is related to the interface and is outside of the scope, but has serious security concerns, please do report it as well and a bounty can be also decided ad-hoc. Again, you can ask all your questions in [Discord](https://discord.gg/JZgvmaenwn). ### Rules Determinations of eligibility, score and all terms related to an award are at the sole and final discretion of Gearbox Protocol working DAO members. The goal is to make sure the ecosystem is safe, and that proper bug bounty work is rewarded well. In order to be considered for a reward, all bug reports must contain the following: * Description of suspected vulnerability * Steps to reproduce the issue so we can check it * Your name and/or colleagues if you wish to be later recognized * (Optional) A patch and/or suggestions to resolve the vulnerability The following activities are **prohibited** by bug bounty program: * Testing with mainnet or public testnet contracts: all testing should be done on private testnets * Any testing with pricing oracles or third party smart contracts * Attempting phishing or other social engineering attacks against our employees and/or customers * Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) * Any denial of service attacks * Automated testing of services that generates significant amounts of traffic * Public disclosure of an unpatched vulnerability in an embargoed bounty Security is a continuous effort which must always be following protocol growth. As a DAO, it is imperative to constantly dedicate ample resources to ensure safety of funds. ## Market Curators Source: https://docs.gearbox.finance/core/market-curators File: content/core/market-curators.mdx The **Market Curator** is the operator of a specific lending market instance. Unlike traditional asset managers who actively allocate capital, Gearbox Curators act as **Risk Parameter Managers**. They define the boundary conditions—such as Loan-to-Value ratios, interest rate curves, and allowed collateral—under which the market operates. This role is permissionless: any entity can deploy a Market Configurator and launch a lending business on top of the Gearbox Protocol. ### Operational Model: Parameters, Not Funds The Curator does not have custody of user funds. Instead, the Curator manages a set of smart contracts that enforce rules on how funds can be utilized. ![Figure](https://docs.gearbox.finance/assets/docs/core/market-curators/01-operational-model-parameters-not-funds.png) * **No Custody:** Curators cannot withdraw Liquidity Provider (LP) funds or seize Borrower collateral (except via standard liquidation mechanics). * **No Active Allocation:** Curators do not manually move funds between strategies. They set the *eligibility* rules (e.g., "Strategy A is allowed up to $10M debt"), and the protocol automatically manages the flow based on user demand. ### Role Architecture To balance operational agility with security, Curator powers are segregated into distinct roles. These are typically assigned to different multisigs or governance controllers depending on the Curator's internal structure. #### 1. The Administrator (Governance) The ultimate authority for the market. This address controls the **Market Configurator** contract. * **Capabilities:** Can modify all risk parameters (LTVs, Supply Caps, Interest Models, Fee Splits). * **Constraint:** All actions are subject to a mandatory **Timelock** (see below). #### 2. The Emergency Admin (Security) A specialized role designed for crisis response. It has a limited subset of powers that bypass the timelock to prevent bad debt or exploits. * **Capabilities:** * Pause contracts (freeze borrowing/withdrawals). * Set debt limits to zero (stop new borrowing). * Forbid specific adapters or tokens (stop exposure to risky assets). * **Constraint:** Cannot *increase* risk (e.g., cannot raise LTVs or debt limits). Can only restrict operations. #### 3. Operational Roles Granular roles for day-to-day maintenance without full administrative access. * **Pausable/Unpausable Admin:** Can freeze or unfreeze specific market contracts. * **Fee Multisig:** Designated recipient for accrued protocol fees. * **Emergency Liquidator:** Whitelisted address permitted to liquidate positions when the market is paused. ### Safety Constraints: The Timelock To protect users from malicious or erroneous parameter changes, the protocol enforces a **Time-Delayed Execution** model for the Administrator role. * **The Rule:** Any transaction that alters a risk parameter (e.g., changing LTV from 80% to 90%) must be queued in the Timelock contract for a minimum of **24 hours** before execution. * **The Purpose:** This delay guarantees that Lenders and Borrowers have sufficient time to audit pending changes and exit the market if they disagree with the new risk profile. ### Economic Model Curators monetize their markets by configuring specific fee parameters. These fees are programmatic and deducted automatically by the smart contracts. #### Revenue Sources 1. **Interest Fee:** A percentage of the interest paid by borrowers. This is added on top of the base rate paid to Lenders. 2. **Liquidation Fee:** A percentage of the collateral value seized during a liquidation event. #### Fee Sharing The Gearbox Protocol infrastructure takes a share of the revenue generated by Curators to sustain the DAO and core development. * **Default Split:** 50% to the Curator / 50% to the Protocol DAO. * **Configuration:** This split is enforced at the `TreasurySplitter` contract level. #### Learn More * **Parameter reference:** Where can I find a comprehensive dictionary of all configurable risk parameters and their constraints? * [risk-configuration-dictionary](https://docs.gearbox.finance/core/risk-configuration-dictionary) ## Instance Owner Source: https://docs.gearbox.finance/core/instance-owner File: content/core/instance-owner.mdx The Instance Owner is a chain-specific technical multisig responsible for maintaining the integrity of the local Gearbox deployment. It acts as a **technical gatekeeper**, ensuring that critical infrastructure, specifically the Price Feed Store, remains secure, verified, and consistent across networks. Unlike Market Curators, who manage financial risk parameters, the Instance Owner operates under a strict mandate of **business neutrality**. It does not assess the economic viability of assets or strategies but ensures the underlying data feeds function correctly. ### The Neutrality Principle Gearbox enforces a strict separation between **Technical Maintenance** and **Financial Risk Management**. * **Market Curators (Financial Layer):** Responsible for setting LTVs, interest rates, and supply caps. They bear the economic risk of their decisions. * **Instance Owner (Infrastructure Layer):** Responsible for verifying that a price feed contract is technically sound, correctly configured, and secure. The Instance Owner does not gatekeep assets based on quality or volatility. If a Curator wishes to list a volatile asset, the Instance Owner’s sole responsibility is to ensure the requested price feed (e.g., Chainlink, Redstone, or TWAP) is implemented correctly and added to the registry. This prevents technical misconfigurations—such as decimal errors or stale feed pointers—without interfering in the free market of credit strategies. ### Core Responsibilities #### Price Feed Store Management The primary function of the Instance Owner is the management of the **Price Feed Store**, the onchain registry of allowed price sources for a specific network. Before a Curator can list an asset in a Credit Manager, the asset and its corresponding price feed must be whitelisted in the Price Feed Store. The Instance Owner verifies: 1. **Contract Verification:** The feed contract is verified on the block explorer. 2. **Source Integrity:** The feed points to the correct aggregator address (e.g., the official Chainlink or Pyth contract for that chain). 3. **Technical Specification:** The feed returns data in the format required by the Credit Manager (typically 8 decimals). Once verified, the Instance Owner adds the feed to the store, making it available for any Curator to use. * [**See: Price Oracle Architecture**](https://www.google.com/url?sa=E\&q=..%2Feconomics-and-risk%2Fprice-oracle.md) #### Protocol Upgrades & Maintenance While the Protocol DAO votes on global upgrades and new contract versions, the Instance Owner executes the specific transactions required to apply these updates to the local chain instance. This ensures that upgrades are applied atomically and correctly within the context of the specific network environment. ### Multisig Composition To maintain neutrality and prevent censorship, the Instance Owner multisig is composed of a diverse set of ecosystem participants. This structure ensures that no single entity can block a valid technical integration. **Typical Composition:** * **Threshold:** 4-of-12 (Subject to chain-specific configuration) * **Signers:** * Active Market Curators * Chain Foundation Contributors * Security Auditors * Partner Protocol Founders * Gearbox Core Contributors This broad distribution prevents the Instance Owner from becoming a point of centralization while maintaining a high bar for technical competence among signers. ![Figure](https://docs.gearbox.finance/assets/docs/core/instance-owner/01-credit-configurator-graph.png) ## Protocol DAO Source: https://docs.gearbox.finance/core/protocol-dao File: content/core/protocol-dao.mdx Unlike traditional DeFi protocols where the DAO manages risk parameters (like LTVs or Interest Rates) directly, Gearbox delegates these operational responsibilities to **Market Curators**. The DAO focuses on building the rails, while Curators operate the trains. ### Core Responsibilities #### 1. System Upgrades & Versioning The DAO maintains the core smart contracts that define the protocol's logic. It is the only entity capable of authorizing new versions of system components. * **Contract Updates:** The DAO votes to deploy and authorize new implementations of core contracts (e.g., `PoolV3`, `CreditManagerV3`). * **Bytecode Repository:** The DAO manages the onchain registry of verified contract bytecode. This ensures that when Curators deploy new markets, they are using secure, audited code approved by the protocol. #### 2. Chain Activation The DAO controls the expansion of the protocol to new blockchain networks. * **Instance Deployment:** Before Gearbox can operate on a new chain (e.g., Arbitrum, Optimism), the DAO must authorize the deployment of the **Instance Owner** and **Treasury** contracts on that network. * **Canonical Addressing:** The DAO ensures that there is a single, canonical instance of the protocol infrastructure on each supported chain, preventing fragmentation. #### 3. Economic Alignment (GEAR Token) The DAO utilizes the GEAR token to incentivize growth and align the interests of Curators, Liquidity Providers (LPs), and the protocol. * **Incentive Programs:** The DAO can vote to allocate GEAR tokens for liquidity mining or grants to bootstrap specific markets or integrations. * **Fee Split Configuration:** While Curators set the total fees for their markets, the DAO defines the protocol-level **Fee Split** (e.g., 50/50 split between Curator and DAO). Changing this global parameter requires a DAO vote. ### Limits of Authority To preserve the permissionless nature of the protocol, the DAO's power is strictly limited at the smart contract level. * **No Market Interference:** The DAO **cannot** change the risk parameters (LTVs, Liquidation Thresholds, Interest Rates) of a live market managed by a Curator. * **No Asset Management:** The DAO **cannot** seize or reallocate funds deposited into Curator-managed pools. This separation of powers ensures that Curators retain full sovereignty over their lending businesses. #### Learn More * **Risk management & operations:** Who manages risk parameters and oversees day-to-day market operations? * [market-curators](https://docs.gearbox.finance/core/market-curators) ## Protocol audits Source: https://docs.gearbox.finance/core/protocol-audits File: content/core/protocol-audits.mdx The **Bytecode Repository** is a core infrastructure component of Gearbox V3 designed to enable permissionless, multi-chain protocol expansion while maintaining strict security guarantees. It serves as a decentralized, on-chain registry for verified smart contract implementations. #### An On-Chain "GitHub" for Smart Contracts The Bytecode Repository acts as a decentralized version of a code hosting platform like GitHub, but for compiled EVM bytecode rather than source code. * **Versioned Catalog:** Like a GitHub repository with tags, it organizes contracts into **Domains** (e.g., `IRM` for interest rate models) and **Postfixes** (e.g., `_LINEAR`), allowing for semantic versioning (Major/Minor/Patch). * **Public vs. System Domains:** * **System Domains** (Core contracts like Credit Managers) are DAO-governed; updates require an on-chain vote. * **Public Domains** allow any developer to submit "plugins" (e.g., a new yield farming adapter). Once a developer's submission is verified, they "own" that identifier in the repository. * **Immutable Storage:** Instead of a centralized server, the contract uses **SSTORE2** to store the initialization code (init code) directly in the Ethereum state, ensuring it can never be deleted or modified. #### Protecting the Protocol Lifecycle The repository protects the protocol by decoupling the **upload** of code from its **deployment**, introducing a mandatory verification layer. **1. On-Chain Audit Verification** Before a contract can be deployed via the repository, it must be "audited" on-chain. This is not just a social claim; it is a cryptographic requirement: * **Approved Auditors:** The Gearbox DAO maintains a whitelist of approved auditor addresses in the `BytecodeRepository`. * **EIP-712 Attestations:** Auditors sign a specific `bytecodeHash`. This signature is submitted to the repository via `submitAuditReport`. * **Enforced Solvency:** The `deploy` function checks `isBytecodeAudited`. If a bytecode hash does not have a valid signature from an authorized auditor, the protocol will refuse to deploy it, preventing unverified or malicious code from entering the ecosystem. **2. Deterministic and Secure Deployment** The repository uses `CREATE2` to ensure that a contract deployed on Ethereum Mainnet will have the exact same address and code when deployed on L2s like Optimism or Arbitrum. * **Front-running Protection:** It mixes the deployer's address into the salt, preventing malicious actors from "sniping" a contract address before the legitimate user. * **Integrity Checks:** Upon deployment, the repository verifies that the resulting contract's `contractType` and `version` (via the `IVersion` interface) match the registry records. #### Key Security Features * **Init Code Blacklisting:** The DAO can permanently forbid specific `initCode` hashes (via `forbidInitCode`) if a vulnerability is found, effectively "bricking" that version and preventing any further deployments of it. * **Author Signatures:** Only the original author of the bytecode can upload it on Mainnet, preventing others from claiming ownership of a developer's work. * **Token-Specific Logic:** It handles edge cases (like USDT's non-standard transfer behavior) through `tokenSpecificPostfixes`, ensuring the correct specialized implementation is used for specific assets.
Sources * [contracts/global/BytecodeRepository.sol](https://github.com/Gearbox-protocol/permissionless/blob/master/contracts/global/BytecodeRepository.sol) * [specification.md](https://github.com/Gearbox-protocol/permissionless/blob/master/specification.md) * [contracts/interfaces/IBytecodeRepository.sol](https://github.com/Gearbox-protocol/permissionless/blob/master/contracts/interfaces/IBytecodeRepository.sol) * [contracts/traits/DeployerTrait.sol](https://github.com/Gearbox-protocol/permissionless/blob/master/contracts/traits/DeployerTrait.sol) * [script/UploadBytecode.s.sol](https://github.com/Gearbox-protocol/periphery-v3/blob/main/script/UploadBytecode.s.sol)
## V3.0 operational multisigs Source: https://docs.gearbox.finance/core/v3-0-operational-multisigs File: content/core/v3-0-operational-multisigs.mdx Multisig roles were split into a financial-treasury and technical. Both multisigs were created prior to the deployment ceremony by previous initial core members, as contracts needed to know the wallet addresses. Then, multisig members and a signer count requirement were added after **DAO voting procedures**. All this can be verified on-chain and Etherscan in logs of respective contracts. Multisig must execute whatever proposal reaches winning quorum. Given that multisig are members previously enacted by token holders, meaning the DAO, and are semi-public people with big reputation - in *extreme* cases they could voice against implementing some proposal. However, that could breach *trust* in the governance model and require immediate action and restructuring. This must be exercised carefully. ### Technical Guard | 6/12 Executes proposals which have reached quorum related to technical changes and the protocol. Ethereum Address: [0xA7D5DDc1b8557914F158076b228AA91eF613f1D5](https://etherscan.io/address/0xA7D5DDc1b8557914F158076b228AA91eF613f1D5) List of members on the multisig: 1. [zefram.eth](https://twitter.com/boredGenius) - Building [88mphapp](https://twitter.com/88mphapp), sudoswap, and more. Member of MetaCartel. 2. [Ignacio](https://twitter.com/iicc_eth) - Co-Founder of Stakely 3. van0k - Gearbox protocol developer 4. [0xmikko](https://twitter.com/0xmikko_eth) - original inventor of Gearbox \[on behalf of Gearbox Protocol Limited] 5. [Alex Smirnov](https://twitter.com/AlexSmirnov__) - co-founder of [deBridge](https://twitter.com/deBridgeFinance) 6. [MacLane Wilkison](https://twitter.com/MacLaneWilkison) - co-founder of [NuCypher](https://twitter.com/NuCypher) & [Threshold](https://twitter.com/TheTNetwork) 7. [Simone](https://twitter.com/kronosimste) - developer at [DegenScore](https://twitter.com/DegenScore) 8. [Lewi](https://twitter.com/lewifree) - OG degenerate & ESD summoner 9. [Klim](https://twitter.com/milkyklim) - data analytics and [YFI](https://twitter.com/iearnfinance) Maximalist 10. Alex - ex-Neutrino, a lobster and a builder 11. [Alex](https://twitter.com/0xAlexEuler) - CTO of [Mellow Protocol](https://twitter.com/Mellowprotocol) 12. [Lekhovitsky](https://twitter.com/lekhovitsky) - Gearbox protocol developer Transactions related to technical changes and protocol improvements are behind a 2-day timelock, and you can transparently observe every stage and queue in the [Risk Framework](https://risk.gearbox.foundation/updates): []() #### Veto / Unpause role | 4/12 Ethereum Address: [0xbb803559B4D58b75E12dd74641AB955e8B0Df40E](https://etherscan.io/address/0xbb803559B4D58b75E12dd74641AB955e8B0Df40E) A multisig with the same set of singers as the Technical Guard, but a lower 4/12 for faster response. The veto role is related to the ability to circumvent malicious proposals and transactions, it can only say "no" basically, but can't propose or push anything. The unpause role relates to unpausing. The pause function was granted to [2 analytical addresses](https://gov.gearbox.fi/t/gip-17-multisig-reshuffle-pausable-admin/1447) 1/1. They can only pause the protocol, in case their monitoring tools detect issues, in an attempt to stop the protocol from being fully exploited. In case that is possible and the time onchain gives that window. * 0xD5C96E5c1E1C84dFD293473fC195BbE7FC8E4840 * 0x65b384cecb12527da51d52f15b4140ed7fad7308 *** ### Treasury Guard | 5/10 Executes proposals which have reached quorum related to spending, grants, and the treasury overall. Ethereum Address: [0x7b065Fcb0760dF0CEA8CFd144e08554F3CeA73D1](https://etherscan.io/address/0x7b065Fcb0760dF0CEA8CFd144e08554F3CeA73D1) List of members on the multisig: 1. [Stani](https://twitter.com/StaniKulechov) - founder of [Aave](https://twitter.com/AaveAave), venture partner at [Variant Fund](https://twitter.com/VariantFund) 2. [Amplice](https://twitter.com/astr0bas3d) - [lobsterdao](https://twitter.com/10b57e6da0) member & core DAO contributor on marketing 3. [Pepo](https://twitter.com/0xPEPO) - contributor of [Wonderland](https://twitter.com/defi_wonderland) & [DeFi LATAM](https://twitter.com/defi_latam) 4. [Sergey](https://t.me/icodrops_sergey) - founder of [ICODrops](https://twitter.com/ICODrops) 5. [NDW](https://twitter.com/cryptondee) - Castle Capital member and a DeFi degen 6. [apeir99n](https://twitter.com/apeir99n) - original math & product at Gearbox \[on behalf of Gearbox Protocol Limited] 7. [Nikitakle](https://twitter.com/NOstroymov) - core DAO contributor on marketing & community 8. [Amantay](https://twitter.com/amantay_a) - core DAO contributor on risk & analytics 9. [duckdegen.eth](https://twitter.com/DuckDegen) - devrel, ex-Connext \[[GIP-40](https://gov.gearbox.fi/t/gip-40-financial-multisig-reshuffle/2204/5)] 10. [Vadym](https://twitter.com/0x_vadym) - head of product at Kolibrio Spending and grants paid out can be seen in monthly DAO reports: []() #### Fee Temporary Guard 5/10 Ethereum Address: [0x3E965117A51186e41c2BB58b729A1e518A715e5F](https://etherscan.io/address/0x3E965117A51186e41c2BB58b729A1e518A715e5F) A temporary multisig with the same set of singers as the Treasury Guard. It is created to separate funds from the DAO rounds which are used for the development of the protocol. This Fee Guard collects all fees from the protocol and can later on give control over to an initiative which will focus on staking programs, or whatever else the DAO decides to do. It's a holder of fees for now. #### Rewards management Guard 2/3 Executes rewards distribution and sets up temporary incentive campaigns, typically provided by partner protocols. Ethereum address: [0x6f378f36899cEB7C6fB7D293aAE1ca86B0Edbf6D](https://app.safe.global/transactions/history?safe=eth:0x6f378f36899cEB7C6fB7D293aAE1ca86B0Edbf6D) ## Risk Configuration Dictionary Source: https://docs.gearbox.finance/core/risk-configuration-dictionary File: content/core/risk-configuration-dictionary.mdx Flexibility is at the core of Gearbox’s design. Credit Accounts support a wide range of on-chain assets as collateral, which requires a risk framework capable of handling diverse asset properties. Gearbox’s risk controls are built to operate under uncertainty and adapt to any market conditions. Gearbox is a platform for the permissionless creation and curation of lending markets. To participate safely, both Curators and Users must understand the risk-control allowlist: Curators need to know the capabilities it grants, while Users should understand the trust assumptions they accept when engaging in lending activity. ### Curator Roles The Curator utilizes two primary roles to modify market parameters: * **Admin**\ Can modify all configurable parameters, subject to a minimum **24-hour timelock**. * **Emergency Admin**\ Can update a limited set of risk parameters **instantly** (without timelock) to mitigate immediate threats. ### Pool-Level Rules These parameters define the global constraints for the Liquidity Pool. If a user disagrees with these terms, they must select a different pool. #### Definitions * **Total debt limit:** Maximum amount of underlying assets that can be borrowed across the entire pool. * **Collateral limit:** Maximum amount of debt that can be backed by a specific collateral token (Quota Limit). * **Main Price Feed:** Primary price source used for calculating account value and triggering liquidations. * **Reserve Price Feed:** Secondary price source used to run safety checks on operations; can block Credit Account actions to protect LPs. * **Increase Rate:** One-time fee charged whenever exposure to a collateral increases. * **Collateral-specific rate:** Additional interest rate (APR) charged for borrowing against a specific collateral. * **IRM:** The Utilization-based Interest Rate Model contract. * **Loss Policy:** The logic executed when a liquidation results in bad debt. * **Emergency liquidators whitelist:** Addresses authorized to liquidate accounts when the Credit Manager is paused (Default: Permissionless). * **Loss liquidators whitelist:** Addresses authorized to execute liquidations that result in bad debt (Default: Permissionless). #### Permissions Matrix | Parameter | Admin (24h Delay) | Emergency Admin (Instant) | | ----------------------------------- | :---------------: | ------------------------- | | **Total debt limit** | ✅ | ⚠️ Reduce to zero-only | | **Collateral limit** | ✅ | ⚠️ Reduce to zero-only | | **Main Price Feed** | ✅ | ⚠️ Limited choice | | **Loss Policy** | ✅ | ⚠️ Can turn off | | **Loss liquidators whitelist** | ✅ | ⚠️ Can turn off | | **Emergency liquidators whitelist** | ✅ | ⚠️ Can turn off | | **Reserve Price Feed** | ✅ | ❌ | | **Increase Rate** | ✅ | ❌ | | **Collateral-specific rate** | ✅ | ❌ | | **IRM** | ✅ | ❌ | ### Credit Manager-Level Rules These parameters define the strategy for a specific Credit Manager. If a user disagrees with these terms, they can choose another Credit Manager within the same pool. #### Definitions * **Total debt limit:** Maximum aggregate debt of all Credit Accounts created from this Credit Manager. * **MinDebt:** Minimum required debt to open a Credit Account. * **MaxDebt:** Maximum permitted debt per Credit Account. * **Liquidation Premium:** Percentage of collateral value paid to the liquidator as an incentive. * **Liquidation Fee:** Percentage of collateral value paid to the Protocol (Curator & DAO). * **Max Enabled Tokens:** Maximum number of collateral tokens a single account can enable simultaneously. * **Interest Fee:** Percentage of borrowing interest captured as revenue (split between Curator & DAO). * **Collateral's LT:** The Liquidation Threshold (Loan-to-Value ratio). * **Collateral's forbidden status:** Controls whether a token is allowed or forbidden. * **List of allowed adapters:** Restricts which external contracts (e.g., Uniswap, Curve) a Credit Account can interact with. * **Expiration Policy:** Date after which the strategy winds down. After this date, all Credit Accounts become liquidatable regardless of Health Factor. #### Permissions Matrix | Parameter | Admin (24h Delay) | Emergency Admin (Instant) | | ---------------------------- | :---------------: | ------------------------- | | **Total debt limit** | ✅ | ⚠️ Reduce to zero-only | | **List of allowed adapters** | ✅ | ⚠️ Forbid-only | | **Collaterals list** | ✅ | ⚠️ Forbid-only | | **Liquidation Premium** | ✅ | ❌ | | **Liquidation Fee** | ✅ | ❌ | | **Collaterals' LT** | ✅ | ❌ | | **Expiration Policy** | ✅ | ❌ | | **MinDebt** | ❌ | ❌ | | **MaxDebt** | ❌ | ❌ | | **Max Enabled Tokens** | ❌ | ❌ | | **Interest Fee** | ❌ | ❌ | Flexibility is at the core of Gearbox’s design. Credit Accounts support a wide range of on-chain assets as collateral, which requires a risk framework capable of handling diverse asset properties. Gearbox’s risk controls are built to operate under uncertainty and adapt to any market conditions. Gearbox is a platform for the permissionless creation and curation of lending markets. To participate safely, both Curators and Users should understand the risk-control allowlist: Curators need to know the capabilities it grants, while Users should understand the trust assumptions they accept when engaging in lending activity. Curator has 2 main roles to modify markets' parameters: * **Admin** Can modify all configurable parameters, subject to a minimum 24-hour timelock. * **Emergency Admin** Can update a limited set of risk parameters without a timelock in emergency situations. All the rules below will have a specification based on which access those roles have. ## Pool-level rules If a user disagrees with these terms, they need to select another pool. * **Total debt limit:** maximum that can be borrowed across the entire pool * **Collateral limit:** maximum that can be borrowed against each token * **Main Price Feed:** price source for calculating account value and triggering liquidations * **Reserve Price Feed:** runs safety checks on operations and can block Credit Account actions to protect LPs * **Increase Rate:** one-time fee whenever exposure to a collateral increases * **Collateral-specific rate:** extra interest for borrowing against a given collateral * **IRM:** utilization-based interest rate model * **Loss Policy:** additional liquidation logic for cases that create bad debt * **Emergency liquidators whitelist:** when Credit Manager is paused, liquidations are performed in "Emergency" mode which allows to restrict access to liquidations. By default they are permissionless * **Loss liquidators whitelist:** when a liquidation creates bad debt, it's performed in "Loss" mode mode which allows to restrict access to liquidations. By default they are permissionless ### **Credit Manager-level rules** If a user disagrees with these terms, they can choose another Credit Manager within the same pool. * **Total debt limit:** maximum aggregate debt of all Credit Accounts created from this Credit Manager * **MinDebt:** minimum required debt for a Credit Account * **MaxDebt:** maximum permitted debt for a Credit Account * **Liquidation Premium:** portion of collateral value paid to the liquidator during liquidation * **Liquidation Fee:** portion of collateral value paid to the curator and Gearbox DAO during liquidation * **Max Enabled Tokens:** number of different collateral tokens that can count toward account value * **Interest Fee:** extra rate on top of the IRM and collateral-specific rate, split between the curator and DAO * **Collateral's LT** (loan to value) * **Collateral's forbidden status** * **List of allowed adapters:** restricts which external contracts a Credit Account can use * **Expiration Policy:** curator may set an expiration; after the cutoff date, all Credit Accounts become liquidatable regardless of Health Factor with penalties set by the expired liquidation fee and premium parameters. ## Usecase: Direct Redemptions Source: https://docs.gearbox.finance/core/usecase-direct-redemptions File: content/core/usecase-direct-redemptions.mdx ## The problem: constrained instant liquidity ⇒ leverage stops working properly Other lending protocols must treat assets with timelocked liquidity like standard tokens and rely on DEX liquidity to enable leverage. Building and maintaining deep DEX liquidity is hard, leading to thin books and low collateral limits. Furthermore, asset issuers often have to pay to seed and maintain DEX liquidity. **This leads to fragmented UX and capital-inefficiency**, forcing users to wait for weeks or pay months worth of yield for instant liquidity ![Figure](https://docs.gearbox.finance/assets/docs/core/usecase-direct-redemptions/01-problem-constrained-instant-liquidity-leverage-stops-working-properly.png) ## Gearbox's Solution **Zero DEX Liquidity Required:** With Gearbox, leverage can go live on day one. It eliminates the need for DEX liquidity seeding, working at any size. **Direct Integration:** Execution is handled through direct smart-contract integration, allowing deposits and withdrawals at face value. **Benefits for users:** * Save time up to **8 periods** of native redemption. * Capital requirements are reduced by **10x**. * Save fees equal to a **month of farming yield**. ## How it works For simplicity, we refer to the example semi-liquid asset as xVAULT, since vaults are a common example of assets with these properties. The same logic also applies to RWAs, LRTs, and other tokens with time-locked liquidity. ![Figure](https://docs.gearbox.finance/assets/docs/core/usecase-direct-redemptions/02-how-it-works.png) ### Take leverage * User adds USDC to Credit Account and borrows 5x more to get leveraged exposure on xVAULT yield * Credit Account deposits 6x USDC to xVAULT issuance contract and receives the xVAULT ### Undwind position * The Credit Account holds an xVAULT token and has an outstanding USDC debt. * The user starts the redemption process: Credit Account sends the xVAULT token to the redemption contract. * In return, the Credit Account receives a redemption receipt token, which represents a future claim on the underlying asset. * The Credit Account now holds the redemption receipt token and USDC debt. #### After the Redemption Window: * Once the redemption window has passed, the user can finalize the redemption. * The Credit Account burns the redemption receipt token and receives USDC to repay debt. The Credit Account always stays overcollateralized, while collateral transfroms from xRWA into redemption receipt token and eventually into liquid underlying. ## Usecase: Intent-based lending Source: https://docs.gearbox.finance/core/usecase-intent-based-lending File: content/core/usecase-intent-based-lending.mdx Programmable Credit with Predictable Outcomes for Institutional Lenders ### The Problem DeFi lending looks liquid, but behaves like a black box. **Your capital goes into a vault.** Rates move unpredictably. Risks get pooled. When something breaks: MEV, liquidations, curator mistakes — losses are socialized. You find out the hard way it was never really your money. **For regulated institutions, it gets worse:** comingled funds, unknown counterparties, no audit trail. Most compliance frameworks require counterparty identification and fund segregation. Pooled DeFi offers neither. *Legacy finance offers bespoke terms, but with counterparty risk, settlement delays, and opaque execution.* *** ### The Solution **Post your terms. Match with counterparties. Execute on-chain.** You don't "deposit." You define: * Asset, size, duration * Rate: fixed (5% APY) or reference-based (LIBOR + 2%, Aave + 3%) * Accepted collateral and strategies * Compliance requirements Your order is signed and immutable. No curator can change it. No protocol upgrade can rewrite it. When a counterparty matches your terms, the contract executes. Until then, your capital stays productive where it already is. **You own the terms. You own the risk. You own the exit.** *** ### How It Works | | Step | |---|---| | 1️⃣ | Post — Define exact terms: rate, collateral, duration, compliance gates. Sign onchain. | | 2️⃣ | Match — Engine pairs compatible orders with counterparty verification. No gatekeepers. | | 3️⃣ | Execute — Isolated pool + credit account deployed with your exact parameters. | | 4️⃣ | Exit — Sell position on secondary market anytime, or wait for maturity. | No idle capital. No comingled funds. No curator risk. *** ### Why Gearbox | | Capability | Benefit | |---|---|---| | 🎯 | Predictable Rates | Fixed or reference-based (LIBOR, Aave). You define the formula: no utilization roulette. | | 🔗 | Controlled Composability | Lender defines allowed strategies. Borrower executes within boundaries: transparent, on-chain enforced. | | 🏦 | Custom Collateral | Tokenized equities, private credit, real estate. Each deal: own oracle, own risk params. | | 🔄 | Secondary Market | Sell active positions anytime. Turn illiquid terms into liquid exits. | | 🔒 | No Curator Risk | Once matched, the contract is final. No vault-level loss sharing. No surprises. | | 📋 | Regulatory Alignment | No comingled funds, clear audit trails, counterparty-specific compliance. | *** ### Regulatory Alignment Traditional DeFi pools create compliance barriers. Intent-based lending solves them: | | Requirement | ✅ Solution | |---|---|---| | 👤 | Know Your Counterparty | Direct matching. Verifiable filtering of participants. | | 🔒 | No Comingling | Isolated infrastructure per deal. Capital never mixes. | | 📝 | Audit Trail | On-chain record: who, what, when, all transactions. | | ✓ | Compliance Gates | Per-deal KYC/AML, jurisdiction, accreditation checks. | | 🛡️ | Risk Segregation | One default doesn't cascade to other positions. | This structure aligns with emerging regulatory frameworks for institutional DeFi participation. *** ### RWA Collateral | | Collateral Type | Example | |---|---|---| | 📈 | Tokenized Securities | Borrow USDC against S&P 500 ETF tokens | | 💼 | Private Credit | Collateralize with tokenized loan tranches | | 🏠 | Real Estate | Borrow against tokenized property | | 🏛️ | T-Bills | Treasury tokens as pristine collateral | Custom price feeds, LTV ratios, liquidation parameters—negotiated per intent. *** ### Capital Efficiency | | Traditional Pool | Intent-Based | |---|---|---| | 💰 Capital | ❌ Locked on deposit | ✅ Productive until match | | 📊 Rates | ❌ Utilization-driven volatility | ✅ Defined formula (fixed or reference-based) | | 🏦 Collateral | ❌ Single profile | ✅ Custom per agreement | | ⚠️ Risk | ❌ Socialized losses | ✅ Isolated per deal | | 🚪 Exit | ❌ Wait for utilization | ✅ Secondary market anytime | *** ### Product Preview Both sides define their exact terms: asset, rate (fixed or reference-based), duration, LTV, and counterparty compliance requirements (KYC, jurisdiction, institutional status). | Lender View | Borrower View | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ![](https://docs.gearbox.finance/assets/docs/core/usecase-intent-based-lending/01-intent-lending-lender-ui.png) | ![](https://docs.gearbox.finance/assets/docs/core/usecase-intent-based-lending/02-intent-lending-borrower-ui.png) | *** ### Next Step Interested in institutional-grade DeFi lending with predictable rates, custom collateral, and compliance controls? **Contact the Gearbox team** to discuss pilot programs for intent-based credit markets. ## Usecase: Faster RWA settlement with leverage Source: https://docs.gearbox.finance/core/usecase-faster-rwa-settlement-with-leverage File: content/core/usecase-faster-rwa-settlement-with-leverage.mdx How Gearbox enables faster entry/exit for RWA-backed debt positions with non-atomic settlement, using ACRED leverage as an illustrative go-to-market use case. *** ### The Problem: Slow Settlement Breaks RWA-Backed Debt Positions RWA tokens (tokenized securities, private credit, treasuries) typically do not settle atomically. Deposits (e.g., USDC → ACRED mint) can require hours or days, while redemptions can be materially longer (ACRED can be \~90 days). This settlement profile constrains RWA-backed debt strategies (leverage is the clearest example): * **Limited ability to react to market opportunities** — by the time a deposit matures, market conditions may have changed * **Limited ability to exit during volatility** — positions can remain in redemption queues while prices move * **Lower liquidator participation** — institutional liquidators are reluctant to warehouse long-dated redemption receipts (ACRED: \~90 days) Traditional flash-loan style flows are insufficient because standard ERC20 collateral is unavailable during the waiting period. *** ### The Solution: Up to 10x Faster Entry/Exit for RWA-Backed Debt Positions Gearbox acts as a **prime brokerage layer** that holds positions during transition phases — when assets are pending deposits or redemption receipts, not yet standard ERC20s. **Result:** Partner lending platforms can support RWA-backed debt positions with materially faster entry/exit handling. * **Time to open an RWA-backed debt position:** can be near-immediate (Hour 0), instead of waiting for mint completion. * **Time to unwind credit position backed by RWA:** 1 redemption period, instead of iterative deleverage slowed by multi-day redemptions. *** ### Who Benefits | User | Current Problem | With Gearbox | | ----------------- | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | **Traders** | Miss entry points during multi-day settlement | Get an RWA-backed debt position immediately, then exit when appropriate | | **Liquidators** | Reluctant to take on long-dated redemption risk (ACRED can be \~90 days) | Fast de-risking path (sell/finance receipt), reducing duration exposure | | **Risk Curators** | Limited ability to offer fast credit products on RWAs with delayed settlement | Integration-ready infrastructure with no core protocol changes required | *** ### Exit Speed Comparison (ACRED Redemption) * **Time to de-risk position exposure:** near-immediate with Gearbox vs \~90 days without * **Time to unwind leveraged position into stablecoins:** \~90 days with Gearbox vs >240 days without Gearbox improves liquidity and risk transfer during the waiting period; it does not shorten issuer redemption cycles *** ### How It Works Gearbox acts as a **prime brokerage layer** that holds positions during transition phases — when assets are not yet standard ERC20s but pending deposits or redemption receipts. ``` **What happens:** * User interacts with familiar **Partner UI** * **Partner Market** holds positions when collateral is mature ERC20 * **Gearbox** holds positions during transition (pending deposits, redemption receipts) * **Curator** moves liquidity between Partner Market and Gearbox as positions mature **Result:** Partner lending platforms can offer faster RWA-backed debt products without modifying their core architecture. *** ### Actors & Contracts | Actor | Role | Contracts | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | **User** | Borrower opening an RWA-backed debt position | User wallet | | **Partner Market Curator** | Capital allocator. Manages liquidity allocation between Partner vaults and Gearbox pool. Takes lending-side risk. | Partner allocator contracts | | **Gearbox Curator** | Configures collateral types including transition-stage assets. Sets risk parameters for pending deposits and redemption receipts. | Credit Configurator | | **Partner Market** | Lending infrastructure for mature ERC20 positions | Partner market contracts | | **Partner Vault** | Liquidity source. Holds capital allocated by curators. | Partner vault contracts | | **Gearbox** | Transitional venue. Holds positions during deposit/redemption windows. | Pool, Credit Manager, Credit Facade, Credit Account | | **Securitize** | ACRED issuer. Handles mint and redeem operations. | ACRED token, mint contract, redeem contract | #### Curator Relationship Partner Market curators and Gearbox curators are **formally different roles** but can be the same entity. A single party may: * Configure the Partner Vault and allocate to Gearbox * Configure the Gearbox market for transition-stage collateral This alignment simplifies risk management and capital efficiency. *** ### Position Transfer Mechanism When a position matures (pending-deposit → ACRED), it can be migrated from Gearbox to the Partner Market. Two approaches: Migration between Gearbox and Partner Market does not require additional capital because both sides of the position move simultaneously: * **Curator** controls supply-side allocation — moves liquidity between Gearbox Pool and Partner Market * **User** (via Credit Account) controls debt + collateral — repays one venue, borrows from the other When curator and user are coordinated (e.g., via smart contract integration or allocator contracts), supply and debt move together. The financial position stays exactly the same — same collateral, same debt, same health factor. Only the infrastructure changes. This coordination can be implemented at the contract level, but the specifics are integration-dependent. *** ### Entry Flow (Illustrative Use Case): Taking 5x Leverage on ACRED User wants $500 ACRED exposure with $100 own capital. #### Phase 1: User Intent ``` * User opens leveraged position through Partner UI * Transaction triggers Allocator (via adapter) to rebalance capital * Allocator moves USDC from Partner Vault to Gearbox Pool * Capital is now available for the Credit Account to borrow (next phase) #### Phase 2: Transition Setup (Gearbox + Securitize contracts) ``` **Key Points:** * **Credit Account opened** via adapter (same transaction as Phase 1) * User's $100 + borrowed $400 = $500 total position * **Pending-deposit token is valid collateral** (curator-configured) * Position remains overcollateralized during wait #### Phase 3: Waiting ``` * Deposit window passes (hours to days depending on ACRED terms) * Pending-deposit token becomes ACRED * Position still on Gearbox Credit Account #### Phase 4: Migration to Partner Market (Partner + Gearbox contracts) User triggers migration (manual or auto-opt-in): ``` * **Allocator withdraws** liquidity from Gearbox Pool and **supplies** to Partner Market * **Borrow $400 USDC** from Partner Market * **Repay Gearbox debt** with borrowed USDC * **Supply ACRED** to Partner Market as collateral * **Close Credit Account** **Result:** User has overcollateralized ACRED position on Partner Market. $500 ACRED collateral, $400 USDC debt. No additional capital is required — curator's supply-side reallocation and the user's debt migration happen together, so the financial position is unchanged (see [Position Transfer Mechanism](#position-transfer-mechanism)). *** ### Exit Flow: Redeeming ACRED Position User wants to exit a $500 ACRED RWA-backed debt position ($100 equity, $400 debt) and receive USDC. #### Why Exit Speed Matters * **Liquidators avoid long-dated redemption risk** — ACRED redemption can be \~90 days * **Near-immediate de-risking path enables more active liquidation participation** * **Gearbox provides transition liquidity service** for liquidated positions #### Phase 1: User Intent ``` * User exits position through Partner UI * Transaction triggers Allocator (via adapter) to rebalance capital * Allocator moves USDC from Partner Vault to Gearbox Pool #### Phase 2: Transition Setup (Gearbox + Securitize contracts) ``` * **Credit Account opened** via adapter (same transaction as Phase 1) * **Borrow $400 USDC** from Gearbox pool * **Repay Partner Market debt** with borrowed USDC * **Release ACRED** from Partner Market to Credit Account * **Initiate redemption** → Credit Account sends $500 ACRED to Securitize, receives redemption receipt * **Position:** Redemption receipt (collateral) + $400 USDC debt * **Overcollateralized** because Gearbox curator configured redemption receipt as valid collateral **Result:** User has zero position on Partner Market, overcollateralized position on Gearbox (redemption receipt collateral, USDC debt). As with entry migration, this is capital-neutral — supply and debt move together between venues. #### Phase 3: Waiting ``` * Redemption window passes (ACRED can be long-dated, e.g., \~90 days; issuer-dependent) * Redemption receipt matures → USDC received * Position remains on Gearbox Credit Account until final settlement #### Phase 4: Finalization & Close (Gearbox + Partner contracts) User triggers finalization (manual or auto-opt-in): ``` * **Repay $400 debt** to Gearbox pool * **Close Credit Account** * **User receives** net USDC: redemption proceeds minus debt, interest, and fees (plus/minus PnL) * **Allocator rebalances** liquidity from Gearbox Pool back to Partner Market `Net user payout = redemption proceeds - repaid debt - accrued borrow interest - protocol fees ± position PnL` **Result:** Position fully closed. User has USDC in wallet. *** ### Exit Value for Liquidators Gearbox's speed advantage is most valuable during liquidations. #### The Liquidator's Problem When an RWA-backed debt position becomes undercollateralized: 1. Traditional approach: Liquidator takes position, initiates redemption, and often holds the receipt to settlement (ACRED: \~90 days) 2. Problem: Institutional liquidators are reluctant to hold long-dated redemption receipts through volatile periods 3. Result: **Lower liquidation participation can increase bad-debt risk** #### The Gearbox Solution 1. Liquidator takes position in Credit Account 2. Redemption receipt is already there (or can be initiated immediately) 3. Liquidator can hold until redemption matures 4. **Or:** Gearbox curator can provide near-immediate liquidity by buying/financing the receipt at a discount #### Value Proposition | Metric | Traditional | With Gearbox | | ------------------------------------ | ---------------------------------------------------------- | -------------------------------------------------- | | Time to de-risk position exposure | Often tied to full redemption window (\~90 days for ACRED) | Near-immediate if receipt is sold/financed | | Time to final issuer cash settlement | \~90 days (ACRED illustrative) | \~90 days (issuer-dependent; unchanged by Gearbox) | | Liquidator risk | High (duration + market exposure) | Lower (faster de-risking path) | | Protocol health | Lower liquidation participation, higher bad-debt risk | More active liquidation participation | **Key insight:** The same mechanism that helps traders enter fast also helps liquidators de-risk faster, while final settlement remains issuer-timed. This makes the system healthier under stress. *** ## Interest Rate Model Source: https://docs.gearbox.finance/core/interest-rate-model-2 File: content/core/interest-rate-model-2.mdx The Interest Rate Model (IRM) is a critical component of the Gearbox Protocol that determines the cost of borrowing for Credit Accounts. In Gearbox V3, the protocol primarily utilizes a **Two-Point Linear Interest Rate Model** (`IRM::LINEAR`), designed to provide more stable rates and prevent sudden interest spikes during large liquidity fluctuations. ### Pool and IRM Interaction The `PoolV3` contract acts as the primary consumer of the IRM. It does not store interest rate logic internally but instead queries the IRM whenever the pool's state changes. #### Triggering Rate Updates The pool triggers a rate recalculation via the IRM's `calcBorrowRate` function during any operation that affects the pool's utilization: * **Lending Operations**: `deposit`, `mint`, `withdraw`, and `redeem`. * **Borrowing Operations**: `lendCreditAccount` (when a user opens or increases debt) and `repayCreditAccount` (when debt is repaid or an account is liquidated). #### Optimal Borrowing Check A unique feature of the V3 IRM is the `checkOptimalBorrowing` flag. When a Credit Manager attempts to borrow funds via `lendCreditAccount`, it passes `true` to this flag. If the IRM is configured with `isBorrowingMoreU2Forbidden = true`, the call will revert if the new borrowing would push the pool's utilization beyond the U\_2 (steep region) threshold. This ensures a liquidity buffer remains available for lenders to withdraw. ### The Two-Point Linear Model Unlike traditional models that use a single "kink," Gearbox V3 introduces an intermediate region to smooth the transition between low utilization and the "liquidity crunch" (steep) region. | Region | Range | Slope | Description | | ---------------- | --------------- | ------------- | --------------------------------------------------------------------- | | **Obtuse** | $0 \to U\_1$ | $R\_{slope1}$ | Low utilization; rates grow slowly. | | **Intermediate** | $U\_1 \to U\_2$ | $R\_{slope2}$ | Normal operation; provides a buffer before the steep curve. | | **Steep** | $U\_2 \to 100%$ | $R\_{slope3}$ | Emergency region; rates increase aggressively to encourage repayment. | ### Fetching Core Parameters Users and integrators can fetch the parameters influencing their interest rates through multiple layers. #### 1. Direct Contract Queries You can call the IRM contract directly using the `ILinearInterestRateModelV3` interface: * **`getModelParameters()`**: Returns the fixed configuration ($U\_1, U\_2, R\_{base}, R\_{slope1}, R\_{slope2}, R\_{slope3}$) in basis points (1/100th of a percent). * **`isBorrowingMoreU2Forbidden()`**: Returns whether the pool blocks borrowing above $U\_2$. * **`calcBorrowRate(expected, available, check)`**: Returns the current borrow rate in **RAY** ($10^{27}$) based on hypothetical liquidity levels. #### 2. High-Level Pool State The `PoolV3` provides the results of the IRM's calculation: * **`baseInterestRate()`**: Returns the current annual interest rate (in RAY) currently applied to all borrowers. * **`supplyRate()`**: Returns the annual rate earned by LPs, which is the `baseInterestRate` scaled by utilization, plus quota revenue. ```typescript // TypeScript: Reading interest rates from pool const borrowRate = await pool.read.baseInterestRate(); const supplyRate = await pool.read.supplyRate(); // Convert from RAY (27 decimals) to percentage const RAY = 10n ** 27n; const borrowAPR = Number(borrowRate * 10000n / RAY) / 100; // e.g., 5.25% const supplyAPY = Number(supplyRate * 10000n / RAY) / 100; // Reading IRM parameters directly const irm = getContract({ address: irmAddress, abi: linearInterestRateModelAbi, client: publicClient, }); const params = await irm.read.getModelParameters(); // Returns: [U1, U2, Rbase, Rslope1, Rslope2, Rslope3] in basis points ``` ### Security and Risk Considerations * **Utilization Manipulation**: Because the rate is calculated based on `availableLiquidity`, large atomic withdrawals can spike the interest rate. The $U\_1 \to U\_2$ intermediate slope is specifically designed to mitigate the impact of these "jumps." * **Immutable Parameters**: In the standard deployment, IRM parameters are set at construction. However, the `PoolV3` allows the `CONFIGURATOR` to swap the entire IRM contract via `setInterestRateModel` if market conditions shift significantly.
Sources * [contracts/interfaces/ILinearInterestRateModelV3.sol](https://github.com/Gearbox-protocol/core-v3/blob/main/contracts/interfaces/ILinearInterestRateModelV3.sol) * [contracts/pool/LinearInterestRateModelV3.sol](https://github.com/Gearbox-protocol/core-v3/blob/main/contracts/pool/LinearInterestRateModelV3.sol) * [contracts/pool/PoolV3.sol](https://github.com/Gearbox-protocol/core-v3/blob/main/contracts/pool/PoolV3.sol) * [contracts/compressors/MarketCompressor.sol](https://github.com/Gearbox-protocol/periphery-v3/blob/main/contracts/compressors/MarketCompressor.sol) * [contracts/types/MarketData.sol](https://github.com/Gearbox-protocol/periphery-v3/blob/main/contracts/types/MarketData.sol)