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

Governance
1

Summary

This proposal seeks community input on two related questions:

  1. Should Gnosis Chain establish formal bug bounty coverage for execution client code?
  2. 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:

  1. Attacker signs an EIP-7702 authorization delegating their EOA’s code to any contract
  2. Any uncensored address submits a transaction containing this authorization
  3. Transaction passes filtering (sender is clean)
  4. EVM processes authorization – attacker’s EOA gains code execution capability
  5. 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:

  1. Assumed responsibility for the security and effectiveness of their intervention
  2. Deployed code that directly determined whether $5.3M would be recovered or lost
  3. 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:

  1. Compensation is appropriate regardless of formal program existence
  2. 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:

  1. Acknowledgment of the coverage gap: No formal program existed
  2. Good faith engagement: Balancing value delivered against current limitations
  3. 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:

  1. Forward-looking: Should GnosisDAO establish bounty coverage for client code?
  2. 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

10 Likes
Balancer hack: claim process
2

I think this is an important discussion, thanks for highlighting the gap in the current program.

Yes, I absolutely think this is a good idea.

I think a much lower amount is probably appropriate here, framed as compensation for work completed rather than as a traditional bug bounty.

While I understand that there were indeed additional steps you highlighted that helped reduce the risk of loss, this work took place during an evolving security incident spanning multiple days. In my view, this is materially different from discovering an unknown vulnerability “in the wild” within a product that is presented as complete and fit for use.

The easiest way for me to explain my concern is to imagine the perspective of those implementing the original soft fork. If non-exhaustive mitigations were understood to be open-endedly compensable after the fact, there could be a perverse incentive to delay deploying partial but meaningful risk reductions until all vectors were fully understood. That would be counterproductive in live incident response.

The key distinction from a traditional vulnerability disclosure is that those codebases are deployed as exhaustive and complete by their authors. In contrast, incident mitigations are often necessarily incremental. The entire premise of the soft fork prior to a hard fork shows this approach and its intent, otherwise it could be argued that the hard fork, the ultimate final recovery, was the most valuable and critical element of the response, and that all prior elements were faulty, which I think is misguided.

I would be very concerned about setting a precedent that incentivizes waiting until risk is reduced to zero, rather than shipping mitigations as soon as they are ready and meaningfully reduce harm.

I think this characterization is contentious. The Balancer code is what introduced the risk of direct loss of funds. The original soft fork reduced - and did not increase - the scope and likelihood of that loss. Your contribution further reduced that scope and likelihood, which is valuable and worth recognizing.

However, this distinction matters not only for categorizing the disclosure and assessing the appropriate level of compensation, but also because the framing above could be interpreted as implying that the authors of the original soft fork would have been directly responsible for any loss had it occurred. I think it is important to avoid setting precedent that increases legal or systemic pressure on those closest to recovery and security efforts during incidents.

My final point is that whatever level of compensation this disclosure is ultimately deemed worthy of — whether that is $100k, more, or less - the entity that proposed and implemented the original soft fork should be compensated at a higher level, given their relative impact on reducing the likelihood of loss of funds.

Apologies for the long post, but I think it’s very worth highlighting the very marked differences between contributions to a live security effort that requires an incremental approach vs. a vulnerability disclosure for code that has been greenlit in its entirety.

N.B. I was not part of the security response myself, so I’d be happy to hear from those directly involved, especially from those involved in the original soft fork.

2 Likes
3

Thank you for the thoughtful response. I want to address your points directly.

I think this conflates two distinct activities:

  1. Incident response work – implementing mitigations, coordinating validators, deploying fixes
  2. Security research – independently reviewing code to identify vulnerabilities

My contribution was the latter. The soft fork code was publicly tagged on GitHub and deployed to a majority of validators. At that point, it became production infrastructure – reviewable by anyone, including the attacker. Discovering a bypass vector in deployed client code is security research, regardless of when that code was written.

The timing is incidental; the vulnerability existed regardless of whether anyone was looking.

The incentive structure runs precisely the opposite direction. I disclosed within hours of identifying the vulnerability. A framework that compensates rapid, responsible disclosure encourages exactly that behaviour.

The alternative – no expectation of compensation for reviewing emergency code – creates a different problem: why spend time auditing code that falls outside formal bounty scope? The current gap means researchers have less reason to scrutinise precisely the code that matters most during incidents.

The soft fork was deployed specifically to prevent loss of funds. A bypass in that code would have resulted in the attacker draining $5.3M. Whether the root cause was Balancer’s vulnerability is immaterial to classifying the soft fork bypass – the impact of exploiting that bypass was direct loss of funds.

