Beanstalk does not have any collateral requirements. Beanstalk uses credit instead of collateral to create Bean price stability relative to its value peg of $1. The practicality of using DeFi is currently limited by the lack of decentralized low-volatility assets with competitive carrying costs. Borrowing rates on USD stablecoins have historically been higher than borrowing rates on USD, even when supply increases rapidly. Non-competitive carrying costs are due to collateral requirements.

Beanstalk relies on three native assets and three interconnected facilities to regularly oscillate the price of Bean across its value peg:

Tokens

Beanstalk issues 3 tokens:

1. Beans — Beanstalk ERC-20 fiat stablecoins;

Primary Facilities

1. The Sun

2. The Silo

To encourage consistent security:

• Seeds yield Stalk every Season.

• The associated amount of Stalk and Seeds from a given Deposit must be forfeited when it is Withdrawn from the Silo.

Deep and consistent liquidity in liquidity pools that Beans trade in improves stability. Liquidity providers to liquidity pools whose LP tokens are whitelisted can also Deposit their LP tokens in the Silo to earn Stalk and Seeds. At least 1 LP token Deposit type earns at least as many Seeds as Bean Deposits.

3. The Field

Soil is the number of Beans that can be lent to Beanstalk at any given time. Any time Beanstalk is willing to issue debt, there is Soil available in the Field. Any Beans not in the Silo can be Sown (lent) to Beanstalk in exchange for Pods.

Creating Stability

Beanstalk requires a diverse set of participants, including Silo Members (people who Deposit assets in the Silo), Sowers (people who lend Beans to Beanstalk), and arbitrageurs. Beanstalk aligns the incentives of every individual participant to maximize price stability and create a diverse, decentralized economy. Beanstalk-native financial incentives consistently increase censorship resistance, stability and liquidity over time.

At the beginning of each Season, the Sun calculates deltaB (the cumulative time-weighted average shortages or excesses of Beans across liquidity pools on the Minting Whitelist), Beanstalk's debt level, the change in demand for Soil over the previous 2 Seasons, and Beanstalk's liquidity level, and dynamically adjusts the Bean supply, Soil supply, Maximum Temperature and the Crop Ratio to bring the price back towards the peg.

When the price of Bean is too low (i.e., deltaB is negative), Beanstalk:

• Raises the Maximum Temperature; and

• Adjusts the Crop Ratio based on Beanstalk's debt and liquidity levels.

By increasing the Soil supply and raising the Maximum Temperature, Beanstalk can decrease the supply of Beans and therefore bring the price of Bean back up to its peg (assuming there are willing lenders at the given Temperature). In principle, a reasonable debt level and consistent credit history attracts lenders.

When the Bean price is too high (i.e., deltaB is positive), Beanstalk:

• Increases the Bean supply by deltaB, subject to the cap in EBIP-2;

• Lowers the Maximum Temperature; and

• Lowers the Crop Ratio.

By increasing the Bean supply, lowering the Maximum Temperature and lowering the Crop Ratio, Beanstalk can bring the price of Bean back down to its peg.

The Beanstalk peg maintenance mechanism requires a protocol-native timekeeping mechanism and regular code execution on Arbitrum. The Sun keeps time on the Farm in Seasons and incentivizes cost-efficient and timely calling of the gm function.

Beanstalk adjusts itself to return the Bean price to its value peg at the beginning of every Season. Each Season is ~1 hour long. The first Season began when Beanstalk was deployed on August 6, 2021 (initially on Ethereum).

The exact beginning of each Season may vary as Seasons do not begin until the gm function has been called through an Arbitrum transaction. The first transaction that successfully calls the gm function after the top of each hour UTC begins a new Season. Beanstalk only accepts one gm function call per Season.

Beanstalk covers the cost of calling the gm function by awarding the sender of an accepted gm function call with newly minted Beans. To encourage regular gm function calls even during periods of congestion on Arbitrum while minimizing cost, the award for successfully calling the gm function starts at 1 Bean and compounds 1.0201% every additional 2 seconds for 300 seconds.

Upon acceptance of the gm call, the Sun:

1. Increments the Season number;

7. Awards Beans to the address that successfully called the gm function.

Minting Whitelist

1. The pool address; and

2. A function to calculate the liquidity and time weighted average shortage or excess of Beans in the pool.

Current Minting Whitelist

Transparency is the cornerstone of DeFi. The Beanstalk DAO endeavors to be as transparent as possible, particularly as it pertains to communicating the risks of interacting with Beanstalk.

1. BEANSTALK WAS ATTACKED ON APRIL 17, 2022 VIA ON-CHAIN GOVERNANCE. ALL ~$77M IN NON-BEAN ASSETS WERE STOLEN. PROTOCOL GOVERNANCE HAS BEEN CHANGED TO A 5-OF-9 COMMUNITY MULTISIG.

On April 17, 2022, Beanstalk was attacked via on-chain governance resulting in a theft of all ~$77M in non-Beanstalk user assets. The attacker used a flash loan to compromise the governance mechanism and steal the assets deposited in the DAO.

Shortly after the attack, Beanstalk was Paused and on-chain governance was removed. Since the attack, governance votes have taken place on Snapshot. Beanstalk is now owned by a community-run multisig wallet (the Beanstalk Community Multisig, or BCM) responsible for executing the will of the DAO as indicated via Snapshot vote. The keys to the BCM are custodied by a group of nine anonymous Beanstalk community members and contributors. All contract changes under the BCM structure require the signature of 5-of-9 BCM signers. This serves as a temporary security measure until either (1) a secure and fully decentralized governance mechanism has been developed and sufficiently audited, or (2) governance is removed altogether.

More information:

2. THERE IS NO MAXIMUM BEAN SUPPLY. THE BEAN SUPPLY CAN GROW INFINITELY THROUGH DEMAND-BASED MINTING AND GOVERNANCE.

Beanstalk increases the Bean supply every Season where the time weighted average price of 1 Bean is greater than $1 over the previous Season. Enough Beans are minted such that if all the newly minted Beans were sold, the Bean price would return to $1. Those Beans are distributed to Stalkholders, Pod holders and Active Fertilizer holders.

More information:

3. BEANSTALK DID NOT HAVE A PRE-MINE, PRE-SALE, OR TEAM ALLOCATION. ALL BEANS HAVE BEEN MINTED IN ACCORDANCE WITH EITHER THE MINTING SCHEDULE OR GOVERNANCE.

Beanstalk did not have a pre-mine, pre-sale or team allocation of any kind. The first 100 Beans were minted when the init function was called to deploy Beanstalk.

More information:

4. BEANSTALK RELIES ON THIRD PARTIES TO PROVIDE CREDIT TO RETURN THE BEAN PRICE TO ITS PEG. THERE IS NO LENDER OF LAST RESORT.

Beanstalk uses a credit based model, allowing anyone to lend Beans to the protocol to participate in peg maintenance. Beanstalk burns any Beans it borrows. As a consequence, the ability of the protocol to return the price of a Bean to the peg relies on the availability of willing creditors, which is not guaranteed. The economic design of Beanstalk fails if it can no longer attract creditors.

More information:

5. BEANSTALK DOES NOT GUARANTEE THE BEAN PRICE. INSTEAD BEANSTALK INCENTIVIZES THE REGULAR OSCILLATION OF THE BEAN PRICE ABOVE AND BELOW ITS PEG THROUGH PROTOCOL-NATIVE INCENTIVES.

Bean is not a collateralized stablecoin and Beanstalk offers no guarantee of the value of Bean. Beanstalk was deployed on August 6, 2021, and since then, the Bean price has crossed its dollar peg thousands of times. Even so, Beanstalk is still in an early stage and various parts of its economic design continue to be improved through governance.

Beanstalk tries to incentivize the regular oscillation of the Bean price above and below its peg. While the protocol's incentives are designed to return the price of a Bean to its peg, the timing of oscillations is indeterminate. The price will almost never be exactly equal to its peg. Crossing the peg in the past is no guarantee of it happening again in the future.

More information:

6. BEANSTALK-NATIVE DEBT DOES NOT HAVE A MATURITY DATE AND THEREFORE MAY NEVER BECOME REDEEMABLE FOR BEANS.

Beanstalk borrows Beans from lenders in exchange for Pods and Sprouts. Bean loans have fixed interest rates but do not have fixed maturity dates.

More information:

7. STALKHOLDERS CAN MAKE ARBITRARY CHANGES TO BEANSTALK THROUGH GOVERNANCE, IF ENACTED BY THE BEANSTALK COMMUNITY MULTISIG. THERE IS NO GUARANTEE THE CHANGES WILL BE BENEFICIAL TO BEANSTALK.

More information:

8. ANYONE CAN RECEIVE STALK BY DEPOSITING WHITELISTED ASSETS IN THE SILO. EARLIER DEPOSITORS IN THE SILO HAVE PROPORTIONALLY GREATER GOVERNANCE POWER RELATIVE TO THE BEAN DENOMINATED VALUE ORIGINALLY DEPOSITED.

Depositors earn Stalk and Seeds. Seeds yield 1/10000 new Stalk every Season. Stalkholders participate in governance and earn Bean seigniorage. Stalk ownership, and thus governance power, decentralizes over time.

As earlier Depositors in the Silo have been accruing Stalk from Seeds for more Seasons compared to later Depositors, these Depositors have greater governance power in proportion to the Bean Denominated Value (BDV) of their original Deposits.

More information:

9. THE BEANSTALK CONTRACT IS OWNED BY THE BEANSTALK COMMUNITY MULTISIG. THE MULTISIG CAN MAKE ARBITRARY CHANGES TO BEANSTALK WITH 5-OF-9 SIGNATURES FROM THE ANONYMOUS SIGNERS. THERE IS NO GUARANTEE THE MULTISIG ENACTS THE GOVERNANCE DECISIONS OF THE DAO.

Ownership of the Beanstalk contracts is held by a 5-of-9 multisig known as the Beanstalk Community Multisig (BCM). The BCM is an extension of the Beanstalk DAO. The BCM's role is to enact on-chain the decisions Stalkholders make via off-chain voting on Snapshot. Besides Publius (one of the members), all members of the BCM are anonymous. Publius selects the other members, who Publius believes will act in the best interest of Beanstalk. This process was approved via governance.

Off-chain governance introduces significant risks related to security and censorship. The BCM is designed to mitigate as many of those risks as possible by distributing the multisig keys across reputable community members and Beanstalk core contributors, and collectively implementing and adhering to a set of best practices. There is no guarantee the BCM enacts the governance decisions the DAO voted on via Snapshot.

More information:

10. MOST BEANSTALK FUNCTIONS CAN BE ARBITRARILY REMOVED BY HYPERNATIVE, A PROACTIVE THREAT PREVENTION AND REAL-TIME MONITORING PLATFORM. THERE IS NO GUARANTEE THAT FUNCTIONS ARE ONLY REMOVED WHEN APPROPRIATE.

The Beanstalk DAO implemented Hypernative into Beanstalk, a proactive threat prevention and real-time monitoring platform. Hypernative has the ability to remove any Beanstalk function unrelated to the Arbitrum Diamond and upgradability of Beanstalk.

Hypernative introduces significant risks related to security and censorship. There is no guarantee that:

• Hypernative only removes functions during high confidence pre-exploit and exploit-in-progress detections;

• The BCM will remove Hypernative protections when necessary for the security or censorship resistance of Beanstalk; or that

• The BCM only removes Hypernative protections when it beneficial to Beanstalk.

More information:

11. AS GOVERNANCE POWER IS DETERMINED THROUGH STALK OWNERSHIP, SUFFICIENT CAPITAL COULD PURCHASE SIGNIFICANT GOVERNANCE POWER AND TAKE OVER BEANSTALK.

More information:

12. A VULNERABILITY IN ETHEREUM OR ARBITRUM COULD RESULT IN A LOSS OF FUNDS. BEANSTALK ASSUMES THE SECURITY OF ETHEREUM AND ARBITRUM.

Ethereum is the largest smart contract blockchain by market capitalization, total value deposited, and dollar denominated transaction value. Arbitrum is the largest L2 on Ethereum by TVL. In general, open source networks with large amounts of value on them and long track records indicate security, but there is no guarantee. Beanstalk assumes the security of Ethereum and Arbitrum.

13. A VULNERABILITY IN BASIN OR ITS COMPONENTS COULD RESULT IN A LOSS OF FUNDS. BEANSTALK ASSUMES THE SECURITY OF BASIN AND ITS CORRESPONDING COMPONENTS.

More information:

14. A VULNERABILITY IN PIPELINE COULD RESULT IN A LOSS OF FUNDS. BEANSTALK ASSUMES THE SECURITY OF PIPELINE.

Through Beanstalk, users can perform complex, gas-efficient interactions with other Arbitrum-native protocols, like Pipeline. Pipeline is a sandbox contract allows anyone to perform an arbitrary series of actions in the EVM in a single transaction.

Pipeline was audited by Halborn, but there is no guarantee that Pipeline is secure. Beanstalk assumes the security of Pipeline.

More information:

15. THE BEAN PRICE IS DERIVED FROM THE VALUE OF ASSETS IT TRADES AGAINST IN DECENTRALIZED AMMS. THERE IS NO GUARANTEE ANY OF THESE ASSETS RETAIN VALUE.

The value of Beans is derived from the non-Bean assets trading against it in decentralized liquidity pools. Each of these assets have their own set of associated risks, unique to the asset. Beanstalk implicitly assumes risk associated with these assets.

16. BECAUSE BEANS DERIVE THEIR VALUE FROM THE ASSETS THEY TRADE AGAINST, AND NOT COLLATERAL, IT IS NOT POSSIBLE FOR ALL BEAN HOLDERS TO EXIT AT A DOLLAR OF VALUE FOR EVERY BEAN.

Beans are not redeemable for any other asset; they can only be traded for another asset that Beans are trading against. As Bean holders sell their Beans, there is less and less value trading against Beans. Thus, unlike collateralized stablecoins, it is not possible for the Bean supply to scale down to zero with every Bean holder getting a dollar of value for every Bean sold.

17. BEANSTALK REQUIRES TRUSTLESS AND RELIABLE ACCESS TO A MANIPULATION RESISTANT PRICE ORACLE FOR A DOLLAR. BEANSTALK USES A CHAINLINK DATA FEED AND THE ON-CHAIN PRICES OF OTHER STABLECOINS TO DETERMINE THE PRICE OF A DOLLAR. THERE IS RISK ASSOCIATED WITH BOTH OF THESE METHODS THAT CAN COMPROMISE THEIR INTEGRITY AS ACCURATE PRICE ORACLES.

Beanstalk's core objective is to oscillate the price of a Bean above and below its dollar peg. To do this, Beanstalk must be able to reliably measure the price of a dollar on-chain without trusting a centralized third-party to provide it. A robust, decentralized stablecoin requires a tamper-proof, manipulation resistant and decentralized price oracle.

A disruption in the reliability of various Chainlink data feeds could impact Bean minting, resulting in adverse consequences for Beanstalk. The Chainlink data feeds are inherently centralized.

More information:

18. BEANSTALK REQUIRES THAT THE GM FUNCTION IS CALLED AT THE TOP OF EACH HOUR ON ARBITRUM. FAILURE TO SUCCESSFULLY INCENTIVIZE THE CALLING OF THE GM FUNCTION COULD HAVE AN ADVERSE AFFECT ON BEANSTALK'S ABILITY TO OSCILLATE THE BEAN PRICE ABOVE AND BELOW ITS PEG.

Beans and/or Soil are minted upon a successful call of the gm function. Beanstalk covers the cost of gm by awarding the sender of an accepted gm function call with newly minted Beans. The failure of Beanstalk to successfully incentivize the calling of gm would effectively result in the failure of Beanstalk to influence the size of the Bean supply, and thereby the Bean price.

More information:

19. THE BEANSTALK CONTRACTS ARE OPEN SOURCE. ANYONE CAN VIEW THE SOURCE CODE AND ATTEMPT TO FIND VULNERABILITIES.

More information:

20. BEANSTALK IS AUDITED BUT AUDITS CANNOT GUARANTEE SECURITY. IT IS ANTICIPATED THAT FUTURE CODE WILL NOT BE AUDITED BEFORE BEING COMMITTED BY THE DAO.

In the future, it is anticipated that the DAO will vote to commit unaudited code. There is always additional risk associated with implementing unaudited code.

There is no guarantee that interacting with Beanstalk through the Beanstalk UI and SDK is secure. Any issues could lead to a loss of funds.

More information:

21. THE APP.BEAN.MONEY FRONTEND CAN BE CENSORED AS IT IS HOSTED ON A CLOUD PROVIDER.

There have been multiple instances of Netlify getting compromised, resulting in phishing attacks. There is no guarantee that the Beanstalk UI will not be subjected to similar attacks.

More information:

22. THE APP.BEAN.MONEY FRONTEND DEPENDS ON THE SUBGRAPHS FOR DISPLAYING VARIOUS ON-CHAIN DATA. THERE IS NO GUARANTEE THAT SUBGRAPH DATA IS ACCURATE OR AVAILABLE.

By default the Beanstalk UI uses a version of the subgraph hosted on Hetzner, a privately held, Germany based cloud provider. Hetzner could censor the subgraph or a technical disruption could prevent access.

More information:

23. REGULATORY INTEREST IN STABLECOINS AND DECENTRALIZED FINANCE WILL RESULT IN NEW INDUSTRY REGULATIONS. THE IMPACT OF FUTURE REGULATIONS ON BEANSTALK IS UNCERTAIN.

In alignment with the ethos of DeFi, Beanstalk has been designed to be permissionless and censorship resistant, without the requirement for any trust-providing intermediary.

It is unclear what regulations, if any, governments will attempt to impose on DeFi. Therefore, it is impossible to predict how any new government regulations of DeFi will affect Beanstalk, or any of the protocols or networks Beanstalk relies on as part of its ecosystem.

24. BEANSTALK IS NOT A FINISHED PROTOCOL AND REQUIRES ONGOING DEVELOPMENT. THERE IS NO GUARANTEE OF FURTHER DEVELOPMENT.

Beanstalk is likely not at a point where it can sustain itself in perpetuity without additional development of itself and the surrounding ecosystem. High quality improvements are essential but are not guaranteed.

Publius, the pseudonym for the three co-founders of Beanstalk, continues to be influential within the Beanstalk DAO. The identities of Publius are public. The identities of most of the remaining Beanstalk contributors are anonymous.

Beanstalk is designed from first principles to issue capital-efficient, decentralized stablecoins that are accessible to anyone with an internet connection.

Today’s predominant stablecoins suffer from one or more fundamental issues, primarily centralization and non-competitive carrying costs.

Centralization

Centralized stablecoins are currently the most widely used stablecoins by market capitalization. The businesses that issue these stablecoins are subject to external oversight and governmental coercion, and have the unilateral power to freeze their stablecoins.

Carrying Costs

Real economic activity built on DeFi requires low-volatility assets for users to hold and transact with. However, borrowing rates of low-volatility on-chain assets exceed those of the off-chain assets to which they are pegged. This is due primarily to collateral requirements — there is an opportunity cost associated with locking up collateral to issue stablecoins.

These collateralized stablecoins suffer from what’s known as negative carry—a condition in which the cost of holding an asset exceeds the yield earned while holding it. In other words, holding the collateral has an inherent inflation-adjusted cost, whether explicit in the form of an interest rate on a loan, or implicit in the form of an opportunity cost to lend it out to borrowers. Issuance and use of collateralized stablecoins is greatly inhibited by non-competitive carrying costs.

Beanstalk is designed to incentivize all capital entering the protocol to continuously maintain exposure to the Bean stablecoin, and in doing so, participate in the growth of Beanstalk. Volatility and yield are baked into the Bean token itself—when the Bean price is too high, Beanstalk mints new Beans and distributes them to various ecosystem participants in a deterministic fashion. This seigniorage is the positive carry that the Beanstalk economy is based on.

Additional resources:

The Field is Beanstalk's credit facility. Beanstalk relies on a decentralized set of creditors to maintain Bean price stability.

Farmers who Sow Beans (lend Beans to Beanstalk) in exchange for Pods are known as Sowers. The Temperature is the interest rate on Bean loans.

The Morning is the first 5 minutes of each Season. Beanstalk changes the Soil and Temperature throughout the Morning according to the peg maintenance mechanism.

Soil

Anytime Beanstalk is willing to issue debt, there is Soil in the Field. Soil represents the number of Beans that Beanstalk is currently willing to borrow.

When Beans are Sown, Beanstalk burns them, permanently removing the Sown Beans from the Bean supply. For example, if there's 10 Soil available and 10 Beans are Sown, the Soil supply becomes 0 and 10 Beans are removed from the Bean supply. If the market is in some sort of equilibrium, Beans are bought to be Sown, which drives the Bean price upward towards its value peg.

Pods

Beans are Sown in exchange for Pods, the Beanstalk-native debt asset. Loans to Beanstalk are issued with a fixed interest rate, known as Temperature, and an unknown maturity date.

Temperature

The Temperature is the interest rate for Sowing Beans in the Field. At 500% Temperature, 1 Bean can be Sown in exchange for 6 Pods. Once those Pods become Harvestable, they can be Harvested in exchange for 6 Beans.

Field Process

1. Beans are Sown in exchange for Pods.

2. Pods Ripen into Harvestable Pods on a FIFO basis when Beanstalk mints new Beans according to the peg maintenance mechanism.

3. Harvestable Pods can be Harvested into Beans.

Economics

