Quantum Audit Logo
Launch App

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

Is Pendle Safe?

PENDLEEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance2/10Upgrades6/10Checks passed5 of 7Findings3 Info3
SummaryAI Copilot

This audit was conducted on the provided Solidity source code, which consists of OpenZeppelin's Address.sol library and IERC20.sol interface.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
56.3%Contracts13.8%Wallets30.0%Everyone else
56.3%Contracts13.8%30.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
70.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking56.3%
  • Walletsanonymous holders, free to sell13.8%
  • Everyone elsethe rest of the supply30.0%
Effective concentrationwhat the score reads36.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$449.0K across 13 pairs
Show 4 more pairs

The 3 remaining pairs hold $370 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$210.9KShare of depth47.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x4c9f…fb01

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

Security Findings

3 Info
Info

Limitations of Address.isContract Function

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Info

Reentrancy Warning in Address.sendValue

The 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.I-02

Issue

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

Fix

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

Status

Unresolved

Info

Use of Low-Level Calls and Inline Assembly

The 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.I-03

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical10/10Low risk

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.

Governance2/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

For the full PENDLE token implementation, it is crucial to ensure that all custom logic adheres to the highest security standards, including rigorous testing and formal verification.

Developers should carefully consider the implications of using library functions, especially those that transfer control or value, and implement appropriate reentrancy guards and access controls. A comprehensive audit of the complete PENDLE token contract, including its specific business logic and interactions with external protocols, is strongly recommended to identify and mitigate any project-specific vulnerabilities.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age1y
Contract0x8085…a827
Deployer0x196e…af62
Badge for your website
Pendle security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202634Low
  2. Sep 2, 202650Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
Wrapped SOLSOL · Ethereum34LowBasic Attention TokenBAT · Ethereum34LowHookVolveHVOLVE · Ethereum34LowStarmanEthereum33LowDecentralandMANA · Ethereum35MediumOsaka ProtocolOSAK · Ethereum35Medium

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 Is this your token? Publish your own audit on this page