BIP-50: Reseed Beanstalk

Proposed: October 1, 2024

Status: Passed

Link: Snapshot

Note: During the BIP-50 vote, it was noticed that the L2 TokenFacet proposed to be added to the L2 Beanstalk referenced the L1 WETH contract address instead of the Arbitrum WETH contract address. The L2 TokenFacet was redeployed at 0xf8B5Fa117f492608b8f16AAE84C69175ead6A38d using the correct WETH contract address.

BIP-50 stated that PauseFacet was left on the L1 mainnet. It was removed.

BIP-50 listed InternalBalanceChanged as a modified event. It was unchanged.

BIP-50 incorrectly listed UpdatedSeedGaugeSettings as a new event. The correct event name is UpdatedEvaluationParameters.

The text below represents BIP-50 as voted upon, without corrections.

• Proposer
• Summary
• Links
• Problem
• Proposed Solution
• Technical Rationale
• Economic Rationale
• Contract Changes
• Beans Minted
• Audit
• Effective
• Appendix

Proposer

Beanstalk Farms, Ben Weintraub, Brendan Sanderson

Proposer Wallet: 0xf9d183af486a973b7921ceb5fdc9908d12aab440

Summary

1. Upgrade Beanstalk to include the following major features:
   • Secure Beanstalk, which implements function modifiers that maintain protocol wide invariants and adds them to most write functions in Beanstalk;
   • Generalized Convert, which introduces a new Convert function that uses Pipeline to Convert a set of arbitrary (non-Unripe) Deposits to 1 Deposit (including LP → LP Converts);
   • Generalized Flood, which implements Flood in a generalized fashion such that Flood can occur in multiple Wells at once;
   • Shipments, which introduces a generalized system for allocating new Bean mints to various components of Beanstalk; and
   • Tractor, which is a peer-to-peer transaction marketplace that allows third party operators to perform Beanstalk actions on behalf of a Farmer;
2. Upgrade Beanstalk to include the following various quality of life improvements:
   • Upgrade the Solidity version from v0.7.6 to v0.8.20;
   • Implement a generalized whitelist system that supports custom oracles, Gauge Point functions and Liquidity Weight functions that do not require a diamond cut to change for a given whitelisted asset;
     • Implement a generalized Chainlink oracle system such that a Well that has a non-Bean asset whose USD price can be queried via Chainlink can be whitelisted without a diamond cut;
     • Implement a generalized Uniswap V3 oracle system such that a Well that has a non-Bean asset whose price can be queried via Uniswap V3 can be whitelisted without a diamond cut, provided that the other token in the oracle pool has a Chainlink feed (e.g., WBTC/USDC on Uniswap V3 * USDC/USD Chainlink feed);
   • Change the control variable in the Morning Auction from 2 to 0.1 to slow down the increase in the Temperature;
   • Update the default Gauge Point function (used by all whitelisted LP tokens) to adjust the Gauge Points more aggressively the farther away the current % BDV distribution is away from optimal;
   • Update the Bean to Max LP Ratio to its minimum value upon Rain;
   • Add several view functions for getting Farmer's balances;
   • Redesign App Storage to improve developer experience and future proof new additions to contract storage;
   • Move several constants that have the potential to change into contract state;
   • Redesign reentrancy protection to support Pipeline and Depot;
   • Increase Stalk decimal precision by 1e6 to prevent micro Stalk from being lost;
   • Add a TokenTransferred event with data on sender and receiver addresses of Farm balance transfers;
3. Migrate Beanstalk from Ethereum mainnet to Arbitrum:
   • Pause Beanstalk on L1 mainnet;
   • Remove all L1 facets except for the DiamondCutFacet, DiamondLoupeFacet, OwnershipFacet and PauseFacet;
   • Upgrade L1 Beanstalk with a new TokenFacet and L2MigrationFacet that allows Circulating Beans to be migrated to L2;
   • Run initialization scripts that transfer whitelisted LP tokens from Beanstalk to the L1 BCM to be unwrapped and bridged to L2 BCM (BEAN:3CRV is migrated to BEAN:USDC on Arbitrum);
   • Deploy L2 Beanstalk;
   • Update L2 Beanstalk with the L1 state;
   • Deploy, add liquidity to and whitelist the following Wells (see Proposed Solution for details):
     • BEAN:USDC;
     • BEAN:USDT;
     • BEAN:WBTC;
     • BEAN:wstETH;
     • BEAN:WETH; and
     • BEAN:weETH;
   • Add all facets that include the upgrades described above (excluding FundraiserFacet, LegacyClaimWithdrawalFacet, CurveFacet and MigrationFacet) to L2 Beanstalk; and
   • Unpause L2 Beanstalk.
4. Update various processes and documentation such as Hypernative, Immunefi and the Disclosures to reflect the new state of Beanstalk.

Links

• BIP-50 GitHub PR
• GitHub Commit Hash: faa0ec60a455b0afdd20ad86f28f41cbc52c2e2d
• Safe Transaction

Problem

Secure Beanstalk

Since Replant in August 2022, there have been 5 bugs that could have led to a loss of funds (fixed in EBIPs 1, 4, 5 (only Circulating assets were at risk), 10 and 12). In particular, the bugs that were mitigated in EBIPs 1, 10 and 12 could have led to losses of nearly all value in the Beanstalk contract.

Since the creation of the Immunefi Bug Bounty Program in BIP-26, the DAO has paid 1,530,350 Beans in bounties, 1,322,100 of which was for bug reports concerning funds in the Beanstalk contract that were at risk.

Generalized Convert

The effectiveness of the LP component of the Seed Gauge System is highly limited due to excessive friction between LP Converts. Currently, in order to Convert LP → LP, the source pool(s) must have negative deltaBs and the destination pool must have a positive deltaB (effectively a Pipeline LP → BEAN → LP Conversion). This is both inefficient from a gas perspective and limiting for Farmers' choices given that the effect from a peg maintenance perspective is neutral.

Generalized Flood

Currently, Flood is only implemented to take place in a single Well. The effectiveness of Flood is substantially decreased with the introduction of several whitelisted Wells.

Shipments

Currently, the distribution of Bean mints (allocated to the Silo, Field and Barn) is not sufficiently generalized such that it can be upgraded by changing parameters (i.e., facet changes are required).

Tractor

Maintaining and optimizing a position in Beanstalk requires manual intervention (Mowing, Planting, Harvesting Pods and Depositing the Beans, etc.). Smaller Farmers do not necessarily have the resources to automate the execution of their Beanstalk transactions.

Existing peer-to-peer transaction marketplaces (such as Seaport) are limited in the scope of the functionality that they support. Existing generalized function call systems (i.e., smart contract accounts, Depot + Pipeline) only support the use of assets from the sender of the transaction.

QoL Improvements

Solidity Version v0.8.20

As a result of Beanstalk using Solidity v0.7.6, many QoL tools are not available to the Beanstalk development community, such as:

• Using additional methods provided in EIP-1559;
• Naming variables from mappings;
• Using SafeMath by default (leading to overflow); and
• Using Foundry without bespoke fixes.

Whitehats and auditors are generally more familiar with Solidity v0.8.0 and higher.

Whitelist Upgrades

Whitelisting a Well requires new code changes to the Beanstalk contracts, which increases the friction associated with whitelisting a Well (via audits, etc.). Ideally, the DAO can whitelist a Well in the Silo without any facet changes.

Morning Auction Adjustment

Currently, the Temperature increases excessively fast in the first few blocks of the Morning. For example, Soil can never be purchased at a Temperature below ~27% of the Maximum Temperature given the current parameters.

New Default Gauge Point Function

Currently, the default Gauge Point function increments or decrements the Gauge Points for each whitelisted LP token by 1 based on whether the current BDV distribution for the LP token is greater than or less than the optimal BDV distribution. Given the maximum and minimum Gauge Point values of 1000 and 0, respectively, it can take up to 20 days ((1000/2) Gauge Points / 24 Seasons ~= 20.833 days) for the Gauge Points to "catch up" such that the Seed rewards reflect the new current vs. optimal distribution.

For example: BEANwstETH and BEANETH currently have 1000 and 0 Gauge Points, respectively. If sufficient amounts of BEANETH Converts to BEANwstETH such that the current distribution of BEANwstETH is higher than optimal, Beanstalk will keep rewarding more Seeds to BEANwstETH than BEANETH for ~20 days even though it is no longer necessary.

Minimum Bean to Max LP Ratio Upon Rain

Currently, it's possible for Beanstalk to Flood before the Bean to Max LP Ratio has reached its minimum value, i.e., before Beanstalk has created the maximum incentive for Converting downwards.

Technical Improvements

Some Farmer balances can only be calculated by indexing events since Beanstalk deployment, resulting in either (1) thousands of calls to RPC providers each time the Beanstalk UI loads (which often gets rate limited), or (2) reliance on infrastructure like the subgraphs. Both have historically resulted in downtime for Farmers trying to view their balances.

Beanstalk currently has a number of variables set as constants in order to save gas. This increases the friction of upgrading Beanstalk by needing to redeploy the facets with only constants changed.

The current App Storage structure is difficult to extend and develop with.

Currently, Beanstalk's reentrancy protection system does not support Pipeline and Depot.

Micro Stalk can sometimes be lost during certain Silo interactions due to the current Stalk precision relative to the Seed precision. This introduced a rounding error where users had slightly less Stalk than the amount needed to Withdraw.

Within Beanstalk, Farmers can transfer assets to and from their Circulating and Farm balances. When a Farmer transfers an asset from their Farm Balance to another address' Farm Balance, the emitted events make it difficult to trace the origin of the assets.

L2 Migration to Arbitrum

Beanstalk is a gaseous protocol. While the costs of interacting with Beanstalk at the time of writing in September 2024 are reasonable, activity on Ethereum L1 is currently low. In the past when Gwei has spiked, interacting with Beanstalk has cost tens or hundreds of US dollars. This prices out smaller Farmers and reduces the efficacy of Beanstalk's peg maintenance mechanism.

Upgrades like Secure Beanstalk, the new view functions, etc. increase the cost of interacting with Beanstalk across the board.

New Whitelist

Opportunities for Bean liquidity providers to receive Stalk and Seed rewards are currently limited. A wider variety of options increases utility for Silo Depositors, particularly with the combination of the Seed Gauge System and Generalized Convert.

Process Updates

Hypernative, the Immunefi Bug Bounty Program and the Beanstalk DAO Disclosures can all be updated to reflect the new state of Beanstalk.

Proposed Solution

Secure Beanstalk

We propose the implementation of system-wide invariants that are checked on every write call to Beanstalk. The invariants are indicative of a healthy state of Beanstalk's internal accounting and must always be maintained. These invariants ensure that the Beanstalk contract contains enough assets to cover all of its user obligations, ERC-20s are not being transferred unexpectedly and that the Bean supply is not being manipulated.

The Invariable contract defines several invariant modifiers that are used across the code base.

Specification

The invariants fall into three different categories:

1. ERC-20 balance checking

The fundsSafu modifier checks every whitelisted ERC-20 token. If the balance of the token in the Beanstalk contract is lower than the amount of the token that users can claim (through Withdrawals, Harvests, Claims, etc) then the invariant will fail and the call will revert. This ensures there are always enough tokens in the contract for Beanstalk to pay its existing obligations. Excluding diamond management functions, this invariant can be placed on every write function in Beanstalk.

2. Asset movement limitations

The noNetFlow, noOutFlow, and oneOutFlow invariants track the balance of ERC-20 tokens inside Beanstalk and fail if there is an unexpected movement of assets. This ensures that there are not any withdrawals of unexpected assets in the modified functions, however, it does not set any limits on the amounts withdrawn. noNetFlow requires that Beanstalk token balances are the same at the end of the call as they were at the beginning, noOutFlow requires that all Beanstalk token balances are the same or higher at the end of the call and oneOutFlow allows for only one asset to decrease in amount during the call. These three modifiers cover the vast majority of use cases and one of the three can be put on almost every write function in Beanstalk. Notable exceptions are diamond management, Convert and farm-like functions.

3. Bean supply control

The noSupplyChange and noSupplyIncrease invariants keep track of the total supply of Bean at the beginning and end of the call to ensure that the Bean supply was not unexpectedly modified. noSupplyChange prevents both minting and burning, whereas noSupplyIncrease only prevents minting. One of these two modifiers can be placed on every write function in Beanstalk that is not intentionally minting or burning Beans (such as Sowing and gm). Notable exceptions are diamond management and farm-like functions.

We also propose to remove various dead code such as the Pod Market V2 pricing functions.

Generalized Convert

We propose a Generalized Convert implementation with support for LP → LP Converts, a Stalk penalty system to enable Converting against peg and a per-block Convert cap mechanism to protect against flash loan attacks.

The PipelineConvertFacet exposes the new pipelineConvert function and Stalk penalty logic has been applied to the existing ConvertFacet. The existing ConvertFacet retains support for Unripe Converts, which are not supported by the new PipelineConvertFacet.

Specification

The Pipeline Convert function is defined as:

    function pipelineConvert(
            address inputToken,
            int96[] calldata stems,
            uint256[] calldata amounts,
            address outputToken,
            AdvancedPipeCall[] memory advancedPipeCalls
        )
            external
            payable
            fundsSafu
            nonReentrantFarm
            returns (int96 toStem, uint256 fromAmount, uint256 toAmount, uint256 fromBdv, uint256 toBdv);
    

Usage of the first four parameters is the same as the existing convert function (specify the input crates using the Deposited Stem and amounts, as well as the input and output tokens to Convert from and to). The advancedPipeCalls parameter is new.

The pipelineConvert function withdraws the corresponding whitelisted tokens from Beanstalk and passes them to the Pipeline contract. The supplied Pipeline calls should call other contracts to swap (the total input token amount available to swap can be calculated by summating all the amounts passed in via amounts).

Example Pipeline Calls for Convert

A typical series of Pipeline calls might follow these steps (using Solidity):

1. Approve spending the ERC20 token:

   bytes memory approveEncoded = abi.encodeWithSelector(
        IERC20.approve.selector,
        TARGET_ADDRESS,
        MAX_UINT256
       );
       

   The previous user of the Pipeline contract may not have setup an approval for spending the input token used to Convert, so an approval call verifies the ERC-20 can be sent to the TARGET_ADDRESS (in some cases, perhaps a Well).

2. Perform the swap:

   bytes memory addLiquidityEncoded = abi.encodeWithSelector(
        IWell.addLiquidity.selector,
        tokenAmountsIn, // tokenAmountsIn
        minAmountOut, // min out (should not be left as zero, or the Convert can be frontrun)
        PIPELINE, // recipient
        type(uint256).max // deadline
       );
       

This example adds liquidity to a Well (assuming this is a Bean → Well convert). Note that this action is performed from the Pipeline contract itself, and thus, the recipient is the Pipeline contract. The swap call does not have to use Wells—other DEXs (Uniswap, Curve, etc) or aggregators (0x, 1inch, etc) can be used.

The above encoded calls are then wrapped in AdvancedPipeCall so that the target contract and Clipboard data can be specified. The final array of these calls are inserted into the Convert function. Note these calls may want to check available Convert capacity first if a MEV protection RPC is not used (see Convert Capacity below).

After the final Pipeline call is performed, the pipelineConvert function calls the ERC-20 balanceOf function on the Pipeline contract and removes all of the ERC20 token of the outputToken type. Any other ERC-20's remaining in Pipeline after the Convert must be removed by the user.

Stalk Penalty

Generalized Convert introduces the ability to Convert against peg and a Stalk penalty for doing so. The penalty applies a 100% reduction in Grown Stalk of the Converted Deposit based on the amount that was Converted against peg.

For example, if 20 BDV is Converted, and only 10 of the BDV Converted is against peg, then 50% of the Grown Stalk associated with Deposit will be burned. No penalty is applied if the Convert brings the cumulative deltaB closer to 0.

Convert Capacity

To prevent flash loan attacks that allow Converting against peg without incurring the Stalk penalty, a Convert capacity mechanism is introduced.

Every Convert updates the amount of BDV Converted per block on a per Well and overall basis. The total capacity available before a penalty applies is based on deltaB for each corresponding Well and the overall deltaB.

View functions are exposed to read the remaining capacity for a block in order to ensure that the Pipeline function can revert if conditions become unfavorable to the user over the course of the block.

Convert Capacity View Functions

Two functions are available to view available Convert capacity for the block, the first being the overall capacity remaining:

function getOverallConvertCapacity() external view returns (uint256);
    

And the second being the capacity available on a per Well basis:

function getWellConvertCapacity(address well) external view returns (uint256);
    

If the available Convert capacity of either is less than the BDV of the amount being Converted, then the Stalk penalty will apply.

Generalized Flood

We propose a Generalized Flood implementation that supports Flooding in the highest deltaB Wells until the cumulative deltaB is 0.

While previously the entire Pod Line became Harvestable upon Flood, we propose that only 0.1% of the Bean supply worth of Pods become Harvestable.

Shipments

We propose a dynamic system for distributing Bean mints to the different outputs within the system—the Silo, Field and Barn. The system is sufficiently generalized such that it can change between different configurations without requiring contract changes. It can support multiple Fields and is expandable to handle unknown output types that can be implemented in future upgrades.

Specification

Each distribution stream for new Bean mints is defined by two different structures: a ShipmentRoute and a ShipmentPlan.

Shipment Routes define where a portion of the Bean mints will be sent to and how the associated Plan is retrieved. The Routes are stored in Beanstalk state. They can be modified via owner-restricted write functions. The Route contains an enum indicating which output stream the mints are associated with—the Silo, Field or Barn. Implementation of streams that do not fall into these categories require modification to the Beanstalk contracts.

struct ShipmentRoute {
        address planContract;
        bytes4 planSelector;
        ShipmentRecipient recipient;
        bytes data;
    }
    

Shipment Plans specify the ratio and the maximum Beans that a Route can receive for the current mint. This configuration is dynamic, based on current state and arbitrary logic. Shipment Plans are retrieved by calling standardized Plan getter functions. The functions can live internal or external to Beanstalk. Externalizing these functions allows for them to be updated without modifying Beanstalk contracts.

struct ShipmentPlan {
        uint256 points;
        uint256 cap;
    }
    

Each Plan assigns points to its associated route. The Route receives the ratio of minted Beans equal to the ratio of Route points / all points. In this way, there are not circular dependencies for each Plan to know about the other Plans.

If Beans to a route exceed the maximum Beans that Route can handle the excess Beans will be distributed to the other routes, in proportion to their points. The Silo Route should never have a cap.

Both Shipment Routes and Plans can be updated via the setShipmentRoutes function, in conjunction with an external contract that contains the associated Shipment Plan getters.

Tractor

We propose Tractor, a peer-to-peer transaction marketplace that allows third party operators to perform Beanstalk actions on behalf of a Farmer.

Blueprints are off-chain data structures that are EIP-712 signed to verify the intent of the publishing Farmer. Blueprints allow Farmers to define arbitrary sequences of on-chain function calls, which can be executed permissionlessly by other Farmers known as Tractor Operators.

Blueprints contain the Publisher, an Advanced Farm function call containing an arbitrary sequence of internal function calls, a set of copy instructions that define how to interpret Operator calldata, expiry parameters and the EIP-712 signature from the Publisher. Any Tractor Operator can execute any Blueprint with any calldata at anytime through the tractor(...) function provided that the Blueprint does not revert.

Junctions are contracts that are contain basic operations as external functions that are used by Tractor orders. Junctions allow Farmers to define Blueprints that will fail under a predefined set of conditions, such as balance limits, price thresholds, etc.

Examples

