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.
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.
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.
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.
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.
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.
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.
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).
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).
The following outlines the process that the BIC follows upon receipt of a bug report.
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.
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.
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.
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.
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: 0xa9bA2C40b263843C04d344727b954A545c81D043
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.
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.
Signers hashes are published from 0x925753106fcdb6d2f30c3db295328a0a1c5fd1d1, the address that Publius used to deploy Beanstalk on August 6, 2021.
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 Ethereum mainnet.
See BIC Process for more information.
Beanstalk Community Multisig Safe address: 0x879c8B99430F28C4d297BD479Cd43396b4aCF697
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.
Total to Whitehats: 1,530,350 Beans
Total to Immunefi: 138,335 Beans (excluding the annual Immunefi subscription fee beginning after BIP-41)
Remaining in Immunefi Vault: 2,453,000 Beans
Bugs found: 19
The BCM is not intended to have decision making power. Its role is to enact on-chain the decisions Stalkholders make via off-chain voting and review and verify proposals to ensure the suggested changes are truthfully represented.
USDC from Fertilizer sales were custodied by the BCM between the beginning of the Barn Raise on June 6, 2022 and Replant on August 4, 2022.
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.
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:
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.
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.
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.