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:

• Chain Rollbacks

• Attack Investment Amount

• Attacks With A Financial Risk To The Attacker

• When Is An Impactful Attack Downgraded To Griefing?

Proof of Concept (PoC) Requirements

A PoC is required for all bug reports.

• 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.

A PoC is required for all severity levels. 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. For all Medium, High, and Critical reports, the PoC must demonstrate the vulnerability end-to-end on a local 4-node network, from an external point of view. The vulnerability must be shown against the running network as an external actor would encounter it, not in isolation. The following are the requirements for a valid PoC:

• The PoC must spin up a local 4-node network and demonstrate the vulnerability against that running network.
• The vulnerability must be demonstrated from an external perspective. If the attack requires a malicious node, the PoC may inject the necessary code into a single instance to make it malicious, but the impact must be demonstrated against the network as a whole.
• The ideal PoC is a self-contained bash script that spins up the network, applies any required modifications, and runs the CLI commands that carry out and prove the attack.

The following are not accepted as valid PoCs on their own:

• Unit tests
• Integration tests
• Written explanations, descriptions, or theoretical demonstrations without a working end-to-end PoC against the local network Reports that do not demonstrate the vulnerability end-to-end on a local network, as described above, will be considered insufficient and will not be eligible for a reward until a valid PoC is provided.

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