# Balancer hack: claim process Source: https://forum.gnosis.io/t/balancer-hack-claim-process/12149?u=mdr Kiwi News: https://news.kiwistand.com/stories/Balancer-hack-claim-process?index=0x69a166b5dcfebb97c0453c96a2b2c5ba38fe637cc965cfb1950c223ca93b165cdacded7d Submitted by misha on 2026-02-27 UTC, 1 upvote, 1 comment ## Summary Gnosis Chain has secured roughly $9.4 million drained from it in the November 3, 2025 Balancer V2 exploit, which took about $120–128 million across multiple chains. The response was an emergency soft fork that froze the stolen funds, followed by a hard fork on December 22, 2025 that transferred control of them to a DAO-controlled Safe multisig. Affected users can claim recovered tokens through a Merkl-powered claim page after a review period for a published CSV of addresses and amounts. The claim page includes an optional donation slider, defaulting to 5%, for teams that worked on the recovery. ## Article Balancer hack: claim process Recovering $9.4M From the Balancer Exploit: How Gnosis Chain Hard-Forked and How to Claim Your Funds On November 3, 2025, a sophisticated attacker exploited a vulnerability in Balancer V2’s Composable Stable Pools, draining approximately $120–128 million across multiple chains — including roughly $9.4 million on Gnosis Chain. In the weeks that followed, we coordinated an unprecedented two-phase response: first an emergency soft fork to freeze the stolen funds in place, then a hard fork on December 22, 2025 to transfer control of those funds to a DAO-controlled Safe multisig. All of the exploiter‑controlled funds on Gnosis Chain that could be recovered via the hard fork have been successfully secured. This post serves two purposes: to provide a full account of what happened and how we responded, and to kick off the recovery claim process so affected users can reclaim recovered tokens. Claiming Your Funds We are now beginning the process of making the recovered funds available for claim to affected users, in line with the Recovery Claim Terms. Before the claim page goes live, we are publishing the full list of affected addresses and claimable amounts so that the community can review them and flag any discrepancies. How It Works Review period (now): The CSV lists every affected address and the tokens they can recover. Please review the data and report any issues or questions in the comments of this post. Claim page: Once the review period concludes and the data is confirmed, a claim page will go live where affected users can connect their wallet and recover their tokens. The claim process is powered by Merkl, the same infrastructure Balancer is using for their own redistribution on other chains. UPDATE: The claims portal is now open: https://gnosis-balancer-claim.eth.link/. Optional donation: The claim page will include a donation slider. If you wish, you can donate a portion of your recovered funds to the teams who contributed to the recovery effort — the client teams, core contributors, and others who spent many stressful, sleepless nights making this possible. The slider defaults to 5% and is entirely optional. Any amount is appreciated, but there is absolutely no obligation. Affected Addresses and Claimable Amounts If your address appears in this list and you believe the amounts are incorrect, or if you believe your address should be listed but is not, please leave a comment below with details so we can investigate before the claim page goes live. The CSV can be found here. Methodology The CSV file was generated using the maxyz-xyz/balancer-upscale-exploit-shares repository, and allows everyone to independently confirm the content of the file. The Beefy team has already validated the output. Full Technical Account The rest of this post provides a comprehensive technical deep-dive into the exploit, our response, the hard fork implementation, and the community debate that accompanied one of the most consequential decisions in Gnosis Chain’s history. Table of Contents The Balancer V2 Exploit The Vulnerability: Precision Loss in Composable Stable Pools The Attack Methodology Immediate Aftermath Across Chains Our Response: The Soft Fork The Hard Fork Decision Technical Specification of the Hard Fork Implementation Across Execution Clients Why This Approach and Not Another Community Debate: Immutability vs. Accountability Timeline of Events Conclusion The Balancer V2 Exploit: November 3, 2025 Balancer is one of the oldest and most established decentralized exchange (DEX) and automated market maker (AMM) protocols in the DeFi ecosystem. At the time of the exploit, Balancer V2 had undergone 11 audits by four different security firms and was widely regarded as one of the most battle-tested protocols in DeFi. The attack targeted Composable Stable Pools — a specialized pool type designed for trading assets that hold near-parity value to each other, such as USDC/USDT or WETH/stETH. These pools use StableMath, a variant of Curve’s invariant math, to offer minimal slippage for correlated assets. The total damage across all chains exceeded $120 million, making it one of the largest DeFi exploits of 2025. White hat hackers were able to recover approximately $28 million, but the majority of the stolen funds initially remained under the attacker’s control. The Vulnerability: Precision Loss in Composable Stable Pools According to the post-incident analysis by the SlowMist security team, the vulnerability resided in the integer fixed-point arithmetic used to calculate scaling factors inside Composable Stable Pools. Root Cause The Balancer V2 math library uses fixed-point integer arithmetic with 18 decimal places of precision (i.e., values are represented as integers scaled by 10^18). When computing swap outputs for very small amounts, the rounding behavior of integer division creates tiny but systematic discrepancies between the theoretical price and the actual computed result. Under normal conditions these rounding errors are negligible — fractions of a wei. However, the attacker discovered that by carefully manipulating pool liquidity and executing precisely calibrated sequences of small swaps, these errors could be amplified and extracted as profit. Key Technical Details Affected pool type: Composable Stable Pools (CSPv6) Root cause: Precision loss in fixed-point FixedPoint.mulDown() and FixedPoint.divDown() operations during scaling factor calculations Attack vector: Batch swaps chaining multiple operations within a single transaction Amplification mechanism: Repeated cycles of small swaps that compound rounding errors Prerequisite: The attacker first drained pool liquidity to amplify the relative magnitude of precision errors in subsequent small-amount swaps The Attack Methodology The attacker executed a sophisticated multi-step strategy, repeated in cycles: Liquidity Drain: Swap BPT (Balancer Pool Tokens) for underlying liquidity tokens to reduce the pool’s reserves, making subsequent precision errors proportionally larger. Precision Setup: Perform preparatory swaps between liquidity tokens (e.g., osETH → WETH) to position balances at specific decimal boundaries. Error Accumulation: Execute carefully controlled small-amount swaps (e.g., osETH → WETH) that trigger precision loss in the rounding calculations, each time extracting a tiny excess output. Liquidity Restoration: Swap between liquidity tokens in the reverse direction (WETH → osETH) to restore enough liquidity for the next cycle. Amplification Loop: Repeat steps 2–4 many times to continuously compound the accumulated error. Extraction: Swap the liquidity tokens back into BPT to restore the pool to a superficially balanced state while pocketing the accumulated profit. Through this methodology, the attacker pushed the system into settling a final amountOut that exceeded the true amountIn owed, generating substantial profit on each cycle. Funding and Execution SlowMist traced the attacker’s operations across multiple addresses and chains. Initial funds were routed through Tornado Cash, then through intermediate nodes and cross-chain gas.zip usage, before being assembled on Ethereum-based addresses. The attacker held prepared positions across multiple networks to exploit the same vulnerable pool type simultaneously. Immediate Aftermath Across Chains The response varied significantly across affected networks: Chain Estimated Loss Response Ethereum ~$80M+ CSPv6 pools paused, factory disabled, gauges killed. White hat recovery of ~$28M (including 5,041 osETH worth ~$19M). Gnosis Chain ~$9.4M Emergency soft fork freezing attacker’s address, followed by hard fork. Monerium froze EURe balances. StakeWise froze osGNO (~$2M). Arbitrum Significant No validator-level intervention possible. Base, Polygon, others Various Limited recovery options. Balancer offered a 20% bounty for the return of stolen funds to both white hats and the attacker. As of the time of the hard fork, this bounty remained unclaimed by the primary attacker. The key differentiator for Gnosis Chain was that the funds remained on-chain in identifiable wallets and our validator set was coordinated enough to act. Our Response: The Soft Fork The Decision to Act On November 5, 2025, two days after the exploit, we published the first update on the Gnosis Forum. The post outlined the situation and the options available: “Our goal remains to get to a point where censorship — even at the validator level — is impossible. But, since validators do still have an ability to act, the question is how we use it. To stand aside because power can be abused or to act responsibly while we can?” Why a Soft Fork First? A hard fork would have required all ~340,000 validators to upgrade almost immediately, risking network disruption and penalizing smaller independent validators who might not be online 24/7. We chose a soft fork as the initial measure because: It allowed voluntary adoption by validators without network disruption Validators could adopt a client update that simply refused to attest to blocks that included transactions from the attacker’s address (0x506d1f9efe24f0d47853adca907eb8d62e3207) and deployed smart contracts It preserved validator autonomy — each validator chose whether to participate It bought time for the community to coordinate a broader response It did not require consensus from all validators — only a majority (>50%) needed to adopt it A Critical Property: Zero Chain Modification A crucial and often misunderstood aspect of the soft fork is that it did not modify the chain state in any way. No blocks were rewritten, no transactions were reversed, no balances were altered. The soft fork was purely a block production policy: validators running the soft-fork client simply refused to attest to blocks that included the attacker’s transactions. The chain’s history, state, and rules remained completely untouched. This means the soft fork was fully and trivially reversible at any moment. If a majority of validators had decided to stop running the soft-fork client and revert to standard software, everything would have gone back to normal — as if nothing had ever happened. The attacker’s funds would have been unfrozen, and the attacker could have moved them freely. There was no lasting mark on the chain from the soft fork itself; it existed only as a collective, voluntary, real-time decision by validators about which transactions to include in new blocks. This property is what made the soft fork an appropriate emergency measure: it bought time without committing the chain to anything irreversible, preserving the community’s ability to deliberate on next steps with full optionality. Implementation The soft fork was coordinated discreetly to avoid alerting the attacker. Once over 50% of validators had adopted the soft-fork client, we publicly announced the measure. Bridge governors also temporarily halted bridge activity to prevent the attacker from moving funds off-chain. Martin Köppelmann, co-founder of Gnosis, stated: “What triggered me to try to get the soft-fork done was indeed protecting users. What described as ‘Low-risk DeFi’ is what Gnosis has focused on in the last couple of years. And I cannot: 1) promote users / ‘normal people’ our products 2) if something happens not do anything I can to try to fix it.” The Hard Fork Decision While the soft fork successfully froze the stolen funds, it was inherently fragile and temporary. Because it made no modifications to the chain whatsoever — it was purely a voluntary validator policy — it could evaporate at any moment if validator participation dropped below the required threshold: It required ongoing, active cooperation from a majority of validators; if they stopped running the soft-fork client, the freeze would vanish instantly and the attacker would regain full access to the funds Any future client updates could inadvertently break the censorship rule if validators upgraded without the soft-fork patch The funds could not be redistributed to victims — only prevented from moving The longer the soft fork persisted, the higher the risk of the freeze breaking On December 12, 2025, we announced on the governance forum that execution client releases for a hard fork were ready: “Since then contributors, validators and other stakeholders have been working on a hard fork intended to create a technical path for the potential return of stolen funds. Gnosis Chain rules are baked into the code the validators run. The last step is the crucial one: a majority of validators must adopt the new binaries in order for the hard fork to succeed.” The hard fork was set to activate at 16:11:40 UTC on December 22, 2025 (Unix timestamp 1766419900). Node operators were given 10 days to decide whether they wanted to update or not. Technical Specification of the Hard Fork The hard fork was formally specified in the gnosischain/specs repository. Core Mechanism: Irregular State Transition The hard fork introduced an irregular state transition — a one-time modification to the chain state that occurs outside of normal EVM execution. The specification defines: “Introduce an irregular state transition on Gnosis Chain to replace the code of the Balancer V2 attacker’s externally owned account (EOA) with a restricted forwarding contract. This enables coordinated recovery and subsequent redistribution of funds taken in the Balancer V2 exploit of November 3, 2025.” What Happens at Fork Time During block processing of the first block whose timestamp crosses BALANCER_HARDFORK_TIMESTAMP, and before the system calls of EIP-4788 (beacon root) and EIP-2935 (historical block hashes), the bytecode of the attacker’s account MUST be set to the rescue contract bytecode. No other account fields (balance, nonce, storage) are modified. Parameters Constant Value BALANCER_HARDFORK_TIMESTAMP 1766419900 (Dec 22, 2025 16:11:40 UTC) BALANCER_ATTACKER_ADDRESS 0x506d1f9efe24f0d47853adca907eb8d89ae03207 BALANCER_RESCUE_ADDRESS 0x7Be579238a6a621601Eae2c346cDA54d68F7dfee BALANCER_RESCUE_BYTECODE (see below) Reference Implementation (Pseudocode) def process_block(parent_header, block, state): if ( parent_header.timestamp < BALANCER_HARDFORK_TIMESTAMP and block.header.timestamp >= BALANCER_HARDFORK_TIMESTAMP ): state.account(BALANCER_ATTACKER_ADDRESS).bytecode = BALANCER_RESCUE_BYTECODE # ... continue with regular block processing, including EIP-4788 and EIP-2935. The Rescue Contract (HardcodedForwarder) The bytecode injected into the attacker’s account is a minimal Solidity contract with a single hardcoded owner: // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.30; contract HardcodedForwarder { /// BALANCER_RESCUE_ADDRESS address public constant owner = 0x7Be579238a6a621601Eae2c346cDA54d68F7dfee; modifier onlyOwner() { require(msg.sender == owner, "not owner"); _; } function execute( address target, uint256 value, bytes calldata data ) external onlyOwner returns (bytes memory result) { require(target != address(0), "zero target"); require(target.code.length > 0, "not a contract"); (bool success, bytes memory returndata) = target.call{value: value}(data); if (!success) { if (returndata.length > 0) { assembly { let returndata_size := mload(returndata) revert(add(returndata, 0x20), returndata_size) } } else { revert("call failed"); } } return returndata; } receive() external payable {} } Key design properties: Single immutable owner: The BALANCER_RESCUE_ADDRESS (0x7Be579238a6a621601Eae2c346cDA54d68F7dfee) is hardcoded as a constant — it cannot be changed. Forward-only to contracts: The execute function can only call non-zero contract addresses, preventing direct ETH transfers to EOAs. No state of its own: The contract holds no storage, minimizing the attack surface. EIP-3607 enforcement: Because the attacker’s account now has bytecode, EIP-3607 prevents any transaction originating from this address from being included in blocks, even though the attacker still holds the private key. This is because EIP-3607 rejects transactions from accounts that have non-empty code. The BALANCER_RESCUE_ADDRESS was configured as a Gnosis Safe multisig with the same signer set as other DAO Safes. Initially deployed with a single signer for shadow fork testing, the signers were updated on December 15, 2025 to match the DAO’s multisig configuration before the fork went live. Implementation Across Execution Clients The hard fork required implementation across all four execution layer (EL) clients supported on Gnosis Chain. The work was completed by the respective client teams in coordination with our core developers over the course of approximately 6 weeks. Nethermind — v1.35.8 Release: v1.35.8 (December 19, 2025) Commit: c066aee Notes: The release also included optimized getProofs RPC endpoints and build-time signing of release artifacts. The Balancer hardfork support was integrated into Nethermind’s Gnosis Chain configuration, with the irregular state transition being applied at the specified timestamp. Nethermind holds the supermajority client position on Gnosis Chain. Erigon — v3.3.2 Release: v3.3.2 “Rocky Romp” (December 13, 2025) PR: #18282 “Balancer cherry picks”, cherry-picked from #18122 Merge commit: 7d0dd4f Key commits: a6c5ba0 — Set fork time dfaf16c — “Balancer HF: support code rewrite” (by yperbasis and mh0lt) 92fe7e0 — Censoring in state_transition e4ce76e — Add sender/authority censoring to txpool e25c0aa — Add override.balancer flag 4664f24 — Override CensoringSchedule 37ec713 — Use *big.Int for BalancerTime so that it feeds into the fork ID Contributors: mh0lt, yperbasis, AskAlexSharov Notes: Erigon’s implementation notably includes the censoring logic in both the state transition and the transaction pool. The override.balancer flag allows operators to explicitly opt in or out. Reth (Gnosis) — v1.0.0 Release: v1.0.0 (December 12, 2025) Commit: 159a354 Key PRs: #95 “feat: Balancer hardfork spec - per block application” #99 “Balancer Hardfork” Contributor: debjit-bw Notes: This was a major release for reth_gnosis, marking its v1.0.0. It also introduced pre-merge history support via ERA file imports and migrated state files to Cloudflare R2. Important: Upgrading to v1.0.0 from any previous version required a full database resync. Built on upstream paradigmxyz/reth v1.9.3, including Fusaka-ready logic. Geth (Gnosis) — v1.16.7-gc.9 Release: v1.16.7-gc.9 (December 14, 2025) Commit: 40d619f Repository: gnosischain/go-ethereum Notes: The Gnosis fork of go-ethereum (Geth). This release included the Balancer hardfork support specific to Gnosis Chain’s configuration. Consensus Layer Clients For completeness, the consensus layer (CL) clients also required updates, though the core fork logic resides in the EL: Client Version Nimbus v25.11.1 Lighthouse v8.0.1 Teku v25.11.1 Lodestar v1.37.0 The Formal Spec The full formal specification is available in the gnosischain/specs repository: Spec PR: #87 “Spec Balancer hard fork” Merged: December 15, 2025 (commit 8c846ab) Files: execution/balancer_recovery.md — The detailed technical specification network-upgrades/balancer.md — The network upgrade schedule Why This Approach and Not Another Several alternative approaches were considered or discussed. Understanding why we chose the bytecode-replacement approach illuminates the constraints and trade-offs involved. Why not a simple balance transfer (state override)? A direct balance transfer (debiting the attacker’s account and crediting victims) would have been more invasive. The stolen funds were not simply native xDAI sitting in the attacker’s EOA — they existed as various ERC-20 token balances (Balancer V2 account balances, EURe, etc.) held in smart contracts where the attacker’s address was the authorized party. Simply moving ETH/xDAI balances would not recover these tokens. The bytecode replacement approach is more surgical: it doesn’t touch the attacker’s balance, nonce, or storage. Instead, it gives the DAO-controlled rescue address the ability to execute arbitrary calls as the attacker, which means it can interact with the Balancer Vault and other contracts to properly withdraw and redistribute all token types. Why not revert the transactions (chain rollback)? A chain rollback (reverting to a state before the exploit) was never seriously considered. Unlike the 2016 Ethereum DAO fork, the Balancer exploit had been live for weeks before the hard fork. Reverting weeks of chain history would have invalidated thousands of legitimate transactions and would have been catastrophic for the ecosystem. Why not just let the DAO reimburse victims? Some community members suggested the DAO should simply cover the losses from its treasury. As we responded: “I cannot understand how anyone could expect the DAO to reimburse anyone for Balancer getting hacked? So a protocol deployed on Gnosis gets hacked for $10m, and you expect Gnosis DAO to lose $10m, whether they had $0 or $10m in Balancer, and everyone else walks out whole? Why?” Additionally, the DAO’s exposure to the hack was reportedly less than 2% of its holdings — the primary motivation was protecting retail users who had deposited in what was marketed as “low-risk DeFi.” Why not wait for a governance framework first? Several community members argued the hard fork should be delayed until a formal governance framework for such interventions was established. We explained the urgency: “There is another critical downside: the soft fork is inherently fragile. Every day the hardfork is delayed, chances of recovering any funds diminish significantly, especially when new client versions are released, as people tend to update to those. If we delay this until after New Years, I give a non-insignificant chance of wasting all our efforts for the past 1.5 months and losing all the funds.” Why bytecode replacement specifically? The choice to replace the attacker’s account bytecode rather than modifying balances directly was motivated by: Minimal state change: Only the account’s code field is modified. Balance, nonce, and storage remain unchanged. EIP-3607 compliance: Once the account has code, the attacker can no longer send transactions from it — the private key becomes useless for transaction signing. Flexibility: The rescue contract allows the DAO to execute arbitrary calls as the attacker, enabling interaction with any contract where the attacker has permissions or balances. Auditability: All rescue operations happen as normal on-chain transactions, fully visible and verifiable. Preservation of history: No historical blocks or transactions are modified. The chain’s history remains fully intact and immutable. ## Comments **misha**: > We believe that in due course, validators should not be able to censor transactions and the underlying network infrastructure should be actually blind. We commit to working towards this future, but in the meantime encourage a community discussion on how and when the community should wield this power it still has when acting in concert.