Pendle Bounty
Total reward
$2,000,000
Deposit required
$50
Findings submitted
53
Start date
14 Jun 2024
Please sign in as a researcher to join the bounty.
Log inPendle is the first protocol that enables the trading of tokenized future yield on an AMM system. The project aims to give holders of yield-generating assets the opportunity to generate additional yield and to lock in future yield upfront, while offering traders direct exposure to future yield streams, without the need for an underlying collateral.
Further resources about Pendle can be found at pendle.finance
The bug bounty program is focused around its smart contracts and is mostly concerned with the loss of user funds.
Upfront Expectations
We aim for reports with a clear, actionable outcome. A report is eligible for a reward under this program only if all of the following are true:
- The report demonstrates an exploitable issue within in-scope Pendle V2 contracts that can result in loss of user funds (or an equivalent direct financial impact, such as permanent fund freeze).
- The report includes clear reproduction steps and a credible impact assessment.
- The report proposes an actionable remediation or mitigation (code-level or operational), sufficient for the Pendle team to evaluate.
- The issue is confirmed by the Pendle team under the rules of this program (including scope and eligibility criteria).
Please see the Out of Scope section for additional details.
SEAL Safe Harbor (Active Exploits)
Pendle has adopted the SEAL (Security Alliance) Whitehat Safe Harbor framework. Safe Harbor is intended for active exploits (i.e., hacks-in-progress), where whitehats may need to intervene to rescue funds and return them with clear pre-authorization and rules of engagement.
Authoritative references (please read these first):
- Overview: https://frameworks.securityalliance.org/safe-harbor/overview/
- Scope terms / definitions: https://frameworks.securityalliance.org/safe-harbor/scope-terms
- Pendle’s Safe Harbor registry entry (contacts, terms, recovery details): https://safeharbor.securityalliance.org/database/pendle
If you believe an exploit is actively underway
If you intend to perform any rescue actions, you must follow the Safe Harbor requirements and parameters defined in the links above (including where rescued assets must be returned). In particular:
- Coordinate immediately with the Pendle contacts listed in the SEAL registry entry before taking action; and
- Return any recovered assets only to the Asset Recovery Address / recovery destination specified for Pendle under SEAL Safe Harbor; and
- Submit a Safe Harbor report with relevant transaction hashes, timeline, amounts, affected contracts, and a clear explanation of the actions taken.
Outside of active exploit scenarios, please follow the standard rules of this bug bounty program.
Contracts in Scope
The following table contains the addresses of Pendle V2 system contracts across chains where Pendle V2 has been deployed.
Additionally, markets that are whitelisted on the Pendle V2 platform are considered in scope.
-
This includes
StandardizedYieldToken(SY),PendlePrincipalToken(PT),PendleYieldToken(YT),PendleYieldTokenV2(YTv2) andPendleMarket(Market). -
Please note that each asset will have a different SY but the same PT, YT (or YTv2), and Market.
-
The list of currently active and inactive markets can be obtained using the following endpoints from our Backend:
- https://api-v2.pendle.finance/core/docs#/Markets/MarketsSimplifiedController_getActiveMarkets
- https://api-v2.pendle.finance/core/docs#/Markets/MarketsSimplifiedController_getInactiveMarkets
- Markets that are not obtainable by the above endpoints are not whitelisted by us.
- Markets that are inactive or not whitelisted by us will NOT be considered if the vulnerability is isolated in that market only and does not affect the Pendle V2 system or the other markets.
- Markets that are inactive or not whitelisted by us will be considered if the vulnerability has system-wide impact, or impacts on active markets.
-
SY contracts that are not deployed and audited by Pendle Team will NOT be considered.
- To see if a SY contract is deployed and audited by Pendle Team, go to
https://app.pendle.finance/trade/markets/<market_address>/swapand see the market info:
- To see if a SY contract is deployed and audited by Pendle Team, go to
-
The underlying contracts that SY and Market based on are considered out of scope.
Award Levels
| Level | Critical | High |
|---|---|---|
| Max | 1,000,000 USD | 100,000 USD |
| Min | 100,000 USD | 10,000 USD |
Rewards are capped at 10% of economic impact.
Detailed Reward calculation
- For critical/high smart Contract bugs, the reward amount is 10% of the funds directly affected up to a maximum of 1,000,000 USD/100,000 USD respectively.
- The calculation of the amount of funds at risk is based on the time and date the bug report is submitted.
- However, a minimum reward of 100,000 USD/10,000 USD is to be rewarded in order to incentivize security researchers against withholding a bug report.
Cross-Market Limitations
- If multiple markets whitelisted on Pendle can be exploited with the same vulnerability, the fund at risk is the combined sum of the fund that can be stolen across those markets.
Repeatable Attack Limitations
- For smart contracts where the vulnerability exists can be upgraded or paused, only the stolen funds from the first attack is considered the fund at risk.
- For smart contracts where the vulnerability exists can NOT be upgraded or paused, the fund at risk of each attack will be calculated as follows:
- 100% funds that could be stolen from the first attack.
- max(0, 100% - 25% * ⌈t⌉) funds that could be stolen from the subsequent attack, where t is the time from the first attack, in hour (25% funds reduction by hour).
- If the attack has cross-chain impact:
- Among all of the sent transactions across all chain supported by Pendle, the transaction with the lowest block time is consider the first attack.
- Claimable-yields (interests and rewards) that can be stolen by the attacks are also considered fund at risk.
Feasibility Limitations
- Bug reports about an attack that focuses only on the underlying protocol of one of the markets whitelisted on Pendle V2, without any exploits on Pendle V2’s contracts, will NOT be considered for this bug bounty program.
- Even though Pendle V2 users can lose their fund when interacting with Pendle V2, the reason was the exploitation on the underlying protocol, forcing incompatibility with the Pendle V2 system.
- Bug reports that require an attack that involve one or more other protocols (e.g. utilizing flash loans from a margin protocol or manipulating the spot prices on a DEX), either to make an attack more severe than it would be in isolation, or to achieve an attack that would otherwise be impossible or infeasible, would be downgraded by one severity level.
- However, they will be considered as in-scope and categorized according to the program rules as long as all of the following are true:
- Losses or other negative effects of the attack are inflicted upon Pendle V2 users.
- The additional protocols used must have enough liquidity in various assets to allow the attack to succeed at the time of bug report submission. For example: if an attack requires an ETH flash loan, but the amount is larger than all the ETH available for loan across the ecosystem
- However, they will be considered as in-scope and categorized according to the program rules as long as all of the following are true:
Severity levels
For manipulation that can steal/freeze users' funds
| Likelihood/Impact | >1% TVL | < 1% TVL |
|---|---|---|
| High | Critical | High or Critical |
| Medium | High or Critical | High |
For other manipulation
The Pendle team will exercise its discretion, together with the Cantina team, to judge the severity with the aim of awarding fairly to security researchers.
| Likelihood/Impact | Significant | Moderate |
|---|---|---|
| High | High or Critical | High |
| Medium | High | Medium |
Out of Scope (all repositories)
Source files
The source files that are not listed in the "In Scope" section are considered out of scope.
Known Public Issues
Known issues from previous security reviews are considered out of scope.
- pendle-core-v2-public/audits are considered as out-of-scope.
Known but Not Public Issues
The issue is considered out-of-scope if it is already known to the Pendle team, has already been reported, or we have already taken prior steps to mitigate it (including mitigations that are deployed, in progress, or scheduled).
Specific Types of Issues
- Informational findings.
- Pure design preference or theoretical critique without a concrete exploit path against in-scope contracts.
- Issues that are ultimately user errors and can easily be caught in the frontend. For example, transfers to
address(0). - Rounding or precision issues that do not result in material loss of user funds or an exploitable imbalance.
- Relatively high gas consumption.
- Market-risk scenarios where losses arise solely from adverse price movements (with no exploit of Pendle V2 contract logic).
Issues Without Any Actionable Fixes
Along with a clear description and reproduction steps, reports must include an actionable remediation. A remediation can be either:
- A concrete code-level change (patch, pseudo-code, or precise guidance on what to change), or
- A concrete operational/design mitigation that we can realistically adopt (e.g., configuration constraints, process controls, monitoring + response, feature removal/disablement).
A report may be considered out of scope if:
- It does not include a credible remediation or mitigation path, or
- The reported impact relies on a condition that we can reasonably avoid through configuration, operational controls, or design choices (i.e., the protocol is not exposed under intended and reasonably expected operation), or
- The proposed remediation is not feasible to implement or does not meaningfully reduce the reported risk.
We reserve the right to determine whether a mitigation is feasible and "reasonably avoidable" based on intended protocol usage and realistic operational constraints.
Other Types of Severity
Issues that do not have strong impact according to the severity criteria are considered out of scope.
We still encourage researchers to report such issues in good faith, as they can help us improve resilience and user safety. Please see the Goodwill Policy section below.
Goodwill Policy
We still encourage researchers to report issues even if they appear out of scope under this program. Security is our priority, and we’d rather hear about a potential weakness than miss it. Pendle frequently offers goodwill awards for high-quality, well-evidenced reports that identify unusual or previously unknown behaviors affecting the protocol. To date, Pendle has awarded over $20,000 in goodwill to researchers for such reports.
That said, out-of-scope reports are eligible for goodwill awards only at Pendle’s discretion. To keep this channel useful for everyone, we will prioritize submissions that are:
- Clear, reproducible, and show a concrete security impact; and
- Made in good faith (focused on helping us remediate or mitigate the issue, rather than seeking to litigate the interpretation of these rules).
We may close or mark as out of scope reports that are low-signal (e.g., generic best-practices, speculative concerns without a realistic impact, duplicates/known issues, or reports that require long back-and-forth without new technical information).
Prohibited Actions
- Interaction with mainnet or public testnets using real transactions. All testing must be performed on local forks (mainnet or testnet) or in local development environments.
- Target or disrupt third-party systems (e.g., oracle networks, external protocols). Any interactions with third-party contracts must be limited to what is necessary to demonstrate impact on Pendle within a local fork.
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Public disclosure of bugs without the consent of the protocol team.
- Conflict of Interest: any employee or contractor working with Project Entity cannot participate in the Bug Bounty.