• A Farmer creates a Blueprint for an Operator to Plant on their behalf any time they have more than 100 Earned Beans and will pay the caller 1 Earned Bean.
• A Farmer creates a Blueprint for an Operator to Mow on their behalf any time that P > 1 and will pay the caller 5 USDC.

Specification

Blueprints

Blueprints are off-chain data structures that are EIP-712 signed to verify Publisher intent. Each Blueprint contains an arbitrary sequence of internal and external function calls wrapped into an AdvancedFarm call and to be executed through the TractorFacet. Any properly signed Blueprint can be executed through Tractor given that:

1. startTime < block.timestamp < endTime;
2. blueprintNonce[nonce] < maxNonce; and
3. The advancedFarm function call does not revert (Publishers can encode logic checks that revert under arbitrary conditions).

Blueprints are defined by the following struct:

struct Blueprint {
        address publisher;
        bytes data;
        bytes32[] operatorPasteInstrs;
        uint256 maxNonce;
        uint256 startTime;
        uint256 endTime;
    }
    

Blueprints are wrapped in a Requisition, which contains the Blueprint hash and the Publisher's signature of the hash.

struct Requisition {
        Blueprint blueprint;
        bytes32 blueprintHash;
        bytes signature;
    }
    

Where:

1. publisher is the account that published the Blueprint;
2. data is bytes that decode into (AdvancedFarmCall[]);
3. operatorPasteInstrs are a set of instructions that define how operator-defiend data is injected into the AdvancedFarmCalls of the data;
4. maxNonce is the maximum # of times a Blueprint can be executed;
5. startTime is the timestamp at which the Blueprint can start to be executed;
6. endTime is the timestamp at which the Blueprint can no longer be executed;
7. blueprintHash is the keccak256 hash of the populated Blueprint struct; and
8. signature is the Publisher's EIP-712 signature of the Blueprint Hash.

Blueprint Hash

Blueprint Hashes are unique identifiers for Blueprints. Blueprint Hashes are used to track the nonce of a Blueprint and used in the signing process. A Blueprint Hash must be hashed following the EIP-712 standard. Beanstalk provides a public helper function getBlueprintHash(Blueprint blueprint).

Publish Blueprint

Requisitions do not need to be written on-chain. They can be provided to operators off-chain and verified via the signature. However, Tractor offers a system to publicly publish any Requisition via the PublishRequisition function, which emits an event containing the Requisition.

function publishRequisition(LibTractor.Requisition calldata requisition) external;
    
    event PublishRequisition(LibTractor.Requisition requisition);
    

Cancel Blueprint

Blueprints can be canceled at anytime by the Blueprint Publisher by calling cancelBlueprint. This sets the nonce to uint256.max, rendering the Blueprint unusable.

function cancelBlueprint(LibTractor.Requisition calldata requisition) external;
    
    event CancelBlueprint(bytes32 blueprintHash);
    

Tractor

function tractor(LibTractor.Requisition calldata requisition, bytes memory operatorData) external returns (bytes[] memory results);
    
    event Tractor(address indexed operator, bytes32 blueprintHash);
    

Tractor executes a Blueprint. Executing a Blueprint:

1. Verifies the Blueprint signature is correct;
2. Checks startTime < block.timestamp < endTime;
3. Checks blueprintNonce[blueprintHash] < maxNonce;
4. Increments blueprintNonce[blueprintHash];
5. Modifies blueprint.data using the operatorPasteInstrs and operatorData;
6. Executes advancedFarm using data; and
7. Emits a Tractor event.

Tractor Storage

Instead of adding new state variables to AppStorage, a TractorStorage library is created where TractorStorage is loaded at slot keccak256("diamond.storage.tractor") (stored as a constant).

struct TractorStorage {
        mapping(bytes32 => uint256) blueprintNonce;
        mapping(address => mapping(bytes32 => uint256)) blueprintCounters;
        address activePublisher;
    }
    

Tractor Counters

Blueprints can utilize arbitrary counters to track and limit use. These are stored in TractorStorage and writes are restricted based on the Publisher's address. Blueprints using counters are expected to generate sufficiently random counter IDs to avoid collisions with a Publisher's other counters.

Active Publisher

Tractor performs actions on behalf of the Publisher of a Blueprint that that is executed by Tractor. Rather than using msg.sender to determine the account to act on, the active Publisher address is used.

QoL Improvements

Solidity Version v0.8.20

We propose to upgrade each contract and facet in Beanstalk from v0.7.6 to v0.8.20.

Whitelist Upgrades

We propose to upgrade the whitelisting system such that various Implementations can be set and changed for each Well. Implementations can be used to the set a Well's:

• Gauge Point function selector;
• Liquidity Weight function selector; and
• Oracle implementation for calculating the value of the non-Bean token in the Well.

In order for a whitelisted Well to be included in the Minting Whitelist, the Gauge System and Converts, the non-Bean token in the Well must have an Oracle Implementation. Whitelisted Wells without a Gauge Point or Liquidity Weight Implementation use the default Gauge Point and Liquidity Weight Implementation defined in GaugePointFacet and LiquidityWeightFacet, respectively.

An Implementation is defined in App Storage as:

struct Implementation {
        address target;
        bytes4 selector;
        bytes1 encodeType;
        bytes data;
    }
    

Where:

• target is the the address in which selector is called at;
• selector is the function selector Beanstalk is calling at address;
• encodeType determines the function signature Beanstalk should call at the address; and
• data is arbitrary data that can be added to a function call.

For a given Gauge Point Implementation, the function should match the following signature:

function gaugePointFunction(
        uint256 currentGaugePoints,
        uint256 optimalPercentDepositedBdv,
        uint256 percentOfDepositedBdv,
        bytes memory
    )
    

For a given Liquidity Weight Implementation, the function should match the following signature:

function liquidityWeight(bytes)
    

For a given Oracle Implementation, the function should match the following signature:

function oracle(
        uint256 tokenDecimals
        uint256 lookback
        byte memory data
    )
    

Gauge Point and Liquidity Weight Implementations are set per whitelisted Well. Oracle Implementations are set on a token basis.

Beanstalk has 2 default Oracle Implementations, which are used when the whitelisted Well is whitelisted with an oracle encodeType of 0x01 and 0x02:

• 0x01 → Chainlink Implementation; and
• 0x02 → Uniswap and Chainlink Implementation.

To use the 0x01 default Implementation, the Oracle Implementation address for the non-Bean token in the Well should be set to the Chainlink aggregator that the price should be fetched from. The Oracle Implementation should return the USD price of the non-Bean token.

To use the 0x02 default Implementation:

• The Oracle Implementation address for the non-Bean token in the Well should be set to the address of the Uniswap V3 pool that the price should be fetched from; and
• The Oracle Implementation address for the other token in the Uniswap V3 pool should be set to the Chainlink aggregator that the price should be fetched from.

