Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Pendle's public materials frame the protocol around yield uncertainty in DeFi and position Pendle as a permissionless yield-trading protocol that lets users execute yield-management strategies on top of existing yield-bearing assets. The same public record describes Pendle as bringing interest-rate and fixed-yield style positioning into DeFi through tokenized yield exposure.
(Source: Pendle Docs, PENDLE)
(b) Operational priorities
Public sources show operating priorities around deep and liquid yield markets, incentive design, protocol scaling, and launch or rollout execution. Pendle's tokenomics post says the team allocated the highest percentage to liquidity incentives because it prioritized creating deep and liquid yield markets, and the same post says the team's near-term focus included security audits, testnet optimization, and launch preparation.
(Source: Pendle Tokenomics, Incentives)
(c) High-level project overview
At a high level, Pendle wraps a yield-bearing token into a Standardized Yield (SY) token, then splits that exposure into a Principal Token (PT) and a Yield Token (YT). Public materials state that PT and YT can be traded through Pendle's AMM, that PendleRouter aggregates actions across SY, PT, YT, and markets, and that PendleMarket enables trading between PT and its corresponding SY while also supporting liquidity provision.
(Source: Pendle Docs, High Level Architecture)
(d) Primary token functions
Verified launch-era materials state that $PENDLE is the protocol's ERC-20 native token and that it launched as a utility token, with governance functions intended to come later as the protocol matured. Current protocol documentation states that sPENDLE is Pendle's native governance token, that it is the staked version of PENDLE, that PENDLE may be staked 1:1 into sPENDLE, and that active sPENDLE holders receive protocol rewards funded through buybacks and other distributions.
(Source: sPENDLE, Pendle Tokenomics)
(e) Control surface reliance
The public record shows an evolving governance and control surface rather than a fully static one. Pendle's launch-era tokenomics materials said the team would decide incentive distribution at the beginning and that the system would evolve into community governance or a veCRV-like mechanism as the protocol matured. Current materials state that sPENDLE holders vote on Pendle Protocol Proposals (PPP), that vote snapshots determine governance power, that PendleRouter has no special permissions or whitelists, and that market contracts are immutable while newer SY contracts are upgradable proxies.
(Source: sPENDLE, Pendle Tokenomics)
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
TN Lee | Co-founder and CEO. | TN Lee entered the crypto space around 2017, with early experience as a research assistant exploring fintech. |
Vu Nguyen | Co-founder and CTO. | 3-time Math Olympiad gold medalist and was previously in charge of smart contract development at Digix, a project focused on tokenizing gold |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
No foundation exists for PENDLE. | N/A | N/A |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
No DAO exists for PENDLE | N/A | N/A |
(Source: Pendle Integrates Chainlink, Zenith)
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
No DAO exists for PENDLE.
(b) Contract/admin powers
No DAO exists for PENDLE.
(c) Locked-token rights (conditional)
No DAO exists for PENDLE. The PENDLE team disclosed that sPENDLE will carry governance voting rights for protocol improvements.
(d) Value accrual & holder rights
No DAO exists for PENDLE.
(e) Dissolution authority
No DAO exists for PENDLE.
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
No foundation exists for PENDLE.
(b) IP ownership & control
No foundation exists for PENDLE.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No foundation exists for PENDLE.
(d) Powers over DevCo
No foundation exists for PENDLE.
(e) Contract/admin powers
No foundation exists for PENDLE.
(f) Current economic arrangements and distribution policies
No foundation exists for PENDLE.
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Public sources identify Univerum Innovations Inc. as the operator of the Website and the Pendle Protocol. The public record states that Univerum Innovations Inc. is established under the laws of the Republic of Panama. The public record does not disclose the entity's legal type beyond its incorporation jurisdiction, nor does it identify any subsidiary entities.
(Source: Terms of Use, Privacy Policy)
(b) IP ownership & control
The public record does not attribute IP ownership to Univerum Innovations Inc. by name. The public codebase record discloses that the primary license for Pendle Core (V1) smart contracts is the Business Source License 1.1 (BUSL-1.1), under which core contracts including PendleRouter.sol and PendleData.sol are published. Pendle Core V2 smart contracts are also published under BUSL-1.1. Under BUSL-1.1, the licensor retains commercial control over the source code while making it source-available; the licensor is identified in the repository as the pendle-finance GitHub organization. Subsidiary entities, trademark registrations, and brand ownership assignments are not disclosed in the verified public record.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DAO exists for PENDLE. The public record discloses that a Governance Multisig address and a Team Multisig address exist as distinct onchain structures holding PENDLE, as referenced in Pendle's tokenomics documentation. The same record discloses that incentive distribution was decided by the team at the outset, and that governance may propose changes to tokenomics as the industry matures. The public record does not disclose the specific multisig thresholds, signer counts, or the scope of actions each multisig can execute. The public record confirms that market contracts are immutable once deployed and that newer SY contracts are upgradable proxies, but does not specify which entity or address holds the upgrade key for those proxies.
(d) Powers over Foundation
No foundation exists for PENDLE.
(e) Contract/admin powers
The public record discloses that Pendle's protocol is controlled by a multisig, characterized by a third-party risk assessment as a 2-of-4 configuration, and that no timelock is documented. The V1 codebase includes a PendleGovernanceManager contract that enforces an onlyGovernance modifier and implements a two-step governance transfer process requiring a pending governance address to claim control before it takes effect. The public record confirms that PendleRouter carries no special permissions or whitelists and that market contracts are immutable, while SY contracts are upgradable proxies. The specific pause authorities, upgrade-executor addresses, and threshold configurations for the current V2 protocol are not disclosed in the verified public record.
(f) Current economic arrangements and distribution policies
The public record discloses that 80% of V2 protocol fees are directed to buybacks distributed to sPENDLE holders, and that the Pendle protocol at the time of legacy documentation distributed all protocol revenue to vePENDLE holders with no allocation to the Pendle treasury, noting that a portion of revenue may be redirected to the treasury in the future. The same record further discloses that undistributed weekly incentive PENDLE is returned to the protocol treasury and does not roll over. The Ecosystem Fund address (0x399Be606db281a054E359Eb709df9F21E922eC9a) is publicly disclosed and described as used primarily for onchain integrations and liquidity bootstrapping. No governance-approved or contractual mechanism directing protocol revenue, treasury assets, or token distributions to Univerum Innovations Inc., its equityholders, or contributors are publicly disclosed.
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch. Include: (a) Launch supply totals — the total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch; (b) Recipient categories & use of funds — the recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket; (c) Initial price per token (if applicable) — the initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so; (d) Ticker / market symbol — the ticker/market symbol; (e) Total supply & supply regime — the total supply and whether the supply is fixed (if not explain inflation rate or deflation rate); (f) Initial vesting / release schedules — the initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
Launch Supply Totals | Recipient Categories & Use of Funds | Initial Price per Token | Ticker / Market Symbol | Total Supply & Supply Regime | Initial Vesting / Release Schedules |
|---|---|---|---|---|---|
The public record discloses that prior to the LDB event on April 28, 2021, no PENDLE tokens were in circulation. At launch, 16,582,875 PENDLE was made available through the LDB, with team and investor tokens remaining locked. The LDB combined with the Ecosystem Fund was stated to represent approximately 16% of the projected year-2 total supply of 251,061,124 PENDLE. A consolidated single-table disclosure of all tokens issued, locked, and unlocked at launch was not published by the team. | The public record discloses six allocation categories: Liquidity Incentives (49.21%), Team (17.74%), Ecosystem Fund (14.83%), Investors (12.07%), Liquidity Bootstrapping (5.35%), and Advisors (0.80%). The team's launch-era tokenomics post describes each category's purpose. Liquidity incentives were prioritized for deep yield markets, the Ecosystem Fund was reserved for future development, team tokens were subject to vesting to align long-term incentives, and investor allocations were distributed so the majority of backers held under 0.4% of supply. A complete filing-style recipient schedule with named recipients and individual token quantities was not published. | No fixed issuer-set offering price was established. The private round price was $0.14 per PENDLE. The LDB on April 28, 2021 used a market-discovery mechanism: the initial ETH/PENDLE ratio was set at 0.00017633 with ETH pegged at $2,552, implying an opening price of approximately $0.45. The LDB closed at $1.71 per PENDLE, reaching a high of $2.15 over the six-hour event, with total ETH raised of approximately $11.83 million. | The ticker disclosed in cited sources is PENDLE. | Verified launch-era materials state that Pendle adopted a hybrid inflation model, beginning with stable incentives of 1.2 million PENDLE per week for the first 26 weeks, followed by a 1% weekly decay until week 260, after which a 2% terminal inflation rate per annum applies to circulating supply. Current documentation says that as of September 2024 weekly emission was 216,076, that it decreases by 1.1% each week until April 2026, and that it then switches to a 2% annual terminal inflation rate for incentives. | The public record confirms that team, investor, and advisor allocations were all subject to vesting schedules. Team tokens vested through April 2023, and the current Pendle documentation confirms that as of September 2024 all team and investor tokens had fully vested. The granular vesting table published in the April 2021 tokenomics post was rendered as an image and its per-category cliff and duration data is not recoverable in text form from the public record. |
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
(b) Executed airdrop
Pendle did not conduct a token-generation-event airdrop. The verified public record shows that the sole token distribution mechanism at launch was the Liquidity Drop Bootstrapping event on April 28, 2021, through which 16,582,875 PENDLE was made available to the public via a market-based price discovery process on Balancer. The verified public record does, however, identify later Merkle-based reward and airdrop distribution surfaces. Pendle's official merkle-distributions repository contains Merkle distributions for different rewards and is organized into three folders: external-rewards, which contains Merkle distributions of additional off-chain rewards for certain pools; vependle-airdrop, which contains an additional airdrop for locking vePENDLE; and vependle, which contains fee rewards for locking vePENDLE. In the external-rewards and vependle-airdrop folders, each distribution includes campaign.json with campaign information and per-user reward breakdowns, and main.json with the Merkle distribution data used to generate the Merkle tree.
(Source: Merkle, Bootstrapping Pendle, Pendle Tokenomics)
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: (a) Market maker's name — the market maker's name; (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply; (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable, (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
No public data found for market-maker agreements, token-loan amounts, term durations, or agreement structures affecting PENDLE liquidity.
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair); (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply; (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable, (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
No public data found for filing-style CEX or DEX listing agreements, token allocations committed for listings, term durations, or native-token listing fees.
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Private round ($3.5M); investors included CMS, DeFi Alliance, Lemniscap, Hashkey Capital, imToken, and Spartan Group | April 16, 2021 | |||
YZi Labs (formerly Binance Labs); OTC purchase | No public token quantity or dollar amount disclosed. | |||
Spartan Capital; follow-on OTC purchase | No public token quantity or dollar amount disclosed. | |||
L1D; OTC purchase | No public token quantity or dollar amount disclosed. |
The verified public source set identifies multiple fundraising rounds, but no round discloses a complete filing-style sale history with investment instruments or token quantities.
(Source: Coin Telegraph, Binance, Tokenomics, Pendle Tokenomics, FXStreet, The Pendle Swings)
Previous Exploits Affecting the Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — Link(s) to post-mortem/advisory/PR.
(c) Quantified impact
No exploit or incident affecting protocol funds was identified. Pendle's risk materials do, however, discuss the relevant failure modes: they state that Pendle contracts being exploited could cause PT to lose value sharply, that underlying yield-bearing protocols can also create loss exposure, and that oracle manipulation or insufficient liquidity during liquidation can create bad-debt risk for integrations. The current security page adds that Pendle smart contracts have been audited by Ackee, Dedaub, Dingbats, and top Code4rena wardens, that all Pendle smart contracts are open source, and that the audit reports are collected in Pendle's GitHub audit repository. The earlier PT-collateral analysis also states that Pendle V2 contracts had been audited by 6 auditors and that no incidents had occurred in Pendle contracts since June 2021. More recent audit artifacts in Pendle's repository show a MarketV6 security review dated September 26, 2025 by HickupHH3 with 0 high, 0 medium, 0 low, and 2 informational findings, plus an sPendle audit report delivered on January 11, 2026 with 5 total issues, including acknowledged findings around cooldown behavior and fee-receiver initialization.
(f) References (optional)
(Source: HickupHH3, WatchPug, High Level Architecture, FAQ, Recommended reading order, Security)
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
- (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
- Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
- Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
- Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
- Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
- (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
- Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
- Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
- (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
- Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
- Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
Pendle's legal materials state that the Website and Pendle Protocol are operated by Univerum Innovations Inc., an entity established under the laws of the Republic of Panama. The Terms define excluded jurisdictions and excluded persons by reference to FATF high-risk jurisdictions, OFAC, EU and UN sanctions lists, and other regulatory restrictions, which means legal or regulatory changes can directly affect who is permitted to access the protocol. The same public legal record states that neither Pendle Protocol nor its affiliates is the user's broker, agent, tax advisor, legal advisor, or fiduciary, and that no communication from Pendle should be construed as investment, financial, tax, or legal advice.
(Source: Terms of Use)
(b) Protocol, Technology & Security Risks
Public technical materials state that Pendle contracts malfunctioning or being exploited could cause PT to lose value quickly and create bad debt for integrations such as money markets. The same record states that each PT is built on an underlying yield-bearing token, so exploits or malfunctions in those underlying protocols can also create losses. Pendle's security posture includes audit coverage and an active bug-bounty surface: the PT collateral analysis says Pendle V2 contracts had been audited by 6 auditors, the current security page says Pendle smart contracts have been audited by Ackee, Dedaub, Dingbats, and top Code4rena wardens and links the audits repository, the core repository says the V2 contracts were audited by six auditors with reports in the audits folder, Pendle maintains a bounty program covering in-scope V2 contracts, the MarketV6 audit dated September 26, 2025 reported 0 high, 0 medium, and 0 low findings, and the sPendle audit delivered on January 11, 2026 reported 5 total issues with a mix of acknowledged and fixed findings for the staking and governance subsystem.
(Source: Recommended reading order, Security, pendle-core-v2-public, Pendle Bounty, HickupHH3, WatchPug)
(c) Token Economics, Unlocks & Incentive Risks
Pendle's token-economics disclosures describe a continuing inflationary incentive regime rather than a permanently fixed supply. Launch-era materials describe 1.2 million PENDLE per week for the first 26 weeks, then 1% weekly decay until week 260, then 2% annual terminal inflation; current docs describe 216,076 weekly emissions as of September 2024, falling by 1.1% each week until April 2026 before switching to a 2% annual terminal rate for incentives. Public materials also show that tokenholder economics depend on participation and fee generation. sPENDLE rewards require active participation in proposal voting when a PPP is live, 80% of V2 fees are allocated to buybacks, and incentive allocation remains an active, algorithmic, and governance-linked process.
(Source: sPENDLE, Incentives, Fees, Pendle Tokenomics, Tokenomics)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.