Beanstalk is credit based and only fails if it can no longer attract creditors. A reasonable level of debt, a strong credit history and a competitive interest rate attract creditors.

The combination of non-expiry, the FIFO Harvest schedule and transferability encourages Farmers to Sow Beans as efficiently as possible. By maximizing the efficiency of the Soil market, Beanstalk minimizes its cost to attract creditors, the durations and magnitudes of price deviations below its value peg, and excess Bean minting.

On April 17, 2022, Beanstalk was exploited via a governance attack. The attacker used a flash loan to exploit the protocol’s then on-chain governance mechanism and transferred all of the Deposited assets in the Silo to an address they controlled, resulting in a theft of ~$77M in non-Bean assets.

The Barn is the Beanstalk recapitalization facility used to Replant Beanstalk. The Barn Raise started on June 6, 2022 while the protocol was offline.

Timeline

• April 17, 2022: Governance exploit

• June 6, 2022: Barn Raise starts

• August 6, 2022: Beanstalk Replant

• October 20, 2023: Migration of Unripe liquidity from BEAN:3CRV to the BEAN:ETH Well

• July 26, 2024: Migration of Unripe liquidity from BEAN:ETH to BEAN:wstETH

Fertilizer

Fertilizer is a semi-fungible limited debt issuance to recapitalize $77M in stolen liquidity.

At the beginning of the Barn Raise, there was 77M Available Fertilizer. Available Fertilizer is the number of Fertilizer that can be bought from Beanstalk in exchange for 1 USD worth of wstETH each. Fertilizer becomes Active when it is bought, at which point the ERC-1155 Fertilizer token is minted.

Active Fertilizer comes with an associated number of Sprouts. Sprouts represent the debt left to be repaid to Active Fertilizer holders. Fertilizer becomes Used after all of its associated Sprouts are Fertilized into Rinsable Sprouts that can be Rinsed (redeemed) for 1 Bean each.

• If Fertilizer is not sold yet, it’s Available.

• If Fertilizer still has Sprouts (is owed Bean mints), it’s Active.

• If Fertilizer has no more Sprouts (is done earning Bean mints), it’s Used.

When Fertilizer is sold, Beanstalk adds liquidity to the BEAN:wstETH Well at a ratio of 1:0.866616. Adding liquidity at this ratio causes the deltaB in the BEAN:wstETH Well to trend towards the pre-exploit deltaB.

Humidity

The Humidity is the interest rate on Fertilizer purchases. At 200% Humidity, each Fertilizer purchased comes with 3 Sprouts.

Barn Process

1. Fertilizer is bought with wstETH. Active Fertilizer comes with Sprouts.

3. Rinsable Sprouts can be Rinsed to be redeemed for Beans.

Unripe Assets

Beanstalk uses the proceeds from the Fertilizer sales to recapitalize liquidity stolen from Silo Members in the April 17th, 2022 governance exploit. Beanstalk will sell enough Fertilizer to fully recapitalize all non-Bean liquidity stolen from Silo Members.

Prior to Replant, Farmers who held Beans in the block prior to the exploit received 1 Unripe Bean for every pre-exploit Bean; Farmers who held whitelisted LP Tokens in the block prior to the exploit received 1 Unripe LP for every 1 Bean Denominated Value (BDV) of each pre-exploit whitelisted LP Token.

For example, a Farmer with 1000 Beans and 2000 BDV of whitelisted LP tokens in the block prior to the exploit received 1000 Unripe Beans and 2000 Unripe LP.

Unripe assets are placed on a vesting schedule in accordance with the success of the Barn Raise and growth of the Bean supply thereafter.

Ripe Assets

More specifically, Unripe assets entitle holders to an associated number of underlying Ripe assets. Ripe Beans and Ripe BEAN:wstETH are minted as Fertilizer is sold.

Chopping

The percentage of Ripe assets that can be claimed by Chopping a pro rata portion of Unripe assets is a the [% recapitalization]^2, where the % recapitalization represents the amount of Ripe assets per Unripe.

Chopped Unripe assets are burned. Beans and BEAN:wstETH LP received for Chopping are distributed from the set of Ripe Beans and Ripe BEAN:wstETH LP, respectively.

For example, if there are 0.22 Ripe Beans for every Unripe Bean, an Unripe Bean can be Chopped in exchange for 0.0484 Ripe Beans.

Because Available Fertilizer is a function of how much non-Bean liquidity still needs to be recapitalized, if Available Fertilizer is non-zero and Unripe BEAN:wstETH LP is Chopped, the amount of Available Fertilizer (and thus how much non-Bean liquidity Beanstalk needs to recapitalize) decreases. The same is true of Conversions from Unripe BEAN:wstETH LP to Unripe Beans in the Silo, while the converse is true of Conversions from Unripe Beans to Unripe BEAN:wstETH LP.

For example, say there’s 50M Available Fertilizer and a Farmer Chops 2M Unripe BEAN:wstETH LP in exchange for 1M BEAN:wstETH Well LP. If non-Beans make up 50% of the BEAN:wstETH Well by dollar value, then 500k less Fertilizer needs to be sold, resulting in 49.5M Available Fertilizer.

Revitalized Assets

Upon Replant, Silo Members in the block prior to the exploit received a portion of their Stalk and Seeds based on the percentage of Fertilizer sold prior to Replant. As the BDV of Unripe assets increases, additional Stalk and Seeds become Revitalized and can be Enrooted. Revitalized Stalk and Seeds start earning Bean seigniorage and Grown Stalk, respectively, upon being Enrooted.

If 20% of total Fertilizer has sold before Replant, a Silo Member receives 20% of their Stalk, Seed and Plantable Seed balances at the time of the Replant. As an example, if the percentage of Fertilizer sold increases by 5%, the additional 5% is distributed to the Silo Member in the form of Revitalized Stalk and Seeds. Once Enrooted, a Silo Member brings their balances to 25% of their pre-exploit Stalk and Seed balances, independent of any Stalk or Seeds they may have earned since Replant.

The Silo is the Beanstalk DAO. The Silo uses the Stalk System to create protocol-native financial incentives that improve Beanstalk’s security and Bean’s liquidity and stability.

Anyone can become a Silo Member by Depositing whitelisted assets in the Silo to earn Stalk and Seeds. Neither Stalk nor Seeds are liquid. Deposits are represented as ERC-1155 standard tokens.

Deposit Whitelist

To be Deposited into the Silo, an ERC-20 standard token must be on the Deposit Whitelist.

1. The token address;

2. A function to calculate the Bean Denominated Value (BDV) of the token; and

3. The number of Stalk issued per BDV;

4. The number of initial Gauge Points (which determine Grown Stalk issuance across various LP tokens);

5. An oracle for calculating the price on the non-Bean asset in the Well;

6. A function to calculate how the Gauge Points change each Season;

8. The optimal percentage of Deposited LP BDV.

Current Deposit Whitelist

The Stalk System

Stalkholders are entitled to participate in Beanstalk governance and earn a portion of Bean mints. Governance power and distribution of Bean mints are proportional to each Stalkholder's Stalk balance relative to total outstanding Stalk.

Older Deposits have their Stalk ownership diluted by newer Deposits upon Deposit. Stalk ownership, and each Stalkholder's share of Beanstalk governance voting power, decentralizes over time. Therefore, newly minted Beans are more widely distributed over time. A design that lowers the Gini coefficient of Beans and Stalk is essential to censorship resistance.

Germination

*Stalk is rewarded to a Deposit 2 gm calls after Deposit. In the interim, new Deposits are considered Germinating. Germinating Deposits can be Withdrawn or Transferred, but cannot be Converted.

Germination adds flash loan and inter-block MEV manipulation resistance to the calculation of Deposited BDV (used by the Seed Gauge System). By preventing the accrual of Earned Beans for 1 full Season, Beanstalk further disincentivizes inorganic demand.

The Seed Gauge System

Seeds generate opportunity cost for Withdrawing assets that have been Deposited for longer and marginal benefit for holding particular assets in the Silo in the form of Grown Stalk.

There are 3 new primary tools that Beanstalk has at its disposal as a result of the Seed Gauge System:

1. The Target Seasons to Catch Up, which determines the target number of Seasons for a new Deposit with an average number of Seeds to catch up to the average Grown Stalk per BDV of existing Deposits at the time of Deposit;

3. LP vs LP Seed distribution, which determines relative benefits of holding a given non-Bean asset in the Silo over time.

Withdraw

The associated amount of Stalk, Seeds, and Stalk from Seeds from a given Deposit must be forfeited when the Deposit is Withdrawn from the Silo. The requirement to forfeit Stalk that has grown from Seeds over time creates an opportunity cost to leave the Silo, thereby increasing the stickiness of Deposits the longer they stay Deposited.

Deposits can be Withdrawn from the Silo at any time. Deposits can be Transferred to another address directly without the loss of Stalk, Seeds, and Stalk from Seeds.

Convert

Conversions within the Silo between Bean and LP Deposits serve a major role in peg maintenance. LP Deposits can also be Converted to other LP Deposit types for a potential gain in Stalk and/or Seeds. Conversions from one Deposited asset to another are permissioned by a Convert Whitelist.

Governance

Silo Rewards

Earned Beans are Beans that have been paid to a Silo Member since the last Season the Silo Member Planted their Plantable Seeds (defined below). Upon Plant, Earned Beans are Deposited in the current Season.

Earned Stalk are Stalk earned from Earned Beans. Earned Stalk automatically contribute to Stalk ownership and do not require any action to claim them.

Grown Stalk is the Stalk earned from Seeds. Grown Stalk does not contribute to Stalk ownership until it is Mown. Mow can be called on its own, and it is also called at the beginning of any Silo interaction (Depositing, Withdrawing, Converting, Planting, etc.).

Plantable Seeds are Seeds earned in conjunction with Earned Beans. Plantable Seeds must be Planted in order to grow Stalk.

Beanstalk is a permissionless fiat stablecoin protocol built on Arbitrum.

Beanstalk forms the monetary basis of an Arbitrum-native, rent-free economy facilitated by the seigniorage of its native fiat currency, a stablecoin called Bean.

A stablecoin that does not compromise on decentralization nor require collateral, has competitive carrying costs, and trends toward more stability and liquidity, will unlock the potential of DeFi. Beanstalk's primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.

You can find an overview of why Beanstalk was created here:

Links

The Farm is the Beanstalk ecosystem. Anyone can become a Farmer by interacting with Beanstalk.

The Farm has four primary components: the Sun, Silo, Field and Toolshed.

Pods

Sellers can List Pods or Fill open Pod Orders placed by buyers.

Buyers can Order Pods or Fill open Pod Listings placed by sellers.

Pod Listings

Pods from Beans Sown in a single transaction form a Plot. Anyone with a Plot can List a whole or partial Plot for sale in exchange for Beans. This is known as a Pod Listing. Pod Listings have the following inputs:

1. Plot

Farmers may own multiple Plots. Plots are identified by their place in the Pod Line.

2. Position within the Plot

As Pods are Harvested on a First In, First Out (FIFO) basis, if less than a whole Plot is Listed, the seller must choose which Pods within the Plot to List. A seller can List any contiguous set of Pods within a Plot. If only a portion of a Plot is Listed, the seller must choose which subset of Pods within that Plot are for sale. In the example above, the last 2,000 Beans in the Plot are Listed, while the first 2,000 (i.e. Pods 0 - 2,000) remain in the seller’s possession.

3. Price per Pod

The sale price of each Pod, denominated in Beans.

4. Expiration

The number of Pods that can Harvest before the expiration of the Listing. Setting this input to 30M Pods would remove this Listing from the Pod Market once 30M Pods are Harvested after the creation of the Listing.

A Pod Listing can be Cancelled at any time until it is entirely Filled. Plots can only be Listed in a single Pod Listing at a time. Pod Listings are automatically Cancelled if the owner of the Plot transfers or re-Lists any Pods in the Plot.

A Pod Listing can be entirely or partially Filled at any time by a buyer. If the Pod Listing is partially Filled, the rest of the Pod Listing remains Listed.

Pod Orders

A Pod Order is an offer to buy Pods at a given price, before a given place in the Pod Line. Any seller may Fill a Pod Order by selling Pods according to the terms of the Order.

Anyone with Beans can Order Pods by creating a Pod Order. A Pod Order has the following inputs:

1. Maximum number of Pods to be purchased

Because Pod Orders can be partially or entirely Filled at any time by a seller, a Pod Order defines the maximum number of Pods the buyer would like to purchase at a given price.

2. Price per Pod

The price to be paid for each Pod, denominated in Beans.

3. Maximum place in the Pod Line

A Pod Order with a maximum place in the Pod Line of 140.0M could be Filled by any Pods with a position in the Pod Line of 140.0M or earlier. In general, Pods closer to the front of the Pod Line are more valuable, as they become Harvestable for Beans sooner due to the FIFO Harvest schedule.

A Pod Order can be Cancelled at any time until it is Filled. To facilitate instant clearance, Beans are locked in a Pod Order until it is entirely Filled or Cancelled. If the Pod Order is partially Filled, the rest of the Pod Order remains Listed.

Current complex interactions with Arbitrum-native protocols are tedious, cumbersome and expensive. The Depot facilitates complex, gas-efficient interactions with other Arbitrum-native protocols in a single transaction.

Pipeline

• pipe(...)

• multiPipe(...)

• advancedPipe(...)

Direction

The current state of Beanstalk is in part determined by the direction of change with respect to ideal equilibrium.

When the deltaB over the previous Season is > 0, debt is paid back. Therefore, if there is more debt than optimal, Beanstalk is moving toward the ideal equilibrium. If there is less debt than optimal, Beanstalk is moving away from the ideal equilibrium.

When the deltaB over the previous Season is < 0, debt can only increase or remain constant. Therefore, if there is more debt than optimal, Beanstalk is moving away from ideal equilibrium. If there is less debt than optimal, Beanstalk is moving toward ideal equilibrium.

Demand for Soil

Demand for Soil is a factor in the acceleration of Beanstalk with respect to ideal equilibrium, which affects Maximum Temperature changes. Demand for Soil is considered decreasing, steady or increasing.

Based on this ratio of the number of Sown Beans over the prior two Seasons, or Delta Demand:

• If Delta Demand < 95%, demand for Soil is decreasing.

• If 95% ≤ Delta Demand < 105%, demand for Soil is steady.

• If 105% ≤ Delta Demand, demand for Soil is increasing.

However, when there is between 0 and 1 Soil remaining at the end of any Season, the ratio is not used. Instead, Beanstalk checks the following conditions to determine the current demand for Soil:

• After one or more Seasons in which there was > 1 Soil remaining, if there is between 0 and 1 Soil remaining at the end of the latest Season, demand for Soil is increasing.

• When there is at most 1 Soil remaining in consecutive Seasons, the difference in time it takes for the excess Soil (S > 1) to be Sown over the previous two Seasons can provide a more accurate measurement.

  • If S > 1 was Sown in the first 10 minutes of the previous Season, demand for Soil is increasing.

Acceleration

The current state of Beanstalk with respect to ideal equilibrium is in part determined by the acceleration of change.

The acceleration of Beanstalk affects the magnitude of Maximum Temperature changes and is considered decelerating, steady or accelerating based on the price over the previous Season and the demand for Soil.

Current and Optimal State

Based on a combination of Beanstalk’s direction and acceleration, Beanstalk has six potential current states:

• Accelerating away from ideal equilibrium;

• Accelerating toward ideal equilibrium;

• Steady away from ideal equilibrium;

• Steady toward ideal equilibrium;

• Decelerating away from ideal equilibrium; and

• Decelerating toward ideal equilibrium.

Beanstalk’s optimal state is that which moves Beanstalk toward ideal equilibrium in the healthiest fashion, given the current position.

When the debt level is excessively high or low, an optimal state is accelerating toward ideal equilibrium. When the debt level is reasonably high or low, an optimal state is either steady or decelerating toward ideal equilibrium.

Considering the current state and the debt level, Beanstalk adjusts the Maximum Temperature to move toward the optimal state:

Morning

Beanstalk faces the fundamental limitation that it cannot fix the Bean price at its value peg, but instead must encourage widespread participation in peg maintenance through protocol-native financial incentives. Stability is a function of how regularly the price of a Bean oscillates across its peg and the magnitude of price deviations from it.

Beanstalk has five direct peg maintenance tools available:

Ideal Equilibrium

Beanstalk is in ideal equilibrium when the Bean price, the debt level and liquidity level are all stable at their optimal levels. In practice, this requires that four conditions are met:

1. The price of Bean is regularly oscillating around the peg;

2. The Beanstalk debt level is optimal;

3. The Beanstalk liquidity level is optimal; and

4. Demand for Soil is steady.

In order to return to ideal equilibrium, Beanstalk affects the supply of and demand for Beans in response to the Bean price, the Beanstalk debt level, the Beanstalk liquidity level and changing demand for Soil. It does so by adjusting the Bean supply, Soil supply, Temperature and Crop Ratio.

Bean supply increases primarily affect the Bean price. Soil supply impacts the Bean supply and the debt level. Temperature changes primarily affect demand for Soil. Crop Ratio changes primarily affect demand for Conversions.

In order to make the proper adjustments, Beanstalk reassesses the states of both the Bean and Soil markets at the beginning of each Season.

In practice, maintaining ideal equilibrium is impossible. Deviations from ideal equilibrium are normal and expected. As Beanstalk grows, the durations and magnitudes of deviations are expected to decrease.

Decentralized Price Oracle

Beanstalk's core objective is to oscillate the price of Bean above and below its dollar peg. To do this, Beanstalk must be able to reliably measure the price of a dollar on-chain without trusting a centralized third-party to provide it. A robust, decentralized stablecoin requires a tamper-proof, manipulation-resistant and decentralized price oracle.

P > Q

Price spikes makes Beans less attractive to borrow and price other assets against. Beanstalk should be more aggressive in returning the price to peg when the price reaches a particular threshold above $1. Currently Q is set to $1.05, a reasonable threshold while the Bean supply is small. It does not seem that there is a natural opposite to Q when P < 1.

Debt Level

Beanstalk defines a handful of Pod Rate ranges that it uses as an input to determine how to change the Temperature:

• Excessively low debt: Pod Rate < 5%

• Reasonably low debt: 5% ≤ Pod Rate < 15%

• Optimal level of debt: Pod Rate = 15%

• Reasonably high debt: 15% < Pod Rate ≤ 25%

• Excessively high debt: Pod Rate > 25%

Liquidity Level

The Liquidity to Supply Ratio (L2SR) represents the Beanstalk liquidity level relative to the Bean supply. The L2SR is a useful indicator of Beanstalk's health.

In the context of the L2SR, liquidity is defined as the sum of the USD values of the non-Bean assets in each whitelisted liquidity pool multiplied by their respective liquidity weights. Supply is defined as the total Bean supply minus Locked Beans (defined below).

Beanstalk can be in 4 different states in relation to its L2SR:

• Excessively low liquidity: L2SR < 12%;

• Reasonably low liquidity: 12% ≤ L2SR < 40%;

• Optimal level of liquidity: L2SR = 40%

• Reasonably high liquidity: 40% < L2SR ≤ 80%; or

• Excessively high liquidity: L2SR > 80%.

Locked Beans

Due to the Barn Raise and the associated Beans underlying Unripe assets, the number of tradable Beans does not equal the total Bean supply. As of May 2024, ~0.224 Beans underlying each Unripe Bean, but holders can only redeem ~0.0102 Beans per Unripe Bean. Thus, ~0.2138 Beans Per Unripe are considered not tradable.

By excluding Locked Beans from the Bean supply in the L2SR calculation, Beanstalk can determine its health in terms of liquidity based on only the number of Beans that can reasonably be sold. This is preferable over factoring in Beans that cannot be sold.

Bean Supply

Soil Supply

When the Bean price is below peg (i.e., deltaB is negative), Deposited LP tokens may be Converted to Deposited Beans without forfeiting grown Stalk from Seeds or any Stalk due to LP impermanent loss. This Conversion allows Stalkholders to remove excess Beans from liquidity pools and increase the price back towards peg without leaving the Silo, minimizing debt issuance.

Convert Whitelist

In order for a Farmer to be able to Convert a Deposited asset to another, that Conversion must be on the Convert Whitelist.

1. The From token address;

2. The To token address;

3. Conditions under which the From token can be converted to the To token; and

Current Convert Whitelist

Performance

Generalized Convert

Stalk Penalty

Generalized Convert introduced 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 was 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.

Current Flood Whitelist

The Toolshed offers a suite of tools for efficient use of Beanstalk and other Arbitrum-native protocols.

The Beanstalk Immunefi Committee, or BIC, determines the categorization and payout of bug bounties in accordance with the bug bounty program structure approved by the Beanstalk DAO.

The Immunefi Bug Bounty Program is primarily focused preventing loss of Farmers' Beanstalk assets in Beanstalk and other ecosystem smart contracts.

Immunefi Program

In summary:

• The max bounty is 1,100,000 Beans;

• Bugs are categorized as Critical, High or Medium severity;

• The BIC determines whether a whitehat is entitled to a bug bounty/reward, and if so, the amount of such bounty/reward according to the defined bug bounty program structure; and

• Immunefi serves as a mediator in cases where a whitehat disputes the BIC's determination of whether the whitehat is entitled to any bug bounty/reward, or what the appropriate bounty/reward should be within each Impact range.