To use an analogy: if a bank installs a new lock after a break-in, and someone discovers that lock can be picked, the severity of that discovery relates to what the lock protects, not to the original break-in.

I want to be clear: I am not suggesting the original soft fork authors were negligent. Emergency code written under time pressure will sometimes have gaps – that is precisely why security review matters.

What I am suggesting is that code deployed to protect user funds should have bounty coverage. This protects everyone: it gives researchers clear expectations, and it gives implementers additional eyes on critical code.

Implementation work and security research are compensated through different mechanisms. Client teams receive salaries, grants, or contractual payments for building and maintaining software. Bug bounties compensate external researchers for identifying flaws. Both are necessary; neither substitutes for the other.

The Ethereum Foundation’s bug bounty programme does not reduce payouts because core developers are already compensated for their implementation work. The two are complementary.

The $100,000 figure represents approximately 2% of the funds protected – well below the industry standard of 10%. This already reflects acknowledgement that no formal programme existed at the time.

The vulnerability was real, the impact was quantifiable, and the disclosure was timely.

4

This alone is disappointing as it shows me that you haven’t considered or understood the post at all. The entire point is that there is a huge difference between work you did, and ‘industry norms’ for entirely different vulnerability disclosures. Even comparing this work to the 10% figure elsewhere is a failure to take on board the feedback provided whatsoever, and IMHO overstates your role in this dramatically.

You are anchoring your work to this 10% figure which represents, under industry norms, sole and full mitigation of a vulnerability in exhaustively audited and deployed code. You did not do this - you made a small, but valid, addition to a live and ongoing security effort.

At this point it reads like a very insensitive moneygrab tbqh and is extremely disrespectful to those who were responsible for the other 99% of the security effort. You deserve 10% but are graciously waiving it to 2%, while they are just forced to sit there with no expectation of compensation, but all the responsibility of your payment?

I was initially supportive of payment for work completed, but in light of this delusion of grandeur I will now be voting against this proposal entirely should it make it to a snapshot.

1 Like
5

There is a tension in this argument. You have stated support for establishing formal bug bounty coverage for client code. If such a programme had existed – aligned with Gnosis’s existing Immunefi programme – this disclosure would fall squarely within scope, and the payout would be significantly higher.

The argument that this work does not fit “industry norms” rests on the premise that no such programme existed. But that is precisely what this proposal seeks to address – both retrospectively and going forward.

The on-chain disclosure timestamp is 17:51 UTC on November 5 (transaction 0x116dd19b...). The transaction data contains the commit hash (cf760d8f41...) corresponding to the vulnerability disclosure in the repository. This provides cryptographic proof that the disclosure preceded – and prompted – the subsequent soft fork addressing the EIP-7702 vector.

Gnosis’s response – deploying a second emergency soft fork within 48 hours – reflects the severity of what was identified.

I have not suggested incident responders should go uncompensated. If there is concern that Gnosis lacks a framework for compensating emergency response work, I would support addressing that separately. It is not in tension with this proposal.

Nor does compensating this disclosure create pressure on the developers who wrote the original code. Aviation safety learned this long ago: when organisations treat incident reports as personal failures, people stop reporting. A “just culture” separates systemic learning from individual blame. Bug bounty payouts work the same way – they are an organisational cost, not a penalty levied against contributors. The developers who built the soft fork under time pressure should not diminished by the fact that a vulnerability was later identified and patched.

I would note the timeline: the formal bounty inquiry was made on November 10, the hard fork executed on December 22, and this proposal was submitted on January 6 – two months after the disclosure. I deliberately allowed time for the situation to stabilise before bringing this to the forum.

I regret that conclusion, and I want to be clear: I am open to discussion on the quantum. If the community believes a different figure better reflects the circumstances, I am willing to engage on that basis.

What I am not willing to accept is the conclusion that the absence of a formal programme should result in no compensation at all. A vulnerability that could have resulted in $5.3M in permanent losses – and which prompted an emergency response within 48 hours – warrants recognition commensurate with its impact. That would set a troubling precedent for future disclosures.

6

Thank you for your proposal! I’ll start by confirming that @mfw78 did indeed disclose this vulnerability.

Here is my personal opinion on the situation:

I also agree that the DAO needs to establish a bug bounty program, and in my opinion, the EF’s bug bounty program is a good start. That being said, it doesn’t sufficiently address all scenarios, like the one we encountered here, as it mostly relates to network safety.

Context

