1 of 100

Farmers' Almanac

Disclosures

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

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 Beanstalk whitepaper, the Farmers' Almanac, 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.

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

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

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

The old Bean token was replaced with another token on Ethereum, which was then replaced with the latest Bean token on Arbitrum. The obsolete tokens have no value according to Beanstalk.

More information:

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

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

The Bean supply is uncapped and grows as demand for Beans increases. Beans can also be minted arbitrarily through governance (see #7).

More information:

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

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

Beanstalk launched without the need to raise capital. However, after an on-chain governance attack on April 17, 2022 (see #1), a fundraiser known as the Barn Raise is being used to recapitalize the non-Bean funds stolen in the exploit. The terms offered in the fundraiser are available to any Arbitrum address.

More information:

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

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

More information:

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

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

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

More information:

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

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

Pods and Sprouts are repaid when the time weighted average price of 1 Bean is greater than $1 over the previous Season, but there is no guarantee this will continue until all Pods and Sprouts become redeemable (see #4). Governance may also arbitrarily modify the redeemability of Beanstalk debt (see #7).

More information:

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

Beanstalk is governed by the Beanstalk DAO—the Silo, which is comprised of Stalkholders. Stalkholders vote on Beanstalk Improvement Proposals (BIPs), which can arbitrarily change Beanstalk. Voting rights come from Stalk ownership (see #8 for details on Stalk).

Any community member that meets a certain Stalk ownership threshold may propose a BIP. If the BIP passes, the Beanstalk Community Multisig (see #9 for details on the BCM) executes the will of the DAO based on the results of the vote, unless the Stalk distribution is compromised in a flash loan or other governance attack. Through this governance process, Stalkholders may make arbitrary changes to Beanstalk.

More information:

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

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

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

More information:

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

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

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

More information:

BFP-73: Beanstalk Community Multisig
BCM Multisig Powers Documentation
Anonymous Multisig Signers Documentation
BCM Dashboard

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

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

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

Hypernative only removes functions during high confidence pre-exploit and exploit-in-progress detections;
The BCM will remove Hypernative protections when necessary for the security or censorship resistance of Beanstalk; or that
The BCM only removes Hypernative protections when it beneficial to Beanstalk.

More information:

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

Beanstalk is governed by Stalkholders, as described in #7. Stalk ownership, and thus governance power, decentralizes over time given the inflationary nature of Stalk. However, there is no maximum Stalk supply. Stalk is minted for Deposits based on the Bean Denominated Value (BDV) of the Deposit, up to any arbitrary BDV.

Stalk ownership was previously compromised via flash loan, which enabled the on-chain governance attack on April 17, 2022 (see #1). The Beanstalk Community Multisig serves as a temporary security measure until either (1) a secure and fully decentralized governance mechanism has been developed and sufficiently audited, or (2) governance is removed altogether.

More information:

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

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

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

Beans trade in Wells on Basin. Well LP tokens are whitelisted in the Silo and used by Beanstalk to determine how many Beans and/or Soil to mint. Basin and the corresponding components that Beanstalk uses (the Constant Product Well Function, the Stable Well Function, the Well Implementation, Multi Flow, etc.) were audited by Halborn, Cyfrin and Code4rena. While all are reputable auditors, there is no guarantee that Basin or its components are secure. Beanstalk assumes the security of Basin and its corresponding components.

More information:

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

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

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

More information:

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

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

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

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

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

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

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

More information:

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

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

More information:

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

The Beanstalk contracts are open source and deployed on Arbitrum. There may be bugs, flaws, or other unintended consequences from using open source code to govern irreversible financial transactions on a decentralized network. These issues may lead to a loss of funds if present and discovered by malicious actors, and has in the past (see #1).

More information:

Beanstalk on GitHub

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.

Security is paramount to Beanstalk's success. Prior to Replant in August 2022, the majority of Beanstalk’s code was audited by Halborn and Trail of Bits. Up to October 2024, the majority of new Beanstalk code since Replant has been audited by Halborn, Cyfrin and Codehawks. While all are reputable audit firms, there is no guarantee Beanstalk is secure. Beanstalk was audited by Omniscia prior to the April 2022 governance exploit.

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

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

More information:

Beanstalk Audits

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

The Beanstalk UI hosted at app.bean.money is hosted on Netlify, a privately held, United States based cloud provider. Netlify could censor the frontend at will, or a technical disruption could prevent access. In either scenario, Beanstalk would not be accessible from a web browser until (1) Beanstalk Farms, the decentralized development organization that manages the site, could deploy the frontend elsewhere, or (2) other parties could use the open source code to deploy their own frontends to interact with the Beanstalk contracts.

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

More information:

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

The Beanstalk UI hosted at app.bean.money depends on the Beanstalk and Bean Subgraphs for displaying various data.

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

More information:

Beanstalk Subgraph on GitHub

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

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

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

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

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

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

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.

Beanstalk, on the other hand, is governed by a DAO and uses an on-chain price oracle to determine the price of a dollar. The yield-bearing governance token, known as , becomes more distributed over time. Beanstalk is highly resistant to censorship by design such that anyone, anywhere can access low-volatility assets in a fully permissionless manner.

Carrying Costs

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

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

Instead, Beanstalk utilizes a credit-based model to create endogenous value. By relying on its own creditworthiness to expand supply and maintain Bean price stability, rather than collateral, Beanstalk creates a scalable, capital-efficient alternative. Furthermore, because Beans require no collateral and Bean seigniorage is partially distributed to Bean holders in the , Beans have positive carry.

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

Additional resources:

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

Beanstalk issues 3 tokens:

Beans — Beanstalk ERC-20 fiat stablecoins;
Stalk — illiquid yield-generating governance tokens; and
Seeds — illiquid tokens which yield 1/10000 Stalk each Season.

Primary Facilities

1. The Sun

Beanstalk uses the Sun to create a cost-efficient and protocol-native timekeeping mechanism. The Sun keeps time on the Farm in Seasons. Each Season is ~1 hour long. Beanstalk adjusts itself to return the Bean price to its value peg at the beginning of every Season.

In practice, Beanstalk does not calculate the price of 1 Bean. Instead, at the beginning of a Season, Beanstalk calculates deltaB, the sum of the time-weighted average shortages or excesses Beans across liquidity pools on the Minting Whitelist;

The Sun uses deltaB to determine how to change the Bean supply and Soil supply.

2. The Silo

Beanstalk uses the Silo, the Beanstalk DAO, to create a robust decentralized governance mechanism. Farmers can earn yield from passive participation in Beanstalk governance by Depositing assets on the Deposit Whitelist in the Silo to receive Stalk and Seeds.

Stalkholders can submit and vote on Beanstalk Improvement Proposals (BIPs) and collect a portion of Bean supply increases. A diverse community of Stalkholders creates decentralization.

To encourage consistent security:

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

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

The Bean vs LP Seed distribution, or more specifically, the Crop Ratio, determines the relative benefits of holding Bean exposure vs exposure to at least 1 particular LP token in the Silo over time.

Conversions within the Silo between Bean and LP Deposits serve a major role in peg maintenance (see Convert Whitelist).

3. The Field

The Field is Beanstalk’s decentralized credit facility. Anytime the Bean price is too low, Beanstalk uses the Field to attract lenders who can lend their Beans to Beanstalk, which are subsequently burnt in exchange for Pods, Beanstalk’s native debt asset. Pods are paid out on a First In, First Out (FIFO) basis when new Beans are minted.

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

Pods have a fixed interest rate and unknown maturity date. The number of Pods that grow from 1 Sown Bean is determined by the Temperature— the Beanstalk-native interest rate — at the time of Sowing. Pods become Harvestable (redeemable) for 1 Bean on a First In, First Out (FIFO) basis when new Beans are minted.

Creating Stability

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

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

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

Increases the Soil supply by deltaB, subject to the cap in EBIP-2;
Raises the Maximum Temperature; and
Adjusts the Crop Ratio based on Beanstalk's debt and liquidity levels.

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

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

Increases the Bean supply by deltaB, subject to the cap in EBIP-2;
Lowers the Maximum Temperature; and
Lowers the Crop Ratio.

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

To align the interests of Stalkholders and Sowers, 1/3 of Bean supply increases are distributed to Stalkholders and 1/3 go to Pod Harvests. The other 1/3 are distributed to Active Fertilizer holders as part of Beanstalk’s recapitalization plan after the April 2022 governance exploit (see Barn section).

In order to prevent inorganic growth, if the Bean price is too high and the debt level is excessively low for a Season, Beanstalk sells Beans directly in the liquidity pools on the Flood Whitelist with the highest deltaB until the cumulative deltaB across all pools is 0.

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 Barn 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 Minting Whitelist;
Changes the Maximum Temperature if necessary and checks for Flood;
Changes the Crop Ratio (and updates the Gauge Points of each whitelisted asset);
Sets the initial Soil supply;
Mints Beans if necessary; and
Awards Beans to the address that successfully called the gm function.

Minting Whitelist

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

Additional liquidity pools may be added to the Minting Whitelist via Beanstalk governance. 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

BEAN:WETH Well

BEAN:wstETH Well

BEAN:weETH Well

BEAN:WBTC Well

BEAN:USDC Well

BEAN:USDT Well

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 Beanstalk governance. 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;
The number of initial Gauge Points (which determine Grown Stalk issuance across various LP tokens);
An oracle for calculating the price on the non-Bean asset in the Well;
A function to calculate how the Gauge Points change each Season;
A function to calculate what portion of liquidity counts towards the Liquidity to Supply Ratio calculation (i.e., Liquidity Weight); and
The optimal percentage of Deposited LP BDV.

Current Deposit Whitelist

Whitelisted asset

Stalk per BDV

Optimal % Deposited LP BDV

Liquidity weight

N/A

16%

100%

26%

100%

14%

100%

20%

100%

12%

100%

12%

100%\

N/A

*See the Unripe Assets section of the Barn 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 Season.

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 Barn). 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 Crop Ratio, 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 Seed Gauge System 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 Convert section for more information.

Governance

See Governance 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 Revitalized Assets section of the Barn 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 Revitalized Assets section of the Barn page for more info.

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 Crop Ratio, 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.

Grown Stalk Inflation Rate

The Grown Stalk per BDV for a Deposit can be thought of as the age of that Deposit—the longer the Deposit has been in the Silo, the higher its Grown Stalk is relative to its BDV. Thus, the average Grown Stalk per BDV is a measure for how old Deposits are across the entire Silo relative to the total BDV in the Silo.

The Seed Gauge System enables Beanstalk to target an amount of Grown Stalk per BDV that should be issued each Season. In particular, Beanstalk sets 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, or in other words, the Target Seasons to Catch Up. The Target Seasons to Catchup is currently set to 4320 Seasons, or ~6 months.

Gauge Points

Gauge Points determine how the Grown Stalk issued in a Season should be distributed between whitelisted LP tokens. Only whitelisted LP tokens have Gauge Points.

Every Season, Beanstalk calculates the new amount of Gauge Points an LP token should have by calling each whitelisted LP token's Gauge Point function. Currently all whitelisted LP tokens use the same Gauge Point function that increases or decreases the Gauge Points based on whether the current Deposited BDV is lower or higher than optimal.

Crop Ratio

Gauge Points per BDV is the amount of Gauge Points allocated to a whitelisted LP token divided by the total BDV of that LP token Deposited in the Silo. The whitelisted LP token with the largest Gauge Points per BDV is used to determine the distribution of Grown Stalk to Beans in the Silo in order to ensure that at least 1 LP token always receives at least as much Grown Stalk as Deposited Beans. Ensuring that 1 whitelisted LP token (i.e., the LP token with the highest Gauge Points per BDV) is always allocated at least as many Seeds as Beans ensures that Beanstalk never incentivizes holding Beans over providing liquidity.

The Crop Scalar ( $L$ ) is a scalar between 0 and 1 that is adjusted by the peg maintenance mechanism. The Crop Ratio has a minimum ( $Y$ ) and maximum value ( $Z$ ). Currently, $Y$ and $Z$ are set to 1:2 (i.e., 50%) and 1:1 (i.e., 100%), respectively.

Bean To Max LP Seed Ratio = Y + L(Z - Y)

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 .

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.

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.

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.

Barn

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

Upon exploit, Beanstalk was Paused and the on-chain governance mechanism was removed. Stalkholders voted via Snapshot on how Beanstalk should proceed.

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

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

Timeline

April 17, 2022: Governance exploit
June 6, 2022: Barn Raise starts
August 6, 2022: Beanstalk Replant
October 20, 2023: Migration of Unripe liquidity from BEAN:3CRV to the BEAN:ETH Well
July 26, 2024: Migration of Unripe liquidity from BEAN:ETH to BEAN:wstETH

Fertilizer

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

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

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

When there are more than zero Unfertilized Sprouts, 1/3 of new Bean mints are allocated towards Fertilizer on a pari passu basis. This is in contrast to the FIFO Harvest schedule of the Pod Line in the Field.

If Fertilizer is not sold yet, it’s Available.
If Fertilizer still has Sprouts (is owed Bean mints), it’s Active.
If Fertilizer has no more Sprouts (is done earning Bean mints), it’s Used.

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

Humidity

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

The Humidity is constant each Season. The Humidity was 500% prior to Replant, after which it dropped to 250% and then decreased by an additional 0.5% each Season until it reached 20%. The Humidity will remain at 20% until all Available Fertilizer is purchased.

Barn Process

Fertilizer is bought with wstETH. Active Fertilizer comes with Sprouts.
Sprouts become Rinsable on a pari passu basis when Beanstalk mints new Beans according to the peg maintenance mechanism.
Rinsable Sprouts can be Rinsed to be redeemed for Beans.

Unripe Assets

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

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

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

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

Ripe Assets

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

On October 20th, 2023 Ripe BEAN:3CRV LP was migrated to Ripe BEAN:ETH LP. As a result, Unripe BEAN:3CRV LP became Unripe BEAN:ETH LP (with the same token address). See BIP-38.

On July 26, 2024 Ripe BEAN:ETH LP was migrated to Ripe BEAN:wstETH LP. As a result, Unripe BEAN:ETH LP became Unripe BEAN:wstETH LP (with the same token address). See BIP-48.

Chopping

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

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

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

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

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

Revitalized Assets

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

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

Toolshed

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

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 as a sandbox for execution.

The following functions to interact with Pipeline can be called through the Pipeline.

pipe(...)
multiPipe(...)
advancedPipe(...)

Pod Market

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

Pods

can be bought and sold in a decentralized, trustless fashion on the Market. The Market creates liquidity for Pods through an on-chain order book.

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

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

Pod Listings

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

1. Plot

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

2. Position within the Plot

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

3. Price per Pod

The sale price of each Pod, denominated in Beans.

4. Expiration

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

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

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

Pod Orders

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

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

1. Maximum number of Pods to be purchased

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

2. Price per Pod

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

3. Maximum place in the Pod Line

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

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

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

Overview

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

Beanstalk has five direct peg maintenance tools available:

Increase the ;
Change the ;
Change the ;
Change the ; and
Sell Beans ().

At the beginning of every , Beanstalk evaluates its position (i.e., price, debt level and liquidity level) and current state (i.e., direction and acceleration) with respect to ideal equilibrium, and dynamically adjusts the Bean supply, Soil supply, Temperature and Crop Ratio to move closer to ideal equilibrium.

within the between Bean and LP Deposits serve a major role in peg maintenance.

Ideal Equilibrium

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

The price of Bean is regularly oscillating around the peg;
The Beanstalk debt level is optimal;
The Beanstalk liquidity level is optimal; and
Demand for Soil is steady.

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

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

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

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

Decentralized Price Oracle

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

P > Q

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

Debt Level

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

Excessively low debt: Pod Rate < 5%
Reasonably low debt: 5% ≤ Pod Rate < 15%
Optimal level of debt: Pod Rate = 15%
Reasonably high debt: 15% < Pod Rate ≤ 25%
Excessively high debt: Pod Rate > 25%

Liquidity Level

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

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

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

Excessively low liquidity: L2SR < 12%;
Reasonably low liquidity: 12% ≤ L2SR < 40%;
Optimal level of liquidity: L2SR = 40%
Reasonably high liquidity: 40% < L2SR ≤ 80%; or
Excessively high liquidity: L2SR > 80%.

Locked Beans

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

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

Bean Supply

Soil Supply

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 deltaB 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 ( $u_t$ ) 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 ( $u_{t-1}$ ) divided by the number of Sown Beans two Seasons ago ( $u_{t-2}$ ).

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.
- If S > 1 was not Sown in the first 10 minutes of the previous Season, Beanstalk compares the time it took for all S > 1 to be Sown in the previous two Seasons ( $u_{t-1}$ and $u_{t-2}$ ).
- If it took less than one minute longer for all S > 1 to be Sown in $u_{t-2}$ than $u_{t-1}$ , demand for Soil is decreasing. If it took longer than one minute, demand for Soil is increasing. Otherwise, demand for Soil is steady.

Acceleration

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

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

Current and Optimal State

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

Accelerating away from ideal equilibrium;
Accelerating toward ideal equilibrium;
Steady away from ideal equilibrium;
Steady toward ideal equilibrium;
Decelerating away from ideal equilibrium; and
Decelerating toward ideal equilibrium.

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

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

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

The Maximum Temperature Flow Chart 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 Section 8.12.2 of the whitepaper for complete formulas). During times of short-term excess demand for Soil, the Morning results in Beanstalk paying significantly less to attract creditors.

Crop Ratio

Beanstalk is a credit-based stablecoin protocol. The main goal of Beanstalk is to regularly oscillate the Bean price across $1, indefinitely. Beanstalk's primary peg maintenance mechanism, and theoretical basis for existence, is the Field (i.e., the Beanstalk credit facility). The ability for Beanstalk to borrow Beans from the open market at a reasonable interest rate is essential for long term peg maintenance.

However, with the successful addition of Conversions within the Silo in December 2021, a second peg maintenance mechanism was discovered. The ability to add and remove Beans from liquidity pools to decrease and increase the Bean price, respectively, changes the Bean price without any outflows or inflows from the system. Currently, Converts are limited in that Depositors can only Convert between Beans and LP tokens, and vice versa (i.e., not across LP tokens). Furthermore, the incentives for Converting in a given direction with respect to peg (in particular, Seed allocations to the various assets whitelisted for Deposit) are not adjusted autonomously in response to Beanstalk's state.

With the introduction of the Seed Gauge System, now Beanstalk also measures its liquidity level (in practice, the Liquidity to Supply Ratio, or L2SR).

In order to adjust the Crop Ratio, in practice Beanstalk adjusts a scalar (the Crop Scalar) between 0 and 1, where 0 results in the minimum Bean to Max LP Ratio and 1 results in the maximum Bean to Max LP Ratio. Therefore, the peg maintenance mechanism can adjust the Bean to Max LP Ratio independently of the minimum and maximum values (set to 50% and 100%, respectively).

At the beginning of each Season, Beanstalk changes the Crop Scalar depending on its position (price, debt level and liquidity level) with respect to its ideal equilibrium.

Considering the current state and the liquidity level, Beanstalk adjusts the Crop Scalar to move toward the optimal state:

Excessively Low L2SR

No matter the L2SR, when P > Q, Beanstalk should maximally incentivize Converting to LP Deposits by aggressively decreasing the Crop Ratio. By decreasing the scalar by 0.5 each Season, the Crop Ratio returns to the minimum value within 2 Seasons.

When L2SR is excessively low, in all cases, Beanstalk should be similarly aggressive in incentivizing Conversions to LP Deposits by quickly reaching the minimum Crop Ratio.

Reasonably Low L2SR

When the L2SR is reasonably low and Pod Rate is low, Beanstalk should be similarly aggressive in reaching the minimum Crop Ratio given that, at the margin, Beanstalk would rather take on debt than lose liquidity. When the L2SR is reasonably low and Pod Rate is high, Beanstalk should gradually increase the Crop Ratio when P > 1 (to incentivize Conversions above peg) and gradually decrease it when P < 1 (to incentivize Conversions below peg). By changing the scalar by 0.01 each Season, the Crop Ratio can change from the maximum to the minimum value (or vice versa) within 100 Seasons.

Reasonably High L2SR

When L2SR is reasonably high and P < 1, Beanstalk should similarly gradually increase the Crop Ratio to incentivize Converting from LP Deposits to Bean Deposits, and vice versa when P > 1.

Excessively High L2SR

When L2SR is excessively high, Beanstalk should be more willing to accept a loss of liquidity rather than an increase in debt level at the margin. Therefore, it should adjust the Crop Scalar just as it does when L2SR is reasonably high, except it can be slightly more aggressive when P < 1 and the Pod Rate is high. By increasing the Crop Scalar by 0.02, the Crop Ratio can change from the minimum to the maximum value within 50 Seasons.

Convert

Conversions within the Silo between Bean and LP Deposits serve a major role in peg maintenance.

Conversions from one Deposited asset to another are permissioned by a Convert Whitelist. Conversions can be added or removed from the Convert Whitelist via Beanstalk governance.

When the Bean price is above peg (i.e., deltaB is positive), Deposited Beans may be Converted to Deposited LP tokens while retaining grown Stalk from Seeds. This Conversion allows the Silo Member to add Beans to liquidity pools, which has the practical effect of selling Beans above peg. In doing so, Beanstalk incentivizes Stalkholders to grow liquidity for Beans at the expense of additional Bean mints, as the Bean price is decreased back towards peg.

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

Unripe Beans are also convertible to Unripe BEAN:ETH LP, and vice versa, in a similar fashion. See the Unripe Assets section of the Barn page for more info.

Convert Whitelist

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

Additional Conversions may be added to the Convert Whitelist via Beanstalk governance. In order for a Conversion to be added to the Convert Whitelist, Beanstalk requires:

The From token address;
The To token address;
Conditions under which the From token can be converted to the To token; and
A function to determine the number of To tokens received for Converting a given number of From tokens (see Section 14.4 in the whitepaper for complete formulas).

Current Convert Whitelist

From token

To token

Conditions

Any token on the Deposit Whitelist*

The same token as From token

Anytime

Unripe token

Underlying token

Anytime

Unripe Bean

Unripe BEAN:wstETH LP

deltaB in the BEAN:wstETH Well > 0

Unripe BEAN:wstETH LP

Unripe Bean

deltaB in the BEAN:wstETH Well < 0

Bean

Whitelisted Well LP token

deltaB in the given Well > 0

Whitelisted Well LP token

Bean

deltaB in the given Well < 0

*Any token on the Deposit Whitelist can be Converted to the same token in order to allow Stalkholders to update the BDV of their LP tokens when their BDV increases due to impermanent loss.

Performance

Convert functionality was first added in BIP-7, and generalized to support a Convert Whitelist in BIP-21. Since BIP-7 was committed, Conversions by Stalkholders have played a significant role in peg maintenance.

Generalized Convert

With the introduction of Generalized Convert in BIP-50, which supports LP token -> LP token Converts as well as Converts against peg (with an associated Stalk penalty). A per-block Convert cap mechanism protects against flash loan attacks.

Stalk Penalty

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

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

Convert Capacity

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

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

Flood

Beanstalk sells newly minted Beans on the open market during long run increases in demand for Beans when increasing the Bean supply, lowering the Maximum Temperature and lowering the Crop Ratio have not crossed the Bean price over its peg.

At the beginning of a Season, if it is currently Raining (the previous Season P > 1), and the Pod Rate is less than 5%, it Floods at the beginning of the next Season.

At the beginning of a Season during a Flood, Beanstalk mints additional Beans and sells them directly in pools on the Flood Whitelist with the highest shortage of Beans at the end of the previous Season. Liquidity pools can be added to and removed from the Flood Whitelist via Beanstalk governance. Proceeds from the sale are distributed to Stalkholders at the beginning of Season in proportion to their Stalk holdings when it began to Rain. At the beginning of each Season in which it Floods, up to 0.1% of the Bean supply worth of Pods that grew from Beans Sown before it began to Rain Ripen and become Harvestable.

Current Flood Whitelist

Name

Address

BEAN:WETH Well

BEAN:wstETH Well

BEAN:weETH Well

BEAN:WBTC Well

BEAN:USDC Well

BEAN:USDT Well

Advanced

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 low volatility asset – in 2014, the stablecoin industry has grown from a fringe backwater to a $150B market cap 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, borrowing rates on USD stablecoins have significantly exceeded borrowing rates on fiat USD. 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.

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
Network-native exogenous value convertible stablecoin protocols
- Examples: wETH, Liquity, MakerDAO, Abracadabra
Non-network-native exogenous value non-convertible stablecoin protocols
- Examples: N/A
Network-native exogenous value non-convertible stablecoin protocols
- Examples: Olympus
Non-network-native endogenous value convertible stablecoin protocols
- Examples: N/A
Network-native endogenous value convertible stablecoin protocols
- Examples: Terra
Non-network-native endogenous value non-convertible stablecoin protocols
- Examples: US Dollars
Network-native endogenous value non-convertible stablecoin protocols
- Examples: Beanstalk, Ampleforth

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

Non-network-native exogenous value fractional reserve convertible stablecoin protocols
- Examples: Bank Notes
Network-native exogenous value fractional reserve convertible stablecoin protocols
- Examples: Frax

Exogenous Value Stablecoins

Non-network-native exogenous value convertible stablecoin protocols

Examples: USD Coin, Tether, BinanceUSD

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: wETH, Liquity, MakerDAO, Abracadabra

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.

Liquity is an ideal simple iteration of this type of stablecoin protocol, without any points of centralization and with protocol-native positive carry (via the Stability Pool). 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: Olympus (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: Frax

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 increased more than 500% to over $100 billion.

However, despite this rapid increase in supply, the borrowing rates on exogenous value convertible USD stablecoins have historically been higher than borrowing rates on USD. 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: Terra

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: Beanstalk, Ampleforth

Rebasing stablecoin protocols (e.g., Ampleforth) 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.

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;
The marginal rate of substitution;
Low friction;
Equilibrium; and
Incentive structures determine behaviors of financially motivated actors.

Ownership Concentration

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

Older Deposits have their Stalk from Seeds diluted relative to newer Deposits every Season. 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 Temperature to return the Pod Rate to the optimal Pod Rate while regularly crossing the Bean price over its value peg. Beanstalk acts more aggressively when the Pod Rate is excessively high or low.

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 Disclosures). Beanstalk is willing to issue Pods every Season.

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 adjusts it to move closer to ideal equilibrium.

Low Friction

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

The FIFO Pod Harvest schedule allows smaller Sowers 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 liquid secondary market 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 arbitrarily increase the Bean supply 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 Soil affects marginal demand for Beans). The marginal demand for Soil and Beans are functions of the Temperature and the Bean price. By changing the Temperature, 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).

The Stalk System incentivizes (1) leaving assets Deposited in the Silo continuously by creating opportunity cost to Withdraw assets from the Silo, (2) adding value to liquidity pools with Beans by rewarding more Seeds to Deposited LP tokens than Deposited Beans, and (3) returning the Bean price to its value peg by allowing Conversions 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 (Flood) 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.

Governance

Beanstalk

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

Prior to Beanstalk’s April 17, 2022 exploit, Beanstalk Improvement Proposals (BIPs) were entirely on-chain and autonomous. However, after the exploit, Beanstalk was Paused and the ability to propose BIPs on-chain halted. Until governance is removed entirely, BIPs will be voted on off-chain via Snapshot and will be executed on-chain by the Beanstalk Community Multisig (BCM). Stalkholders are able to vote on BIPs via Snapshot.

BIPs are proposed on the Beanstalk DAO Snapshot page. Stalkholders can vote on BIPs on the Beanstalk UI Governance page. Past BIPs can be read here.

Participation

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

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

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

Voting Period

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

If at the end of the Voting Period:

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

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

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

Pause

In case of a particularly dangerous vulnerability to Beanstalk, the BCM can Pause Beanstalk without a Snapshot. You can read more about which actions the BCM can take without a Snapshot proposal here. The Beanstalk DAO can also Pause Beanstalk via BIP.

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

Commit

The BCM address has the exclusive and unilateral ability to Pause or Unpause Beanstalk, and commit a BIP. In the future, it is expected that BIPs will remove governance entirely, revoking these abilities from the BCM. You can read more about the BCM here.

BCM Process

This document can be found on Arweave .

The Beanstalk Community Multisig, or BCM, custodies ownership of the . 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 , 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

The following functions are only callable from the owner address:

diamondCut — Add, replace and/or remove any function(s) and/or execute an init function with a delegatecall.
whitelistToken — Add a token to the Deposit Whitelist.
dewhitelistToken — Remove a token from the Deposit Whitelist.
pause — Pause Beanstalk, which makes it such that the gm function cannot be successfully called.
unpause — Unpause Beanstalk, which allows the gm function to be successfully called at the top of the 2nd hour. The TWAP oracle and Season timer are reset as well.
createFundraiser — Create a Fundraiser.
transferOwnership — Transfer ownership of the Beanstalk contract to a new address.
addUnripeToken — Add an Unripe token to Beanstalk.

Snapshot Usage

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

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

BIP Proposal and Voting

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

BIP Proposal Content

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

A written proposal of the changes that would be implemented in the BIP, which must include:
- A Contract Changes section that includes the facets and the init contract address in the diamondCut call, if applicable; and
- A Beans Minted section that describes the number of Beans minted by the BIP, if applicable.

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

BIP Proposal Process

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

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.
Allow sufficient time for discussion of the proposal. What constitutes sufficient is at the sole discretion of the BCM.
Tag the @BCM Liaison user to request that the BIP be formally proposed.
The BCM shall then formally propose the BIP by submitting the on-chain transaction and Snapshot proposal.
If the BIP passes, the Signers will sign m/n signatures and execute the on-chain transaction as soon as possible. If the BIP fails to pass, the Signers will submit and execute a cancel transaction with the same nonce as soon as possible.

BIP Voting

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

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

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

If at the end of the Voting Period:

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

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

BOP Proposal and Voting

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

BOP Proposal Content

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

BOP Proposal Process

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

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.
Allow sufficient time for discussion of the proposal. What constitutes sufficient is at the sole discretion of the BCM.
Tag the @BCM Liaison user to request that the BOP be formally proposed.
The BCM shall then formally propose the BOP by submitting the Snapshot proposal.

BOP Voting

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

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

If at the end of the Voting Period:

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

BIR Proposal and Voting

BIR Proposal Content

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

BIR Proposal Process

BIR Voting

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

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

Signer Best Practices

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

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.

As soon as possible after the Voting Period:

If the proposal passed, Signers who have verified the transaction will sign and execute the transaction; or
If the proposal failed, Signers with sign and execute a cancel transaction with the same nonce.

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

Act against Stalkholders' off-chain voting (or the BIC's off-chain voting in the case of BIRs);
Get through 2 votes without performing any of their Signer duties.

Verifying and Signing Transactions

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

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

Performing the diamondCut on a local mainnet fork and confirm that the facet addresses, function selectors and facet cut actions are correct;
Confirming that the _init address and _calldata are correct; and
Confirming that the deployed bytecode for changed facets matches the corresponding bytecode compiled from the GitHub PR branch.

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

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;
Was not responsive in 2 months; or
Votes against the outcome of any proposal, in which case the Signer would be subject to removal immediately.

Problems During Verification

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

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

The BCM will respond as follows:

If the BCM determines that the Signer is "rogue" and attempting to censor the transaction, the BCM will indicate that by continuing to verify (and ultimately sign and execute, in the case that the proposal passes) the transaction; or
If the BCM determines that the Signer is not rogue, the BCM will indicate that by submitting, signing and executing a cancel transaction with the same nonce.

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

Emergency Response Procedures

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

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

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

If a bug or vulnerability is severe and requires significant code changes to fix, the BCM may remove functions from Beanstalk and take any necessary extra action to mitigate further damage; or
If a bug or vulnerability is minor and does not require significant code changes to fix, a hotfix may be implemented by the BCM.

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

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

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

Rotating Signers

Anonymous Signers

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

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

Malicious Key Holder Risk

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

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

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

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

BCM Dashboard

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

Beanstalk Community Multisig Safe address: 0xDd5b31E73dB1c566Ca09e1F1f74Df34913DaaF69

The Beanstalk contract is guarded by a 5-of-9 multisig. This means any changes to the Beanstalk contract must be approved by at least 5 of the 9 signers.

BCM Signers

Publius currently holds 1 of the 9 keys on the BCM. The identities of the remaining signers are anonymous per #anonymous-signers.

See the BCM Verification page for more information on how the BCM is verifying transactions.

Address

Verifications

Date of Last Verification

07/20/24

07/26/24

05/30/24

10/04/24

10/02/24

05/30/24

07/25/24

10/04/24

10/05/24

Signer Hashes

Signers hashes are published from 0x925753106fcdb6d2f30c3db295328a0a1c5fd1d1, the address that Publius used to deploy Beanstalk on August 6, 2021.

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 Immunefi Bug Bounty Program page. The latest version of the program approved by the DAO can be found on Arweave here.

In summary:

The max bounty is 1,100,000 Beans;
Bugs are categorized as Critical, High or Medium severity;
The BIC determines whether a whitehat is entitled to a bug bounty/reward, and if so, the amount of such bounty/reward according to the defined bug bounty program structure; and
Immunefi serves as a mediator in cases where a whitehat disputes the BIC's determination of whether the whitehat is entitled to any bug bounty/reward, or what the appropriate bounty/reward should be within each Impact range.

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

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

The BIC structure of community-known members (see BICM Dashboard) and public Snapshot proposals (see Beanstalk Bug Bounty Snapshot space) 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 #response-process; and
Updating the Immunefi Bug Bounty Program when necessary.

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

Adding/removing assets as in scope, particularly adding contracts that have been audited and/or have attracted large amounts of Beans/BDV;
Adding/removing impacts as in scope;
Adding/removing rules to the Out of Scope section;
Adding documentation and links; and
Updating language to improve clarity.

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

Changing Members

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

Response Process

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

Immediate Response

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

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

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

Bug Fix

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

If it is determined that the bug report is valid, the BIC will work with the corresponding party (the BCM, 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
Whether the whitehat is entitled to a bug bounty/reward, and if so, the amount of such bounty/reward.

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

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

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

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

Publish the BIR to Snapshot;
Announce the existence of the BIR to the Beanstalk community via the Discord; and
Vote on the BIR.

BIR voting takes place on the Beanstalk Bug Bounty Snapshot space 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 Immunefi Vault, 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.

BICM Dashboard

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

See for more information.

Beanstalk Community Multisig Safe address:

BICM Signers

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

aloceros
Brean
Chaikitty
deadmanwalking
funderberker
mod323
pizzaman1337

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

uncoolzero
MrMochi
guy

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

Beans Paid

Total to Whitehats: 1,536,350 Beans

Remaining in Immunefi Vault: 2,447,000 Beans

Bugs found: 21

Beanstalk Farms

The Beanstalk DAO is responsible for the formation of two independent, symbiotic organizations with distinct mandates: Beanstalk Farms and (a Beanstalk accelerator program).

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

Funding

Neither Beanstalk Farms nor Beanstalk have a treasury. Beanstalk Farms has historically been funded by the Beanstalk DAO. Beanstalk Farms proposes budget BIPs that mint Beans to cover operating expenses and compensate contributors. Budget funds are custodied by the . Larger payments in non-Bean assets like audits have historically been paid for via .

Past BIPs that funded Beanstalk Farms:

(included Beanstalk Farms and Bean Sprout)

Monthly reports on how Beanstalk Farms is spending its budget can be found .

Beanstalk Farms Committee

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

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

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

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

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

BFM Dashboard

Beanstalk Farms budget funds are custodied by the Beanstalk Farms Multisig, or BFM. The BFM is deployed using Safe. Its m-of-n configuration is currently 4-of-7 on Arbitrum. This means any use of the budget funds must be approved by at least 4 of the 7 signers.

Beanstalk Farms Multisig Safe address:

BFM Signers

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

Michael Montoya
Brean
guy
sweetredbeans
mod323
aloceros
Cujo

The following Farmers serve as backup signers for the BFM, in no particular order:

pizzaman1337
CanadianBennett
MrMochi

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 .

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 .

BeaNFTs

BeaNFTs were the first project built on top of Beanstalk. BeaNFTs have historically been awarded to Farmers for interacting with Beanstalk during certain time periods. BeaNFT contract addresses can be found on the page.

You can read more about them here:

OpenSea:

Governance

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

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

If at the end of the Voting Period:

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

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

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

Proposals

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

Notes

In all proposals where Stalkholders vote:

A Stalkholder's vote for a given proposal is counted as their Stalk at the beginning of the Voting Period that still exists;
1 Stalk equals 1 vote; and
The proposer must have at least 0.1% of total Stalk at the beginning and end of the Voting Period (including delegated Stalk) in order for the proposal to pass.

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

Beanstalk Improvement Proposal

Beanstalk Improvement Proposals, or BIPs, are proposals to:

Change the Beanstalk protocol;
Mint Beans; and/or
Change Beanstalk governance.

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

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

If at the end of the Voting Period:

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

Beanstalk Operations Proposal

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

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

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

If at the end of the Voting Period:

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

Emergency Beanstalk Improvement Proposal

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

Beanstalk Farms Committee Proposal

Stalkholders vote to:

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

BFCP-A

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

If at the end of the Voting Period:

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

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

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

BFCP-B

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

If at the end of the Voting Period:

Less than or equal to 35% of total Stalk is voting For or the majority of participating Stalk is voting Against the BFCP-B, it fails, or
More than 35% of total Stalk votes For and the majority of participating Stalk is voting For the BFCP-B, it passes.

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

BFCP-C

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

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

If at the end of the Voting Period:

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

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

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

Beanstalk Farms Budget Proposal

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

BFC members vote to:

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

BFBP-A

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

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

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

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

BFBP-B

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

If at the end of the Voting Period:

Less than a majority of the BFC is voting For the BFBP-B, it fails, or
At least a majority of the BFC is voting For the BFBP-B, it passes.

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

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

BFBP-C

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

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

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

Beanstalk Immunefi Response

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

If at the end of the Voting Period:

Less than a two-thirds majority of the BIC is voting For the BIR, it fails, or
At least a two-thirds majority of the BIC is voting For the BIR, it passes.

BeaNFT Proposal

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

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

If at the end of the Voting Period:

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

A BNP 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.