-
Notifications
You must be signed in to change notification settings - Fork 16
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
OWR and OWRfactory audit fix #85
Conversation
8e0ad90
to
fa5ad33
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@@ -81,7 +81,7 @@ contract LidoSplit is Clone { | |||
if (balance > 0) splitWallet().safeTransferETH(balance); | |||
} else { | |||
balance = ERC20(token).balanceOf(address(this)); | |||
if (balance > 0) ERC20(token).transfer(splitWallet(), balance); | |||
if (balance > 0) ERC20(token).safeTransfer(splitWallet(), balance); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume splitWallet will handle ERC20 transfers properly? Is this just a good practice change or any other reason why we would add this? Also i assume if it fails, the tokens are just stuck forever and 🤷, because there's not another place to recover to?
@@ -179,9 +160,6 @@ contract OptimisticWithdrawalRecipient is Clone { | |||
function recoverFunds(address nonOWRToken, address recipient) external payable { | |||
/// checks | |||
|
|||
// revert if caller tries to recover OWRecipient token | |||
if (nonOWRToken == token()) revert InvalidTokenRecovery_OWRToken(); | |||
|
|||
// if recoveryAddress is set, recipient must match it | |||
// else, recipient must be one of the OWR recipients |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a little weird that there is subjectivity around who gets the recovered token, i.e. if you're an operator, and you see an airdrop has happened, you can rush in and recover it to the reward address, netting you X%. Whereas the beneficial owner would have swept it to the principal address, keeping 100% otherwise. Should we consider that recovery can only be to either principal or a recovery address and not (principal || reward) or recovery?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at your tests, I see that you just set principalAddress
as the recovery address sometimes. This is probably a fine workaround, and we should tell people that they should do that if they don't want principal or reward to be able to claim, but don't want to set a third recovery address. Feel free to ignore.
Fixes #79 #80