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.