Request for Proposal (RFP): Compound DAO Security Service Provider (SSP)

[CSI]

Compound Security Initiative (CSI) - Proposal for Compound DAO Security Service Provider

We are proposing to create the Compound Security Initiative (CSI), a group founded by Compound community members, auditors, and security experts.

We see that security is a crucial part of the protocol, and in the modern DeFi era, it should include several key-stones:

• Security pipeline should be integrated throughout the whole product lifecycle. Real security comes from the dedicated security team, “blue” team, as in traditional cybersecurity. Obviously, to have a diversification, the protocol should have periodic independent audits (that is the contribution of “red” teams), but the core security should come from its own internal “blue” team;
• So, we believe that the task of security team is not just audit, but a full risk-based assessment, continuous cooperation with the development team, implementation of security practices on each stage of the product lifecycle (either its architecture design stage, development kickoff, intermediate releases, features review or release curation), development pipeline hardening with security practices - the whole package expected from a “blue” team;
• We believe that Compound Foundation should have ownership over this direction. In such a case, the protocol will have a rapid feedback loop with the security team, the security enhancements will have high visibility, the security team will be able to respond directly to the protocol’s needs, and the development team will be able to work without interruptions with continuous supervision from the security team.

CSI was already involved in some developments as a security advisor for WOOF! (@woof) team in the form of a “blue” team advisor throughout several Compound enhancements. The proposal reflects the scaling of the tested approach up to the full Compound Security Initiative (CSI), which will secure Compound from all sides of the lifecycle under the Compound Foundation ownership.

General Overview

Team and background

Founding Member: Pavlo Horbonos ( @Midvel )

As an individual, I have over a decade of experience in software development and web3/blockchain development, with half of that focused on web3 security. The professional experience included the building and launch of different protocols, leadership and advising as CTO or Head of Security. I’m focused on in-depth R&D in the web3 space, covering both the technical and risk assessment aspects. Thus, a significant part of my expertise lies in DeFi, with a current focus on lending protocols and risk analysis within the DeFi field.

While keeping an up-to-date overview of the web3 technological and security landscapes, I keep the initiative on knowledge sharing and strengthening the web3 security community, which is reflected in my main media:

[LinkedIn] [X] [Medium]

As a web3 security leader, I built a security team from diverse security researchers and web3 engineers. I’m integrating the red + blue team approach, thus we provide auditing and code assessment services (“red” approach) and advisorship and direct integration with the development team on security aspects (“blue” approach), building the defence in-depth, conducting risk assessment on early stages, and offering a continuous support during the lifcecycle of the product.

In Q2 2020, I started building the auditing team called Blaize Security. We worked with Mysten Labs, Everstake, Ava Labs, Drosera, E Money Network, 01node, Dusk Network, Allbridge, and a row of other projects, securing them as a security vendor. Part of the public reports can be found here: GitHub - blaize-security/blaize-security-audits: Public security reports

In 2025, my team and I (@Midvel) decided to go our own way, pushing the web3 security initiative on protecting products in the web3 space from all angles - same red+blue team approach but scaled from all sides. Same team, same experience - new targeted initiative.

The team includes a diverse set of security researchers and web3 engineers with qualifications in all modern web3 ecosystems. Skillset includes:

• Solidity stack for EVM chains (L1s, L2s, Cosmos evmos chains, and other EVM instances)
• Golang stack and blockchain assessment expertise for geth, evmos, Cosmos SDK and other chain technologies
• Rust stack for Solana, Polkadot, Casper, and other Rust-based chains
• C/C++ stack for BTC-family, EOS chains, and other C++ based technologies
• Move stack for Sui and Aptos
• Specific stacks for chains like StarkNet, ICP, Kadena, TON, etc

My team and I have worked for more than 5 years in the web3 security industry, making a long-running security initiative.

Existing Relationship with Compound

Currently, CSI is engaged with @woof as a contractor security advisor for the security advisory and internal audits.

The engagement currently includes:

• advising on a partial liquidation solution from a security standpoint, with future engagements planned for risk assessment during the modeling phase and internal audit of the implementation;
• advising on a bytecode repository with version control solution and deployment pipeline improvements from a security standpoint, with a solution review from the security side; with future engagements planned for internal audits;
• security advising for the Sandbox team, engaging with the developers in a Blue team mode;
• advising the WOOF! (@woof ) team on the Compound repository and infra improvements;
• plus, engagements with a few currently unannounced improvements planned for the protocol.

