427.md

joestakey

medium

When redeeming, users can choose a different assetToken than the one they deposited, potentially making some users unable to redeem

Summary

users can choose a different assetToken than the one they deposited, potentially grieving other users.

Vulnerability Detail

When a user calls redeem() to redeem their UXD against an asset, they can specify the assetToken they want to receive in the function parameter. They can specify the asset they want, ie not necessarily the one they deposited when they minted. Consequently, some user( or users) will be "forced" to receive a different assetToken than the ones they deposited.

Though bad for user experience/expectations, this on its own does not lead to any loss (even if the assetToken is different, the value is equivalent).

The issue is for users who are blacklisted by USDC. Let us look at the following example:

• Alice sends USDC and mints N UXD
• Bob, a user blacklisted by USDC, sends WETH and mints N UXD
• Alice redeems her N UXD for WETH
• Bob is now forced to receive USDC. When he calls redeem(), the call reverts here because of the USDC blacklist.

Impact

Some users may be unable to redeem.

Code Snippet

https://github.com/sherlock-audit/2023-01-uxd/blob/main/contracts/core/UXDController.sol#L312-L340

Tool used

Manual Review

Recommendation

You can consider using a mapping to track which assetToken has been deposited by a user. But this would limit the user to deposit one type of collateral. Another solution would be to use a different UXDcontroller for each collateral, and tracking the amount of UXD minted by a user, to ensure they do not redeem more than what they have minted on a given controller.