A Framework for the Future

[SCBuergel]

From recent forum discussions it feels clear that we need to collectively define the framework that we want to guide us in case of any future on-chain incidents like the recent Balancer exploit and resultant chain forks.

I’d like to offer my time and input to support this initiative, based on my understanding and experience, but also just because the values of credible neutrality, transparency, and governance are absolutely vital to me.

I’d like to start with an open consultation period, and encourage everyone to share their perspective. I strongly encourage you to do that in public by commenting against this post but, if you’re uncomfortable with that, then you’re welcome to contact me and schedule a call. I can anonymise and share back here so it remains in the open. The AMA on the 7th of January will also be a good space to talk through some of the key considerations and exchange ideas.

After about a month of input – late January – I will start to draft a framework. We’ll refine it together and, if appropriate, it will be submitted as a GIP for your approval.

Within this process we need to agree if and when we feel an intervention would be justified. If we feel that we should intervene, then we should also define the criteria that would need to be met to justify it.

Key topics for consideration within this include:

• The problem space of credible neutrality vs risk for users
• Technical suitability / feasibility and futureproofing
• Parameters and processes
• Transparency and accountability vs security

Whatever your thoughts about what has happened so far, please work with us now. This is how Gnosis DAO sets the direction and gives clarity to our node operators.

We can’t turn back time. But we can define the future.

Please comment below and let’s get the process started.

[e3o8o]

Lovely to see this conversation started, @SCBuergel !

I’ve been tracking this “safety vs. immutability” tension closely and actually raised the need for a framework like this, I am calling it the “Native Compliance Framework” (updated_name: Legitimate Intervention Framework) right now (https://x.com/elemoghenekaro/status/2001917593519628373?s=20). It has become increasingly clear that “improvisational” governance during crises is not sustainable for institutional-grade networks.

To that end, I established the Native Compliance Framework (NCF) initiative and created this repository to prepare an initial manuscript.

My co-author (Dr. Nimrod Talmon) and I are also finalizing an academic paper titled “Legitimate Overrides in Decentralized Protocols.” We are developing a Scope x Authority Matrix to classify these interventions, and we view the Gnosis Chains approach as a critical case study of the Global Scope / Governance Authority quadrant (what I’m calling a neofinance model). These names are mostly working titles at this point

Our research suggests that legitimizing these interventions requires moving from “binary” thinking (Halt vs. Nothing) to a Hierarchy of Precision:

1. Network Scope (Chain Halt - “Nuclear Option”)
2. Asset Scope (Token Freeze)
3. Protocol Scope (dApp Pause)
4. Module Scope (Feature Pause)
5. Account Scope (Targeted intervention)

We are perfectly aligned with this rigorous approach so I would be very happy to jump on this next week to share findings and discuss how they might inform the specific criteria Gnosis is developing…

I will share more details here by next week!

[mrtdlgc]

I will chime in later with a detailed reading touching on the pillars of credible neutrality on establishing a framework for Gnosis specific issues.
However, I felt obliged to just chime into your Compliance Framework and call out its underlying colonial foundations in its formation. This framework you are offering reeks of legitimizing censorship, an extension of ostracization practices of what we see in the broken “traditional financial systems” that solves nothing other than being used as a tool to punish those who are not aligned with the colonialist values, and even adding a hierarchical definition of who to punish and at what scale.
This is neither decentralized nor aligned with censorship resistance that is one of the core values of Gnosis as an entity.

[TheVoidFreak]

@e3o8o Thank you for taking up the initiative here!

I was a bit struggling with where exactly to start and how we might be able to work efficiently on this^^ → Github seems like a good solution, specially for devs familiar with it.

Generally interested non-devs may also use github over the interface and give feedback.
However, one important thing is the synchronization of the community, so that we don’t make the same mistake again that we have sub-community finding a solution where the rest is unaware there was even a process going on.

As far I can see there are multiple angles from where community members may interface with the Gnosis Community:

• this forum here
• a discord group
• Telegram group
• I don’t think that X counts as community channel^^… let’s ignore this for now

What else are the various angles Gnosis community members are connected?
How may we sync them up with the process?^^

[e3o8o]

Thank you for the feedback! I agree that any framework in crypto must be shaped by the community, not a select few decision makers. The work so far is intentionally preliminary as a collection of data points meant to map the problem space and clarify what an intervention framework should aim to address.

While intervention can feel antithetical to immutability, almost a Chekhov’s gun baked into the system, I will argue this work is fundamentally pro-decentralization. The attempts is to formalize intervention from a community perspective rather than leaving it implicit or opaque.

Today, about 1/5 blockchains already have some form of intervention mechanism, yet there are no formal rules or broad awareness around when or how these tools should be used legitimately. I hope you’ll have a chance to review the work and share your input, so we can build a framework that works not just for Gnosis as a pioneer, but for the broader crypto ecosystem.

Given the rising frequency of hacks and the declining cost of attacks (accelerated by AI), my view is that security must become preemptive rather than reactive. Hackers are armed; defenders should be too

[TheVoidFreak]

@mrtdlgc

colonial foundations

@mrtdlgc

an extension of ostracization practices of what we see in the broken “traditional financial systems”

@mrtdlgc

colonialist values

There is no relation to “colonialism” here - it seems a bit like a far-fetched… It does not convey any helpful meaning - at best it is confusing at worst it leads to unjustified positive or unjustified negative reflections inside people who are invested in certain political ideologies.

Criticism of any sorts may be better expressed neutrally by best effort of precisely describing it:
What is the problem you see there?

I can understand the aversion of “legitimization of censorship” and this is exactly one core component here that will face further hot debate - don’t worry about that, this spirit is well alive in many of us ;-).

However - we are confronted with an imperfect world as you can see with the situation we faced recently.
So I think it is good to become more aware of the risks. And based on that we can discuss how various approaches may look like. First we need to get the process running - no need to be scared of premature conclusions

[mrtdlgc]

@TheVoidFreak

What is the problem you see there?

Okay, let me be more precise in my wording, then. I thought it would be obvious for a scholar of humanities to make the connection to colonialism and what constituted the practices of it when you provide a hierarchical framework of censorship to be enacted under the guide of compliance.

The Compliance Framework discussed by @e3o8o et.al. basically takes it at face value that we can always just implement some kind of a punishing action that can target various levels of entities. It is what I mean by the extension of colonialism and what we see in today’s foreign policies utilized through sanctions, ostracizing an entire group of people regardless of their affiliation to the “defector”. We see these being implemented in traditional finance through very much error-prone algorithms such as KYT. This is being used as an extension of the same ideology that led to colonialism in the first place by nature indicating that “those people do not know how to even transact, those filthy lowlife motherfuckers and we have to teach them the right ways”.
And working on a “hierarchical precision” model, the proposed framework simply considers censorship is a given and we should definitely adopt it at different levels without touching upon the core issues that leads to these situations where we have to collectively react as it happened in the recent hard fork case. The framework also suggests moving away from the “binary” thinking whereas doing so in a way that doing nothing and preserving immutability is always secondary while in the past, we have again collectively worked on better remediation solutions, for instance, in the case of the Agave hack that I was personally impacted losing more than 80% of my net worth.
Anyways, let me not divert too much away from the main question of why I specifically used the term “colonialism”.
Anyone who studied the aftermath of “decolonization” would see that it was merely a face-saving fake practice by the colonizers at the United Nations, and during the post-colonial period, we still see practices that are literal extensions of the idea. And colonialism was not only covering what the European powers were doing in Africa, you could even see the practices of it in the “modernization” of especially in the Ottoman and Japanese societies where the same powers were “teaching the right ways”, and today, the sanctioned groups of people are the ones who are seen as inferior; and the hierarchy of precision here is an open-ended way to sanction/censor individuals from access to finance. So, unless we actually define the specific behaviors that should not go without being punished, it is ready to be used as a tool to ostracize individuals who we believe are not “good” enough.
Even so, the framework that Gnosis needs is actually designing the playground as fairly as possible in such a way that we do not create single points of failures as in the case of the recent Balancer hack, and it needs impartiality from Gnosis side to not favor protocols over others because they are “low-risk DeFi” or because they are “essential to the operations of a Gnosis affiliated business such as Gnosis Pay”.
The recent Balancer hack is partially was the result of that as KPK, whose service contract was terminated after the incident not very surprisingly, was favoring building the liquidity on a protocol where they had some sort of conflict of interest that made the issue a compelling one to led to a very critical decision, even setting a precedent for a possible future coercion despite it being a collective decision by the node runners. But I will talk about these when I have a clearer mind.
I hope, at least, I was able to make it more clear for everyone what I did not like about the proposed Native Compliance Framework though.
Sorry, I do not use LLMs to create text for me It is a little bit fragmented and not as structured for the reduced attention span, but once you read it twice, you will get the gist of it.