For example, for a BEAN:WBTC Well, the 0x02 default Oracle Implementation could be used by combining the WBTC:USDC Uniswap V3 pool with the USDC:USD Chainlink aggregator.

Additional support for different function signatures can be accomplished by implementing new code for a given encode type.

Morning Auction Adjustment

We propose to change the control variable in the Morning Auction from 2 to 0.1.

More specifically, change the calculation for the Temperature during blocks 1 to 25 (x) of each Season from (the blue line):

To the following (the red line):

See Desmos link.

Due to the L2 Migration, in practice the Temperature only updates L1_BLOCK_TIME / L2_BLOCK_TIME = 12/0.25 = 48 times. The duration of the Morning is still 5 minutes. Thus, on Arbitrum, the Temperature during the first 1200 blocks of each Season is calculated as:

New Default Gauge Point Function

We propose to update the default Gauge Point function to change the Gauge Points for the whitelisted LP token by ±5/3/1 based on the following thresholds:

• Extremely Far below optimal:
  • current % < (optimal % (100% - 66%)) → *+5 Gauge Points
• Relatively Far below optimal:
  • (optimal % (100% - 66%)) < current % < (optimal % (100% - 33%)) → +3 Gauge Points
• Relatively Close below optimal:
  • (optimal % (100% - 33%)) < current % < optimal % → *+1 Gauge Point
• Relatively Close above optimal
  • optimal % < current % < (optimal % + (100% - optimal %) 33%) → *-1 Gauge Point
  • -1 Gauge Point
• Relatively Far above optimal:
  • (optimal % + (100% - optimal %) 33%) < current % < (optimal % + (100% - optimal %) 66%) → -3 Gauge Points
• Extremely Far above optimal:
  • (optimal % + (100% - optimal %) 66%) < current % → *-5 Gauge Points

For example, if BEANETH's optimal % is 16%, the thresholds are:

• Extremely Far below optimal: current % < 5.44%
• Relatively Far below optimal: 5.44% < current % < 10.72%
• Relatively Close below optimal: 10.72% < current % < 16%
• Relatively Close above optimal: 16% < current % < 43.72%
• Relatively Far above optimal: 43.72% < current % < 71.44%
• Extremely Far above optimal: 71.44% < current %

Minimum Bean to Max LP Ratio Upon Oversaturation

We propose to change beanToMaxLpGpPerBdvRatio to the minimum value upon Rain (i.e., at startRain).

Technical Improvements

View Functions

Beanstalk now stores the list of Deposit IDs and Plot indexes on each account, as well as a mapping from Deposit ID to its associated index to support a O(1) read cost.

struct DepositListData {
        uint256[] depositIds;
        mapping(uint256 => uint256) idIndex;
    }
    
    ...
    
    uint256[] plotIndexes;
    mapping(uint256 => uint256) piIndex;
    

The list of Deposit IDs are stored on a per token basis.

Deposit data can be fetched using the following functions:

• getDepositsForAccount;
• getTokenDepositsForAccount;
• getTokenDepositIdsForAccount; and
• getIndexForDepositId.

Plot data can be fetched using the following functions:

• getPlotIndexesFromAccount;
• getPlotsFromAccount; and
• balanceOfPods.

Constants to State

We propose to migrate various parameters that were previously set to constants to be read from contract state. This is stored in the system storage as EvalutationParameters like so:

struct EvaluationParameters {
        uint256 maxBeanMaxLpGpPerBdvRatio;
        uint256 minBeanMaxLpGpPerBdvRatio;
        uint256 targetSeasonsToCatchUp;
        uint256 podRateLowerBound;
        uint256 podRateOptimal;
        uint256 podRateUpperBound;
        uint256 deltaPodDemandLowerBound;
        uint256 deltaPodDemandUpperBound;
        uint256 lpToSupplyRatioUpperBound;
        uint256 lpToSupplyRatioOptimal;
        uint256 lpToSupplyRatioLowerBound;
        uint256 excessivePriceThreshold;
        uint256 soilCoefficientHigh;
        uint256 soilCoefficientLow;
        uint256 baseReward;
    }
    

App Storage Redesign

App Storage has been redesigned such that two structs are implemented:

• Account contains state stored on an account level; and
• System contains state stored on a protocol level.

struct AppStorage {
        mapping(address => Account) accts;
        System sys;
    }
    

Various deprecated state variables are removed between the two structs and state is reordered to improve organization and developer experience. Buffers are placed throughout the state to allow for future upgradability without the need to append new state at the end of the AppStorage struct.

Reentrancy Design

The current reentrancy system does not support farm and farm-like functions (such as advancedFarm and tractor), as the farm function is used within Beanstalk to call multiple functions in one transaction. This allows Farm calls to be called within other Farm calls, which may introduce additional security risks.

We propose a reentrancy redesign that now supports farm and farm-like calls. A new modifier nonReentrantFarm is added that allows for the function to call any other function, other than other functions that have the nonReentrantFarm modifier.

Micro Stalk Bug

We propose to increase the precision of Stalk by 1e6 (for a total of 16 decimals) and update various functions that calculate Stalk to account for the new precision.

Farm Balance Transfer Event

We propose a new event that is emitted when transferToken is called that explicitly includes the sender and recipient addresses:

event TokenTransferred(
            address indexed token,
            address indexed sender,
            address indexed recipient,
            uint256 amount,
            From fromMode,
            To toMode
        );
    

L2 Migration to Arbitrum

We propose to migrate Beanstalk and its state from Ethereum L1 to Arbitrum.

See the Effective section for full process. Note that BEAN:3CRV liquidity is proposed to be migrated to a BEAN:USDC Well on Arbitrum.

As part of the migration process:

• Grown Stalk is Mown;
• Earned Beans are Planted; and
• Rinsable Sprouts, Unpicked Unripe assets and unclaimed Silo V2 Withdrawals are put into the respective accounts' Farm Balances.

Circulating Beans at the time of the Reseed need to be manually migrated by calling migrateL2Beans on L1, which burns the Beans on L1 and issues them on the L2.

Beanstalk assets (Deposits, Plots, Beanstalk-related Farm balances, and Fertilizer) belonging to smart contract accounts cannot be automatically migrated, given that Beanstalk cannot assume an owner of a smart contract is able to gain ownership of the same address on L2. Smart contract owners will need to perform a 2 step migration process in order to claim their assets:

1. On the L1 Beanstalk contract, delegate a L2 address to be the receiver of the assets (this can be an EOA or another smart contract) by calling approveL2Receiver; and
2. On the L2 Beanstalk contract, the user can claim their assets by calling issueDeposits, issuePlots, issueInternalBalances, and issueFertilizer with the list of assets and a merkle proof verifying the validity of the list.

