A Framework for the Future

General Gnosis Chain
21

Framework for the Future: Proposal for Discussion

Thank you for your input during the consultation period.

Specifically, we recognize the contributions of @e3o8o for their tiered intervention framework, @odysseas for their explanation of the Phylax tool, @serenita_Luca for the validator perspective and @mrtdlogic, @mfw78 and @TheVoidFreak for their commitment to maintaining credible neutrality and clear communication.

Reflecting on the Balancer exploit, the community agreed that intervention was warranted, but were also clear that future interventions should be minimized and that processes and communications during and after any incident need to be improved.

With that in mind, I’d like to move the discussion to the next phase.

While the community was unanimous that any intervention must be minimized, some key tensions emerged that we’d like to start to tackle:

  1. Credible Neutrality: The debate highlighted the friction between Gnosis’s “Low-Risk DeFi” strategy and the desire for hard-line credible neutrality.

  2. Operational Ambiguity: It is clear that the current roles of the Gnosis DAO, Validators, and Gnosis Ltd are insufficiently defined during a crisis.

  3. Communication: We heard the community’s critique regarding the quality and frequency of updates and we commit to a more robust, single-spokesperson model moving forward.

We present the following as a starting point. We welcome input on the details, but in the interests of moving forward we believe we should consider this general approach to be settled.

1. Credible Neutrality

Censorship resistance was rightly at the heart of the debate surrounding the Balancer exploit.

It is one of our guiding principles, but our stance is that it is only meaningful if we are actually blind and not just wilfully blind. We remain fully committed to a future in which the Gnosis Chain is actually blind and are closely following developments in this space.

We will continue to monitor and will share updates with the DAO as it evolves.

Until then we are proponents of a low-intervention approach within clear parameters. We’re glad to see that the community agrees on this.

2. Operational Ambiguity

We took this opportunity to reflect on the way Gnosis Ltd and the Core Devs worked with the Gnosis DAO and with our validators during this time.

The situation was challenging for all involved and we are grateful to you for working with us.

In our opinion, the outcome was good but the process for getting there wasn’t.

We want to clarify roles, responsibilities and processes to make sure we avoid putting ecosystem participants in that position again. This needs to strike a balance between consulting relevant parties and acting quickly and responsibly in a dynamic exploit situation.

Here is a starting point for what that could look like.

Step 1: define the process

We propose a simple framework for determining when it is necessary to intervene in the standard operation of Gnosis Chain and Bridge.

Unfortunately it is challenging to remove all judgement from the assessment, but we should be transparent on the factors that would be considered as well as the roles of each of these actors in times of crisis.

Once an issue is flagged:

  1. A dedicated Crisis Response Team within Gnosis Ltd would assess the criticality based on:
  • Amount of funds affected (e.g., >3% of TVL might be moderately critical, while >5% of TVL could be severe).
  • Level of assumed user risk (e.g., services with robust audits AND over 3 years of operations might be deemed low risk; those with robust audits OR over 3 years of operations deemed medium risk; and those with neither deemed high risk). The higher the assumed risk, the less warranted an intervention.
  • Technical feasibility of intervention (e.g., actions like bridge pausing may be a relatively simple precautionary measure as opposed to chain interventions that could range from transaction censorship, to soft fork, to hard fork, right up to roll back).

These details are obviously critical and we would hugely value the community’s input.

  1. These assessments would be combined into a recommendation that would be provided to a Security Council (more details below). This council would approve or veto the decision based on a simple majority. Crucially, the Security Council acts only to ratify the recommendation, and has no responsibility for developing or implementing it.

While the recommendation would not be public at the time, it would be published within months of the resolution of the incident, along with the outcome of the Security Council’s vote. It may also be possible to publish an encrypted version of the decision at the time for later decryption, provided this does not slow down the process.

  1. If ratified, the official recommendation is communicated to the relevant parties so they can determine how to act. Depending on the specifics of the ratified recommendation, these parties might include core devs, validators, client teams, the bridge committee, and others.

Step 2: Confirm the role of Gnosis DAO

Security incidents create unique operational challenges that may be at odds with a DAO’s collective decision-making. This is because of the probable need for swift response without a malicious actor being forewarned via public discourse.

We suggest that decision making authority is delegated to a DAO-appointed Security Council. We could use a similar approach as GIP-129, for example.

The DAO remains the foundational governing body of the ecosystem, is responsible for establishing and updating the overarching incident response framework, and will remain informed of decisions/actions taken, having audit rights to hold stakeholders accountable.

Specific rights and responsibilities of the DAO in times of crisis could look as follows:

  1. Recovery Asset Steward: If an intervention is designed to intercept or recover assets that were compromised during an exploit/security incident, they may be sent to the DAO to hold, ensuring the community retains control over the final distribution of such assets;

  2. Strategic Accountability: within two months of any incident, the relevant stakeholders (Core Devs, Gnosis Ltd and the Security Council) commit to a formal retrospective with the DAO;

  3. Continuous Improvement: the retrospective will be the primary mechanism for the DAO to audit actions/decisions taken, identify learnings, and mandate improvements to the framework.

Step 3: Confirm the role of Gnosis Validators

While Chain Governance is the mandate of our validator community, the current mechanisms for consensus were designed for network stability and upgrades, rather than rapid response security interventions.

It is unreasonable to put the responsibility of decision making in extraordinary scenarios on our validator community.

In the event of a crisis or exploit, placing the burden of decision-making on the validator community presents significant challenges:

  1. Neutrality / Liability: By forcing validators to make subjective choices about freezing/diverting funds or enforcing state changes, it could compromise their “blind” neutrality and expose individual validators to undue legal risks / social pressures.
  2. Operational Constraints: The validator community is globally distributed and therefore reaching a timely consensus on a complex, evolving security threat is logistically / practically difficult and may not be achievable within the timeframes required to prevent asset loss.

Step 4: establish a Security Council

Rather than delegate these crisis decisions to the validator set, we recommend the creation of an independent committee, a Security Council, who would act as a check on power and ensure that the agreed framework guides actions in times of crisis.

The structure is designed to:

  1. Insulate the validator community: The Security Council takes on the technical and ethical burden of the immediate response, allowing validators to focus on their primary mission: maintaining the security and uptime of Gnosis Chain.

  2. Provide an expert check on power: By appointing a council of recognised experts and committed community members on the basis of their objectivity, integrity and experience, we ensure that intervention is guided by a rigorous, agreed-upon framework, rather than ad hoc pressure.

This could be a five-member council, with members chosen from outside of Gnosis Ltd on the basis of their objectivity, integrity, and experience. Gnosis Ltd could make recommendations for council members and we would welcome nominations from the community.

3. Communications

We will strengthen our crisis comms process to improve quality and timeliness of updates to the community and partners. A clear crisis comms plan will ease the decision making burden placed on the Crisis Response team, allowing them to focus on what matters while still keeping the community informed. However, it’s important to note that information may need to be withheld from the public domain while decisions are being made and implemented.

This includes making sure that there is a spokesperson defined in each case who will ensure timely updates.

Future Possibilities

As tools like Phylax evolve there is a possibility of managing risk tolerance at a dApp level but it is too early to rely on this entirely at this stage. We could look to bring tools like this into the Gnosis ecosystem to empower dApps building on Gnosis to define their own strategy.

If this rough framework seems agreeable, the next step would be for us to produce a more detailed proposal for the community to assess through the GIP process.

Next Steps

The next step is to produce a formal version of this proposal for DAO approval. This will include the assessment criteria for intervention, process commitments for communication and nominations for the security council. We welcome input on all these points and more.

I’ll be hosting a community call at on Thursday, 2pm UTC where I’ll look forward to your feedback and ideas.

Within about one month this proposal will be presented to the DAO as a GIP.

5 Likes
22

I joined the X Space on Thursday and appreciate how far this process has come. Thank you for turning the Security Council Framework into a concrete proposal @SCBuergel.

The structure reads as a clean separation of concerns: Crisis Response Team (assessment and evidence gathering), Security Council (time-critical decision, with veto/ratification hooks), and the DAO (auditability and accountability). It maps closely to the separation of concerns we’ve discussed in this thread.

A few suggestions that would strengthen the proposal:

1) Codify an explicit non‑powers list

The draft already separates the SC from implementation (validators, core devs, bridge committee). I’d recommend the GIP explicitly codifies what the SC cannot do:

  • Cannot arbitrarily overwrite chain state
  • Cannot move user funds from arbitrary addresses
  • Cannot unilaterally change protocol rules (consensus/execution changes require validator adoption and/or a fork)
  • Cannot expand its own scope without DAO approval

A clear non‑powers list turns the SC from a trusted committee into a constrained decision body, and directly addresses credible neutrality concerns.

2) Enforce constraints technically at the Safe level (where applicable)

If the SC operates via a Gnosis Safe (natural given prior incident-response patterns), an “emergency action registry” can be enforced via a Guard contract that restricts the Safe to a pre-approved allowlist of (target contract, function selector) pairs.

This makes SC authority technically bounded rather than socially bounded. I described a concrete implementation path here:

3) Make assessment criteria quantitative where possible

The proposed factors (% of TVL, protocol maturity, audit status) are strong. One option is to publish a simple decision matrix template with approximate thresholds to reduce ambiguity under time pressure (example only):

Factor Low Moderate Severe
TVL affected < 1% 1–5% > 5%
Protocol age > 3 yrs 1–3 yrs < 1 yr
Audit status Multiple Single None

This makes criteria testable and reduces decision load during incidents.

If helpful, I’d be happy to help contribute in drafting the GIP. I can provide:

I’m happy to help with a working group. I’m also open to serving on the Security Council if the community thinks my contributions and research engineering background would be useful.

Thank you again, this is a valuable precedent for defining legible emergency authority.

2 Likes
23

Following up on my post with a more concrete constraint model. This covers the three areas I raised i.e. the non-powers list, the Guard-based action registry, and an quantitative assessment matrix, in enough detail that they could be incorporated directly or adapted into the GIP draft. These are just a general minimum constraints I think can surround it, not prescriptive.

Title: Emergency Governance “Minimum Viable Constraint” (MVC)

Goal: if Gnosis adopts this framework, make Security Council authority bounded by design and legible under time pressure.

This MVC includes a non‑powers list, a Guard-based action registry concept, and a quantitative assessment matrix template.

A) Non‑Powers (negative capability) - what the SC explicitly cannot do

These constraints fit the execution-layer reality described in Gnosis’ execution specs and existing precedent (e.g. BGB actions are contract-surface actions, not arbitrary state edits).

The SC should not be able to:

  1. Arbitrarily overwrite chain state

    • No generalized state editor
    • Any true state-level recovery still requires validator adoption or a fork path (outside SC’s unilateral authority)

  2. Move user funds from arbitrary addresses

    • No confiscation or discretionary transfers
    • Property-rights boundaries should stay explicit

  3. Unilaterally change protocol rules

    • Consensus or execution rule changes still belong to node operators and formal governance processes

  4. Expand its own scope or powers without DAO approval

    • Any new action surface should require an explicit governance decision (GIP + vote).

  5. Act outside a pre-approved action registry

    • If a surface is not pre-authorized, it should not become callable in the middle of a crisis

Rationale: This shifts the SC from “trusted committee” to “constrained decision body”, and thus preserves credible neutrality while still enabling fast response on pre-approved surfaces.

B) Guard-based emergency action registry - allowlist schema

Where the SC or EC acts through a Safe, one concrete way to bound authority is through a Guard that enforces a pre-approved allowlist.

The registry should be:

  • simple
  • auditable
  • easy to review before an incident
  • narrow enough that the community can reason about each permitted action surface

Minimal schema (conceptual)

Each entry defines an allowed call pattern (can be defined in JSON as a review artifact):

  • target: contract address or constrained target set
  • selector: 4-byte function selector
  • value_max_wei: maximum ETH value allowed, often 0
  • calldata_rules: optional parameter constraints (range/enum)
  • expires_after_seconds: optional “sunset window” for the entry
  • reason: human-readable explanation
  • added_by_gip: reference to the governance proposal authorizing it

Guard behavior (high-level)

  • reject any Safe tx where (to, selector) is not allowlisted
  • enforce value <= value_max_wei
  • optionally enforce calldata invariants such as token address or bounds
  • emit an onchain event EmergencyActionAttempted and EmergencyActionExecuted

Design note: This is the least invasive enforcement path (Safe-level). Protocol-level enforcement is a separate, higher-social-cost choice.

C) Quantitative assessment matrix template (illustrative incident triage)

This should not be treated as a rigid algorithm. The purpose is to reduce ambiguity and make decisions more reviewable after the fact.

Example input dimensions (from incident ops reality)

Dimension Low Moderate Severe
TVL affected < 1% 1–5% > 5%
Exploit novelty Known pattern Partially novel Novel or unclear
Protocol maturity > 3 years 1–3 years < 1 year
Audit posture Multiple audits Single audit Unaudited
Contagion risk Low Medium High
Confidence in attribution High Medium Low
User impact Contained / limited Noticeable but bounded Broad user harm or likely mass loss
Time sensitivity Hours or days Rapidly unfolding Minutes matter / active outflows
Recoverability without intervention Likely Uncertain Unlikely
Availability of least-scope action Clear narrow action exists Action exists but may affect bystanders Only broad action appears available
Cross-domain coordination burden Single actor / surface Multiple actors Bridges, validators, infra, and external coordination required
Reversibility Easily reversible Partially reversible Hard to reverse once executed
Evidence quality Strong onchain evidence Mixed onchain/offchain evidence Fragmented, disputed, or incomplete evidence
Governance readiness Predefined authority and runbook exist Partial process exists No process or ratification path

These bands are illustrative, not canonical. The DAO or working group would still need to decide whether these are the right dimensions and thresholds for Gnosis.

Example output logic

  • High severity + high confidence + time-critical + narrow action available
    Prefer the least restrictive containment surface that is likely to work, especially where reversibility remains high and bystander impact is limited.

  • High severity + low confidence or fragmented evidence
    Prefer monitoring, evidence collection, bridge and infrastructure coordination, and explicit escalation triggers over broad action.

  • Moderate severity + uncertain recoverability
    Require additional escalation criteria, such as ongoing extraction over a defined period, worsening contagion risk, or evidence that a narrow intervention path will soon disappear.

  • Severe impact + only broad action available
    Raise the legitimacy bar. Broad intervention should require stronger evidence, clearer ratification paths, and more explicit justification for why narrower options are insufficient.

  • Low or moderate impact + high reversibility + strong existing process
    Favour bounded, temporary actions with automatic expiry and immediate public evidence publication.

Required evidence bundle (always)

Any SC emergency action should still be accompanied by:

  • Incident summary and timeline
  • Affected contracts and scope
  • Rationale for why this action is the least restrictive option likely to work
  • Sunset or expiry window
  • ratification and review path.

I think these minimum constraints would make the GIP more legible and easier to audit. Hopefully, this serves as an informative appendix towards drafting the language for the eventual GIP.

1 Like
24

Thanks @e3o8o for all this great input. I think the update assessment framework is particularly strong. Will have more feedback once I’ve been able to assess technical feasibility and suitability of some of the other points, but just wanted to assure you you aren’t typing into the void.

I’m drafting the first version of the GIP in consultation with @SCBuergel and Gnosis Legal, but obviously we welcome robust input and changes once that’s published. Expected timeline is sometime next week.

25

Thank you @thewanderingeditor, I appreciate that.

I’m glad the assessment framework is useful. My sense is that the most important aspect is exactly what you mention; stress-testing which parts are legally and technically workable, and then making those boundaries for implementation clear. I looking forward to the GIP draft.

26

Sorry for the long delay here. This was partly me getting drawn into the rabbit hole of this issue, particularly in the wake of Mythos, which has seen a bit of an explosion of interest in security response strategies, particularly for those outside that particular walled garden.

The GIP has been through several drafts, the latest of which is currently being looked over by legal and technical teams. The framework structure is largely unchanged.

Having read your Legitimate Overrides in Decentralized Systems paper, and your posts on Eth Research and elsewhere, I did want to continue the discussion on a few general points.

First, a clarification: the Security Council is designed to only have ratification powers, so in a narrow sense your non-powers list is irrelevant. The Council couldn’t do any of those things you list even it wanted to. (It could try to engage the DAO to do them, but then so could you or I.)

But the list itself is very relevant because I agree that those powers, considered more generally, are things that we wouldn’t want to see come out of this framework, from any involved actor. But it is harder to codify non-powers when it’s less clear where the power would be located. Perhaps the Security Council would pledge to not ratify proposals which entailed things like those you list.

Similarly, given that the Security Council is purely to ratify intervention proposals, it wouldn’t need a Safe or any on-chain presence at all (perhaps it could make sense to vote on chain, but that doesn’t seem necessary since votes would likely need to be private at the time of an incident, or at least the context would need to be).

Equally, no other parties involved in the framework have a clear Safe or other on-chain interface which could be constrained. While I agree that the constraints listed seem sensible, it seems counterintuitive to build such a Safe for the sole purpose of applying these constraints. That might be wrong (e.g., if all the powers which need constraining exist, but diffusely, it could feasibly better to combine them somewhere in order to constrain them.)

I don’t think anything in the Gnosis Chain context is as clear cut as that, though. It’s not like, e.g., AAVE, which you cover in your paper, where there is a clear core protocol to protect. The only wrinkle to this that I can see is the bridge, and perhaps that would be worth more consideration. But the bridge committee is not the security council, for all kinds of legal, practical and technical reasons.

All of which is a longwinded way of saying that I think some of your suggestions fall outside the scope of what this framework wants to or could achieve. That said, I would like to further discuss two issues which are addressed in your work.

The first is speed: your data shows the strong correlation between the speed and effectiveness of a response. This is largely unsurprising, of course, but it was still helpful to see the strongly non-linear drop-off in effectiveness as time passed.

Which brings me to my question: having analysed so many exploits, does the Balancer Exploit seem anomalous to you, particularly in the Gnosis case? Gnosis was able to effectively spot the exploit, pause the bridge, and ultimately recover assets. This framework is being created as a response to that to try and improve communication and legitimacy, but I wonder if there’s a hidden assumption that the speed of the Balancer exploit was reasonably typical, and therefore there is scope to add extra response steps. If it was atypical, and much faster response times are generally needed, then adding all these assessment and ratification steps may not straightforwardly help. Having come this far, I’m not inclined to move away from this structure. A certain amount of pre-defined process aids decision making, but it is important to not overcomplicate things if speed is the most essential factor.

The other concern I have is about feasibility of coming up with a plan to be ratified. I think the original draft was somewhat naïve to imply that a single plan is possible to create in advance. I therefore modified the GIP to allow for partial or contingent plans, with resubmission and re-ratification needed once events progress outside of the scope of the original proposal. But maybe this is still naïve, and the reality is too messy. Of course any process which is designed to proceed in natural language and be largely unbounded in scope will be messy and require considerable application of common sense, both during an incident and retrospectively, but equally the specifications for the proposals can’t be so loose that this all becomes bureaucracy theatre.

In your experience, did the exploits you studied where intervention was possible allow for clear descriptions of those interventions in advance, which something like our proposed Security Council could meaningfully ratify?

27

@thewanderingeditor thank you for the careful read and for pushing on these two hard questions. The Mythos aftermath def makes both more urgent; every new incident narrows the window for establishing a legible default before the next one forces improvisation again.

On the first question: The Balancer incident should not be treated as the baseline timing assumption. It was not purely anomalous. Other addressable incidents in the dataset had meaningful intervention windows. But Balancer sits in the favorable part of the distribution:

  • it was noticed relatively quickly
  • there were still reachable containment surfaces (notably the bridge)
  • coordination capacity existed across multiple actors
  • the recovery path did not depend on a single fully-specified plan at minute zero.

In the 52 focus-verified intervention cases in the paper, the median containment time for Delegated Body actions was roughly 60-90 minutes; Signer Set actions were closer to 30 minutes. Balancer’s case involving bridge freeze fell within the delegated body range, but it benefited from conditions that many incidents do not share.

Effectiveness drops off sharply as windows close and action surfaces disappear, and the non-linear decay you noted in the data is the main reason I would be careful about adding too many hot-path steps.

A useful default is:

  1. pre-authorize the smallest plausible fast-path actions (containment)
  2. ratify continuation or escalation (deliberation)
  3. audit and revise after the fact (accountability)

that is different from expecting the full legitimacy stack to be completed before anything happens.

On the second question: most incidents do not allow for a single clean, complete intervention plan to be written in advance and then ratified once.

Facts move, bridges behave differently than expected, attackers change routes, and the feasible action set shrinks over time. So your move toward partial / contingent plans is the right direction. What seems more realistic is ratifying a bounded decision envelope rather than a detailed script. For example:

  • current incident summary and evidence threshold
  • the immediate objective (e.g. “prevent further drainage via bridge”)
  • the permitted action surfaces (e.g. outflow pause for listed tokens)
  • an expiry / sunset window
  • explicit resubmission triggers if the incident evolves beyond that envelope

The bridge freeze is an reference that fits this shape: scope limited to bridge outflows for defined tokens, objective to contain while the DAO determined next steps, expiry once ratification occurred. That is concrete enough to ratify without pretending the full incident can be specified beforehand.

On the non-powers / Guard point, I agree with your clarification. If the SC is purely ratifying, then the non-powers belong at the framework level, not as SC technical constraints. My underlying point was about wherever a constrained operational surface does exist, it should be bounded by design. In the Gnosis context, the bridge is the clearest place where that kind of hard constraint may be feasible. Elsewhere, an action registry may still be useful as a review artifact even if it is not enforced by a single Guard.

One related point on operational surfaces is that recent incidents pattern are increasingly dominated by access control failures, may involve insider compromise or social engineering of one or two individuals. This is relevant to how any operational multisig in the framework is configured.

A 2-of-n threshold requires compromising only a single line of communication between two signers. A 3-of-n threshold requires compromising three lines. The combinatorics (n(n-1)/2) is 2 signers need 1 line, 3 need 3, 4 need 6, 5 need 10, etc.

A threshold of at least n/2 + 1 from a signer set of 5 or more makes the coordination cost of compromise meaningfully harder. Thus, where the framework touches operational surfaces, I would recommend the threshold design reflects this esp in the wake of recent postmortems.

signers
signers552×412 23.5 KB

Finally, an additional reason I care about making these boundaries explicit beyond improving governance legibility is that they change the eventual insurability of decentralized systems. A protocol with pre-defined action surfaces, bounded authority, and reviewable evidence is materially different, from an underwriting perspective, from one that relies on improvisation. That is not the main reason to build the framework, but it is an important downstream consequence for the ecosystem.

TLDR; I will compress my answer as such:

  • Balancer was informative, but not a safe default timing assumption
  • speed should dominate the first containment
  • ratification is still valuable, but it should usually ratify bounded partial plans rather than pretend a complete plan exists upfront because in reality “plans are worthless, but planning is everything.”
  • framework-level non-powers still matter even if the ratifier is not the actor with direct execution capability.

Happy to keep helping as the GIP gets closer to publication.