Superstate A-1

In the redeem() function, when calculating the USDC amount out in return for the ustbInAmount input, the chainlink feed price for the USTB/USD pair is directly used as the USDC price, assuming a pegged exchange ratio with USD.

(bool isBadData,, uint256 usdPerUstbChainlinkRaw) = _getChainlinkPrice();
if (isBadData) revert BadChainlinkData();

// converts from a USTB amount to a USD amount, and then scales back up to a USDC amount
uint256 usdcOutAmount =
    (ustbInAmount * usdPerUstbChainlinkRaw * USDC_PRECISION) / (CHAINLINK_FEED_PRECISION * USTB_PRECISION);

Reference: Redemption.sol#L177-182

However, in abnormal market conditions, this 1:1 ratio can change and has changed before, potentially allowing external actors to execute arbitrage operations and profit from this indirect hardcoded value. Depending on the direction of de-peg, actors could receive more USDC than they should, allowing them to profit from external opportunities or users could end up with a lower exchange rate than what they should have received.

Remediations to Consider

• Consider implementing a price feed for USDC and use it as a reference to calculate the amount out in redeem() and maxUstbRedemptionAmount().

In the _getChainlinkPrice() function when performing validation, _isBadData is determined using following expression:

(, int256 _answer,, uint256 _chainlinkUpdatedAt,) =
            AggregatorV3Interface(CHAINLINK_FEED_ADDRESS).latestRoundData();

// If data is stale or below first price, set bad data to true and return
// 10_000_000 is $10.000000 in the oracle format, that was our starting NAV per Share price for USTB
// The oracle should never return a price much lower than this
_isBadData = _answer <= 7_000_000 || ((block.timestamp - _chainlinkUpdatedAt) > maximumOracleDelay);

Reference: Redemption.sol#L142-148

Part of the validation _answer <= 7_000_000 implicitly assumes that _answer is a number with 6 decimal places of precision.

However, most of the non-ETH pairs return values with 8 decimal places of precision, while price feeds with ETH pairs have 18 decimal places of precision. As a result, if the USTB chainlink feed is indeed 8 decimal places of precision due to the incorrect assumption, this validation will be incorrect. For example, even if the result from the price feed is $0.08, it will still pass the validation.

Remediations to consider

• Take into account CHAINLINK_FEED_PRECISION for USTB feed when evaluating _answer price data.

Although the Redemption contract can be indirectly paused or stopped by setting the maximumOracleDelay to zero or withdrawing all assets as an admin, consider adding pause features and checks to allow admin control and user transparency on potential contract states and unwanted external financial scenarios where redemptions should not be executed.

In the _getChainlinPrice() function, the answer value comparison is hard coded to 7_000_000 as safety insurance. Consider having a constant variable for this value to avoid having magic numbers.

Compound supports withdrawing the whole balance when type(uint256).max is provided as an amount to withdraw. However, in the admin callable withdraw() function, there is a validation that prevents this feature from being utilized:

if (balance < amount) revert InsufficientBalance();

Reference: Redemption.sol#L206

As a result, withdrawals of max amounts may leave dust amounts of USDC in the Compound contract.

Remediations to consider

• Skip token balance validation when the provided token is a COMPOUND token and leave it to underlying Compound contract implementation to generate an error in case the requested amount is too big.

In withdraw() and deposit() functions, corresponding Withdraw() and Deposit() events are emitted. Both of these events, when emitted, set withdrawer and depositor values to msg.sender, which for both functions is unchangeable ADMIN. Since no added value exists in including fixed values within events, consider removing withdrawer and depositor arguments from these two events.

The Redemption contract integrates with Compound Comet contracts to supply and withdraw assets, generating yield with the USDC deposited in the contract and withdrawing it when users execute redeem(). It is worth noticing that Compound contracts can pause both supply and withdrawal via the Pause guardian, a governance-elected entity. If paused, the contract will be stale, disallowing the user’s redemption and protocol’s deposit and withdrawals.

Since on-chain redemptions are available even when traditional markets are closed (e.g., weekends, holidays), any market-generating event that could reduce USTB's NAV on the following trading day could be a front-ran on-chain by the users through this redemption contract.