For the ibc-go asset, the following components are in-scope:

• IBC Core - 02-client, 03-connection, 04-channel, 05-port, 23-commitment, 24-host
• Application Modules - transfer, 27-interchain-accounts
• Light Clients - 06-solomachine, 07-tendermint, 08-wasm, 09-localhost
• Middleware Modules - 29-fee, callbacks

For the Cosmos SDK asset, the core packages baseapp, crypto, types, and store, as well as the modules x/auth, x/bank, x/staking, x/slashing, x/evidence, x/distribution, and x/mint, are the components most likely to contain significant vulnerabilities. Bug reports on other maintained modules are also accepted, subject to the module exclusions listed under Other Terms and Information.

Impact Definitions and Severity Downgrade Conditions

The impacts listed in the Impacts in Scope table further below are defined as follows, together with the conditions under which a bug report covering that impact may be downgraded. Where more than one downgrade condition applies, the severity level is only downgraded once under this subsection.

Blockchain/DLT

For the Critical impact "Unauthorized minting / burning of user funds", it is defined as direct, unauthorized creation or destruction of value tied to user balances which are tokens minted from nothing, or a user's tokens burned or destroyed, without authorization, changing what holders actually own.

Bug reports covering this impact may be downgraded to High severity where any of the following conditions applies:

• The impact is limited to a single, one-time mint or burn.
• The impact is limited to a limited amount of funds being minted or burned.
• The issue is reachable only when an optional or non-default module is enabled (ICA, PFM, IBC-hooks, vote extensions, x/poa, etc).
• Unauthorized burning of funds is reversible via governance (note that this is not a rollback).

For the High impact "Chain halt / liveness failure", it is defined as where the whole chain stops producing or finalizing blocks, so no transactions can land until operators ship a coordinated fix. This happens when a single attacker-reachable input drives every validator into the same fatal error or unbounded work while applying a block, so the network stalls on one height all at once.

Bug reports covering this impact may be downgraded to Medium severity where any of the following conditions applies:

• The issue is reachable only when an optional or non-default module is enabled (ICA, PFM, IBC-hooks, vote extensions, x/poa, etc.).
• The attack requires a contrived trigger, such as a multi-step setup, an oversized multi-MB payload, a version split, or a probabilistic GC/heap race.
• The halt is recoverable and clears once the offending transaction clears or on restart (a block delay, not a permanent stop).

Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The halt is difficult or nearly impossible in practice. I.e. a contrived trigger which is also unlikely to achieve in practice, or financially punishing to the attacker, or has no exploitable chains in production.

For the High impact "Non-determinism / consensus fork / AppHash divergence", it is defined as where validators compute different results from the same block, so they can no longer agree on the chain state, splitting the network or halting it because no single result reaches the required supermajority. This arises whenever part of state processing depends on something that is not identical across all nodes.

Bug reports covering this impact may be downgraded to Medium severity where any of the following conditions applies:

• The issue is confined to an optional module or configuration (29-fee, PFM, ICA-host Proto3JSON, wasmd safe-queries, gov precompile, etc.).
• The issue requires validators running mismatched versions or configurations, or node-local configuration divergence.
• The attack requires a contrived trigger, such as a boundary-straddling transaction, repeated crafted messages, a corrupted snapshot, or attacker-controlled forwarding chains.
• The issue is configuration-dependent and recoverable via governance.

For the High impact "Permanent locking / freezing of funds or clients", which is defined as where user funds, an account, or a non-malicious cross-chain connection become permanently unusable with no automatic recovery, where typically only a chain upgrade or a governance intervention can release them, bug reports covering this impact may be downgraded to Medium severity where any of the following conditions applies:

• The issue requires an optional or non-default module (ICA host, x/accounts lockup, x/rate-limiting, ICS02 precompile, transfer-v2 forwarding, erc20 middleware, etc.).
• The issue requires a self-inflicted or contrived configuration or trigger (genesis export/import, forwarded-hop timeout, client-ID collision, etc.).
• The scope of the impact is limited to a single account, client, or path and is recoverable via governance or a chain upgrade.

