Lenders deposit funds into Gearbox and receive interest payments from borrowers.

Gearbox is a non-custodial lending protocol built on Ethereum. Gearbox was founded by Mikhail Lazarev and launched in 2021.

GEAR tokenholders own and govern the protocol. They currently take a cut of the total interest paid by borrowers (revenue).

governance

github

twitter

discord

etherscan

website

Lending

Gearbox

# Gearbox Active users (daily) Methodology

## 1. Overview

Active users (daily) is defined as the number of unique addresses that make a revenue-generating or capital-allocating transaction with Gearbox. These transactions are executed by depositors, withdrawers, borrowers, and repayers interacting with the protocol's lending pools and credit accounts. By analyzing active users (daily), the overall adoption, user engagement, and transactional activity of Gearbox V1 and Gearbox V3 are evaluated. Activity from Gearbox V2 credit accounts is reported under Gearbox V1, as these accounts borrow directly from Gearbox V1 pools.

## 2. Data sources

- **Blockchain events**: `AddLiquidity`, `RemoveLiquidity`, `Borrow`, and `Repay` events from `Pool` contracts; `Deposit`, `Withdraw`, `Borrow`, and `Repay` events from `PoolV3` contracts; `OpenCreditAccount` and `CloseCreditAccount` events from `CreditFacadeV3` contracts; `OpenCreditAccount` events from `CreditManager` and `CreditFacade` contracts; and ERC-20 token transfers, covering Ethereum, Monad, and Plasma.

## 3. Step-by-step calculation

### Component A: Gearbox V1 and Gearbox V3 credit account ownership mapping

- **Purpose**: Map credit accounts to the specific user addresses that opened them over time.
- **Logic**: `OpenCreditAccount` events are parsed from `CreditManager`, `CreditFacade`, and `CreditFacadeV3` contracts. The user address and credit account address are extracted. Because credit accounts can be reused by different owners over time, validity windows are established for each owner, starting at the block timestamp of opening and ending at the timestamp of the next opening of the same account.
- **Key fields**: `block_timestamp`, `user_address`, `creditAccount`

### Component B: Gearbox V1 and Gearbox V3 depositor and withdrawer tracking

- **Purpose**: Identify users who supply or withdraw liquidity from the lending pools.
- **Logic**: For Gearbox V1, `AddLiquidity` and `RemoveLiquidity` events are parsed from `Pool` contracts to extract the sender address. For Gearbox V3, `Deposit` and `Withdraw` events are parsed from `PoolV3` contracts to extract the owner and receiver addresses, respectively. These addresses are classified as depositors and withdrawers.
- **Key fields**: `block_timestamp`, `transaction_hash`, `user_address`

### Component C: Gearbox V1 and Gearbox V3 borrower tracking

- **Purpose**: Identify users who borrow assets from the lending pools.
- **Logic**: `Borrow` events are parsed from `Pool` and `PoolV3` contracts. The credit account address is extracted and matched against the credit account ownership mapping established in Component A. The borrow event timestamp is required to fall within the active validity window of the mapped owner to identify the correct borrower address.
- **Key fields**: `block_timestamp`, `transaction_hash`, `credit_account`, `user_address`

### Component D: Gearbox V1 and Gearbox V3 repayer tracking

- **Purpose**: Identify users who repay borrowed assets to the lending pools.
- **Logic**: `Repay` events are parsed from `Pool` and `PoolV3` contracts. To recover the credit account associated with the repayment, these events are joined with ERC-20 token transfers where the transfer recipient matches the pool address within the same transaction. The sending address of the transfer is then matched against the credit account ownership mapping established in Component A within the active validity window to identify the repayer address.
- **Key fields**: `block_timestamp`, `transaction_hash`, `credit_account`, `user_address`

### Component E: Gearbox V3 credit account lifecycle tracking

- **Purpose**: Capture users opening or closing credit accounts directly.
- **Logic**: `OpenCreditAccount` and `CloseCreditAccount` events are parsed from `CreditFacadeV3` contracts. The user addresses are extracted and classified as borrowers.
- **Key fields**: `block_timestamp`, `transaction_hash`, `user_address`

### Component F: Daily active user aggregation

- **Purpose**: Aggregate all unique active addresses into daily counts.
- **Logic**: All identified user addresses from depositors, withdrawers, borrowers, and repayers are combined. The distinct count of unique user addresses is calculated over a fixed 24-hour window, partitioned by day, chain, and product. Daily boundaries are defined using UTC timestamps.
- **Key fields**: `block_timestamp`, `user_address`, `chain`, `product_id`

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Unique revenue-generating users over a fixed 24-hour window.

GearboxGEAR

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown