Cosmos Labs believes that proactively finding and fixing bugs is a vital part of building strong, resilient blockchain protocols. This program exists as a public good to actively reward the people who discover bugs in the Cosmos Stack. Our stack includes distributed systems protocols, cryptography, a smart contract platform, a consensus algorithm, and an interoperability protocol. As such, this program is not the right place to search for web application vulnerabilities like XSS, CSRF, and header misconfigurations.The focus of this program is on surfacing vulnerabilities in the protocols, modules, and infrastructure that make up the Cosmos Stack. Assets in scope include source code for integral components of Cosmos, and do not include third-party services or IT assets. These assets are fully defined in our Scope section. Bounty rewards are based on multiple factors, including impact, risk, likelihood of exploitation, and report quality. We use an impact/likelihood framework to assess criticality, available here.
Triaged by Immunefi
PoC Required
KYC required
Rewards
Rewards by Threat Level
Primacy of Impact vs Primacy of Rules
Cosmos adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.
Rewards by Threat Level
Rewards are distributed according to the impact the vulnerability could otherwise cause based on the Impacts in Scope table further below.
Informational reports are not eligible for a reward. Repeated informational or inapplicable submissions will be treated as spam and may result in exclusion from the program.
Informational Findings
Findings with no real security consequence, such as cosmetic issues, problems confined to documentation or build tooling that never runs on-chain, behavior that is safe-by-design, or bugs with no demonstrated impact or no demonstrated exploit, are classified as Informational and are not eligible for a reward.
Program Wide Severity Downgrade Conditions
In addition to the impact-specific conditions above, the severity level of a bug report may be downgraded by one severity level where any of the following conditions applies:
-
The attack requires a race condition to occur in which the timing is not within the attacker's control.
-
Performing the attack requires the attacker to be within a permissioned set, such as a validator within the active set or a user with the ability to deploy contracts on a restricted chain.
-
The attack requires a governance action to be taken in order for the attack to take place, such as an on-chain consensus parameter change.
-
The attack requires validator collusion of one third or more, of voting power.
-
The vulnerability is easily recoverable with built-in tooling that mitigates the impact.
-
The attack requires a relayer to behave maliciously
Important Note for All Bug Reports
While Cosmos aims to provide as clear as possible objective downgrade reasoning in this bug bounty program text, it cannot cover all scenarios that would warrant a downgrade, especially given the uniqueness of the Cosmos structure compared with other bug bounty programs on Immunefi. Because of this, all reports to the Cosmos bug bounty program may be further downgraded by Cosmos separate from or in addition to the downgrade conditions here. The Cosmos team thus retains full discretion on the final severity level of all reports. However, the Cosmos team adheres to providing a reason for all these special additional downgrades.
Feasibility Limitations
The following standard feasibility limitations apply for the bug bounty program:
Proof of Concept (PoC) Requirements
A PoC is required for all bug reports.
All PoCs submitted must comply with the Immunefi-wide PoC Guidelines and Rules. Bug report submissions without a PoC will not be provided with a reward.
In addition, the following requirements apply:
-
The PoC must be code that can be read and run by the security team. Written descriptions of an attack alone do not count as a valid PoC.
-
PoCs must demonstrate real user flows. Mock-only or database-only calls are insufficient.
-
Bug reports without adequate detail may be closed or returned for revision.
Other Terms and Information
- Release Policy Requirement - Only released code is eligible for a reward. To be considered valid and in-scope, the issue must exist in released code that is tagged and actively maintained under the Cosmos Release Family Policy. Code that exists only on main, master, or other development branches is not in-scope. In addition, the issue must be exploitable in an intended deployed environment and configuration.
Program Response SLA
Cosmos defines its own response and resolution SLA's as described below:
| Severity | Acknowledgement + Triage SLA | Resolution + Payment SLA (starting from date ack'd by Cosmos) |
|---|---|---|
| Critical | 2 weeks | 5 weeks |
| High | 2 weeks | 3 weeks |
| Medium | 2 weeks | 6 weeks |
| Low | 2 weeks | 8 weeks |
Program Overview
Cosmos Labs believes that proactively finding and fixing bugs is a vital part of building strong, resilient blockchain protocols. This bug bounty program exists as a public good to actively reward the people who discover bugs in the Cosmos Stack. The Cosmos Stack includes distributed systems protocols, cryptography, a smart contract platform, a consensus algorithm, and an interoperability protocol. The focus of this program is on surfacing vulnerabilities in the protocols, modules, and infrastructure that make up the Cosmos Stack. It is not the right place to search for web application vulnerabilities such as XSS, CSRF, and header misconfigurations.
For more information about Cosmos, please visit https://cosmos.network/.
Cosmos provides rewards in USD. For more details about the payment process, please view the Rewards by Threat Level section further below.
Responsible Publication
Cosmos adheres to category [3] - Approval Required. This policy determines what information security researchers are allowed to make public from their submitted bug reports. For more information about the category selected, please refer to our Responsible Publication page.
Primacy of Impact vs Primacy of Rules
Cosmos adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms stated in this page.
Pay to Submit
This program uses Immunefi’s pay-to-submit feature. Security researchers may be required to pay a per-report fee, denominated in USDC and paid on-chain from a verified wallet, in order to submit a report.
This fee is charged by, and paid to, Immunefi as an operational fee for use of its platform. It is not a fee to Cosmos Labs, is not paid to or recoverable from Cosmos Labs, and is non-refundable regardless of the outcome of the report. Payment of the fee does not guarantee that a report will be triaged, accepted, determined valid, or rewarded, and does not create any relationship, obligation, or entitlement between the security researcher and Cosmos Labs beyond the terms of this policy. Cosmos Labs retains full discretion over the assessment of all reports submitted under this program, consistent with the Primacy of Rules set out above.
Further information on the operation of the pay-to-submit feature, including current fee amounts, payment mechanics, and the disclaimer shown on this program’s page, is available within Immunefi's pay-to-submit policy page.
Audits
Completed audit reports for this project can be found at the links below.
Any unpatched or unresolved vulnerabilities disclosed in these reports are not eligible for rewards.
KYC required
The submission of KYC information is a requirement for payout processing.
Additional information: Security researchers who have been employed by or contracted to the team maintaining the affected code within the 12 months preceding the bug report submission are not eligible
Proof of Concept
Proof of concept is always required for all severities.
Responsible Publication
Category 3: Approval Required
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.