[BIP-892] Distribution of Rescued Funds from Balancer v2 November 3rd 2025 Attacks

Governance General Proposal
1

Author(s): @Xeonus, @0xDanko

PR with Payloads

Summary

Here, the DAO proposes a framework for distributing funds rescued during the Balancer v2 exploit in early November 2025.

Whitehat actors and internal rescue operations successfully recovered approximately $8M in user funds across multiple networks (with an additional ~$19.7M in osETH/osGNO handled separately by StakeWise). Users understand the inherent risks of DeFi and the community’s ongoing efforts to manage them through tools like the Terms of Use, Risk Reminders and adoption of the SEAL Safe Harbor Agreement (BIP-726). This proposal builds on that foundation by detailing the next steps in the risk management strategy including: (1) implementation of the previously approved whitehat reimbursement policy under [BIP-726] Safe Harbor Agreement; (2) the breakdown of the funds recovered by network and whitehat contributors, and (3) the methodology for reimbursing LPs affected by the theft.

Background

In early November 2025, Balancer v2 was actively attacked across multiple networks. In accordance with [BIP-726]: Adopt the SEAL Safe Harbor Agreement, whitehat actors intervened to rescue funds at risk and qualified for “Predetermined rewards for successful whitehats that protect protocol funds”.

The Safe Harbor Agreement, adopted by Balancer DAO, provides clear terms for whitehat interventions:

  • Bounty: 10% of recovered funds
  • Cap: $1,000,000 USD per rescue operation
  • Retainable: False (funds must be returned to DAO recovery address; bounty paid separately)
  • Identity: Full legal name required
  • Compliance: KYC and global sanctions verification required

1. Whitehat Reimbursement Policy

1.1 Bounty Payment Denomination

Proposal: All whitehat bounties shall be paid in the same token as returned funds, calculated as 10% of recovered tokens as approved in BIP-726 and described in the section 2.2.

Rationale:

  • The Safe Harbor Agreement specifies “Retainable: False,” meaning whitehats cannot retain bounties directly from recovered assets. This necessitates a separate bounty payment.
  • Payment-in-kind (PIK) as recovered assets provides:
    • Clarity and consistency across different token types
    • No price volatility between bounty calculation and payment
    • Simplified accounting for the DAO and recipients
    • Operational efficiency for multi-network settlements

1.2 Eligibility Requirements

Per BIP-726 and the Safe Harbor Agreement, whitehats must complete:

  1. Identity Verification: Provide full legal name
  2. KYC: Complete Know Your Customer verification
  3. Sanctions Screening: Clear OFAC, UK, and EU sanctions lists

The Foundation has cleared the compliance requirements for this proposal, and the identity of the whitehats will remain anonymous and preserved.

1.3 Mandate to Dispute Procedures

In the event of a dispute between Balancer DAO and the whitehat, the Treasury Council will be mandated to represent the DAO’s interests in such resolutions via the Balancer Foundation, according to the Safe Harbor Agreement.

2. External Whitehat Recoveries

The following table details all external whitehat recoveries, organized by whitehat and network.

2.1 Summary by Whitehat

Whitehat Network Total Recovered (USD at the time of recovery)
Anon #1 Polygon $2,681,321
Bitfinding Ethereum Mainnet $963,832
Anon #2 Base $161,274
Unknown #1 Arbitrum $46,933
Unknown #2 Arbitrum $1,862
Unknown #3 Arbitrum $230
TOTAL $3,855,452

Note: StakeWise rescued osETH (Ethereum) and osGNO (Gnosis) but will handle redistribution to affected users directly via their own mechanism. These funds are excluded from this proposal.

Note 2: Whitehat rescuers on Arbitrum have waived their bounty by not identifying themselves and/or refusing to KYC.

2.2 Detailed Recovery Breakdown and bounty targets

Anon #1 — Polygon

Token Amount Bounty Total (Net) Refund Tx
WPOL 8,007,431.9 800,743.19 7,206,688.71 0x52f19146…
MaticX 6,802,355.9 680,235.59 6,122,120.31 0x2c844233…
TruMATIC 2,865,691 286,569 2,579,122.26 0x3daae091…
stMatic 72,412.2 7,241.22 65,170.98 0xe3137b85…

Bounty shall be paid back to 0xCdef7f1e13b86CC1f9C0cF57bDC9A7db501CB680

BitFinding — Ethereum Mainnet

