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 — 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 · shared base 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

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.

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.