For the High impact "Theft / unauthorized extraction of funds", which is defined as where an attacker moves or withdraws value they do not own, bug reports covering this impact may be downgraded to Medium severity where any of the following conditions applies:

• The attack requires an optional or non-default module, or an attacker-deployed contract (TipDecorator chain, x/accounts lockup, CosmWasm + IBC-hooks, etc.).
• The attack requires being the account owner or withdrawer, or a contrived trigger (a forced timeout plus reentrant submessages, a victim contract relying on staticcall safety, etc.).
• The impact is single-victim and isolated per transaction, or an off-chain bridge theft with no on-chain state change.

For the High impact "Loss of cryptoeconomic security", it is defined as where a misbehaving validator escapes the penalties (slashing) or breaks the signature guarantees that secure the chain economically, without crashing anything, weakening the deterrents that keep validators honest.

Bug reports covering this impact may be downgraded to Medium severity where any of the following conditions applies:

• The issue is a narrow, conditional slashing evasion, such as dodging a single slash in the re-delegation flow.
• The benefit accrues only to a Byzantine validator or double-signer, and the attack requires operating as a validator.
• The attack requires an optional module (LSM, or a non-default BLS build tag) or a contrived multi-step timing (tokenize/transfer/redeem/redelegate, conceal-past-expiry, etc.).

For the Medium impact "Supply inflation / accounting corruption", it is defined as where the chain's books or aggregate token supply drift from reality without directly creating or destroying a specific user's funds. Internal accounting (escrow, FeePool, reward or staking pools) becomes inconsistent, or total supply inflates through systemic miscalculation.

Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The issue is reachable only under an optional or non-default module or configuration (protocolpool, a custom InputOutputCoins caller, 29-fee, PFM, NonrefundableKey middleware, etc.).
• The attack requires validator or proposer privilege to land the transaction (e.g. a Byzantine proposer), meaning only a validator, and not an unprivileged user, can trigger it.
• The attack requires a contrived multi-step or asymmetric setup, or a forced forwarded-hop timeout or ordering race.
• The issue is recoverable via governance.
• The internal accounting mismatch produces no real-world impact.

For the Medium impact "Single-node crash / resource-exhaustion DoS", it is defined as where a single attacker-reachable input crashes or exhausts an individual node (CPU, memory, or disk) without stopping the chain, but because the same input works against any node, it can knock out the public RPC and infrastructure that users and services depend on.

Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The crash is confined to a single node and is recoverable on restart.
• The crash requires access to publicly available RPC methods.
• The issue is reachable only via an optional module, a non-default configuration (state sync, vote extensions, PostHandler, wasm), or only on RPC, simulation, or build-tooling paths.

The following scenario is not in-scope for this impact:

• Use of the CometBFT tx_search and block_search RPC endpoints for DoS. This is a known issue and it is publicly documented that these endpoints should not be exposed publicly.

For the Medium impact "Privilege escalation / authorization bypass / unauthorized state mutation", it is defined as where an actor performs an action a control was meant to forbid, mutating state or evading a restriction they should not be able to. Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• Some authorization is bypassed but leads to no impact for the attacker or the system that was bypassed.
• The attack requires an optional module to be enabled (authz, circuit, distribution, IBC, vesting, or capability-gated chains).
• The attack requires a governance-granted starting permission, a victim's loose authz grant, or a non-default mode (EIP-7702, Exchange swap).
• The attack requires a contrived trigger (address collision, re-entrant 7702 callback, etc.) and is single-account and isolated per transaction.

The following scenarios are not in-scope for this impact:

• Intentionally permissionless-by-design paths (permissionless evidence submission, UpdateClient, the ICA active-channel swap) where the missing control is cryptographic proof, not authorization.
• Nested authz MsgExec authorizations (a message wrapped, possibly several levels deep, inside MsgExec). Executing through a validly held authz grant is authorized behavior by design, so it is not an authorization bypass and is excluded from this impact.

For the Medium impact "Transaction censorship / mempool manipulation", which is defined as where an attacker prevents, delays, or unfairly reorders other users' transactions, or starves them of block space, without necessarily halting the chain, bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The impact is a transaction ordering skew only.
• The fee-market censorship requires a paid premium plus a fee-enabled channel and a profit-optimizing relayer.
• The censorship is per-packet or isolated to a single transaction.
• The attack requires spamming transactions that impose significant financial penalties on the attacker.

For the Low impact "Information disclosure", this is defined as where sensitive data is exposed to parties who should not see it. In this ecosystem, the impact is usually limited unless the leaked data is security-critical.

Bug reports covering this impact may be downgraded further, including to the ineligible Informational level, where any of the following conditions applies:

• The exposed secrets are single, low-value, or public-by-design, or are isolated to a template or documentation configuration.
• The issue is confined to build or npm tooling, not the chain runtime, or to a single device with no chain effect.
• The attack requires an authenticated request to be redirected cross-origin.

For the High impact "Relayer / off-chain service key and wallet compromise", it is defined as an off-chain service that holds signing keys and funded wallets, such as an IBC relayer paying gas on every chain it serves, is compromised, letting an attacker extract keys, sign arbitrary transactions as the service, or drain its hot wallets across all configured chains at once.

Bug reports covering this impact may be downgraded to Medium severity where any of the following conditions applies:

• The issue is only reachable under an operator-chosen insecure configuration (a plaintext key in a world-readable file, a management API bound to a public interface).

For the Medium impact "Supply-chain / CI-CD / RCE / account takeover", it is defined as a case whereby the software's build, release, dependency, or operator tooling is compromised. This is outside the chain's consensus, but able to put attacker-controlled code or content in front of node operators and users.

Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The impact is confined to a single off-chain asset (one bucket, site, or subdomain) or to the build/CI environment, with no on-chain effect.
• The attack requires the referenced resource to be unclaimed or dangling, or requires the attacker to first register a freed namespace and the victim to rebuild.
• The attack requires a non-default configuration or flag, or build-time or install-time-only conditions.
• The attack requires privileged users to intentionally approve a malicious workflow.

For the Medium impact "Signing-display tamper / blind signing", it is defined as a case whereby a signing device or interface shows the user benign or incomplete information while a different or fuller payload is actually signed, so the user is tricked into authorizing something they did not intend. Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The attack requires a contrived input (more than 255 displayable items) and is single-user and single-transaction with no chain effect.

The following scenarios are not in-scope for this impact:

• The fields remain visible to the user through a different, non-default mode (e.g. expert mode on a Ledger device).

For the Medium impact "Relayer / off-chain service fund exhaustion (economic griefing)", it is defined as when an attacker crafts on-chain activity that forces an off-chain service to spend its own funds with no compensation until it can no longer operate. For an IBC relayer, this means spamming packets it relays at a loss, or forcing redundant or expensive client updates, draining its gas wallet and stopping relaying.

Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The attack is mitigated by fee middleware or relayer-side filtering.
• The attack only affects an operator running an uneconomic or misconfigured relaying policy.
• The attack financially punishes the attacker just as much as the relayer.
• The attack requires a connection to a malicious chain (i.e. it is not demonstrated how an attacker could force an honest chain to produce a value or input that would cause the fund exhaustion) or a compromised RPC node.

For the Medium impact "Relayer / off-chain service liveness failure", this is defined as when a crafted untrusted input or network-level abuse crashes, hangs, deadlocks, or exhausts an off-chain delivery service so it stops doing its job. For an IBC relayer, this halts packet, acknowledgement, or timeout delivery and client updates, which strands in-transit user funds and can let an IBC light client expire, freezing the channel until a governance recovery.

Bug reports covering this impact may be downgraded to Low severity where any of the following conditions applies:

• The service simply crashes and is restartable with no stuck funds or client expiry, and another relayer can cover the path.
• The attack requires a contrived input or a non-default configuration.
• The attack requires a connection to a malicious chain (i.e. it is not demonstrated how an attacker could force an honest chain to produce a value or input that would cause the relayer DoS) or a compromised RPC node.

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