# The Lending Stack

> Markdown export of the Gearbox Protocol documentation page for agents and retrieval systems.

Canonical page: https://docs.gearbox.finance/developers/intro-101
Source file: content/developers/intro-101.mdx
Section router: https://docs.gearbox.finance/developers/llms.txt
Section full export: https://docs.gearbox.finance/developers/llms-full.txt

Every product built on Gearbox — leveraged farming, margin trading, RWA settlement, structured credit — starts from the same primitive: the **Credit Account**.

## Credit Account: The Primitive

A Credit Account is an isolated smart contract wallet that holds both a user's collateral and borrowed funds in one place. Unlike traditional lending protocols where collateral sits in a shared vault, each Gearbox position is a separate contract with its own state.

```mermaid
flowchart LR
    subgraph "Traditional Lending"
        User1[User A] --> Vault[Shared Vault]
        User2[User B] --> Vault
        User3[User C] --> Vault
    end

    subgraph "Gearbox"
        UserA[User A] --> CA1[Credit Account A]
        UserB[User B] --> CA2[Credit Account B]
        UserC[User C] --> CA3[Credit Account C]
    end
```

This isolation is what makes everything else possible:

- **Programmable leverage** — the Credit Account can interact with any whitelisted DeFi protocol (Uniswap, Curve, Lido, Aave) as if it were a regular wallet. Borrowed funds never leave the account — they're deployed *inside* it.
- **Check-on-exit** — the protocol doesn't restrict what you do within a transaction. It only checks that the account is solvent at the end. This enables complex multi-step strategies (borrow → swap → farm → rebalance) in a single atomic transaction.
- **Composability** — external protocols see the Credit Account as a standard EOA-like contract. No special integrations needed from their side.

## Leverage with Delayed Deposits

The Credit Account primitive uniquely solves a problem that traditional lending protocols cannot: **leverage on assets with non-atomic settlement**.

### The Looping Problem

Many assets — tokenized securities (ACRED), staked positions, RWA deposits — have settlement delays. A deposit of USDC into ACRED might take 2 days to mint.

On traditional platforms (Morpho, Aave), building a 10x leveraged position with such a token requires **looping**: deposit collateral → wait 2 days → use the minted token as collateral → borrow more → deposit again → wait 2 more days → repeat. Getting to 10x leverage takes weeks.

### Phantom Tokens: Instant Leverage

Gearbox solves this with **phantom tokens** — on-chain representations of pending positions that act as collateral *during* the settlement period.

```mermaid
flowchart LR
    subgraph "Traditional (Looping)"
        T1["Deposit $100"] -->|"wait 2 days"| T2["Get Token"]
        T2 -->|"use as collateral"| T3["Borrow $85"]
        T3 -->|"deposit again"| T4["wait 2 days..."]
        T4 -->|"repeat 8x"| T5["~3 weeks for 10x"]
    end

    subgraph "Gearbox (Instant)"
        G1["Deposit $100 + Borrow $900"] -->|"same tx"| G2["Send $1000 to mint"]
        G2 --> G3["Receive phantom token"]
        G3 --> G4["10x leverage, Day 0"]
    end
```

How it works:

1. User opens a Credit Account, deposits \$100 collateral, borrows \$900
2. The Credit Account sends \$1,000 to the issuer's deposit contract
3. While the deposit is pending (2 days), the Credit Account receives a **phantom token** — a futures-like representation of the position
4. The phantom token is accepted as collateral by the Credit Manager (configured by the curator), keeping the account solvent
5. When the deposit matures, the phantom token is replaced by the real asset

The user gets 10x leverage **on day zero**, not after weeks of looping. The curator configures the phantom token's liquidation threshold to reflect settlement risk.

This is why the Credit Account is the right primitive for RWAs and delayed deposits — it holds the entire position (collateral + debt + pending assets) in one isolated contract, making the settlement state visible and manageable at the protocol level.

## The Lending Stack

Capital flows through three layers: from liquidity source, through a Credit Manager, into Credit Accounts that interact with DeFi.

```mermaid
flowchart LR
    subgraph "Liquidity Source"
        Markets["Gearbox Markets\n(Pooled)"]
        Intent["Intent-Based\n(P2P)"]
    end

    subgraph "Credit Manager"
        CM["Credit Manager\n(Policy Keeper)"]
    end

    subgraph "Credit Accounts"
        CA1["Credit Account"]
        CA2["Credit Account"]
        CA3["Credit Account"]
    end

    subgraph "DeFi Protocols"
        Uniswap["Uniswap"]
        Curve["Curve"]
        Lido["Lido"]
        Aave["Aave"]
    end

    Markets -->|"lend"| CM
    Intent -->|"lend"| CM

    CM --> CA1
    CM --> CA2
    CM --> CA3

    CA1 -->|"via Adapters"| Uniswap
    CA2 -->|"via Adapters"| Curve
    CA2 -->|"via Adapters"| Lido
    CA3 -->|"via Adapters"| Aave
```