Token Amount Bounty Total (Net) Refund Tx
WETH 136.000 13.600 122.400 0x1c20be7a…
osETH 105.208 10.520 94.688 0x60687df4…
wstETH 10.956 1.095 9.859 0xf6e3db8f…
weETH 6.616 0.661 5.955 0x4936c50c…
rETH 6.225 0.622 5.603 0x18fccc83…

Bounty shall be paid back to 0xc3C7ccE1962B7a744847933CC3abD50b67ff5402

Anon #2 — Base

Token Amount Bounty Total (Net) Refund Tx
rETH 24.240 2.424 21.816 0xb88c2119…
WETH 16.969 1.696 15.273 0x33ea6ee0…
weETH 0.062 0.006 0.056 0x836a01a8…

Bounty shall be paid back to 0xcab1e5cc8bda570d29d5e321ec15cde5b9f6e555

Unknown — Arbitrum (waived bounty)

Token Amount Bounty Total (Net) Refund Tx
USDX 117.3 n/a 117.3 0x284055aa…
sUSDX 105.9 n/a 105.9 0xa025ecae…
ETH 13.7 n/a 13.7 0x6cf102dd…
rETH 0.2 n/a 0.2 0x6c5cdbbf…
WETH 0.2 n/a 0.2 0xce75a26a…
ETH 0.1 n/a 0.1 0xd84ed71a…
ezETH 0.1 n/a 0.1 0xab5cdc56…
weETH ~0.0 n/a ~0.0 0xf9b4d356…
wstETH ~0.0 n/a ~0.0 0x370efc5b…

3. Internal Rescue Operation (Certora — Metastable Pools)

In coordination with the Certora team, Balancer DAO executed an internal whitehat rescue operation targeting metastable pools [CSPv5] (including rETH and other correlated-asset pools) that were at risk but not yet exploited by external actors. This rescue effort is not covered under the SEAL Safe Harbor Agreement and its terms.

3.1 Treatment of Internal Rescue

Proposal: The internal Certora rescue operation is not eligible for the 10% Safe Harbor bounty for the following reasons:

  1. Certora’s involvement was under an existing service relationship with Balancer
  2. The Safe Harbor Agreement is designed to incentivize external actors to protect the protocol; internal coordinated responses fall outside this scope

3.2 Metastable Pool Recovery Details

The following tokens were rescued via the internal Certora-coordinated operation and returned to Balancer DAO multi-sig addresses:

Ethereum (0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f)

Token Amount
WETH 510.37
rETH 320.12
wstETH 141.39
StaFi rETH 0.80
Subtotal

Optimism (0x043f9687842771b3dF8852c1E9801DCAeED3f6bc)

Token Amount
rETH 64.88
WETH 66.06
wstETH 1.86
Subtotal

Arbitrum (0xaF23DC5983230E9eEAf93280e312e57539D098D0)

Token Amount
wstETH 3.53
WETH 4.04
Subtotal

Internal Rescue Total

Network Total Recovered (USD at the time of recovery)
Ethereum $3,590,712.58
Optimism $488,327.39
Arbitrum $28,525.58
TOTAL $4,107,565.55

These funds are held in the respective DAO multi-sig addresses as internal balances in the Balancer v2 vault on the corresponding network. These will be claimed and distributed to affected metastable pool LPs according to the methodology outlined in Section 4.

Internal balances can be verified here.

4. LP Reimbursement

4.1 Methodology

Proposal: Distribution of rescued funds to affected users shall be:

  1. Non-socialized — Each affected pool’s rescued funds are distributed only to LPs of that specific pool and network
  2. Pro-rata by BPT holdings — Distribution proportional to each holder’s share of the pool’s BPT at the snapshot block
  3. Payment-in-Kind — LPs receive the same tokens that were rescued (e.g., WETH, wstETH, WPOL, etc.)

4.2 Snapshot Blocks

4.2.1 External White Hat Rescues

Distribution eligibility for external white hat rescued funds shall be determined by BPT holdings at the following blocks (last block before first exploit tx on each network):

Network Snapshot Block
Ethereum Mainnet 23717626
Base 37683373
Polygon 78525618
Arbitrum 396293450

4.2.2 Internal Rescue (Metastable Pools)

Distribution eligibility for internally rescued metastable pool funds shall be determined by BPT holdings at the following blocks, per pool:

Ethereum Mainnet