Smart contract owners can migrate their Beanstalk assets to an EOA prior to the deployment of this BIP if they'd like they assets to be automatically migrated.

The following code is updated to support L2 deployments:

The gm incentive is generalized to support L2 deployments by changing the incentive to be based on the time elapsed from the start of the hour. The incentive starts at 1 Bean and compounds 1.0201% every additional 2 seconds that elapse past the first timestamp in which gm could have been called, for 300 seconds.

New Whitelist

We propose to whitelist the following Wells with Upgradable Well Implementations (owned by Beanstalk) on Arbitrum:

Process Updates

We propose to setup Hypernative on Arbitrum with the same configuration proposed in BIP-46.

We propose to update the Immunefi Bug Bounty Program to reflect the changes proposed in this BIP, notably adding the Stable 2 Well Function and Tractor Junctions as in scope and adding following Impacts as in scope (the updated program can be read here):

• Medium: Invariant is missing on a function where it should be implemented; and
• Medium: Exploit is possible but is exclusively prevented by an invariant.

We propose to update the Beanstalk DAO Disclosures to include risks associated with Hypernative, Arbitrum and the new set of whitelisted assets. The updated Beanstalk DAO Disclosures can be read here.

Technical Rationale

Secure Beanstalk

Calling farm within other farm-like functions (including advancedFarm and tractor) is disabled in the interest of security with minimal to no loss in composability.

Given that packing is no longer necessary for saving gas due to the L2 migration, many variables in the Beanstalk contracts are casted up to int256 or uint256 to prevent unnecessary overflows.

Removing dead code reduces the surface area of potential vulnerabilities in Beanstalk.

Generalized Convert

Unripe Converts cannot be supported by pipelineConvert because the underlying tokens are not liquid. For this reason, the existing convert function that supports Unripe Converts is left in the ConvertFacet.

Pipeline Converts are limited to usage of Pipeline (i.e. pipeCalls) rather than farm calls for security reasons (with regard to reentrancy attacks).

Generalized Flood

In LibWhitelist, Wells are flagged as Floodable (isSoppable) based on whether or not Beanstalk should sell Beans in the Well during Flood conditions. This functionality is added in the event that future whitelisted Wells should not be Flooded in.

Shipments

Within a given Season, if a Shipment gets paid off, the remaining Bean mints are allocated equally to all remaining Shipments until the following Season. In this way, there are not circular dependencies for each Plan to know about other Plans. Doing so with enough Shipments would eventually exceed the gas limit.

Externalizing the Shipment functionality allows the Bean mint distribution to be changed without a diamond cut.

Tractor

All write functions functions in Beanstalk use LibTractor.getUser to get either msg.sender or the Publisher of the executing Blueprint. From a developer experience perspective, this is preferable to having a Tractor-specific version of every write function.

QoL Improvements

Solidity Version v0.8.20

Most DeFi protocols use Solidity v0.8.0 or higher. Upgrading Solidity versions allows the Beanstalk development community to take advantage of tooling that is developed with v0.8.0^ in mind. For example, using Foundry with v0.7.6 requires a number of workarounds in order to properly use it. While there are more recent versions of Solidity, Beanstalk should strike a balance between using a battle tested compiler and the latest version. For reference, Basin is developed in v0.8.20.

Whitelist Upgrades

Removing friction associated with whitelisting new assets and modifying existing whitelisted assets allows the DAO to upgrade the whitelist more quickly and with fewer security risks.

Morning Auction Adjustment

Using an if-else ladder in LibDibbler to approximate the Temperature during the Morning is necessary due to the infeasibility of calculating logarithms on-chain.

The if-else ladder is limited to updating the Temperature every 12 seconds due to the contract size limit on Ethereum. For this reason, the Temperature updates every 48 blocks on Arbitrum during the Morning Auction.

View Functions

Getting user balances requires either (1) thousands of calls to RPC providers each time the Beanstalk UI loads (which often gets rate limited), or (2) reliance on infrastructure like the subgraphs. The migration to a L2 makes it possible to update the storage architecture to support getter functions for user balances.

App Storage Redesign

The difficulty of organizing storage data in Ethereum Diamonds can lead to security risks. From a development perspective, the L2 Migration is a great opportunity to address this issue.

Constants to State

Changing facets comes with additional security risks and migrating constants to state eliminates these risks. The migration to a L2 makes this migration more feasible.

L2 Migration to Arbitrum

Removing the SiloFacet and waiting for all Deposits to Germinate (assuming there are Germinating Deposits at the time of BIP passage) before executing the migration simplifies the migration of Deposits.

Given that Beanstalk does not have control of Beans outside of the Beanstalk contract, Circulating Beans at the time of the Reseed need to be manually migrated from L1 to L2.

Beanstalk assets in smart contract accounts cannot be automatically migrated given that Beanstalk cannot assume an owner of a smart contract is able to gain ownership of the same address on L2.

The diamond cut initialization scripts that migrate Beanstalk state are generalized to be executed across multiple transactions given that migration process will exceed the gas limit.

The remaining facets on L1 allow the continued support of Farm Balances on L1 Beanstalk. The L1TokenFacet must be updated to disallow transferring Beanstalk-related assets (which are migrated to L2) out of L1 Beanstalk.

New Whitelist

Deploying the Wells with an Upgradable Well Implementation (owned by Beanstalk) allows the BCM to fix bugs in the corresponding Wells without requiring a Silo migration from the vulnerable Well to a new one.

Economic Rationale

Secure Beanstalk

Ensuring that certain invariants are not violated as a result of transaction execution substantially increases the security of Beanstalk and has the potential to save the DAO a significant number of Beans from being spent on bug reports.

Generalized Convert

Supporting LP → LP Converts significantly increases the efficacy of the Seed Gauge System with respect to achieving the optimal distribution of Bean liquidity.

Using the capped reserves in Multi Flow to measure Convert capacity allows Beanstalk to use the least stale data possible while preserving manipulation resistance.

Updating the existing convert function is necessary to penalize Farmers for Converting in a direction that causes the cumulative deltaB to move away from peg.

Generalized Flood

Generalizing Flood the occur in multiple Wells at once is an essential peg maintenance tool for Beanstalk.

Capping the number of Pods that become Harvestable upon Flood to 0.1% of the Bean supply is a useful security measure given that it does not seem necessary to make all Pods Harvestable.

Tractor

Decreasing friction for Farmers to automate the execution of their transactions improves the efficiency of Beanstalk.

QoL Improvements

Whitelist Upgrades

