> 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/architecture/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, …).

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 onchain 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`

## 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/architecture/onchain-accounting/balance-adapters.md#how-an-adapter-is-built).

## Balance calculation

<figure><picture><source srcset="/files/iPBQRFdWrnMB7L0iqwzj" media="(prefers-color-scheme: dark)"><img src="https://1699303810-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUsQM4bzcmOPSgkWddkeN%2Fuploads%2FuAyhbUvP87udZDrYVHM9%2Fmeta-aave-v3.png?alt=media&amp;token=1c384c60-2dde-4e8a-9ccc-d56c72f317fe" alt="Flowchart of the Aave V3 balance adapter: read calls derive position legs into PositionBalance entries."></picture><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 onchain market id, e.g. distinguishing Aave Core from Aave Lido); surfaced only by the verbose reads.
* **shape enumeration:** [`positionIds()`](/funds/infrastructure/architecture/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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kpk.io/funds/infrastructure/architecture/onchain-accounting/meta-balance-adapters/aave-v3.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.