Weâre presenting our assessment of cUSD & stcUSD, which was part of the original ARFC. LlamaRisk believes these assets can be safely onboarded once liquidity conditions improve.
Summary
LlamaRisk provisionally supports the onboarding of cUSD and stcUSD to the MegaETH instance, contingent upon improved liquidity depth on the network. The Cap Protocol assets are reserve-backed stablecoins, with stcUSD representing the staked, yield-bearing component of the protocol. cUSD facilitates yield generation by enabling borrowers to access liquidity against collateral sourced from restaking platforms, Symbiotic and EigenLayer.
While the protocol introduces dependencies on these platforms, slashing conditions and whitelisting requirements provide sufficient risk mitigation to preserve the underlying value of both assets. Liquidity on MegaETH remains severely constrained for cUSD and stcUSD, with cUSD representing the only asset currently supported by a tradeable pair (~$9K TVL at time of writing). We also note a contraction in supply on both the canonical chain and MegaETH. Both assets implement LayerZeroâs OFT standard, a familiar framework for Aave given its use across several integrated assets. A Chainlink stcUSD/cUSD price feed is available; however, a cUSD/USD price feed would need to be deployed on MegaETH in the long term to account for a multi-asset reserve. Presently, a USDC/USD price feed can be used, as 95% of reserves are in USDC.
Based on our analysis, we recommend onboarding after a reassessment of liquidity availability, with a full endorsement conditional on sufficient liquidity to support onboarding and the establishment of a Chainlink price feed.
1. Asset Fundamental Characteristics
1.1 Asset
Cap USD (cUSD) is a U.S. dollar stablecoin, with underlying reserves consisting of institutional-grade stablecoins, which currently include USDC and WTGXX. cUSD is 1:1 collateralised by these onchain assets and can be redeemed on the same basis.
Staked Cap USD (stcUSD) is a yield-bearing stablecoin that generates yield from underlying cUSD collateral that is allocated to varying yield strategies curated by institutional investors called âoperatorsâ.
As of February 26, 2026, cUSD has a circulating supply of 142.6K on MegaETH (out of 110M total), and stcUSD has a circulating supply of 3.1K on MegaETH (out of 74M total).
1.2 Architecture
Issued by the Cap Protocol, cUSD, and to a greater extent, stcUSD, rely on three primary actors to facilitate the protocolâs design. These actors consist of operators, restakers, and liquidators who are incentivized to generate yield through diversified strategies while also providing secured collateral to underwrite the risk to stablecoin reserves.
Source: Cap Protocol, Protocol Overview
On MegaETH, cUSD and stcUSD use layerzeroâs bridging infrastructure and utilize the OFT standard.
cUSD
cUSD is a reserve-backed stablecoin, with minting, burning, and redemption operations occurring on mainnet. The ERC20 token represents a share of an underlying vault of supported assets and serves as the liquidity hub for the protocolâs yield generation.
Core vault and peg management include the following mechanisms:
- cUSD can be redeemed for any whitelisted asset on a weighted basis
- Oracle-referenced pricing determines the cUSD price relative to the underlying assets
- Mint/burn operations include fees that accrue to an insurance fund
- A deposit cap function limits the amount of cUSD that can be minted
cUSD effectively acts as an onramp for USD collateral used in yield operations when cUSD holders stake for stcUSD. The vault employs a fractional reserve model, which deploys idle capital into yield-generating strategies such as lending markets on Aave and Morpho. Gelato automates capital deployment, yield harvesting, and fee distribution, with yields accrued to stcUSD holders (see the stcUSD section below for the fee accrual process). According to Cap protocol docs, a buffer reserve is used to facilitate withdrawals.
Source: Cap Protocol, Protocol Transparency, February 23, 2026
Deposit caps are set per whitelisted asset, which currently includes USDC and wWTGXX (Wrapped WisdomTree Government Money Market Digital Fund). USDC currently has an effectively unlimited deposit cap, while WTGXX has a cap of 5.1 million. The presence of a depositCap parameter potentially limits the ability to maintain cUSDâs peg; however, USDC deposits are functionally unlimited.
Key components that enable cUSD include:
- Vault: Manages collateral storage, accounting, and cUSD minting/burning.
- Minter: Handles dynamic fee calculation for minting, burning, and redeeming operations.
- FractionalReserve: Main logic for capital deployment on a per asset basis, following Yearn V3âs Tokenized Strategy pattern.
- CapSweeper: Gelato contract that periodically invests excess assets.
- cUSD Adapter: Calculates cUSD value relative to the underlying.
stcUSD
Yield accruals to stcUSD are enabled through an over-collateralized lending model, following a permissionless lending mechanism similar to Aave. Protocol actors that engage with the Cap protocol include:
- Operators: investors that borrow underlying liquidity to generate yield, borrowing against secured collateral from restakers. To access liquidity, operators must be whitelisted and generate yield above the hurdle rate of the borrowed asset.
- Restakers: protocols that operate on restaking platforms such as Symbiotic and Eigenlayer, that delegate staked assets to operators as collateral to underwrite liquidity that operators borrow from the cUSD vault.
- Liquidators: permissionlessly liquidate undercollateralized positions by slashing restaker delegated collateral.
Source: stcUSD flow, Cap Protocol
Operators borrow reserves from the vault up to the assetâs Loan To Value, and based on their ability to generate yield above a âhurdle rateâ, which is a dynamic rate consisting of a minimum market rate (benchmarked against protocols like Aave) and the utilization rate. Operators pay a borrow rate to the protocol, which comprises the restaker rate and hurdle rate.
Operators
Borrowing from the vault requires operators to be whitelisted by the Cap protocol and have an agreement with restakers. Collateral coverage for loans is governed by a set of loan parameters, including Loan to Value (LTV), Maximum Borrow Amount (Coverage x LTV), liquidation Threshold, and LTV Buffer (Minimum gap between LTV and liquidation threshold). Permitted investment strategies are determined in agreement with restakers, who take on the underwriting risk.
There are currently 25 whitelisted operators, with a total borrowed amount of $16.88M originating from 6 operators.
Source: Operator Loans, Cap Protocol, February 23, 2026
Restakers
Delegations are made from Shared Security Networks; Symbiotic and Eigenlayer, by restaking protocols that enter into agreements with operators to underwrite borrowing from the cUSD vault. Restakers set a fixed restaker rate they receive from operators, with fees paid in ETH and USD. Cap integrates with SSN infrastructures, with delegators deploying restaking platform-based vaults to provide coverage to operators.
Source: Symbiotic collateral vault deployment, Cap Protocol
Delegations are isolated per operator, meaning slashing events affect only specific operators rather than the entire protocol. Currently, there are 17 total delegators, with a combined delegation of $74.05M, made up of wstETH, LBTC, WBTC, sfrxUSD, weETH, OETH, and uniBTC. Delegated collateral that is withdrawn is liable to be slashed should its coverage of a borrowed position fall below the LT.
Collateral delegation by platform is concentrated around Symbiotic, with 98% of all delegations occurring there. The largest restaker, Bedrock, accounts for ~51% of delegated collateral.
In the event a liquidation threshold is exceeded, borrowers are afforded a 12-hour grace period to repay the loan.
Liquidations
Slashing occurs under 2 conditions: when the collateral value falls below safe thresholds, and when operators default on loan repayments. The conditions for slashing are determined by operator health factors dropping below the liquidation threshold. When a slashing event happens, liquidators purchase the operatorâs delegated collateral and repay the outstanding debt.
Liquidations occur via a Dutch auction, with liquidators buying collateral at a discount to recapitalize undercollateralized positions. To date, no liquidations have occurred, with LTVs currently configured conservatively.
Yield Sources and Accrual
stcUSD yield is primarily generated from passive reserve allocations to lending markets. At the time of writing, the 7-day average yield accrual had a distribution of 35.67% from AAVE USDC, 45.23% from Morpho USDC, and 19.11% from Borrow Yield. If cUSD and stcUSD are onboarded, this would rehypothecate underlying USDC collateral.
Accrued fees in USD and ETH are sold at auction for cUSD and distributed to stcUSD holders.
Source: Fee auction, Cap Protocol
Key components that enable stcUSD include:
- StakedCap: ERC4626 yield-bearing vault that accrues and distributes yield to stakers.
- Delegation: middleware between Shared Security Networks and the lending protocol, enabling.
- Oracle: Main contract combining PriceOracle and RateOracle functionality, handling price and interest rate data.
- Lender: Main interface for all lending operations. Manages the borrowing, repayment, and liquidation processes for operators.
- Access Control: Central contract that implements the role-based access control logic.
- Fee Auction: facilitates permissionless Dutch auctions of accumulated yield.
- Fee Receiver: distributes fees collected from the auction to stakeholders.
- Network Middleware: vault slashing and collateral management middleware.
- Vault Factory: creates collateral vaults for collateral delegation from restakers.
- Agent Manager: whitelist manager for operator registration.
cUSD and stcUSD implement a novel lending model that utilizes collateral sourced from restaking platforms. The lending mechanisms employed are akin to Aave, with parameters such as LTV and dynamic interest rates based on utilization and loan management.
1.3 Tokenomics
Minting and Burning
cUSD is minted when a user deposits a whitelisted USD asset, currently USDC or WTGXX. Cap protocol docs indicate additional supported assets; the team indicates that these will be on the borrower side, based on demand, e.g., BUIDL. Minting occurs at an approximate 1:1 exchange rate, minus a dynamic fee (based on a piecewise curve). This fee is calculated by the Minter contract based on the assetâs current allocation ratio within the total vault reserves.
stcUSD is minted when users deposit cUSD into the StakedCap vault, receiving a corresponding amount based on stcUSDâs exchange rate. Burning functions similarly for both assets, the difference being that:
- Burning stcUSD returns cUSD with accrued yield.
- Burning cUSD redeems a proportional basket of assets.
Source: Mint/Burn dynamic fees, Cap Protocol
Redemption
In the event of an underlying depeg, losses are socialized proportionally. Redemption fees are charged at a fixed percentage (currently set to 0). At the time of writing, the current vault composition indicates minimal buffer liquidity to support redemptions (<0.01%). This limits the possible avenues for immediate liquidity. Aave and Morpho deposits remain liquid but will incur marginal delays when facilitating redemptions
wWTGXX
The WisdomTree Treasury Money Market Digital Fund is a yield-bearing stablecoin backed by RWAs, including U.S. TBills and Bank Repos. The ERC20 token implements compliance and regulatory controls, requiring holders to be whitelisted, authorised accounts to implement regulatory interventions (pause/freeze), and minting is privileged.
This underlying asset is intended to be borrowed only by permissioned users, thereby limiting utilization to KYCâd borrowers.
Source: WTGXX, Holding Details, February 23, 2026
1.3.1 Token Holder Concentration
As of February 23, 2026, cUSD has 176 holders and a total onchain supply of 137K. The largest 3 holders:
stcUSD currently has 18 holders and a total supply of 3K tokens on-chain. Liquidity is concentrated with 3 holders:
2. Market Risk
2.1 Liquidity
Source: Fly, February 26, 2026
Users can swap 9.8K cUSD for $9.3K USDm within a price impact of 7.5%.
2.1.1 Liquidity Venue Concentration
Source: cUSD Liquidity Pools on MegaETH, GeckoTerminal, February 26, 2026
cUSD onchain liquidity is limited to cUSD/USDm pool on Prism ($14.2K TVL) and cUSD/USDm pool on Kumbaya ($6.4K). stcUSD DEX liquidity on MegaETH is currently zero.
2.1.2 DEX LP Concentration
cUSD DEX liquidity on MegaETH is significantly concentrated, with a single LP supplying the majority of the liquidity. Below is the breakdown (as of February 26, 2026):
- Prism cUSD/USDm: 57% of the poolâs liquidity is supplied by an EOA.
- Kumbaya cUSD/USDm: 72% of the poolâs liquidity is supplied by the same EOA.
2.2 Volatility
MegaETH deployment of cUSD and stcUSD is recent; thus, market volatility is data is limited.
Source: cUSD/USDM pair, GeckoTerminal, February 23, 2026
2.3 Exchanges
cUSD and stcUSD are exclusively traded on DEXs and are not currently listed on any centralized exchange.
2.4 Growth
On the ETH mainnet, cUSD saw initial positive growth, rising from 8M to 443M in January 2026. At the time of writing, supply has steadily declined to a current ~120M. stcUSD growth is dependent on cUSD growth, with a current staked rate of ~69%.
Source: stcUSD staked percentage, Dune, February 23, 2026
As stated previously, given the recent deployment on MegaETH, growth data is limited.
3. Technological Risk
3.1 Smart Contract Risk
8 audits have been conducted on Cap protocolâs codebase; the following findings were observed based on severity:
- Spearbit, November 27th, 2025 - None
- Certora, September 15th, 2025 - 2 medium, 3 low, and 3 informational
- Sherlock, July 10th, 2025 - 10 medium
- Recon, May 28th 2025 - 2 medium, and 4 low
- Electisec, May 25th, 2025 - 3 low
- Spearbit Lead Security Researchers, Apr 14th, 2025 - 2 high, 8 medium, 8 low, 7 informational, and 2 gas-related
- Trail of Bits, March 3rd, 2025 - 7 high, 8 medium, 6 low, and 8 informational
- Zellic, February 17th, 2025 - 1 critical, 1 high, 2 medium, 1 low, and 4 informational
3.2 Bug Bounty Program
Layerzero and Cap Protocol both have bug bounties, with max bounties worth $15.5M and $1M, respectively. OFT, Cap protocol smart contracts are explicitly stated in the program scopes.
3.3 Price Feed Risk
Cap Protocol determines cUSD price via [CapTokenAdapter](https://etherscan.io/address/0xAcc9ce4C15A0F6A2bec49C3F81261d60553D2Faf), which calculates the weighted average of the underlying basket of assets (USDC, wWTGXX) for cUSD pricing. Conceptually, the price per cUSD equals the total USD value of all assets in the vault divided by the total supply of Cap Tokens. The underlying reserve assets are priced using external price feeds, using the priceOracleData function, which are as follows:
Hardcoding WTGXX to $1 introduces collateralization risk; if WTGXX were to become undercollateralized, this would create an exploit opportunity, allowing holders to redeem at a higher proportion than their shares are worth (and new mints would charge users a premium). As stated previously, redemptions are fulfilled on a proportional basis based on the weights and market prices of underlying assets. Mitigating factors for WTGXX include its low deposit cap of 5.1M, which currently represents ~4.3% of deposits, and compliance controls on collateralization, minting, and redemption.
Source: [contracts/oracle/libraries/CapTokenAdapter.sol](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/oracle/libraries/CapTokenAdapter.sol)
function price(address _asset) external view returns (uint256 latestAnswer, uint256 lastUpdated) {
uint256 capTokenSupply = IERC20Metadata(_asset).totalSupply();
if (capTokenSupply == 0) return (1e8, block.timestamp);
address[] memory assets = IVault(_asset).assets();
lastUpdated = block.timestamp;
uint256 totalUsdValue;
for (uint256 i; i < assets.length; ++i) {
address asset = assets[i];
uint256 supply = IVault(_asset).totalSupplies(asset);
uint256 supplyDecimalsPow = 10 ** IERC20Metadata(asset).decimals();
(uint256 assetPrice, uint256 assetLastUpdated) = IOracle(msg.sender).getPrice(asset);
totalUsdValue += supply * assetPrice / supplyDecimalsPow;
if (assetLastUpdated < lastUpdated) lastUpdated = assetLastUpdated;
}
uint256 decimalsPow = 10 ** IERC20Metadata(_asset).decimals();
latestAnswer = totalUsdValue * decimalsPow / capTokenSupply;
}
Additionally, the protocol has no mechanism to handle bad debt or write down loaned reserves. When an operator defaults on a loan, and a liquidation cannot fully recover the debt, the vault will hold fewer actual tokens than recorded in totalSupplies (i.e. totalSupplies is never reduced). The CapTokenAdapter oracle prices cUSD as sum(totalSupplies[i] Ă assetPrice[i]) / capTokenSupply, so it ignores these shortfalls and overstates cUSD value when backing losses occur (e.g., deficit accrual due to unsuccessful liquidation). An insurance fund (477K cUSD, 13K USDC) is available as a short-term buffer, but there is no oracle adjustment for deficits. This insolvency would be borne by the last withdrawers, where redemptions could face reversals due to InsufficientReserves.
Given that >95% of cUSD is backed by USDC, we recommend pricing cUSD using the USDC/USD feed and using the stcUSD/cUSD exchange rate feed in conjunction to price stcUSD. In the long term, a cUSD/USD price feed can be deployed for MegaETH, which relays the cUSD price by calling getPrice(asset) on the Oracle contract on Ethereum Mainnet.
3.4 Dependency Risk
Cap protocol is primarily dependent on the restaking platforms Symbiotic and Eigen to secure collateral. The risks associated with this architectural design relate to restaking, namely, wrongful slashing in the event of inaccurate slashing conditions or restakers pulling delegated liquidity, thereby undercollateralizing/slashing. Restaking platforms implement automated monitoring systems to mitigate this, and the Cap protocol sets a 2-epoch (8-14 days) processing time for withdrawals from its vaults, with collateral still vulnerable to slashing if loans remain open. This ensures immediate withdrawals canât be made and that open loans are never undercollateralized.
On MegaETH, the cUSD and stcUSD are implemented as LayerZero OFTâs (Omnichain Fungible Token). This standard is familiar to Aave and inherits risks already accepted with other OFTs.
4. Counterparty Risk
4.1 Governance and Regulatory Risk
The website located at cap.app is published, owned, and operated by Covered Agents S.A., a corporation incorporated under the laws of the Republic of Panama (âCompanyâ), together with its Affiliates and related entities. The user-facing âPlatformâ is structured to enable Users to interact directly, without the Companyâs active involvement, via public blockchains and smart contracts. The Terms expressly state that the Company âhas designed the Platform to be directly accessible by Users without any involvement or actions taken by Company or any third-party,â and that âall transactions on the Platform are facilitated by Smart Contracts.â
Based on a review of Capâs documentation and the Platform Terms of Use, cUSD holder ârightsâ are most appropriately characterized as technical entitlements enforced through smart contract execution, rather than as a clearly documented contractual claim against an identifiable issuer or obligor. cUSD is described as a stablecoin implemented via smart contracts that holds and/or allocates a pool of whitelisted reserve assets and enables minting, burning, and redeeming operations against that pool. On that basis, cUSD resembles a multi-collateral onchain âclaim on a poolâ (i.e., a redemption mechanism implemented in code), rather than a traditional single-issuer IOU. However, the absence of an explicit legal issuer and a governing-law holder agreement complicates any attempt to anchor cUSD as a legally enforceable obligation or claim in the conventional sense.
âMintâ is described as depositing reserve assets to mint cUSD at oracle value; âBurnâ as redeeming cUSD for reserve assets at the asset price reflecting the highest deviation; and âRedeemâ as multi-collateral redemption. Redemption outputs are described as proportional baskets determined by current weights and market prices. Redemptions are described as âguaranteed at all times,â but may be delayed where reserve assets are fully utilized. These statements describe intended protocol behavior; they do not, on their face, constitute a clear legal undertaking by a defined person to redeem at par in fiat, or to provide liquidity within any fixed timeframe.
Cap states that it does not rely on third-party custodians. At the same time, the âreserve assetsâ comprise third-party stablecoins and tokenized products (e.g., USDC, pyUSD, BENJI, BUIDL) whose respective issuers and/or administrators typically retain contractual controls, including token-level freezing or blacklisting, and Capâs risk disclosures expressly flag freeze, seizure, and forfeiture risk.
The Terms are governed by Panamanian law and specify Panamanian jurisdiction and Panamanian-seated arbitration (CeCAP in Panama City). Panamanian financial regulators have historically taken the position that cryptocurrencies lack a specific Panamanian legal framework and are not subject to financial regulator supervision in the manner applicable to regulated securities or banking products.
The SMV published a warning stating that cryptocurrencies âdo not have a legal frameworkâ and therefore âare not under supervision or oversight of a financial regulatorâ in Panama.
SMV Opinion No. 07-2018 states, in substance, that there is no regulation for fintech and cryptocurrencies in Panama. The SBP similarly stated (in a public notice) that cryptocurrencies âdo not have a specific legal regulationâ in Panama, that SBP-regulated banks had not requested authorization to engage in cryptocurrency exchange, investment, or commercialization activities, and it reminded the public that such crypto activities âare not subject to supervisionâ by the SBP.
These regulator statements are (i) regulator-competence-specific and (ii) do not constitute a general âlicense-freeâ safe harbor for every structure involving crypto. Separately, Capâs own Terms define âApplicable Lawâ broadly to include âall laws⌠having the effect of law of any Governmental Authority, including the Republic of Panama,â and require Users to âuse the Platform only for lawful purposes⌠and comply with the law.â Based on the cited Panamanian sources, Capâs stated position that there are no licensing or regulatory requirements for its structure appears defensible. From these sources, Cap can credibly support a ânon-custodial, smart-contract-mediated access modelâ narrative (direct access, smart contracts, public blockchain execution, and a front-end operator governed by Panama law).
Nonetheless, in response to our questions as to whether they have sought legal advice regarding the Panamanian regulatory framework and its implications for the operating entity, and whether they rely on a formal legal opinion addressing the applicable framework and any relevant exemptions, the Cap team stated that they have conducted internal legal research and analysis supported by a Panamanian legal team. They further indicated that, based on that work, their conclusion is that the protocol does not fall within any particular Panamanian licensing framework and that Panama does not require a license for the relevant activities. This position aligns with the conclusions reflected in our summary above. The Cap team also confirmed that, if required, they are prepared to provide a formal written position on this matter.
4.2 Access Control Risk
cUSD and stcUSD are deployed behind Transparent Upgradeable Proxies.
4.2.1 Contract Modification Options
ETH mainnet implements a role-based access control (RBAC) system. The main roles and their associated capabilities mainly consist of:
- DEFAULT_ADMIN_ROLE: Can upgrade the AccessControl contract
- Access Management Roles: Can grant/revoke permissions
- Function Specific Roles: Control access to individual functions
Each contact has an admin assigned, i.e., Oracle admin, Rate oracle admin, Lender admin, Delegation admin, Vault config admin. An Emergency admin can pause the protocol, make emergency withdrawals, and
The MegaETH-based OFT contracts: cUSD and stcUSD are owned by a â
multisig.
The owner has access to the following sensitive functions:
upgradeTo - contract upgradetransferOwnership: changes contract ownershiprenounceOwnership: renounce ownership- LayerZero Configuration Changes
-
setDebt: OFT debt settingsetPeer: sets LayerZero peer contractssetUseCustomAdapterParams: set adapter params
4.2.2 Timelock Duration and Function
A TimelockController with a 24-hour delay for changes made on mainnet.
No Timelock is in place for the MegaETH contracts. The contracts use a single-owner model with immediate execution for all privileged functions.
This pattern is common for bridged assets, with the canonical chain applying delays to admin changes that affect the underlying collateral and the protocolâs design.
4.2.3 Multisig Threshold / Signer identity
Signers are Cap Protocol members.
Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.
Aave V3 Specific Parameters
Will be presented jointly with @ChaosLabs.
Price feed Recommendation
We recommend using a USDC/USD feed to price cUSD. stcUSD can be priced using the internal stcUSD/cUSD exchange rate in conjunction with the base USDC feed with CAPO.
Disclaimer
This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.
The information provided should not be construed as legal, financial, tax, or professional advice.