### Layer 1: Liquidity Source

Where the capital comes from. Two models, same Credit Account primitive underneath:

- **[Gearbox Markets](https://docs.gearbox.finance/developers/gm-overview)** (pooled) — many lenders deposit into a shared Pool. Dynamic rates based on utilization. Quotas limit per-token exposure.
- **Intent-Based** (P2P) — one lender matches one borrower directly. Fixed or reference-based rates (LIBOR + 2%). Custom terms per deal.

### Layer 2: Credit Manager

The **policy keeper**. Each Credit Manager defines the rules: which collateral tokens are accepted, which DeFi protocols can be used, what leverage is allowed. The Credit Manager borrows from the liquidity source and allocates to Credit Accounts.

### Layer 3: Credit Accounts → DeFi

The **execution layer**. Each Credit Account is an isolated contract holding collateral + borrowed funds. Through **Adapters**, it interacts with external DeFi protocols — swap on Uniswap, stake on Lido, deposit on Curve. **Multicalls** batch all operations into a single atomic transaction with a solvency check at the end.

## Zoom Into the Credit Account

The Credit Account is the foundation of the entire stack. Everything — markets, P2P lending, leveraged farming, RWA settlement — is built by composing operations on top of this single primitive. Here's what makes it work.

### Multi-Collateral Solvency

A Credit Account can hold **many tokens simultaneously** — WETH, USDC, stETH, CRV LP tokens, phantom tokens. The Credit Manager iterates over all of them to compute the account's value:

For each token in the account:
1. Get the **price** from a dual oracle — `min(main feed, reserve feed)` — protection against manipulation
2. Apply the **Liquidation Threshold** — e.g., WETH at 90% means \$100 of ETH counts as \$90
3. Cap the contribution by the token's **Quota** — concentration limit per token
4. Sum into the **Total Weighted Value (TWV)**

Then:

```
Health Factor = TWV / Total Debt

where Total Debt = principal + accrued interest + quota fees
```

If **HF >= 1** → account is solvent. If **HF < 1** → account is liquidatable.

### Check-on-Exit: The Execution Model

The Credit Account doesn't check solvency on every operation — only at the end of a multicall. This is the **check-on-exit** model:

> **Example: building a leveraged stETH position**
>
> 1. `addCollateral` — deposit \$100 USDC
> 2. `increaseDebt` — borrow \$900 USDC from Pool
> 3. `swap` (via Uniswap adapter) — swap \$1,000 USDC → WETH
> 4. `stake` (via Lido adapter) — stake WETH → stETH
> 5. `deposit` (via Curve adapter) — deposit stETH into Curve pool
> 6. **Final check: HF >= 1?** → Yes: TX succeeds. No: entire TX reverts.

Between steps 2 and 5, the account is temporarily insolvent — it has \$900 debt but collateral is mid-transformation. This is fine because all operations are **atomic**: if the final check fails, everything reverts as if nothing happened. No bad debt can ever be created.

### The Building Block

This is why every product on Gearbox reduces to the same primitive:

| Product | What Happens Inside the Credit Account |
| --- | --- |
| Leveraged Farming | Borrow → swap → deposit into yield vault |
| Margin Trading | Borrow → swap to long/short asset |
| RWA Settlement | Borrow → deposit with issuer → hold phantom token |
| Structured Credit | P2P terms → borrow → deploy into strategy |

The Credit Manager defines *which* operations and tokens are allowed. The Credit Account executes them. The solvency check enforces safety. Everything else — pools, quotas, insurance, oracles — exists to support this core loop.

## Deep Dive

- [**Credit Accounts**](https://docs.gearbox.finance/developers/gm-concept-accounts) — The Credit Suite architecture (Manager, Facade, Configurator), account lifecycle, and configuration parameters
- [**Multicall System**](https://docs.gearbox.finance/developers/gm-concept-multicalls) — All available operations, the diff pattern, safety controls, and bot permissions
- [**Health Factor & Risk**](https://docs.gearbox.finance/developers/gm-concept-risk) — TWV formula, Liquidation Thresholds, Quotas, Dual Oracle, Loss Policy, and liquidation mechanics

## What's Next

- [**Gearbox Markets**](https://docs.gearbox.finance/developers/gm-overview) — The pooled lending product built on top of this stack
- [**Start building**](https://docs.gearbox.finance/developers/gm-start-ts) — Install the SDK and make your first call