Security is paramount to the success of Beanstalk. Immunefi is crypto's leading bug bounty platform that many other well-known DeFi protocols use to facilitate their bug bounty programs. This bounty program is competitive with the largest programs currently on Immunefi.

This program establishes a method for the reporting and fixing bugs in a way that minimizes the risk to Beanstalk (and other ecosystem contracts) between the report and the fix, as well as the fair and transparent compensation for the reporting of bugs. The program gives bounty hunters a clear process and structure in order to increase the likelihood they attempt to find issues with Beanstalk and its related contracts and code.

Having several members on the BIC and requiring a majority vote to execute bug bounty payments increases decentralization.

Responsibilities

The BIC has the following primary responsibilities:

• Following the processes outlined in Response Process; and

• Updating the Immunefi Bug Bounty Program when necessary.

The BIC may update the Immunefi Bug Bounty Program without a proposal in the following cases:

• Adding/removing assets as in scope, particularly adding contracts that have been audited and/or have attracted large amounts of Beans/BDV;

• Adding/removing impacts as in scope;

• Adding/removing rules to the Out of Scope section;

• Adding documentation and links; and

• Updating language to improve clarity.

Any other changes to the Immunefi Bug Bounty Program require a BOP (or BIP).

Changing Members

In the event that one or more members are deemed unfit for the BIC (or a member voluntarily chooses to be removed), the BIC will rotate them out and replace them with a backup member approved by the DAO (no Snapshot proposal required).

Response Process

The following outlines the process that the BIC follows upon receipt of a bug report.

Immediate Response

After a bug report is submitted through the Immunefi Dashboard, all BIC Members are notified via email.

As mentioned in the bug bounty program, in order to be considered for the maximum potential reward, bug reports must come with a Proof of Concept (PoC).

In response to each bug report, the BIC will immediately evaluate the validity and severity of the bug, as well as the PoC if included in the bug report.

Bug Fix

For Beanstalk and Basin UI bug reports, the BIC will work with Beanstalk Farms to resolve the issue.

BIR Proposal

As soon as possible after completing the above, the BIC will prepare, but not publish, a BIR, which includes:

• Whether the bug report qualifies for a Critical, High or Medium Impact bounty/reward;

• What the potential practicable economic damage of the bug is (if categorized as Critical or High Impact);

• What the appropriate bounty/reward should be within the Impact range; and

• Whether the whitehat is entitled to a bug bounty/reward, and if so, the amount of such bounty/reward.

In instances where there are multiple bugs reported in the same report, a BIR will be prepared for each bug.

Before a BIR is proposed, its contents are confirmed with the submitter of the bug report via the Immunefi platform. As outlined in the bug bounty structure, in certain instances where the submitting party disputes the BIC’s proposal, Immunefi mediates.

If the bounty/reward is less than 50,000 Beans, the BIC may pay the bounty without formally voting on the BIR on Snapshot.

If the bounty/reward is greater than or equal to 50,000 Beans, as soon as possible after the implementation of a fix by the BCM, the BIC will:

• Publish the BIR to Snapshot;

• Announce the existence of the BIR to the Beanstalk community via the Discord; and

• Vote on the BIR.

BIR Exection

Once a BIR passes, the BICM executes it by:

• Transferring Beans in the Immunefi Vault to the submitting party’s address.

• • Examples: USD Coin, Tether, BinanceUSD

• • Examples: wETH, Liquity, MakerDAO, Abracadabra

• • Examples: N/A

• • Examples: Olympus

• • Examples: N/A

• • Examples: Terra

• • Examples: US Dollars

• • Examples: Beanstalk, Ampleforth

Additionally, implementations of exogenous value convertible stablecoin protocols with fractional reserves are considered:

• • Examples: Bank Notes

• • Examples: Frax

Exogenous Value Stablecoins

Non-network-native exogenous value convertible stablecoin protocols

Non-network-native exogenous value convertible stablecoin protocols issue tokens that are supposedly collateralized by, and require a custodian that facilitates the convertibility to, non-network-native exogenous value worth at least 100% of total outstanding protocol liabilities. These protocols function as low-volatility permissioned bridges between their respective networks and the rest of the world.

Users of non-network-native exogenous value convertible stablecoins sacrifice trustlessness and carry: third parties custody the non-network-native assets, can freeze the network-native assets unilaterally and can retain yield earned on collateral. The absence of protocol-native opportunities for carry limits liquidity.

Trustlessness: Permissioned

Carrying Costs: Non-competitive as compared to the asset being pegged to, but best among exogenous value convertible stablecoins

Volatility: Best among exogenous value stablecoins, but frictions around convertibility remain significant, leading to imperfect peg maintenance

Liquidity: Best among exogenous value stablecoins, but limited by opportunity cost of using off-chain collateral as capital

Network-native exogenous value convertible stablecoin protocols

Network-native exogenous value convertible stablecoin protocols use excess network-native collateral to remove most points of centralization. Overcollateralization removes most risk associated with the volatility of the collateral but by necessity requires the introduction of rent payments in order to prevent the value of the stablecoin from trending towards the value of the underlying collateral. The combination of collateral requirements and rent payments significantly limits the potential liquidity of these stablecoins.

Trustlessness: Can be totally permissionless; collateral distribution is the primary determinant of trustlessness

Carrying Costs: Non-competitive as compared to the asset being pegged to, unless at the expense of volatility

Volatility: Very low volatility when factoring in frictions around convertibility, unless in order to improve the competitivity of carrying costs

Liquidity: Limited by available network-native collateral, particularly trustless network-native collateral

Non-network-native exogenous value non-convertible stablecoin protocols

Examples: N/A

Convertibility is the main source of low price volatility and confidence in the custodian. Therefore, it is unlikely that a non-network-native exogenous value non-convertible stablecoin protocol will find product market fit.

Trustlessness: Permissioned

Carrying Costs: Non-competitive as compared to the asset being pegged to

Volatility: Speculation on the trustworthiness of the custodian of collateral will be higher due to the lack of convertibility, which should lead to more price volatility

Liquidity: Limited by opportunity cost of using off-chain collateral as capital, but less so because the custodian is unencumbered by the limited asset allocations necessary to facilitate convertibility

Network-native exogenous value non-convertible stablecoin protocols

Convertibility is the main source of low price volatility. The main benefit of collateralization is low price volatility, the majority of which is forfeited in the absence of convertibility. Therefore, it is unlikely that a network-native exogenous value non-convertible stablecoin protocol will find product market fit.

Trustlessness: Can be totally permissionless; collateral distribution is the primary determinant of trustlessness

Carrying Costs: Non-competitive as compared to the asset being pegged to, but potentially better than network-native exogenous value convertible stablecoin protocols because of the ability to take more risk with the underlying collateral at the cost of volatility

Volatility: There exists some tradeoff between carrying costs and volatility, dependent on protocol design

Liquidity: Limited by available network-native collateral, particularly trustless network-native collateral

Non-network-native exogenous value fractional reserve convertible stablecoin protocols

Examples: Bank Notes (not implemented on any decentralized networks to date)

Credit-based non-network-native exogenous value convertible stablecoin protocols most closely resemble traditional bank notes. The introduction of fractional reserves to create competitive carrying costs is a well documented historical phenomenon. The lending out of collateral creates yield that can be passed onto the users of the fractional reserve notes. However, the combination of convertibility and fractional reserves creates an asset liability duration mismatch that can lead to complete collapse. Fractional reserves are another example of currencies trading volatility for carry.

Trustlessness: Permissioned

Carrying Costs: Competitive as compared to the asset being pegged to, at the expense of tail risk in volatility

Volatility: Low volatility when factoring in frictions around convertibility; exposure to bank runs

Liquidity: Limited by available collateral

Network-native exogenous value fractional reserve convertible stablecoin protocols

The use of fractional reserves by network-native exogenous value convertible stablecoin protocols has been used in an attempt to help remediate the negative effect on carrying costs of collateral requirements. However, the network-native nature of the system makes lowering the collateralization ratio difficult without spurring a bank run. While fractional reserve implementations of network-native exogenous value convertible stablecoins offer competitive carrying costs as compared to non-fractional reserve implementations, they do so at the cost of tail risk in volatility.

Trustlessness: Can be totally permissionless; collateral distribution is the primary determinant of trustlessness

Carrying Costs: Can be competitive as compared to the asset being pegged to at lower collateralization ratios

Volatility: Low volatility when factoring in frictions around convertibility; exposure to bank runs

Liquidity: Limited by available network-native collateral, particularly trustless network-native collateral

Summary

Convertibility to exogenous value is the primary source of low price volatility, but it comes at the cost of competitive carrying costs and liquidity. In most implementations, trustlessness is sacrificed for deeper liquidity.

Businesses built on trustless primitives cannot compete with businesses built on centralized systems due to non-competitive carrying costs on low-volatility network-native trustless assets.

Endogenous Value Stablecoins

Non-network-native endogenous value convertible stablecoin protocols

Examples: N/A

It is difficult for network-native protocols to create and facilitate the conversion to non-network-native value. Therefore, it is unlikely that non-network-native endogenous value convertible stablecoin protocols find product market fit.

In theory, this would be like a private company issuing a stablecoin that is convertible to company stock at market price.

Trustlessness: Permissioned

Carrying Costs: Can be competitive as compared to the asset being pegged to, but the issuer must create more than enough endogenous value to facilitate the carry

Volatility: Likely to maintain a tight peg due to convertibility, but exposed to collapse in the instance the issuer’s endogenous value source falters, or is expected to falter

Liquidity: Limited by the endogenous value of the issuer

Network-native endogenous value convertible stablecoin protocols

To date, implementations of network-native endogenous value convertible stablecoin protocols have failed to regularly cross their stablecoin price over their value peg. This is primarily due to the fluctuation in value of endogenous value. The convertibility to endogenous value typically correlates with decreases in endogenous value, which creates excess reflexivity. It is unclear whether network-native endogenous value convertible stablecoin protocols can succeed.

Trustlessness: Permissionless

Carrying Costs: Can be competitive as compared to the asset being pegged to, but the issuer must create more than enough endogenous value to facilitate the carry

Volatility: Likely to maintain a tight peg due to convertibility, but exposed to collapse in the instance the issuer’s endogenous value source falters, or is expected to falter

Liquidity: Limited by the endogenous value of the issuer

Non-network-native endogenous value non-convertible stablecoin protocols

Examples: US Dollars

The current financial system (i.e., fiat money) can be thought of as an implementation of credit-based non-network-native endogenous value non-convertible stablecoin protocols, where the fiat money is pegged to a time-weighted discount of its current purchasing power. The non-network-native nature of the credit of the issuer introduces significant sacrifices to trustlessness.

Trustlessness: Permissioned

Carrying Costs: Very competitive

Volatility: Determined by a variety of factors; sufficiently low volatility is a prerequisite to adoption

Liquidity: Limited by the creditworthiness of the issuer

Network-native endogenous value non-convertible stablecoin protocols

