Euler Bug Bounty Programme

Euler is a modular lending platform built around the Euler Vault Kit (EVK), which enables permissionless deployment of customised lending vaults, and the Ethereum Vault Connector (EVC), which coordinates accounts and collateral across compatible vaults.

Euler Vault Kit

EVK is a system for constructing credit vaults: ERC-4626 vaults with borrowing functionality. Unlike vaults that actively invest deposits, credit vaults earn yield by lending deposited assets.

Ethereum Vault Connector

EVC provides account, collateral and permission coordination between compatible vaults, allowing lending implementations to share common infrastructure.

Euler Price Oracle

Euler Price Oracle provides modular adapters implementing the quote-based IPriceOracle interface. EulerRouter selects configured pricing sources and supports ERC-4626 share-to-asset resolution through convertToAssets.

Reward Streams

Reward Streams distributes rewards proportionally through staking or tracked balance changes, supporting multiple reward tokens and permissionless creation of reward streams.

Fee Flow

Fee Flow converts fee assets into a single payment token through a continuous, auto-adjusting Dutch auction.

Securitize Vaults

Securitize vaults are collateral vaults for permissioned assets. Their public metadata uses the type securitize.

Euler Earn

Euler Earn is an ERC-4626 vault system that allows curators to allocate a single underlying asset across multiple ERC-4626 strategies.

Synths

The Synths subsystem in the EVK repository includes synthetic-asset contracts, Euler Savings Rate (ESR), associated hooks and interest-rate models, and a peg-stability module.

Eligibility

To qualify for a reward, you must:

1. Identify an in-scope vulnerability that has not already been publicly disclosed or established by an earlier report.
2. Be the first to submit sufficient information to independently verify the distinct vulnerability and its impact. A proposed fix is not required.
3. Report privately through Cantina and follow the programme's testing and disclosure requirements.
4. Avoid unauthorised live exploitation, profiting from the vulnerability, privacy breaches, data destruction or disruption.
5. Not re-report the same underlying vulnerability for an additional reward; the known-issue and aggregation rules below apply.
6. Refrain from unlawful conduct, threats, coercion and demands for payment outside the programme.
7. Be at least 18 years old, or participate with parental or guardian consent where permitted by law and Cantina's requirements.
8. Be legally eligible to receive payment, including under applicable sanctions restrictions such as OFAC requirements.
9. Disclose relevant employment or engagement relationships and meet the conflict-of-interest rules below.

Current and former employees of Euler Foundation or Euler Labs and active contractors/vendors of either entity are excluded. Former contractors/vendors are excluded unless they were external security auditors or researchers, who may qualify across all in-scope systems, including the web interface, after their engagement ends. Findings known from, reported under or owed under a paid engagement, and vulnerabilities the researcher introduced, remain ineligible. Resolve uncertain conflicts before participating.

Scope

Smart-contract coverage follows the system-specific scope below and requires a defect in a listed implementation causing an eligible security impact. A repository listing does not include every branch, file, deployment or external integration.

Steps for Security Researchers

1. Identify the system. Check the repositories and system-specific scope below.

2. Find the deployment. Use Euler Contract Addresses to identify production networks and deployed components. A listed development deployment, test network or unrelated component is not included in scope.

3. Check vault eligibility. For EVK-family, Euler Earn and Securitize vaults, query is-known with the chain ID and vault address. Omit addresses to retrieve the known set for a chain. Eligibility is determined by Euler's records of the known set at initial submission of the finding report. The endpoint reflects those records; where the two differ, Euler's records govern.

   curl 'https://app.euler.finance/api/public/is-known?chainId=<chainId>&addresses=<vault-address>'

4. Identify the vault type, if needed. Query metadata to distinguish EVK, Euler Earn and Securitize vaults. Use is-known, not metadata, to determine vault eligibility.

   curl 'https://app.euler.finance/api/public/metadata?chainId=<chainId>&addresses=<vault-address>'

5. Match the affected code and impact to scope. Apply the system-specific scope and exclusions below. For pre-deployment Synths, follow its source-scope rules instead of deployment and vault checks.

See the public API documentation for formats, caching, address validation and request limits.

A known-vault verdict does not certify the safety of its assets, configuration, oracle, IRM, hooks, liquidity or market conditions. Third-party-operated vaults can qualify; their operators' unrelated systems do not.

Repositories and Systems in Scope

Coverage includes eligible vault implementations and the listed Euler components they rely on, including their factories and implementation dependencies. A component relied on by an eligible vault need not itself appear in the vault-only is-known endpoint.

Reward category	Covered implementation
Core Components	EVC, EVK excluding Synths, and Euler Price Oracle
Supporting Components	Reward Streams and Fee Flow (independently covered)
Euler Earn	Euler Earn
Securitize Vaults	src/Vault/deployed/ERC4626EVCCollateralSecuritize.sol in EVK Periphery
Synths	src/Synths in EVK, including ESR

Reward Streams findings are eligible only when the defect harms an in-scope EVK vault or its users' positions in that vault. This includes harm that reaches users who have opted in to Reward Streams, for example by enabling balance forwarding. Findings whose impact is limited to Reward Streams' own reward accounting, distribution or token holdings are excluded.

Production findings must affect either an eligible vault or a component expressly listed as independently covered. Deployment in Euler Contract Addresses alone does not establish independent coverage. Production findings are assessed against the deployed implementation and matching source version.

EVK Periphery contracts other than the Securitize vault listed above, including governors, hook targets and other periphery components, and external protocols, tokens, vaults or hooks are not covered, even where a covered contract interacts with or relies on them. A defect in a covered implementation reached through such a contract is assessed under Classification and Aggregation.

Pre-deployment Synths findings must identify the default-branch commit at initial submission of the finding report and demonstrate the issue locally in a supported configuration; they use the non-monetary reward table.

Scope and terms are assessed at the initial submission of the finding report; subsequent fixes, delisting or programme changes do not disqualify it.

Website in Scope

https://app.euler.finance only, including its production frontend and Euler-operated application/API functionality served through that origin.

Other origins, direct backend hosts, staging, deprecated applications, marketing sites and infrastructure are excluded. Third-party wallets, extensions, RPCs, identity providers and other services are not authorised testing targets. A defect in the in-scope application remains assessable when a library or external interaction contributes to it; the third-party system itself remains excluded.

Severity

Assess the most serious demonstrated eligible consequence and realistic exploitability: permissions, capital, transaction ordering, repeatability, external assumptions and recovery. Assess exploit prerequisites under likelihood; impossible or purely hypothetical conditions do not establish eligibility. Low, informational, cosmetic and best-practice-only findings receive no standard reward.

Smart Contracts

Severity follows Cantina's bug bounty impact × likelihood matrix, applied with the impact and likelihood definitions below. Where these definitions differ from Cantina's standard, these govern. Assess impact and likelihood separately, then use the matrix to determine the reward tier.

Impact

• Critical: catastrophic harm, such as severe asset loss, insolvency or permanent disruption of essential operations.
• High: significant, but not catastrophic, financial loss or disruption of essential operations.
• Medium: limited financial loss or moderate disruption.
• Low: minor loss or non-critical functionality impact.

Assess the loss across the accounts and assets the report demonstrates or specifically identifies, including feasible repetitions against assets present at initial submission; Euler may extend the assessment to further affected assets at its discretion. Loss of principal alone does not establish High or Critical impact; consider its magnitude relative to the in-scope assets of the affected reward category, its duration and its recoverability. A disruption or freeze that Euler or another authorised party can reverse, including through a factory upgrade or governance action, is not permanent.

Likelihood

• High: readily exploitable with few prerequisites and minimal or no victim interaction.
• Medium: exploitable under specific, realistically attainable conditions or with required victim interaction.
• Low: exploitable only under unlikely or restrictive conditions, or with substantial victim interaction.

Assess permissions, available capital, transaction ordering, external dependencies and any deployment-specific configuration the exploit requires, including a configuration that already exists in production. Impossible prerequisites do not establish a valid exploit.

Likelihood / Impact	Critical	High	Medium	Low
High	Critical	High	Medium	Low
Medium	High	High	Medium	Low
Low	Medium	Medium	Low	Informational

Web Interface

Severity	Impact
Critical	Production application/security-boundary compromise enabling direct theft, unauthorised control of user transaction/signature requests, or comparable systemic compromise
High	Material compromise below Critical, including attacker-controlled code in a sensitive production context, unauthorised privileged actions or substantial confidential user/system-data access
Medium	Concrete but limited confidentiality, integrity or authorisation failure below High

XSS, SQL injection, SSRF, CSRF and authentication bypass are classified by consequence, not their names. Demonstrate the attack path, required user interaction and remaining wallet protections; misleading text alone is insufficient.

Rewards

The programme has a total reward budget of USD $1,500,000, allocated to eligible reports on a first-come, first-served basis by report submission time.

All amounts are USD-denominated maximums. There are no guaranteed minimums.