Generalizing the whitelisting process substantially reduces the amount of code needed to be written to whitelist new assets, change oracles, change Gauge Point functions, etc.

Morning Auction Adjustment

Decreasing the rate at which the Temperature increases during the Morning Auction should decrease the number of Pods issued by Beanstalk during times of high demand for Soil.

New Default Gauge Point Function

A Gauge Point function that factors in the distance between the current LP BDV distribution and the optimal may be more effective at issuing the proper amount of Grown Stalk to LP Depositors.

Minimum Bean to Max LP Ratio Upon Rain

Changing the Bean to Max LP Ratio to its minimum value before a Flood reflects that Beanstalk would prefer that Farmers first Convert down to add liquidity first before it mints and sells Beans directly on the market.

L2 Migration to Arbitrum

Arbitrum is the largest Ethereum L2 by market cap and TVL. Migrating to a L2 substantially decreases the costs of interacting with Beanstalk.

BEAN:3CRV is migrated to BEAN:USDC given that there is no 3CRV on Arbitrum.

New Whitelist

A wider variety of options for Bean liquidity providers to receive Stalk and Seed rewards increases utility for Silo Depositors.

Whitelisting BEAN:USDC and BEAN:USDT gives Depositors the opportunity to earn Stalk and Seeds while being exposed to less volatile assets. The relatively low optimal LP BDV distribution of 12% for both BEAN:USDC and BEAN:USDT reflects the centralization risks of the two stablecoins. Using the Stable 2 Well Function in these Wells allows for better execution prices for traders around peg.

Setting the initial Gauge Points to 0 (the minimum value) for BEANwstETH and 1000 (the maximum value) for all other whitelisted assets reflects that nearly all Bean liquidity is already in the BEANwstETH Well due to the Unripe liquidity. Given this, Beanstalk should immediately start incentivizing holding the other whitelisted LP tokens.

Whitelisting BEAN:WBTC gives Depositors the opportunity to earn Stalk and Seeds while holding BTC exposure. The relatively low optimal LP BDV distribution of 20% reflects the centralization risks of WBTC.

weETH has the largest TVL of any liquid staking derivative on Arbitrum. Basin does not have a Well Implementation that tracks rebasing tokens—thus, Basin (and thus, Beanstalk) must use weETH (i.e., the wrapped, non-rebasing version of eETH).

Contract Changes

L1 Initialization Contract

The init function on the ReseedL2Migration contract is called: 0xE35c0397dBB43EB7E2cb28a182d857a3A42eFaDB

L1 Beanstalk

All remaining facets and functions on L1 Beanstalk can be found in the Appendix section.

L2 Beanstalk

The following facets are removed from Beanstalk (i.e., not added to L2 Beanstalk):

• FundraiserFacet
• LegacyClaimWithdrawalFacet
• CurveFacet
• MigrationFacet

All facets and functions added to L2 Beanstalk can be found in the Appendix section.

Beans Minted

During the L2 migration, Beans are minted on Arbitrum corresponding to the amount in L1 Beanstalk (i.e., Beans underlying Bean Deposits, Beans underlying Deposited LP tokens, Ripe Beans, Farm Balances and Beans in Pod Orders).

After the conclusion of the L2 migration, anytime a Farmer migrates L1 Circulating Beans, L2 Beans will be minted. Similarly, any time a smart contract account owner on L1 migrates their assets, L2 Beans may be minted depending on which assets are migrated.

Audit

The commit hash of this BIP is faa0ec60a455b0afdd20ad86f28f41cbc52c2e2d.

An audit competition of this upgrade was held via Codehawks using commit hash 4e0ad0b964f74a1b4880114f4dd5b339bc69cd3e. The final report can be read here.

Audit remediations were committed and documented in PRs #970, #1046, #1047, #1054, #1056 and #1076. All changes were reviewed by 2 top Codehawks auditors.

The Upgradable Well Implementation and Stable 2 Well Function were audited by Code4rena—final report here. The final report for the fix review is here.

Post Audit Changelog

Beanstalk

• ca970be820d5aa13071ed032eb39f3d4aadcc43b, which divides by 1e6 in LibGauge.issueGrownStalkPerBdv;
• d5714c86e949c58939f273c3edb5095c22877079, which adds various try-catches in LibPipelineConvert for Wells that do not have any reserves;
• 0e5a0601bf3db45c670b700f1d20e6770ff8155a, which adds an additional check in LibEvaluate.calcLpToSupplyRatio that skips the evaluation of liquidity when the reserves are 0;
• 2d078411e35ed0c75f085633fa6883bce70e2d4f, which updates ReseedGlobal to emit the ShipmentRouteSet event; an
• b712b15bd82130a6595edad99fecb0f24c115fae, which adds a try-catch in LibWell.calculateTokenBeanPriceFromReserves to fail gracefully.

Basin

All of the following are implemented in PR #146:

• Update MultiFlowPump to fail gracefully when calcRate fails;
• Update IMultiFlowWellFunction to implement ratioPrecision(uint256 j, bytes data), which returns the precision that MultiFlowPump should use when calculating the capped reserves;
• Update MultiFlowPump to use ratioPrecision when calculating ratios[j] in calcReservesAtRatioSwap;
• Update ConstantProduct2, ConstantProduct, and Stable2 to implement ratioPrecision; and
• Update IWellFunction to implement version, allowing users to verify Well Functions.

Effective

After either:

• A two-thirds supermajority is reached; or
• The Voting Period ends and either (1) 50% of Stalk is voting For or (2) one-third of Stalk, plus the amount of Stalk voting Against, is voting For,

The L1 BCM will:

• Execute a diamond cut that removes the SiloFacet and wait for 2 Seasons to pass in order for all Deposits to Germinate (only if there are Germinating Deposits at the time of BIP passage);
• Execute the BIP-50 diamond cut, which:
  • Calls the ReseedL2Migration initialization contract, which:
    • Pauses L1 Beanstalk; and
    • Transfers all BEANETH, BEANwstETH and BEAN3CRV in L1 Beanstalk to the L1 BCM;
  • Removes all facets except for DiamondCutFacet, DiamondLoupeFacet, OwnershipFacet and PauseFacet; and
  • Adds the L1TokenFacet and L2MigrationFacet;
• Remove corresponding liquidity from the BEAN:WETH, BEAN:wstETH and BEAN:3CRV pools;
• Swap all 3CRV for USDC; and
• Send all WETH, wstETH and USDC to Arbitrum using the Arbitrum-native bridge.

In addition, a deployer will:

• Fetch the state of L1 Beanstalk at the end of the block in which the BIP-50 diamond cut is executed;
• Deploy the L2 Beanstalk diamond on Arbitrum (in a Paused state);
• Execute the series of scripts to:
  • Initialize the state of L2 Beanstalk;
  • Deploy all whitelisted Wells;
  • Mint Beans to be added as liquidity to the L2 BCM;
  • Mint remaining Beans (for Bean Deposits, Ripe Beans, Farm Balances and Beans in Pod Orders) to L2 Beanstalk; and
  • Mint Unripe Beans and Unripe LP to L2 Beanstalk; and
• Transfer ownership of L2 Beanstalk to the L2 BCM.

After which the L2 BCM will:

• Execute a series of scripts that verify the state of L2 Beanstalk;
• Claim ownership of L2 Beanstalk;
• Add liquidity to the BEAN:WETH, BEAN:wstETH and BEAN:USDC Wells;
• Transfer the corresponding BEANWETH, BEANwstETH and BEANUSDC Well LP tokens to L2 Beanstalk;
• Add all the facets mentioned in the Contract Changes section; and
• Unpause L2 Beanstalk.

Appendix

L1 Beanstalk

The following facets show all functions remaining on L1 Beanstalk:

L1 DiamondCutFacet

Remaining DiamondCutFacet address: 0xDFeFF7592915bea8D040499E961E332BD453C249

L1 DiamondLoupeFacet

Remaining DiamondLoupeFacet address: 0xB51D5C699B749E0382e257244610039dDB272Da0

L1 OwnershipFacet

Remaining OwnershipFacet address: 0x5D45283Ff53aabDb93693095039b489Af8b18Cf7

L1 PauseFacet

Remaining PauseFacet address: 0xeab4398f62194948cB25F45fEE4C46Fae2e91229

L1 L1TokenFacet

Added L1TokenFacet address: 0x8F66044a9C95FaE9d38B8Bc30665eE04A2456501

L1 L2MigrationFacet

Added L2MigrationFacet address: 0xb7EA01231e518cd22E118165b290f5CC3263F5bB

L2 Beanstalk

The following facets show all functions added to L2 Beanstalk: 0xD1A0060ba708BC4BCD3DA6C37EFa8deDF015FB70

Notes:

• All functions that were in L1 Beanstalk but are not added to L2 Beanstalk are indicated by a "Remove" in the Action column; and
• Functions that have changed solely as a result of at least one of the following do not have a "✓" in the New Functionality column:
  • Secure Beanstalk modifiers;
  • Changes to msg.sender as a result of introducing Tractor; or
  • Storage changes.

L2 DiamondCutFacet

Added DiamondCutFacet address: 0x7B08f0efC94626D373c99fd39353217a371F90c0

L2 DiamondLoupeFacet

Added DiamondLoupeFacet address: 0x82aF8BC912284F916dBe7208074F3B16ea27BB40

L2 OwnershipFacet

Added OwnershipFacet address: 0x2cb2D140c42b79F602535e2447E7Afa980034464

L2 WhitelistFacet

Added WhitelistFacet address: 0x7f855852a7191635c845c4183a6335ecb0B7aFAb

L2 UnripeFacet

Added UnripeFacet address: 0x87F1FB2CF1CDC19103739F7cdb0068b203184354

L2 MetadataFacet

Added MetadataFacet address: 0x5794fDb0cfE2AbFCB3D22103F5d8c6B4C2cCD1d9

L2 SeasonFacet

Added SeasonFacet address: 0x40c8688969c91290311314fbB2f10156b43Fbe4B

L2 SeasonGettersFacet

Added SeasonGettersFacet address: 0xfe15fe467d06Ce19d20709eAE9E24B3bD8309132

L2 GaugeGettersFacet

Added GaugeGettersFacet address: 0x2e804f24134baCF12036757D1dcdcCbBBb3e2f31

L2 PauseFacet

Added PauseFacet address: 0x926CFCe66aa8A0CC29470dA28095D88CF24ABE16

L2 MarketplaceFacet

Added MarketplaceFacet address: 0xcA03AbaBA37566d89B707878495D9EB8Ea48C3c5

L2 FieldFacet

Added FieldFacet address: 0xa9085918d5632EA12BA91709F819B800fa8B3726

L2 FertilizerFacet

Added FertilizerFacet address: 0x7B2BDA06CE2cD8287e169b241d68d1Bb6568e342

L2 FarmFacet

Added FarmFacet address: 0x24103B8141F97D9D8794fE2EE0eD96F577EeC05F

L2 SiloFacet

Added SiloFacet address: 0x5678345D444918a38ad9dC7CA1b0C208E1927094

L2 SiloGettersFacet

Added SiloGettersFacet address: 0xb4F9d59f787642F64c73346A747Bf1984A52D4Ea

L2 EnrootFacet

Added EnrootFacet address: 0x3AF703FACA14A0201E5aa98D91cA1Dbb10a8f110

L2 TokenFacet

Added TokenFacet address: 0x915D09eC953520AB46c3AC76B7153e354DEa84CD

L2 DepotFacet

Added DepotFacet address: 0x107F33211935bb72B721675c7e95a2d4cC0c96cc

L2 TokenSupportFacet

Added TokenSupportFacet address: 0x17AC9d59f4637a16F47C8a77A1c4EE7c7a159A95

L2 ConvertFacet

Added ConvertFacet address: 0x242A339C73d3b373a91C157865B36a1480ec3b09

L2 ConvertGettersFacet

Added ConvertGettersFacet address: 0x999A04B54a386b1C68A9Be926AF0200F2C49A47A

L2 ApprovalFacet

Added ApprovalFacet address: 0x5579358403eD126dB6ed6A213B5129696161Bad6

L2 BDVFacet

Added BDVFacet address: 0x4da6AAed2a2C3605f7c098037014003697Cb0426

L2 GaugePointFacet

Added GaugePointFacet address: 0xbcF3bA03bf792F9f8B5dbd460eAa446529020778

L2 LiquidityWeightFacet

Added LiquidityWeightFacet address: 0x19AC2dc9A0BFda04Dde8EA7437945872DB95B13E

L2 TractorFacet

Added TractorFacet address: 0xcb84F1a368f303798DB6d9cE7B4084Aaf316479b

L2 L1ReceiverFacet

Added L1ReceiverFacet address: 0x8F2bB164dF87183af23E72d49572052e27651A57

L2 PipelineConvertFacet

Added PipelineConvertFacet address: 0x6B1B5E5cef71f0cC65d32B67D8794F58faD491a3

L2 ClaimFacet

Added ClaimFacet address: 0x76eF6b03775A4cDE7666C96f3Ca21feb736afeBC

L2 OracleFacet

Added OracleFacet address: 0x48Fa359664820A12ad6Ae8769ccB4365053da580

Event Changes from L1 to L2