The value of fiat currency is derived from its utility and the credit of its issuer. Utility of fiat currency is a function of trustlessness, carrying costs, stability and liquidity. Decentralized credit can be used to issue a permissionless fiat stablecoin with competitive carrying costs, low volatility and deep liquidity.

Credit-based network-native endogenous value non-convertible stablecoin protocols are network-native implementations of fiat currency. The value of such assets derive from the credit of its issuer, which exists in a network-native capacity. The network-native nature of the credit creates value in a trustless fashion. The creation of endogenous value through credit facilitates competitive carrying costs. A strong series of network-native incentives and diverse network of creditors can create price stability and deep liquidity without collateral requirements.

Credit-based network-native endogenous value non-convertible stablecoin protocols present an opportunity to achieve trustlessness, competitive carrying costs, low price volatility and deep liquidity. The use of network-native credit can eliminate the negative carrying costs and reduce the excess price volatility associated with rebasing stablecoin protocols.

Summary

Convertibility to endogenous value prioritizes low price volatility at the expense of long term sustainability.

Rebasing tokens have shown some efficacy and peg maintenance, but not enough to create utility. The introduction of network-native credit can reduce volatility.

The current financial system runs on credit-based non-network-native endogenous value non-convertible stablecoin protocols.

Implementations of network-native endogenous value non-convertible stablecoin protocols present a viable option for the creation of trustless currency with competitive carrying costs, low price volatility and deep liquidity that can facilitate the competition between businesses built on decentralized primitives against businesses built on centralized ones.

The BCM is not intended to have decision making power. Its role is to enact on-chain the decisions Stalkholders make via off-chain voting and review and verify proposals to ensure the suggested changes are truthfully represented.

USDC from Fertilizer sales were custodied by the BCM between the beginning of the Barn Raise on June 6, 2022 and Replant on August 4, 2022.

Multisig Powers

The following functions are only callable from the owner address:

• diamondCut — Add, replace and/or remove any function(s) and/or execute an init function with a delegatecall.

• whitelistToken — Add a token to the Deposit Whitelist.

• dewhitelistToken — Remove a token from the Deposit Whitelist.

• pause — Pause Beanstalk, which makes it such that the gm function cannot be successfully called.

• unpause — Unpause Beanstalk, which allows the gm function to be successfully called at the top of the 2nd hour. The TWAP oracle and Season timer are reset as well.

• createFundraiser — Create a Fundraiser.

• transferOwnership — Transfer ownership of the Beanstalk contract to a new address.

• addUnripeToken — Add an Unripe token to Beanstalk.

Snapshot Usage

The BCM is an extension of the Beanstalk DAO. As such, the role of the BCM is to (1) enact on-chain the decisions Stalkholders make via off-chain voting and (2) review and verify proposals to ensure the suggested changes are truthfully represented.

The BCM shall not execute transactions until an associated Snapshot proposal successfully passes, apart from the exceptions outlined in the table below:

BIP Proposal and Voting

Beanstalk's governance is designed to be as permissionless as possible. Any Stalkholder with 0.1% of total Stalk may propose BIPs. If a Stalkholder wishes to propose a BIP they must complete a public proposal process before the BCM will submit a Snapshot proposal and an on-chain transaction to the BCM on their behalf.

BIP Proposal Content

BIPs can propose to (1) change the Beanstalk protocol, (2) mint Beans and/or (3) change Beanstalk governance. BIPs consist of a pull request on the Beanstalk GitHub repo that includes the following:

• A written proposal of the changes that would be implemented in the BIP, which must include:

  • A Contract Changes section that includes the facets and the init contract address in the diamondCut call, if applicable; and

  • A Beans Minted section that describes the number of Beans minted by the BIP, if applicable.

BIPs may have multiple transactions if made explicit in the written proposal.

BIP Proposal Process

The following are the processes in place for a Stalkholder to propose a BIP:

1. Submit a pull request on the public Beanstalk GitHub repo with a written proposal of the changes that would be implemented in the BIP.

