cUSD’s design choice: a PSM-backed dollar that routes yield through stcUSD

Cap’s core bet is that a stablecoin can stay boring at the token level while still paying competitive yield through a separate receipt token. cUSD (tracked as CUSD on CoinGecko) is positioned as the “digital dollar” layer, with minting and redemption mechanics designed like a Peg Stability Module (PSM).

Yield is not embedded into cUSD’s balance. It’s pulled into stcUSD, which users mint by staking cUSD. stcUSD is where the protocol concentrates the “yield-bearing stablecoin” behavior, and it does so via operator borrowing and a liquidation and slashing framework intended to keep cUSD 1:1 backed through stress, as described in the stcUSD mechanics.

That separation matters under a regulatory lens. A plain stablecoin with clear redemption rights tends to be easier to explain and integrate. A yield-bearing token, even if technically just a staking wrapper, raises harder questions around who is paying the yield, what risks sit underneath, and whether the wrapper starts to resemble an investment product.

Cap went live on Ethereum mainnet on August 18, 2025, and opened cUSD minting to the public at that time.

Supply: elastic issuance, no emissions, and the separate CAP governance token

cUSD supply is demand-driven. It mints when users deposit whitelisted reserve assets and burns when users redeem. There is no fixed max supply baked into the concept. For comparison, our Avant USD review walks through a different stablecoin tokenomics setup.

On Ethereum mainnet, Cap publishes cUSD’s contract address as 0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC.

Because live supply moves, any snapshot should be treated as informational, not a parameter.

Cap also documents a separate “Cap Tokens” section that describes a governance token allocation framework. This is not cUSD. Still, it matters for cUSD tokenomics because it implies there may be a governance and value capture layer that can change cUSD/stcUSD parameters over time. The doc explicitly lists governance scope as “parameters, collateral management, operator onboarding, protocol fees.”

Documented allocation targets for the Cap governance token are:

There are two immediate analytic consequences.

First, cUSD and stcUSD are not “the governance token.” They look more like product tokens with redemption and yield mechanics. That can reduce expectation-of-profit signaling at the cUSD layer, which is useful. Second, the existence of a separate governance token that can steer protocol fees and onboarding increases regulatory and operational surface area. It also lowers parameter stability unless governance is credibly constrained by timelocks, disclosure, and predictable change processes.

Mint, burn, redeem: peg management and depeg loss socialization

Cap describes cUSD as a PSM-like stablecoin. Users can interact via three operations-mint, burn, and redeem-outlined in the PSM-like operations.

The reserve basket is documented as “blue chip stablecoins” and tokenized money market fund assets. Cap’s docs and public roadmap explicitly name USDC, USDT, pyUSD, BUIDL, and BENJI as examples of reserve assets.

The protocol leans into a specific depeg philosophy. If one backing asset depegs, a naive “burn into the best asset” path creates a last-man-standing problem. Cap’s “redeem” function instead outputs a proportional basket based on current weights and prices, which intentionally socializes depeg losses across redeemers and reduces incentives to race.

Fees are not cosmetic here. They are one of the protocol’s main levers for shaping reserve composition and discouraging toxic flows during stress.

The Vault module mints and burns cUSD roughly 1:1 for supported backing assets, with fees that are dynamically calculated based on each asset’s allocation ratio.

The Minter contract implements those dynamic mint and burn fees through a piecewise model with an optimal ratio and kink points. It also documents a minimum mint fee. The current minimum mint fee is described as 10 bps, capped to 5% maximum.

Redeems use a percentage-based fee model, and the docs state that whitelisted users pay 0% redeem fee. The global redeem fee itself is an admin-set parameter.

Two operational constraints are easy to miss but structurally important.

First, mint and burn functions are disabled if oracle prices are stale, until the oracles are back in sync. That protects solvency but can strand liquidity at the worst moment.

Second, Cap explicitly supports whitelisted minters that can bypass fees for privileged users. That may be defensible for institutional flow or market-making, but it does create an unequal playing field around peg rebalancing and can become contentious if not transparently governed.

Yield and cash flows: stcUSD, operator borrowing, and who gets paid

Cap frames yield generation as a credit engine. Operators borrow from cUSD reserves, run strategies, and repay principal plus interest. Restakers (delegators) post collateral via shared security networks to underwrite operator positions. Liquidators enforce solvency by slashing collateral when health factors breach thresholds.

That’s the mechanism. The cash flow map is the tokenomics question.

