RFC: Fork Migration System

[funderbrker]

Authors

funderbrker, Ben Weintraub, Brendan Sanderson, Beanstalk Farms

Summary

Implement a Fork Migration System that allows Farmers to migrate assets from one or more Beanstalks (Source Beanstalks) to another (a Destination Beanstalk) under conditions defined by the Destination Beanstalk.

Context

Forks and upgrades both allow protocols to be modified:

• Upgrades: Occurs when there is some native mechanism in the software that allows the rules of the existing instantiation of the system to be changed. As there is still only 1 instance of the system, participants are forced into the upgrade.
• Forks: Occurs when a set of participants decide to change the rules of the protocol such that a new instance of the system is created. Each participant has the option to keep using the old system or switch to the new one.

Forks give participants complete agency while upgrades minimize fragmentation.

A powerful property of governance in networks like Bitcoin and Ethereum is that there is a guarantee that the rules of the system will not change without participants opting into the changes. Bitcoin miners who did not update their software to Bitcoin Cash remained on Bitcoin. Ethereum nodes that did not update their software to facilitate the fork that reorganized Ethereum post-DAO hack remained on ETH Classic. When juxtaposed against smart contract upgrades, where the rules can be changed for participants who did not opt into it, social consensus seems preferable for a base money.

Furthermore, because smart contracts do not have a strong relationship with network validators, it is harder for smart contracts to coordinate a reorganization via social consensus in the instance of a flaw (e.g., Ethereum did not reorganize post-Beanstalk exploit). Therefore, even though there is friction in the form of lost network effects, it seems the optimal governance model for smart contracts is to make them non-upgradable and to make migrating to future implementations (or forks) as frictionless as possible such that there can be a Lindy effect around safe implementations to use without slowing down innovation.

While this solution likely creates more overhead for developers to support backward compatibility, it also provides more similar properties for users of smart contracts as it does for users of systems based on social consensus.

Problem

Centralized Governance

Since the April 2022 governance exploit, Beanstalk governance has been off-chain. In addition to being fundamentally misaligned with the ethos of Beanstalk, off-chain governance has numerous censorship risks.

Counting Votes

It is unclear how to count votes in the fairest way possible. Because of the ability to use infinite addresses, without a unique identity system there is no way to ensure that each participant only votes once.

Therefore, the only viable option for voting in smart contract-based governance for contracts with value stored in them is for the weights in participation in governance to be value-based in some capacity (e.g., the Stalk System). While the Stalk System is designed to dampen the effect of participants with more value in the system, it's imperfect with respect to ownership concentration.

There do not seem to be constructions of on-chain voting systems that are battle-tested with significant value in them.

DAO Doubt

The main problem with a DAO-based system is that it allows the majority to force changes (or a lack of changes) on the minority. Over the past year, there have been multiple BIPs that have proposed major model improvements. These proposed improvements received near unanimous approval amongst active community members, yet failed to pass when it came time for the DAO to vote due to a lack of participation. Given the fact that Beanstalk is far from optimal in terms of its current design and parameters, the inability to pass BIPs presents an existential threat to Beanstalk and a major problem for each participant.

Forks

Currently, there is significant friction involved in migrating assets from one Beanstalk to another version of Beanstalk. Without a standard interface and system for migrations between forks, any Destination Beanstalk that would like to accept migrations would have to implement a bespoke solution based on approving the Destination Beanstalk to spend Farmer's Source Beanstalk assets.

Solution

The Fork Migration System allows Farmers to migrate assets from one or more Source Beanstalks to a Destination Beanstalk under conditions defined by the Destination Beanstalk.

The following assets can be migrated by burning them on the Source Beanstalk and minting them on the Destination Beanstalk:

• Bean Deposits;
• LP Deposits that are whitelisted on the Destination Beanstalk;
• Whitelisted assets outside of the Silo;
• Fertilizer; and
• Plots.

It remains unclear how to allow Unripe Deposit migrations in a way that remains fair to the Source Beanstalk given the discrepancy between the liquidatable (Choppable) value of and the underlying value of Unripe assets. Because of this the Fork Migration System does not support migrations of Unripe Deposits.

Any Destination Beanstalk can implement arbitrary logic to determine under what conditions it will accept migrations from a Source Beanstalk. For example:

• Below a particular L2SR on the Destination Beanstalk, only accept LP Deposit migrations,
• Above a particular Pod Rate on the Destination Beanstalk, do not accept Plot migrations,
• Only let Source Beans migrate to Destination Beans at a rate according to the USD price of Source Beans,
• Allow Deposits to migrate with no loss of Grown Stalk, etc.

Specification

Every instance of Beanstalk with the Fork Migration System implemented has facets to migrate assets into and out of itself. The migration interfaces are standardized in a generalized fashion such that any altered implemenation of Beanstalk can be supported. The interfaces necessary to enable standardized migration of assets between forks are shown below.

interface ITransmitOutFacet {
    function transmitOut(
        address destination,
        LibTransmitOut.SourceDeposit[] calldata sourceDeposits,
        LibTransmitOut.SourcePlot[] calldata sourcePlots,
        LibTransmitOut.SourceFertilizer[] calldata sourceFertilizer,
        bytes calldata data
    ) external;
}

interface ITransmitInFacet {
    function transmitIn(
        address user,
        bytes[] calldata deposits,
        bytes[] calldata plots,
        bytes[] calldata fertilizer,
        bytes calldata data
    ) external;
}

When a Farmer decides to opt-in to a Destination Beanstalk they call transmitOut with the desired assets. The assets will be burnt on the Source Beanstalk, the definitions will be transmitted to the Destination Beanstalk using transmitIn and the Destination Beanstalk will mint new assets based on its particular specfication.

A Source Beanstalk has no knowledge of which Destination Beanstalks may exist after it, however, the Destination must define all acceptable Source Beanstalks at deployment time. Destination Beanstalks can set arbitrary rules on what assets to accept and how to reward the migration of those assets.