Version 1.1.0-beta · Last Updated: 2025-02-04
- Architecture Principles
- Testing Methodology
- Audit Strategy
- Dependency Management
- Emergency Protocols
- Access Control and Permissions
In the intricate world of blockchain and Ethereum-based projects, complexity can often be the enemy of security. The more convoluted the code, the more likely vulnerabilities are to creep in, either due to oversight or the inherent challenges of managing multifaceted systems. At Inverter Protocol, we firmly believe in the principle of KISS (Keep It Simple, Stupid). This philosophy is not about dumbing down the process, but about eliminating unnecessary complexities. By ensuring that our codebase remains as simple and straightforward as possible, we achieve several key objectives:
- Readability: A straightforward codebase is easier to read, understand, and review. This enhances the efficiency of our internal review processes and makes third-party audits more effective.
- Maintainability: Simplicity ensures that updates or patches can be implemented with minimal risk of introducing new vulnerabilities.
- Transparency: A simple and clear codebase allows our community and stakeholders to better understand our protocol's workings, fostering trust and collaboration.
Key Objectives:
- Readability: Clear code structure for efficient reviews
- Maintainability: Easy updates with minimal side effects
- Transparency: Community-verifiable logic
A modular approach to architecture is akin to building with LEGO blocks. Each module, or block, is designed to perform a specific function and can be integrated or removed without affecting the system's overall integrity. This approach offers several distinct advantages for the Inverter Protocol:
- Scalability: As the protocol grows and evolves, new modules can be added seamlessly. This ensures that the Inverter Protocol remains agile and can adapt to the ever-changing demands of the Ethereum ecosystem.
- Isolation of Issues: If a vulnerability or bug is detected in one module, it can be isolated and addressed without compromising the entire system. This containment strategy significantly reduces the potential impact of security threats.
- Flexibility: Modules can be updated, replaced, or enhanced individually, allowing for continuous improvement without extensive overhauls.
- Interoperability: A modular design facilitates easier integration with other systems and protocols. As the Ethereum ecosystem is vast and interconnected, this ensures that the Inverter Protocol can collaborate and function efficiently alongside other projects.
In conclusion, the architectural choices of the Inverter Protocol are not just about building a robust system today but about ensuring that it remains resilient, adaptable, and secure in the face of future challenges. By prioritizing simplicity and adopting a modular approach, we lay a foundation that safeguards our stakeholders' interests and paves the way for sustainable growth.
While smart contract security remains paramount, we extend our security principles to all layers of the stack through overlapping protective measures:
Infrastructure Hardening
Every service component undergoes rigorous hardening before deployment. This includes:
- Minimal attack surface configuration using industry-standard benchmarks (CIS Level 1)
- Immutable infrastructure patterns where production systems deploy as read-only artifacts
- Automated vulnerability scanning of container images and VM templates
Network Security Architecture
Our network design follows zero-trust principles with:
- Tiered segmentation separating frontend, backend, and management planes
- Strict ingress/egress filtering using next-generation firewalls
- Encrypted service-to-service communication via mutual TLS authentication
- In the future: Continuous traffic analysis for protocol anomalies
Identity and Access Fabric
The identity layer implements:
- Hardware-backed service identities for all automated components
- Just-in-time certificate issuance with short validity periods
- Automated credential rotation integrated with hardware security modules
- Multi-factor authentication enforcement for human operators
Cryptographic Controls
We employ defense-grade cryptography through:
- FIPS 140-2 validated modules for key generation/storage
- Threshold signature schemes for critical operations
Observability Stack
Security telemetry flows through:
- Unified security information and event management (SIEM) system
- Behavioral anomaly detection across cloud and blockchain layers
- Immutable audit trails preserved in write-once storage
- Automated alert correlation reducing mean-time-to-detect
This layered approach ensures that even if one security control fails, subsequent layers provide overlapping protection. We continuously validate these defenses through purple team exercises that simulate advanced persistent threats across the entire stack.
At the most granular level, we have unit testing. Each individual component of the Inverter Protocol undergoes rigorous testing to ensure it functions as intended in isolation. At this point we make heavy use of mock contracts to represent the other components of the system. This meticulous approach ensures:
- Precision: By testing each function individually, we can pinpoint any anomalies or discrepancies with high accuracy.
- Efficiency: Early detection of issues at the unit level prevents larger, more complex problems later.
Once the mechanisms of individual components are verified through unit tests, the next step is to ensure they work harmoniously when integrated into the protocol architecture. At this point we use real instances of the contracts the Module will interact with and focus on making sure those interactions happen in a correct and safe way. If the module integrates with protocols external to Inverter, this is the point where we set up a local testing environment that simulates these interactions. This ensures:
- Compatibility: Validates that different units cohesively work together without conflicts.
- Data Flow: Ensures that data is correctly passed and processed between integrated units.
E2E testing evaluates the system as a whole. We simulate real-world scenarios and user interactions from the ground up until the end of the lifecycle. Protocol integrations at this point are subjected to fork tests in the most realistic way possible. This comprehensive testing ensures:
- User Experience: Validates that the entire system functions smoothly from a user's perspective.
- System Integrity: Confirms that all components operate cohesively.
User testing exposes the system to real prospective users in an on-chain testnet environment with a basic UI prototype. This allows us to pinpoint specific User Experience issues that may have been missed during the more functional evaluations. It may also help find "last mile" issues relating to off-chain services like block explorers, backends, or interfaces. This opens the door for:
- User evaluation: Prospective users will be able to interact with the system in an environment similar to the final product.
- Offchain integrations: We can verify that the system will integrate with common off-chain services according to our expectations.
When developing our tests, we employ advanced techniques to comprehensively target the whole interaction space. We implement:
- Fuzz Testing: This involves bombarding the system with a wide array of random inputs to uncover unexpected vulnerabilities. It's akin to stress-testing the protocol against a large number of scenarios.
- Invariant Testing: Here, we define certain invariants (conditions that must always hold true). The system is then tested to ensure these invariants are never violated, guaranteeing stability and reliability.
- Code Coverage Control: We use tools to analyze the test coverage of our contracts and bring it close to 100%. This ensures that no code execution path is left untested.
- Static Analysis: By employing static analysis tools like Slither, we can quickly scan the code for known vulnerability patterns and address them early.
The blockchain ecosystem, while revolutionary, has witnessed its share of vulnerabilities. At Inverter Protocol, we take a proactive approach by:
- Historical Analysis: Studying past breaches and vulnerabilities in the space.
- Simulative Testing: Replicating conditions of previous hacks to ensure our system remains impervious to similar threats. If any historical vulnerability is identified as relevant to our codebase, we collect it in a list. Based on this list, we can verify whether we sufficiently covered it via simulative tests or other means. In essence, testing at Inverter Protocol is not a mere procedural step but a holistic strategy. By combining traditional testing methods with innovative approaches and learning from historical vulnerabilities, we ensure a robust, reliable, and resilient protocol for our users.
While smart contract security forms our core focus, we extend rigorous testing to user-facing components through a three-pillar approach:
1. Interactive Interface Validation
Web interfaces undergo comprehensive security vetting:
- Client-Side Protections:
- Automated XSS/CSRF detection via static analysis and dynamic scanners
- Content Security Policy (CSP) enforcement with strict directive whitelisting
- Subresource Integrity (SRI) hashing for all third-party scripts/stylesheets
- Wallet Integration Safety:
- EIP-712 signature validation for all meta-transactions
- Transaction simulation previews with gas estimation safeguards
- Security Analysis service integration for real-time threat detection
2. Dependency Hygiene
Frontend supply chain security includes:
- Vulnerability Scanning:
- Daily npm audit runs with severity threshold enforcement
- Commercial vulnerability database monitoring (CVEs/NVD)
- License Compliance:
- Automated license inventory generation
- Copyleft detection and policy enforcement
- Lifecycle Management:
- Deprecated package monitoring with migration roadmaps
- Cryptographic verification of locked dependency versions
3. Real-World Attack Simulation
Quarterly external penetration tests validate:
- Browser Exploit Resistance:
- DOM-based attack surface analysis
- Phishing vector identification (fake wallet connectors)
- API Security:
- OAuth2 token binding validation
- Session fixation testing across subdomains
- Infrastructure Integration:
- DNS/SSL configuration hardening checks
- CDN cache poisoning resistance verification
Findings are triaged using CVSS scoring with mandatory remediation timelines based on severity ratings. All frontend deployments require passing security thresholds across these test categories before production release.
Our continuous integration and delivery pipeline implements a zero-trust model throughout the software supply chain. Build processes execute in isolated ephemeral environments to prevent cross-contamination between development branches, with each step requiring cryptographic verification of its execution context.
Artifact integrity is maintained through signed build outputs and provenance verification, ensuring only authorized code reaches production. Dependency management combines version pinning with automated CVE scanning at every stage, while binary authorization policies prevent unauthorized third-party components from entering the build process.
Access controls follow strict least-privilege principles - human operators require multi-factor authentication and time-bound approvals for deployment actions, while automated systems use short-lived credentials scoped to specific environments. All configuration changes undergo mandatory peer review with immutable audit trails preserved in a dedicated security log.
Monitoring systems track pipeline metrics against behavioral baselines, triggering automated lockdown procedures for anomalies like unexpected build durations or resource consumption patterns. Failed security checks initiate incident response protocols that halt deployments until manual verification completes.
Audits serve as critical checkpoints in blockchain and Ethereum-based projects, providing external validation of the protocol's security and functionality. At Inverter Protocol, we view audits not as a mere formality but as an essential component of our commitment to transparency and security.
Recognizing the diverse nature of potential vulnerabilities, we employ a multi-layered audit strategy:
- Professional Auditing Firms and Solo Researchers: Engaging reputable third parties ensures a thorough and unbiased review of our codebase. These experts bring a wealth of experience, having audited numerous projects in the Ethereum space. When selecting auditors for our codebase, we look for teams and researchers that can provide the most value with their insights: We not only look at their history but also review their latest audits to ensure the quality standard corresponds to their reputation. We particularly value teams or researchers that have reviewed other modular protocols, since they can bring insights gained from other codebases into their evaluations.
- Community Auditors: Beyond professional firms, we tap into the collective wisdom of the community. The more eyes on the code, the more likely we are to find vulnerabilities. Platforms like Hats.Finance or Code4rena offer a unique opportunity: They expose our protocol to a community of auditors who approach the code from different angles and can uncover vectors that might be overlooked in a traditional audit setting.
- Bug Bounties: As important as it is to thoroughly review the code before deployment, it is also vital to offer a clear path for whitehats to report discovered vulnerabilities. Platforms like Immunefi incentivize the community to disclose bugs in a responsible way, enabling fair payouts while minimizing security risks.
Security in the digital realm is not a one-time achievement but an ongoing endeavor. Auditing code too early can be a security risk in itself since spending audit time reporting "low-hanging" bugs can prevent auditors from diving deeper and finding more hidden issues. As such, we subject our code to a continuous auditing system:
- In-development review process: We try to catch most bugs as early as possible. In addition to our regular testing architecture, we regularly review our code with security experts.
- Pre-release audit: Before deploying any code, we audit it and resolve any issues that may arise.
- Periodic Reviews: Even post-launch, we schedule regular audits to ensure that, as the protocol evolves, its security posture remains uncompromised.
- Post-Update Audits: Every new module, significant update (major version), or addition to the protocol undergoes a fresh round of audits to ensure that new features or changes don't introduce vulnerabilities.
Every integration with external protocols introduces a potential security risk. While some of these (like oracle attacks) can be pinpointed and controlled, others cannot reasonably fit into an audit scope and arguably rely on trusting the external code to be secure. To minimize the security risk these integrations entail, we apply the following principles:
- Minimize reach of integration: While the functionalities the integration offers may be a core component of a module, we keep the interaction surface as limited as possible to that module. This ties into our general "separation of concerns" guideline when writing modules.
- Prioritize reputable protocols as integration partners: When collaborating with new integration partners, we strongly favor security over recentness. We evaluate how long the other protocol has been running, the total amount of funds (or similar) managed, the existence of high-quality audits, and the history of previous security incidents.
Post-audit, our commitment to transparency comes to the fore:
- Detailed Reporting: We make audit reports publicly available, detailing findings, potential vulnerabilities, and the actions taken to address them. Findings (and their corresponding fixes) that occur outside of regular audit reports are referenced in our wiki.
- Community Engagement: We aim to actively engage with our community post-audit, addressing questions, concerns, and feedback. This two-way dialogue ensures that our stakeholders are always in the loop and reinforces trust.
In conclusion, Inverter Protocol's audits testify to our unwavering commitment to security and transparency. By embracing a comprehensive, multi-layered, and continuous audit strategy, we ensure that our protocol meets the highest standards of security and reliability in the Ethereum ecosystem.
While not currently certified, we align our security practices with leading standards including:
-
Penetration Testing Standards:
Regular external testing aligned with Open Web Application Security Project (OWASP) Top 10 and Cloud Security Alliance (CSA) guidelines -
Information Security Management:
ISO 27001 control framework for establishing/maintaining information security management systems -
Cloud Security Specifics:
ISO 27017 code of practice for information security controls in cloud services -
Service Organization Controls:
System and Organization Controls (SOC) 2 Type II feasibility analysis for trust services criteria -
Cryptocurrency Security:
Cryptocurrency Security Standard (CCSS) Level 3 requirements for institutional-grade asset protection
This remains an active research area as we evaluate certification pathways against operational requirements.
Dependencies, in this context, refer to external protocol contracts or sources of truth (oracles) that we may have to rely on for the proper functioning of our protocol or for enhanced functionalities in our modules.
As an example, consider a lending protocol that uses Inverter modules to create a workflow that mimics a lending protocol. They can have a requirement where they want the collateral collected from the borrower to earn some passive interest via deposits into long-standing, low-risk protocols such as Compound or Aave.
Another example could be a module that requires knowledge of the current market price of a certain asset(s) to execute appropriate transactions on the blockchain. This is usually achieved using external price oracles such as Chainlink Oracles.
Now that we have established the need for dependencies in the Inverter Network, we need to formulate a security policy for managing these dependencies.
We must realize that any and all dependencies that are added to the Inverter Network module increase the attack surface, which can compromise the security of the Inverter Network. When a couple of dependencies are added to the Inverter network, that does not mean that the attack vectors increase by 2, but they increase by the sum of all new execution paths made possible via these 2 new dependencies.
Now that we understand how many attack vectors can be enabled by introducing just a few dependencies, here is a non-exhaustive list of measures we should take to keep the Inverter Network as secure as possible. While there is no exact science to determine how dependable a particular dependency is, we can use a few parameters to serve as a proxy for its reliability.
-
Non-upgradable contracts: If the contracts that are being integrated into the Inverter Network as a dependency are upgradable, then the entire Inverter Network is working on the goodwill of the upgrade admin of the dependency. The ideal scenario would be to incorporate smart contracts that are not upgradable so that a malicious or naive admin could not introduce changes in their smart contracts that compromise the security of the Inverter. Here are a few examples of upgradability being a bug rather than a feature:
- Swaprum Finance Rug
- Tornado Cash Hack
- Wormhole attacker counter-hack (upgradable Oasis contracts)
-
Audited contracts: We must ensure that any dependency added to the Inverter has been audited by at least two well-reputed audit houses (or independent auditors), with public audit reports confirming that the team has fixed all the issues found in the audit.
- It is not enough to check for the presence of audit reports and be done with it. Often, the auditors point out pathways through which the protocol can become undesirable for a user. Since this is not exactly a security bug, the protocol dismisses it by labeling it a design decision. So, it is important to actually weave through the audit reports and be aware of such edge cases or gotchas in all of the dependencies being introduced to Inverter.
-
Top-Notch Testing Suite: The testing suite of the protocol that we intend to incorporate should be held to at least the same standards that we hold our testing to. Their testing suite should include fuzz tests, invariant tests, unit tests, integration tests, mutation tests, maximal test coverage, and a list of all the scenarios that are tested in plain English.
-
Versioning of dependencies: In an earlier point, we mentioned that the potential dependencies must have been audited by reputed audit firms, and the reasoning behind that point was to make sure that the dependency contracts are safe. However, if the contracts have changed since the last audit, then bugs can be re-introduced. Therefore, we must always ensure that we are on a version of the contracts that have been completely audited. Updating the dependencies should always be under the control of the Inverter instead of any external party.
-
Community Perception/Reputation: While it is possible that many new projects may have solid teams and the best of intentions, we must try and only include protocols that have been around in the DeFi space as a protocol for at least 18 months and ideally have been hack-free at that time. As a bonus, if the protocol has a positive perception amongst the community members in regard to their commitment to security, then we can use that as another social proof of the legitimacy of the protocol.
-
Other Integrations: Ideally, we should look for protocols as dependencies if they already have other protocols that have successfully used them as their dependencies. Basically, we want to look at others and see if they have done something that we want to do.
-
Engineering Support: The actual integration of the dependencies with the Inverter modules can become quite complicated, depending on their complexity and how well they are abstracted away. In these scenarios, if we have a choice between two protocols that offer the same functionality, we should select the protocol that offers better engineering support to our team.
-
Internal Security Procedures: The team that provides the most insights into its internal security procedures regarding how it handles its protocol and also proves that it does what it says it does should be given preference as our integration partner.
-
Insurance and Risk Coverage: The team that can provide insurance coverage to our protocol to insure against any potential loss caused due to the code malfunction of the dependency should be given preference
-
Design with minimal trust assumptions: Always assume that the third-party dependency can stop working at any time and the values returned from it can be malicious. So, the design pattern around external dependencies should have minimal trust assumptions on the dependency, which means extreme answer validation and preparation for DoS scenarios.
The decision of integrating a particular dependency into the Inverter should never be taken lightly and the Inverter team must conduct their own due diligence on the project that is potentially going to be integrated into the Inverter as a dependency. This due diligence should focus heavily on threat modeling for the potential dependency, thoroughly reviewing the security audit reports for the dependency, and conducting Inverter's own security review. During our extensive research on protocol threat modeling, we came across Composable Security's threat modeling for integrating with Uniswap v4. We opine that in the future, Inverter developers/security researchers can follow the same format for carrying out their own threat modeling of a particular protocol. The report can be found here. Additionally, here are a few resources on integration checklists for various famous DeFi protocols, which have been kindly published into the public domain by helpful web3 security collaborators.
- Aave v3
- Convex Finance
- Curve v1
- Balancer
- Layer Zero
- Bridge Integration Checklist from Spearbit
- Generalized integration checklist from SCSVS
- Integrating Price Oracles: Chainlink Oracles
This is an area of interest that is still under active discussion. However, the following points/requirements were made clear from the discussions up until now:
- The license should be able to protect the project from vampire attacks
- The license should enable retail users to use the software freely, but for any commercial purposes, express consent of the Inverter Network would be required
- The license should be able to handle the cases where a competitor clones the Inverter contracts, makes slight alterations, and starts marketing it as their own protocol. Eg. A new protocol which is basically Inverter Protocol without any fees
- The license should prevent any legal overhead in cases of shared ownership. Eg. Inverter Network's partnership with Topos.
- The license should prevent any legal overhead in cases of revenue sharing with external module developers in the future.
Moreover, it was observed that it is not necessary to license the entire Inverter Network contracts under the same license, and a set of different licenses can definitely be used for different parts of the codebase. A case in point is Uniswap v4. Therefore, licensing would be done according to the future utility of each code segment.
Our dependency management strategy spans both application and smart contract layers:
Smart Contract Development
- Foundry Integration:
- Pinned dependency versions verified through cryptographic hashes
- Git submodules for direct source control of external contracts
- Automated vulnerability scans during
pre-commitprocesses and in the CI/CD pipeline
- Upgradeable Components:
- Immutable dependency contracts preferred where possible
- Timelock-enforced upgrade paths for critical integrations
- Impact analysis for dependency version changes
Application Development
- Package Management:
- NPM/Yarn dependencies locked with exact version specifiers
- Automated license compliance checks during CI builds
- Peer review requirements for major version updates
- Container Security:
- Distroless base images from approved repositories
- Image signing with Cosign for deployment verification
- Runtime vulnerability scanning via eBPF probes
The protocol should include a public and easily accessible GitHub repository (or other public-facing webpage) detailing the company's stance on different kinds of security incidents/scenarios.
For example, this repository should clearly state how many audits the protocol has gone through, at what stages, and by which audit houses. The audit reports from each of the audits should be publicly accessible.
The repository should contain the e-mail addresses of the relevant team members from the Inverter Network, who would act as the first responders to any security breach report. The team members' email addresses should be accompanied by their PGP keys so that all communication between the whitehat and the protocol happens through an encrypted channel.
The Inverter Network team's contact details should be in their own repository and on platforms that aggregate the contact information for different DeFi projects, such as OpenZeppelin’s Smart Contract Security Registry or Blockchain Security Contacts.
- Bug or vulnerability that puts users' funds at risk is discovered in your protocol's smart contracts
- Bug or vulnerability that puts users' funds at risk is discovered in an underlying protocol (which your dApp utilizes)
- Bug or vulnerability is discovered in third-party infrastructure and/or tooling used previously or currently. Examples include oracles, wallet address generators, bridges, multisig wallets, programming languages, and more.
- Bug or vulnerability is discovered by an ethical hacker, bug bounty hunter, or security researcher
- Active exploit or hack of your protocol is discovered and reported by a user, community member, or unidentified party
- Key internal infrastructure is compromised (e.g., theft of founders' private keys)
Any of the aforementioned situations would call for a swift response to mitigate the situation (Wintermute lost $160M in funds due to an address generator vulnerability, for example).
When the above conditions have been met, you have to initialize a war room to put the emergency protocol into practice. War rooming starts with assessing what happened; have you, in fact, been hacked? Once you've assessed that there has been a breach, you should pause that contract (if you have upgradeable contracts), since you don't know if the hacker has finished executing the attack or how much more could be at risk. As soon as the contract has been paused, you should assess the situation and staff your war room. You'll want at least one analyst, one person on operations, and a comms lead.
All of these functions need to operate simultaneously: the ops lead organizes and directs. The analyst stops the bleeding and conducts forensics to assess the impact, discover long-term mitigation, and determine when it's safe to unpause the contracts. The comms lead clearly communicates what is happening to the public and talks with key stakeholders in the community to maintain their support throughout the crisis.
After all these functions are in motion and the community has been made aware of the situation, proceed with publishing a clear and transparent postmortem in the following 24–48 hours, which outlines what happened, what the impact was, the specifics of the vulnerability, if a fix is in place, and how the project will prevent future attacks. The purpose of a postmortem is to communicate that you've identified and resolved the issue, that you're taking the situation seriously, and that there is a plan to prevent these events from occurring going forward.
Even with the postmortem, it's going to take time to rebuild trust. The comms lead should be actively engaged in rebuilding faith with the community, in addition to interviewing stakeholders to discover their key concerns and how they could be alleviated. They should keep the community informed about what the protocol is doing at every step and then follow through on action plans to restore confidence in the team's ability to weather any crisis.
After setting up a war room, the next step is to review the threat. This involves assessing known information to confirm the existence and severity of the bug or vulnerability. Below are some questions to guide this phase of the incident response:
- Is there concrete evidence validating the issue? Recent transactions or social media reports from affected users would be examples.
- Is this an isolated incident, or does it affect multiple components in the protocol? You want to identify domino effects that a particular vulnerability might produce.
- Are users' funds at risk? How much? The amount at stake may inform your team's response plans—for example, the BNB token bridge exploit (which put nearly $566M at risk) required halting the blockchain as a mitigative measure.
- If users' funds are safe (for now), does the incident still require an intervention?
- If users' funds are at risk, what (immediate) actions can be taken to mitigate losses?
Once enough information confirms the incident, swift action is critical to determine the root cause(s) of smart contract exploits. Members of the incident response team will likely need to collaborate on reviewing exploit transactions to understand the vulnerability.
Live debugging sessions (via videoconferencing tools like Zoom) are ideal and can be aided with the following tools:
- Tenderly Debugger
- Foundry Debugger
Certain security incidents may require immediate action to mitigate the loss of funds. This is especially the case if an exploit is ongoing or the bug is still active.
Below are some defensive actions to consider if your protocol suffers an exploit:
- Pausing smart contracts
- Upgrading the UI to reflect information about security incidents or disable specific user operations (e.g., deposits and withdrawals)
- Performing whitehat rescues (i.e. contracting ethical hackers to drain funds from vulnerable smart contracts) Taking defensive actions reduces the pressure on incident response teams and allows them to properly evaluate attacks before developing long-term solutions.
Like other parts of the incident response, tasks in this phase should be assigned to specific parties beforehand to improve efficiency and speed of execution.
Further steps would include:
- Listing EOA or multisig wallet accounts required to execute transactions
- Preparing scripts for deploying mitigative measures in advance
Transparent, reliable, and consistent communication with users is an important aspect of effective incident response. Besides raising security awareness, it protects the protocol's reputation and ensures it continues to receive support from the community.
That said, we follow rules guiding crisis communication when dealing with security incidents:
- Ensure that someone reviews all outgoing information for accuracy, and that information that could further jeopardize security efforts is not disclosed immediately.
- Avoid making commitments to remediating users' losses until all facts concerning the situation are understood. Sometimes, the magnitude of losses may be larger than realized (making previous remediation plans infeasible).
- Employ the best communication channels available. For example, communication may start with a post on our Discord server or Telegram channel before publishing an announcement on the company's Twitter page.
- Send regular updates at frequent intervals. Even if no new information is available, posting messages at intervals communicates to users that you're working to resolve the situation.
Note: This task will likely be handled by the Communications role or someone who acts in that capacity (e.g. community manager or public relations officer).
After implementing mitigative measures, you'll need to work out a permanent solution. Teams should have discovered the root cause of the smart contract hack by now so they can brainstorm a fix.
This phase could be split into several sub-tasks:
- Different war room participants (coordinated by the Strategy Lead) work on various solutions. Each solution is evaluated according to different criteria such as complexity, implementation timeline, and minimization of losses for users. Teams may need to work out disagreements and evaluate concerns from members before settling on an acceptable solution.
- After reaching a consensus, the team runs tests to confirm the patch fixes the flaw. Anvil is useful for forking blockchain state and testing contracts locally.
- The patch is reviewed (if needed) by security auditors and other developers to ensure it doesn't introduce new vulnerabilities. Another approach is to set up independent reviews using a platform like Code4rena (audit contests can be as short as 24-48 hours).
- The solution is implemented by the responsible party (assigned beforehand). The incident response plan document should include contract deployment/upgrade scripts, relevant multisig wallet address(es), and other necessary details.
The post-mortem is the final phase of the security incident response phase. Here, team members (and other relevant parties) gather to reevaluate the incident, identify other root causes (aside from those mentioned already), and share feedback on the overall incident response process. This provides development teams with useful information for preventing future exploits and improving internal security and incident response processes.
Another reason to conduct a post-mortem is to gather information for the vulnerability disclosure statement. The disclosure statement details the security incident for the benefit of users, developers, and interested stakeholders and highlights the team's actions to address the vulnerability. This way, users are aware of your team's commitment to proactively handling security issues and safeguarding users' funds.
Recognizing the invaluable contribution of the white-hat community, Inverter Protocol institutes a bug bounty program. This initiative encourages ethical hackers to identify and report potential vulnerabilities in our system proactively. We offer reasonable rewards in appreciation of their efforts, ensuring that their expertise and time are duly recognized. The program's specifics, including the reward structure and reporting guidelines, will be made available to the public, fostering a collaborative approach to security.
The Bug Bounty would ideally not be limited to smart contract security vulnerabilities but encompass all other aspects of the Inverter Network, including its web2 components, such as the front end, server security, proxy security, etc. To ensure the safety of its web2 components, Inverter Network can leverage existing legacy bug bounty platforms such as Hackerone and Bugcrowd.
While Inverter should plan to stay visible on at least one major bug bounty platform at all times, all arrangements should be made to carry out the bug triaging and patching pipeline along with rewarding the whitehat even if the bug report was submitted to Inverter on any other platform via any other means.
In the dynamic landscape of blockchain-based projects, the ability to swiftly respond to emerging threats is crucial. Our protocol is equipped with mechanisms that allow:
- Inverter-Level Pausing: This would be done in extreme circumstances where a catastrophic bug has either been discovered or is being actively exploited. If the bug exists on a module that is frequently used in a different array of workflows, Inverter Network intends to implement an Inverter-Level Pausing, where the Inverter Network pushes out a minor update to each and every Inverter module, which pauses all the contracts, until newly patched and tested contract is not re-deployed as another minor update.
- Selective Pausing: We can temporarily halt specific sections of contracts, ensuring that only the affected components are paused while the rest of the system remains operational. The pause can be limited to a certain module or a small set of modules working together. This feature allows for more precise and targeted responses to potential threats or issues, thereby minimizing disruption to the entire system.
- Full System Pause: While we prioritize selective pausing, the protocol is designed to enable a complete system halt if necessary. However, such a decision will only be made after a comprehensive governance decision, ensuring that it is in the best interest of all stakeholders.
- Automated Circuit-Breakers: On top of manual pausing mechanisms, we will implement certain automated circuit breakers where necessary. These could trigger a pause whenever a certain number of tokens are transferred out of the system or when the system is used in a non-desired way. Our range of heuristics and mechanisms includes both internal implementations and external service providers, such as SphereX.
- User Choice: It's important to note that all pausing or circuit-breaking mechanisms come 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 unpausable system.
To maintain a real-time pulse on the protocol's operations and potential threats, we're integrating a state-of-the-art monitoring system akin to OpenZeppelin Defender 2.0. Other options include Forta, Tenderly, Parsiq, and Certik. This system will feature:
- War Room: A dedicated space where our team can monitor activities, detect anomalies, and strategize responses in real time.
- Alert Mechanisms: Any unusual or potentially malicious activity will trigger instant alerts, ensuring that our team is always informed and ready to act.
Effective communication, both internally and externally, is paramount during emergencies. To this end:
- External Reporting Channels: We will establish dedicated channels for external parties, such as users or white-hat hackers, to swiftly report concerns or vulnerabilities.
- Internal Communication: A secure and efficient internal chat system, ensuring that our team can coordinate seamlessly, discuss ongoing issues, and implement solutions without delay.
Our cloud emergency protocols extend beyond smart contract protections to address infrastructure-level threats through coordinated containment strategies:
Breach Containment Playbook
Upon detecting unauthorized access, we initiate automated isolation procedures that segment compromised accounts while maintaining core service availability. This includes immediate credential rotation through integrated secrets management systems and infrastructure rollbacks using version-controlled configuration templates.
Distributed Attack Mitigation
For volumetric attacks targeting cloud resources, our layered defenses combine traffic filtering through global scrubbing centers with intelligent rate limiting that distinguishes legitimate users from malicious bots. Capacity scaling plans maintain service continuity while forensic tooling preserves attack patterns for post-incident analysis.
Recovery Orchestration
All remediation workflows follow pre-validated runbooks that prioritize:
- Evidence preservation for regulatory reporting
- Gradual service restoration with integrity checks
- Compromise root cause analysis using immutable logs
Response timelines and decision trees are regularly validated through tabletop exercises simulating advanced persistent threats across hybrid cloud environments.
Our surveillance strategy employs layered detection systems spanning blockchain and infrastructure layers:
Inverter Guardian System
This proprietary monitoring solution operates at three levels:
- Blockchain Layer Analysis:
- Processes every new block across supported networks, scanning all transaction interactions with protocol contracts
- Maintains real-time transaction pattern analysis using historical behavior baselines
- Threat Detection:
- Protocol-specific attack signature database updated with emerging exploit patterns
- External account reputation checks via integrated security APIs
- Intelligence Integration:
- Combines internal heuristics with third-party threat feeds
- Automated alert prioritization using machine learning models
Unified Security Information System
Cross-platform monitoring combines:
- On-chain event correlation with cloud infrastructure telemetry
- Behavioral anomaly detection across user sessions and API endpoints
- Immutable audit trails preserved in write-once storage systems
Operational Health Checks
Automated verification mechanisms ensure system resilience:
- Synthetic transaction monitoring across test networks
- Dependency uptime validation through heartbeat checks
- Graceful degradation enforcement during partial outages
This multi-spectrum approach enables sub-60 second detection of critical anomalies while maintaining <2% false positive rate across alert streams. Continuous validation occurs through purple team exercises simulating sophisticated cross-chain attacks.
In our decentralized digital world, governance plays a pivotal role in guiding the protocol and ensuring its safety. The Inverter Protocol is fundamentally a community-driven platform. Our governance model reflects this ethos, aiming to protect users and ensure the protocol's long-term sustainability.
While we prioritize user protection and decentralization, we also recognize the need for efficient management. Our governance mechanisms embody this balance, ensuring that the Inverter Protocol remains resilient, user-centric, and poised for future growth.
While we prioritize user protection and decentralization, we also recognize the need for efficient management. Our governance mechanisms embody this balance, ensuring that the Inverter Protocol remains resilient, user-centric, and poised for future growth. Our approach contains:
Primary Multisig
- Composition: This multisig comprises a diverse group, including members from the Inverter team, influential figures from other projects, community representatives, and advisors.
- Responsibilities: Entrusted with critical decisions, this multisig has the authority to approve critical on-chain upgrades and, if necessary, pause the entire system.
- Purpose: The primary multisig embodies our commitment to decentralization. By including external members, we ensure that the Inverter Protocol remains a public good, free from the influence of any centralized entity.
Secondary Multisig
- Composition: Exclusively consisting of Inverter team members, this multisig is more agile, facilitating swift decision-making.
- Responsibilities: This multisig is tailored for operational efficiency and handles day-to-day tasks such as managing the deployment/setup of new contracts, adding new modules to the whitelist, managing routine upgrades, and pausing specific modules if necessary.
- Purpose: While the primary multisig focuses on strategic and high-impact decisions, the secondary multisig ensures that the protocol's daily operations run smoothly and efficiently.
Protection Mechanisms for Live Contracts
- Timelock Mechanisms: For contracts already deployed, we employ Timelock contracts for major upgrades. This mechanism ensures that any significant change will only take effect after a predetermined waiting period, ranging from hours to days, depending on the severity of the change. This delay allows users to review and assess the changes, providing them an option to opt out if they disagree with the modifications. While determining the waiting period, we'll consider the urgency of actions but will always prioritize user safety.
In a decentralized ecosystem, centralization introduces inherent risks, particularly for users who should remain autonomous and not be unduly influenced by any single entity's decisions. The Inverter Protocol is acutely aware of these risks and has implemented measures to ensure that users retain control over their workflows:
- User Autonomy: The primary risk of centralization is to the user. At all costs, users should not be subject to our unilateral decisions regarding their workflows. They should have the freedom and tools to assess and respond to any changes we propose.
- Upgrade Mechanisms: While our intention is to use upgrade mechanisms for live workflows only in the case of bugs or other critical issues, we recognize that any change, however well-intentioned, can be viewed with suspicion by users. Especially for those who have significant funds within their workflow, blind trust is not advisable.
- Timelocks for User Protection: To ensure that users have time to review and assess any proposed changes, we employ a Timelock mechanism with a sufficient duration. In cases of severe bugs, we may pause the affected workflow until the bug has been addressed. However, during the active Timelock period, the owner/admin and users of the workflow retain the ability to withdraw funds. This ensures that users can assess the contents of any upgrade, and if they disagree with the changes, they can exit the workflow with their funds intact. This mechanism ensures that we cannot unilaterally access or control users' funds.
Module Replacement by Workflow Admins The workflow admin has the authority to replace modules. While this provides flexibility in managing the workflow, it also introduces a risk. The admin could potentially replace a module with a malicious one or make changes that users of the workflow disagree with, jeopardizing their funds.
To mitigate this risk, we are making use of a Timelock for Module Changes. For live and deployed workflows that contain funds, any module changes proposed by the workflow admin will be subject to a Timelock. This ensures that users have sufficient time to review and assess any proposed module replacements or changes. By implementing this Timelock mechanism, users are given the opportunity to assess any changes made by the workflow admin. If they find the changes unsatisfactory or potentially harmful, they have the window provided by the Timelock to exit the workflow and safeguard their funds.
In the realm of blockchain, the security of private keys is paramount. These cryptographic keys are the gatekeepers to assets and control within a protocol. Ensuring their safety is not just a best practice but a necessity.
Hardware Wallets - The Gold Standard
- Mandatory Use: A hardware wallet is required for any significant operation within the Inverter Protocol. The security community recognizes and endorses hardware wallets, which provide an isolated environment and safeguard private keys from online threats.
- No Hot Wallets for Critical Operations: While hot wallets offer convenience, they are susceptible to a myriad of online threats. As such, they are strictly prohibited from being involved in any critical operations within our protocol.
Multisig and Hardware Wallets - A Layered Defense While multisig provides a layer of decentralized control, as detailed in 5.1, the security of each signatory's key remains crucial. By mandating the use of hardware wallets, we add an additional layer of security, ensuring that even if one key is compromised, the protocol remains secure.
Operational Security (OpSec) Best Practices Operational security, commonly referred to as OpSec, is the frontline defense against both digital and physical threats. While on-chain measures provide robust security, it's the off-chain practices that often determine the safety of assets and operations. Adhering to the following best practices ensures a holistic security approach, safeguarding against potential vulnerabilities and threats:
- Two-Factor Authentication (2FA): All participants should enable 2FA. While many opt for SMS-based 2FA, it's vulnerable to SIM swapping attacks. We recommend using authentication apps or hardware-based 2FA.
- Robust Passwords: Use complex passwords, combining uppercase, lowercase, numbers, and symbols. Avoid using easily guessable information like birthdays or names.
- Secure PIN for Hardware Wallets: Choose a strong PIN for your hardware wallet, and avoid using easily guessable combinations.
- Physical Security: Never leave your hardware wallet unsupervised in public spaces. In addition to digital threats, physical attacks like side-channeling can compromise the wallet.
- Seed Phrase Security: The seed phrase is the ultimate backup. Never input it online or store it digitally. Instead, write it down and store it in a secure location, like a safe. Avoid common storage methods, such as notebooks, which can be easily misplaced or accessed.
- Transaction Verification: Don't blindly sign any transaction. Always compare hashes and meticulously verify the inputs, ensuring that the function and the contract address match your intentions. Be aware of known attacks that manipulate transactions during the signing process, leading users to inadvertently sign malicious transactions.
- Regular Software Updates: Ensure that the wallet software and any related applications are regularly updated. This will protect you from known vulnerabilities.
- Avoid Public Wi-Fi: Be very cautious when accessing your wallet or conducting transactions over public Wi-Fi. It is often insecure and can be a hotbed for man-in-the-middle attacks. Consider using a VPN service to further protect your network traffic from attackers within the same network.
Here are some good articles and guidelines that outline further best practices of OpSec:
Handling Compromised Private Keys In the unfortunate event of a private key compromise, especially for contract admins, the Inverter Protocol has a structured response mechanism:
- Multisig Protection: At the forefront of our defense is the use of multisig wallets for critical access control. This ensures that a single compromised key doesn't jeopardize the entire system, and the decentralized control provided by multisig wallets is crucial in such scenarios.
- Immediate Assessment: Should a compromise be detected or reported, our team will swiftly assess the extent of the potential damage. We'll determine if the ownership of any contracts that the compromised key had access to can be replaced.
- Fund Rescue: If the compromised key threatens funds immediately, we'll initiate measures to secure and rescue any at-risk assets. This could involve moving funds to a secure contract or initiating protective protocol mechanisms.
- Address Removal from Multisig: If a key within a multisig setup is identified as compromised, it will be promptly removed to ensure the continued security of the protocol. Replacement signatories will be considered based on governance decisions.
Our cryptographic material handling follows institutional-grade standards across environments:
Production Credentials
- Storage: Never persisted in version control systems, even encrypted
- Rotation: Automated through secrets manager with a 90-day maximum lifespan
- Access: Ephemeral IAM roles scoped to CI/CD job requirements
Human Access Controls
- Authentication: Hardware-based multi-factor authentication enforcement
- Authorization: Just-in-time elevation with maximum 4-hour validity
- Auditing: Key usage logs immutable in security information systems
Signing Operations
- HSM Integration: Cloud-hosted hardware security modules for automated signing
- Transaction Safety: Isolated VPC execution with air-gapped approval flows
- Key Separation: Dedicated cryptographic material per environment tier
Disaster Recovery
- Geographic Distribution: Keys replicated across availability zones
- Backup Protocols: Shamir's Secret Sharing with geographically dispersed trustees
- Revocation: Automated through centralized certificate authority integration