> 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/balance-adapters/cap-stablecoin.md).

# Cap Stablecoin

Reports an account's directly-held cUSD — Cap's synthetic dollar — valued in USDC through cUSD's burn quote.

Reports an account's **directly-held cUSD**, Cap's synthetic dollar, valued in USDC. One leg, one label pair: `["Stablecoin", "cUSD"]` for every position this adapter can emit.

Sibling of [Cap Savings](/funds/infrastructure/onchain-accounting/balance-adapters/cap-savings.md) — same protocol, same taxonomy, same underlying asset, different leg. Both are registered on the NAV Calculator.

* **Type:** Plain adapter
* **protocolSubId:** `keccak256("cap")` — unchanged from the pre-split adapter
* **Underlying asset:** USDC
* **Source:** [`CapStablecoinBalanceAdapter.sol`](https://github.com/karpatkey/onchain-accounting/blob/main/src/balances/BalanceAdapters/cap/CapStablecoinBalanceAdapter.sol) · shared base [`CapBalanceAdapterBase.sol`](https://github.com/karpatkey/onchain-accounting/blob/main/src/balances/BalanceAdapters/cap/CapBalanceAdapterBase.sol)

***

## Positions returned

| Leg  | PositionKind | isDebt  | Description                                           |
| ---- | ------------ | ------- | ----------------------------------------------------- |
| cUSD | `Supplied`   | `false` | Directly-held cUSD, valued in USDC via the burn quote |

***

## Balance calculation

```
amount = ICUsd.getBurnAmount(USDC, cUSD.balanceOf(account)).amountOut
```

A single hop: the burn quote converts held cUSD to its USDC-equivalent. The reported amount is identical to what the pre-split adapter produced for this leg — the split changed the contract layout, not the valuation.

***

## Why Cap is served by two adapters

{% hint style="info" %}
**Why Cap is two adapters rather than one.** A single adapter serving both legs would have to branch its labels on the `positionId` — `["Stablecoin", "cUSD"]` for held cUSD, `["Savings", "stcUSD"]` for staked stcUSD — making index 0 a value that varies per position.

`AssetKindRegistry`'s label overrides are keyed by **adapter**, so one `setAdapterLabels(cap, [...])` would rewrite **both** legs: correcting either would silently corrupt the other, at both indices.

That is not a defect of the override mechanism. A per-adapter table cannot express a per-position value, and giving it one would reintroduce exactly the per-position bookkeeping the design exists to avoid. Splitting the contract keeps each label segment a per-adapter constant, and therefore safely overridable.
{% endhint %}

**What is deliberately not split: the protocol taxonomy.** All three levels stay `ProtocolIds.CAP` on both adapters and `protocolName()` stays `ProtocolNames.CAP`. The taxonomy identifies the *protocol*, and consumers group configured adapters by display name — two names here would manufacture the phantom-sibling split that `protocolName()` exists to prevent.


---

# 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/balance-adapters/cap-stablecoin.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.