# Should GnosisDAO establish bug bounty coverage for client code?

Source: https://forum.gnosis.io/t/should-gnosisdao-establish-bug-bounty-coverage-for-client-code-and-compensate-the-eip-7702-disclosure/11951?u=mdr

Should GnosisDAO establish bug bounty coverage for client code and compensate the EIP-7702 disclosure?

Summary

This proposal seeks community input on two related questions:

Should Gnosis Chain establish formal bug bounty coverage for execution client code?

Should GnosisDAO provide retrospective compensation ($100,000) for the EIP-7702 censorship bypass disclosure that protected $5.3M in user funds during the Balancer incident?

This responds directly to @SCBuergel’s A Framework for the Future, which calls for community input on incident response principles.

Background: The Balancer Incident

The Incident

On November 3, 2025, Balancer V2 was exploited on Gnosis Chain. Approximately $9.4M was stolen. Of this:

~$4M (EURe, osGNO) was frozen immediately by token issuers

~$5.3M remained at risk, protected only by an emergency soft fork censoring attacker transactions

The Vulnerability I Discovered

On November 5, 2025, upon reviewing the publicly tagged Erigon release implementing the soft fork, I identified a critical bypass vector through EIP-7702.

The Problem: The censorship filtered transaction from and to addresses, but did not filter internal transactions or EIP-7702 authorization addresses.

The Bypass:

Attacker signs an EIP-7702 authorization delegating their EOA’s code to any contract

Any uncensored address submits a transaction containing this authorization

Transaction passes filtering (sender is clean)

EVM processes authorization – attacker’s EOA gains code execution capability

Censorship completely bypassed

My Response

November 5, 2025 ~16:00 UTC: I immediately disclosed this vulnerability privately to the Gnosis Chain security team, providing:

Full proof-of-concept test suite demonstrating the bypass

Detailed technical analysis with exact code locations

On-chain timestamp: 0x116dd19b…

November 6-7: I additionally analysed the attacker’s contracts to verify no other exploit vectors existed (vault relayer permissions, reentrancy vectors, Balancer internal balance permissions).

November 7: A second soft fork addressing the EIP-7702 vector was deployed.

Impact

Funds Recovered

The hard fork executed successfully on December 22, 2025.

Total Recovered: $5,308,954.42

Token Amount Value (USD)

sDAI 1,821,849.21 $2,222,656

wstETH 319.39 $1,159,660

WETH 265.97 $789,571

GNO 5,802.51 $735,352

stEUR 311,407.45 $401,716

This recovery was only possible because the soft fork remained intact. The EIP-7702 vulnerability, if exploited, would have resulted in permanent, irreversible loss of these funds.

Severity

Under the Immunefi Severity Classification, this falls under Blockchain/DLT with impact of “Direct loss of funds” – the highest severity category.

The severity is evidenced by Gnosis’s response: they developed and deployed a second emergency soft fork within 48 hours.

Rationale

Gnosis Chose to Intervene

Unlike Ethereum, which maintains protocol-level neutrality and does not intervene in application-layer incidents, Gnosis made an active choice to implement emergency censorship to protect Balancer users.

By taking that action, Gnosis:

Assumed responsibility for the security and effectiveness of their intervention

Deployed code that directly determined whether $5.3M would be recovered or lost

Benefited when that intervention succeeded

The intervention succeeded because the vulnerability was responsibly disclosed and patched.

If Gnosis is going to take extraordinary protocol-level actions to protect users, there must be security coverage for that code. The alternative is deploying emergency code with no incentive structure for security review.

This directly connects to @SCBuergel’s “Framework for the Future”: if Gnosis exercises discretion to help users during incidents, the framework must include security researcher engagement.

The Current Coverage Gap

The Gnosis Chain bug bounty program on Immunefi covers only AMB & Omnibridge contracts. Execution client code has no formal coverage.

When Gnosis coordinates deployment of modified client code to >50% of validators, that code becomes integral to network security. The Ethereum Foundation recognises this with their bug bounty program covering execution clients.

This incident illustrates the gap: emergency client code had no bounty coverage, yet contained a vulnerability that could have undone the entire response effort.

The Incentive Problem

Bug bounties exist because security researchers have choices. Without a formal program, the calculus becomes uncertain – researchers may question whether reporting is worth their effort, particularly when vulnerabilities could be monetised through other means.

A formal framework ensures researchers know expected compensation before deciding how to act – and critically, before they must choose between responsible disclosure and other options.

Precedent Supports Compensation

In a previous incident, a consensus bug was disclosed to Gnosis Chain. Despite the GIP not reaching quorum, Gnosis Ltd paid $10,000. This established:

Compensation is appropriate regardless of formal program existence

Ad-hoc decisions create uncertainty – a formal framework benefits everyone

Severity Is Independent of Attacker Cooperation

While exploiting this vulnerability required the attacker’s signature, this is not a mitigating factor. The attacker possessed their private key. They could have learned of the bypass through:

Public review of the tagged soft fork code on GitHub

Independent discovery

Disclosure from any party with knowledge

The soft fork’s security relied entirely on the attacker not knowing – a well-documented anti-pattern (“security through obscurity”).

Proportionality

Benchmark Amount

Ethereum Foundation (execution client bugs) Up to $250,000

Industry standard (critical severity) 10% of funds at risk

Gnosis Immunefi (bridge, critical) Up to $2M (10%)

Previous Gnosis consensus bug $10,000

This request $100,000 (~2%)

The request represents 2% of funds protected – well below industry standard. This reflects:

Acknowledgment of the coverage gap: No formal program existed

Good faith engagement: Balancing value delivered against current limitations

Precedent-aware: Consistent with established practice of compensating responsible disclosure

Quality of Disclosure

Immediacy: Disclosed within hours of public patch announcement

Quality: Full proof-of-concept test suite, not theoretical

Comprehensiveness: Additional attacker contract analysis provided

Confidentiality: Maintained until patched soft fork deployed

Distinct from Implementation Work

This addresses vulnerability disclosure, not implementation. Client teams are compensated through existing employment and contractual arrangements for building. Bug bounties compensate external researchers for finding flaws. Both are necessary.

The Request

Given the above, I am requesting $100,000 for this disclosure – approximately 2% of the $5.3M protected.

Date Event

Nov 5, 2025 Vulnerability disclosed privately

Nov 7, 2025 Second soft fork deployed

Nov 10, 2025 Formal bounty inquiry made

Dec 22, 2025 Hard fork executed, $5.3M recovered

Jan 6, 2026 This proposal submitted

Two months have elapsed. The value has been demonstrated. I respectfully request timely consideration.

Proposed Changes

1. Establish Formal Bug Bounty Coverage

Expand the Gnosis Chain bug bounty program to include:

In Scope:

Execution client modifications maintained or distributed by Gnosis

Consensus-critical specification changes coordinated by Gnosis

Emergency patches and soft forks deployed during incident response

Any code where Gnosis coordinates validator adoption

Severity Tiers: Align with the existing Gnosis Chain Immunefi program.

2. Retrospective Bounty Payment

Approve payment for the EIP-7702 censorship bypass disclosure:

Amount: $100,000 (~2% of $5.3M protected)

Recipient: [To be provided]

Funding: GnosisDAO treasury

Conclusion

This proposal seeks community input on:

Forward-looking: Should GnosisDAO establish bounty coverage for client code?

Retrospective: Should GnosisDAO compensate a disclosure that protected $5.3M?

By adopting this framework, GnosisDAO would demonstrate its commitment to security researcher engagement and establish expectations for future incidents.

Discussion Points

This is a Phase 1 proposal seeking feedback. I welcome discussion on:

The appropriateness of the proposed bounty scope

The requested amount ($100,000 / ~2%)

Concerns about precedent or process

Suggestions for improvement

Appendix: Technical Details

Vulnerable Code

File: core/state_transition.go

The filtering (lines 280-313) only checked:

if _, bad := BadFroms[msg.From()]; bad { return nil, fmt.Errorf("from address is filtered") } if _, bad := BadTos[*msg.To()]; bad { return nil, fmt.Errorf("to address is filtered") }

But verifyAuthorities() (lines 686-707) processed authorizations without checking:

authority := ecrecover(...) // Recovers censored address // NO CHECK against BadFroms st.state.SetCode(authority, delegation) // Censored address gains code

Fix Applied

if _, badAuthority := BadFroms[authority]; badAuthority { log.Warn("Ignoring authorization from filtered address", "authority", authority) continue }

Proof of Concept

core/eip7702_bypass_test.go

core/eip7702_complete_attack_test.go

Technical analysis

## Comments

**mishaderidder.eth**: Curating this bc there's lots of background reading on the Balancer incident and how Gnosis chose to intervene.

**timdaub.eth**: My commentary to the whole Gnosis fork thing: https://etherscan.io/tx/0x6893d246fc4bee564ed9c109607930f9055cd66cdece55b96d4871a6f353f254 (divested 1.8K worth of GNO last week)

**mishaderidder.eth**: I still haven’t figured out why would they sacrifice neutrality? I mean 5 million dollars is quite a lot of money, but is it enough to sacrifice the neutrality of your blockchain? On the other hand it is also setting a new paradigm, what I guess they call accountability - they want to provide safe self custody banking and now there’s a safety net maybe? But well of course bottom line is who decides what transactions need to be censored? Of course there is decentralized governance in place, validators decide in the end if there’s going to be a hard fork. But it’s all very slippery indeed. Haha I’m still on the fence. For now critically watching and waiting to see where it goes. But I understand you’re selling your tokens.