Per Cap’s stcUSD mechanics doc, the idea is that stcUSD holders receive yield up to a hurdle rate. Restakers earn a negotiated fixed rate for underwriting. Operators keep the surplus above those two costs if they perform. If you want a point of comparison for yield-first stablecoin design, see our Resolv USR analysis.

Cap’s docs are explicit that idle reserve assets can be deployed into “fractional reserve” strategies, including integrations with crypto lending markets like Aave, when assets are not actively borrowed.

In November 2025, Cap announced that WisdomTree’s tokenized government money market fund WTGXX joined the Cap Stablecoin Network as an approved collateral asset, with RedStone acting as the oracle for the reserve asset.

From a regulatory pragmatist view, this is the line you watch. The more the reserve basket leans into regulated tokenized funds, the more Cap inherits their constraints. Permissioning, transfer restrictions, investor eligibility, and redemption gates can all bleed into “how stable is the stablecoin” during stress. Cap itself acknowledges whitelisting and segregation behavior in practice for institutional integrations.

On the credit side, the Lender module documents key parameters that shape both safety and realized yield.

Borrowing is overcollateralized against delegated collateral. The Lender doc defines initial LTV as the maximum borrow relative to total slashable collateral and gives a concrete example: 50% LTV implies delegations must be at least 2x the size of the borrow.

Default liquidation settings are also stated in the docs: liquidation threshold is set to 80% by default, grace period is 12 hours, expiry period is 3 days, target health is 125%, and liquidation bonus cap is 10%.

Interest is explicitly split into two streams: “Vault Interest” paid to the vault (which the doc associates with stcUSD holders) and “Restaker Interest” paid to delegators who provide collateral coverage.

The interest rate model is additive, and the interest rate model describes how operators pay a minimum rate plus utilization and restaker components.

The utilization component is kinked. The docs state a target utilization (“kink”) of 90%, after which rates increase rapidly, to preserve withdrawal liquidity.

Net-net, stcUSD yield is not “free yield.” It is the product of (1) base yield from idle reserve deployment and (2) spread earned from operators paying above that base yield, minus (3) whatever restakers negotiate and (4) any protocol-level fees that accrue to a treasury for safety.

This is also where the model’s regulatory tension concentrates. Yield is being “generated” through lending and private-credit-like activity, and stcUSD is the on-chain claim on that yield stream. Even if the engineering is clean, the compliance interpretation can shift quickly depending on jurisdictions, distribution channels, and marketing.

Governance and control: multisig-admin, timelock, and whitelists

Cap’s governance reality today reads closer to “administered protocol with strong controls” than to a DAO.

The docs describe a granular, function-level access control system. Roles are managed by an access control admin that is “currently set to Cap’s multisig address,” as described in the access control roles.

Cap also publishes a Timelock contract address on Ethereum mainnet. 0xD8236031d8279d82E615aF2BFab5FC0127A329ab.

Upgradeability and admin power are not abstract risks here. CoinGecko explicitly flags CUSD as a proxy contract and warns that the contract owner can change code, mint, transfer, change fees, or disable selling. Whether or not those actions are likely, the control surface exists.

Whitelisting is part of Cap’s current trust envelope. The Delegation module states Cap will initially whitelist delegators and operators “to prevent malicious actors from attacking the protocol.”

It also documents that Cap supports multiple shared security networks and names current integrations as Symbiotic and EigenLayer.

One design decision I like from a risk containment standpoint is isolation. Cap’s delegation coverage is described as isolated at the network and operator level, and the docs state that a delegator’s stake can only be used for a single operator in Cap.

That reduces cross-contagion. It also increases operational friction. It pushes delegators toward more deliberate underwriting choices, which is arguably aligned with Cap’s “financial guarantee market” framing. But it is still a market in which the protocol’s admin can whitelist, set LTVs, and modify liquidation thresholds.

Finally, be clear-eyed about governance optics. If a separate CAP token is used to govern “operator onboarding” and “protocol fees,” then tokenholders are participating in decisions that look a lot like credit policy and product pricing. That can be valuable. It can also raise the compliance bar, especially if token distribution is concentrated or if tokenholders are perceived as directing an enterprise for profit.

Risk analysis: where the model strains under real regulation

Cap’s risk disclosures enumerate smart contract risk, counterparty risk (including SSN platform risk), reserve collateral depeg and freeze risk, oracle and bridge risk, and liquidation and slashing dynamics.

The right way to evaluate cUSD tokenomics is to treat “yield” as a liability that must be serviced under constraints. Those constraints are on-chain (oracles, liquidation mechanics, utilization) and off-chain (asset issuer actions, legal agreements, and regulatory posture).

Top 3 risks

  1. Trigger: a regulator or major distribution partner treats stcUSD (or the yield program around it) as a regulated yield product; Mechanism: forced geo-blocking, KYC expansion, delisting, or restrictions on “yield-bearing stablecoin” distribution reduce demand and can fragment liquidity between cUSD and stcUSD; Who bears it: stcUSD holders first (reduced yield access and liquidity), then cUSD holders via secondary market peg pressure; Measurable indicators: sudden changes to access policy in official terms, new mandatory whitelists for staking, exchange/aggregator delistings, and sustained discount on CUSD pairs relative to redemption parity.
  2. Trigger: smart contract exploit or an admin key event in upgradeable components; Mechanism: proxy upgrades or privileged function calls change fees, pause redemptions, or create unexpected mint/burn behavior, leading to bank-run dynamics; Who bears it: cUSD holders (redemption uncertainty) and stcUSD holders (yield claims and liquidity), with restakers only partially offsetting if losses bypass liquidation paths; Measurable indicators: contract upgrade events, emergency pause usage, and persistent divergence between on-chain oracle price and secondary market price.
  3. Trigger: reserve asset impairment (depeg, freeze, seizure) or SSN platform stress that disrupts collateral value and liquidation execution; Mechanism: cUSD redeem socializes backing-asset losses across redeemers, while operator-side liquidations rely on oracles and liquidation windows to convert collateral into reserve assets fast enough; Who bears it: cUSD holders through basket-level impairment, restakers through slashing, and stcUSD holders through reduced effective yield and liquidity under stress; Measurable indicators: backing asset price deviations, asset-level pauses, elevated utilization approaching the 90% kink, and increased liquidations/slashing frequency.

Dominant risk: regulatory classification and distribution constraints around yield and guarantees.

Cap’s most distinctive feature is also the one that is hardest to keep in a clean compliance bucket. cUSD is framed as a redeemable stablecoin backed by regulated stablecoins and tokenized money market fund assets. It is designed with a PSM-like mint/burn/redeem interface. That part is relatively legible.

The strain shows up when you follow the yield path end-to-end.

stcUSD is explicitly the yield-bearing token, issued by staking cUSD, with yield generated by an operator layer that borrows reserves and pays interest. Restakers underwrite operator positions and receive a fixed rate. That starts to look like a structured product stack: depositors (stcUSD holders) receive a yield stream that depends on credit performance, underwriting, and liquidation mechanics. Even if tokenholders are “protected” through slashing, the product still has economic risk and a non-trivial set of managerial and technical dependencies.

From a regulatory pragmatist view, the danger is not that this is “bad design.” The danger is that distribution constraints can arrive faster than the protocol can decentralize control or re-architect product packaging.

Three mechanics increase that exposure.

First, stcUSD is an explicit yield wrapper. You can argue it’s just “staking,” but the yield source is lending and credit spreads. That is a familiar regulatory trigger in many jurisdictions, regardless of whether claims are enforced by code.

Second, whitelisting and multisig control can cut both ways. Operationally, they are safety tools. Legally, they can be read as centralized control and discretionary gatekeeping, which may pull the system toward an issuer/operator profile rather than a neutral protocol.

Third, the reserve basket includes assets issued by regulated entities and tokenized MMFs. Those instruments come with their own transfer restrictions, investor eligibility constraints, and compliance expectations. Cap’s own institutional collateral integrations explicitly discuss segregation and compliant paths.

In practice, the dominant-risk question becomes simple. Can Cap keep cUSD widely usable and liquid if stcUSD faces distribution friction, or if underwriter/operator participation gets narrowed by compliance requirements? If yes, the system can degrade gracefully. If no, cUSD can inherit stcUSD’s constraints through demand shocks and liquidity fragmentation.

If you are building around cUSD, treat parameter stability and access policy as first-class dependencies. Watch the timelock, the whitelist perimeter, and how quickly risk and compliance disclosures evolve relative to product expansion.

If you need a sharper external review of these mechanics for an integration or a treasury policy, this is the sort of system where tokenomics consulting pays for itself. The hard part is not modeling a yield curve. It’s modeling governance control, compliance constraints, and tail scenarios in the same spreadsheet.



This article is part of our Tokenomics Deep Dive series.