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

feat: Add minimum first deposit, refactor convert/preview functions (SC-446) #2

Merged
merged 16 commits into from
Jun 4, 2024

Conversation

lucas-manuel
Copy link
Contributor

@lucas-manuel lucas-manuel commented May 21, 2024

Share Inflation Attack Initial Approach vs. Final Approach

This PR was originally created to address the issue outlined in picture below within the contract's deposit logic. This was fully implemented in commit d32fd2f. It was subsequently removed in favor of simplifying core logic in the contract and addressing the issue in a different way - by operationally requiring an initial deposit to be made on deployment. This would fix multiple attack vectors as outlined in @hexonaut's comment.

Screenshot 2024-05-16 at 3 51 13 PM

Other Changes within PR

  • Adds test to prove that the attack vector is resolved by the initial deposit being made.
  • Adds section to README outlining attack prevention measures to be taken.
  • Also refactors to use preview functions to return rounding-accurate conversions.
  • Updates to have convertToShares and convertToAssets use generic value and asset-specific values.

Copy link

linear bot commented May 21, 2024

Copy link
Contributor

@hexonaut hexonaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've thought about it some more and to keep things simple I don't think we should include any custom logic for ensuring an initial burn amount. There are actually a lot of ways to brick the contract with an initial deposit. This current method prevents the share inflation attack, but you can also just send a non-zero balance to the contract before the first call to deposit to DoS any deposit after that as convertToShares(...) will return 0 always since psm value is > 0 and totalShares = 0.

I think instead let's just make it very clear a small seed amount should be deposited as the first action in all cases. This is what other protocols do, and I think it's easier to not go overly fancy as it introduces complexity.

For the deposit and withdraw functions let's add a receiver param and during deployment we will just deposit some initial amount and send it to the zero address.

As part of the deployment script we can include this initial deposit to force the deployer address to have a seed balance inside it's wallet.

@lucas-manuel lucas-manuel requested a review from hexonaut May 30, 2024 12:08
Copy link
Contributor

@hexonaut hexonaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good. Some requested changes.

I would also make the recommendation to burn at least 1 full unit instead of 1000 shares.

@lucas-manuel lucas-manuel requested a review from hexonaut June 3, 2024 13:50
Copy link
Contributor

@hexonaut hexonaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to merge now.

@lucas-manuel lucas-manuel merged commit 6c44569 into master Jun 4, 2024
2 checks passed
@lucas-manuel lucas-manuel deleted the add-min-first-deposit branch June 4, 2024 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants