`operationalTreasury`: assumes 1:1 USD value for base token
In OperationalTreasury, the protocol calculates fees and premium amounts in USD, but it assumes that the baseSetUp.token (buy token) value is always equal to 1 USD.
Severity
Impact: High
Likelihood: Low
Description
In OperationalTreasury, the protocol calculates fees and premium amounts in USD, but it assumes that the baseSetUp.token (buy token) value is always equal to 1 USD. This assumption can lead to a wrong collection of funds if the token is valued at less than 1 USD, or worse if it becomes depegged.
_takeFeesLockLiquidity function:
function _takeFeesLockLiquidity(Position memory pos, uint256 amount, uint256 premium, uint8 tokenDecimals)internalreturns (uint256 fees){OperationalTreasuryStorage.BaseSetUp memory baseSetUp = OperationalTreasuryStorage.layout().setUp.base;// fees and transfer funds here{fees = _calculateFeesUSD(pos.uAsset, amount).toDecimals(18, tokenDecimals);// fees added on top of premiumOperationalTreasuryStorage.layout().ledger.collectedFees[address(baseSetUp.token)] += fees;// funds transfer from buyer to treasury. Premium transferred to pool, fees stay in treasurybaseSetUp.token.safeTransferFrom(msg.sender, address(this), premium + fees);}// lock liquidity in pool{baseSetUp.token.safeIncreaseAllowance(baseSetUp.pool, premium);IPositionInteraction(baseSetUp.pool).openPosition(pos);}}
In the current implementation:
- Fees are calculated in USD with 18 decimals.
- Then converted to token decimals (e.g., 6 or 18) using .toDecimals().
- The amount of base token is transferred from msg.sender.
- But the actual exchange rate between the base token and USD is not accounted for. This leads to incorrect fees and premium amounts being transferred from the user, especially if the token loses its peg or fluctuates significantly.
Note: Same issue happens in payoff, The pnl amount is calculated in USD, but finally the amount of the base token is transferred to the user.
Recommendations
Consider using base token (buy token) price and value in calculations.
Report provenance
Published by Pashov Audit Group, with Carlos (Bloqarl) participating as a contractor. The source report states that its fixes review was not fully completed; no final remediation disposition is recorded for this finding. Read the full report.