2. Tag the @BCM Liaison user in the (#🏛・governance) channel in the Beanstalk Discord to create a dedicated discussion channel for the BIP.

3. Share a link to the GitHub PR and the written proposal in the newly created dedicated discussion channel.

4. Allow sufficient time for discussion of the proposal. What constitutes sufficient is at the sole discretion of the BCM.

5. Tag the @BCM Liaison user to request that the BIP be formally proposed.

7. The BCM shall then formally propose the BIP by submitting the on-chain transaction and Snapshot proposal.

9. If the BIP passes, the Signers will sign m/n signatures and execute the on-chain transaction as soon as possible. If the BIP fails to pass, the Signers will submit and execute a cancel transaction with the same nonce as soon as possible.

BIP Voting

Voting for BIPs takes place on Snapshot using Stalk at the beginning of the Voting Period that still exists.

Any Stalkholder can vote For, Abstain or Against on any BIP. In all instances, 1 Stalk equals 1 vote, and not voting or voting Abstain is equivalent to voting Against.

The Voting Period opens when the Snapshot proposal for a BIP can be voted on and ends after 7 days or once a two-thirds supermajority is reached.

If at the end of the Voting Period:

• Less than or equal to one-third of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, it fails, or

• More than one-third of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, or more than half of total outstanding Stalk is voting For, it passes.

If at any time 24 hours or more after the beginning and before the end of the Voting Period more than two-thirds of the Stalk supply votes in favor of the BIP, the BCM can execute the BIP on-chain.

BOP Proposal and Voting

Any Stalkholder with 0.1% of total Stalk may propose BOPs. If a Stalkholder wishes to propose a BOP they must complete a public proposal process before the BCM will submit a Snapshot proposal on their behalf.

BOP Proposal Content

BOPs can propose for the DAO to agree on processes that do not involve (1) changing the Beanstalk protocol, (2) minting Beans or (3) changing Beanstalk governance. BOPs consist of a pull request on the Beanstalk GitHub repo that includes the following:

BOP Proposal Process

The following are the processes in place for a Stalkholder to propose a BOP:

1. Submit a pull request on the public Beanstalk GitHub repo with a written proposal of the changes that would be implemented in the BOP.

2. Tag the @BCM Liaison user in the (#🏛・governance) channel in the Beanstalk Discord to create a dedicated discussion channel for the BOP.

3. Share a link to the GitHub PR and the written proposal in the dedicated discussion channel.

4. Allow sufficient time for discussion of the proposal. What constitutes sufficient is at the sole discretion of the BCM.

5. Tag the @BCM Liaison user to request that the BOP be formally proposed.

7. The BCM shall then formally propose the BOP by submitting the Snapshot proposal.

BOP Voting

Voting for BOPs takes place on Snapshot using Stalk at the beginning of the Voting Period that still exists.

Any Stalkholder can vote For or Against on any BOP. The Voting Period opens when the Snapshot proposal for a BOP can be voted on and closes after 7 days.

If at the end of the Voting Period:

• Less than or equal to 25% of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, it fails, or

• More than 25% of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, or more than half of total outstanding Stalk is voting For, it passes.

BIR Proposal and Voting

BIR Proposal Content

BIRs can propose to mint Beans to reward valid bug reports on Immunefi. BIRs consist of a Snapshot proposal that includes information about the bug report and has a Beans Minted section that describes the number of Beans minted to both the whitehat and Immunefi.

BIR Proposal Process

BIR Voting

The following are the processes in place for the BIC to propose and have the BCM execute a BIR:

1. The BIC shares BIR info with the BCM for them to submit a corresponding on-chain transaction.

2. The BCM shall then formally propose the BIR by submitting the on-chain transaction.

5. If the BIR passes (two-thirds majority of BIC members voting For), the Signers will sign m/n signatures and execute the on-chain transaction as soon as possible. If the BIR fails to pass, the Signers will submit and execute a cancel transaction with the same nonce as soon as possible.

Signer Best Practices

BCM Signers shall follow the best practices outlined below. It is of paramount importance that Beanstalk limits key man risk by implementing best practices with respect to multisig key custody. Signers are expected to:

1. Regularly check in with the rest of the BCM and confirm access to their wallet;

2. Maintain active communication regarding travel plans and availability in order to ensure that there are always enough Signers on call; and

3. Acknowledge their Signer duties and processes for signing off on BIPs and BIRs.

In addition to the above expectations, Signers shall follow the BCM's wallet security best practices:

1. Use a reputable hardware wallet like Trezor or Ledger;

2. Use a fresh address that doesn't have any pre-existing transactions or balances on it;

3. Set up a new passphrase on their hardware wallet device when selecting a new address to be the signing address; and

Signer Duties

Signers are expected to follow best practices and maintain active communication in order to ensure that there are always enough Signers available to execute transactions in case of an emergency. Signer duties are broken down into three stages: (1) confirming access to their wallet, (2) verifying proposed transactions and (3) executing transactions on the BCM.

As soon as possible after the Voting Period:

• If the proposal passed, Signers who have verified the transaction will sign and execute the transaction; or

• If the proposal failed, Signers with sign and execute a cancel transaction with the same nonce.

A Signer shall lose their role on the BCM (by the remaining Signers removing them) if they:

• Act against Stalkholders' off-chain voting (or the BIC's off-chain voting in the case of BIRs);

• Get through 2 votes without performing any of their Signer duties.

Verifying and Signing Transactions

All BCM Signers are expected to know how to verify diamondCut data and confirm they have verified transactions by creating an Etherscan verified message.

The following should be used as a guide for the minimum review criteria in cases where a diamondCut is being executed:

• Performing the diamondCut on a local mainnet fork and confirm that the facet addresses, function selectors and facet cut actions are correct;

• Confirming that the _init address and _calldata are correct; and

• Confirming that the deployed bytecode for changed facets matches the corresponding bytecode compiled from the GitHub PR branch.

If a situation arises where not all Signers submit a verification, the BCM may continue with execution if the Signer:

1. Was not responsive during the draft phase of the proposal or Voting Period;

2. Notified the rest of the BCM during the draft phase of the proposal that they would not be able to verify, sign or execute the transaction;

3. Missed 2 verifications;

4. Was not responsive in 2 months; or

5. Votes against the outcome of any proposal, in which case the Signer would be subject to removal immediately.

Problems During Verification

The BCM will not execute a transaction that was misrepresented in the Snapshot proposal.

In the case that any Signer during the verification process determines that a Snapshot proposal does not accurately represent the transaction, that Signer will sign an Etherscan verified message indicating as such with context on the issue.

The BCM will respond as follows:

• If the BCM determines that the Signer is "rogue" and attempting to censor the transaction, the BCM will indicate that by continuing to verify (and ultimately sign and execute, in the case that the proposal passes) the transaction; or

• If the BCM determines that the Signer is not rogue, the BCM will indicate that by submitting, signing and executing a cancel transaction with the same nonce.

In cases where the BCM cancels a transaction, the community will be notified via the Beanstalk Discord and the BCM will work with the proposer to resolve the issue. Once resolved, a new BIP will be proposed on Snapshot with its associated transaction.

Emergency Response Procedures

Although the BCM's role is to enact on-chain the decisions Stalkholders make via off-chain voting, it is of critical importance that the BCM take swift action to protect Beanstalk in the event of a bug or vulnerability. Emergency upgrades to Beanstalk submitted by the BCM are known as EBIPs.

Bugs or security vulnerabilities qualify as emergencies. Emergency action will not be taken for any reason related to the economic health of Beanstalk.

Depending on the severity of a given emergency, BCM members shall swiftly decide the best course of action:

• If a bug or vulnerability is severe and requires significant code changes to fix, the BCM may remove functions from Beanstalk and take any necessary extra action to mitigate further damage; or

• If a bug or vulnerability is minor and does not require significant code changes to fix, a hotfix may be implemented by the BCM.

After emergency action is taken, the BCM shall swiftly issue a summarized report to the community via the Beanstalk Discord detailing:

1. The administrative permissions that were used (e.g., which functions were removed);

2. The context and severity of the issue; and

3. The next steps and decisions, if any, that the community must agree on in order to proceed.

EBIP During Voting Period

In the event that an EBIP must be executed during the Voting Period of another proposal, the on-chain transaction for the outstanding proposal must be canceled.

In order avoid the need to revote on a proposal in this situation, the BCM will repropose the on-chain transaction for the outstanding proposal after the successful execution of the EBIP.

Hypernative

The BCM continues to be the owner of and the sole address capable of adding and updating functions on Beanstalk. Instances where Hypernative removes all non-diamond functions will be considered EBIPs, i.e., they will be documented as such and follow the DAO-approved procedures outlined above.

Rotating Signers

Anonymous Signers

The most significant risk associated with off-chain governance is the potential corruption of the BCM from an outside party. In order to minimize the chances of this, the Signers are anonymous. The anonymous Signers are selected by Publius. Signers will be anonymous to each other as well, apart from Publius.

In no instance shall a majority of the BCM keys be held by Beanstalk Farms contributors. Publius will collectively hold at most 1 key. The remaining keys will be held by reputable members of the Beanstalk community.

Malicious Key Holder Risk

Under this structure, it’s important to acknowledge the risk of anonymous key holders conspiring to attack Beanstalk. Because only Publius knows the identities of the anonymous Signers, Publius would be the main attack vector. If a malicious actor were to compromise Publius before conspiring to attack Beanstalk, they could be reasonably sure that their identity would never be revealed.

In order to mitigate this attack vector, the BCM institutes the following process whenever the m-of-n configuration of the BCM is changed:

• Publius will share the list of Signers and their wallets with their personal legal counsel, to be released in the event that Publius is compromised such that they cannot publicly share the list themselves. This makes Publius and their personal legal counsel the only parties with access to the list.

In the event that Publius' counsel publicly shares the list of Signers and their wallets, anyone could verify that it's the correct list by hashing it and comparing it with the hash on Etherscan. This creates accountability for the anonymous Signers.

Beanstalk Farms is a decentralized development organization of core contributors working on Beanstalk, operating across the stack on technical and non-technical problems.

Funding

Past BIPs that funded Beanstalk Farms:

Beanstalk Farms Committee

The Beanstalk Farms Committee (BFC) is the group of Beanstalk Farms contributors that has discretion over the Beanstalk Farms budget, including contributor compensation. The BFC hires at and dismisses contributors from Beanstalk Farms.

Beanstalk Farms Committee Proposals, or BFCPs, are proposals related to personnel on the BFC. The Beanstalk DAO governs the BFC. The Beanstalk DAO adds contributors to the BFC via BFCP-As, removes contributors from the BFC via BFCP-Bs, and renews the terms of existing BFC members via BFCP-Cs.

Any Stalkholder with 0.1% of the Stalk supply can propose a BFCP-A or BFCP-B. There is no maximum number of BFC members, which facilitates permissionlessness.

Beanstalk Farms Budget Proposals, or BFBPs, are proposals related to the use of the Beanstalk Farms budget. Only BFC members can propose and vote on BFBPs.

The BFC hires contributors via BFBP-As, dismisses contributors via BFBP-Bs, and otherwise uses the Beanstalk Farms budget via BFBP-Cs.

The Beanstalk Immunefi Committee (BIC) has the exclusive ability to determine the categorization and payout of bug bounties in accordance with the bug bounty program structure approved by the DAO. BIC members serve as signers on the BICM. The BICM is deployed using Safe. Its m-of-n configuration is currently 4-of-7 on Arbitrum.

BICM Signers

The current BICM signers are as follows, in no particular order:

• aloceros

• Brean

• Chaikitty

• deadmanwalking

• funderberker

• mod323

• pizzaman1337

The following Farmers serve as backups for the BICM, in no particular order:

• uncoolzero

• MrMochi

• guy

Rotating members (to a backup member listed here) on the BIC requires a majority vote of the BIC, for which a Snapshot proposal is not necessary.

Beans Paid

Total to Whitehats: 1,536,350 Beans

Remaining in Immunefi Vault: 2,447,000 Beans

Bugs found: 21

Links

A robust decentralized governance mechanism must balance the principles of decentralization with resistance to attempted protocol changes, both malicious and ignorant, and the ability to quickly adapt to changing information. In practice, Beanstalk must balance ensuring sufficient time for all ecosystem participants to consider a Beanstalk Improvement Proposal (BIP) with the ability to be quickly upgraded in cases of emergency.

Participation

Anyone can become a Stalkholder and participate in Beanstalk governance by Depositing whitelisted assets in the Silo to earn Stalk.

A Stalkholder’s voting power is proportional to their Stalk balance relative to the total Stalk supply. Any Stalkholder can vote For or Against on any BIP. A Stalkholder's vote for a given proposal is counted as their Stalk at the beginning of the Voting Period that still exists. Stalkholders have the ability to delegate their vote to any other user.

Any Stalkholder that owns more than 0.1% of total outstanding Stalk can submit a BIP per the BIP Proposal Process. The submitter of a BIP must still own more than 0.1% of Stalk at the end of the Voting Period for the BIP to be able to pass.

Voting Period

The Voting Period opens when the Snapshot proposal for a BIP can be voted on and ends 7 days later or when it is committed with a supermajority.

If at the end of the Voting Period:

• Less than or equal to one-third of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, it fails, or

• More than one-third of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, or more than half of total outstanding Stalk is voting For, it passes.

If at any time 24 hours or more after the beginning and before the end of the Voting Period more than two-thirds of the total outstanding Stalk is voting in favor of the BIP, the BCM can execute the BIP on-chain.

Beanstalk governance is designed to move slow and steady. When trying to become an issuer of money, the potential for rapid monetary policy changes is unattractive. By requiring more than one-third of Stalk to vote in favor of a BIP for it to pass, it is quite difficult for a BIP to pass. Therefore, unless the proposed change is significantly preferred by Stalkholders, it is unlikely to pass.

Pause

When Paused, Beanstalk does not accept a gm function call. Once Unpaused, the gm function can be called at the beginning of the next hour.

Commit

BeaNFT contracts are custodied by the BeaNFT DAO Multisig, or BDM. The BDM is deployed using Safe. Its m-of-n configuration is currently 4-of-7 on Ethereum mainnet. This means any upgrade of the BeaNFT contracts must be approved by at least 4 of the 7 signers.

BDM Signers

The current BDM signers are as follows, in no particular order:

• blc

• Brean

• Safisynai

• guy

• Rex

• pizzaman1337

• MrMochi

The following people serve as backup signers for the BDM, in no particular order:

• Silo Chad

• Sowphocles

• CanadianBennett

This page is a comprehensive overview of all proposals types in Beanstalk-related governance.

Table of Contents

Notes

In all proposals where Stalkholders vote:

• A Stalkholder's vote for a given proposal is counted as their Stalk at the beginning of the Voting Period that still exists;

• 1 Stalk equals 1 vote; and

• The proposer must have at least 0.1% of total Stalk at the beginning and end of the Voting Period (including delegated Stalk) in order for the proposal to pass.

Any proposal that proposes for another party to perform work upon, or at any point after, the passage of the proposal must have that party's explicit approval.

Beanstalk Improvement Proposal

Beanstalk Improvement Proposals, or BIPs, are proposals to:

• Change the Beanstalk protocol;

• Mint Beans; and/or

• Change Beanstalk governance.

Any Stalkholder that owns at least 0.1% of total Stalk can propose a BIP. Any Stalkholder can vote For or Against a BIP.

The Voting Period opens when the Snapshot proposal for a BIP can be voted on and closes after 7 days or when it is committed with a supermajority.

If at the end of the Voting Period:

• Less than or equal to one-third of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, it fails, or

• More than one-third of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, or more than half of total outstanding Stalk is voting For, it passes.

Beanstalk Operations Proposal

Beanstalk Operations Proposals, or BOPs, are proposals for the DAO to agree on processes that do not involve (1) changing the Beanstalk protocol, (2) minting Beans or (3) changing Beanstalk governance. A BIP can include any changes that would otherwise be in a BOP.

Any Stalkholder that owns at least 0.1% of total Stalk can propose a BOP. Any Stalkholder can vote For or Against.

The Voting Period opens when the Snapshot proposal for a BOP can be voted on and closes after 7 days.

If at the end of the Voting Period:

• Less than or equal to 25% of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, it fails, or

• More than 25% of the total outstanding Stalk, plus the amount of Stalk voting Against, is voting For, or more than half of total outstanding Stalk is voting For, it passes.

Emergency Beanstalk Improvement Proposal

Emergency Beanstalk Improvement Proposals, or EBIPs, are emergency upgrades to Beanstalk. EBIPs are submitted and executed by the BCM in order to protect Beanstalk.

Beanstalk Farms Committee Proposal

Stalkholders vote to:

The Voting Period opens when the Snapshot proposal for a BFCP can be voted on and closes after 7 days.

BFCP-A

BFCP-As are proposals to add someone to the BFC. Any Stalkholder that owns at least 0.1% of total Stalk can propose a BFCP-A. Any Stalkholder can vote For or Against.

If at the end of the Voting Period:

• Less than or equal to 25% of total Stalk is voting For or the majority of participating Stalk is voting Against the BFCP-A, it fails, or

• More than 25% of total Stalk is voting For and the majority of participating Stalk is voting For the BFCP-A, it passes.

The term of a BFC member whose BFCP-A passes ends two quarters after the end of the current quarter (end of March, June, September or December). There is no guarantee that payment terms in a BFCP-A can be fulfilled until the end of a BFC member's term given that the Beanstalk DAO must continually choose to fund Beanstalk Farms.

A BFCP-A is also the proposed BFC member's hiring proposal. Therefore, a BFCP-A must contain payment information at minimum, but should also contain information about what makes the person a good candidate for the BFC, their proposed responsibilities within Beanstalk Farms, etc.

BFCP-B

BFCP-Bs are proposals to remove someone from the BFC. Any Stalkholder that owns at least 0.1% of total Stalk can propose a BFCP-B. Any Stalkholder can vote For or Against.

If at the end of the Voting Period:

• Less than or equal to 35% of total Stalk is voting For or the majority of participating Stalk is voting Against the BFCP-B, it fails, or

• More than 35% of total Stalk votes For and the majority of participating Stalk is voting For the BFCP-B, it passes.

A BFCP-B is not required if the BFC member voluntarily leaves Beanstalk Farms or the BFC.

BFCP-C

BFCP-Cs are proposals to extend the terms of current BFC members. Only BFC members can propose a BFCP-C.

BFCP-Cs are multi-choice votes where each voting choice corresponds to extending the term of a current BFC member (approval voting style).

If at the end of the Voting Period:

• Less than or equal to 25% of total Stalk is voting For a BFC member's proposal, that BFC member's proposal fails, or

• More than 25% of total Stalk is voting For a BFC member's proposal, that BFC member's proposal passes.

BFC members whose BFCP-C passes shall have their term extended by two quarters after the end of their current term, with a maximum term length of three quarters after the end of the current quarter. There is no term limit for BFC members.

BFC members have the option to update their previous hiring proposal terms in a BFCP-C. There is no guarantee that payment terms in a BFCP-C can be fulfilled until the end of a BFC member's term given that the Beanstalk DAO must continually choose to fund Beanstalk Farms.

Beanstalk Farms Budget Proposal

Only BFC members can propose and vote on BFBPs and each member has 1 vote. Any BFC member can vote For or Against.

BFC members vote to:

The Voting Period opens when the Snapshot proposal for a BFBP can be voted on and closes after 2 days.

BFBP-A

BFBP-As are proposals to hire a contributor to Beanstalk Farms.

A BFBP-A passes if at the end of the Voting Period there are at least 3 votes For, but this can be vetoed by a majority of the BFC voting Against.

Once hired via BFBP-A, a contributor's term length is indefinite unless otherwise specified. There is no guarantee that payment terms in a BFBP-A can be fulfilled indefinitely given that the Beanstalk DAO must continually choose to fund Beanstalk Farms.

Current (non-BFC) contributors only require another BFBP-A if their pay rate has increased or role/commitment has significantly changed since the terms of the proposal in effect.

BFBP-B

BFBP-Bs are proposals to dismiss a contributor from Beanstalk Farms.

If at the end of the Voting Period:

• Less than a majority of the BFC is voting For the BFBP-B, it fails, or

• At least a majority of the BFC is voting For the BFBP-B, it passes.

A BFBP-B is not required in circumstances where a contributor is leaving Beanstalk Farms voluntarily or gracefully.

BFBP-Bs shall not mention the contributor's name, but instead shall include a hash, where the input of the hash indicates the contributor being dismissed. The input of the hash shall only be shared with the BFC and the contributor in question. This allows the contributor to verify the result of the vote while preserving their privacy during the Voting Period and if the vote fails.

BFBP-C

BFBP-Cs are proposals to use the Beanstalk Farms budget outside of hiring contributors.

A BFBP-C passes if at the end of the Voting Period there are at least 3 votes For, but this can be vetoed by a majority of the BFC voting Against.

A BFBP-C is not required for payments valued at less than or equal to 25,000 Beans or USDC.

Beanstalk Immunefi Response

The Voting Period opens when the Snapshot proposal for a BIR can be voted on and closes after 3 days.

If at the end of the Voting Period:

• Less than a two-thirds majority of the BIC is voting For the BIR, it fails, or

• At least a two-thirds majority of the BIC is voting For the BIR, it passes.

BeaNFT Proposal

BeaNFT Proposals, or BNPs, are proposals through which the BeaNFT DAO votes on the direction of BeaNFTs (new collections, collection upgrades, etc.).

Anyone with 0.1% of the BeaNFT supply can propose a BNP. BNPs are voted on by BeaNFT holders and have two voting choices: For and Against. The Voting Period for BNPs is 7 days.

If at the end of the Voting Period:

• Less than or equal to 15% of the BeaNFT supply is voting For or the majority of participating BeaNFTs is voting Against the BNP, it fails, or

• More than 15% of the BeaNFT supply is voting For and the majority of participating BeaNFTs is voting For the BNP, it passes.

A BNP to create a new BeaNFT collection should include, at a minimum: (1) criteria to qualify for a BeaNFT in the new collection and (2) any rarity boost criteria. Including high level information about the theme of the collection, whether qualifying Farmers will be required to mint them, etc. is recommended. After the passage of the BNP, it is on the proposer to see through the completion of the art, the creation and deployment of the contracts, etc. Due to this, there is no guarantee that a new collection gets created after the passage of this type of BNP.

A BNP seeking to upgrade an existing BeaNFT collection should outline (1) the proposed upgrade, (2) the rationale for the upgrade and (3) any technical criteria required to be implement the upgrade.

You can read more about them here:

OpenSea:

Governance

BeaNFT Proposals, or BNPs, are proposals through which the BeaNFT DAO votes on the direction of BeaNFTs (new collections, collection upgrades, etc.).

Anyone with 0.1% of the BeaNFT supply can propose a BNP. BNPs are voted on by BeaNFT holders and have two voting choices: For and Against. The Voting Period for BNPs is 7 days.

If at the end of the Voting Period:

• Less than or equal to 15% of the BeaNFT supply is voting For or the majority of participating BeaNFTs is voting Against the BNP, it fails, or

• More than 15% of the BeaNFT supply is voting For and the majority of participating BeaNFTs is voting For the BNP, it passes.

A BNP to create a new BeaNFT collection should include, at a minimum: (1) criteria to qualify for a BeaNFT in the new collection and (2) any rarity boost criteria. Including high level information about the theme of the collection, whether qualifying Farmers will be required to mint them, etc. is recommended. After the passage of the BNP, it is on the proposer to see through the completion of the art, the creation and deployment of the contracts, etc. Due to this, there is no guarantee that a new collection gets created after the passage of this type of BNP.

A BNP seeking to upgrade an existing BeaNFT collection should outline (1) the proposed upgrade, (2) the rationale for the upgrade and (3) any technical criteria required to be implement the upgrade.

Selecting the Bean price displays more detail of the liquidity pools that Beans trade in.

The detail view shows the:

• USD denominated price of Bean in the liquidity pool;

• USD denominated total liquidity in the liquidity pool, including non-Bean assets; and

In addition to an internet connection, interacting with Beanstalk requires:

1. A supported Arbitrum wallet with an ETH balance.
2. Connecting your Arbitrum wallet to Beanstalk.

Selecting and Funding a Wallet

Arbitrum wallets are applications that let you manage your Arbitrum account. Your wallet lets you connect to decentralized applications such as Beanstalk and authorize transactions. On Arbitrum, you are responsible for the security of your own funds. If you are new to decentralized finance, it strongly recommend to research best practices in wallet security before proceeding.

Some wallets allow purchasing ETH directly within the wallet. Alternatively, send ETH from a cryptocurrency exchange to your wallet address. Make sure both sending and receiving addresses are on the Arbitrum network.

Connect to Beanstalk with MetaMask - Desktop

1. Create a MetaMask Wallet

MetaMask is an Arbitrum wallet that facilitates interaction with the Beanstalk website.

2. Select "Install MetaMask For [your browser]".

3. Select "Add to [your browser]".

4. Select "Add Extension".

5. Select "Get Started".

6. Follow the instructions to set up your MetaMask wallet. Be sure to save your Secret Recovery Phrase somewhere safe! For better security, use a hardware wallet.

7. In the top right of your browser, click the "Puzzle Piece" icon and then click the "Pin" next to the MetaMask icon to pin MetaMask to your browser toolbar. The MetaMask icon should now appear next to the puzzle piece icon.

2. Optional: Connect Your Hardware Wallet to MetaMask

1. Select the MetaMask icon and then click the circle to the right of your MetaMask address.

2. Select "Connect Hardware Wallet".

3. Select your hardware wallet.

4. Select "Connect."

5. Connect and unlock your hardware wallet.

6. Select the wallet address(es) you want to pair with MetaMask.

7. Select "Unlock".

3. Fund Your MetaMask Wallet with ETH

This step may be unnecessary if you performed Step 2.

1. Copy your MetaMask Arbitrum wallet address.

2. Send your ETH to your MetaMask wallet address from your current ETH wallet or an exchange.

4. Connect Your MetaMask Wallet to Beanstalk

2. Select "Connect Wallet" in the top right of the page.

3. Click the MetaMask icon and confirm that you are on the Arbitrum network. If not, click the down arrow at the top of the window and click "Arbitrum".

4. Congratulations, you are now connected to Beanstalk. Double check that your wallet address in the top right of the website is the same as your MetaMask wallet address.

Connect to Beanstalk with MetaMask - Mobile

2. Follow the instructions to set up your MetaMask wallet. Be sure to save your Secret Recovery Phrase somewhere safe! For better security, use a hardware wallet.

4. Select "Connect Wallet" in the top right of the page and select "MetaMask". Confirm the connection in MetaMask.

5. The "Connect" button will change into an icon representing your wallet. Congratulations, you are now connected to Beanstalk.

Connect to Beanstalk with WalletConnect

2. Click “Connect Wallet” in the top right of the page.

3. Click “WalletConnect”.

4. Scan the QR code with your mobile wallet and tap “Connect”. Or, select “Desktop” in the toggle and select your wallet of choice and follow the necessary flow.

Confirm that you are on the Arbitrum network via the network dropdown in the top right. If so, congratulations, you are now connected to Beanstalk. Double check that your wallet address in the top right of the website is the address you connected through WalletConnect.

Connect to Beanstalk with Coinbase Wallet

2. Click “Connect Wallet” in the top right of the page.

3. Click “Coinbase Wallet”.

4. If you are using the Coinbase Wallet mobile app, scan the QR code.

Confirm that you are on the Arbitrum network via the network dropdown in the top right. If so, congratulations, you are now connected to Beanstalk. Double check that your wallet address in the top right of the website is the same as your Coinbase Wallet address.

Certain transactions require approving certain smart contracts to process your transaction. When a mode is selected that requires an approval, if you have not yet approved the contract, a special notice will appear and the module will be unusable until you send an approve.

To send an approval for the transaction in question:

1. Select "Approve [Token]".

1. At the bottom of the “Assets” tab in MetaMask, select “import tokens”.

2. Select the “Custom Token” tab.

3. Under “Token Contract Address”, enter “0xBEA0005B8599265D41256905A9B3073D397812E4”. “Token Symbol” will automatically be filled with “BEAN”.

4. Select “Add Custom Token”.

5. Select “Import Tokens”.