Thus, the team is familiar with the protocol, and I’m actively engaged with the protocol’s codebase and infrastructure.

Relevant Security Partnerships or Clients

Throughout my web3 security journey, I worked with Mysten Labs, Everstake, Ava Labs, 01node, and numerous other projects. Since I’m leading the web3 security initiative, I keep a close connection with security-related projects like CyVers and Drosera, since pro-active security is a must-have in a modern age.

Part of the public reports from the period when I led the team at Blaize Security can be found here: GitHub - blaize-security/blaize-security-audits: Public security reports

Section 1: Scope of Security Work

1a) Scope of Services Overview

My team covers all connected services in a red+blue team manner:

• regular security audit of a release version of the code;
• cooperation with the development team with the review/audit/assessment of all intermediate releases or separate features;
• cooperation with the development team on the assessment of the solution and recommendations on its hardening from the security side;
• risk assessment of the solution;
• risk assessment of the protocol, modeling of stress situations for the protocol, analysis of the protocol economics;
• advising of the development team, development pipeline strengthening (security best practices, layered defense, active protection tuning up, CI/CD strengthening, infra review, etc)
• test strategies development, advising on testing practices integration;
• deployment support and supervision;
• review of the governance proposals;
• integration of active security and monitoring/analytics services;

That includes work with certain offchain components as well (bridge relayers, sequencers, workers, offchain components of oracles, etc)

The team is currently not working with pure web2 components, frontend pentests, load testing of web2 infra, and related services.

1b) Multi-Chain Support & Upgrade Expertise

All mentioned networks are supported. The team has experience in crosschain bridges auditing, including projects based on Chainlink CCIP, LayerZero, Wormhole, and others; in multichain deployments review for DeFi protocols; for crosschain operations review and crosschain messaging protocols auditing.

All newly emerged L2s are studied within the team based on our R&D initiative to extend on every network. Thus, once new technology/L2/chain emerges, it goes through the R&D team to add it to the expanding list of qualifications.

The role of vCISO in this process is:

• setting the R&D strategy to have a vision on what technology should be analyzed first and what risks may be met at that direction;
• continuous education on a risk-based approach for the analysis;
• supervision over the deployment process;
• cooperation between the community and the security team: ensuring the clear communication of all the work done, offering of new practices and instruments, checking on proposals from the community on the ecosystem hardening, analysis of offered integrations/tools/enhancements (in cooperation with necessary specialists)
• continuous analysis of the state of the system, predicting the needs (from the security standpoint) for modeling/analysis

Taking the vCISO role in a wider sense:

• setting the strategy on the development pipeline hardening - cooperation with the development team on adoption of certain testing strategies, integration of additional tools (fuzziers, analyzers, deployment helpers - any that will bring strength into the development), adoption of best practices
• assessment of the current state of the protocol - that best practices are followed, that recommendations are applied, that the team is security-oriented;
• continuous cooperation with the development team on knowledge sharing, security-oriented approach, and experience sharing and even on educting the team on the security-based approach;
• risk assessment for the protocol, vision on future threats that the protocol may meet, and thus - resolving risks in cooperation with the development team;
• a link between developers and auditors, which supports and shares the context between them;
• work with the community and educate it on the best practices and safe behavior within the ecosystem
• cooperation with the ecosystem projects, ensuring that all projects under the Compound umbrella share the same mindset.

1c) Resource Allocation and Availability

The proposal includes the exclusive dedication from me and my team under the Compound Security Initiative, offering priority within the pipeline, working on a by-demand basis. Compound Security Initiative can offer a guaranteed allocation of two teams, with the possibility of extension in case of necessity. Plus my own time as vCISO for the Compound.

The team will develop a rotation strategy and a knowledge-sharing strategy to prevent any potential bottlenecks. The context will be preserved through a curated knowledge base between the teams, ensuring that no time will be lost during the rotation.

1d) Additional Services or Tools (if any)

The team can additionally:

• prepare educational resources in a form of articles for the Compound forum
• participate in community calls
• evaluate external tools for the security pipeline strengthening and assist in their integration

Section 2: Technical Methodology and Audit Process

2a) Audit Methodology

Our methodology is built around several base points:

• Risk-based approach. We analyze the protocol within the environment in which it will work. Therefore, within the audit we integrate risk modeling elements to deduct the most possible attack vectors, and that include economical risks analysis (depending on market conditions, on price movements, on different risk profiles of users, etc), integration risk analysis (both direct dependencies on 3rd party protocols and components, and indirect influence within the niche or via shared resources), user behavior related risks (humar errors, interface usability issues, different approaches from users), and internal risks (incorrects settings combinations, edge cases within regular flows, incorrect interactions between the protocol modules, etc)
• Business logic validation. We dissect the project from the business logic perspective, detect all actors (users of different types, different pro-active entities, hidden players, access control of different levels, etc), all components and modules, and analyze internal flows and interactions between all of them to detect deadlocks, edge cases, substandard behavior, fluctuations in behavior or abnormalities.
• Line-by-line review. The core of the audit is the review of code by at least 2 auditors, with cross-verification of results to ensure that each line was reviewed. This also includes the use of static analyzers and linters, as well as best practices analyses and possible optimizations in terms of gas usage (or its equivalent), and software optimizations (such as code complexity, readability, and dependency management).
• Code testability verification. We review the existing tests suite coverage in terms of adequacy and completness. We write our own set of tests to ensure that all code is testable, we conduct an exploratory testing phase (search for edge cases and new hypotheses), we develop PoCs for all high-impact issues, we provide fuzzy-testing in case of necessity or by request.

Thus, we ensure that we secure the protocol as a complex system, from the code side, environment side, and business logic side.

2b) Audit Workflow & Deliverables

Scoping and estimation

We require the codebase to make an estimation over it; we avoid blind estimations, as the quotation should include only the services necessary for a particular codebase. The scope for quotation includes only functional files - actual smart contracts and libraries (or equivalents in terms of only functional code of offchain workers, or only functional code from chain layer, etc). However, the audit scope also includes review of interfaces, tests, settings, configs and other non-functional items, even if the review is formal. All standard elements and libraries (forked or as 3rd-party dependencies) are always formally compared with original to ensure that no changes are made.

This stage usually takes up to 24 hrs (1 day in timeline) depending on the size of the codebase. After that the scope, the necessary team, the budget, the start date and the timeline are set.

Manual stage

We start the audit from the manual stage, which includes the business logic assessment, risk-based assessment, line-by-line review, usage of analyzers, hypotheses construction. It ends with the intermediate report that contains all issues discovered by the moment, results of business logic analysis, and list of hypotheses to be proved during the testing stage. The intermediate report is shared with the customer, so they can start working on fixes.

Testing stage

It is usually run after the initial manual stage, though can be run in parallel based on the nature of the audit. It includes a review of the existing test suite, development of own set of tests, PoCs for issues and hypotheses, exploratory testing, and fuzzy testing. In case of complex systems, it also includes integration and end-to-end testing (e.g. fork tests, or deployment on private network, etc). All issues discovered during this stage are added to the report and notified to the customer.

Fixes review and consulting

During the audit, we establish direct communication with the customer. Therefore:

• all critical issues are communicated immediately, to give more time for their remediation;
• we have ongoing communication regarding the business logic and substandard behavior;
• we provide ongoing consulting on the discovered issues and best ways to fix them;
• we can communicate directly on fixes and their review.

So, right after the manual stage, intermediate report delivery, we can advise and communicate on potential fixes.

Additionally, we work on fixes and consulting until the last issue is resolved . Regardless of whether more issues are discovered, if fixes take longer to deliver, or for any other reason, we always ensure that we deliver a report with all issues communicated and resolved to a common result between the customer and auditors. Thus we have no fixed number of review rounds or fixed timeline for review (as fixes delivery can take more time from the development team) - we work up to the last issue resolved.

Report

The final report is delivered after all stages are finished. It includes:

• protocol overview section with the description of main actors, components, assets, settings and launch specifics with certain notes from the business logic analysis stage
• analysis section with all issues listed. Each issue has clear description, recommendation and post-audit comment in case of specific actions connected with it
• additional sections describing testing stage and existing tests suite (if necessary), best practices recommendations, deployment flow specifics, etc
• rating section with a clear depiction on how the final rating was calculated.

As for the severity levels, it includes:

• critical issues - direct losses by the protocol or by users, or violation of the protocol’s integrity or availability
• high-impact issues - same as critical, but with lower likelihood or with additional steps to recreate the issue, or with workaround preventing the issue
• medium issues - noticeable impact on user flow, protocol internal processes, funds distribution, usability and other aspects
• low - issues with low likelihood, low impact, or with high gas spending
• info - unclassified issues connected to the sub-standard business logic or implementation decisions, which may lead to high risk issues, but which depend on the customer’s risk-aceptance level
• best practices - no-risk recommendations and code improvements

