> 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/aave-v3.md).

# Aave V3

One immutable meta-adapter that reports an account's lending positions across *any* Aave V3 instance (Core, Prime, an L2 market, …). Each governed instance is identified by the instance's **ProtocolDataProvider** address; within an instance, reserves are enumerated trustlessly via `getAllReservesTokens()`. Emits up to two legs per reserve (Supply/Collateral + Borrow).

* **Type:** Meta-adapter
* **protocolSubId:** `keccak256("aave-v3-lending")` (brand `aave`, ecosystem `aave-v3`)
* **Instance key:** the instance's ProtocolDataProvider address, widened to `bytes32`
* **Source:** [`AaveV3InstancesMetaBalanceAdapter.sol`](https://github.com/karpatkey/onchain-accounting/blob/main/src/balances/MetaBalanceAdapters/AaveV3InstancesMetaBalanceAdapter.sol)

***

## Positions returned

Up to two legs per registered reserve, per instance (one supply-side leg + one borrow leg):

| Leg        | PositionKind | isDebt  | isLocked | Description                                                                                         |
| ---------- | ------------ | ------- | -------- | --------------------------------------------------------------------------------------------------- |
| Supply     | `Supplied`   | `false` | `false`  | aToken balance when `usageAsCollateralEnabled == false`                                             |
| Collateral | `Collateral` | `false` | `false`  | aToken balance when `usageAsCollateralEnabled == true`                                              |
| Borrow     | `Borrowed`   | `true`  | `false`  | Variable + stable debt, summed — one Borrowed leg per reserve, emitted only when the total is `> 0` |

Reserves not registered on NAVCalculator are skipped; `assetFilter` is respected. But if the account **borrows** a reserve whose asset is unregistered, the instance reports **nothing at all** — every supply and collateral leg included — rather than emitting credit legs with no offsetting debt, which would over-report NAV. Which reserves the account actually borrows is read from Aave's user-configuration bitmap (`getUserConfiguration`), so only those are checked against the registry rather than scanning every reserve on each read; if the bitmap is unavailable the adapter falls back to a full scan. See [Never report collateral without its debt](/funds/infrastructure/onchain-accounting/balance-adapters.md#how-an-adapter-is-built).

***

## Balance calculation

<figure><img src="/files/m7kTPNxlIkPi0lyXCkc1" alt="Flowchart of the Aave V3 balance adapter: read calls derive position legs into PositionBalance entries."><figcaption><p>Aave V3 adapter — how the underlying balances reported to the NAV Calculator are derived.</p></figcaption></figure>

Per instance, the ProtocolDataProvider (`_toAddress(instance)`) is queried. For each reserve from `getAllReservesTokens()`:

```
(aTokenBalance, stableDebt, variableDebt, …, usageAsCollateral) = dp.getUserReserveData(asset, account)

supply leg:   amount = aTokenBalance              kind = usageAsCollateral ? Collateral : Supplied
borrow leg:   amount = variableDebt + stableDebt  isDebt = true, kind = Borrowed   (if > 0)
```

Variable and stable debt are summed into a single `Borrowed` leg per reserve. Emitting them as two legs would collide on the identity key — both would share the same `(chainId, protocolSubId, positionId, balanceAsset.asset, positionKind)` tuple. Aave has deprecated new stable borrows, but legacy stable debt can still persist, so the adapter folds whatever stable debt remains into the variable amount.

The instance Pool address (used in `positionId`) is resolved via `dp.ADDRESSES_PROVIDER().getPool()`.

***

## Identity

* **positionId:** `abi.encode(address pool)` — one position per instance Pool; the reserve each leg refers to is carried in `balanceAsset`, not the `positionId`
* **positionKind:** `Supplied` · `Collateral` · `Borrowed`
* **labels:** there is no `labels` field on the position. The adapter implements `positionLabels(positionId)`, which returns `["Market", "<market id>"]` (the instance's on-chain market id, e.g. distinguishing Aave Core from Aave Lido) — surfaced only by the verbose reads.
* **shape enumeration:** [`positionIds()`](/funds/infrastructure/onchain-accounting/concepts/position-identity.md#enumerating-position-shapes) advertises the **Pool** for each configured instance — the id the legs actually emit — not the `ProtocolDataProvider` coordinate. The two differ only here, and getting it wrong would be invisible to a label check: `positionLabels` returns the same `["Market", …]` for either address, so only a byte-exact join against real positions catches the mismatch. `_instancePositions` resolves the Pool back out of the same hook, so the emitted and advertised ids cannot drift apart.

***

## Constructor

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

| Parameter        | Description                                                                               |
| ---------------- | ----------------------------------------------------------------------------------------- |
| `navCalculator_` | NAVCalculator address (must be a contract); source of the instance set and asset registry |

***

## Registration

Registered with `addMetaBalanceAdapter(adapter, instances)` (register + seed); instances adjusted with `addMetaInstances` / `removeMetaInstances`. Each instance coordinate is a ProtocolDataProvider address widened to `bytes32`. One contract covers every Aave V3 market — adding a market is an `addMetaInstances` call, not a new deploy. 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/aave-v3.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.