Because Beanstalk is a single contract, all of the Facets can share a common state through the AppStorage pattern.

Each Facet should define the AppStorage storage variable in the base contract and define no other internal or public state variables.

AppStorage internal s;

The AppStorage struct can be found in the AppStorage.sol file.

When adding new state variables, always add them to the end of the AppStorage struct to ensure consistent mapping of state variables to storage slots. When deprecating an unnecessary state variables, either replace it with a different variable denoting that the state variable is deprecated or leave it as is.

In the EVM, data is accessed 32 bytes at a time (known as a slot). Because of this, in Beanstalk, many state variables are packed within the AppStorage struct to reduce gas costs. For example, say that in function foo, the state of 2 uint256 values is changed. Changing a non-zero value to another non-zero value costs 10000 gas (2 * 5000). If the 2 values could be stored in uint128s instead (meaning the data is in one slot), 2100 gas is shaved off, as the state slot is now warm. (If a slot is touched for the first time in a transaction, it is turned from cold to warm for the rest of that transaction. Warm touches are cheaper than cold touches.)

The Agronomics Handbook is a collection of technical documentation about Beanstalk.

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

Beanstalk strives to create product market fit on both a technical and economic level.

Beanstalk pioneers a path forward for devising more efficient and complex systems. Beanstalk is implemented in Solidity v0.8.20 for intended use in the EVM. Beanstalk leverages EIP-2535 to minimize gas costs and complexity.

The contract code can be found below. Beanstalk is deployed at 0xD1A0060ba708BC4BCD3DA6C37EFa8deDF015FB70.

• If you are looking for non-technical documentation about Beanstalk, check out the .

• If you are looking for comprehensive formulas behind Beanstalk's mechanics, check out the .

• If you have any other questions while browsing the Agronomics Handbook, join the Beanstalk Discord and ask in the (#🪵・development) channel!

Please share any feedback on the Agronomics Handbook in the (#📜・docs-feedback) channel in Discord and stay tuned for updates in (#📜・docs-updates). You can submit a pull request to the Agronomics Handbook yourself .

Links

The Beanstalk contract is a Diamond – a multi-facet proxy defined in that can implement functionality from numerous different Facet contracts.

All the Facets share a common storage through the pattern. Functionality is shared between Facets through internal Libraries.

Understanding EIP-2535 really helps to understand Beanstalk. This page serves as a resource hub for EIP-2535.

What is a Diamond?

Beanstalk is a permissionless fiat stablecoin protocol built on Arbitrum.

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

Beanstalk's primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean across its value peg of $1 in a sustainable fashion. The stability of the Bean price relative to its value peg is a function of the creditworthiness of Beanstalk—Beanstalk attracts lenders when the price of a Bean is below its value peg to remove Beans from the supply and increase their price.

When the Bean price is too high, Beanstalk mints new Beans and distributes them to various ecosystem participants in a deterministic fashion. This inflation is that the Beanstalk economy is based on.

Beanstalk implements several novel mechanisms including a first-in-first-out (FIFO) supplemented by

Decentralized blockchains like Ethereum impose extreme computational and storage limitations. While centralized computation solutions allow the execution of advanced statistical models on gigabytes of data, decentralized systems force users to pay for every byte stored and basic arithmetic operation performed on-chain.

Decentralized systems will scale infinitely over time, eventually allowing users to perform large scale machine learning operations on decentralized architectures. However, it's imperative to start building, experimenting with and iterating on the financial primitives that will define the foundations of permissionless ecosystems. Otherwise, it is likely that they will merely mimic those of the centralized world. Beanstalk is an attempt at implementing a permissionless fiat currency designed to become the basis of the rent-free economy that decentralized primitives are ushering in.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupéry

No one wants to be limited, but resource scarcity forces innovation. For example, because Ethereum does not lend itself to trading on order books, Automated Market Makers (AMMs) like and created liquidity pools based on a predefined pricing curve to create an efficient exchange format (instead of a high frequency order book).

AMMs are still being iterated and innovated on. Uniswap created an order book/AMM hybrid with Uniswap V3. implemented capital efficient pricing curves. Bancor built an omnipool, providing impermanent loss protection. supports a 0% (customizable) fee AMM.

Open source protocols are a public good. More than protocols have forked Uniswap V2 to try to improve on its model. Some may call it competitive, but it is also collaborative. Each implementation is more advanced than its previous iteration and is made possible through increasingly efficient allocation of EVM resources.

Question everything, be critical, and collaborate.

The Farm allows Farmers to call multiple functions in a single transaction and use assets between different functions in a composable manner, without those assets every leaving Beanstalk (thanks to Internal Balances). Internal Balances allow the farm function to use the output of a function in the next function call.

The Farm also provides composable Beanstalk-native interfaces for other DeFi protocols. This allows Farmers to call supported external protocols through the farm function and leverage Internal Balances. The current protocols that the Farm supports are:

• WETH -> wrapping and unwrapping; and

• Curve -> swapping and adding/removing liquidity.

• Pipeline -> performing an arbitrary series of actions in the EVM in a single transaction.

The Farm creates an interface to transfer ERC-20 tokens between Internal and External Balances, as well as between Farmers through the transferToken function.

The Farm consists of 5 facets:

The Diamond module contains various functions that require ownership of Beanstalk to execute in Beanstalk. This includes Pausing and Unpausing Beanstalk and upgrading Beanstalk via Diamond Cuts.

See EIP-2535 Diamond to read more about Beanstalk's upgradable proxy implementation.

The Diamond consists of 4 facets:

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

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.

Anytime there is Soil in the Field, Farmers can Sow Beans in exchange for Pods. Pods are stored in Plots and placed at the end of the Pod Line.

The Pause Facet handles the Pausing and Unpausing of Beanstalk.

The Market will house various DEXs for zero fee trading. For now, there is only the Pod Market, but in the future there may be a zero fee AMM, a zero fee NFT marketplace, etc.

The Pod Market allows Farmers to create, Fill and Cancel Pod Listings and Pod Orders.

Pod Listings

Farmers with Pods can create Pod Listings, which allow other Farmers to buy part or all of their Plots at a given price.

Pod Listings are contained in the following struct:

Pod Listings are created with the createPodListing function. Pod Listings can only be created by the owner of the Plot being listed.

When a Pod Listing is created, The PodListing struct with the exception of account and index is encoded and hashed. Beanstalk stores the hash of the listing on-chain in the s.podListings state mapping. Pod Listing hashes are stored by index of the corresponding Plot. The Pod Listing struct is emitted in an event upon creation.

Pod Listings are Filled with the fillPodListing function. The Pod buyer is required to input the PodListing struct associated with the Plot being transferred. Beanstalk hashes the PodListing data and verifies that the hash is the same as the hash in storage at the corresponding index. If the original Plot owner no longer owns the Plot, then the transaction will fail. If the Fill is successful, Beanstalk then transfers the corresponding part of the Plot to the buyer in exchange for Beans. If the Listing is not empty, the updated Listing is then hashed and stored on-chain.

Pod Listings can be Cancelled at any time with the cancelPodListing function. Pod Listings are automatically Cancelled on Harvest, Transfer or if a new Pod Listing is created with the same plot.

Pod Orders

Pod Orders allow Farmer with Beans to create Orders to buy Plots. An Order specifies a max Place in Line that the Farmer is will to buy Pods at, the price they are willing to by Pods at and the amount they are willing to buy. All Orders are denominated in Beans. Pod Orders are contained in the following struct:

Pod Orders are created with the createPodOrder function. Pod Orders can be created by any Farmer.

When a Pod Order is created, The PodOrder struct is encoded and hashed. Beanstalk stores the hash of the Order on-chain in the s.podOrders state mapping. The hash is the key in the mapping and the amount in the Order is stored in the hash. When a Pod Order is created, Beans are transferred from the Farmer to Beanstalk equal to the amount of Pods being bought times the Price per Pod in the Order. These Beans are locked in Beanstalk until either the Pod Order creator Cancels the Order or the Order is Filled.

Farmers with Pods can sell Pods to open Pod Orders with the fillPodOrder function. The Pod seller is required to input what part of which Plot is being sold and the PodOrder struct associated with Order they are filling. Beanstalk hashes the PodOrder data and verifies that the hash maps to a non-zero value in s.podOrders. The seller is also required to input the Plot being sold as a part of the calldata. If the Fill is successful, the value at the hash key is updated to equal the new amount remaining in the Pod Order.

Pod Orders can be Cancelled at anytime with the cancelPodOrder function. When an Order is Cancelled, Beanstalk returns the remaining Beans in the Pod Order to the Farmer.

The Farm Facet allows Farmers to perform multiple Beanstalk functions calls in a single transaction using farm calls.

The Sun advances Beanstalk to the next Season through the sunrise function in the Season Facet. Every time an hour passes, sunrise can be called 1 more time.

The Season Facet has :

The Diamond Cut Facet is used by the owner to upgrade Beanstalk.

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 and continues until the recapitalization target has been reached.

The Barn is consists of 2 Facets:

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 USDC each. Fertilizer becomes Active when it is bought, at which point the ERC-1155 Fertilizer token is minted.

Active Fertilizer entitles holders to a pro rata portion of 1/3 of Bean mints.

Fertilizer is minted with a given % Humidity. Humidity is dependent on the Season during which the Fertilizer is minted. During Season 6074 (the Season Beanstalk was Paused at), the Humidity was 500%. The next Season, Humidity was set to 250% and decreased 0.5% every Season until it reached 20%. The Humidity will remain at 20% until all Fertilizer is sold.

Each Fertilizer entitles its holder up to 1 + humidity Unfertilized Beans. Unfertilized Beans become Fertilized Beans when Beans are distributed to Active Fertilizer holders. When Fertilizer has no more corresponding Unfertilized Beans, it becomes Used and no longer receives Bean mints.

To track Active Fertilizer, Beanstalk has a global variable s.bpf, which is the cumulative Beans Per Fertilizer (BPF) paid back over all Seasons. Fertilizer is indexed by endBpf = s.bpf + 1 + humidity at the time of minting. This indicates that once s.bpf reaches endBpf, the Fertilizer becomes Used. Beanstalk sorts all non-zero Fertilizer ids by endBpf in s.nextFid. This is a linked list where s.fFirst is the start of the list and s.fLast is the end of the list.

Every Season, Beanstalk increments s.bpf by the number of new Bean mints distributed to Fertilizer holders divided by s.activeFertilizer. Note that Beanstalk integrates s.bpf over s.activeFertilizer—every time s.bpf reaches s.fFirst, s.activeFertilizer decreases by the supply of Fertilizer with an id of s.fFirst. The first item is then popped off the linked list and s.fFirst is set to the next item. When s.fFirst == 0, Beanstalk stops paying Beans to Fertilizer as all Fertilizer is either Used or Available (and thus

Fertilizer can be claimed via the claimFertilizer function (it is also claimed automatically whenever Fertilizer is transferred). The Fertilizer contract stores the lastBpf value for each token id that the Farmer owns. When a Farmer claims Fertilizer, Beanstalk computes how many Beans have been Fertilized since the last time the Farmer Fertilized that id with: min(s.bpf, s.nextFid[id]) – lastBpf. It then gives the Farmer that many Beans for each Fertilizer they have of that id.

Pre-Replant Fertilizer

Before Beanstalk was Replanted, Fertilizer was deployed as FertilizerPreMint.sol, which transferred USDC from the caller to in exchange for Fertilizer. The Fertilizer was issued at the id 6_000_000 as the Humidity was 500% before Replant.

When Beanstalk was Replanted, the BCM called the addFertilizerOwner function that handled the process of adding liquidity to the BEAN:3CRV pool and minting new Beans for all of the Fertilizer minted prior to Replant.

At the same time, the Fertilizer contract was upgraded to . This moved the mintFertilizer() functionality from the Fertilizer contract to Beanstalk itself. From this point forward, Beanstalk automatically adds new liquidity for Unripe LP holders and new Beans for Unripe Bean holders in the same transaction that Fertilizer is minted in.

Unripe Assets

Upon 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 BEAN:3CRV LP for every 1 BDV of each pre-exploit whitelisted LP Token.

As Fertilizer is sold, Beans are distributed to all Unripe Bean holders pro rata (and BEAN:3CRV LP is distributed to all Unripe LP holders) using the shares and underlying token model that uses for yield-bearing tokens. The Unripe tokens are the Shares and Beans/LP are the underlying assets. The underlying portion will continue to increase as Fertilizer is minted in exchange for USDC.

Farmers can Chop their Unripe assets at any point for a penalized percent of the corresponding underlying tokens. The penalized percent is equal to the percent of Unfertilized Beans that have been Fertilized. This can be computed as s.fertilizedIndex / s.unfertilizedIndex.

The Metadata Facet provides metadata for the ERC-1155 Silo Deposits. Deposit IDs are a uint256 that is the concatenation of the token address and the Stem.

Call Functions

None.

View Functions

Returns the URI for a given Deposit ID.

Returns the name of the collection for OpenSea compatibility.

Returns the ticker of the collection for OpenSea compatibility.

Returns the image URI for a given Deposit ID.

Events

Not currently emitted.

The Beanstalk codebase currently uses several terms that are out of date with the whitepaper, the Beanstalk UI, the Farmers' Almanac, etc. The following is a list of outdated terminology used in the Beanstalk codebase and the associated proper terms.

The following discrepancies are in the .

The Legacy Claim Withdrawal Facet allows anyone to Claim and read Withdrawals. removed the Withdrawal Freeze from the Silo. Withdrawing now directly sends ERC-20 tokens to the Farmer's Farm or Circulating balances instead of creating a Withdrawal.

Although new Withdrawals cannot be created, the claim Withdrawal functionality has been preserved in this facet to allow pre-existing unclaimed Withdrawals to still be claimed.

The Diamond Loupe Facet allows anyone to see the available functions within Beanstalk.

The Convert Getters Facet contains view functions for Convert data.

What are Internal Balances?

Beanstalk uses an Internal Balances system largely inspired by . With Internal Balances, Beanstalk is able to store an any ERC-20 token on behalf of a user. Beanstalk stores that the user has that ERC-20 token in . All functions within Beanstalk that either use a user's ERC-20 tokens or send ERC-20 tokens to a user can send/receive the ERC-20 tokens from the user's Internal Balance and/or External Balance (the user's wallet).

Internal Balances can significantly reduce transaction costs for using tokens that remain in Beanstalk. As more protocols utilize Internal Balances, the gas savings can compound.

The Depot Facet wraps Pipeline's pipe functions to facilitate the loading of non-Ether assets in Pipeline.

Call Functions

Pipe a PipeCall through Pipeline.

Pipe multiple PipeCalls through Pipeline. Does not support sending Ether in the call.

Pipe multiple AdvancedPipeCalls through Pipeline.

Pipe a PipeCall through Pipeline with an Ether value.

View Functions

Return the return value of a PipeCall without executing it.

Events

None.

The Ownership Facet handles the ownership of Beanstalk.

Call Functions

Transfers ownership of Beanstalk to a new address. Can only be called by the owner of Beanstalk.

Callable by candidate for ownership after a successful transferOwnership function call.

View Functions

Returns the address of the owner of Beanstalk.

Returns the owner candidate of Beanstalk.

Events

Emitted when ownership of Beanstalk is transferred.

The BDV Facet holds functions to get the BDV for each whitelisted Silo asset.

Farmers can Deposit assets on the Deposit Whitelist into the Silo in exchange for Stalk and Seeds. The number of Stalk and Seeds received is dependent on the BDV at the time of Deposit, the Stalk per BDV and the Seeds per BDV. Stalk entitles Farmers to a pro-rata portion of Bean seignorage distributed to the Silo and Seeds grown into 0.0001 Stalk each Season.

A Farmer can Withdraw at any time, but must forfeit all Stalk and Seeds associated with the Deposit. All Withdrawals are subject to an unlock period (currently set to the remainder of the current Season). Once a Withdraw is complete, it can be Claimed at any time.

Farmers can also convert a Deposited asset into a different one via the Convert function if the ability to convert between those two assets is on the . Each Convert type must be approved via governance and the Convert functionality must be added to LibConvert.

Adding and Removing Assets on the Deposit Whitelist

Assets can only be Deposited into the Silo if the assets are on the Deposit Whitelist. A token is considered on the Deposit Whitelist if it has a non-zero Silo Settings in Beanstalk’s storage. Silo Settings for each asset on the Deposit Whitelist are stored in the s.ss mapping in defined as:

• The key used in the mapping is the ERC-20 token address.

• selector is a function selector that calculates the BDV of a given amount of the token. selector should be an encoded external view function added to the Beanstalk diamond. BDV is represented with 6 decimal places.

Tokens can be added to the Deposit Whitelist via BIP. In order to Whitelist a token, an address, BDV function selector, Stalk per BDV and Seeds per BDV must be included in the proposal. The BDV function selector must either already be added to Beanstalk or be added as a part of the BIP.

Similarly, tokens can be Dewhitelisted (removed from the Deposit Whitelist) via BIP.

Bean Denominated Value

All Deposited assets are valued based on the Bean Denominated Value (BDV) at the time Deposit. Each asset on the Deposit Whitelist has a unique BDV function in the to calculate the BDV of a given amount of the asset.

Stalk and Seeds

Stalk entitles the Farmer to a pro rata portion of at least 1/3 of Bean mints and 1 Stalk is 1 vote in Governance. Beans mints allocated to the Silo are called Earned Beans. Farmers also receive 1 Earned Stalk and 2 Earned Seeds for each Earned Bean.

Each Seed grows 0.0001 Stalk every Season. Stalk grown from Seeds is called Grown Stalk.

There are 3 types of Stalk:

• Stalk -> Stalk stored in a Farmer’s account storage. Stalk is acquired by Depositing, Converting, Updating or Planting.

• Earned Stalk -> A Farmer receives 1 Earned Stalk for each Earned Bean. Earned Stalk automatically compounds and receives a portion of Bean mints. Earned Stalk is claimed as part of the plant function, which turns it into Stalk. Because it is considered active, Earned Stalk has already been minted and it is included in the totalStalk and balanceOfStalk counts. To the Farmer, Earned Stalk is no different from Stalk and just serves as an indicator of how much Stalk has been earned through Bean seignorage since the last plant

There are 2 types of Seeds:

• Seeds → Seeds stored in a Farmer’s account storage. Seeds are acquired by Depositing, Planting and in certain cases, Converting.

• Earned Seeds → A Farmer receives 2 Earned Seeds for each Earned Bean. Earned Seeds are not active. Earned Seeds can be claimed via the plant function, which turns them into Seeds. Because Earned Seeds are not active, they are not included in the totalSeeds or balanceOfSeeds function.

Deposit

Farmers can deposit Whitelisted ERC-20 tokens in the Silo in exchange for Stalk and Seeds via the deposit function. deposit first calls the BDV function selector stored in Storage to calculate the BDV of the Deposit. It then distributes Stalk and Seeds to the Farmer based on the Stalk per BDV and Seeds per BDV.

A Deposit is stored in the current Season to record at what Season the Seeds associated with the Deposit started accruing Grown Stalk. The total Seeds and Stalk associated with a Deposit can be calculated as:

Deposits are stored in the Account storage as:

• The mapping is from token address to Season to Deposit.

• amount is the amount of tokens in the Deposit. A Farmer can Withdraw up to amount.

• bdv

Withdraw

Farmers can Withdraw any Deposit via the withdrawDeposit or withdrawDeposits functions. When a Farmer Withdraws, they specific the token, the Season(s) of the Deposit(s) and the corresponding amount(s) to Withdraw.

In order to Withdraw a Deposit, a Farmer must burn all of the Stalk and Seeds associated with the Deposit.

A Withdraw is locked for a certain number of Seasons. This number is stored in s.season.withdrawSeasons. This number is equal to the # of full Seasons required for Withdraw plus 1. The plus 1 accounts for the partial Season that Farmer Withdraws in.

The Season of a Withdrawal is equal to the Season at which the Withdrawal can be Claimed (Not the Season that the Withdrawal is initiated).

A Withdraw is in the following mapping:

• The mapping is from token address to Season to amount.

Claim Withdrawal

Farmers can Claim Withdrawals that have been unlocked via the claimWithdrawal and claimWithdrawals functions. A Withdrawal is Claimable if the current Season is greater than or equal to the Season of the Withdrawal. A Withdrawal is Claimed by specifying the token and Season(s) of the Withdrawals to Claim. When a Withdrawals is Claimed, the Withdrawal is deleted and the Farmer receives the corresponding amount of the underlying token.

Convert

Farmers can Convert one asset on the Deposit Whitelist (Token A) to another asset on the Deposit Whitelist (Token B) if Converting from Token A to Token B is on the Convert Whitelist. convert takes in a convertData payload that stores the encoded Convert data payload. Convert data is encoded so that different Convert types can have different parameters as necessary. However, each Convert type must specify at least the Convert type and the amount to Convert. Farmers must also specify the Season(s) of Deposits and corresponding amounts to Convert.

Convert does 3 main actions:

1. Converts some amount of Token A to Token B via LibConvert;

2. Removes Deposits of Token A equal to the amount of Token A that was Converted; and

3. Adds a Deposit of Token B equal to the amount received in Convert.

Convert uses the maximum of the BDV of Token A and Token B so that BDV is never lost. Thus, the Farmer won’t lose any Stalk during Convert, but may still gain Stalk depending the BDV of Token B. Seeds can be gained or lost depending on the Seeds per BDV of Token B versus Token A.

Grown Stalk is preserved during Convert and the Season that Converted assets are Deposited into is depending on the number of Grown Stalk:

Converts may have a maximize amount that can be converted from Token A to Token B. For instance, Deposited Beans can only be converted into Deposited BEAN:3CRV LP tokens if the price in the BEAN:3CRV pool is greater than $1 after the Convert. This can be retrieved via the getMaxAmountIn function.

The getAmountOut function returns the expected output amount of a given Convert.

New Converts can be approved via adding new Convert types to LibConvertData and adding the Convert case to LibConvert.

Who calls the gm function?

In theory, anyone is able to call the gm function. In practice, MEV bots will front run your transaction by calling the function themselves as they can determine that they will get the Beans instead of you. As there are a number of bots playing the Sunrise game, the chances of getting a successful gm call from clicking the Sunrise button on the UI are essentially zero.

Where can I call functions directly on Beanstalk?

Louper allows users to directly call functions in a contract that implements EIP-2535, as Etherscan does not yet support this. The Beanstalk contract on Louper can be found .

Why do Beans only have 6 decimals?

Solidity has a limit of 2^256 - 1 ~= 1e77 for integers. Beanstalk is a complex protocol that does a lot of multiplication of big numbers which could potentially bring that upper integer limit into play, especially in the Flood functionality. Given that Bean is a stablecoin and the the value peg is $1, there is no need for an excessive amount of decimals. By reducing decimals to increase protocol security in the long run, Beanstalk is better set up for success. Note that USDC and Tether both have 6 decimals.

A lot of tokens have 18 decimals. Non-stable tokens have to be functional at any possible price at any point in the future.

Let's take the example of ETH and say that the ETH price is $4300. $0.01 is about 0.0000023 ETH. Thus, for ETH to be tradable at the cent level, it needs to have at least 7 decimals. Now fast forward 100 years and let's say (hypothetically) that ETH is worth $1,000,000,000. This would require ETH to have 11 decimals to be transacted at a cent level. Thus, it makes sense for ETH to have 18 decimals.

In terms of gas cost, there is no difference between 6 and 18 decimals.

How are proxy contracts used to upgrade Beanstalk?

Delegate calls in Solidity allow a smart contract to use functionality stored in another contract’s bytecode and apply it to its own memory.

Traditionally, an upgradeable contract is a proxy address with an implementation contract. All calls to the proxy use the logic stored in the implementation contract, but update the state of the proxy. Thus, by changing a proxy’s implementation address, one can change the functionality in a contract while maintaining the same state and address. You can read about it more on the OpenZeppelin docs and . Beanstalk is actually a multi-facet proxy implementation called a Diamond. This implementation is defined by EIP-2535. allows a single proxy to implement multiple smart contracts at the same time. You can read more about the reasoning behind EIP-2535 usage with Beanstalk .

What are Roots?

Roots were implemented in . Roots are an underlying accounting variable for Stalk in order to track how many Earned Beans a Farmer has earned. When a Farmer Deposits assets or Mows Grown Stalk, they are given Roots proportional to the Stalk they receive: newStalk * totalRoots / totalStalk.

When Beanstalk mints Beans, it increases totalStalk but not totalRoots, which in effect, increases stalk / root. When a Farmer Mows their Grown Stalk, the ratio: farmerStalk / farmerRoots = totalStalk / totalRoots is restored. (In this formula farmerStalk is equal to the Stalk they have after Mowing.)

earnedStalk = farmerStalk - totalStalk / totalRoots * farmerRoots (In this formula farmerStalk is equal to the Stalk they have before the Mow.) 1 Stalk = 1 Bean, so earnedBeans = earnedStalk.

Why build a zero fee AMM?

From an engineering perspective, building a zero fee AMM is simpler than building an AMM with fees—you can simply skip the code that implements the fee when a swap occurs.

From an economic perspective, the concept is that Silo yield is a sufficient enough incentive to attract and retain liquidity providers such that there is no need to charge a fee on swaps.

Why is having zero fees important? Given that whether deltaB < 0 or deltaB > 0 is a defining data point in how Beanstalk's peg maintenance operates, any fee on swaps creates a serious inefficiency in Farmers' ability to arbitrage the peg. The BEAN:3CRV pool charges a 0.04% on swaps (including Convert). This means that buying or Converting above the price of $0.9996 means you are paying more than $1 per Bean and selling or Converting below $1.0004 means you are getting less than $1 per Bean. Any Farmer who is constantly arbitraging the price within this range is losing money overtime instead of making a profit (which they should be). For reference, the BEAN:ETH pool previously had a 0.3% fee, which created an even more extreme inefficiency in peg maintenance.

In addition, Beanstalk can overtime become the primary liquidity provider for all of DeFi by providing the cheapest on-chain swaps between two non-Bean assets.

Why aren't Pods / Plots implemented with an ERC standard?

Plots function completely differently than both ERC-721 and ERC-1155. ERC-1155 doesn't work for Plots/Pods as Pods require ordinality for FIFO Harvesting. ERC-721 could work for Pods, but its hard to see how this would add value. ERC-721 tokens are non-divisible, so it would only allow entire Plots to be bought and sold on NFT marketplaces, which is far less efficient that the current Pod Market. Implementing Pods as ERC-721 would increase the cost of Sowing, Harvesting, Transferring, buying and selling.

Why doesn't Fertilizer.sol have an initialize function?

When Fertilizer was originally deployed. It was deployed as the FertilizerPreMint.sol contract, which has an initialize function that calls __Internallize_init . The initialize function was run on deployment. When Beanstalk was Replanted, The Fertilizer proxy contract was upgraded to the Fertilizer contract found . This is the current implementation contract you see on Etherscan. There was no additional initialization needed as __Internallize_init was already executed. Thus, the Fertilizer contract has no need to have an external initialize function.

Why is the BDV of urBEAN3CRV lower than the BDV of urBEAN?

On October 25, 2022, two values could be found on the :

• Underlying per urBEAN3CRV: 0.219823021543684162

• Underlying per urBEAN: 0.222227

• Dividing the two numbers: 0.219823021543684162/0.222227 = 0.9891823

This implies that 1 urBEAN3CRV will only ripen into 0.9891823 BEAN3CRV (i.e., not 1 BEAN3CRV) when Beanstalk is full recapitalized, assuming there are no Chops, no fees, deltaB = 0 and 1 BEAN3CRV = 1 BEAN. 1 urBEAN will ripen into 1 BEAN.

There are numerous reasons for this discrepancy, but the most significant is that deltaB > 0 when the exploit occurred, so the BDV of LP tokens at the time was less than 1.

Why are Beans minted for a Fundraiser just to later burn them?

See .

Fundraisers are meant to mimic an OTC swap where the buyer trades some stablecoin for a Bean and then automatically Sows the bought Beans for Pods, similar to how the credit mechanism to sustain the peg works. As defined in the whitepaper, Sowing requires a Bean to be burned in exchanged for the Pods. At the start of the Fundraiser, Beans are minted. These Beans represent (1) expected "sell pressure" for Beans as they can be sold at anytime for 1 stablecoin (normally USDC) and (2) expected Pod issuance given that the Beans will be Sown into Pods.

Algorithm Explanations

totalDollars is the total dollar value required to be raised in the Barn Raise. It is equal to dollarPerUnripeLP() * unripeLP().totalSupply(). If no Farmer has forfeited Unripe LP, then totalDollars is 77 million, but given that Farmer's can chop their Unripe LP and forfeit the funds they have not yet been paid back, we need totalDollars to decrease with the total supply of Unripe LP.

if (s.recapitalized >= totalDollars) return 0; —

A safe guard in case Beanstalk ends up in a situation where too much is raised. This is also possible if someone uses the chop function at a penalty even after the full amount has been raised.

return totalDollars.sub(s.recapitalized); —

s.recapitalized is incremented every time USDC is exchanged for Fertilizer (or Unripe LP is generated through Convert), but it is equal to the dollar value that has been recapitalized. Thus, the difference between the two is the amount remaining.

See .

It is assumed that if |deltaB| > beanSupply / 100, then manipulation occurred. This isn't always true, but the ramifications if |deltaB| > beanSupply / 100 naturally are minimal as Beanstalk will simply mint fewer Beans/less Soil this Season.

Theoretically, a multi-block MEV attack could manipulate deltaB to be any value. Multi-block MEV can only be executed on some time cadence dependent on % ownership of Ethereal stake. Therefore, the greatest vulnerability to Beanstalk is a massive one-time Bean/Soil issuance. By adding this supply cap, the maximum effect of potential manipulation can be at most 1% of supply.

The Convert Facet handles Conversions between assets in the Silo and Enrooting Unripe Deposits.

Beanstalk can be broken down into 7 different Modules consisting of 25 Facets:

• (1 Facet)

The Migration Facet contains functions related to . Farmers are required to migrate to the new accounting system created by the Silo V3 upgrade.

The Token Support Facet handles permits for ERC-20 and ERC-721 tokens and transfers for ERC-721 and ERC-1155 tokens.

Call Functions

permitERC20 is a wrapper function for permit of token.

Execute an ERC-721 token transfer.

Execute a permit for an ERC-721 token.

Execute an ERC-1155 token transfer of a single ID.

Execute an ERC-1155 token transfer of multiple IDs.

View Functions

None.

Events

None.

Whitelist Facet handles the whitelisting/dewhitelisting of assets on the Deposit Whitelist.

Call Functions

Dewhitelists tokens on the Deposit Whitelist. A token can no longer be Deposited in the Silo after dewhitelisting. Can only be called by the owner of Beanstalk.

Adds a token to the Deposit Whitelist. Can only be called by the owner of Beanstalk.

Adds a token to the Deposit Whitelist with an encodeType. Can only be called by the owner of Beanstalk.

Changes the Grown Stalk per BDV per Season for a token on the Deposit Whitelist. Can only be called by the owner of Beanstalk.

View Functions

None.

Events

Emitted when a token is added to the Deposit Whitelist.

Emitted when the Grown Stalk per BDV per Season for a token on the Deposit Whitelist is changed.

Emitted when a token is removed from the Deposit Whitelist.

The Enroot Facet handles logic for Enrooting Unripe Deposits.

Call Functions

Claims outstanding Revitalized Stalk and Seeds and updates BDV of a single Unripe Deposit.

Claims outstanding Revitalized Stalk and Seeds and updates BDV of multiple Unripe Deposits.

View Functions

None.

Events

Emitted when account removes a single Deposit from the Silo. Occurs during Withdraw and Convert.

Emitted when account removes multiple Deposits from the Silo. Occurs during Withdraw and Convert.