[e3o8o]

You’ve done a great job articulating your POV, thanks for taking the time to share it in detail. This is very valuable input for the framework. At its core, the goal is to move from reactive responses to proactive measures that are grounded in clear rules and guidelines. It is feedback like this that help clarify what should be emphasized and what can be removed so we arrive at a community-approved approach to proactive security

[TheVoidFreak]

@mrtdlgc

So, unless we actually define the specific behaviors that should not go without being punished, it is ready to be used as a tool to ostracize individuals who we believe are not “good” enough.

I guess everyone here agrees, that this has to be made impossible.

[TheVoidFreak]

After checking through the repository of @e3o8o I arrived at the conclusion that the foundation best fits as a data analysis fundament - while it naturally lends itself to also explore the ways these incidents had been “stopped” I think it is not the optimal place for directly discussion mitigation of such.

I have a suggestion for a baseline and maybe we create a shared document somewhere to generally build on that. If requested I can do it (in my own way).

Targets:

• There cannot be any mechanism ever implemented in the blockchain which interferes with transactions no matter on which basis.
• Prevention via preemptive detection however there should be no feasible angle to unjustified and untruthfully “flag” or “verify” a contract or UI.
• On top of contract verification and “audits” we need some sort of extended(continuous forever) exploit-screening on used contracts and add this to etherscan/gnosisscan flag deprecated/dead/exploitable contracts.
• For the user-interfaces we also need another strong “verification” line. Easy verification for users to check if they are dealing with an UI verified by many parties to not contain malicious code. Or a new altered unverified version.
• Define the way how to deal with discovered vulnerabilities and issues.
• Define the way how to deal with visible ongoing exploits.

Some of my Opinions

A blockchain “freeze” and hardfork can be a response to an existential threat that is being acutely exploited. It is clear that this causes massive damage to the whole ecosystem and thus there must be obvious markers which make it an “existential threat” and the validators need verifiable proof of the severity of this existential threat to reach the obvious consensus fast without coercion.

However it is not clear if this is really a good thing. Obviously validators are coercible as we now have a precendence with the latest hardfork - as soon as there is a communication line to a large majority of the validators this is the case - this is in fact a technical vulnerability to a great social engineering attack. The response of the majority of validators is what we have to “trust” this erodes trustlessness. To give the validators the task to be responsibe to a kind of emergency-situation. Is solidifying this trust dependence.

So in any case I strongly recommend to first and foremost work on the prevention.

Maybe we need an own kind of blockchain which simply deals with attestations of security qualities of code. Or attestation of existence of a bug/vulnerability. Should be mechanically verifiable.
Whoever finds the first exploit receives a huge reward.

If this kind of prevention works well - then any way of damage control on the running blockchain should be made impossible to close this angle of corruption.

[mfw78]

Thank you @SCBuergel for opening this consultation. I would like to contribute some observations on a dimension that may be worth including in the framework: organisational resilience and human factors.

@e3o8o

It has become increasingly clear that “improvisational” governance during crises is not sustainable for institutional-grade networks.

This captures something important. If Gnosis determines that intervention capability is appropriate, that capability needs to be designed – not improvised. Improvisation is often a symptom of under-resourcing.

@e3o8o

security must become preemptive rather than reactive

@TheVoidFreak

I strongly recommend to first and foremost work on the prevention

I agree. But whether the focus is prevention or response, both require sustained investment – in tooling, in monitoring, and in the people who operate them.

The current context

This framework is being developed at a moment when teams have responded to a series of incidents in quick succession. That context matters. If personnel are already stretched – carrying accumulated fatigue, deferred leave, and backlogs from recent events – then any framework that assumes they can simply respond to the next incident is building on a fragile foundation.

It is worth asking: what is the current state of the people who would be called upon to execute this framework? If capacity is already running thin, that is not a criticism of those involved – it is a signal that the organisation needs to invest in recovery before the next event, not just in processes for when it arrives.

Human factors as a framework consideration

