[BIP:83] Development Insurance Fund

TL;DR - allocates a pot of treasury funds as “insurance” to be paid out against incidental losses arising from the development of new products.

Background

Building new products in DeFi is hard. Even the simplest of smart contract designs can give rise to lots of unexpected and incidental consequences when opened up to the full, live production environment of onchain finance. Though Beefy has been careful and effective at avoiding risks and losses arising out of our new product designs, expanding into truly novel and innovative areas inevitably opens up the risk of unexpected consequences.

Since coming out of beta at the start of June 2024, our CLM products have been rolled out to 12 different chains, and now reflects over 40% of our fleet of live products. That rollout has succeeded generally without issue, and demonstrated the robustness of the product and its code, after completing 4 successive rounds of auditing (with a fifth now ongoing).

However, when introduced into live environments, a specific issue has come to light and resulted in a relatively small amount of loss of user funds in a narrow group of products. In view of this discovery, this proposal suggests that a reasonable pot of treasury funds should be allocated for distribution to any products that are affected by unexpected issues such as this whilst our new products are still finding their feet.

Issue

A small number of products on BNB Chain witnessed unusual activity around their harvest function caused by bots. As BNB Chain offers a public mempool for transactions, bots are able to scan pending transactions looking for profitable opportunities to rearrange transactions in the block (known as “sandwich attacks”).

For the affected CLM products, a bot was able to first imbalance the underlying pool by depositing a large amount of liquidity from a flashloan. The harvest function was then called which moved most of the liquidity from the main position to the alt position, thereby concentrating the CLM product in only one of the pool assets. A separate bot then rebalanced the pool, causing the CLM product to trade the single-sided liquidity back at a worse price, realizing loss in the position. Interestingly, as the actions were performed separately across two separate wallets, it is not clear whether the rebalances were intentional or merely an unlucky coincidence. Effectively, the CLM product worked as intended, but bad rebalances gave rise to unacceptable economic loss.

The solution to this vector is relatively simple - adding a calmness check around the harvest function to ensure that the pool hasn’t been recently imbalanced, meaning harvest can’t be called in the same transaction where a flashloan has suddenly imbalanced the pool. The Beefy core team has immediately deployed a fix to all live CLM products, and is working with our existing auditors to ensure that the best possible solution is implemented permanently.

Insurance Fund

The emergence of this new issue has resulted in a relatively small amount of loss to user funds. Given the pace of development and innovation in this space, our products will be faced with different challenges as they are rolled out to new environments and product types. Though all reasonable endeavors are being made to avoid and mitigate any knowable risks, the core team proposes that some treasury funds should be set aside for compensating users where unknowable risks do arise in live production.

Specifically, this proposal suggests that an initial fixed budget of $350,000 should be set aside in stablecoins (including deposits into yield protocols like Aave or Compound) for use in compensating users where genuine issues arising in the design or implementation of Beefy’s products do cause or threaten loss of user funds. This budget may be replenished if depleted by way of further governance proposal only, but shall otherwise be run perpetually until depleted.

Foremost, discretion over payment of these funds will rest with the core team, to determine that any claim arises from a genuine issue arising from a product’s design or implementation, as opposed to commonly-known risks taken by the user (e.g. price action in the underlying assets, or impermanent loss arising from ordinary operation of a product). Likewise, the fund would not be intended to cover issues relating to an underlying product or token, such as a depeg event or an upgrade that deprecates the existing product. Where any claimants do not accept the decision of the core team with respect to use of these funds, a separate proposal can be raised through the Beefy DAO’s formal governance procedures.

With risks of this nature, it is of the utmost importance that the developers and auditors working on addressing risks are not undercut by the need to cover losses promptly. Where details of a risk are made known before a full solution is reached and deployed, that publication may invite others to seek to exploit the same risk. As such, claims from the Insurance Fund will always be made either privately or retrospectively, and full details will be published at regular intervals (e.g. quarterly) only after an issue is believed to be fixed. Nonetheless, the team intends to account for everything paid out of the insurance fund, to make clear to the DAO how it is being used.

Proposal

Beefy should create a Development Insurance Fund, funded with an initial fixed budget of $350,000, approved for distribution to cover user claims relating to genuine issues arising from the design or implementation of Beefy’s products.

Discretion over distributions shall rest initially with the core contributor team, though always with a right to raise concerns or additional claims through the formal governance process.