RFC: Generalized Convert

[pizzaman1337]

RFC: Generalized Convert

Authors

Ben Weintraub, Brendan Sanderson, Brean, Guy, Pizzaman1337

Summary

• Introduce a new Convert function which allows Farmers to 1) Convert a set of whitelisted assets to 1 whitelisted asset and 2) choose the output stems; and
• Rather than disallowing certain Conversions in a given state while allowing others (like whether deltaB is less than or greater than 0), the system instead implements a Stalk penalty or bonus based on the type and amounts of Converts and the Beanstalk state.

Problem

Currently, Farmers are not able to Convert between whitelisted LP tokens without significant disparities in the deltaB for each pool. The effectiveness of an LP gauge system is highly limited by excessive friction between LP Converts. Currently, the source pool(s) would need to have negative deltaB, and the destination pool would need to have positive deltaB (essentially, a Pipeline LP → BEAN → LP Conversion). This is both inefficient from a gas perspective, and limiting for Farmers choices, given that from a peg maintenance perspective, the effect is neutral.

Solution

Introduce a new pipelineConvert function that allows Farmers to Convert from any whitelisted token(s) to another whitelisted token via Pipeline.

Notes:

• Previously, Beanstalk allowed Farmers to retain the BDV of their Deposit(s) to reduce the opportunity cost in Converting (i.e , if a Deposit’s BDV were to decrease in a LP → BEAN convert, the previous BDV would be retained).
• Because tokens can be withdrawn directly to a Farmer’s address in a Pipeline convert, BDV will be able to decrease (unlike the current convert function) as Beanstalk is unable to identify the cause of the decrease in BDV. Therefore, if the BDV decreases, the Grown Stalk earned from the input Deposits should be decremented proportionally to the decrease in BDV.

Specification

Limitations

• A separate function is needed from the traditional convert function due to complexity.
• A NxN Convert cannot be done (i.e., N Deposits to N Deposits), due to the ability to manipulate the Stalk per Deposit favorably towards the Farmer (i.e., avoid the bonus/penalty for LP <> LP conversions).
  • For example: say a Farmer had BEAN Deposits and BEANETH Deposits, with significantly more Grown Stalk associated with their Bean Deposits. They want to sell Beans. Additionally, the Bean price is below peg (i.e., unable to convert BEAN → LP). With a NxN Convert, they can redistribute the Stalk into BEANETH, retaining the Stalk growth while still being able to sell.
  • It is not possible to impose a penalty on all NxN mappings given the Pipeline flexibility.
  • However, an NxN Convert can be performed by combining multiple Nx1 Convert functions in a farm transaction.

Context

Although NxN Converts introduce the potential for avoidance of the Stalk bonus/penalty system, you can effectively create NxN Converts in a single transaction through the composition of multiple Nx1 Converts. Farmers get the clean UX of NxN while Beanstalk can impose the appropriate economic incentives.

The Nx1 Convert can be (and should be) further evaluated in terms of N 1x1 converts, such that each individual asset conversion within the Nx1 Convert is evaluated independently. Upon evaluation of all 1x1 Converts within the Nx1 Convert, the appropriate aggregate penalty or bonus can be applied to the Nx1 convert.

1x1 Converts have 4 potential paths:

• $LP → BEAN$ Conversions from LP Deposits to BEAN Deposits with no changes in BDV or Grown Stalk
• $BEAN → LP$ Conversions from BEAN deposits to LP deposits with no changes in BDV or Grown Stalk
• $LP_x → LP_y$ Conversions from LP_x deposits to LP_y deposits with no changes in BDV or Grown Stalk
• $\lambda → \lambda$ Conversions from Deposits of an asset to Deposits of the same asset, with changes to BDV and/or Grown Stalk

1x1 Converts can be understood as the combination of one of either $LP → BEAN$, $BEAN → LP$ or $LP_x → LP_y$ Conversions AND a $\lambda → \lambda$ Conversion.

Only $LP → BEAN$, $BEAN → LP$ or $LP_x → LP_y$ Conversions are used to calculate the appropriate Stalk penalty and bonus associated with the Nx1 Convert. Only a $\lambda → \lambda$ Conversion uses the penalty and bonus to confirm the Nx1 conversion is appropriate. Therefore, the pipelineConvert function can work as follows:

1. Evaluate all $LP → BEAN$, $BEAN → LP$ or $LP_x → LP_y$ Conversions to determine the appropriate Stalk penalty and bonus;
2. Evaluate the $\lambda → \lambda$ Conversion using the Stalk penalty and bonus calculated in Step 1; and
3. If Step 2 returns an approval, the Convert is accepted.

Step 1: LP → BEAN, BEAN → LP or LP_x → LP_y Converts

Determining the appropriate aggregate penalty associated with a given Nx1 convert is still a WIP.

Step 2: Lambda → Lambda Convert

The intuition behind the $\lambda → \lambda$ Convert check is that the opportunity cost for withdrawing any amount of BDV from the Silo should be equal to the Convert vs prior to it, having properly adjusted for changes in BDV and the Grown
Stalk penalty and bonus.

The following condition should be met in order for $\lambda → \lambda$ Converts to be accepted by Beanstalk:

The bonus and penalty adjusted Grown Stalk in ≥ Grown Stalk out for all BDV.

There are 4 cases to consider with regard to this condition.

1. BDV increases
2. BDV decreases
3. Grown Stalk penalty
4. Grown Stalk bonus

Case 1 - BDV Increases:

Intuition: In order to avoid the creation of new Deposits with 0 Grown Stalk from the new BDV, distribute the BDV evenly across all Grown Stalk.

Implementation: In practice this will require scaling the BDV of each Deposit up by $\text{max}(\frac{BDV^{in}}{BDV^{out}}, 1)$ and the Grown Stalk per BDV (Stem) down for each Deposit by $\frac{1}{\text{max}(\frac{BDV^{in}}{BDV^{out}}, 1)}$.

Case 2 - BDV Decreases:

You don’t lose Grown Stalk when BDV decreases. Only future Grown Stalk and base stalk.

When BDV decreases it should be distributed evenly across all BDV in the Convert.

Implementation: In practice this will require scaling the BDV of each Deposit down by $\text{min}(\frac{BDV^{in}}{BDV^{out}}, 1)$ and the Stem up for each Deposit by $\frac{1}{\text{min}(\frac{BDV^{in}}{BDV^{out}}, 1)}$.

In practice, accounting for the change in BDV (i.e., Cases 1 and 2) can be combined into a single adjustment of BDV and Grown Stalk. Scale BDV by $\frac{BDV^{in}}{BDV^{out}}$ and scale Stem by $\frac{BDV^{out}}{BDV^{in}}$.

Case 3 - Grown Stalk Penalty:

Assumption: the penalty is some value from [0,1] where 0 implies complete retention of Grown Stalk (i.e., no penalty) and 1 implies complete loss of Grown Stalk.

When there is a Grown Stalk penalty you can:

1. Distribute the penalty equally across all Stems
2. Allow arbitrary distribution of the lost Grown Stalk

Intuition: because arbitrary distribution of the lost Grown Stalk allows for some Deposits to be returned to 0 opportunity cost (and therefore withdrawn without friction) it is in the interest of Beanstalk to enforce equal distribution of the penalty across all Stems.

Implementation: In practice this will require scaling down all Stems in by 1 - penalty.

Case 4 - Grown Stalk Bonus:

Assumption: the bonus can be an arbitrary set of (BDV, Stem) pairs that is ordered in ascending order in terms of Stem.

When there is a Grown Stalk bonus you can:

1. Force the distribution of Stems equally across BDV.
2. Force or allow the retention of the distribution of the bonus Stems by the highest Stem BDV

Intuition: there is no reason for Beanstalk to mandate the equal distribution of the bonus Grown Stalk across BDV. Enforcing the distribution of the Grown Stalk bonus across the highest Stem increases the opportunity cost for some Deposits (this reasoning could be better).

Implementation: bonus Stem added to the highest Stem BDV.

Inter-Block MEV Manipulation Resistance

Use BDV and Stem of deposits into the Convert. Use Multi Flow inst. inst EMA or last balances (TBD) for BDV of output Deposits of Convert.

Reasoning: although there is an inefficiency due to the EMA, this is preferable to arbitrary manipulation if raw last balances were used. Unclear if last balances or EMA is better for Convert. More analysis needed.