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()andFixedPoint.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
executefunction 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
getProofsRPC 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 timedfaf16c— “Balancer HF: support code rewrite” (byyperbasisandmh0lt)92fe7e0— Censoring instate_transitione4ce76e— Add sender/authority censoring to txpoole25c0aa— Addoverride.balancerflag4664f24— OverrideCensoringSchedule37ec713— Use*big.IntforBalancerTimeso 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.balancerflag allows operators to explicitly opt in or out.
Reth (Gnosis) — v1.0.0
- Release: v1.0.0 (December 12, 2025)
- Commit:
159a354 - Key PRs:
- 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 upstreamparadigmxyz/rethv1.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 specificationnetwork-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.