Any intervention framework that assumes personnel will be available to execute it needs to account for human factors. High-reliability industries – aviation, nuclear power, emergency medicine – have long recognised that technical capability alone is insufficient. The framework should consider:

• Headcount: Sufficient depth to allow rotation during extended operations
• Surge capacity: Retainers, partnerships, or standby arrangements
• Training: Regular exercises, documented runbooks, clear escalation paths – and specific training in human factors such as communication under pressure, fatigue recognition, and structured decision-making
• Sustainable baseline: Teams that are chronically stretched have reduced capacity to respond when needed. Recovery time between incidents is not a luxury; it is a prerequisite for reliable performance.

The aviation industry calls this “just culture” – the principle that safety depends on honest reporting, and honest reporting depends on distinguishing between systemic failures and individual culpability. The objective is to learn, not to punish. This principle might usefully inform how post-incident reviews are conducted.

The accountant’s question

There is a straightforward way to frame this: if Gnosis wishes to maintain intervention capability, the cost of maintaining that capability should be budgeted explicitly. This includes:

• Internal headcount with appropriate depth
• External retainers or partnerships with security firms
• Comprehensive bug bounty programmes that incentivise responsible disclosure across the full stack
• Training and exercises
• Recovery capacity: Time and resources for teams to decompress between incidents

Treating emergency response as an externality – absorbing the cost through goodwill and overtime – creates fragility and deprives the organisation of the information needed to make informed resourcing decisions.

@SCBuergel

We can’t turn back time. But we can define the future.

Part of defining that future is ensuring that whatever framework is adopted, the people who will be called upon to execute it are set up to succeed – not just in terms of tools and processes, but in terms of sustainable working conditions and appropriate training. That starts with acknowledging the current state of those teams and investing in their recovery.

[e3o8o]

@SCBuergel thank you again for initiating this consultation! Following up on the discussion, I am submitting the following structured proposal for legitimate intervention criteria.

tl;dr

The key finding from researching emergency governance across 166 blockchains is that 21% already have intervention capabilities, but most lack transparent criteria for their use. This is a proposal for:

1. Hierarchy of Precision — Graduated response levels (Network → Account)
2. Legitimacy Conditions — Transparency, Proportionality, Accountability, Due Process
3. Optimistic Freeze — Fast action with DAO ratification

---

The Problem (Data-Backed)

Finding	Source
$91.3 billion in crypto losses (2014-2025)	LIF Database (759 incidents)
21% of chains have freezing capability	Bybit Security Lab (Nov 2025)
AI agents can execute 55.8% of 2025 exploits	Anthropic Red Team (Dec 2025)
Exploit potential doubles every 1.3 months	Anthropic

The implication is that pre-defined intervention criteria are necessary to respond to AI-accelerated attacks without improvisation.

---

Proposal: Hierarchy of Precision

Instead of binary thinking (Halt vs. Nothing), define graduated levels:

Level	Scope	Example
1	Network (Chain Halt)	Berachain Nov 2025
2	Asset (Token Freeze)	Sui Cetus freeze
3	Protocol (dApp Pause)	Balancer pool pause
4	Module (Feature Pause)	Swap disabled only
5	Account (Targeted)	Attacker wallet blocked

The Principle behind the Hierarchy of Precision is to use the least restrictive intervention that achieves security.

---

Legitimacy Conditions

For any intervention to be legitimate:

1. Transparency - Criteria documented before use
2. Proportionality - Scope matches severity
3. Accountability - Clear authority, penalties for misuse
4. Due Process - Appeals mechanism exists

---

Optimistic Freeze Model

Anomaly → Emergency Council (fast) or a Sentinel → Immediate Pause
                                                        ↓
                           DAO Vote (24-48h) ← ratify or revert

• If ratified: intervention confirmed
• If reverted: council members may review

---

Addressing Concerns

@mfw78’s human factors dimension:

• Completely agree! “Improvisation is a symptom of under-resourcing.”
• A framework without resourced teams to execute it is fragile.
• I support explicit budgeting for:
  • Headcount with depth (rotation during extended ops)
  • Surge capacity (retainers, partnerships)
  • Training & exercises (including fatigue recognition)
  • Recovery time between incidents
• The “just culture” principle from aviation is directly applicable here

This proposal makes everything public and contestable.