Pool ID Snapshot Block
0x1e19cf2d73a72ef1332c882f20534b6519be0276000200000000000000000112 23785042
0x32296969ef14eb0c6d29669c550d4a0449130230000200000000000000000080 23785044
0x851523a36690bf267bbfec389c823072d82921a90002000000000000000001ed 23785052
0xb08885e6026bab4333a80024ec25a1a3e1ff2b8a000200000000000000000445 23785057

Optimism

Pool ID Snapshot Block
0x4fd63966879300cafafbb35d157dc5229278ed2300020000000000000000002b 143687339
0x7b50775383d3d6f0215a8f290f2c9e2eebbeceb200020000000000000000008b 143687377

Arbitrum

Pool ID Snapshot Block
0x36bf227d6bac96e2ab1ebb5492ecec69c691943f000200000000000000000316 399567435

4.3 Net Distribution

The amount available for LP distribution is:

Net Distribution = Rescued Funds − Whitehat Bounties

For each pool, the net tokens (after deducting the 10% bounty in-kind) will be distributed to BPT holders.
Note, that this will not apply to rescued funds from the internal white-hat operation as described in 4.2.2, meaning the full amount of recovered funds shall be returned to affected LPs from those pools.

4.4 Claim Mechanism

A claiming mechanism will be developed to facilitate the distribution of rescued funds to eligible LPs. The technical implementation details—including the specific smart contract architecture, claim interface, and operational procedures—will be finalized and communicated to the community prior to launch.

Key Principles:

  • Acceptance Required: Claimants will be required to provide digital proof of consent to Balancer’s terms and conditions, explicitly agreeing to release Balancer Labs, Balancer DAO, Balancer Foundation and any affiliated parties and service providers from liabilities related to the exploit or any disputes.
  • Smart Contract & Multi-Sig Handling: Smart contract accounts and multi-sig wallets may require case-by-case coordination. Affected parties can contact admin@balancer.finance for guidance.
  • Claim Period: A reasonable claim window will be established. At the conclusion of this period, unclaimed assets will be declared dormant and their disposition may be reassessed by the community via a separate governance proposal.

5. Specification

If this proposal passes, the following actions will be executed:

  1. Execute White Hat Bounty Payments: Distribute bounties to KYC-verified white hats as specified in Section 2.2, paid in-kind (10% of recovered tokens) to their designated addresses.
  2. Publish Claim Data for Community Review: Release complete snapshot data including:
    • Per-pool BPT holder lists at specified snapshot blocks
    • Token allocation amounts per eligible address
    • Data verification scripts for community audit
  3. Deploy Claiming Mechanism: The Balancer Foundation and Service Providers are mandated to develop and deploy the claim framework for affected LPs
  4. Execute LP Distributions: Open the claim window for eligible LPs to retrieve their rescued funds according to the methodology in Section 4.
  5. Monitor and Support Claims: Provide ongoing assistance to claimants, particularly for smart contract accounts and multi-sig wallets requiring case-by-case coordination (contact: admin@balancer.finance).
  6. Dormant Asset Management: At the conclusion of the 180-day claim window, propose new allocation for unclaimed dormant assets via separate governance proposal.

References

Edits:

  • assign BIP ID and reformat as BIP
  • add payload file for white hat repayments
  • add white hat bounty payment information
  • adjust section 4.3 to clarify external vs internal white hat token distributions
  • adjust wording on proposal execution flow in section 5
6 Likes
2

What is with bpt-sss ??? On Beets???

1 Like
3

Personally I do not see any benefit to holding the recovered assets hostage until users “claim” them back. Once it is known how much of it belongs to whom, the assets can simply be airdropped directly back to their original owners.

First, acceptance of terms and conditions is already covered by the dapp, which already contains releases, in addition to the releases included in the adopted Safe Harbor Agreement. Why go through all that bureaucracy a third time? Is there really a scenario in which all these aforementioned acceptances of releases is not enough, but a third one is?

Secondly, calling assets “dormant” because someone did not “claim” back their own assets within an arbitrary timeframe goes against the ethos of our ecosystem in my opinion. In no circumstance should it be up to the DAO to take ownership of any users’ assets, also not when they happened to be offline for 180 days.

Not to mention the overhead (and delay!) of building a smart contract system and GUI to facilitate all this. An active airdrop is by far the simplest and most effective way of distributing these assets, and prevents users from missing out on the fact that their assets were recovered.

What is there to say against an immediate airdrop?

Screenshot 2025-11-28 at 08.05.04
Screenshot 2025-11-28 at 08.05.04488×215 16.5 KB

[…] you expressly waive and release Balancer from any and all liability, claims, causes of action, responsibility or damages arising from or in any way related to your use of the Site, the Application or the Smart Contracts.

ref: https://balancer.fi/terms-of-use

The Protocol Community collectively and each Protocol Community Member individually, hereby, to the extent permitted at law, irrevocably, unconditionally, and completely exculpates, releases, acquits and forever discharges the Protocol Community and each Protocol Community Member from, and hereby irrevocably, unconditionally, and completely waives and relinquishes, every Claim, that any Protocol Community or Protocol Community Member may have had in the past, may now have, or may have in the future against the Protocol Community or any Protocol Community Member, relating to or arising out of this Agreement or any Eligible Funds Rescue attempted or effected in connection herewith or any of the other matters contemplated hereby.

ref: safe-harbor/documents/agreement.pdf at main · security-alliance/safe-harbor · GitHub

4 Likes
4

Disclosure: this is not part of the proposal, just personal opinion, but we want to signal this to the community for consideration.

Afaik, claiming mechanics are pretty standard and shouldn’t cause too much of a burden to Balancer’s technical teams.

When drafting this RFC, my thought was there’s a good chance that a big chunk of these funds will never be claimed. Being the affected pool are so old, it could very well be that there’s a lot of dead liquidity in here, especially in the meta stable pools recovered.

Once this claim window is over (180 days) and we have clear numbers, the community could propose to governance that the dormant funds are socialized between all the affected wallets, hence making a higher number of victims whole (i.e. holding Treasury assets as collateral). Considering a basic Pareto rule, a more significant number of wallets will carry a lesser portion of the total affected funds. It’s a valid approach to be considered and could potentially reach hundreds (or thousands) of people.

However this is not under scope of this proposal, and I believe this discussion is premature, that’s why I’m against simply airdropping funds and shutting down the debate forever.

As burdensome as the technicalities might be, and the resources needed to be spent to put this together, I think they might be well worth it given the number of users impacted.

1 Like
5

KYC for whitehats?
What is the message you are saying for the future, if necessary help from whitehats again?

1 Like
6

These funds were *stolen*, This should not be taken as an opportunity to see which wallets are active and which aren’t. That I need to deliver proof hella over complicates something that could be easily solved by distributing the funds back into the pool as they are meant to be with every single pool. If I was more involved into this community and was able to vote I would definitely vote against this. Which reminds me that I was banned from the Balancer discord for warning people over a scam and sharing the scammers account information so even if I wanted to be more involved I can’t.

They kicked me out like I was nothing and seemingly to protect scammers which instantly flocked to me when I joined the server there by tricking me.

This will guaranteed result in living wallets not get the money back that is rightfully theirs.

Any time any info is shared to the public there are bound to be a lot of people that either will not come across the message or won’t understand how to claim their assets back in this case.

Give me back my money and I’m out of here.

1 Like
7

The message to me sounds like ‘don’t bother unless you’re willing to give up countless personal details that will put you at risk.’. A person that stole money back from criminals is at extra risk if the personal info leaks. And i wouldn’t trust them either, especially after being banned from their discord over warning people of a scam.

Even if they were trustworthy there is an inherent risk to sharing personal information.

1 Like
8

There’s a clear misunderstanding here that claiming the assets and singing the acceptance would require KYC and personal information, which is certainly not the case.

2 Likes
9

That’s true, I meant for the white hat hackers requiring KYC to get the bounty they deserve.

2 Likes
10

Update: all identified whitehats have cleared compliance checks via Balancer Foundation. We will edit the proposal accordingly.

2 Likes
11

One point I want to flag for consideration regarding the snapshot and claim design:

At the time of the exploit, a significant portion of affected BPT was held by intermediary smart contracts (e.g. Aura gauges / vaults), rather than end-user EOAs. From a user perspective, many LPs are economically exposed via these wrappers, even though the BPT itself sits at a vault address.

It would be great to have clarity (or explicit guarantees) that:

  1. the snapshot accurately captures these vault-held BPT positions, and

  2. the claim mechanism does not require vault contracts to manually claim on behalf of users, unless absolutely necessary.

Ideally, the recovery flow should allow fair attribution to underlying LPs without forcing coordination or trust assumptions at the wrapper-protocol level.

Speaking as an LP who was affected while having BPT staked via Aura, my personal preference would be a flow where I can first withdraw my BPT from Aura and then independently claim based on my BPT balance, rather than having to rely on a third-party vault or wrapper protocol to coordinate claims on my behalf.

Appreciate the work that’s gone into the proposal so far — just wanted to raise this for consideration early to help avoid potential UX or distribution issues later in the process.

3 Likes
12

Following the same methodology as for the assets recovered by StakeWise, we have generated a list of all users for which assets were recovered by the whitehats.

The complete CSV can be found here: balancer-upscale-exploit-shares/output/shares_whitehats_filtered.csv at main · maxyz-xyz/balancer-upscale-exploit-shares · GitHub.

Users for which assets have been recovered that are worth less that 1 $USD are currently filtered out. The token column is the token that has been recovered, user_amount_recovered is how many of those tokens will be returned to the user. Note that user_amount_recovered_usd is based on the USD price of the asset on the day of the hack.

We considered the following positions and aggregated them accordingly:

  • regular balance of the Balancer Pool Token (BPT)
  • stakes in the corresponding Balancer gauge
  • stakes in the corresponding Aura gauge
  • deposits in the corresponding Beefy vault

Extensive double checks were performed on the total supply of the BPT onchain at the time of the hack and the sum of user snapshots. For a more detailed description of the calculations, please see the repo’s readme and/or source code: GitHub - maxyz-xyz/balancer-upscale-exploit-shares

We encourage all users to verify their data on the CSV if they were a liquidity provider (directly or indirectly) for the following pools (ref):

Pool ID Symbol Chain
0x05ff47afada98a98982113758878f9a8b9fdda0a000000000000000000000645 weETH/rETH Ethereum
0x58aadfb1afac0ad7fca1148f3cde6aedf5236b6d00000000000000000000067f rsETH/WETH Ethereum
0x93d199263632a4ef4bb438f1feb99e57b4b5f0bd0000000000000000000005c2 wstETH-WETH-BPT Ethereum
0xdacf5fa19b1f720111609043ac67a9818262850c000000000000000000000635 osETH/wETH-BPT Ethereum
0x8159462d255c1d24915cb51ec361f700174cd99400000000000000000000075d B-stMATIC-Stable Polygon POS
0x951d84e358dd8ad6b3ae6220981bcfc4baf95c84000000000000000000000d62 TruMATIC-WMATIC Polygon POS
0xcd78a20c597e367a4e478a2411ceb790604d7c8f000000000000000000000c22 maticX-WMATIC-BPT Polygon POS
0xab99a3e856deb448ed99713dfce62f937e2d4d74000000000000000000000118 weETH/wETH Base
0xc771c1a5905420daec317b154eb13e4198ba97d0000000000000000000000023 rETH-WETH-BPT Base
5 Likes
14

We now also added the recovered assets on Arbitrum One: feat: add arb1 whitehat recovered assets (#2) · maxyz-xyz/balancer-upscale-exploit-shares@0d2d1c0 · GitHub

Pool ID Symbol Chain
0x3fd4954a851ead144c2ff72b1f5a38ea5976bd54000000000000000000000480 ankrETH/wstETH-BPT Arbitrum
0x4a2f6ae7f3e5d715689530873ec35593dc28951b000000000000000000000481 wstETH/rETH/cbETH Arbitrum
0x7b54c44fbe6db6d97fd22b8756f89c0af16202cc00000000000000000000053c ETHx/wstETH Arbitrum
0x90e6cb5249f5e1572afbf8a96d8a1ca6acffd73900000000000000000000055c rsETH/wETH Arbitrum
0xb3047330c1cb5eb1a3670fabfb99bdc106d631eb0000000000000000000005e4 sUSDX/USDX Arbitrum
0xb61371ab661b1acec81c699854d2f911070c059e000000000000000000000516 ezETH/wstETH Arbitrum
0xc2598280bfea1fe18dfcabd21c7165c40c6859d30000000000000000000004f3 wstETH/sfrxETH Arbitrum
0xd0ec47c54ca5e20aaae4616c25c825c7f48d40690000000000000000000004ef rETH/wETH BPT Arbitrum
0xf13758d6edd1937dcb3f4fe75889b579d400299a000000000000000000000595 weETH/wETH Arbitrum
1 Like
15

https://snapshot.box/#/s:balancer.eth/proposal/0x79d4abf2838eead8f153f409ee200ebafa83a1499a7b5c586497d68562209657