2c) Quality Assurance and Track Record

Over the last five years, my team and I have worked in the web3 security space, conducting over 200 audits that uncovered approximately 150 critical and high-impact issues, which were subsequently mitigated. Notably, no post-audit security breaches were detected following our work.

Section 3: Risk Management and Incident Response

3a) Vulnerability Triage & Disclosure:

At the start of the audit we establish the communication channel with a person responsible for audit results acceptance and keep direct communication throughout the audit Thus, in case of a critical or high-impact issue discovered, it is immediately reported to that person to develop a common strategy on mitigation and next steps. The issue is never publicly disclosed, unless specifically allowed by a Customer. However, if the issue will be a part of a full report (from a regularly delivered service), it will be publicly disclosed once the report is published.

• In case of critical issue is found, it is prioritized up to the full resolution plan.
• Since communication is ongoing, the remediation plan will be developed immediately in cooperation with the client.
• We also provide a patch design.
• All communication is held in a messenger of the Customer’s choice.

So, the lifecycle of such an issue is: discovery, immediate communication through the previously established channel, preparation of the recommendation and patch (if necessary), remediation plan preparation together with the customer, and review of the implemented fixes. Public disclosure is not a part of this lifecycle, as it is up to the customer if disclosure should happen immediately or within the regular report.

3b) Incident Response Support:

In case of the exploit, we will

• conduct a technical investigation in 24hrs from the moment of contact to detect the root cause and develop a countermeasure
• communicate through the previously established communication channel
• Verify the integrity of the protocol after patching
• Supervise the recovery of the protocol’s functions
• Monitor the protocol’s activity after the recovery
• In case of exploit, it is prioritized within the company, thus all resources are used throughout the process.

3c) Continuous Monitoring & Threat Detection:

In the monitoring and prevention segment, we previously worked closely with CyVers.

As for the internal solutions, we actively use Tenderly dry-runs and alerts, solutions based on Prometheus and Grafana (mostly for the chain-level activities). Such a solution is usually based on a custom request from the Customer, thus its specifics (either Oracles monitoring, or certain transactions monitoring, or whale activity, or abnormal token transfers) depend on a structure of the request.

Section 4: Commercial Terms and Commitmen/h2>

4a) Budget Request and Pricing Model:

Shared as a private attachment

4b) Milestones and Performance Metrics:

• quotation is delivered in 24hrs after the code is received (up to 48 hrs in case of large codebases)
• audit start is within 2 weeks period from the quotation (1 week for the exclusive conditions for the Compound protocol)
• intermediate audit report is delivered within the timeline set at the quotation stage

As for the cooperation with Compound the KPIs may include:

• activity report by the end of each month
• development pipeline hardening suggestions delivered on a monthly basis
• standard features/intermediate patches/minor releases should have audits delivered within 2 weeks of code readiness (at least in the intermediate report state)
• critical issues triaged in 24hrs after the discovery
• be-weekly participation in forum activities (in a form of suggestions on protocol improvements or best practices improvements)
• participation in all community calls and governance discussions
• review or commentary on each RFC or suggestion published on Compound forum

4c) Conflict of Interest Declaration

The CSI is dedicated exclusively to supporting Compound.

4d) Transition and Offboarding Plan

In case of cooperation termination, we will ensure the transfer of the knowledge base within a 30-day period before the end of the 60-day termination period.

Section 5: Service Level Expectations (SLA)

5a) Incident Response

Target response time is within 1 hour, with the aim of resolution within 24 hrs. Escalation, triage, and mitigation processes are incident-dependent, though the initial assessment and research are aimed to be performed within the first 4 hours of the incident, with further actions being incident-dependent.

5b) vCISO Support

Exclusive availability for a vCISO support within the same day of the request. I personally will be the DAO’s primary contact.

5c) Governance Proposal Reviews:

Governance proposal can be reviewed in 48hrs after the request. In case it contains any new and previously unaudited code, that fact should be communicated prior and the new code audit is processed via a regular process.

Urgent reviews are supported within the same day of the request.

5d) Code Audits:

Within the exclusive conditions of cooperation with Compound lead time is 1 week.

Final considerations

The goal of the Compound Security Initiative is to provide the 24/7 “blue+red” team approach exclusively for Compound ecosystem, tailored for its needs, with a direct communication with the development team and with services targeted on a security on all lifecycle stages.