# \[ARFC\] Onboard stcUSD to Aave V3 MegaETH

**URL:** <https://governance.aave.com/t/arfc-onboard-stcusd-to-aave-v3-megaeth/25018>\
**Category:** New Asset\
**Created:** [June 2, 2026, 1:20am UTC](https://governance.aave.com/t/arfc-onboard-stcusd-to-aave-v3-megaeth/25018 "2026-06-02T01:20:53Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![LlamaRisk](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/llamarisk/32/12865_2.png) [@LlamaRisk](https://governance.aave.com/u/LlamaRisk)\
**Post date:** [June 15, 2026, 9:39pm UTC](https://governance.aave.com/t/arfc-onboard-stcusd-to-aave-v3-megaeth/25018/8 "2026-06-15T21:39:19Z")

</div>

This analysis serves as an addendum to our [initial analysis](https://governance.aave.com/t/arfc-deploy-aave-v3-to-megaeth/23517/50) of Cap Protocols cUSD and stcUSD. The main areas covered include

1. A technical review of all the smart contracts of the cUSD and stcUSD and their main dependencies, including Layerzero cross-chain configs.
2. An update on material changes and liquidity conditions
3. Parameter recommendations

# **Summary**

LlamaRisk supports the onboarding of stcUSD. Although both Cap assets have been evaluated, following discussions with service providers and the respective teams, the preference is to commence onboarding with stcUSD only at this stage.

This is a technical review of the key smart contracts for cUSD and stcUSD, along with their main dependencies.

# **Asset Description**

Cap USD ([**cUSD**](https://megaeth.blockscout.com/token/0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC)) is a U.S. dollar stablecoin with underlying reserves consisting of institutional-grade stablecoins, including USDC and WTGXX. cUSD is 1:1 collateralized by these onchain assets and can be redeemed on the same basis.

Staked Cap USD ([**stcUSD**](https://megaeth.blockscout.com/token/0x88887bE419578051FF9F4eb6C858A951921D8888)) is a yield-bearing stablecoin that generates yield from underlying cUSD collateral, allocated to various yield strategies curated by institutional investors, called ‘Operators’.

# **Technical Analysis**

The focus of our technical analysis includes the following aspects, critical for the correct and secure integration with Aave:

- A recommendation of a pricing strategy to be used in the Aave integration.
- Mechanism to update the exchange rate of the asset for the underlying.
- Analysis of the access control (ownerships, admin roles) and the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:

| **Criticality** | **Description** |
| --- | --- |
| Critical | Grants super-admin capabilities that could fundamentally compromise the system, resulting in loss of funds if misused or exploited. (e.g., proxy admin, default admin roles) |
| High | Governs multiple system components with meaningful exposure to fund loss if misused or exploited. (e.g., general owners or admin roles involved in the flow of funds) |
| Medium | Can trigger malfunctions or minor financial losses if misused or exploited. (e.g., adjusting rates and fees, fee recipient addresses) |
| Low | Can cause malfunctions in non-critical areas without direct financial impact. (e.g., updating descriptions or certain non-critical parameters) |

| **Risk** | **Description** |
| --- | --- |
| 🟢 | Control mechanisms are robust, providing strong protection for the system and its users. Measures often include on-chain governance, a timelock contract, and multi-sigs under certain circumstances. |
| 🟡 | Control mechanisms introduce some risk exposure, depending on the scope of actions available. |
| 🔴 | Control mechanisms are inadequate and not secure, posing a direct risk to the system and its users. |

## **Contracts**

The following is a non-exhaustive overview of the main smart contracts for cUSD and stcUSD related to the main protocol functions, i.e., collateralized borrowing.

### **CapToken**

Deployed behind an upgradable ERC1967Proxy [**contract**](https://etherscan.io/address/0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC), the CapToken contract integrates minting and burning operations for cUSD and asset management functions for underlying assets within its vault structure. Implementing Oppenzepplin’s proxy standard, the implementation contract directs to this [**address**](https://etherscan.io/address/0xa76645e15c267b876999bf7689e0b2c1ee29bfe6#code). CapToken inherits from the Vault and UUPSUpgradeable contracts, which affects upgrades via the proxy.

#### **Operations**

1. **Mint** : Any user can mint new CapTokens by depositing an underlying asset by calling the `mint()` function. Internally, `getRemainingMintCapacity()` checks the deposit cap and truncates `_amountIn` if it exceeds the remaining capacity. The contract then calls `Minter.getMintAmount()` to calculate `amountOut` and `fee`. Mint fees set are sent to the [insurance fund](https://etherscan.io/address/0x5Eaf535b1e399DE08Db23b4E18bD3cD29E16b825).

2. **Burn** : Users can burn vault tokens to receive a single underlying asset by calling the `burn()` function. Internally, `getBurnAmount()` calculates the underlying `amountOut` and `fee.` The vault verifies that it has a sufficient balance of the underlying asset via the `divest() function.` Finally, `VaultLogic.burn()` enforces slippage and deadline checks, with the fee retained in the vault and `amountOut` sent to the receiving address.

3. **Redeem** : Users can redeem vault tokens for a proportional share of every underlying asset in the vault by calling the `redeem()` function. The contract calls `_burn()` to destroy the vault tokens upfront, and the vault then verifies that a sufficient balance of each underlying asset is available. Fees are retained in the vault.

4. **Borrow** : Permissioned addresses with borrow access can borrow underlying assets by calling the `borrow()` function. The `checkAccess()` modifier restricts callers. `divest()` verifies the vault has sufficient balance. Finally, `VaultLogic.borrow()` updates `totalBorrows[_asset]` and transfers `_amount` to `_receiver`.

5. **Repay** : Permissioned addresses with repay access can repay borrowed assets by calling the `repay()` function. The `checkAccess(this.repay.selector)` modifier restricts callers. `VaultLogic.repay()` decreases `totalBorrows[_asset]` and transfers \_amount of \_asset from the message sender to the vault (requires prior ERC‑20 approval). The function does not verify that the repayer is the original borrower.

6. **Add/Remove Asset** : Admin addresses can add or remove an underlying asset to the vault by calling the `addAsset(_asset)` or `removeAsset(_asset)` functions. The `checkAccess()` modifier restricts callers.

7. **Pause/Unpause Asset** : Admin addresses can pause and unpause a specific asset by calling the `unpauseAsset(_asset)` or `pauseAsset(_asset`) functions. The `checkAccess()` modifier restricts callers.

8. **Pause Protocol** : Permissioned users can pause the entire protocol by calling the `pauseProtocol()` function. The `checkAccess()` modifier restricts callers. The internal `_pause()` function from OpenZeppelin’s `PausableUpgradeable` activates the `whenNotPaused` modifier on `mint, burn, redeem, borrow`, and `repay`, temporarily locking all user funds.

9. **Unpause Protocol** : Permissioned users can unpause the entire protocol by calling the `unpauseProtocol()` function. The `checkAccess()` modifier restricts callers. The internal `_unpause`function deactivates the global pause, resuming all operations.

10. **Upgrade** : Admin can upgrade the proxy implementation logic by calling: `upgradeTo(address` `newImplementation)`.

#### **Access Control**

All permissioned functions are validated by the checkAccess method in the Access Control contract, which determines whether the caller can operate.

| Function | Permission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| addAsset | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | HIGH | 🟢 |
| removeAsset | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟡 |
| setInsuranceFund | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | MEDIUM | 🟡 |
| rescueERC20 | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | MEDIUM | 🟢 |
| pauseAsset | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟢 |
| unpauseAsset | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟢 |
| pauseProtocol | [Cap Deployer](https://etherscan.io/address/0xc1ab5a9593e6e1662a9a44f84df4f31fc8a76b52) (EOA), [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟡 |
| unpauseProtocol | [3/5 multisig](https://megaeth.blockscout.com/address/0xb8FC49402dF3ee4f8587268FB89fda4d621a8793?tab=read_proxy) | HIGH | 🟢 |
| borrow | [Lender](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) | HIGH | 🟢 |
| repay | [Lender](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) | HIGH | 🟢 |

### **stakedCap**

Deployed behind an upgradable ERC1967Proxy [**contract**](https://etherscan.io/token/0x88887be419578051ff9f4eb6c858a951921d8888#code), [**StakedCap**](https://etherscan.io/address/0x88887bE419578051FF9F4eb6C858A951921D8888) is an ERC4626 yield-bearing vault that integrates minting and burning operations for staked Cap tokens and manages the vesting logic for newly accrued yield from the underlying asset.

#### **Operations**

1. **Deposit and Mint** : Users can deposit the underlying cUSD and receive stcUSD tokens by calling `deposit()`. It calculates shares via `previewDeposit(assets)` and calls `_deposit()` , which updates `storedTotal += assets`. Minting is enacted by `mint()` function, calculating the required assets via `previewMint(shares)` and calling the same `_deposit` logic. Staked Cap tokens are minted to the receiver.
2. **Withdrawal and Redeem** : Users can redeem shares for underlying assets by calling `redeem()`, which burns a specific number of shares and sends the underlying assets. Uses `previewRedeem(shares)` to calculate assets returned. Users can withdraw using `withdraw()`, which withdraws a specific amount of underlying assets. Uses `previewWithdraw(assets)` to calculate shares burned.
3. **Yield Notification** : Anyone can notify new yield accrual by calling notify(), which starts linear unlock of newly deposited yield.
4. **Upgrade** : Admin can upgrade the proxy implementation logic by calling: `upgradeTo(address` `newImplementation)`, inherited from UUPSUpgradeable.

#### **Access Control**

| Function | Permission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |

### **DebtToken**

The DebtToken [**contract**](https://etherscan.io/address/0xfa8C6D0b95d9191B5A1D51C868Da2BDFd6C04Ff9#code) integrates minting and burning operations for debt tokens representing borrowed assets, with automatic interest accrual and interest rate management functions within its lending market structure. The contract relies on an oracle to fetch market, benchmark, and utilization rates, which determine the dynamic interest rate applied to all debt positions. Each mint or burn operation triggers an index update that compounds interest and recalculates the current interest rate.

#### **Operations**

1. **Mint** : Lender can mint debt tokens representing borrowed assets by calling `mint()`==,== minting debt tokens to a specified address. Internally calls `_updateIndex()` to refresh the accrual index before minting, then `_mintScaled()`, which scales the minted amount by the current debt index.

2. **Burn** : Lender burns debt tokens (repays debt) by calling `burn()`. Internally calls `_updateIndex()` to refresh the accrual index before burning, then `_burnScaled(),` it scales the burned amount by the current debt index.

3. **Interest Rate Accrual** : The contract automatically accrues interest when any mint or burn occurs by calling `_updateIndex()`

4. **Debt Calculation** : View functions for accrued interest include;

5. **Upgrade** : Admin can upgrade the proxy implementation logic by calling: `upgradeTo(address newImplementation)`, inherited from UUPSUpgradeable.

#### **Access Control**

| Function | Permission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| mint | [Lender](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) | CRITICAL | 🟢 |
| burn | [Lender](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) | HIGH | 🟢 |

### **Oracle**

The Oracle [**contract**](https://etherscan.io/address/0xcD7f45566bc0E7303fB92A93969BB4D3f6e662bb#code) unifies price and rate oracle functionality, providing asset prices, market rates, benchmark rates, and utilization rates to determine dynamic borrowing costs across debt positions.

#### **Operations**

1. **Rate Queries** : External contracts can fetch market rates, benchmark rates, or utilization rates by calling rate getter functions inherited from `PriceOracle` and `RateOracle`. Current Oracles:

### **Lender**

The Lender [contract](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) manages borrowing and repayment of whitelisted tokens by Operators (covered agents), calculating interest based on asset utilization rates within vaults. Lender inherits from UUPSUpgradeable, Access, and LenderStorageUtils, which affects upgrades via the proxy.

#### **Operations**

1. **Borrowing** : Agents can borrow assets by calling the `borrow()` function. Internally, it calls `BorrowLogic.borrow` with parameters including the agent, asset, amount, receiver, and a maxBorrow flag set to true if the amount is `type(uint256).max`. The borrowing process includes checks for agent eligibility (whitelisting via AccessControl), Sufficient collateral and delegation to back the borrow, and borrow amount not exceeding the maximum borrowable amount (`maxBorrowable`), and health factor remaining above the `targetHealth` after the borrow (among other checks).

2. **Repay** : Agents can repay borrowed assets by calling the `repay()` function. Internally, it calls `BorrowLogic.repay` with the agent, asset, amount, and caller (msg.sender) as parameters.

3. **Interest Management** : Anyone can realize accrued interest for an asset by calling the `realizeInterest()` function. Internally, it calls `BorrowLogic.realizeInterest`, which calculates accrued interest based on utilization rates and adds it to the reserve’s interest receiver.

4. **Restaker Interest** : Restakers can realize their specific accrued interest by calling the `realizeRestakerInterest()` function. Internally, it calls `BorrowLogic.realizeRestakerInterest`, which calculates and transfers the interest earned by a restaker for a specific agent-asset pair.

5. **Liquidations** :

6. **Asset Management** :

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| addAsset | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| removeAsset | Unassigned | CRITICAL | – |
| pauseAsset | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟡 |
| setInterestReceiver | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | MEDIUM | 🟢 |
| setMinBorrow | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | MEDIUM | 🟢 |
| setGrace | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟢 |
| setExpiry | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟢 |
| setBonusCap | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | MEDIUM | 🟢 |

### **Delegation**

The Delegation [contract](https://etherscan.io/address/0xF3E3Eae671000612CE3Fd15e1019154C1a4d693F) manages slashing, reward distribution, and coverage calculations for restakers providing coverage to borrowers within a symbiotic network middleware architecture. The contract tracks agent-specific parameters, including loan-to-value (LTV) ratios and liquidation thresholds. In the contract context, an Operator is a trusted entity that manages the delegation system that enables agents to borrow.

#### **Operations**

1. **Agent Management** :

2. **Network Registration** : Operators can register new networks by calling `registerNetwork()`. The function validates that `_network` is not the zero address, adds the network to the network’s enumerable set via `networks.add()`, which reverts with `DuplicateNetwork` if already present.

3. **Slashing** : Operators can slash an agent by calling `slash()`. The slashShare is calculated as `_amount * 1e18 / networkSlashableCollateral`.

4. **Reward distribution** : Anyone can distribute rewards by calling `distributeRewards()`. The function retrieves the contract’s balance of `_asset` via `IERC20(_asset).balanceOf(address(this))`. If `coverage(_agent)` returns zero; the entire amount is transferred to `feeRecipient`.

5. **Coverage Query** : Users can query an agent’s effective coverage by calling `coverage(_agent)`.

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| addAgent | [SymbioticAgentManager](https://etherscan.io/address/0x08a728cf4e6b39f4afa059c6ee376103722953ea), [EigenAgentManager](https://etherscan.io/address/0xa82f6f9e67e127621f3e5f3953beef926b4b5ba9) | CRITICAL | 🟢 |
| modifyAgent | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | CRITICAL | 🟡 |
| registerNetwork | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | CRITICAL | 🟡 |
| slash | [Lender](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) | CRITICAL | 🟢 |
| setLastBorrow | [Lender](https://etherscan.io/address/0x15622c3dbbc5614E6DFa9446603c1779647f01FC) | MEDIUM | 🟢 |
| setLtvBuffer | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟢 |
| setFeeRecipient | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟢 |
| setCoverageCap | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code), [SymbioticAgentManager](https://etherscan.io/address/0x08a728cf4e6b39f4afa059c6ee376103722953ea), [EigenAgentManager](https://etherscan.io/address/0xa82f6f9e67e127621f3e5f3953beef926b4b5ba9) | MEDIUM | 🟢 |

### **Vault Adapter**

The VaultAdapter contract calculates dynamic interest rates for assets in external vaults using utilization data and configurable slope parameters. The contract tracks utilization per vault-asset pair, applies a piecewise rate curve around a kink threshold, and adjusts a time-sensitive multiplier.

#### **Operations**

1. **Interest Rate Calculation** : The contract calculates interest rates based on vault utilization by calling the `rate()` function. Internally, it retrieves stored utilization data, including the last update timestamp and utilization index. Internal function applies the rate logic based on where utilization falls relative to the configured kink point.
2. **Modify Slopes** : Permissioned users can modify rate curve parameters by calling `setSlopes()`. This function validates that the kink value is neither zero nor greater than or equal to 100%, then stores the slope0, slope1, and kink values for the specified asset.
3. **Modify Limits** : Permissioned users can modify global multiplier limits and adjustment speed by calling `setLimits()`. This function updates the stored `maxMultiplier`, `minMultiplier`, and rate values that control how quickly the dynamic multiplier moves toward its bounds.

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| setSlopes | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| setLimits | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |

### **Network Middleware**

The SymbioticNetworkMiddleware [contract](https://etherscan.io/address/0x09A3976d8D63728d20DCDFEe1e531C206Ba91225) (likewise with the EigenLayer version) manages collateral, slashing, and reward distribution for agents within a Symbiotic-based network. It integrates with Symbiotic vaults to register coverage, slash operators based on oracle prices, and route rewards to staker rewarders.

#### **Operations**

1. **Vault Registration** : Permissioned users register a vault for agents by calling `registerVault()`. The function checks caller access, verifies that the agent is not already registered, and then calls the internal `_verifyVault()` function, which validates that the vault exists in the registry and has the correct configuration. Vaults are created by the `vaultFactory` (CapSymbioticVaultFactory)[**contract**](https://etherscan.io/address/0x0B92300C8494833E504Ad7d36a301eA80DbBAE2e), which deploys new vaults compliant with the Cap system.

2. **Slashing** : Permissioned callers can slash an agent via `slash()`. The function retrieves the agent’s vault, calculates slashable collateral via `slashableCollateralByVault()`, then computes the actual slash amount.

3. **Reward Distribution** : Permissioned callers distribute rewards via `distributeRewards()`.

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| registerVault | [SymbioticAgentManager](https://etherscan.io/address/0x08a728cf4e6b39f4afa059c6ee376103722953ea) | CRITICAL | 🟢 |
| setFeeAllowed | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) | HIGH | 🟡 |
| slash | [Delegation](https://etherscan.io/address/0xF3E3Eae671000612CE3Fd15e1019154C1a4d693F) | CRITICAL | 🟢 |
| distributeRewards | [Delegation](https://etherscan.io/address/0xF3E3Eae671000612CE3Fd15e1019154C1a4d693F) | HIGH | 🟢 |

### **AccessControl**

The AccessControl contract provides granular role-based access control for contract functions, enabling access rights for specific functions within specific contracts. The contract inherits from `AccessControlEnumerableUpgradeable` from OpenZeppelin.

#### **Operations**

1. **Grant Access** : Permssioned users can grant function-level access to a specific contract by calling the `grantAccess()` function. Internally, it checks that the caller has the grant access role via `_checkRole()`. It then creates a unique role ID assigned to the specific contract.
2. **Revoke Access** : Admins can revoke function-level access by calling `revokeAccess()`. Internally, it checks that the caller has the revoke access role via `_checkRole(role()`. The contract prevents self-revocation.

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| grantAccess | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |
| revokeAccess | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) | CRITICAL | 🟢 |

### **TimelockController**

The TimelockController [contract](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) integrates role-based access control and time-locked execution into its modular structure for governance operations. TimelockController inherits from AccessControl, which enables it to enforce a minimum delay on scheduled operations. The current minimum delay set is 24 hours.

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| schedule | PROPOSER\_ROLE | CRITICAL | 🟢 |
| scheduleBatch | PROPOSER\_ROLE | CRITICAL | 🟢 |
| execute | EXECUTOR\_ROLE | CRITICAL | 🟡 |
| executeBatch | EXECUTOR\_ROLE | CRITICAL | 🟡 |
| cancel | CANCELLER\_ROLE | HIGH | 🟢 |
| updateDelay | Internal | CRITICAL | – |
| grantRole | DEFAULT\_ADMIN\_ROLE | CRITICAL | 🟢 |
| revokeRole | DEFAULT\_ADMIN\_ROLE | CRITICAL | 🟢 |

#### **Roles**

| Title | Accounts |
| --- | --- |
| DEFAULT\_ADMIN\_ROLE | [TimelockController](https://etherscan.io/address/0xd8236031d8279d82e615af2bfab5fc0127a329ab#code) |
| PROPOSER\_ROLE | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) |
| CANCELLER\_ROLE | [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) |
| EXECUTOR\_ROLE | [**Cap: Deployer 1 (EOA)**](https://etherscan.io/address/0xc1ab5a9593e6e1662a9a44f84df4f31fc8a76b52), [3/5 multisig](https://etherscan.io/address/0xb8fc49402df3ee4f8587268fb89fda4d621a8793) |

### **L2TokenUpgradeable**

The L2TokenUpgradeable [**contract**](https://megaeth.blockscout.com/address/0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC?tab=read_write_proxy), which the cUSD and stcUSD MegaETH proxy deployments point to, implements cross-chain token functionality using LayerZero’s OFT (Omnichain Fungible Token) standard, combining ERC20 features for gasless approvals and UUPS upgradeability.

#### **Operations**

1. **Cross-Chain Send** : User calls `send()`, this function internally calls `_debit()`, which burns the user’s tokens on the source chain. The function then calls `_lzSend()` to send a LayerZero message to the destination chain. The LayerZero endpoint delivers the message on the destination chain following verification by the configured DVNs.
2. **Cross-Chain Receive** : the LayerZero endpoint calls the `lzReceive()` function, which extracts the recipient address and amount, then calls `_credit()` and subsequently calls the internal `_mint()` function.

#### **Access Control**

| Function | Persmission | Criticality | Risk |
| --- | --- | --- | --- |
| upgrade | [TimelockController](https://megaeth.blockscout.com/address/0x0000000035A7744F94e6949431CE20EA77312a55) | CRITICAL | 🟢 |

### OFTLockboxUpgradeable

The mainnet bridge sits behind an [ERC1967Proxy](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#code) and serves as the LayerZero OFT Adapter lockbox, with the implementation `OFTLockboxUpgradeable` contract. The mechanism holds the canonical assets on the chain and facilitates cross-chain transfers via a lock-and-release mechanism for the underlying assets. Upgrades flow through the proxyadmin, authorized exclusively by the contract owner.

#### Operations

1. **Cross-chain Send** : users can bridge tokens by calling `send` function from the inherited`OFTAdapterUpgradeable`. The adapter locks the underlying token in the lockbox and emits a LayerZero message to the destination chain’s OFT peer, where an equivalent amount is minted or released.
2. **Cross-chain Receive** : Inbound messages from LayerZero peers are processed via the inherited `_lzReceive` handler. The lockbox unlocks and transfers the underlying token to the recipient on the home chain upon receipt of a verified cross-chain message.
3. **Peer Management** : The OApp owner can configure trusted remote peers by calling the inherited `setPeer` function. This determines which destination-chain contracts are authorized to send and receive messages through this adapter.
4. **DVN / Enforced Options Configuration** : The OApp owner can set send and receive library configurations and enforced messaging options (e.g., DVN sets, executor, gas limits) via the LayerZero endpoint.
5. **Delegate Management** : The OApp owner can reassign the delegate (the address authorized to make OApp configuration changes) via the inherited `setDelegate()` function on the LayerZero endpoint.
6. **Upgrade** : The owner can upgrade the implementation contract by calling `upgradeToAndCall`, authorized through `_authorizeUpgrade` which enforces `onlyOwner`.

#### Access Control

| Function | Permission | Criticality | Risk |
| --- | --- | --- | --- |
| `upgradeToAndCall` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | CRITICAL | 🟢 |
| `setPeer` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | CRITICAL | 🟢 |
| `setSendLibrary` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | HIGH | 🟢 |
| `setReceiveLibrary` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | HIGH | 🟢 |
| `setEnforcedOptions` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | HIGH | 🟢 |
| `setDelegate` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | MEDIUM | 🟢 |
| `setMsgInspector` | [TimelockController](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137#readProxyContract) | MEDIUM | 🟢 |

### **Bridge Configuration**

Cap Protocol uses LayerZero’s OFT standard with a 3/0 DVN setup. Funds locked on mainnet before being minted on MegaETH. The protocol recently switched to the 3/0 setup comprising LayerZero Labs, Nethermind, and Canary.

| **Asset** | **OFT Adapter** | **SourceChain** | **requiredDVNs** | optionalDVNs | confirmations |
| --- | --- | --- | --- | --- | --- |
| cUSD | [OFTLockbox 1](https://etherscan.io/address/0xa62571ebdffabc3051a2e5b9e1f57b23d830c8fd#code) | Ethereum | 3 | 0 | 15 |
| stcUSD | [OFTLockbox 2](https://etherscan.io/address/0x983aeaaa0d0426839158435c43725ea7f45d4137) | Ethereum | 3 | 0 | 15 |

The required DVNs:

- [0x282b3386571f7f794450d5789911a9804FA346b4](https://megaeth.blockscout.com/address/0x282b3386571f7f794450d5789911a9804FA346b4) - LayerZero Labs
- [0x7DEcC6Df3aF9CFc275E25d2f9703eCF7ad800D5D](https://megaeth.blockscout.com/address/0x7DEcC6Df3aF9CFc275E25d2f9703eCF7ad800D5D) - Canary
- [0xeEdE111103535e473451311e26C3E6660b0F77e1](https://megaeth.blockscout.com/address/0xeEdE111103535e473451311e26C3E6660b0F77e1) - Nethermind

This setup can be considered reasonably secure, not relying on a quorum not as prone to exposure. cUSD and stcUSD are only available on Ethereum and MegaETH. At the time of writing 660K stcUSD is currently locked in the mainnet bridge.

## **Technical Conclusion**

Based on our assessment, we believe cUSD and stcUSD do not have significant infrastructure barriers to listing; however, we identified technical implementations that could pose potential security risks to users’ funds on the Aave Protocol. We summarized the risk considerations below.

- **Vault** : The `pauseProtocol()` function allows the admin to globally pause all withdrawals (mint, burn, redeem). The Cap Deployer contract retains this privilege; if compromised, this could lock all user funds and freeze the protocol until the Multisig unfreezes it.

Additionally, the MegaETH OFTs were initially owned by the 3/5 multisig, which was able to effect an upgrade without delay. Following engagement with the Cap team, ownership has since been transferred to the TimelockController, which applies a 1-day delay. This security measure enhances the original implementation and aligns with the security framework applied to other critical operations.

## **Fundamental Analysis Update**

### **Asset Classification**

stcUSD remains a yield-bearing stablecoin, comparable to already-onboarded assets such as syrupUSDC/USDT. Thus, staked cUSD complies with an accepted asset classification under AAcA.

### Multi-Chain Scope

stcUSD is available on Ethereum, MegaETH, and Tempo via LayerZero OFT. While mainnet and MegaETH represent chains that Aave has deployed on, Tempo has yet to be fully assessed. stcUSD can be bridged [interchangeably](https://layerzeroscan.com/tx/0xe078097b3e7a6d9d2310300fb6a8bc1966a41a6b3cd7998e9983ed9866bf4d3d) between these. LZ OApp configurations between chains remain consistent, i.e., DVN sets persist as message senders and receivers.

[cUSD](https://explore.tempo.xyz/address/0x20C0000000000000000000000520792DcCccCccC?tab=transfers) and [stcUSD](https://explore.tempo.xyz/address/0x20c0000000000000000000008EE4fcFF88888888) on Tempo uses a `TempoBridgeUpgradeable` [contract](https://explore.tempo.xyz/address/0x4eeC5B8FDfBcdd45Dfb29F666D9c34AD38c7aFa5?tab=interact) to bridge between the 2 available routes. The LayerZero OFT adapter bridges the TIP20 Tempo standard (ERC20 equivalent) of the Cap token between Tempo and the EVM chains, using the same mint/burn pattern. The bridge employs an ownable pattern, with the following operations.

1. **Cross-chain Send** : Caller approves the bridge, then calls `send`. Bridge pulls tokens via `transferFrom`, burns them, and emits a LayerZero message to the destination peer to mint an equivalent amount.
2. **Cross-chain Receive** : Inbound LZ messages are processed via `_lzReceive`. Bridge calls `mint` on the TIP-20 to credit the recipient directly.
3. **Peer Management** : Owner calls `setPeer` to configure trusted remote contracts. Governs which destination-chain addresses may send and receive messages through this bridge.
4. **DVN / Enforced Options Configuration** : Owner sets send/receive library configs and enforced messaging options (DVN sets, executor, gas limits) via the LayerZero endpoint.
5. **Delegate Management** : The owner can call `setDelegate` to reassign the address authorized to make OApp configuration changes.
6. **Upgrade** : Owner can call `upgradeToAndCall`.

#### Access Control

| Function | Permission | Criticality | Risk |
| --- | --- | --- | --- |
| `upgradeToAndCall` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | CRITICAL | 🟢 |
| `setPeer` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | CRITICAL | 🟢 |
| `mint` | internal | CRITICAL | - |
| `burn` | internal | HIGH | - |
| `setSendLibrary` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | HIGH | 🟢 |
| `setReceiveLibrary` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | HIGH | 🟢 |
| `setEnforcedOptions` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | HIGH | 🟢 |
| `setDelegate` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | MEDIUM | 🟢 |
| `setMsgInspector` | [TimelockController](https://explore.tempo.xyz/address/0x0000000035A7744F94e6949431CE20EA77312a55?tab=contract) | MEDIUM | 🟢 |

While the Tempo chain has not been analyzed previously, the bridging mechanism follows established LZ mechanisms. Access controls on the bridge follow the same Timelock-controlled permissions access.

### Asset Backing Structure and Visibility

Cap idle reserves are currently held in Morpho vaults, which represent ~34% of total reserves. The Cap team indicated that this setup is being changed, with idle reserves being moved to TBill products via partners such as Ondo.

Additionally, collateral assets, which consist of Aave (wstETH and weETH) and non-Aave onboarded assets (uniBTC and solvBTC), will evolve to enable RWAs as eligible collateral.

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/7/7fb9cd7173d1bc03c04f55000cd353addc292b7c.png)  
_Source: Assets in Reserve,_ [_Cap Protocol_](https://cap.app/vault/reserves/cUSD)_, June 12th, 2026_

Underlying assets are predominantly held in USDC (\>93%) with the remaining held in WTGXX. This remains consistent with our initial analysis. At present, exit liquidity remains accessible from lending protocols.

### **Operators**

Currently, there are 30 whitelisted [borrowers](https://cap.app/borrowers), of whom 15 are active and have borrowed $42.3M. Their health scores over 120%. This represents an increase since our initial analysis, which saw $16.88M lent to 6 operators.

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/c/c395a7ffd3e947af0917bd5f02d2c88899ce365c.png)  
_Source: Operator Loans,_ [_ **Cap Protocol** _](https://cap.app/vault/reserves/cUSD)_ **,** _ _June 12th, 2026_

Relative to our initial observation, the LTV/LT Ratio map indicates that loans have improved their overall scores, with fewer borrowers near the liquidation threshold. The team indicated that a more in-depth dashboard was being developed with greater visibility on parameters and operator loan health.

The protocol supports per-vault exposure limits, allowing collateral concentration risk to be managed at the individual asset or underwriter level. Coverage caps are already active for several underwriters, with the team indicating that the framework is applicable across the collateral base when required.

### **Restakers**

[Underwriters](https://cap.app/underwriters) (i.e., Delegators) to loans have increased from 17 to 22, with the combined delegation growing to $213.52M from $74.05M.

Permitted collateral assets and parameters are determined by the Cap team. The current Loan to Value parameters:

- 50-60% LTV limits on volatile assets
- 80% LTV on stable assets

The current Liquidation Threshold parameters:

- 80% LT for volatile assets
- 85% LT on Stable assets
- 90% Emergency LT for all assets

At the vault level, per-asset liquidation thresholds are configured at deployment and are not intended to be adjusted, providing borrowers with predictable collateralization requirements and, upon breach, a 12-hour [grace period](https://docs.cap.app/concepts/lender/liquidation#mechanics) during which they may repay outstanding debt before liquidation is triggered. The emergency 90% LT, which bypasses the grace period, functions as a circuit breaker, waiving the standard grace window due to protocol solvency risk.

The emergency liquidation bonus is dynamically capped at (collateral - debt) / debt. The bonus compresses as the collateral buffer narrows, ensuring that liquidations don’t payout more than the liquidatable collateral, thereby pushing a position into bad debt. For example, at 91% LTV, the bonus ceiling is ~9%, and at 95% LTV, it falls to ~5%.

### Slashing on Symbiotic

Within Symbiotic’s Shared Security Network, Cap Protocol operates as a network, permitted to slash Operators whose assets are restaked to them. Networks define their own methods for penalizing Operators within the overall slashing [**framework**](https://docs.symbiotic.fi/get-started/what/components/slashing), with the liquidations/slashing framework consisting of 4 primary contracts: Delegation, Vault, Network Middleware, and Burner Router. The slashing process on Symbiotic mirrors the liquidation process defined by the Cap protocol, and follows the following process:

1. The Network Middleware contract sends a slashing request to a penalized vault
2. The vault’s Slasher module checks if the request is valid,
3. 
  1. Reads stake data from the Delegator and its own internal data (previous slashes).
  2. Guarantees that the collateral snapshot will remain slashable for one vault epoch after that timestamp (otherwise, it is considered stale and rejected).
  3. Checks that the amount constraint is within a slashable amount \< remaining collateral.
  4. If valid, the vault updates its internal data and the Delegation contract

4. Slasher calls The Vault’s Burner module to process the penalized collateral.

Within this framework, networks choose which slashing configuration to implement for their model and which penalties enact slashing (e.g., redistributing stake, burning tokens, routing stake to a contract).

### Cap Protocol Slashing Configuration

The configurations implemented by Cap Protocol for delegations and liquidations (Symbiotic Slashing) are summarized as follows:

#### Vaults

- Symbiotic Vaults are isolated per borrower. Immutability is enforced by `OperatorNetworkSpecificDelegator`.
- Each borrower position is isolated to a single underwriter and collateral asset. When a vault is created, a new operator and vault instance are created (borrower position).
- Vaults implement an INSTANT slashing type, meaning the Slasher module is validated and executed in a single step (no dispute window).

#### Liquidations

- Liquidations are callable by anyone from the Lender contract via the `liquidate` function after the `openLiquidation` window, which invokes IDelegation.slash to begin slashing the target vault.
- Liquidators repay up to `maxLiquidatable` of the Operator’s debt. The liquidation bonus implements a dynamic liquidation bonus system, with the bonus rising linearly until the 10% `bonusCap` during an auction window.
- The LB does not differ per asset, and under emergency liquidations, the 10% maximum applies immediately (when LTV exceeds the emergency LT).
- The vault reduces the operator’s effective stake and forwards the penalized collateral to a Burner. Assets are seized and transferred through the `BurnerRouter`.
- `BurnerRoute` transfers assets upon a valid liquidation. Transfers route to the Network Middleware contract for all Cap protocol vaults.
- The Middleware contract transfers the funds to the liquidator’s `_recipient` address set when `liquidate` was called. Liquidators are compensated for the USDC repaid + applicable liquidation bonus.
- If the health score of the borrower recovers to ≥ 1e27 (\>100%) after the liquidation, the window closes. (Liquidations are only partial, up to a +25% health target recovery)

The protocol operates a layered liquidation infrastructure alongside its permissionless mechanism. The Cap team indicated that formalized liquidation agreements for specific collateral types are under negotiation with market makers. As a further backstop, the protocol operates a proprietary liquidation keeper capable of executing both atomic and non-atomic liquidations that require temporary treasury capital deployment. This multicontingent approach reduces reliance on permissionless liquidator participation during periods of market stress.

### Historical Symbiotic Slashes

To date, there have been only [**2 slash events**](https://dune.com/queries/7570182/) on Symbiotic, all performed on Cap Protocol Vaults. Given the Operator, the slash amount, the Middleware address, and timing, these events were likely internal initial tests performed by the Cap protocol. Therefore, it is difficult to determine how effectively historic liquidations have been performed from the small dataset.

| Description | Slash/Liquidation 1 | Slash/Liquidation 2 |
| --- | --- | --- |
| slashed\_at | [**2025-08-15 11:30:11**](https://etherscan.io/tx/0x31624444c129184f2f8f8048e4f8bc48797619b4a02f1b058d11e65495d9fef3) | [**2025-08-15 11:27:23**](https://etherscan.io/tx/0x6837dd5f71c04be9eae9b4dee9287a03bd460f98f40daa57be1572a1927b3617) |
| slasher\_type | InstantSlasher | InstantSlasher |
| subnetwork | Cap Protocol | Cap Protcol |
| operator | [**CapDeployer 1**](https://etherscan.io/address/0xc1ab5a9593e6e1662a9a44f84df4f31fc8a76b52) | [**CapDeployer 1**](https://etherscan.io/address/0xc1ab5a9593e6e1662a9a44f84df4f31fc8a76b52) |
| slashed\_amount | 0.017867 wstETH | 0.027790 wstETH |
| collateral\_symbol | wstETH | wstETH |
| vault\_address | [**Symbiotic: Vault 27**](https://etherscan.io/address/0x77d2d43e76e50ac3c43dd54533cd303e69cb0307) | [**Symbiotic: Vault 27**](https://etherscan.io/address/0x77d2d43e76e50ac3c43dd54533cd303e69cb0307) |
| slasher\_address | [**(5c427a)**](https://etherscan.io/address/0x3221b31f169ac6891c79f4fc352911f6605c427a#code) | [**(5c427a)**](https://etherscan.io/address/0x3221b31f169ac6891c79f4fc352911f6605c427a#code) |
| capture\_time | 2025-08-11 19:56:11 | 2025-08-11 19:56:11 |

### **Token Holder Concentration**

As of June 12th, 2026, [cUSD](https://mega.etherscan.io/token/0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC) has 478 holders and a total onchain supply of 209.9K. The largest 3 holders:

- [**EOA 1**](https://megaeth.blockscout.com/address/0x0C80c40e8A2067C7cA91409d9d94838007107863): 45.26%
- [**EOA 2**](https://mega.etherscan.io/token/0xcccc62962d17b8914c62d74ffb843d73b2a3cccc?a=0x718f0ae66c2d7dde737550b4c271f6bc131f47f0): 11.56%
- [**EOA 3**](https://mega.etherscan.io/token/0xcccc62962d17b8914c62d74ffb843d73b2a3cccc?a=0xf137ce44fbd527719e51865aacc7e6cb8385662a): 11.08%

[stcUSD](https://mega.etherscan.io/token/0x88887bE419578051FF9F4eb6C858A951921D8888#balances) currently has 197 holders and a total supply of 1.07M tokens onchain. Liquidity is concentrated with 3 holders:

- [EOA 1](https://mega.etherscan.io/token/0x88887bE419578051FF9F4eb6C858A951921D8888?a=0xc1c1fdadd3f76ff4e34f6f3f0b00f4db9b539a8f): 74.14%
- [stcUSD/USDm Kumbaya](https://megaeth.blockscout.com/address/0x0B1810B2f8B4EbA1ae12840A4F8a0EAA656b1e4e?tab=contract): 19.69%
- [**EOA 2**](https://mega.etherscan.io/token/0x88887bE419578051FF9F4eb6C858A951921D8888?a=0x343810e89aa9642616cf585a52d1152613f4cd6a): 1.29%

### **Liquidity**

stcUSD and cUSD liquidity remains low on MegaETH. The Cap protocol team has committed $2M to stcUSD liquidity on the Kumbaya DEX.

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/b/bbc7645c57d85c1bb0648fe424f8c907612ef6d6.png)  
_Source: cUSD/USDm_ [_ **Fly** _](https://app.fly.trade/swap)_, June 12th, 2026_

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/a/ae2fb76d23d9b681a38c606c116b0464371a5a34.png)  
_Source: stcUSD/USDm_ [_Kumbaya_](https://www.kumbaya.xyz/#/)_, June 12th, 2026_

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/3/32a3eb82788d7267661404aa5384d028e5f673fa.png)  
_Source: cUSD Liquidity Pools on MegaETH,_ [_ **GeckoTerminal** _](https://www.geckoterminal.com/megaeth/pools/0xf428bec5f1971186f0921226cd57e6d81e4a28ef)_, June 12th, 2026_

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/6/61c5a289fa4f260490a27b841c2e1bd3b778fe9a.png)  
_Source: stcUSD Liquidity Pools on MegaETH,_ [_ **GeckoTerminal** _](https://www.geckoterminal.com/megaeth/pools/0xf428bec5f1971186f0921226cd57e6d81e4a28ef)_, June 12th, 2026_

### **Volatility**

The [cUSD/USDM pool](https://www.geckoterminal.com/megaeth/pools/0xf428bec5f1971186f0921226cd57e6d81e4a28ef) lacks sufficient liquidity, creating frequent volatility around the intended $1 peg. The maximum and minimum price deviations observed were 1.03 and 0.97, respectively.

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/9/98f9cd549c488f4b536441f34b3bbb20081c4a24.png)  
_Source: cUSD/USDM pair,_ [_ **Dune** _](https://dune.com/queries/7599273/11551744)_, June 12th, 2026_

Given the more recent Kumbaya pool deployment for stcUSD, market volatility data is limited. The sole pool of meaningful liquidity was launched on April 28th, 2026, making a relative comparison to the internal exchange rate impractical at this stage.

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/b/b87b3ee52a86c2189392ddbe2a527b83e4397fac.png)  
_Source: stcUSD/USDM pair,_ [_ **GeckoTerminal** _](https://www.geckoterminal.com/megaeth/pools/0x0b1810b2f8b4eba1ae12840a4f8a0eaa656b1e4e)_, June 12th, 2026_

#### **Multisig Threshold / Signer identity**

Signers are Cap Protocol members.

## **Aave V3 Specific Parameters**

| Parameter | Value |
| --- | --- |
| Asset | stcUSD |
| E-Mode | Stablecoin |
| Borrowable | No |
| Collateral Enabled | No |
| Supply Cap | 10,000,000 |
| Borrow Cap | - |
| Debt Ceiling | - |
| LTV | - |
| LT | - |
| Liquidation Bonus | - |
| Liquidation Protocol Fee | 10% |
| Reserve Factor | - |
| Base Variable Borrow Rate | - |
| Variable Slope 1 | - |
| Variable Slope 2 | - |
| Uoptimal | - |

## stcUSD Stablecoin E-Mode

| Parameter | Value |
| --- | --- |
| isolated | True |
| LTV | 88% |
| LT | 90% |
| Liquidation Bonus | 4% |

| Asset | stcUSD | USDT0 | USDM |
| --- | --- | --- | --- |
| Collateral | Yes | No | No |
| Borrowable | No | Yes | Yes |

## Price Feed Recommendation

We recommend pricing stcUSD on MegaETH using the Chainlink [stcUSD/cUSD exchange rate feed](https://megaeth.blockscout.com/address/0x7055a15452B19D193fbA6ec2FF6bf7B515cf577d) in conjunction with a base [USDC/USD](https://data.chain.link/feeds/megaeth/megaeth/usdc-usd) price feed and CAPO adapter. Both price feeds use a 0.5% deviation threshold and a 24-hour heartbeat.

While a [cUSD/USD](https://megaeth.blockscout.com/address/0x72b127332BEC8722ec964235D33658A72E451754?tab=read_write_contract) Chainlink price feed exists, the feed is an internal exchange rate feed, with the base feed necessitating a market price reference with the exchange-rate component for accurate price reporting for Aave. Given that \>93% of cUSD is backed by USDC, we recommend this setup until the appropriate market rate feed is deployed.

## CAPO Configuration.

The effective yield of stcUSD varies over time based on the selection of Operators, their approved strategies, and the idle liquidity deployed to DeFi protocols that earn passive yields. stcUSD yield has demonstrated minimal volatility over the past three months.

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/f/f27d52d91e137c660bb2bb8e8223cf3ce0fa51e7.png)  
_Source: stcUSD APY,_ [_Dune_](https://dune.com/queries/7404798/11341593)_, June 12th, 2026_

We recommend setting `MINIMUM_SNAPSHOT_DELAY` to 14 days and `maxYearlyRatioGrowthPercent` to 10.5%. This would help smooth short-term volatility, given the asset’s relatively recent deployment, thereby ensuring consistent pricing.

### **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.

---

_[View the full topic](https://governance.aave.com/t/arfc-onboard-stcusd-to-aave-v3-megaeth/25018)._