lifi-contracts-bounty
Bounty Range
$1,000,000 - $1,000,000
external program
Bounty Range
$1,000,000 - $1,000,000
external program
/opportunities/leaderboard[/welcome](Discover Cantina)
[/login](Log in)[/signup](Sign up)
@lifinance Live
https://x.com/lifiprotocolhttps://github.com/lifinancehttps://li.fi/
Total reward
$1,000,000
Deposit required
$20
Findings submitted
258
Start date
20 Mar 2025
Please sign in as a researcher to join the bounty.
[/login](Log in)
LI.FI is a cross-chain aggregation protocol that combines multiple bridges and DEXs to enable seamless asset transfers between different blockchains. The protocol uses a diamond pattern (eip-2535) smart contract architecture where a main contract delegates calls to specialized facet contracts that handle specific bridge and DEX integrations. It simplifies cross-chain transfers for both developers and users by providing a single unified solution instead of requiring individual bridge integrations.
In-Scope Targets:
Smart Contracts:
Repository: https://github.com/lifinance/contracts
Commit: Latest commit
Files: src/*
Website:
"scan.li.fi"
"li.fi"
"portal.li.fi"
WebApp:
"li.quest/*"
If you discover a vulnerability in any component that is not explicitly listed but poses a risk to user funds, user data, or the integrity of the system, you may submit it for consideration. The team will review such submissions on a case-by-case basis.
Out-of-Scope Targets:
Bridge-Specific Exclusions and DEX Aggregation Exclusions
Relayer Latency: Issues related to bridge transaction confirmation times without security impact
Bridge Fee Fluctuations: Economic concerns about variable bridge fees
Cross-Chain Reorg Scenarios: Theoretical concerns requiring deep blockchain reorganizations
Bridge Liquidity Limitations: Reports about insufficient liquidity on specific chains
Oracle Price Delays: Standard delays in price feeds without demonstration of exploitation
Slippage Within Tolerance: Expected price impacts within user-specified slippage limits
MEV and Front-Running: Standard front-running that's inherent to public blockchains
Route Optimization Suggestions: Reports suggesting better routing algorithms without security impact
Gas Optimizations: Suggestions for reducing gas costs without security implications
DEX Availability Issues: Temporary unavailability of specific integrated DEXes
Smart Contract Technical Exclusions
Centralization By Design: Admin control features that are documented and intentional
Non-Exploitable Reentrancy: Reentrancy patterns with proper safeguards in place
Flash Loan Attacks: Without proof of impact under realistic market conditions
Upgradeability Concerns: Issues inherent to our documented upgradeability pattern
Governance Attacks: Requiring unrealistic token accumulation (>10% of total supply)
Known & Acknowledged Issues: Any issue previously reported in an audit and acknowledged by the LI.FI team (find previous audit reports https://github.com/lifinance/contracts/tree/c384c5d46a020ebe12b40636d1fe138c1b38ffb8/audit/reports)
Self-Crafted Calldata Risks: Our contracts are designed to be used with calldata generated by our backend. Any issues resulting from manually crafted calldata are out of scope, as such calldata may bypass protocol-level safety checks intentionally excluded for gas optimization.
Idle Fund Access in LiFiDiamond: The LiFiDiamond contract is not meant to hold funds. Crafting calldata to move or steal residual funds or dust is expected behavior and not a protocol vulnerability.
Cross-EVM Address Mismatch: Certain EVMs (e.g., zkEVMs) may produce different contract addresses. If this leads to issues not affecting production contracts and not triggered by backend-generated calldata, they are out of scope.
Deprecated Contracts: Anything located in the /archive folder is considered deprecated and out of scope.
Automated Findings by Lightchaser: Findings from [https://gist.github.com/ChaseTheLight01/c12e5627d5b50fe4ebc5957ea711b014](this list) are excluded unless otherwise validated by the team.
Duplicate Vulnerability Reports: Any vulnerability previously known and acknowledged by the LI.FI team
Atomic Transaction Reverts: Failures of individual swap or bridge steps within multi-step transactions are expected and revert the full transaction by design — this is not a vulnerability.
Precision & Dust Reverts in Integrations: Minor dust-related issues or precision mismatches causing reverts (e.g., underflows, insufficient input amounts) due to external DEX behavior are considered known limitations and out of scope.
Out of Scope / Invalid Reports
Third-Party Protocol Issues: Bugs in third party code are out of scope
Known Issues: Vulnerabilities listed in our documentation as "Known Issues"
Test Code Vulnerabilities: Issues in non-production test code
User Error Scenarios: Vulnerabilities requiring users to input obviously incorrect parameters
Theoretical Exploits: Attack scenarios without practical proof-of-concept
Known Issues Under Remediation: Vulnerabilities that have already been identified or are in the process of being fixed.
WebApp & Website Exclusions The following vulnerability types are explicitly excluded from the bug bounty program:
Client-Side Static Injections: Vulnerabilities that require modifying client-side code via browser developer tools or similar methods are not considered valid submissions.
Self-XSS Requiring Browser Console: Attacks requiring the victim to paste malicious code into their browser console are excluded.
OR-Based Injection Techniques: SQL injections or similar attacks that rely solely on logical OR operators without demonstrating actual data extraction or manipulation.
Theoretical Vulnerabilities: Issues that cannot be demonstrated with a practical proof of concept.
Rate Limiting Bypass through Multiple IPs: Using multiple IP addresses to circumvent rate limiting is not considered a valid vulnerability.
Missing Security Headers: Reports solely about missing security headers without demonstrating an actual exploit will not be accepted.
Social Engineering Required: Vulnerabilities requiring substantial social engineering to exploit are excluded.
Unvalidated Reports from Automated Tools: Findings from automated scanning tools without manual verification and exploitation proof.
Attacks Requiring Physical Access: Any attack that requires physical access to a user's device.
Clickjacking Using Iframes: Vulnerabilities related to framing the application within iframes (clickjacking) are excluded as these are addressed by our security headers and Content Security Policy.
Zero-day issues are not valid for five days after the CVE is publicly disclosed.
Tools which are not live as yet or develop and staging vulns if not present in prod.
Documentation/Minor Issues
No Unauthorized Testing on Production Environments:
Do not test vulnerabilities on mainnet or public testnet deployments without prior authorization. Use local test environments or private test setups.
We can setup a test environment upon request.
No Public Disclosure Without Consent:
Do not publicly disclose details of any vulnerability before it has been addressed and you have received written permission to disclose.
No Exploitation or Data Exfiltration:
Do not exploit the vulnerability beyond the minimum steps necessary to demonstrate the issue. Do not access private data, engage in social engineering, or disrupt service.
No Conflict of Interest:
Individuals currently or formerly employed by LI.FI, or those who contributed to the development of the affected code, are ineligible to participate.
The report must include:
To be eligible for a reward, you must meet the following requirements:
Vulnerability Requirements
Discover Original Vulnerabilities: Submit previously unreported, in-scope vulnerabilities that aren't publicly known.
First Reporter Advantage: Be the first to report a specific vulnerability through proper channels.
Provide Clear Reproduction Steps: Include detailed information allowing our team to verify and fix the issue.
Responsible Disclosure: Report privately without public disclosure or exploitation for personal gain.
Minimize Impact: Take reasonable precautions to avoid data loss, privacy violations, or service disruptions.
Researcher Requirements
Vulnerabilities are classified using two factors: Impact and Likelihood. The combination of these factors determines the severity and guides the reward amount.
Risk Classification Matrix
Severity Level | Impact: Critical | Impact: High | Impact: Medium | Impact: Low | Likelihood: High | Critical | High | Medium | Low | Likelihood: Medium | High | High | Medium | Low | Likelihood: Low | Medium | Medium | Low | Informational |
Critical:
An issue that results in losses (by stealing, wasting or permanently freezing) amounting to 50%-100% of the daily total user transfers across all EVM chains supported by LI.FI.
Governance
High:
An issue that results in losses (by stealing, wasting or permanently freezing) amounting to 20%-50% of the daily total user transfers across all EVM chains supported by LI.FI.
Medium:
An issue that results in losses (by stealing, wasting or permanently freezing) amounting to 0.5%-20% of the daily total user transfers across all EVM chains supported by LI.FI.
Issues that could impact numerous users and have serious reputational, legal or financial implications
Low/Informational:
Minimal direct risk but may indicate areas for improvement.
Likelihood Definitions:
The following list is examples of where a vulnerability might sit. This is not definitive and each vulnerability reported will be a assessed based on its actual impact.
Critical
For Website
Remote code execution (RCE) on production servers
SQL injection leading to full database access
Authentication bypass allowing unrestricted access to admin functionality
Ability to access, modify, or delete other users' data without authorization
Stored cross-site scripting (XSS) in high-traffic areas affecting multiple users
Session fixation/hijacking allowing complete account takeover
CSRF vulnerabilities that can change critical account settings or perform privileged actions
Vulnerabilities exposing PII (personally identifiable information) of multiple users with a single call
Insecure direct object references (IDOR) affecting sensitive data
Upload functionality allowing execution of malicious files
WebApp
Authentication bypass allowing unrestricted API access
Authorization flaws allowing access to other users' data or functionality
Injection vulnerabilities (SQL, NoSQL, etc.) with significant data exposure
Broken access controls leading to privilege escalation
API keys or secrets exposure in responses
Rate limiting bypass that could lead to service disruption
Business logic flaws allowing unlimited resource consumption
Insecure deserialization vulnerabilities
Server-side request forgery (SSRF) with access to internal systems
Side-channel attacks revealing encryption keys or sensitive data
High Impact
Website
Stored XSS in less critical areas
Reflected XSS requiring minimal user interaction
CSRF vulnerabilities affecting important but non-critical functions
Open redirects with potential for sophisticated phishing
Username/email enumeration combined with weak rate limiting on login
Insecure password reset functionality
Web Cache poisoning leading to injection of malicious code
Clickjacking vulnerabilities on sensitive functions
Unvalidated redirects to malicious sites
Moderate information disclosure of system information
WebApp
Medium Impact
Website
DOM-based XSS requiring complex user interaction
Reflected XSS with limited impact
CSRF in non-sensitive functions
Clickjacking on non-sensitive pages
Weak password policies
Username/email enumeration
Web Cache poisoning leading to significant user disruption
Overly verbose error messages revealing implementation details
Insecure cookie settings (missing Secure/HttpOnly flags)
Mixed content warnings
WebApp
Lack of proper HTTPS implementation
Missing rate limiting on non-critical endpoints
Verbose error messages revealing implementation details
Inconsistent authorization checks
Web Cache poisoning leading to significant user disruption
API versioning issues causing backward compatibility problems
Response manipulation weaknesses
HTTP method overriding issues
Low Impact
Website
Self-XSS (requiring significant user interaction)
Cross-site request forgery (CSRF) on non-sensitive actions
Minor client-side security issues with limited impact
Minor information disclosure (versions, technology stack)
Missing but non-critical security headers
Expired SSL/TLS certificates
Lack of DNSSEC
Lack of HTTP Strict Transport Security (HSTS)
Minor issues with content security policy
WebApp
Risk Score | Payout Range | Critical | $100,000 to $1,000,000 | High | $10,000 to $100,000 | Medium | $5,000 to $10,000 | Low | Discretionary |
Rewards are capped at 10% of the funds impacted
Risk Score | Payout Range | Critical | $10,000 to $25,000 | High | $1,000 to $10,000 | Medium | $500 to $1,000 | Low | Discretionary |
Risk Score | Payout Range | Critical | $2,500 to $7,500 | High | $1,000 to $2,500 | Medium | Up to $1,000 | Low | Discretionary |
Risk Score | Payout Range | Critical | $1,500 to $2,500 | High | $750 to $1,500 | Medium | Up to $750 | Low | Discretionary |
Note: Actual reward amounts are determined at LI.FI’s sole discretion. Factors influencing payout include quality of report, completeness, and the severity and exploitability of the vulnerability.
By submitting a report, you grant LI.FI the rights necessary to investigate, mitigate, and disclose the vulnerability. Reward decisions and eligibility are at the sole discretion of LI.FI. The terms, conditions, and scope of this Program may be revised at any time. All participants are responsible for reviewing the latest version before submitting a report.