BIP-32: Seraph

Proposer

Halborn, Inc. and the Beanstalk Seraph Committee

Halborn is a team of 100+ award-winning ethical blockchain hackers who focus on securing their clients’ full stack end-to-end. Trusted by Solana, Near, BAYC, Ava Labs and many more. Halborn has completed various security audits of Beanstalk and continues to audit BIPs as they are developed.

Seraph is a non-custodial blockchain security notary (BSN). A BSN is a cybersecurity professional who serves an organization (centralized or decentralized) as a third party witness to the signing of important on-chain actions. A BSN’s main purpose is to deter fraud and prevent attacks.

Proposer Wallet: 0xf1a621fe077e4e9ac2c0cefd9b69551db9c3f657

Summary

• Hire Halborn, Inc. for their blockchain security notary product called Seraph to deter new attacks on the protocol;
• Pay 10,000 USDC per month for Seraph for 6 months;
• Form the Beanstalk Seraph Committee (BSC), the group that has discretion over Runbooks for Seraph-protected functions and removing Seraph in cases where it must be removed for the security or censorship resistance of Beanstalk; and
• Make various updates to Beanstalk governance detailed below, including updating the Beanstalk Community Multisig (BCM) Process, the Beanstalk Immunefi Committee (BIC) Process, the Immunefi Bug Bounty Program and the Beanstalk DAO Disclosures.

Note: On multiple occasions the Arweave upload of BIP-32 is referenced due to the Snapshot character limit—see the full BIP-32 proposal on Arweave.

Links

• BIP-32 GitHub PR
• Safe Transaction
• GitHub Commit Hash: bac39bb8c51e8076c6fe9690ac2fd09c5bdbeeea

Problem

Security is paramount to Beanstalk's success. Beanstalk is a complex DeFi protocol that can be vulnerable to different attacks that are not always caused by code flaws or detected during audits. The loss associated with DeFi protocol exploits gets bigger day by day. The Beanstalk DAO should seek to avoid another hack as best as possible.

Under the current Beanstalk governance structure, only a single multisig (the BCM) needs to be compromised in order to corrupt Beanstalk. Implementing Seraph with no other upgrades to Beanstalk governance would make Beanstalk less resistant to censorship.

Beanstalk governance, the BCM Process, the BIC Process, the Immunefi Bug Bounty Program and the Beanstalk DAO Disclosures can all be updated to reflect the current state of Beanstalk and its ecosystem, and in particular the implementation of Seraph.

Proposed Solution

Seraph

A governance structure with a separate multisig that can remove Seraph can mitigate this concern and (combined with Seraph) increase the security and censorship-resistance of Beanstalk. We propose implementing Seraph into Beanstalk as an extra line of defense against hacks or other destructive actions to Beanstalk, and incorporate other complementary changes to Beanstalk governance.

We propose paying 10,000 USDC per month for Seraph for 6 months from the Beanstalk Farms budget.

Protected Functions

The Seraph platform can protect up to 25 of the highest risk smart contract functions embedded in Beanstalk. The Seraph code modifier protects 7 of the highest risk owner functions in Beanstalk:

• diamondCut
• whitelistToken
• dewhitelistToken
• unpause
• transferOwnership
• createFundraiser
• addUnripeToken

Seraph provides 24/7/365 services to review, analyze, and permit or reject any calls to these functions according to the appropriate Runbook(s).

Runbooks

Seraph notaries are required to process any function calls according to the specific notary Runbooks of rules and procedures.

Each of the 7 Seraph-protected functions has a unique Runbook which establishes the rules and procedures for Seraph notaries to process transactions that call the functions and the priority and risk of each function. The Runbooks for each protected function shall remain confidential between Halborn and the BSC.

The details about transactions that call protected functions and whether they have been reviewed, approved or rejected by the Seraph notary are publicly viewable via the Seraph Dashboard.

Beanstalk Seraph Committee

We propose forming the BSC—an anonymous group of six reputable community members and Beanstalk core contributors. The BSC members were selected by Publius.

The Beanstalk Seraph Committee Multisig (BSCM) is the only wallet that can remove Seraph from Beanstalk. The BSC members are the only signers on the BSCM. The BSCM is a 4-of-6 multisig deployed using Safe.

The BSCM cannot call any of the owner functions of Beanstalk—only the BCM can. Publius attests that there is a minority of overlap between the signers on the BSCM and BCM.

Responsibilities

Seraph notaries have created the Runbooks in collaboration with the BSC to implement and activate the Seraph protections as effectively and safely as possible. The BSC has approved initial Runbooks for all protected functions.

The BSC can work with Halborn to update Runbooks at any time, but must sign a transaction verifying the new Runbooks for the change to be valid.

Seraph may be deactivated at any time via BIP. However, in instances where Halborn is unwilling to commit a passed BIP that removes Seraph, or where Seraph must be removed for the security or censorship resistance of Beanstalk, the BSC is responsible for doing so.

On the Seraph contract, the BSCM can call the removeSeraph function that initiates a 24 hour timelock. After the timelock elapses, the BSCM can call the executeRemoval function that removes Seraph from Beanstalk.

Best Practices

• BIP-32, Best Practices

Anonymous Multisig Signers

Off-chain governance introduces significant risks related to security and censorship. The BSCM 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 BSCM best practices.

The most significant risk associated with off-chain governance is the potential corruption of the BSCM (and BCM). In order to minimize the chances of this, the Signers are anonymous. The anonymous Signers have been selected by Publius. Signers are anonymous to each other as well, apart from Publius.

Malicious Key Holder Risk

Under this structure, it’s important to acknowledge the risk of anonymous key holders conspiring to attack Beanstalk.

In order to mitigate this attack vector, the BSCM will institute the same process as the BCM with regard to publishing a hashed list of Signers—see BIP-32, Malicious Key Holder Risk.

The BSC Process can be read here.

Process Amendments

Beanstalk Governance

We propose the following list of changes to Beanstalk governance:

• 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;
• A Stalkholder’s vote for a given BIP is counted as their Stalk plus Grown Stalk at the beginning of the Voting Period that still exists (Voting Stalk);
• If at the end of the Voting Period:
  • Less than or equal to half of total Voting Stalk votes For the BIP, it fails, or
  • More than half of total Voting Stalk votes For the BIP, 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 Voting Stalk votes For the BIP, the BCM can execute the BIP on-chain;
• Voting Stalk is also used to count votes in all other Beanstalk governance proposals where Stalkholders vote (i.e., BOPs, BFCPs and BSPs);
• The proposer must have 0.1% of total Voting Stalk at the end of a Voting Period where Stalkholders vote (i.e., BOPs, BFCPs and BSPs);
• Only BIPs can (1) change the Beanstalk protocol, (2) mint Beans and/or (3) change Beanstalk governance;
• BOPs are proposals for the DAO to agree on processes that do not involve changes that can only be made in BIPs.
• Voting choices for a BIP are For, Abstain and Against (where Abstain and Against have no effect);
• Voting choices for a BOP are For and Against;
• BOPs and BFCP-Bs must have >35% of total Voting Stalk vote For and a majority of participating Voting Stalk vote For at the end of the Voting Period in order to pass; and
• BFCP-As must have >25% of total Voting Stalk vote For and a majority of participating Voting Stalk vote For at the end of the Voting Period in order to pass.

The updated Beanstalk governance process can be read in the new Proposals documentation here.

BCM Process

We propose the following list of changes to the BCM Process:

• Integrate all of the changes included in the above Beanstalk Governance section;
• Add the addUnripeToken and addFertilizerOwner functions to the list of owner functions for completion;
• Require a BIP for non-emergency changes to the m-of-n configuration of the BCM, but allow emergency changes to the m-of-n configuration without a BIP in order to remove rogue Signers before a replacement Signer can be selected;
• Create significantly more clear and permissionless BIP and BOP proposal processes;
• Require that written proposals for BIPs have a Proposer section that at minimum includes a verified message signature uploaded to Arweave;
• Document the process for uploading verified message signatures to Arweave for both BIP proposers and BCM Signers;
• Require that written proposals for BIPs that call diamondCut have a Contract Changes section that at minimum lists the facets and Init contract addresses that diamondCut calls; and
• Require that written proposals for BIPs that call diamondCut have a Beans Minted section that described the number of Beans minted by the execution of the diamondCut;
• Make it clear that BIPs may have multiple transactions if made explicit in the written proposal;
• Add relevant BCM processes for verifying and executing Beanstalk Immunefi Responses (BIRs);
• Remove the requirement for Signers to rotate wallets every 2 months;
• More thoroughly document the processes for BCM Signers to verify and sign transactions;
• Specify that in cases where functions must be removed immediately to protect Beanstalk, BCM Signers are not required to submit a verified message signature on Arweave; and
• Specify that in no instance shall the majority of the BCM keys be held by Beanstalk Farms contributors.

The updated BCM Process can be read here. The guides for uploading verified message signatures to Arweave can be read here.

BIC Process

• BIP-32, BIC Process

The updated BIC Process can be read here.

Immunefi Bug Bounty Program

• BIP-32, Immunefi Bug Bounty Program

The updated Immunefi Bug Bounty Program can be read here.

Disclosures

• BIP-32, Disclosures

The updated Beanstalk DAO Disclosures can be read here.

Rationale

Seraph

Technical analysis of attacks on DeFi protocols over the last 12 months indicate that both the volume and loss-value of attacks on protocols are increasing substantially.

With Seraph, Beanstalk can deter additional attacks on the protocol and disincentivize attackers by making it more difficult and costly to conduct an attack. The fee for Seraph is substantially lower than the projected operational and reputational costs associated with an additional attack. By activating Seraph, Beanstalk assets and contracts are protected such that complex attacks may be prevented before they can be executed on-chain.

As Beanstalk returns to on-chain governance, the Beanstalk DAO and BSC can continue to work with Seraph as an extra layer of defense.

Beanstalk Seraph Committee

Implementing Seraph with no other upgrades to Beanstalk governance would make Beanstalk less resistant to censorship. By implementing Seraph and alongside the formation of the BSC, both the BCM and the BSCM must be compromised in order to corrupt Beanstalk, without compromising censorship resistance before on-chain governance is able to be reimplemented.

Runbooks for each protected function remain confidential between Halborn and the BSC in order to mitigate potential manipulation of Beanstalk by malicious actors.

BSCM Signers are anonymous to minimize the potential corruption of the BSCM from an outside party.

Process Amendments

The other proposed changes to Beanstalk governance (such as the introduction of Voting Stalk, the requirement to meet the proposer Stalk threshold at the end of the Voting Period, etc.) all complement or supplement the introduction of Seraph.

See BIP-32, Process Amendments to read the rationale for the remaining proposed process amendments.

Contract Changes

• BIP-32, Contract Changes

Beans Minted

None.

Effective

Effective immediately upon commit.