level-bug-bounty

Level is a stablecoin protocol that issues lvlUSD, a stablecoin that is fully backed by USDC and USDT generating yield from blue-chip lending protocols like Aave and soon Morpho. Level has consistently provided higher yield than most major yield-bearing stablecoins while only generating yield from low risk lending protocols. Level also offers increased utility and capital efficiency by being deeply integrated into leading DeFi protocols like Morpho, Pendle and Spectra.

Scope

In-Scope Targets:

• Core Contracts:

  • Repository: https://github.com/Level-Money/contracts
  • Hash: 0e86345fed4e84d3cb24ed73cca5d4d11b504430
  • Files:
    • src/v2/*
    • script/v2/*
    • src/v1/lens/*
    • src/v1/lvlUSD.sol
    • src/v1/StakedlvlUSD.sol
    • src/v1/slvlUSDSilo.sol

• Web Interface / Application:

  • https://level.money
  • https://app.level.money

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:

• Smart Contracts:

  • Any v1 directories in https://github.com/Level-Money/contracts, unless they are dependencies of v2:
    • src/v1
      • Excluding:
        • src/v1/lens/*
        • src/v1/lvlUSD.sol
        • src/v1/StakedlvlUSD.sol
        • src/v1/slvlUSDSilo.sol
    • script/v1
    • test/v1
  • Any issues surfaced in prior audits, which can be found here: https://level-money.gitbook.io/docs/technical-documentation/audits
    • Any unfixed vulnerabilities mentioned in these reports are not eligible for reward
  • Any previously-discovered bugs, including known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.
  • Every issue opened in the repo, closed PRs, previous audits or contests
  • Specific issues:
    • Informational findings, including typos, documentation discrepancies, msising events, missing zero-address checks, and non-critical missing input validation
    • Design choices related to the protocol (ie using permissioned addresses to manage reserves)
    • Issues that can be solved by the protocol updating its reserve management criteria (ex: issues caused by deploying into low-liquidity Morpho vaults, which the protocol can simply choose not to allowlist)
    • Issues that ignore trust assumptions (ie data supplied by third party oracles)
    • Issues caused by attacks requiring excessive social engineering to acquire special privileges, including leaked keys/credentials or RBAC roles, except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
    • Issues caused by Sybil attacks
    • Issues involving centralization risk
    • Any secrets/access tokens/API keys/private keys that are not being used in production
    • User errors that can be easily caught in the frontend
    • Rounding errors
    • Any errors that can be solved with a call to BoringVault.manage() by the admin timelock (ex: claiming rewards from Aave)
    • Relatively high gas consumption
    • Vulnerability stemming from extreme market turmoil
    • Dev branches
    • Suggestions for best practices
    • Known issues under remediation
    • Feature requests

• Website/App:

  • Theoretical impacts without any proof or demonstration.
  • Impacts involving attacks requiring physical access to the victim device.
  • Impacts involving attacks requiring access to the local network of the victim.
  • Reflected plain text injection (e.g. url parameters, path, etc.).
  • This does not exclude reflected HTML injection with or without JavaScript.
  • Open ports with no proven risk (e.g., port 22 open on SSH with key-based authentication).
  • Lack of security headers (e.g., missing CSP, X-Frame-Options, HSTS, unless proven to be exploitable).
  • Stack traces & error messages (unless they leak sensitive information).
  • Captcha bypass using OCR without impact demonstration.
  • Impacts causing only the enumeration or confirmation of the existence of users or tenants.
  • Impacts caused by vulnerabilities requiring un-prompted, in-app user actions that are not part of the normal app workflows.
  • Lack of SSL/TLS best practices.
  • Impacts that only require DDoS.
  • UX and UI impacts that do not materially disrupt use of the platform.
  • Impacts primarily caused by browser/plugin defects.
  • Leakage of non sensitive API keys (e.g. Etherscan, Infura, Alchemy, etc.).
  • Any vulnerability exploit requiring browser bugs for exploitation (e.g. CSP bypass).
  • Publicly accessible .git directories (if no sensitive files are exposed).
  • SPF/DMARC issues (unless there is active email spoofing that affects Story Protocol users).
  • Outdated software without a working proof of concept (e.g., reporting "Nginx 1.18.0" without showing an exploit).
  • Clickjacking on non-sensitive pages (e.g., informational pages).
  • Self-XSS (XSS that only affects the person reporting it).
  • CSRF (Cross-Site Request Forgery) on blockchain transactions (since blockchain transactions require explicit user signing).
  • CORS misconfigurations that do not allow credential theft or sensitive data exposure.
  • Rate-limiting issues on public, non-sensitive APIs (e.g., public block explorer APIs).
  • Missing email verification (since Web3 users often rely on wallet authentication rather than email-based login).
  • Login/logout CSRF (only relevant if authentication relies solely on cookies, which is less common in Web3).
  • Session fixation (not relevant if the system uses stateless authentication like JWTs).

Prohibited Actions

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

• 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 [Program Name/Company], or those who contributed to the development of the affected code, are ineligible to participate.

Disclosure Requirements

Report must include:

• A clear description of the vulnerability and its impact.
• Steps to reproduce the issue, ideally with a proof of concept.
• Details on the conditions under which the issue occurs.
• Potential implications if the vulnerability were exploited.

Reports should be made as soon as possible—ideally within 24 hours of discovery.

Eligibility

To be eligible for a reward, you must:

• Be the first to report a previously unknown, non-public vulnerability within the defined scope.
• Provide sufficient information to reproduce and fix the vulnerability.
• Not have exploited the vulnerability in any malicious manner.
• Not have disclosed the vulnerability to third parties before receiving permission.
• Comply with all Program rules and applicable laws.

You must also be of legal age in your jurisdiction and not be a resident in a country under sanctions or restrictions, as required by applicable laws.

Level requires KYC information, including full name, date of birth, and a copy of your passport or other government-issued ID. In addition, you must not:

• Be an OFAC-sanctioned individual or be a part of an OFAC sanctioned entity
• Reside in a country under any trade or economic sanctions by OFAC, or where the laws of the United States or local law prohibits participation
• Have been an official contributor, contractor, or employee of Level
• Be employees or individuals closely associated with Level
• Be security auditors who have participated in the audit review

Severity and Rewards

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

Impact Definitions:

• Critical: Vulnerabilities that can lead to severe loss of user funds, permanent system disruption, or widespread compromise.
• High: Vulnerabilities that cause notable financial loss or significantly harm user trust, but on a lesser scale than Critical.
• Medium: Vulnerabilities that lead to limited financial damage or moderate system impact.
• Low/Informational: Findings that pose minimal direct risk but reflect areas for improvement or best practices.

Likelihood Definitions:

• High: Very easy to exploit or highly incentivized.
• Medium: Exploitation is possible under certain conditions.
• Low: Difficult to exploit or requires highly specific conditions.

Payout Guidelines

• Core Smart Contract Code

Risk Score	Payout Range
Critical	Up to $200,000
High	Up to $50,000
Medium	Up to $10,000
Low	Discretionary

• Web Interface / Frontend

Risk Score	Payout Range
Critical	Up to $25,000
High	Up to $10,000
Medium	Up to $2,500
Low	Discretionary

Note: Actual reward amounts are determined at Level’s sole discretion. Factors influencing payout include quality of report, completeness, and the severity and exploitability of the vulnerability.

Other Terms

By submitting a report, you grant Level the rights necessary to investigate, mitigate, and disclose the vulnerability. Reward decisions and eligibility are at the sole discretion of Level. 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.