Emergency Protocol
In the Inverter Network, maintaining the highest security standards and swiftly responding to threats is paramount. This section describes the conditions that trigger our emergency protocol, our monitoring systems, the procedural steps we take in response to threats, and the specific mechanisms employed during these events.
What Triggers the Emergency Protocol
The emergency protocol is activated under several critical conditions that potentially endanger the platform's integrity and user funds:
Security Breaches: Any detected vulnerability or bug within our smart contracts that poses a risk to user assets.
Underlying Protocol Threats: Vulnerabilities in any underlying protocols or systems that our dApp utilizes.
Third-party Failures: Issues arising from third-party infrastructure such as oracles, wallet generators, and bridges.
External Threats: Any active exploits, hacks, or unauthorized access reported by users or identified by our monitoring systems.
Compromise of Internal Systems: Such as theft of private keys that could jeopardize control over contracts.
Monitoring and Detection
To preemptively detect and respond to threats, we employ a comprehensive monitoring system:
Alert System: We utilize tools akin to OpenZeppelin Defender 2.0, which provide instant alerts on unusual activities, ensuring that any potential threats are addressed immediately.
War Room Operations: A dedicated monitoring center equipped to assess and respond to security threats in real-time will be setup as soon as a threat is detected.
Procedural Response Steps
Upon identification of a threat, our response follows these critical steps:
Immediate Assessment: Our team assesses the extent of the breach in the War Room, determining whether and how much of our protocol is compromised.
Selective or Full System Pause: Depending on the severity and reach of the incident, we may pause individual modules or the entire system to mitigate any ongoing risk.
Selective Pausing: Targets only the affected modules, minimizing disruption to the overall network.
Full System Pause: Used in extreme cases where a widespread threat is detected.
Communication with Stakeholders: We maintain clear, ongoing communication with our users and stakeholders throughout the incident. This includes initial alerts, progress updates, and a comprehensive postmortem.
Post-Incident Analysis and Reporting: A thorough investigation is conducted, resulting in a detailed report that outlines the incident, the response actions taken, and future preventative measures.
Intervention Mechanisms
As mentioned in the Beacon Proxy Pattern section, we also use the Beacon Proxy Pattern to start our Intervention Mechanism. Should one of the Triggers be set off, then we are able to pause the implementation of all or individual contracts. This means that we set the implementation address that the beacon points to to address zero. This prevents all further interactions with the contracts that are linked to these specific beacons.
This gives us room to breathe and make cool headed decisions based on the current circumstances. When we are sure that the triggers are not active anymore or don't pose any threat, then we can either return to a normal functioning state or we update the according implementations to fix bugs or to update general features.
It's important to note that this pausing mechanism comes with an opt-out option. Some users or use cases might opt for an immutable workflow, where pausing is not an option, while others may not trust an un-pausable system. This is further explained in the Factories page.
---
For further details on our security practices and how we handle specific scenarios, please visit our Security Guidelines.
Last updated