Let me start with a bit of context of how the Balancer ordeal happened:

  • The hack happened on November 3rd, at around 8am UTC.
    The exploit affected Balancer‑managed contracts on Gnosis Chain. Balancer is an independent protocol.
  • We immediately started brainstorming internally about whether some mitigations were possible (hard fork, soft fork, closing bridges, etc)
  • The core devs started working on soft fork implementations right away, as time was of the essence in case the community wanted to execute a soft fork
  • To buy some time, it was suggested to the bridge governors (a 8/15 multisig) to stop outflows on the bridge, and to bridge validators to shut down their nodes
  • Once the bridge outflows were stopped (on November 3rd at around 12pm UTC), we suggested that bridge validators turn their nodes on again
  • The soft fork was activated on November 5th at 1:30pm UTC with more than 50% of the validators

Obviously, all of this was extremely time sensitive, as the attacker could have moved funds at any time, rendering the soft fork useless. Technically, the funds could not have left the chain as the bridges were closed, but still, it would have made it more difficult to lock or recover the funds. In any case, the core dev’s utmost priority was to make sure that the chain was safe and did not break in any way. The core dev teams executed several shadow forks with all clients to confirm that.

Once the first soft fork was executed, some time was taken to make sure that everything was safe before suggesting to reopen the bridges. This was especially important as most of the core devs who helped out on this effort basically did not get a chance to sleep during those 3 days.

A few hours later, I personally heard from @mfw78 and confirmed that the issue existed.

Bug bounty

With this context in mind, I personally believe that mfw78 should get compensated. I would however challenge the amount for the following reasons:

  • At the time of discovery the damage was contained as we still had no bridges open.
  • We were already aware that the initial soft fork might not have covered all issues and planned to review everything before reopening the bridges, but his discovery helped to make that process quicker.
  • Although it is valuable, I don’t think the issue identified can be considered truly ‘critical’.
  • This could only have been triggered by the attacker. No one else could have frozen or recovered funds this way.

In general, I also believe that this poses ethical issues. Many parties worked tirelessly to recover funds that users lost because of an unrelated hack. If this is paid out from the recovered funds, then who should be rewarded? What percentage would be fair? This was a huge effort by dozens of different people and entities after all. IIf it gets paid by Gnosis DAO or Gnosis Ltd: why would they ever consider trying to recover funds again in the future? If this ended up being paid directly by Gnosis DAO or Gnosis Ltd, it feels like we’d risk setting a precedent where people expect them to bail out users after third‑party exploits. That’s not a role I think they should be pushed into.

Broader conversation

As this was an effort to recover funds from users, I believe that it might be worth having a wider discussion around the recovery. None of this would have been possible without the (mostly voluntary) help of:

  • The Nethermind team
  • The Erigon team
  • Gnosis Ltd (for Reth and Geth, coordination, etc)
  • All the validators who participated (50%+ were needed, ideally in secrecy)
  • The bridge governors (they shut down the bridge and reopened it once it was safe)
  • @mfw78 (for this disclosure and analyzing the contract)

Some other honorable mentions:

  • Balancer
  • SEAL 911 (hard fork brainstorming)
  • The bridge validators (some shut down while waiting for the governors to push their proposal through)
  • Internal treasury and auditing teams (for analysing the exploit, internal Balancer balances, what the hack did, the hacker’s contracts, etc)

Should a part of the recovered funds be allocated to all of those? If so, in which proportions? I believe that this is something the community should decide, and I personally feel like paying out a large bounty to a single individual is a bit inappropriate in this situation, where efforts were made by 30+ people to recover funds for Gnosis Chain users.

7 Likes
7

We fully agree with the establishing of a formal bug bounty for client code, and support this proposal broadly in its current state.

We would also advocate for a technical review of the bug bounty scope by Gnosis Ltd, to ensure we’re making this sufficiently open in view of their ongoing and future-planned work. Personally, we have nothing further to add to the proposed scope, but agree it seems appropriate as drafted.

We appreciate @mfw78 bringing their own position to the table, and for @0x6f2 and @filoozom’s opinions on the suitability of the $100k proposed bounty. In truth, the DAO has often struggled to reach quorum on recent proposals of this nature (example), and so we feel that setting the amount too high may cause this important proposal to languish due to a lack of engagement.

To avoid this, we’d encourage both perspectives to compromise. The previous $10k payment for a consensus bug is the obvious starting point, though we appreciate that this is a steep decline for @mfw78. Right now, we would support a $25k payment in these exceptional circumstances.

1 Like
8

Thank you, @staworth, for engaging constructively and bringing a concrete proposal to the table.

Allow me to work through the reasoning, as I believe the methodology matters for establishing sound precedent.

Under the Immunefi Vulnerability Severity Classification, this vulnerability falls within the Blockchain/DLT category with potential for direct loss of funds – their “Critical” tier. At industry-standard rates of 10% of funds at risk, the upper bound would be approximately $530,000.

