[BIP-904] Balancer V3 Hypernative Pause Module Enablement

Summary

Hypernative proposes for Balancer to enable a Gnosis Safe Module which we have deployed on each of Balancer V3’s networks in order to pause groups of pools based on our exploit detection logic. The logic consists of various machine learning models which are known to have detected potential exploits and prevented them in real time across the web3 space for roughly 4 years now. Furthermore the extended automated response will be able to pause groups of pools based on compromised rate providers, general exploits of pool types by leveraging their respective factories, and similarly pools with hooks in common. Reference https://forum.balancer.fi/t/bip-775-fund-hypernative-security-services-renewal/6329 & https://forum.balancer.fi/t/bip-794-enable-composable-stable-pool-pause-functionality-to-hypernative/6306 for prior engagement details and configurations.

Motivation

After the recent exploit event of Balancer V2 and our ability to make a large impact by pausing ComposableStablePool version 6, as permitted in our previous post; we think the value added to Balancer V3 is clear. We intend to be the last line of defense for any exploit vectors which the protocol can face going forward, and given the ability to pause individual pools, and the vault on each network in worst case scenarios Hypernative will have a much more comprehensive coverage window over V3 as a whole.

Specification

The Balancer Emergency subDAO Safe on each network will install a safe Module to enable Hypernative to pause pools and vaults across respective networks. A Module is a smart contract that executes a predefined set of instructions on behalf of the Safe address, pre-approved by the Safe signers, and capable of executing these instructions automatically. In this case, the instruction is to call the pause method for each Balancer V3 pool or the V3 vault on each respective network. The module is attached via the Safe’s enableModule function.

The Safe Module is triggered by hacks or exploits detected in Balancer’s contracts by the Hypernative system as well as large deviations in rate providers outside of thresholds defined by Balancer Labs. Hypernative scans blockchains in real-time and detects hacks & exploits using its machine learning model, from the moment of a deployed malicious smart contract targeting Balancer’s contracts to executing malicious transactions.

The list of pools is automatically updated whenever the PoolCreated event is emitted on-chain, though the Balancer team can override this list if necessary.

Enabling the Safe Module will take place on these networks, with future networks to follow:

Ethereum, Base, Optimism, Gnosis, Arbitrum, Avalanche, Plasma, HyperEVM

Corresponding modules will be configured on the above chains. Later deployments will occur for X-Layer, Sonic, and any additional chains Balancer V3 deploys upon proper communication between the responsible Balancer DAO entity. Hyperactive must be given the corresponding vault and Emergency safe addresses prior to deploying the pause module on each network.

Sample Balancer Emergency subDAO Multisig payload:

0xA29F61256e948F3FB707b4b3B138C5cCb9EF9888 will interact with itself 0xA29F61256e948F3FB707b4b3B138C5cCb9EF9888 and call the enableModule function passing the module address 0x7d171c6ef79a22340c6f931e8bd3833db8a8c620 on each network.

The Hypernative Safe Module is canonical and hence has the same address on all chains. This payload will be executed on all chains using the respective emergency multisigs.

Chain	Emergency Safe Address	Module Address
Ethereum	0xA29F61256e948F3FB707b4b3B138C5cCb9EF9888	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
Plasma	0x0d3319A8057A0C8afd87dFEEA252541A76d56Ebf	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
Arbitrum	0xf404C5a0c02397f0908A3524fc5eb84e68Bbe60D	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
Gnosis	0xd6110A7756080a4e3BCF4e7EBBCA8E8aDFBC9962	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
Base	0x183C55A0dc7A7Da0f3581997e764D85Fd9E9f63a	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
Avalanche	0x308f8d3536261C32c97D2f85ddc357f5cCdF33F0	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
HyperEVM	0x44613a28347206F5E26C1B8Db7Dc73f450219746	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620
Optimism	0xd4c87b33afcE39F1E3F4aF1ce8fFFF7241d9128B	0x7d171c6ef79a22340c6f931e8bd3833db8a8c620

Risk Assessment and Testing

Module Audit Report by Certora

Audit Summary: 4 Informational Findings Only

Before coming forward with this proposal, a rigorous test plan has been developed which will take place on the Optimism network in production.

Key Components of the Test:

Test Environment: The tests will take place on Optimism and occur in two pillars; in no specific order.

Emergency Pausing Mechanism: An integration via extended onchain response to pause all vaults and pools will be integrated into the Hypernative system. For the demonstration, the module contracts can be seen in the tables above which will have and the functionality to pause pools and vaults via Balancer’s multisig(s), enabling centralized oversight and triggering during emergencies.

Pillar 1 - Pool factory monitoring

Watchlist Creation: Together Balancer & Hypernative created a watchlist to monitor for hacks and exploits targeting Balancer’s core contracts, associated vaults, and individual pool types. This watchlist is dynamic, automatically updating with each new contract is created.

Pool Monitoring: Hypernative’s system automatically adds new vaults to the watchlist by monitoring transactions where new pools are added. For the scope of the test Hypernative will trigger a test to pause all ReCLAMM pools on Optimism, given there is no production use of the pool type on the chain at this time; limiting any potential down side or delays in revenue generating trades. https://balancer.fi/pools?networks=OPTIMISM&poolTypes=RECLAMM

Pillar 2 - Rate Provider Deviation monitoring

Custom Agents will be utilized to monitor rate provider contracts for large % deviations and trigger pauses of all corresponding pools exposed to that rate provider in the case of rate manipulation. This will also be tested on Optimism with a pool set which will be shared after execution in the post comments section.

Outcome:

Summary of the testing and transaction links will be shared upon test execution in production after the permissions are granted to the modules below.

Onchain Payloads:

On Base: DAO emergency multisig 0x183C55A0dc7A7Da0f3581997e764D85Fd9E9f63a on Base will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On Ethereum: DAO emergency multisig 0xA29F61256e948F3FB707b4b3B138C5cCb9EF9888 on Ethereum will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On Avalanche: DAO emergency multisig 0x308f8d3536261C32c97D2f85ddc357f5cCdF33F0 on Polygon will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On Arbitrum: DAO emergency multisig 0xf404C5a0c02397f0908A3524fc5eb84e68Bbe60D on Arbitrum will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On Optimism: DAO emergency multisig 0xd4c87b33afcE39F1E3F4aF1ce8fFFF7241d9128B on Optimism will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On HyperEVM: DAO emergency multisig 0x44613a28347206F5E26C1B8Db7Dc73f450219746 on zkEVM will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On Plasma: DAO emergency multisig 0x0d3319A8057A0C8afd87dFEEA252541A76d56Ebf on Avalanche will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself

On Gnosis: DAO emergency multisig 0xd6110A7756080a4e3BCF4e7EBBCA8E8aDFBC9962 on Gnosis will call enableModule(0x7d171c6ef79a22340c6f931e8bd3833db8a8c620) on itself