-
Notifications
You must be signed in to change notification settings - Fork 83
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
Secure Beanstalk Invariants #821
Conversation
95752fd
to
9b539f6
Compare
Should depot facet have the noSupplyChange invariant? Currently yes bc its use is intended to be moving control from from Beanstalk to external. Sequences of Beanstalk actions should be achieved using external pipeline or Farm/AdvancedFarm. |
omw to implement some sort of tests... |
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.
Review I. Overall looking on the right track!
e5b4fdf
to
385b9c9
Compare
385b9c9
to
a38a8e2
Compare
This PR implements 3 invariants
fundsSafu
Ensures that Beanstalk contract holds enough assets to pay all users all of their expected existing funds.
This invariant applies to every writing function in Beanstalk. There are a few exceptions in the Diamond system.
noNetFlow
Verifies that no assets have entered or exited Beanstalk during the function execution and that Stalk has not decrease (which should never happen without some underlying asset changes). This applies to the majority of writing functions, excepting functions that are explicitly converting or transferring assets into or out of Beanstalk on behalf of a user. Also excepting diamond features.
noSupplyChange
Verifies that the supply of Bean has not changed during execution. ie there has been no minting or burning. This applies to vast majority of writing functions, excepting the functions that explicitly mint or burn (like sunrise or sow). Also excludes diamond features.
The set of assets checked in these invariants is the list of Silo assets at the beginning of the call. Currently, this includes Beans and LP tokens. The value underlying the LP cannot and should not be verified inside of Beanstalk. The list of covered tokens can be expanded to a known set, but should not be an infinitely scaling set of n possible internal ERC20s.