• 21% of chains already freeze. This framework seeks document and bring accountability to the space
• GnosisDAO is pioneering the path for a formalised system the industry can adopt or adapt

On TheVoidFreak’s point on syncing: you’re right that coordination across forum/discord/TG is essential! Or a single canonical document (github) linked from all channels. I have also created a google doc here for anyone to sync up, critique, drop comments and suggest improvements, and ask questions, all of which will hopefully inform the final drafted framework from @SCBuergel and GIP draft

Friederike’s AMA comments (Decision Parameters):

• I have added a section including some specific parameters mentioned by Friederike (exploit type, protocol maturity, audit status, etc.)
• These factors are critical for determining proportionality within the proposed Hierarchy of Precision.

---

Proposed Next Steps

1. Review this framework and provide feedback in this thread
2. Integrate all or part into the working group’s framework
3. Draft GIP formalising the Framework
4. Define Emergency Council or other [sub]governance body composition or sentinel and authority

Looking forward to building this together!

---

PDF: gnosis_framework_response.pdf

[e3o8o]

gm everyone, I am sharing this follow up about the magnitude of power for an Emergency Council (EC) in the proposed framework. The detailed document is in the repo provided as a structured technical extension with possible paths for discussion by the DAO.

tl;dr

The EC is a scoped responder for Gnosis Chain. It can only execute pre-approved actions from a defined registry, and those actions expire unless ratified by the DAO. The principle is to design a framework that works well with the DAO’s current operating system.

---

What the EC should be able to do (scoped)

The Emergency Council would have bounded authority to execute specific, pre-approved emergency actions:

• Bridge-scope: Trigger pre-approved bridge outflow freezes for defined tokens (precedent: Bridge Governance Board freeze on Nov 3, 2025)
• Protocol-scope: Pause specific DAO-controlled modules where GnosisDAO is the admin (e.g., standard DAO infra)
• Account-scope: Initiate targeted transaction restrictions only if a pre-existing mechanism has been adopted via governance and client adoption
• Reporting: Publish an incident hash/evidence bundle and open the ratification window for public transparency.

What the EC should NOT be able to do

To preserve the chain’s credible neutrality and property rights, the EC explicitly cannot:

• Overwrite arbitrary state,
• Move user funds, or
• Change protocol rules unilaterally: Any change to consensus or execution rules requires validator adoption and/or a hard fork.

---

Technical Ground and Implementation Path

As stated earlier, the principle seeks a design that works with GnosisDAO’s current operating system. Gnosis already has scoped intervention surfaces that this proposal extends. For instance, precedent from the Bridge Governance Board (Nov 3, 2025) and the Validator Coordination (Dec 22, 2025 recovery) which followed during the Balancer incident.

The fastest, least invasive path of implementation appear to be via the use of Safe Guards to enforce an “emergency action registry.” An approach that constrain the EC’s authority without requiring any changes to the underlying protocol rules.

• A Guard contract checks transaction parameters before and after execution.
• It only allows the EC Safe to call pre-approved (contract, selector) pairs.
• All attempts and executions are logged onchain for full transparency.

All feedback for improvement are welcome!

PDF: gnosis_framework_response_technical_extension.pdf

[SCBuergel]

Hi all, firstly a big thanks you to @e3o8o, @mrtdlgc, @TheVoidFreak and @mfw78 for your thoughts, discussions and ideas!

I see from the discussion this far that your takes are generally rather non-interventionnist in nature, do I read that correctly?

I reached out both on X and on TG to try to see especially if there are more pro-intervention views from the other side here as well.

If there are additional thoughts, clarifications or changes, please keep them coming. I will circle back probably next week for specifics, maybe a community call to get us further and potentially draft a proposal then.

[mfw78]

No, this is incorrect. The position I presented above is neither interventionalist or non-interventionalist in nature. It’s that either must take into account human factors, which the response to the Balancer Hack demonstrates a lack of understanding of these factors and/or mitigation of these factors. People were asked to do things of which they were not resourced to do. For any actions, the organisation(s) should be appropriately resourced, and procedures should be in place to handle such.

[serenita_luca]

Hi!

I wanted to share my personal views and input here. By “network-level actors” in the text below, I’m referring to node operators but also other entities that affect on-chain operations, like bridge operators.

Future on-chain incidents and interventions

