1 of 100

Farmers' Almanac

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:

Beanstalk is an experiment. Before interacting with Beanstalk, consider reading the Disclosures prepared by the DAO.

If you are looking for complete formulas behind the different mechanisms of Beanstalk, check out the (being updated to reflect and the migration to Arbitrum).

Please share any feedback on the Farmers' Almanac in the (#📜・docs-feedback) channel in Discord. You can submit a pull request to the Farmers' Almanac yourself .

Disclosures

Before interacting with Beanstalk, consider reading the following disclosures prepared by the Beanstalk DAO. This document can be found on Arweave .

Interacting with Beanstalk involves many risks. Before interacting with Beanstalk, you should review the relevant documentation to make sure you understand how Beanstalk works, as well as information about the current state of Beanstalk. The Beanstalk DAO has created this set of disclosures to assist in the educational process. These disclosures are not exhaustive. The , the , and other Beanstalk resources, as well as participating in the Beanstalk community, can help to understand the protocol. Before participating in the protocol, everyone should do their own research, investigation and analysis.

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.

Introduction

Why Beanstalk

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.

How Beanstalk Works

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

Farm

Overview

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.

The Sun offers payment for participation in timekeeping and regular code execution. Time on the Farm is kept in Seasons.

The Silo—the Beanstalk DAO—offers passive yield opportunities to owners of Bean and other whitelisted assets for participation in governance of Beanstalk upgrades and contribution to security, liquidity and stability.

The Field offers yield opportunities to creditors for participating in peg maintenance.

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

The is the Beanstalk recapitalization facility being used to Replant Beanstalk but is not a primary component of the Farm.

Sun

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:

Increments the Season number;
Calculates deltaB, the sum of the time-weighted average shortages or excesses Beans across liquidity pools on the ;
if necessary and checks for ;

Minting Whitelist

To be included in the calculation of , a liquidity pool must be on the Minting Whitelist.

Additional liquidity pools may be added to the Minting Whitelist via . In order for a liquidity pool to be added to the Minting Whitelist, Beanstalk requires:

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

Current Minting Whitelist

Name

Address

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 implementing the Seed Gauge System:

The Target Seasons to Catchup, 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;
Bean vs LP Seed distribution, or more specifically, the , which determines the relative benefits of holding Bean exposure vs exposure to at least 1 particular LP token in the Silo over time; and

Toolshed

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

Depot
Pod Market
Tractor

Depot

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.

Any protocol with a Pipeline to the Depot can be used via Beanstalk in a single transaction. Pipelines to the Depot can be added via .

Pipeline

The Pipeline allows anyone to perform an arbitrary series of actions in the EVM in a single transaction by using

Tractor

Tractor is currently not supported in the Beanstalk UI.

Maintaining and optimizing a position in Beanstalk requires manual intervention (Mowing, Planting, Harvesting Pods and Depositing the Beans, etc.). Smaller Farmers do not necessarily have the resources to automate the execution of their Beanstalk transactions, and existing generalized function call systems (i.e., smart contract accounts, Depot + Pipeline) only support the use of assets from the sender of the transaction.

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

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

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

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

Examples

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

Peg Maintenance

Advanced

Governance

BFC Dashboard

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

BFC Members

There currently no BFC members.

Adding members to the BFC requires a BFCP-A and removing BFC members requires a BFCP-B. You can read more about BFCPs here.

Guides

Getting Started

Introductory guides on connecting to and interacting with Beanstalk.

Add Bean to MetaMask

If you have Beans in your wallet but they do not appear under “Assets” in MetaMask, you can add the Bean ERC-20 token contract as a so that MetaMask will recognize your Bean holdings. Note that MetaMask will only show your —your balances within Beanstalk can be seen on the page.

At the bottom of the “Assets” tab in MetaMask, select “import tokens”.
Select the “Custom Token” tab.

Sun

Guides on understanding the Bean price and how affects Beanstalk.

Field

Guides on interacting with .

Transfer Pods

Pods can be from one address to another directly. Note that Pods can be exchanged in a trustless fashion on .

Make sure you are on and .
Navigate to the “Field” page.

Market

Guides on using .

Balances

Guides on understanding your Beanstalk balances.

Understand My Balances

BeaNFTs

Guides on minting BeaNFTs.

Swap

Guides on trading and transferring Beans.

Governance

Guides on participating in Beanstalk governance.

Vote on Governance Proposals
Delegate Votes

Unripe Assets

Guides on claiming and redeeming your Unripe assets.

Chop Unripe Assets

Protocol Resources

Ecosystem

Community Resources

Field

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.

For guides on interacting with the Field through the Beanstalk UI, go here.

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.

When P ≥ 1 (i.e., ≥ 0), the Soil supply decreases logarithmically at the beginning of each block in the Morning. When P < 1 (i.e., deltaB < 0), Beanstalk sets the Soil supply to the minimum of (1) the deltaB calculated using the instantaneous reserves from and (2) the time-weighted deltaB over the previous Season. See the section.

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.

The number of Pods received from 1 Sown Bean is determined by the Temperature at the time of Sowing. Newly issued Pods accumulate in the back of the Pod Line. The front of the Pod Line receives 1/3 of new Bean mints when there are more than zero Unfertilized Sprouts (Sprouts are issued by the ). If there are no Unfertilized Sprouts, the front of the Pod Line receives 1/2 of new Bean mints.

Pods Ripen into Harvestable Pods that can be Harvested (redeemed) for 1 Bean each on a First In, First Out () basis. There is no penalty for waiting to Harvest Pods.

Pods are tradeable on the . Pods can also be Transferred to another address directly.

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.

Beanstalk it is willing to offer each Season at the beginning of each Season according to the peg maintenance mechanism.

of each Season, the Temperature is the result of a Dutch auction, where the Temperature increases logarithmically from 1% in the block of a successful gm function call up to the Maximum Temperature over the course of 5 minutes. During times of short-term excess demand for Soil, the Morning results in Beanstalk paying significantly less to attract creditors.

Field Process

Beans are Sown in exchange for Pods.
Pods Ripen into Harvestable Pods on a FIFO basis when Beanstalk mints new Beans according to the peg maintenance mechanism.
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.

Beanstalk never defaults on debt (although in the event of Beanstalk no longer attracting creditors, the loan maturity date would become infinitely far in the future—see ). Beanstalk is willing to issue Pods every Season.

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.

Stablecoin Overview

What is a Stablecoin?

A stablecoin is a fungible asset intended to maintain low price volatility relative to an arbitrary value peg. Oftentimes, stablecoins are pegged to the price of an off-chain currency.

A currency’s utility is a function of:

Trustlessness;
Carrying costs;
Low volatility; and
Liquidity.

Low volatility is essential to the utility of a currency. Without looking at the theoretical reasons for why this is the case, the market has clearly demonstrated its value. Since its inception with the creation of Tether – a historically very – in 2014, the stablecoin industry has grown from a fringe backwater to a decentralized finance (“DeFi”) behemoth.

The history of money tells a story of markets seeking out the least volatile assets to use as currency. The relatively brief history of DeFi tells the same story.

What is the Problem with Current Implementations of Stablecoins?

While the market has demonstrated clear demand for low volatility blockchain-native assets, the vast majority of current implementations suffer from a variety of risks and drawbacks, primarily with regard to a lack of trustlessness, negative carrying costs and thin liquidity. In other words, the only utility that has been created by current stablecoin implementations is low volatility. The absence of a decentralized currency with competitive carrying costs and deep liquidity is the main issue – in addition to high blockchain transaction costs – holding businesses producing real economic activity back from adopting decentralized financial primitives.

Businesses built exclusively on decentralized primitives have struggled to compete with businesses built on centralized financial systems like fiat USD because DeFi lacks a trustless and liquid currency with sufficiently low price volatility and competitive carrying costs.

For example, historically, have significantly exceeded . Until network-native borrowing rates are comparable to or lower than off-chain borrowing rates, DeFi will continue to struggle to attract meaningful economic activity away from TradFi.

Stablecoin Features

Current implementations of stablecoins can be conceptualized along the following three axes: value source, convertibility and network nativity.

1. Value Source: Exogenous value vs. Endogenous value

Stablecoin value can come from exogenous assets or endogenous value creation.

A stablecoin with exogenous value is one whose value is derived from another asset or basket of assets which are held by the issuer as collateral. Reliance on exogenous value generates opportunity costs associated with collateral requirements, which creates non-competitive carrying costs.

A stablecoin with endogenous value is one whose value is derived from demand for the currency. Endogenous value has the potential to facilitate the creation of trustless currency with low price volatility, competitive carrying costs and deep liquidity.

2. Convertibility: Convertible vs. Non-convertible

Convertibility is the option to exchange an asset for its underlying collateral.

A convertible stablecoin protocol is one that facilitates convertibility between its stablecoin and its underlying collateral. Arbitrage opportunities created by convertibility ensure that the stablecoin price is rarely above or below the value of the underlying collateral, once frictions around convertibility are accounted for. Convertibility comes at the expense of low liquidity and non-competitive carrying costs because of the opportunity cost associated with locking up collateral to facilitate it.

A non-convertible stablecoin protocol is one that does not facilitate convertibility between its stablecoin and any form of underlying collateral. It is impossible to keep a stablecoin price equal to its value peg at all times without low-friction convertibility. Non-convertible stablecoin protocols without collateral requirements have the potential to create endogenous value that facilitates trustlessness, competitive carrying costs and deep liquidity at the expense of volatility.

3. Network Nativity: Network-native vs. Non-network native

Network nativity refers to the source of a stablecoin’s value with regard to its network.

A network-native stablecoin is one that derives its value exclusively from the network to which it is native. Network-nativity eliminates most points of centralization from a stablecoin’s value chain.

A non-network-native stablecoin is one that does not exclusively derive its value from the network to which it is native. Non-network-nativity requires a custodian that facilitates a bridge to the network, which can introduce significant costs, complexities and points of centralization.

Economics

Beanstalk is designed from economic first principles to create a useful trustless fiat currency. Over time, trustlessness, stability and liquidity increase, while carrying costs decrease but remain competitive. The following principles inspire Beanstalk:

Low concentration of ownership;
Strong credit;
;
;
; and
.

Ownership Concentration

A design that lowers the of Beans and Stalk over time is essential to censorship resistance.

Older have their diluted relative to newer Deposits every . Therefore, newly minted Beans are more widely distributed over time.

Beanstalk does not require a pre-mine. The first 100 Beans are created when the init function is called to deploy Beanstalk.

Strong Credit

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

Beanstalk changes the to return the Pod Rate to the while regularly crossing the Bean price over its value peg. Beanstalk acts more aggressively when .

Marginal Rate of Substitution

There are a wide variety of opportunities Beanstalk has to compete with for creditors. Therefore, Beanstalk does not define an optimal Temperature, but instead .

Low Friction

Minimizing the cost of using Beans and barriers to the maximizes utility for users and appeal to creditors. The realizes the full benefits of composability on Arbitrum.

The Pod Harvest schedule allows smaller to participate in peg maintenance and decreases the benefit of large scale price manipulation. The combination of non-expiry, the FIFO Harvest schedule, transferability and a enables Sowers 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 Pod issuance.

Equilibrium

Equilibrium is a state of equivalent marginal quantity supplied and demanded. Beanstalk affects the supply of and demand for Beans to regularly cross the equilibrium price of 1 Bean over its value peg.

While Beanstalk can when the Bean price is above its value peg, Beanstalk cannot arbitrarily decrease the Bean supply when the Bean price is below it. Beanstalk relies on the codependence between the equilibria of Beans and Soil to work around this limitation.

In order to Sow Beans, they must be acquired (i.e., marginal demand for affects marginal demand for Beans). The marginal demand for Soil and Beans are functions of the Temperature and the Bean price. By , Beanstalk affects decreases in the Bean supply and changes in demand for Beans.

Incentives

Beanstalk-native financial incentives consistently increase trustlessness, stability and liquidity over time by coordinating independently financially motivated actors (i.e., Stalkholders and Sowers).

incentivizes (1) leaving assets Deposited in the Silo continuously by creating opportunity cost to assets from the Silo, (2) adding value to liquidity pools with Beans by than Deposited Beans, and (3) returning the Bean price to its value peg by allowing within the Silo without forfeiting Stalk.

Beanstalk is governed by Stalkholders. Anyone with Stalk stands to profit from future growth of Beanstalk, but are not owed anything by Beanstalk.

When the Bean price is below $1, there is an incentive to Withdraw assets from the Silo. The combination of the Stalk System and Withdrawal Freeze reduces this incentive significantly.

When the Bean price is above $1, there is an incentive to buy Beans to earn a portion of the upcoming Bean seigniorage. This is exacerbated when the Pod Rate is lower. The commitment to automatically return the Bean price to its value peg and distribute proceeds from the sale to current Stalkholders based on Stalk ownership when the Farm became Oversaturated () and the Withdrawal Freeze, removes this incentive entirely during Seasons where the previous Season's Pod Rate was excessively low, and reduces it significantly otherwise.

Thus, Beanstalk consistently increases trustlessness, stability and liquidity over time.

BIC Process

This document can be found on Arweave here.

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.

You can read more about the current BIC Members and data on past Beans minted for bounties on the BICM Dashboard in the Farmers' Almanac. All Immunefi bug reports and their responses are logged here.

Immunefi Program

You can read the full program and submit bug reports on the page. The latest version of the program approved by the DAO can be found on Arweave .

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

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.

The BIC structure of community-known members (see ) and public Snapshot proposals (see ) allows the Beanstalk community to scrutinize decisions, while still allowing the BIC to move swiftly in response to bug reports. The BIC consists of technical members of the Beanstalk community due to the nature of the BIC. The BIC can keep the bug information private while the bug is unfixed, and then has a clear process to disclose the bug to the public and compensate the whitehat.

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 ; 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;

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

If it is determined that the bug report is invalid, the BIC will close the report on the Immunefi Dashboard. BIC responses to all bug reports are logged .

If it is determined that the bug report is valid, the BIC will work with the corresponding party (the , etc.) to resolve the issue as soon as possible via an emergency upgrade. The fix will be forwarded to an auditor for review, if applicable.

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

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 voting takes place on the and lasts for 3 days. Only BIC members propose and vote on BIRs, and each member has one vote. BIC members can either vote For or Against a BIR, and a majority of the BIC voting For is required to pass.

BIR Exection

Once a BIR passes, the BICM executes it by:

Transferring Beans from the BICM to the , if necessary and to the extent that Beans remain available in the BICM; and
Transferring Beans in the Immunefi Vault to the submitting party’s address.

Temperature

Beanstalk relies on a decentralized set of creditors to maintain Bean price stability. Anytime Beanstalk is willing to issue debt, it issues Soil. Soil represents the number of Beans that Beanstalk is currently willing to borrow. Loans to Beanstalk are issued with a fixed interest rate, known as Temperature. If the Temperature is 500%, 1 Bean can be Sown in exchange for 6 Pods. Once those Pods become Harvestable, they can be Harvested in exchange for 6 Beans.

At the beginning of each Season, Beanstalk changes the Maximum Temperature depending on its position (price and debt level) and current state (direction and acceleration) with respect to its ideal equilibrium.

The Temperature increases at the beginning of each block of the Morning of each Season (25 blocks) according to a Dutch auction.

Direction

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

The direction of change of Beanstalk with respect to ideal equilibrium is considered either toward or away from ideal equilibrium, based on the current debt level and the over the previous Season.

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.

The number of Sown Beans each Season () indicated demand for Soil over the course of that Season.
The rate of change in the number of Sown Beans each Season (Delta Demand) is calculated as the number of Sown Beans in the previous Season () divided by the number of Sown Beans two Seasons ago ().

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;

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:

The contains a graphical representation of each possible state and an explanation for each Maximum Temperature adjustment.

Morning

During the Morning of each Season (the first 5 minutes), the Temperature increases logarithmically from 1% in the block of a successful gm function call up to the Maximum Temperature over the course of 5 minutes (See for complete formulas). During times of short-term excess demand for Soil, the Morning results in Beanstalk paying significantly less to attract creditors.

Connect to Beanstalk

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

A supported Arbitrum wallet with an ETH balance.
- Selecting and Funding a Wallet
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.

Beanstalk officially supports MetaMask, WalletConnect and Coinbase Wallet on desktop and mobile. WalletConnect is a protocol supported by many wallet applications. Although not officially supported, you may be able to connect other wallets such as Brave, Frame or Rabby by selecting MetaMask on .

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.

Visit .
Select "Install MetaMask For [your browser]".
Select "Add to [your browser]".

2. Optional: Connect Your Hardware Wallet to MetaMask

Select the MetaMask icon and then click the circle to the right of your MetaMask address.
Select "Connect Hardware Wallet".
Select your hardware wallet.

3. Fund Your MetaMask Wallet with ETH

This step may be unnecessary if you performed Step 2.

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

4. Connect Your MetaMask Wallet to Beanstalk

Visit .
Select "Connect Wallet" in the top right of the page.
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".

Connect to Beanstalk with MetaMask - Mobile

Download MetaMask from the or .
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.
From the menu, select "Browser" and visit .

Connect to Beanstalk with WalletConnect

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

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

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

Types of Stablecoins

The three axes in the previous section (value source, convertibility and network nativity) present a classification of 8 potential stablecoin types, some of which currently lack successful implementations:

Non-network-native exogenous value convertible stablecoin protocols
- 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

Exogenous Value Stablecoins

Non-network-native exogenous value convertible stablecoin protocols

Examples: , ,

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

Examples: , , ,

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.

is an ideal simple iteration of this type of stablecoin protocol, without any points of centralization and with protocol-native positive carry (via ). In order to remove rent payments, Liquity does not target an exact price for its stablecoin, LUSD. The potential supply of LUSD is limited by the value of trustless network-native value.

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

Examples: (convertible under certain market conditions)

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

Examples:

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.

Despite the shortcomings of exogenous value convertible stablecoin implementations, demand for their USD implementations continues to increase rapidly. Over the twelve months prior to the initial deployment of Beanstalk, the total market capitalization of exogenous value convertible USD stablecoins .

However, despite this rapid increase in supply, the have historically been higher than . Non-competitive carrying costs are structural due to the opportunity costs associated with requirements of exogenous value collateral. Attempts to improve carrying costs through the introduction of fractional reserves have failed to do so.

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

Examples:

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

Examples: ,

Rebasing stablecoin protocols (e.g., have shown efficacy at crossing stablecoin prices over their value pegs, but without the regularity, low volatility or liquidity necessary to create utility. Extreme negative carrying costs during decreases in demand exacerbate difficulty of use.

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.

Silo

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.

For guides on interacting with the Silo through the Beanstalk UI, go here.

Deposit Whitelist

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

Additional tokens may be added to the Deposit Whitelist via . In order for a token to be added to the Deposit Whitelist, Beanstalk requires:

The token address;
A function to calculate the Bean Denominated Value (BDV) of the token; and
The number of Stalk issued per BDV;

Current Deposit Whitelist

*See the section of the page for more info.

The Stalk System

When whitelisted assets are Deposited into the Silo, Beanstalk rewards the Depositor with Stalk* and Seeds. Seeds yield 1/10000 new Stalk every .

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.

Stalkholders can submit and vote on Beanstalk Improvement Proposals (BIPs). Stalkholders receive 1/3 of new Bean mints while there are more than zero Unfertilized Sprouts (Sprouts are issued by the ). If there are no Unfertilized Sprouts, Stalkholders receive 1/2 of new Bean mints.

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:

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;
Bean vs LP Seed distribution, or more specifically, the , which determines the relative benefits of holding Bean exposure vs exposure to at least 1 particular LP token in the Silo over time; and
LP vs LP Seed distribution, which determines relative benefits of holding a given non-Bean asset in the Silo over time.

See section for more information.

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.

See section for more information.

Governance

See section for more information.

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.).

Revitalized Stalk are Stalk that have vested for Unripe asset holders. Revitalized Stalk are minted as the BDV of Unripe assets increases. Revitalized Stalk does not contribute to Stalk ownership until Enrooted. See the section of the page for more info.

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

Revitalized Seeds are Seeds that have vested for Unripe asset holders. Revitalized Seeds are minted as the BDV of Unripe assets increases. Revitalized Seeds do not generate Stalk until Enrooted. See the section of the page for more info.

Proposals

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

(BIP)
(EBIP)
(BOP)
(BFCP)
(BFBP)
(BIR)
(BSP)
(BNP)

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.

All past proposals can be read .

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.

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 Stalk is voting For the BIP, the can execute the BIP.

BIPs are proposed on the . Stalkholders can vote on BIPs on the . Past BIPs can be read .

See for more information on proposing a BIP.

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.

BOPs are proposed on the . Stalkholders can vote on BOPs on the . Past BOPs can be read .

See for more information on proposing a BOP.

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.

EBIPs are shared with the Beanstalk community after commitment. Past EBIPs can be read .

See for more information.

Beanstalk Farms Committee Proposal

Beanstalk Farms Committee Proposals, or BFCPs, are proposals related to personnel on the . The BFC is the group of Beanstalk Farms contributors that has discretion over the Beanstalk Farms budget, including contributor compensation.

Stalkholders vote to:

Add members to the BFC via ;
Remove members from the BFC via ; and
Extend the terms of existing BFC members via .

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

BFCPs are proposed on the . Stalkholders can vote on BFCPs on the . Past BFCPs can be read .

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

Beanstalk Farms Budget Proposals, or BFBPs, are proposals related to the use of the Beanstalk Farms budget. The Beanstalk Farms budget is custodied by the . The BFM executes the will of the BFC.

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:

Hire contributors to Beanstalk Farms via ;
Dismiss contributors from Beanstalk Farms via ; and
Otherwise use the Beanstalk Farms budget via .

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

BFBPs are proposed on the , which is where BFC members vote. Past BFBPs can be read .

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

Beanstalk Immunefi Responses, or BIRs, are responses to bug reports on . Only BIC members can propose and vote on BIRs and each member has 1 vote. Any BIC member can vote For or Against.

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.

See for more information.

BIRs are proposed on the , which is where BIC members vote. Past BIRs can be read .

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.

A BNP can also be used to change the configuration or signers on the .

BNPs are proposed on the . BeaNFT holders can vote on BNPs on the . Past BNPs can be read .

BCM Process

This document can be found on Arweave here.

The Beanstalk Community Multisig, or BCM, custodies ownership of the Beanstalk contract. The BCM has the exclusive and unilateral ability upgrade Beanstalk. In the future, it is expected that BIPs remove governance entirely, revoking these abilities from the BCM.

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.

The BCM is deployed using Safe, the most battle-tested multisig contract on Arbitrum. Its m-of-n configuration is 5-of-9. Parameters m and n are each ultimately defined by Stalkholders and may evolve in the future via Beanstalk Improvement Proposal (BIP).

BCM Signers are an and diverse set of reputable community members and Beanstalk core contributors.

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

Beanstalk implements the , a standard for fully-upgradeable smart contracts.

The mechanism for upgrading a Diamond is by calling , which takes arguments of functions to replace and which functions to replace them with. The diamondCut function is only callable by the owner of Beanstalk, which is the BCM.

Upgrades should only be executed after a proposal has passed and Signers have manually reviewed the transaction. However, in the case of an emergency (like a bug or vulnerability), the BCM may execute an Emergency BIP (EBIP) to protect the Beanstalk contract. The best practices for emergency response handling are outlined in the section.

If a Stalkholder wants to propose a BIP, they can create a pull request to the and begin a formal proposal process outlined in the section.

The BCM also executes the will of the as determined by Beanstalk Immunefi Responses (BIRs). See .

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.

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.

BIPs are voted on at the .

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

Transaction

Snapshot?

Voting Period

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.

Past BIPs can be found .

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:

Code implementing the proposed changes (or simply a change to the file if there are no associated code changes);
A written proposal of the changes that would be implemented in the BIP, which must include:
- A Proposer section that includes an (or an Arweave upload if the proposing wallet is a multisig) confirming the proposer of the BIP;

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:

Submit a pull request on the public Beanstalk GitHub repo with a written proposal of the changes that would be implemented in the BIP.
Tag the @BCM Liaison user in the (#🏛・governance) channel in the Beanstalk Discord to create a dedicated discussion channel for the BIP.
Share a link to the GitHub PR and the written proposal in the newly created dedicated discussion channel.

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.

Past BOPs can be found .

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:

Updates to the file;
A written proposal of the changes that would be implemented in the BOP, which must include a Proposer section that has an (or an Arweave upload if the proposing wallet is a multisig) confirming the proposer of the BOP.

BOP Proposal Process

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

Submit a pull request on the public Beanstalk GitHub repo with a written proposal of the changes that would be implemented in the BOP.
Tag the @BCM Liaison user in the (#🏛・governance) channel in the Beanstalk Discord to create a dedicated discussion channel for the BOP.
Share a link to the GitHub PR and the written proposal in the dedicated discussion channel.

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

The BIC determines the categorization and payout of bug bounties in accordance with the approved by the Beanstalk DAO. The BCM executes the will of the BIC as determined by BIRs.

Any BIC member may propose BIRs. Past BIRs can be found .

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

See .

BIR Voting

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

The BIC shares BIR info with the BCM for them to submit a corresponding on-chain transaction.
The BCM shall then formally propose the BIR by submitting the on-chain transaction.
The BIC shall then formally propose the BIR on the .

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:

Regularly check in with the rest of the BCM and confirm access to their wallet;
Maintain active communication regarding travel plans and availability in order to ensure that there are always enough Signers on call; and
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:

Use a reputable hardware wallet like Trezor or Ledger;
Use a fresh address that doesn't have any pre-existing transactions or balances on it;
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.

Once the Voting Period for a proposal begins on Snapshot, all Signers are expected to promptly review and verify that the proposed transaction accurately reflects the Snapshot proposal per . This limits blind signing and encourages each Signer to independently verify that a proposed transaction is accurately represented. Anyone can verify that a Signer verified a proposed transaction during the Voting Period.

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);
Do not follow best practices outlined in the section; or
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

Once Signers have verified the transaction, they shall sign a message indicating that they have verified the transaction by creating an . This process must be completed for each transaction in a BIP or BIR. See the page for more information on how BCM Signers verify transactions.

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

Was not responsive during the draft phase of the proposal or Voting Period;
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;
Missed 2 verifications;

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.

Past EBIPs can be found .

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.

In cases where functions must be removed immediately to protect Beanstalk, BCM Signers are not required to submit an Etherscan verified message as outlined in .

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

The administrative permissions that were used (e.g., which functions were removed);
The context and severity of the issue; and
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

actively detects and responds to high confidence pre-exploit and exploit-in-progress detections on Beanstalk. Hypernative custodies that has the ability to call functions on added to the BCM. This module has the ability to remove all functions from Beanstalk except for diamondCut, facetAddress, facetAddresses, facetFunctionSelectors and facets. Removing all other functions protects the protocol in the event of an attack.

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

In the event that one or more Signers are compromised, vote against the outcome of any proposal, voluntarily choose to be removed from the BCM, or are otherwise removed in accordance with , the BCM will rotate them out of the multisig and replace them with another Signer. In no instance shall a majority of the BCM keys be held by Beanstalk Farms contributors, nor shall more than 1 key be held by Publius.

Anonymous Signers

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 adhering to .

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 publish a hash of the list of Signers and their corresponding wallets on Etherscan (you can find these under the Signer Hashes section of the ); and
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.

Glossary

Check out the Asset States page to better understand your Balances on the Beanstalk UI.

Barn

The Beanstalk recapitalization facility being used to Replant Beanstalk. Read more here.

Barn Raise

A fundraiser to restore $77M in non-Bean liquidity stolen from the in the April 2022 governance exploit. Participants in the Barn Raise receive and .

Bean Denominated Value (BDV)

The value of an asset denominated in Beans. Used to calculate how many and are rewarded to Depositors of a whitelisted asset. Abbreviated as BDV.

Bean Sprout (BS)

A Beanstalk accelerator program to facilitate development on and around Beanstalk in a decentralized fashion. Read more .

Bean Sprout Multisig (BSM)

The multisig that custodies the Bean Sprout budget funds. Abbreviated as BSM. Read more .

Bean

The ERC-20 fiat stablecoin issued by Beanstalk.

Beanstalk

The Ethereum-native, decentralized fiat stablecoin protocol that issues Beans.

Beanstalk Community Multisig (BCM)

The multisig that will custody ownership of the Beanstalk contract until on-chain governance can be reimplemented. The BCM will be able to propose and execute upgrades to Beanstalk. Abbreviated as BCM. Read more .

Beanstalk Farms (BF)

A decentralized team of core contributors to Beanstalk, operating across the stack on technical and non-technical problems. Read more .

Beanstalk Farms Budget Proposal (BFBP)

A proposal related to the use of the Beanstalk Farms budget. Abbreviated as BFBP. Read more .

Beanstalk Farms Committee (BFC)

The group of Beanstalk Farms contributors that has discretion over the Beanstalk Farms budget, including contributor compensation. The Beanstalk Farms Committee hires and dismisses contributors at Beanstalk Farms. Abbreviated as BFC. Read more .

Beanstalk Farms Committee Proposal (BFCP)

A proposal related to the Beanstalk Farms Committee. Abbreviated as BFCP. Read more .

Beanstalk Farms Multisig (BFM)

The multisig that custodies the Beanstalk Farms budget funds. Abbreviated as BFM. Read more .

Beanstalk Immunefi Committee (BIC)

A committee to determine the categorization and payout of bug bounties in accordance with the bug bounty program. Read more .

Beanstalk Immunefi Responses (BIR)

Responses to bug reports on Immunefi in accordance with the bug bounty program. Read more .

Beanstalk Improvement Proposal (BIP)

A proposal to change Beanstalk. Abbreviated as BIP. Read more .

Beanstalk Operations Proposal (BOP)

A proposal for having the Beanstalk DAO vote on things other than protocol changes. Abbreviated as BOP. Read more .

Cancel

Remove a or from the .

Chop

Burning in exchange for underlying . Read more .

Chop Penalty

The percentage claim to future forfeited by .

Circulating Beans

Beans in Farmers' wallets.

Convert

Changing one asset for another within the . Read more .

Convert Whitelist

The generalized whitelist that determines which within the are permitted under certain conditions. Read more .

Crop Ratio

Determines the relative benefits of holding Bean exposure vs exposure to at least 1 particular LP token in the Silo over time. More specifically, the ratio of Seed rewards between Beans and the LP token with the highest Gauge Points per BDV. Adjusted via the Seed Gauge System. Read more .

deltaB

The shortage or excess of Beans in a liquidity pool Beans trade in.

Delta Demand

The ratio of the change in over the prior two . Used to measure .

Deposit

Assets on the can be Deposited in the at any time to earn and . Read more .

Deposit Whitelist

The whitelist of ERC-20 tokens that can be Deposited in the Silo. Any ERC-20 token can be added or removed from the Deposit Whitelist via governance. Beans are always whitelisted. Read more .

Deposited Assets

Assets Deposited in the .

Depot

The component of the that facilitates interactions with other protocols through Beanstalk in a single transaction. Read more .

Earned Beans

Beans that have been paid to a since the last the Silo Member their . Upon Plant, Earned Beans are .

Earned Stalk

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

Emergency Beanstalk Improvement Proposal (EBIP)

An emergency proposal to change Beanstalk that is decided on and committed by the . Abbreviated as EBIP. Read more .

Enroot

Adds and to your and balances, respectively.

Farm

The Beanstalk ecosystem. The Farm has five primary components: the , , , , and .

Farm Assets

Assets stored in Beanstalk. Farm Assets can be used in transactions on the and may be more gas efficient than . Read more about .

Farmers

Users of Beanstalk.

Fertilize

are Fertilized by Active Fertilizer, at which point they become .

Fertilizer

An ERC-1155 token that Beanstalk mints in exchange for USDC. Fertilizer comes with , which represent debt to be repaid by Beanstalk in the form of new Beans. Fertilizer has no fixed maturity. Fertilizer can be Available, Active or Used. Read more .

Field

The Beanstalk credit facility. Read more .

FIFO

First in, first out. become on a FIFO basis. This means that Pods closer to the front of the become Harvestable before Pods farther back in the Pod Line.

Fill

Match a with an overlapping .

Flood

If P > 1 over the previous and the is less than 5%, there is a Flood. At the beginning of a Season where it Floods, Beanstalk mints additional Beans and sells them in Wells on the .

Gauge Points

Determine issuance across various LP tokens.

Germination

Germinating are Deposits that are <2 gm calls old. Germinating Deposits can be or , but cannot be . Germination exists to add flash loan and inter-block MEV manipulation resistance to the calculation of Deposited . By preventing the accrual of for 1 full , Beanstalk further disincentivizes inorganic demand.

gm

Beanstalk accepts one gm function call every . Upon the gm call, Beanstalk , , distributes Beans to , adjusts the , etc.

Grown Stalk

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

Harvest

Redeem Harvestable Pods for 1 Bean each.

Harvestable Pods

that are redeemable for 1 Bean each. Harvestable Pods must be Harvested in order to use them.

Humidity

The interest rate on purchases. Read more .

Jack

chopped down Beanstalk on April 17, 2022.

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.

Liquidity Weight

The portion of liquidity in a whitelisted liquidity pool that counts towards the calculation.

Maximum Temperature

The maximum Beanstalk is willing to offer during a . Read more .

Minting Whitelist

The whitelist of liquidity pools whose are summed to calculate a cumulative deltaB. Read more .

Morning

The first 25 blocks of each .

Mow

Mowing adds it to your balance. Called upon any interaction with the .

Ordered Beans

Beans stored in .

Pari passu

Fertilizer is paid back on a pari passu basis. Active Fertilizer Fertilizes a pro-rata portion of Sprouts, by Fertilizer. This is in contrast to the first in, first out (FIFO) schedule of the in the .

Pause

Temporarily prevent the function call from being accepted. Read more .

Pipeline

A sandbox contract that can execute an arbitrary number of actions within the EVM from an EOA in a single transaction (see more on the page). Note that this also currently refers to functionality in Beanstalk that is a channel from the to another protocol. Pipelines can be added to the Depot via Beanstalk governance. Read more .

Plant

Planting adds Plantable Seeds to your total balance.

Plantable Seeds

earned in conjunction with . Plantable Seeds must be Planted in order to grow .

Plot

that grow from Beans that were in the same transaction form a Plot.

Pod Line

The order will become based on the Harvest schedule.

Pod Listing

An offer to sell on the . Read more .

Pod Market

The decentralized, trustless market that can be bought and sold on. Read more .

Pod Order

An order to buy on the . Read more .

Pod Rate

The Beanstalk debt level ( supply) relative to the Bean supply. The Pod Rate is often used as a proxy for Beanstalk's health.

Pods

The Beanstalk-native debt asset, redeemable for 1 Bean each once into . Read more .

Publius

The pseudonym of Beanstalk’s founders.

Real Rate of Return (RRoR)

The return for Sowing Beans, accounting for the Bean price. RRoR = (1 + Temperature) / TWAP.

Replant

The relaunch of Beanstalk post-exploit.

Revitalized Stalk

that have vested for Unripe asset holders. Revitalized Stalk are minted as the BDV of Unripe assets increases. Revitalized Stalk does not contribute to ownership until . Read more .

Revitalized Seeds

that have vested for Unripe asset holders. Revitalized Seeds are minted as the BDV of Unripe assets increases. Revitalized Seeds do not generate until . Read more .

Rinsable Sprouts

that are redeemable for 1 Bean each. Rinsable Sprouts must be Rinsed in order to use them.

Rinse

Redeem Rinsable Sprouts for 1 Bean each.

Ripe Assets

Assets that are minted as is sold. represent a pro rata share of underlying Ripe assets.

Ripen

When passively turn into , they Ripen.

Season

Seasons are Beanstalk-native time. Every Season is approximately 1 hour. Each Season begins when the function is successfully called on Ethereum.

Seed Gauge System

The component of Beanstalk responsible for dynamically adjusting the rewards for different assets whitelisted in the . Read more .

Seeds

An internal token that yields 1/10000 every Season.

Silo

The Beanstalk DAO. Read more .

Silo Members

in the Silo.

Silo Rewards

Rewards earned by Silo Members in the form of , , , , , and . Read more .

Soil

The current number of Beans that can be in exchange for . Read more .

Sow

Lend. Used in the context of Sowing Beans, or lending Beans to Beanstalk when there is .

Sprouts

Sprouts represent how many Beans there are left to be earned from .

Stalk

The Beanstalk governance token. Stalk entitles the holder to a pro rata share of future Bean mints and participation in Beanstalk governance. Read more .

Stalkholders

Holders of the Stalk token. Stalkholders participate in governance and earn Bean seigniorage.

Sun

The component of the Farm that keeps time in and incentivizes cost-efficient and timely calling of the function. Read more .

Target Seasons to Catch Up

Determines the target number of for a new with an average number of to catch up to the average per of existing Deposits at the time of Deposit.

Temperature

The interest rate for Beans. Read more .

Toolshed

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

Total Value Deposited (TVD)

The value of assets Deposited in the . Abbreviated as TVD.

Tractor

A peer-to-peer transaction marketplace that allows third party operators to perform Beanstalk actions on behalf of a Farmer. Read more .

Transfer

Moving , or from one address to another. Deposits can be Transferred without the loss of , , or Stalk from Seeds. Assets can be transferred between and .

Unpause

Resume the acceptance of function calls. When Beanstalk is Unpaused, the gm function can be called at the beginning of the next hour.

Unripe Assets

Unripe assets represent a pro rata share of minted as is sold and debt is repaid to Fertilizer. Read more .

urBEAN

Unripe Beans. See .

Voting Period

The time interval in which a (BIP) is considered by . Read more .

Withdraw

can be Withdrawn from the at any time. The number of , , and Stalk from Seeds rewarded for a Deposited asset must be forfeited upon its Withdrawal from the Silo. Read more .

Farmers' Almanac

Farmers' Almanac

hashtagLinks

Disclosures

Introduction

Why Beanstalk

hashtagCentralization

How Beanstalk Works

hashtagTokens

Farm

Overview

Sun

hashtagMinting Whitelist

hashtagCurrent Minting Whitelist

Seed Gauge System

Toolshed

Depot

hashtagPipeline

Tractor

Peg Maintenance

Advanced

Governance

BFC Dashboard

hashtagBFC Members

Guides

Getting Started

Add Bean to MetaMask

Sun

Field

Transfer Pods

Market

Balances

BeaNFTs

Swap

Governance

Unripe Assets

Protocol Resources

Ecosystem

Community Resources

Archives

Farmers' Almanac

hashtagLinks

Overview

Why Beanstalk

hashtagCentralization

How Beanstalk Works

hashtagTokens

hashtagCarrying Costs

hashtagPrimary Facilities

hashtag1. The Sun

hashtag2. The Silo

hashtag3. The Field

hashtagCreating Stability

Sun

BFC Dashboard

hashtagBFC Members

Balances

Sun

hashtagMinting Whitelist

hashtagCurrent Minting Whitelist

Disclosures

Seed Gauge System

Depot

hashtagPipeline

Add Bean to MetaMask

Field

Transfer Pods

Market

BeaNFTs

Getting Started

Swap

Tractor

Governance

Toolshed

Unripe Assets

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

hashtag3. 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.

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

hashtag5. 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.

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

Links

Centralization

Tokens

Minting Whitelist

Current Minting Whitelist

Pipeline

BFC Members

Links

Centralization

Tokens

Carrying Costs

Primary Facilities

1. The Sun

2. The Silo

3. The Field

Creating Stability

BFC Members

Minting Whitelist

Current Minting Whitelist

Pipeline

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

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.

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

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.

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

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.

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.

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.

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.

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

12. A VULNERABILITY IN ETHEREUM OR ARBITRUM COULD RESULT IN A LOSS OF FUNDS. 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.

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

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.

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.

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.

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

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.

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

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.

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

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

Grown Stalk Inflation Rate

Gauge Points

Crop Ratio

Governance

Current Flood Whitelist

Links

Links

BDM Signers

Spending

Voting Period

Pause

Commit

Excessively Low L2SR

Reasonably Low L2SR

Reasonably High L2SR

Excessively High L2SR