# Welcome to Coverage! Blockchain security is a high-stakes game where one exploit can result in billions of losses. Our mission is to make Web3 safer by proactively uncovering vulnerabilities and fortifying defenses.
## 🌐 Social Media * [X](https://x.com/coverage_labs) * [LinkedIn](https://www.linkedin.com/company/coveragelabs/) * [GitHub](https://github.com/coveragelabs) * [Warpcast](https://warpcast.com/coveragelabs) # Request Form This is the starting point through which all engagements begin when a client submits a request for a quote.

Quote Request Form

## Form Upon requesting a quote for an engagement clients are taken to a [form](https://www.coveragelabs.io/quote) in which they are prompted to provide the following information for our team to review: * Project Name * Project Description * Contact Information * Service Type Additionally, clients can also reach out to us on [Twitter](https://x.com/coverage_labs) via a direct message, however, we highly encourage the submission of a formal request for an engagement via our website, or via email, such that our team can begin to assess the[ Scope Of Work](/methodology/scope-of-work). # Scope of Work The scoping process is essential for accurately allocating resources, setting realistic timelines, and defining clear deliverables for the engagement. ## Initial Scoping In this phase, we collaborate closely with the client to define the scope, gather technical insights, and establish expectations for the engagement. This includes: * Reviewing the relevant resources provided by the client, such as the codebase, test-suite and documentation to ensure that the client is fully prepared for the engagement. * Identifying key focus areas within the project, including specific components, modules, or functionalities that require special attention. * Estimating the necessary resources, timelines, and deliverables, based on the complexity and scope of the engagement. This step is crucial to aligning both parties on expectations and ensuring that the engagement is fully tailored to meet the client’s goals. ## Information Gathering Once the initial scoping is complete, we conduct a comprehensive review of all gathered information to ensure our team is fully equipped with the insights needed to deliver high quality results. We require: * **Clear Documentation**: Well-documented code with detailed annotations to explain the logic, intended functionality, and any assumptions within the codebase. * **Test Coverage:** A robust testing suite covering the vast majority of the codebase to facilitate the validation of findings. Ideally, clients should aim for 100% test coverage. # Rates This section details the base weekly rates for security reviews and fuzzing campaigns, determined by the agreed-upon number of engineers and the duration of the engagement. ## Security Review Below are the base rates for each level of security engineer that is allocated to a security review. | Role | Weekly Rate ($) | | --------------------------- | --------------- | | Lead Security Engineer | 3500 | | Associate Security Engineer | 2750 | | Junior Security Engineer | 2000 | ## Fuzzing Campaign Below are the base rates for each level of fuzzing engineer that is allocated to a fuzzing campaign. | Role | Weekly Rate ($) | | -------------------------- | --------------- | | Lead Fuzzing Engineer | 3000 | | Associate Fuzzing Engineer | 2250 | | Junior Fuzzing Engineer | 1500 | # Statement of Work The Statement of Work outlines the key terms of the agreement between the client and Coverage, ensuring both parties are aligned. ## Overview Each Statement of Work includes, but is not limited to, the following components: 1. **Scope of Work** * For our engagements, we will reference a selected commit hash of the codebase and the files within scope for review. 2. **Deliverables** * For security-focused engagements, we will provide a report outlining key findings and insights. These may include technical assessments and supporting materials. 3. **Timelines** * Each engagement will have a defined start date and end date, followed by a two-week fix review period. During this period, the client can address identified issues, with our support for validation and assistance as needed. 4. **Engineering Team Breakdown** * Each engineer assigned to the engagement will be listed in the Statement of Work, along with their respective roles. 5. **Client Responsibilities** * Access and Resources: Ensure we have access to relevant repositories, documentation, and all necessary technical details that are essential for the engagement. * Timely Feedback and Communication: Provide prompt reviews and feedback on deliverables and maintain open communication throughout the engagement to address any questions or concerns. * Vulnerability Remediation: The client is responsible for deciding whether to fix or acknowledge identified vulnerabilities during the two-week fix review period, which begins after the preliminary report is sent. 6. **Price, Payment Schedule and Method** * Price: The total cost for the engagement is based on the number and level of engineers assigned, as well as the estimated duration of the engagement. * Payment Schedule: Payment is required in full upfront before the engagement starts. * Payment Method: We accept payments in USDT or USDC via selected networks. Once both parties have signed the Statement of Work, a dedicated private communication channel will be established between our engineering team and the client's team. # Communication This section outlines how communication is handled during our engagements, including the frequency and channels we'll use to ensure smooth and effective collaboration. ## Asynchronous Communication Asynchronous communication is conducted via text, typically through Telegram or other preferred platforms, facilitating continuous dialogue beyond scheduled meetings. ## Synchronous Communication Synchronous communication is conducted through scheduled meetings to facilitate real-time discussion and immediate feedback. ### Kickoff Meeting The Kickoff meeting marks the official start of the engagement. During this meeting, we’ll review the [Scope of Work](/methodology/scope-of-work) and align on key objectives, expectations, and any other relevant items for the engagement. ### Recurring Meeting Weekly recurring meetings are held throughout the engagement to provide status updates, and address questions from either side. These meetings help ensure that communication remains open and that progress is tracked. ### Close-out Meeting The close-out meeting summarizes the entire engagement, reviews what was accomplished, and ensures that expectations and deliverables initially outlined in the kickoff meeting are met. {% hint style="info" %} **Note:** After the close-out meeting the engagement will transition into the Fix Period following this meeting. {% endhint %} # Security Review # Context & Cleanup During this phase, we dive deep into your codebase to understand its intricacies, establish context, and eliminate known anti-patterns. ## Diagrams & User flows We create detailed diagrams and user flows to visualize the architecture and functionality of your codebase. This approach helps identify potential design flaws and improves the overall understanding of the engineering team involved in the engagement. {% hint style="info" %} **Note:** These diagrams are provided to the client as a deliverable and can be used freely for marketing and development purposes. {% endhint %} ## Static Analysis We utilize various static analysis tools, including [Slither](https://github.com/crytic/slither), [Slitherin](https://github.com/pessimistic-io/slitherin), and [Aderyn](https://github.com/Cyfrin/aderyn), to identify vulnerabilities and known anti-patterns early. This automated review ensures the code is free from unnecessary clutter and establishes a solid foundation for the engagement. ## Gas Optimizations We analyze the codebase to identify opportunities for gas optimizations, concentrating on enhancing cost-efficiency during deployment and runtime while maintaining readability. # Manual Review During this phase, the codebase is reviewed to identify potential edge cases, design flaws, and attack vectors, while ensuring the business logic aligns with the project's technical specifications. ## Overview Leveraging insights gained from previous phases, we perform a thorough examination of the codebase to identify potential edge cases, design flaws, and attack vectors that automated testing techniques may miss. We also review the overall business logic of the protocol to ensure it aligns with project specifications and matches the intended behavior outlined in the documentation. Any identified issues are documented with clear explanations and actionable recommendations for remediation, enabling the client to address them effectively. # Quality Assurance During this phase, we document the capabilities of privileged actors within the protocol and assess the maturity of the codebase across multiple categories, highlighting areas for improvement. ## Access Control During the assessment, we outline each role within the system along with its corresponding capabilities. This evaluation ensures that robust access controls are established, effectively managing each user's permissions within the system. ## Code Maturity The Code Maturity Evaluation is based on several key guidelines, as outlined in the table below.
CategoryDescription
Access ControlThe use of robust access controls to handle identification and authorization, as well as ensuring safe interactions with the system.
ArithmeticThe proper use of mathematical operations, including addition, subtraction, multiplication, and division, as well as semantics.
CentralizationThe proper use of permissionless principles for mitigating insider threats and managing risks posed by contract upgrades.
Code StabilityThe extent to which the code was altered during the audit and the frequency of changes made over time.
UpgradabilityThe presence of upgradeable logic that allow modifications after deployment, ensuring adaptability to future needs.
Front-RunningThe system’s resistance to front-running attacks, where transactions are manipulated to exploit market conditions.
MonitoringThe presence of events that are emitted whenever there are operations that change the state of the system.
SpecificationThe presence of comprehensive and readable codebase documentation outlining the purpose, functionality, and design choices of the system.
Testing & VerificationThe presence of robust testing procedures, including unit tests, integration and end-to-end tests, ensuring the reliability and correctness of the system.
This framework helps ensure a comprehensive understanding of the codebase's robustness and identifies areas for improvement. {% hint style="info" %} **Note:** Upon completion of this phase, a draft report is provided to the client, summarizing the findings. A brief overview is presented during the Close-out Meeting, after which the engagement transitions into the Fix Review phase. {% endhint %} # Fix Review During this phase, the mitigations implemented for previously identified vulnerabilities are reviewed. The goal is to verify that the fixes are correctly applied and do not introduce new issues. ## Fix Review Period We provide a two-week period for clients to implement fixes and have them reviewed by our security team. We also encourage our clients to make the most of this time, ensuring that we can thoroughly review each fix. ## Extensions If fixes are not fully reviewed within the two-week period, the client can request an extension by signing a Fix Review Extension Statement of Work. # Final Report During this phase, we generate a report that summarizes all findings, fixes, and recommendations, marking the end of the engagement ## Final Report Delivery Once the fix review period ends and any requested adjustments to the draft report have been confirmed, the report will be considered final and delivered to the client. ## Portfolio For a complete view of our previous work, please visit our [portfolio](https://github.com/coveragelabs/portfolio). # Fuzzing Campaign # Invariant Development The foundation of an effective fuzzing campaign lies in precisely defining the invariants—the unshakable truths of your protocol. ## Invariant Identification During this phase we collaborate closely with your engineering team to identify both system-level invariants (e.g "The sum of user balances must always equal the total supply") and function-level invariants (e.g "This function must never decrease the protocol's balance"). These invariants are documented in clear English, accompanied by preconditions and bounds to ensure they reflect realistic scenarios. Our team conducts structured brainstorming sessions with your engineering team to identify implicit protocol rules. ## Iterative Improvement We refine invariants based on short fuzzing campaign results, tightening preconditions and arithmetic bounds to ensure all code paths are tested and eliminate false positives. The goal is to produce a suite that is both rigorous and maintainable, while capable of evolving alongside your codebase. # Implementation During this phase we implement a stateful fuzzing test suite with Echidna, translating system properties into enforceable rules to verify correct code behavior. ## Overview We implement our stateful fuzzing test-suite using [Echidna](https://github.com/crytic/echidna), a fast and flexible fuzzer for Ethereum smart contracts. The invariants identified during the [Invariant Development](/services/fuzzing-campaign/invariant-development) phase are translated into executable properties within Echidna’s testing framework. These properties are rigorously tested under various conditions, ensuring they accurately reflect the protocol’s intended behavior. \ \ The implementation includes custom test harnesses and utility functions to simulate realistic interactions with the protocol, enabling comprehensive invariant validation. All test cases are optimized for performance and clarity, ensuring seamless integration into your CI/CD workflow. # Tests & Integration We run a 48-hour fuzzing campaign to extensively test all protocol invariants. The test suite is then integrated into your CI/CD, triggering short fuzzing campaigns on every commit. ## Running the Test Suite Following the completion of invariant development, we initiate a **48-hour fuzzing campaign** designed to uncover deeper edge cases that manual review might miss. The campaign is typically executed on cloud infrastructure (AWS/GCP) to ensure consistent performance and enable parallel execution. ## CI/CD Integration We integrate the test suite into your **GitHub Actions CI/CD pipeline**, triggering short fuzzing campaigns on every commit. This ensures that new code is continuously validated against protocol invariants, preventing buggy code from being pushed. We provide all necessary configuration files and a detailed integration guide, enabling your team to maintain and expand the tests post-engagement. # Fix Review During this phase, the mitigations implemented for previously identified vulnerabilities are reviewed. The goal is to verify that the fixes are correctly applied and do not introduce new issues. ## Fix Review Period We provide a two-week period for clients to implement fixes and have them reviewed by our security team. We also encourage our clients to make the most of this time, ensuring that we can thoroughly review each fix. ## Extensions If fixes are not fully reviewed within the two-week period, the client can request an extension by signing a Fix Review Extension Statement of Work. # Final Report During this phase, we generate a report that summarizes all findings, invariants, runs and recommendations, marking the end of the engagement ## Final Report Delivery Once the fix review period ends and any requested adjustments to the draft report have been confirmed, the report will be considered final and delivered to the client. ## Portfolio For a complete view of our previous work, please visit our [portfolio](https://github.com/coveragelabs/portfolio). # Media Kit {% file src="/files/40YfsJWupUCW838TkgWj" %}