Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding collateral enabled checks for redemption collections might make users uncapable of redeming their funds. #930

Open
0xadrii opened this issue Apr 19, 2024 · 2 comments

Comments

@0xadrii
Copy link

0xadrii commented Apr 19, 2024

[MEDIUM] - Adding collateral enabled checks for redemption collections might make users uncapable of redeming their funds.

This PR is intended to fix the bug described in this Sherlock issue. However, the Sherlock report is actually wrong and the vulnerability described must not be considered as an issue in the first place, so the collateralEnabled check should not be added on collecting redemptions.

Enabling/disabling collaterals allows the protocol to add or remove supported collaterals, not to be used under uncertain situations, such as a hack. In such type of situations, the isRedeemPaused check can be enabled to prevent users from redeeming if something wrong is currently happening.

The problem with adding the collateralEnabled check here is that if Ubiquity decides to disable a collateral in the future, some redemptions might be already queued, so users won't be able to withdraw their funds.

Recommendation: Remove the collateralEnabled check for collecting redemptions.

Originally posted by @0xadrii in #894 (comment)

@rndquu
Copy link
Member

rndquu commented Apr 19, 2024

The isRedeemPaused works pretty much the same way as collateralEnabled (one, two). So if some user requested collateral via redeemDollar() but hasn't collected it (because the protocol paused redeems) then the user also wouldn't be able to collect collateral regardless of whether the collateral is enabled or disabled.

Ideally we should remove both collateralEnabled and isRedeemPaused checks for collectRedemption() to allow users to withdraw any time. But since the protocol is in its early stage I would prefer things to be:

  1. Highly centralized
  2. With as many safety checks as possible

I understand your concerns but this issue is more about centralization risks. We'll gradually move to removing unnecessary safety checks.

I would move this issue to some metatask like "centralization risks" which would have issues like:

  1. Transfer ownership (and admin role) to multisig or governance
  2. Allow users to withdraw funds from the pool at any time

@0xadrii
Copy link
Author

0xadrii commented Apr 19, 2024

I agree with you, although from my point of view even if they work the same way they should be considered as two different mechanisms. From a security perspective, the pool will be protected by directly pausing redeems. But yes I get your point, and probably this won't be a problem for a long time until a collateral needs to be disabled , so I also agree that it could be handled as a centralization risk task and if needed then add it as a new feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants