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

OWR and OWRfactory audit fix #85

Merged
merged 12 commits into from
Oct 1, 2023
Merged

OWR and OWRfactory audit fix #85

merged 12 commits into from
Oct 1, 2023

Conversation

samparsky
Copy link
Collaborator

Fixes #79 #80

@samparsky samparsky changed the title OWR and OWRFfactory audit fix OWR and OWRfactory audit fix Sep 28, 2023
Copy link
Contributor

@OisinKyne OisinKyne left a 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);
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor

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.

@samparsky samparsky merged commit 2df88b6 into feat/audit Oct 1, 2023
1 check passed
@samparsky samparsky deleted the feat/owr-audit-fix branch October 1, 2023 09:39
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

Successfully merging this pull request may close these issues.

2 participants