> 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/morpho-market.md).
# Morpho Markets
One immutable meta-adapter that reports an account's positions on any Morpho market: collateral, loan supply, and loan borrow.
One immutable meta-adapter that reports an account's positions on *any* Morpho market: collateral, loan supply, and loan borrow. Which markets it queries is a governed instance set on the NAV Calculator; the adapter itself holds no per-market state.
* **Type:** Meta-adapter
* **protocolSubId:** `keccak256("morpho-markets")`
* **Instance key:** the Morpho **marketId** (`bytes32`), used directly; not an address
* **Source:** `MorphoMarketsMetaBalanceAdapter.sol`
## Positions returned
Up to three legs per market, each emitted only when its amount is `> 0`:
| Leg | PositionKind | isDebt | Description |
| ----------- | ------------ | ------- | ------------------------------------------ |
| Collateral | `Collateral` | `false` | Posted collateral, in the collateral token |
| Loan supply | `Supplied` | `false` | Supplied loan token (credit) |
| Loan borrow | `Borrowed` | `true` | Borrowed loan token (debt) |
The market's collateral and loan tokens come from `MORPHO.idToMarketParams(marketId)`. A **credit** leg is skipped if its asset is unregistered in NAVCalculator or excluded by `assetFilter`. If the account has **borrowed** and the loan token is unregistered, the market reports **nothing at all**, collateral included, rather than emitting collateral without its offsetting debt, which would over-report NAV. See [Never report collateral without its debt](/funds/infrastructure/architecture/onchain-accounting/balance-adapters.md#how-an-adapter-is-built).
## Balance calculation
Morpho Markets adapter: how the underlying balances reported to the NAV Calculator are derived.
Collateral is read raw from the account position:
```
collateral = MORPHO.position(marketId, account).collateral
```
Loan legs use Morpho's `expectedMarketBalances` (interest accrued to the current block), then pro-rate by shares:
```
(totalSupplyAssets, totalSupplyShares, totalBorrowAssets, totalBorrowShares) = MORPHO.expectedMarketBalances(mp)
supplied = totalSupplyAssets.mulDiv(pos.supplyShares, totalSupplyShares, Floor) // rounds down — avoid overstating credit
borrowed = totalBorrowAssets.mulDiv(pos.borrowShares, totalBorrowShares, Ceil) // rounds up — avoid understating debt
```
Each is guarded by non-zero total shares and non-zero account shares.
## Identity
* **positionId:** `abi.encode(bytes32 marketId)`, the raw marketId (all three legs of a market share it)
* **positionKind:** `Collateral` · `Supplied` · `Borrowed`
There is no `labels` field on the position. The adapter implements `positionLabels(positionId)`, which returns `["Market", "/"]` from the market's onchain token symbols; surfaced only by the verbose reads (`getAccountPositionsVerbose` / `getAccountNavVerbose`); the full breadcrumb is `[protocolName, ...labels]`.
For a marketId with **no market on this chain** the leaf is dropped, giving the bare `["Market"]` category. This matters because Morpho's params getter is a plain mapping read: an unknown id returns an all-zero struct rather than reverting, both symbol reads would then fail open to `"?"`, and the adapter would answer `["Market", "?/?"]`, a confident breadcrumb byte-identical to a real market whose tokens both have unreadable symbols. Existence is checked against the invariant Morpho itself enforces at market creation, rather than inferred from the params: a market with no loan token is creatable, and an idle market legitimately has no collateral token, so neither is a property the protocol guarantees.
## Constructor
```solidity
constructor(address morpho_, address navCalculator_)
```
| Parameter | Description |
| ---------------- | ------------------------------------------------------- |
| `morpho_` | Morpho singleton contract (must be a contract) |
| `navCalculator_` | NAV Calculator contract (asset registry + instance set) |
## Registration
Meta-adapter. Register once and seed its markets with `addMetaBalanceAdapter(adapter, instances)`, then adjust with `addMetaInstances(adapter, instances)` / `removeMetaInstances(adapter, instances)` (MANAGER-gated). Each instance coordinate is a **raw `bytes32` marketId** (not an address widened to bytes32). Adding a new market is a config call, no new deploy. A malformed coordinate is isolated per-instance by the adapter's 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/morpho-market.md?ask=&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.
