Fork System#1042
Open
funderbrker wants to merge 70 commits into
Open
Conversation
Closed
funderbrker
force-pushed
the
transmission
branch
from
4bf1ecf to
5ef5ba8
Compare
✅ Deploy Preview for basin ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for beanstalk-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…Beanstalk into transmission-bytes-array
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fork System
The Fork System enables an opt-in/out system of upgrading and migration of any Diamond Contract to another compatible Diamond Contract. Anyone, including Beanstalk Farms, can implement descendant forks that allow users to opt into the upgrade by migrating existing parent assets into the child.
RFC
#1036
Design of Destination
A source fork has no knowledge of child forks, however each child fork must specifically whitelist and implement logic for the parent forks it will support. This implementation demonstrates one way that a child fork could be designed to accept migrated assets, however, it is not the only way it can be done. Each child fork is responsible for deciding how to mint assets for migrating users. The possible design space is infinite and is not fully captured by this PR, however destination logic modifications should fit inside of the standardized interfaces demonstrated in this PR.
Implementation notes
Although a decent amount of tech debt had to be addressed throughout the codebase while implementing this system, the core of the changes can be found in
TransmitOutFacet.solLibTransmitOut.solTransmitInFacet.solLibTransmitIn.solTransmitToFork.t.sol