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: 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.
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.
| 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
This document can be found on Arweave here.
The Beanstalk Community Multisig, or BCM, custodies ownership of the Beanstalk contract. The BCM has the exclusive and unilateral ability upgrade Beanstalk. In the future, it is expected that BIPs remove governance entirely, revoking these abilities from the BCM.
The BCM is not intended to have decision making power. Its role is to enact on-chain the decisions Stalkholders make via off-chain voting and review and verify proposals to ensure the suggested changes are truthfully represented.
The BCM is deployed using Safe, the most battle-tested multisig contract on Arbitrum. Its m-of-n configuration is 5-of-9. Parameters m and n are each ultimately defined by Stalkholders and may evolve in the future via Beanstalk Improvement Proposal (BIP).
BCM Signers are an anonymous 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.
Beanstalk implements the EIP-2535 Diamond Standard, a standard for fully-upgradeable smart contracts.
The mechanism for upgrading a Diamond is by calling diamondCut, which takes arguments of functions to replace and which functions to replace them with. The diamondCut function is only callable by the owner of Beanstalk, which is the BCM.
Upgrades should only be executed after a proposal has passed and Signers have manually reviewed the transaction. However, in the case of an emergency (like a bug or vulnerability), the BCM may execute an Emergency BIP (EBIP) to protect the Beanstalk contract. The best practices for emergency response handling are outlined in the #emergency-response-procedures section.
If a Stalkholder wants to propose a BIP, they can create a pull request to the Beanstalk GitHub repo and begin a formal proposal process outlined in the #bip-proposal-process section.
The BCM also executes the will of the Beanstalk Immunefi Committee (BIC) as determined by Beanstalk Immunefi Responses (BIRs). See #bir-proposal-and-voting.
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.
BIPs are voted on at the Beanstalk DAO Snapshot space.
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.
Past BIPs can be found here.
BIPs can propose to (1) change the Beanstalk protocol, (2) mint Beans and/or (3) change Beanstalk governance. BIPs consist of a pull request on the Beanstalk GitHub repo that includes the following:
Code implementing the proposed changes (or simply a change to the PROPOSALS.md file if there are no associated code changes);
A written proposal of the changes that would be implemented in the BIP, which must include:
A Proposer section that includes an Etherscan verified message (or an Arweave upload if the proposing wallet is a multisig) confirming the proposer of the BIP;
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.
Before the BCM formally proposes the BIP, they shall verify that the written proposal contains all the necessary content per #bip-proposal-content.
The BCM shall then formally propose the BIP by submitting the on-chain transaction and Snapshot proposal.
During the Voting Period (1-7 days), every BCM Signer shall verify the transaction per #verifying-and-signing-transactions. If not all Signers verify the transaction, the BCM may still continue per the process outlined in #rotating-signers.
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.
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.
Any Stalkholder with 0.1% of total Stalk may propose BOPs. If a Stalkholder wishes to propose a BOP they must complete a public proposal process before the BCM will submit a Snapshot proposal on their behalf.
Past BOPs can be found here.
BOPs can propose for the DAO to agree on processes that do not involve (1) changing the Beanstalk protocol, (2) minting Beans or (3) changing Beanstalk governance. BOPs consist of a pull request on the Beanstalk GitHub repo that includes the following:
Updates to the PROPOSALS.md file;
A written proposal of the changes that would be implemented in the BOP, which must include a Proposer section that has an Etherscan verified message (or an Arweave upload if the proposing wallet is a multisig) confirming the proposer of the BOP.
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.
Before the BCM formally proposes the BOP, they shall verify that the written proposal contains all the necessary content per #bop-proposal-content.
The BCM shall then formally propose the BOP by submitting the Snapshot proposal.
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.
The BIC determines the categorization and payout of bug bounties in accordance with the Immunefi Bug Bounty Program approved by the Beanstalk DAO. The BCM executes the will of the BIC as determined by BIRs.
Any BIC member may propose BIRs. Past BIRs can be found here.
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.
See BIC Process.
The following are the processes in place for the BIC to propose and have the BCM execute a BIR:
The BIC shares BIR info with the BCM for them to submit a corresponding on-chain transaction.
The BCM shall then formally propose the BIR by submitting the on-chain transaction.
The BIC shall then formally propose the BIR on the Beanstalk Bug Bounty Snapshot space.
During the 3 day Voting Period, every BCM Signer shall verify the transaction per #verifying-and-signing-transactions. If not all Signers verify the transaction, the BCM may still continue per the process outlined in #rotating-signers.
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.
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
Follow the standard self-custody best practice guide here.
Signers are expected to follow best practices and maintain active communication in order to ensure that there are always enough Signers available to execute transactions in case of an emergency. Signer duties are broken down into three stages: (1) confirming access to their wallet, (2) verifying proposed transactions and (3) executing transactions on the BCM.
Once the Voting Period for a proposal begins on Snapshot, all Signers are expected to promptly review and verify that the proposed transaction accurately reflects the Snapshot proposal per #verifying-and-signing-transactions. This limits blind signing and encourages each Signer to independently verify that a proposed transaction is accurately represented. Anyone can verify that a Signer verified a proposed transaction during the Voting Period.
As soon as possible after the Voting Period:
If the proposal passed, Signers who have verified the transaction will sign and execute the transaction; or
If the proposal failed, Signers with sign and execute a cancel transaction with the same nonce.
A Signer shall lose their role on the BCM (by the remaining Signers removing them) if they:
Act against Stalkholders' off-chain voting (or the BIC's off-chain voting in the case of BIRs);
Do not follow best practices outlined in the #signer-best-practices section; or
Get through 2 votes without performing any of their Signer duties.
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.
Once Signers have verified the transaction, they shall sign a message indicating that they have verified the transaction by creating an Etherscan verified message. This process must be completed for each transaction in a BIP or BIR. See the BCM Verification page for more information on how BCM Signers verify transactions.
If a situation arises where not all Signers submit a verification, the BCM may continue with execution if the Signer:
Was not responsive during the draft phase of the proposal or Voting Period;
Notified the rest of the BCM during the draft phase of the proposal that they would not be able to verify, sign or execute the transaction;
Missed 2 verifications;
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.
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.
Although the BCM's role is to enact on-chain the decisions Stalkholders make via off-chain voting, it is of critical importance that the BCM take swift action to protect Beanstalk in the event of a bug or vulnerability. Emergency upgrades to Beanstalk submitted by the BCM are known as EBIPs.
Bugs or security vulnerabilities qualify as emergencies. Emergency action will not be taken for any reason related to the economic health of Beanstalk.
Past EBIPs can be found here.
Depending on the severity of a given emergency, BCM members shall swiftly decide the best course of action:
If a bug or vulnerability is severe and requires significant code changes to fix, the BCM may remove functions from Beanstalk and take any necessary extra action to mitigate further damage; or
If a bug or vulnerability is minor and does not require significant code changes to fix, a hotfix may be implemented by the BCM.
In cases where functions must be removed immediately to protect Beanstalk, BCM Signers are not required to submit an Etherscan verified message as outlined in #verifying-and-signing-transactions.
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.
In the event that an EBIP must be executed during the Voting Period of another proposal, the on-chain transaction for the outstanding proposal must be canceled.
In order avoid the need to revote on a proposal in this situation, the BCM will repropose the on-chain transaction for the outstanding proposal after the successful execution of the EBIP.
Hypernative actively detects and responds to high confidence pre-exploit and exploit-in-progress detections on Beanstalk. Hypernative custodies an EOA that has the ability to call functions on the Hypernative module added to the BCM. This module has the ability to remove all functions from Beanstalk except for diamondCut, facetAddress, facetAddresses, facetFunctionSelectors and facets. Removing all other functions protects the protocol in the event of an attack.
The BCM continues to be the owner of and the sole address capable of adding and updating functions on Beanstalk. Instances where Hypernative removes all non-diamond functions will be considered EBIPs, i.e., they will be documented as such and follow the DAO-approved procedures outlined above.
In the event that one or more Signers are compromised, vote against the outcome of any proposal, voluntarily choose to be removed from the BCM, or are otherwise removed in accordance with #signer-duties, the BCM will rotate them out of the multisig and replace them with another Signer. In no instance shall a majority of the BCM keys be held by Beanstalk Farms contributors, nor shall more than 1 key be held by Publius.
Off-chain governance introduces significant risks related to security and censorship. The BCM is designed to mitigate as many of those risks as possible by distributing the multisig keys across reputable community members and Beanstalk core contributors, and collectively adhering to #signer-best-practices.
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.
Under this structure, it’s important to acknowledge the risk of anonymous key holders conspiring to attack Beanstalk. Because only Publius knows the identities of the anonymous Signers, Publius would be the main attack vector. If a malicious actor were to compromise Publius before conspiring to attack Beanstalk, they could be reasonably sure that their identity would never be revealed.
In order to mitigate this attack vector, the BCM institutes the following process whenever the m-of-n configuration of the BCM is changed:
Publius will publish a hash of the list of Signers and their corresponding wallets on Etherscan (you can find these under the Signer Hashes section of the BCM Dashboard); and
Publius will share the list of Signers and their wallets with their personal legal counsel, to be released in the event that Publius is compromised such that they cannot publicly share the list themselves. This makes Publius and their personal legal counsel the only parties with access to the list.
In the event that Publius' counsel publicly shares the list of Signers and their wallets, anyone could verify that it's the correct list by hashing it and comparing it with the hash on Etherscan. This creates accountability for the anonymous Signers.
| Transaction | Snapshot? | Voting Period |
|---|---|---|
Executing BIP
Yes, requires a passed BIP
Up to 7 days as outlined in #bip-voting
Non-emergency change to the m-of-n BCM configuration
Yes, requires a passed BIP
Up to 7 days as outlined in #bip-voting
Executing BIR
Yes, requires a passed BIR
3 days
Executing EBIP (emergency hotfix, etc.)
No, but requires public notification via Discord
N/A
Rotating BCM Signers
No
N/A
Emergency change to the m-of-n BCM configuration to remove rogue Signers
No
N/A
Cancel transaction
No
N/A
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 BIC Process for more information.
Beanstalk Community Multisig Safe address: 0x390b023d316c2e92dd96A9bcC7fAe8dB12A2fBC1
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,536,350 Beans
Total to Immunefi: 138,335 Beans (excluding the annual Immunefi subscription fee beginning after BIP-41)
Remaining in Immunefi Vault: 2,447,000 Beans
Bugs found: 21
| Address |
|---|
| Response | Beans to Whitehat | Beans to Immunefi | Transaction |
|---|---|---|---|
7,500
750
11,000
1,100
181,850
18,185
10,000
1,000
100,000
-
10,000
1,000
1,100,000
110,000
1,000
100
1,000
100
1,000
100
50,000
5,000
10,000
1,000
10,000
-
1,000
-
10,000
-
10,000
-
10,000
-
3,000
-
3,000
-
5,000
-
1,000
-
