Open code423n4 opened 2 years ago
Not an issue; we don't intend to add this complexity for the possibility of the issues mentioned arising in the future.
hairy issue when regulations are brought into the picture. It would add complexity to the code and raises additional security concerns to handle these scenarios.
downgrading to QA because there is some merit to the issue.
user's primary QA
Lines of code
https://github.com/code-423n4/2022-09-tribe/blob/769b0586b4975270b669d7d1581aa5672d6999d5/contracts/shutdown/redeem/TribeRedeemer.sol#L64-L76
Vulnerability details
Impact
Issues with future withdrawals
Proof of Concept
It is becoming increasingly common for jurisdictions throughout the world to create laws and regulations barring users from interacting with or receiving certain assets (i.e. tornado cash). TribeRedeemer.sol forces the redeeming user to receive payment as a basket of all assets. Currently there are no restrictions on assets but this contract is meant to be a permanent redemption for TRIBE and this could change during the lifetime of the contract.
Another thing to consider is that the stETH is an upgradeable ERC20 token. Currently it does not have a blacklist function but one could easily be implemented. This would open the possibility that TribeRedeemer could be blacklisted, blocking all interactions with stETH. In a situation like this, the contract would be inoperable and all funds in the contract would be permanently lost because the transfer of the blacklisted asset would always fail.
Tools Used
Recommended Mitigation Steps
When redeeming their tribe, users should have the option to op out of receiving certain assets. Additionally the contract could be left under the control of the Tribe DAO to deal with a situation like this should it arise.