Euler Foundation retains final discretion over report eligibility, severity, impact assessment and reward amounts, applying this programme's rules and Cantina's applicable review and mediation procedures.

Findings with Quantifiable Economic Impact

Reward: up to the lesser of 10% of Eligible Economic Impact and the applicable maximum.

System	Critical maximum	High maximum	Medium maximum
Core Components	$1,500,000	$500,000	$200,000
Supporting Components	$100,000	$50,000	$25,000
Euler Earn	$500,000	$250,000	$100,000
Securitize Vaults	$100,000	$50,000	$25,000
Synths	$25,000	$10,000	$5,000

This table requires an eligible live deployment with demonstrable economic exposure.

Eligible Economic Impact

Eligible Economic Impact is the realistically achievable USD loss to other participants' in-scope assets or covered protocol assets that the report demonstrates or specifically identifies, assessed using production state at initial submission of the finding report. Euler may extend it to further affected assets at its discretion. If an earlier private notification prompted mitigation before submission, use the state immediately before that mitigation.

• Include feasible repeated exploitation against assets present at initial submission, but exclude attacker-funded losses, assets deposited after submission and hypothetical future exposure.
• Count each underlying loss once and account for available recovery. Each participant's loss is measured net of any obligation the same exploit releases them from; for example, a borrower whose collateral is taken loses the collateral less the debt they are no longer bound to repay.
• Value losses at the lower of an independently supportable price and the value that could be realised by selling the affected amount at submission, not prices distorted by the exploit. Assets without an independently supportable price are valued at zero.
• A freeze that Euler or another authorised party can reverse is valued at 10% of the frozen principal; a freeze that cannot be reversed is valued at the full principal.
• Exclude value already lost or impaired before initial submission, such as existing bad debt.

Findings without a Defensible Monetary Valuation

System	Critical maximum	High maximum	Medium maximum
Core Components	$200,000	$100,000	$50,000
Supporting Components	$25,000	$10,000	$5,000
Euler Earn	$100,000	$50,000	$25,000
Securitize Vaults	$25,000	$10,000	$5,000
Synths	$25,000	$10,000	$5,000

Applies only to eligible security impacts that put no valued assets at risk. A consequence affecting assets with a monetary value, including freezing them, is assessed under Findings with Quantifiable Economic Impact. A finding that puts valued assets at risk but whose Eligible Economic Impact cannot reasonably be determined is also assessed under this table. Assess duration, repeatability, affected functionality, exposure, attacker requirements, recovery options and recovery burden. The award reflects the exposure affected, not severity alone, and the award decision must explain the amount.

A root cause can lead to several consequences. Where they are alternatives for the same assets, for example where an attacker can either take a vault's funds or freeze them, only the most severe is assessed. Consequences are combined only when they affect different assets and can be achieved together, and combined consequences are valued together under the economic-impact rules. Where a finding is assessed under both the economic-impact and the non-monetary rules, it receives the higher of the two awards, never their sum.

Classification and Aggregation

• The defective implementation determines the system category, not the product used to reach it. Eligible EVC/EVK defects reached through another product may qualify as Core; defects in a supporting component do not become Core merely because EVK uses it.
• One root cause is one finding. Within a reward category, aggregate demonstrated non-overlapping impact without stacking chain, deployment or system ceilings.
• Where one root cause affects defective implementations in multiple reward categories, assess each category's demonstrated impacts under its own severity and reward rules. The finding receives the highest of the resulting awards, never their sum.
• Independent defects are assessed separately. An inseparable chain requiring independent defects across systems, with inseparable loss, uses the highest applicable single system/severity ceiling, not the sum. Correctly functioning components do not supply a higher ceiling.

Web Interface Rewards

Severity	Maximum reward
Critical	$25,000
High	$5,000
Medium	$1,000

Awards depend on demonstrated impact, reach, exploitability, required user interaction and affected privileges. No minimum or 10% formula applies.

Payment

• Core Components: first $750,000 in USDC; any remainder in rEUL.
• All other awards: USDC.
• USDC conversion: one USDC per award dollar.
• rEUL valuation: underlying EUL entitlement valued at the EUL/USD 30-day volume-weighted average price (VWAP), using CoinMarketCap, over the 30 complete UTC days before the date of initial submission of the finding report.
• If the required pricing data are unavailable or materially unreliable, agree an alternative source or calculation method for the same period before determining the token amount.

Out of Scope

Known and Previously Reported Issues

• Findings are excluded where dated evidence predating initial submission establishes the same underlying defect affecting a materially equivalent security boundary and consequence, including in another deployment.
• Known issues require dated evidence: a prior report (including non-public reports made by Cantina or submitted through it), security review, open PRs, code comment, documentation or whitepaper. General risk references are insufficient; prior internal knowledge requires contemporaneous evidence.
• Independent defects, regressions and ineffective fixes are assessed separately. Additional impact or a different exploitation technique does not by itself establish an independent defect.

Contracts

• Code outside the system-specific scope; test or deployment-tooling defects without eligible impact on covered implementation code.
• Gas, code-quality, standards-compliance and ERC-20/ERC-4626 compatibility findings without demonstrated security impact; theoretical findings without a feasible exploit.
• Expected consequences of documented governance powers, economic settings or trust assumptions, including authorised governor/deployer misconfiguration.
• Failures solely in third-party code or services, chain reorganisations, consensus/network-liveness failures or sequencer downtime, without a separate covered implementation defect.
• Expressly unsupported token behaviours, including relevant non-standard ERC-20 behaviours, rather than flaws in handling supported configurations.

Configuration and external-dependency risks are excluded, but independent defects in covered Euler code remain eligible. Configuration exclusions concern the victim's authorised choices, not an attacker's use of its own controller, vault, callback, token or hook.

Euler Price Oracle

Excluded when caused by configuration or external trust assumptions, rather than a covered implementation defect:

• Incorrect addresses, base/quote assets or decimals; unsupported network combinations or missing sequencer-liveness protection.
• Insecure spot prices, manipulable ERC-4626 conversions (including donation-sensitive convertToAssets), or unsuitable market-hours feeds.
• External provider failures, upgrades, permissions, signer changes, censorship or delivery failures.
• Pyth/RedStone frontrunning or censorship addressed by the supported atomic price-update-and-use flow.

Web Interface

• Performance, cosmetic and ordinary UI defects without security impact; clickjacking or CSRF without a sensitive action or meaningful security consequence.
• Self-XSS, text injection or spoofing without a credible attack on another user.
• DoS findings.
• Rate-limit/brute-force, version, TLS or provider-path observations without demonstrated security impact; scanner output without reproducible application-specific evidence.
• Issues requiring unsupported, obsolete or attacker-modified browsers/extensions, or physical device access.
• Third-party service, wallet, extension or infrastructure defects without an independent covered-application defect; recently disclosed third-party vulnerabilities without a distinct covered-code vulnerability.
• Intentionally public data and cross-origin access without a confidentiality or authorisation violation.

System Roles and Privileges

• Protocol and registry administrators: documented factory-upgrade/configuration powers and management of assigned oracle-adapter, external-vault and IRM registries, respectively.
• Vault creators/governors: their vault configuration and collateral/pricing choices. EulerRouter governors: their pricing-source configuration and maintenance.
• Earn curators: documented strategy-selection and allocation powers.
• Issuers, eligibility administrators and synth owners/minters: documented powers over their own assets and systems.
• Regular users and unrelated accounts: untrusted.

Trust is limited to each actor's authority and resources. Authorised actions within that boundary and credential compromise without an in-scope defect are excluded; unauthorised role acquisition, permission bypass, privilege escalation and cross-account/vault isolation failures remain assessable.

Prohibited Actions

• Active vulnerability testing or exploitation on public mainnets/testnets without prior written authorisation; read-only inspection is permitted.
• Moving, seizing, destroying or holding real third-party funds, or manipulating live markets.
• Accessing, modifying, destroying or enumerating third-party data beyond minimum unavoidable evidence during permitted research.
• DoS, resource exhaustion, high-volume scanning or disruptive testing.
• Testing out-of-scope or third-party systems without separate authorisation from the responsible party.
• Phishing, social engineering, physical intrusion, threats or coercion.
• Public disclosure or unauthorised sharing without the protocol team's written consent, subject to Cantina's applicable requirements.

Testing Guidelines

1. Use isolated local environments or forks for contract findings.
2. Researchers may perform minimal, non-disruptive security testing of the in-scope web application using accounts and data they control, subject to the prohibited actions.
3. For web-interface reports, source-code findings must demonstrate an eligible impact in the production application.
4. Model real permissions; do not manufacture attacker authority. Identify simulation-only changes and their realistic counterparts.
5. Respect API rate limits. On unexpected sensitive-data access, stop, retain minimum evidence securely and report privately.
6. Provide the affected chain/address/version/block or web URL, scope evidence, preconditions, reproducible steps, impact calculations and recovery assumptions, as applicable. Exclude unrelated personal data and unnecessary secrets.
7. Obtain permission before uncertain tests; programme participation does not exempt research from applicable law.