I believe Gnosis ecosystem participants should continue taking measures that prevent on-chain incidents from occurring in the first place. Protocols/DApps should not rely on network-level actors stepping in to save their users, and instead continue primarily relying on industry best practices.

In my opinion, the best possible outcome of this framework would be that network-level actors never need to step in again.

The simplest way to achieve said outcome would be to agree on a very simple framework - never to intervene on-chain. This is the easiest way to guarantee Gnosis Chain’s credible neutrality at the cost of not being able to rescue victim funds in case of incidents.

This is therefore the first question we should answer. There has been an intervention recently but that doesn’t mean there ever needs to be another one.

→ Do we want network-level actors to intervene in similar cases?

Therefore, on this point I strongly disagree with this statement from the “Legitimate Intervention Framework” that has been discussed in this thread:

The question is not whether to intervene, but how to do so legitimately.

---

Low-risk DeFi

I understand Gnosis wants to position itself as an ecosystem where low-risk DeFi thrives, and that is difficult to achieve when low-risk DeFi users risk losing all of their money through protocol exploits. This is the primary reason why the hardfork was likely even considered for the recent Balancer exploit – it affected a DeFi protocol that would, by many of its users, be considered low-risk DeFi.

If the Gnosis ecosystem indeed decides it is desirable to intervene when low-risk DeFi exploits occur, there should be a very strict and objective definition of that term (I am not currently aware of any such definition). Some of the conditions that DeFi protocols could need to fulfill to be considered low-risk:

• time test - the breached version of the DeFi protocol must have been live on-chain without a breach for at least X months before the incident
• security review test - the breached version of the DeFi protocol must have undergone security review(s) by X reputable independent firms
• TVL test - the breached version of the DeFi protocol must have maintained a TVL of at least $X for the last Y months

The point of these tests is to ensure the emergency intervention mechanism will not be abused for other purposes.

The bar should be as high as practically feasible – with DeFi protocols still taking every industry-accepted measure they can to avoid being breached in the first place. I think intervention should be considered a last resort if every other measure fails, and nothing could have reasonably prevented the incident from occurring.

Intervention mechanism

I may be stating the obvious but still, I want to make a note here that in blockchain land it is not always possible to rescue victim funds. Even if network-level actors were willing to intervene in a previously-agreed-upon scenario, this by no means guarantees they will be able to do so in time.

To stand a chance in situations where steps need to be taken quickly, some level of centralization seems inevitable. For instance, bridges need to be contacted quickly to ensure victim funds do not leave Gnosis Chain. There are many open questions here, like:

• Who is responsible for noticing a DeFi protocol was breached?
• Who should be contacted, how, and by whom?
• How should network-level actors verify a breach has occurred?
• What is the limit in terms of measures network-level actors may take during an intervention? (previous comments already alluded to this)
• What happens if the intervention fails?
• …

Non-retroactivity

There may be a desire to update this framework at some point in the future. This could be a minor parameter adjustment like an increase in the TVL test, or adding another security condition that DeFi protocols must fulfill to be considered low-risk. However, it could also be a larger change to the scope of this framework. In such cases it could be dangerous to allow a change to be retroactive - therefore I suggest any changes to the framework may only apply to future situations, not past.

---

Thank you to everyone who has joined this discussion so far.

[odysseas]

Hey everyone,

This is a very interesting discussions that I am consuming still, but I figured it’s appropriate to throw my hat in the ring.

With Phylax, we have been working for a bit now on a protocol with the very basic premise on “how to make the network itself prevent hacks”. After some iterations, we ended up on a quite simple design, which I would like to very briefly describe, if anything to showcase what’s the state of the art.

The core idea is that hacks originate because business logic and protocol logic diverge, for some very narrow input of transactions. These transactions or exact inputs/state are very hard to identify with testing and/or audits, which is why they are constantly missed.

Well, what if protocols themselves had the ability to define “what a hack is” and then the validators prevented any transactions that realized that state, if they ever came on the network. In practice, you can imagine it as a soft-fork of the network, with now developers having access to a slightly modified EVM that enables them to define invariants, which are checked whenever a transaction interacts with their protocol.

It doesn’t give any party (validators, dapps) any new power they don’t already have, but it gives the dapps affordances to better define “what a hack is” (better than simple require statements) and then a way to communicate that to the network validators.

As such, there is no breach of “neutrality” as the validators simply enforce the invariants that have been defined by the dapps themselves. Because we talk in terms of invariants, and not root causes, this is much simpler for protocol engineers to reason about and express, as they already do when they are coding their protocols. Identifying the “what” is quite easy, but identifying “how” that thing can be realized is the hard thing.

For decentralized networks like Gnosis, this can be applied in two ways:

1. All validators run the “sidecar” that enforces these invariants and effectively the new protocol is enshrined into the core Gnosis protocol. Transactions now have new validation rules and transactions which violate the invariants effectively are no longer protocol compliant.

2. Some validators run the sidecar and then dApps can easily choose these validators to sequence their transactions (Application Specific Sequencing or Application Control Execution). dApps can trust that the validators perform their duties, thanks to either crypto-economic incentives (hacks are provable on-chain) or due to computational-integrity guarantees (TEEs). A social layer trust can be a good starting point and then iterate to remove trust assumptions.

The above protocol is already live on Linea with some trust assumptions, as it’s the first iteration (we have to start from somewhere). We want to remove as many trust assumptions as possible, always in coordination with our users.

You can read our whitepaper, which describes the above mechanism in a bit more abstract terms and offer a better idea of the end-game.

TL;DR

• It is possible to vastly improve the security of dapps by offering better affordances in the protocol
• It is possible to perform this kind of improvement by overlaying a new protocol on top of the existing, minimizing upgrade complexity
• You can have such increased security without vastly changing the trust assumptions or allowing certain parties to exert control over systems
• The above protocol can be expanded for other use-cases, such as protecting DeFi dapps against market volatility ( like traditional circuit breakers work in TradFi exchanges)
• The above protocol is NOT censorship, because no party chooses arbitrarily what transactions are good or bad. Hacks are based on pre-defined rules (assertions), define by the dApps themselves, which already have such a power given they dictate their business logic

Final Note

We have been thinking as well about managing contagion with a rapid-response protocol, expanding on what we currently have. The challenge here, is that a sophisticate attacker can perform actions atomically (hack, swap to bridge), giving essentially no time for any mitigations to take effect, which is why most monitoring platforms fall short of actually preventing hacks in the first place. We are currently exploring designs for the protocol we described above, which would allow dapps to voluntarily participate and effectively “be disconnected” in case a hack happens, to limit the spread of contained assets. If that’s interesting, please reach out.

[thewanderingeditor]

Thanks for this @odysseas. I’d need to look into it more fully (could you update the whitepaper link? I think it’s wrong), but my initial question is whether a system like this alone is sufficient. I do see that it’s very beneficial for dapp developers to be able to define these invariants, and at least at first blush agree with your arguments with regards to neutrality. I’m just wondering how this would actually play out, and how this helps with securing funds in dapps which are already deployed.

How, for example, would this have prevented the Balancer exploit which kick-started this discussion? If it could have been used to retroactively protect Balancer v2, then great. But if it would need a new version of Balancer, then we’re looking at a different issue. Balancer v3 already existed at the time of the exploit, but people didn’t or couldn’t move their assets there.

(Which is not to say that failure to provide coverage to Balancer v2 would be a failing of Phylax: just that there does seem to be an appetite for the kind of mitigations applied in January, just done differently, or more transparently.)

And while I do find something like Phylax appealing, there’s then the question of how developers use it. I am slightly sceptical that these invariants will be all that easy to define and communicate to users. We would I think be back to @SCBuergel’s crusade on establishing a culture of standards-setting, which I find very worthwhile but likely to be slow. I wonder if the community feels it needs some other safeguards in the meantime, or indeed in general.

[odysseas]

1. Whitepaper was written a while back and talks about a more abstract version of the system, while our docs are more about the current state of the system. GitHub - phylaxsystems/credible-layer-whitepaper: We introduce the Phylax Credible Layer, a novel blockchain security mechanism designed to prevent and mitigate hacks in decentralized appli- cations by integrating at the network’s base layer.
2. The system can be used retroactively. dApps can just register assertions for the addresses. We took a balanced stance between ease of use / adoption and decentralization, so we are handling the whitelisting of protocols.
3. Assertions are easy to write by developers, because they already know (more or less) the invariants of their system (that’s how they do a lot of the testing). An auditor can help them with a final check. Please note that we are actively working on improving the syntax and improving affordances, so the current syntax of Assertions is the worst that it’s ever going to be.
4. Regarding end-users (consumers), we are also working on a number of features to make the assertions more easy to understand, and generally surface the various risks that exist with Protocols.

I appreciate the kind words for our project. We have been working hard, in a niche that is very challenging, because we deeply care. This is not only a business, but a passion project for us, so such comments are deeply appreciated.

[e3o8o]

Synthesis for the Framework

@SCBuergel, @mfw78, @serenita_luca, @odysseas, thank you for the depth of this thread! I have followed closely and have found the exchange here highly informative so I wanted to share this synthesis as we approach its next phase led by the Gnosis team. Also I thank Sebastian again for initiating this conversation and being very responsive in the DM!

I think the discussion has surfaced three complementary axes we can make concrete:

1. Prevention primitives (“make the network prevent hacks”)
2. Institutional recourse / response (what happens when prevention fails)
3. Human factors and resourcing (whether any framework is executable in practice)

1) Prevention Track (Consensus leaning)

Building on @odysseas’ Phylax notes: a credible-layer style approach offers a compelling pre-execution prevention path where protocols define invariants/assertions and validators (or a sequencing layer) enforce them.

• Value: We move security from reactive monitoring toward protocol-native prevention
• Neutrality posture: Rules are pre-defined by protocol teams (not ad hoc human judgment)
• Open questions (worth explicitly scoping): retroactive coverage for already-deployed contracts, trust assumptions / rollout model, and UX for surfacing assertions to users

I’d suggest we treat this as a first-class workstream regardless of where we land on intervention.

2) Decision Tree: Do We want Network-Level Intervention Capability at all?

I agree with @serenita_luca that the first-order question is:

Do we want network-level actors to intervene in similar cases?

From there, the framework can be structured as an explicit decision path:

If the answer is No

• Then the “framework” is primarily:
  • prevention standards (secure-by-default expectations)
  • monitoring + incident coordination without onchain intervention powers
  • post-mortems, disclosure norms, and ecosystem-level hardening

If the answer is Yes, but extremely narrow

• Then we should define a strict, non-ambiguous intervention regime:
  • Eligibility gates (e.g. protocol maturity, audits, TVL / system importance) as suggested by @serenita_luca
  • Least-restrictive scope first (account/module/protocol before anything network-wide)
  • Bounded authority (i.e. pre-registered action registry; no arbitrary state overwrites; no moving user funds)
  • Transparency + due process (public incident evidence bundle, appeals window, and clear ratification/revert mechanics)
  • Non-retroactivity for framework changes (parameter changes apply forward, not backward)

This is where LIF is intended to be useful: not to pre-decide “we must intervene,” but to help specify legitimacy conditions if the DAO decides some intervention capability remains on the table.

3) Human Factors / Resourcing (This is a Hard Gate)

Building on @mfw78: any path (prevention-first or limited intervention) fails if it assumes heroics during crisis.

We must establish a minimum bar before claiming a framework is “real”:

• Named ownership (who is on-call / who coordinates)
• Rotation + fatigue-aware escalation
• Runbooks + exercises (training, drills, clear escalation paths)
• Budgeting (explicit cost of security posture like tooling, partnerships/retainers, bounties)
• Post-incident “just culture” norms

---

Suggested Next Steps

Here are some suggested path forward:

1. In anticipation of a Community call, valuable to resolve the path forward including the decision tree question explicitly (“never intervene” vs “narrow intervention”). This will establish the default posture in strictly defined cases
2. Technical deep-dive with @odysseas (and relevant Gnosis contributors) on prevention primitives, including retroactive applicability and rollout constraints
3. Draft GIP that outline clearly separated sections for:
   • Prevention workstream (credible-layer / standards) - whether we want to pursue this as an immediate priority regardless of the intervention decision
   • If-and-only-if intervention is desired: a narrow intervention section with eligibility gates, bounded authority, transparency, and non-retroactivity

---

Data & Research Foundation

This synthesis is informed by the lif-research.org research, an empirical study of 705 exploit cases ($78.81B losses) and 137 reported interventions ($2.51B prevented).

• ArXiv Paper: Legitimate Overrides in Decentralized Protocols (2602.12260)