Several factors warrant meaningful discounts from that ceiling:

  • No formal programme existed. The code fell outside Gnosis’s existing bug bounty scope. A substantial reduction acknowledges this gap.
  • Limited attack surface. As @filoozom correctly noted, only the attacker could have exploited this vulnerability. Whilst severity is ultimately determined by impact, the restricted set of parties capable of triggering the exploit is a legitimate mitigating factor.
  • Bridges remained closed. Although the Balancer hack: Update post announced that bridges would reopen, they did not in fact reopen prior to the second soft fork. That said, indefinite bridge closure was not a sustainable posture – the second soft fork was necessary to establish genuine security whilst the hard fork was designed and coordinated. The bridge closure bought time; the patched soft fork provided the legitimate breathing room required to execute the recovery properly.

Taken together, these factors bring $25,000 into reasonable territory – consistent with @staworth’s suggestion. This represents a reasonable compromise, and I am prepared to proceed on that basis.

On classification: My concern with accurate severity classification is not about the quantum. It is about organisational learning. When we retrospectively downgrade vulnerabilities, we risk developing cultural blind spots that impair future decision-making. Gnosis responded to this disclosure by deploying a second emergency soft fork within 48 hours – a response commensurate with critical severity. Acknowledging this honestly strengthens the case for the formal bug bounty programme this proposal seeks to establish, and ensures Gnosis has accurate institutional memory when considering future security investments.

This connects directly to the broader conversation in @SCBuergel’s Framework for the Future. As I noted there, if Gnosis determines that intervention capability is appropriate, that capability needs to be designed – not improvised. Comprehensive bug bounty coverage for client code is one component of that design. A framework that incentivises responsible disclosure across the full stack reduces reliance on improvisation and goodwill when incidents occur.

@filoozom raises an important point regarding recognition for all contributors. The incident responders, client teams, validators, and bridge governors who made the recovery possible contributed enormously – and if this proposal can serve as a catalyst for a broader conversation about how Gnosis recognises and compensates those who step up during emergencies, that would be a positive outcome. I would be glad to contribute to that discussion as it develops.

Summary:

  • Amount: $25,000
  • Classification: Critical severity, with mitigations appropriately reflected in the quantum
  • Bug Bounty Programme: Formal coverage of client code going forward

If there is sufficient consensus around this position, I am ready to advance the proposal to Phase 2.

2 Likes
9

I reject the idea that there is sufficient consensus surrounding this altered proposal. Your contribution is far less distinct from others’ than you appear to believe, and if a compensation proposal is to be put forward, all contributions should be assessed holistically rather than introduced piecemeal, as you are proposing.

Not only is it far messier, but a piecemeal process clearly advantages the first proposal at the expense of later proposals and/or the benefactor—whether that is Gnosis Ltd, GnosisDAO, or the users. This concern has already been raised. Another relevant issue is that there is an ongoing difficulty in reaching quorum for proposals.

If there is a genuine desire to create a positive catalyst for fairly rewarding all contributions, rather than prioritizing a single one (your own), I would hope you would support a single, well-deliberated proposal that encompasses all security-incident contributions. Doing so would also maximize the likelihood of quorum being met for later and smaller participants, rather than leaving them in the dust with some words of encouragement.

10

I don’t understand. I still haven’t received the refund of the blocked funds from the pool, and now we’re talking about the same issue, but concerning what happens next. What’s going to happen? Will we no longer have 100% of the blocked funds recoverable ?

11

I strongly support this proposal. From a legal and governance perspective, Gnosis took extraordinary action by intervening at the protocol level during the Balancer incident. Once the DAO chose to act, responsibility for the security and correctness of that emergency code became unavoidable. Shipping code that directly protects millions of dollars without formal security coverage exposes the DAO to enormous operational and reputational risk.

This disclosure literally saved $5.3M in user funds from permanent loss. The researcher acted quickly, responsibly, and transparently, providing full proof-of-concept tests and analysis. That kind of contribution is not theoretical—it is real, time-sensitive, and critical. Compensating it fairly is not charity; it is a recognition of the DAO’s legal and moral responsibility to incentivize responsible disclosure.

The $100,000 retrospective payment is reasonable, proportional, and well below industry norms. At roughly 2% of funds protected, it reflects the value delivered while respecting precedent and DAO treasury considerations. Legally, it sets a clear standard: when Gnosis exercises discretion to intervene, the chain must establish formal mechanisms to protect participants, researchers, and the DAO itself.

In short:
• Yes to formal bug bounty coverage for execution client code and emergency patches.
• Yes to the $100,000 retrospective payment.
• Yes to using this as a precedent for predictable, legally sound, and trust-based incident response.

This is about protecting users, securing the chain, and reinforcing a culture where doing the right thing is recognized and rewarded