> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/funds/infrastructure/onchain-accounting/meta-balance-adapters/gearbox-credit-accounts.md).

# Gearbox Credit Accounts

One immutable meta-adapter that reports the **borrow side** of Gearbox V3 — each Credit Account's collateral basket netted against its debt. The supply side (passive liquidity in the ERC-4626 farming pools) is the separate [Gearbox Markets](/funds/infrastructure/onchain-accounting/meta-balance-adapters/gearbox.md) adapter. Which Credit Accounts it queries is a governed instance set on the NAV Calculator; the adapter holds no per-account state.

* **Type:** Meta-adapter
* **protocolSubId:** `keccak256("gearbox-v3-credit-accounts")` (brand `gearbox`, ecosystem `gearbox-v3`)
* **Instance key:** the **Credit Account address**, widened to `bytes32`
* **Source:** [`GearboxV3CreditAccountsMetaBalanceAdapter.sol`](https://github.com/karpatkey/onchain-accounting/blob/main/src/balances/MetaBalanceAdapters/GearboxV3CreditAccountsMetaBalanceAdapter.sol)

{% hint style="warning" %}
**This page documents the design;** [**Deployment addresses**](/funds/infrastructure/onchain-accounting/deployment-addresses.md) **is the authority on whether it is live.** If this adapter has no entry there, it is not deployed and has no instance set — the contract and its unit tests exist without being wired into the deploy configuration.
{% endhint %}

***

## Why key on the Credit Account

Gearbox exposes only the reverse lookup — `creditAccountInfo(ca).borrower` and `creditAccounts()` (every open account) — with no `borrower → creditAccount` view. So the meta instance is the **Credit Account address**, and each read confirms `creditAccountInfo(ca).borrower == account`. A queried sub-account therefore only ever sees the Credit Accounts it actually owns; a closed or liquidated account reads `borrower == address(0)` and contributes nothing.

***

## Positions returned

Per Credit Account the account owns, one debt leg plus one leg per enabled collateral token:

| Leg        | PositionKind | isDebt  | isLocked | Description                                                                                                              |
| ---------- | ------------ | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------ |
| Borrowed   | `Borrowed`   | `true`  | `false`  | Total owed in the pool's underlying — `debt + accruedInterest + accruedFees` from `calcDebtAndCollateral(ca, DEBT_ONLY)` |
| Collateral | `Collateral` | `false` | `false`  | One leg per enabled token the account holds (`balanceOf(creditAccount)`)                                                 |

NAV nets the collateral basket against the debt into the account's equity contribution. Collateral tokens that are unregistered/unpriced in NAVCalculator (or excluded by `assetFilter`) and zero balances are skipped.

{% hint style="info" %}
**Never over-reports.** The adapter values the debt **first**. If the debt can't be read — **or can't be reported**, because the underlying is unreadable or unregistered on NAVCalculator — it drops the **whole** Credit Account (empty) rather than emit collateral with no offsetting debt, which would overstate equity. Dropping an unregistered collateral token while still counting the full debt likewise only ever **under**-reports. See [Never report collateral without its debt](/funds/infrastructure/onchain-accounting/balance-adapters.md#how-an-adapter-is-built).
{% endhint %}

***

## Balance calculation

<figure><img src="/files/dUScbQ8wg6tkGdj5BQZo" alt="Flowchart of the Gearbox Credit Accounts balance adapter: each cached Credit Account is checked for ownership and a readable debt, then valued into a Borrowed leg plus per-token Collateral legs."><figcaption><p>Gearbox Credit Accounts adapter — how the underlying balances reported to the NAV Calculator are derived.</p></figcaption></figure>

For each cached Credit Account, the adapter resolves its Credit Manager, confirms `borrower == account`, values the debt, then enumerates enabled collateral tokens:

```
cm = ca.creditManager()                              // ICreditAccountV3
(enabledMask, borrower) = cm.creditAccountInfo(ca)
require borrower == account                          // else: empty

(debtOk, debt) = cm.calcDebtAndCollateral(ca, DEBT_ONLY)
if !debtOk: return []                                // whole-account drop (no over-report)

for each enabled token (set bit of enabledMask):
    bal = token.balanceOf(ca)                        // → Collateral leg (if registered & > 0)
if debt > 0:
    → Borrowed leg in cm.underlying()
```

Collateral is valued at instantaneous on-chain token balances priced by NAVCalculator; the debt is the total owed in the pool's underlying.

***

## Identity

* **positionId:** `abi.encode(address creditAccount)` — all legs of one Credit Account (the Borrowed leg and every Collateral leg) share this anchor and are told apart by `positionKind` + `balanceAsset.asset`.
* **positionInstanceId:** `bytes32(0)` — the Credit Account address is a stable anchor, so its identity lives in `positionId`; there is no separate ephemeral handle.
* **positionKind:** `Borrowed` · `Collateral`
* **labels:** there is no `labels` field on the position. The adapter implements `positionLabels(positionId)`, which returns `["Credit Account", "<credit-manager name()>"]` — falling back to the pool's underlying asset symbol (e.g. `"USDC"`) when the credit manager's `name()` is missing or empty. Surfaced only by the verbose reads; the full breadcrumb is `[protocolName, ...labels]`.

***

## Constructor

```solidity
constructor(address navCalculator_)
```

| Parameter        | Description                                             |
| ---------------- | ------------------------------------------------------- |
| `navCalculator_` | NAV Calculator contract (asset registry + instance set) |

***

## Registration

Meta-adapter. Register once and seed its Credit Accounts with `addMetaBalanceAdapter(adapter, instances)`, then adjust with `addMetaInstances(adapter, instances)` / `removeMetaInstances(adapter, instances)` (MANAGER-gated). Each instance coordinate is a **Credit Account address widened to `bytes32`** (decoded via `_toAddress`). A malformed coordinate is isolated per-instance by the fan-out.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kpk.io/funds/infrastructure/onchain-accounting/meta-balance-adapters/gearbox-credit-accounts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.