Quantum Audit Logo

Is Pendle Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Pendle PENDLE
0x8085…a827
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit was conducted on the provided Solidity source code, which consists of OpenZeppelin's `Address.sol` library and `IERC20.sol` interface. The main `PENDLE` token contract, which presumably utilizes these components, was not provided for review. Therefore, the scope of this report is limited to the security and best practices observed in the provided library and interface files, and does not cover the full PENDLE token implementation or its specific business logic.

3 Informational
Volume 24h
$140.3K
Liquidity
$210.9K
Price
$1.9700
Token Age
1y
Top 10 Holders
70.0%

Security Findings

3 Info
Info

Limitations of `Address.isContract` Function

I-01The `Address.isContract` function, which relies on `extcodesize`, has known limitations as explicitly documented within the library itself. It returns `false` for externally-owned accounts (EOAs), contracts in construction, addresses where a contract will be created, or addresses where a contract previously existed but was destroyed. This means `isContract` cannot definitively confirm if an address is an active, fully deployed contract in all scenarios.
IssueThe `Address.isContract` function, which relies on `extcodesize`, has known limitations as explicitly documented within the library itself. It returns `false` for externally-owned accounts (EOAs), contracts in construction, addresses where a contract will be created, or addresses where a contract previously existed but was destroyed. This means `isContract` cannot definitively confirm if an address is an active, fully deployed contract in all scenarios.
FixDevelopers should be fully aware of the documented limitations of `Address.isContract` and avoid using it as a sole definitive check for contract existence, especially in security-critical contexts where precise contract state is required. Consider alternative checks or design patterns if a more robust contract verification is needed.
StatusUnresolved
Info

Reentrancy Warning in `Address.sendValue`

I-02The `Address.sendValue` function, while designed to safely send Ether, explicitly includes a warning about potential reentrancy vulnerabilities if control is transferred to a recipient. This highlights that while the library function itself is secure, the calling contract must implement proper reentrancy protection (e.g., using `ReentrancyGuard` or the checks-effects-interactions pattern) when using `sendValue` to prevent malicious re-entry attacks.
IssueThe `Address.sendValue` function, while designed to safely send Ether, explicitly includes a warning about potential reentrancy vulnerabilities if control is transferred to a recipient. This highlights that while the library function itself is secure, the calling contract must implement proper reentrancy protection (e.g., using `ReentrancyGuard` or the checks-effects-interactions pattern) when using `sendValue` to prevent malicious re-entry attacks.
FixAny contract utilizing `Address.sendValue` (or similar functions that transfer value and control) must implement robust reentrancy protection for functions that modify state after an external call. Adhere strictly to the checks-effects-interactions pattern to ensure state changes occur before external calls.
StatusUnresolved
Info

Use of Low-Level Calls and Inline Assembly

I-03The `Address` library internally utilizes low-level calls (`call`, `staticcall`, `delegatecall`) and inline assembly (e.g., `extcodesize`, `revert` in `_verifyCallResult`). While these are necessary for the library's functionality and are carefully wrapped with safety checks and error handling, direct use of such low-level constructs in custom contract logic can introduce significant security risks if not handled with extreme care. The library itself disables `solhint` warnings for these specific lines, acknowledging their inherent complexity.
IssueThe `Address` library internally utilizes low-level calls (`call`, `staticcall`, `delegatecall`) and inline assembly (e.g., `extcodesize`, `revert` in `_verifyCallResult`). While these are necessary for the library's functionality and are carefully wrapped with safety checks and error handling, direct use of such low-level constructs in custom contract logic can introduce significant security risks if not handled with extreme care. The library itself disables `solhint` warnings for these specific lines, acknowledging their inherent complexity.
FixDevelopers should generally avoid direct low-level calls and inline assembly in their application-specific logic unless absolutely necessary and thoroughly understood. When using functions from the `Address` library, trust that its internal mechanisms are secure, but remain vigilant about the potential dangers if similar patterns are implemented without the same level of rigorous safety checks and error handling.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The provided code, consisting of OpenZeppelin's `Address` library and `IERC20` interface, demonstrates high technical quality and adherence to established security patterns (7.2 Code Security). The `Address` library includes robust functions like `sendValue` to mitigate reentrancy risks and `functionCall` variants with comprehensive error handling, replacing unsafe low-level calls. It also explicitly documents the limitations of `isContract` (7.1 Architecture). While the library internally uses low-level calls and assembly, these are carefully wrapped with checks, ensuring safety within its scope. No direct vulnerabilities were found in the provided code.

GovernanceHigh2/10

Due to the absence of the main PENDLE token contract and any associated governance or economic logic, a comprehensive assessment of governance and economic risks (7.4 Economic, 7.5 Governance) cannot be performed. The provided library and interface files do not contain any governance mechanisms or economic parameters. Assuming the main contract follows standard ERC-20 practices, basic economic risks would be tied to token distribution and liquidity, which are outside the scope of this review.

UpgradesMedium6/10

The provided `Address` library and `IERC20` interface are not designed to be upgradeable contracts (7.7 Upgrades). The pre-analysis indicates that the main contract is not a proxy (`is_proxy: false`), suggesting a non-upgradeable deployment model for the PENDLE token itself. Therefore, upgrade safety concerns are minimal for the scope of this audit, as no upgrade mechanisms were present in the reviewed code.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

70.0% in top 10
13.8% in wallets56.3% in contracts
Effective Concentration36.3%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$449.0K across 13 pairs
Uniswap v3WETHanalysed$210.9K47.0%SushiswapWETH$78.6K17.5%Uniswap v4USDC$64.7K14.4%Uniswap v4ETH$39.6K8.8%Uniswap v4ETH$21.2K4.7%Uniswap v3COMP$20.9K4.6%
Show 4 more pairsShow less
Uniswap v4USDC$8.4K1.9%Uniswap v3USDC$1.9K0.4%0x5F1d…D50aWETH$1.5K0.3%BalancerWETH$9950.2%

The 3 remaining pairs hold $370 between them and are not listed.

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x196e…af62
Unlocked LP Held By
0x4c9f…fb01

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

5 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Top-10 concentration > 30% (70.0% total → 36.3% effective; 13.8% in EOAs, 56.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 47% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 47% of DEX liquidity)

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
StarmanMedium RiskSPX6900 (SPX)Medium RiskPrometheusMedium RiskVERA (VRA)Medium RiskTRIAMedium RiskDimitra Token (DMTR)Medium Risk

Would You Like a More Detailed Audit of Pendle?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit