Strong Green Pony - mint

[sherlock-admin4]

Strong Green Pony

Medium

mint

https://github.com/sherlock-audit/2025-07-cap/blob/2bd34fa369d36af8ecc377090d3292ea74ccc669/cap-contracts/contracts/vault/libraries/MinterLogic.sol#L92

Logical Inconsistency

Why do we enforce a strict, oracle-priced value exchange when capSupply > 0, yet switch to a simple 1-to-1 quantity swap for the very first mint? This means the contract’s initial state and all subsequent states obey different rules.

Potential Risk

If, during the first mint, the oracle’s capPrice (e.g., the target $1) differs from assetPrice (e.g., an unstable asset at $0.5), the first minter enters the system at an incorrect valuation. That disadvantages later participants or grants the first minter an unfair edge.

1. Core Risk: Stablecoin De-pegging

This is the primary risk. Stablecoins are not 100 % stable, and history has seen multiple brief or severe de-pegging incidents.

Attack scenario

1. Market panic drives USDT’s market price down; its oracle‐reported assetPrice updates to $0.97, while the top-layer token’s oracle price capPrice remains fixed at $1.00.

2. Attacker (Eve) spots the opportunity and buys a large amount of USDT on the open market at $0.97.

3. She becomes the protocol’s first minter, depositing 1,000,000 USDT.

4. Because of a bug, she receives 1,000,000 top-layer tokens (1-to-1 exchange).

Analysis of Eve’s trade

Item | Value -- | -- Actual market value of her deposit | 1,000,000 × $0.97 = $970,000 Claimed value of the received tokens (per oracle) | 1,000,000 × $1.00 = $1,000,000

Consequence:
With assets worth $970 k, Eve has conjured $1 M of system debt out of thin air. From the very first second the protocol exists, it carries $30 k in bad debt, and its overall collateral ratio is only 97 %.

Follow-up exploit:
Later, an innocent user Bob deposits 100,000 USDC (worth $100 k). Eve can now redeem her top-layer tokens at the $1.00 oracle price, withdrawing Bob’s high-quality USDC and pocketing the difference.

Although this 3 % loss is smaller than the 50 % in earlier examples, for a large-scale protocol it is still an unacceptable, zero-effort profit handed to the attacker.

---

2. Oracle Lag or Small Price Gaps

Even without major de-pegs, tiny price differences between stablecoins—or latency in oracle updates—can be exploited. For instance, pyUSD may have lower liquidity than USDC, causing more frequent micro-fluctuations. A savvy attacker can take a flash-loan, mint during a fleeting price deviation using the cheapest stablecoin, and saddle the protocol with a small initial loss. Over time, these “penny” exploits can add up to a significant problem.

---

What should be done?

A more robust, logically consistent design would use the same valuation logic whether or not capSupply is zero. In other words, the calculation inside the if block should also rely on capPrice.

Suggested Fix

Inside the if (capSupply == 0) branch, make the code match the else branch:

// ❌ Buggy code
amount = assetValue * capDecimalsPow / assetPrice;

// ✅ Corrected code
amount = assetValue * capDecimalsPow / capPrice;