Quantum Audit Logo

Is Pendle Safe?

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

Pendle PENDLE
0xa99f…eb3e
Base
Not verifiedThis 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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The OptimismMintableERC20 contract implements a standard ERC-20 token designed for cross-chain bridging, allowing a designated bridge contract to mint and burn tokens. The contract leverages OpenZeppelin libraries for core ERC-20 functionality and enforces strict access control for minting and burning operations. While the implementation is robust, the token's security and economic stability are heavily reliant on the integrity and security of the external bridge contract.

1 Medium1 Low1 Informational
Volume 24h
$191.9K
Liquidity
$218.4K
Price
$2.4200
Token Age
1y
Top 10 Holders
65.4%

Security Findings

1 Med1 Low1 Info
Medium

Centralization Risk via Bridge Control

M-01The `OptimismMintableERC20` contract grants exclusive control over `mint` and `burn` operations to a single `BRIDGE` address. While this is an inherent design choice for a cross-chain bridge token, it introduces a significant centralization risk. If the `BRIDGE` contract or its controlling entity is compromised, an attacker could mint an arbitrary amount of tokens, leading to severe economic consequences for the token holders and the broader ecosystem. This falls under 7.3 Access Control and 7.4 Economic.
IssueThe `OptimismMintableERC20` contract grants exclusive control over `mint` and `burn` operations to a single `BRIDGE` address. While this is an inherent design choice for a cross-chain bridge token, it introduces a significant centralization risk. If the `BRIDGE` contract or its controlling entity is compromised, an attacker could mint an arbitrary amount of tokens, leading to severe economic consequences for the token holders and the broader ecosystem. This falls under 7.3 Access Control and 7.4 Economic.
FixAcknowledge and manage the inherent risk associated with the centralized `BRIDGE` control. Implement robust security measures for the `BRIDGE` contract, including multi-signature requirements for critical operations, time-locks, and continuous monitoring. Consider a decentralized bridge architecture in future iterations if feasible.
StatusUnresolved
Low

Immutable Decimals Set at Deployment

L-01The `DECIMALS` variable is set as `immutable` in the constructor and cannot be changed after deployment. While immutability is generally a good security practice, an incorrect `_decimals` value set during deployment would permanently affect how the token is displayed and interacted with across all integrated platforms. This could lead to significant user experience issues or incorrect calculations in DeFi protocols. This relates to 7.8 Operations.
IssueThe `DECIMALS` variable is set as `immutable` in the constructor and cannot be changed after deployment. While immutability is generally a good security practice, an incorrect `_decimals` value set during deployment would permanently affect how the token is displayed and interacted with across all integrated platforms. This could lead to significant user experience issues or incorrect calculations in DeFi protocols. This relates to 7.8 Operations.
FixEnsure thorough testing and verification of the `_decimals` parameter during the deployment process. Implement a robust deployment checklist and double-check all constructor arguments before final deployment to production environments.
StatusUnresolved
Info

Redundant View Functions for Bridge and Remote Token Addresses

I-01The contract includes redundant view functions: `l1Token()` and `remoteToken()` both return the `REMOTE_TOKEN` address, and `l2Bridge()` and `bridge()` both return the `BRIDGE` address. While not a vulnerability, this duplication adds unnecessary code complexity and slightly increases contract size. This relates to 7.2 Code Security.
IssueThe contract includes redundant view functions: `l1Token()` and `remoteToken()` both return the `REMOTE_TOKEN` address, and `l2Bridge()` and `bridge()` both return the `BRIDGE` address. While not a vulnerability, this duplication adds unnecessary code complexity and slightly increases contract size. This relates to 7.2 Code Security.
FixConsider consolidating these redundant functions to a single, clearly named function for each address (e.g., `remoteToken()` and `bridge()`) to improve code clarity and reduce contract size. If the duplication is for interface compatibility (e.g., `ILegacyMintableERC20`), document this design choice clearly.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical security practices (7.2 Code Security). It utilizes battle-tested OpenZeppelin libraries for ERC-20 implementation and Solidity 0.8.15, which includes built-in overflow/underflow checks. Access control for critical `mint` and `burn` functions is correctly enforced via an `onlyBridge` modifier, restricting these operations to a single, immutable `BRIDGE` address (7.3 Access Control). However, the contract's functionality is entirely dependent on the security of this external `BRIDGE` contract, introducing a significant technical dependency risk (7.6 External).

GovernanceHigh2/10

The economic model of this token is straightforward: it's a mintable/burnable token whose supply is controlled by an external bridge (7.4 Economic). There is no internal governance mechanism within this contract (7.5 Governance). The primary economic risk stems from the centralized control of token supply by the `BRIDGE` address. A compromise of the `BRIDGE` contract would directly lead to unauthorized minting, devaluing the token and impacting its economic stability.

UpgradesHigh3/10

This contract is not designed to be upgradeable (7.7 Upgrades), which eliminates upgrade-specific risks such as storage collisions or logic errors during upgrades. All critical addresses and parameters (`REMOTE_TOKEN`, `BRIDGE`, `DECIMALS`) are set as `immutable` in the constructor, ensuring their permanence. While the contract itself is not upgradeable, the external `BRIDGE` contract it depends on might be, and any upgrade risks associated with the `BRIDGE` would indirectly affect this token.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

65.4% in top 10
8.7% in wallets56.6% in contracts
Effective Concentration31.4%

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

$228.0K across 10 pairs
AerodromeWETHanalysed$218.4K95.8%AerodromeENA$4.1K1.8%AerodromeUSDC$3.9K1.7%Uniswap v3USDC$1.1K0.5%Uniswap v4USDC$3060.1%Uniswap v4USDC$1150.1%
Show 4 more pairsShow less
Uniswap v3REI$950.0%Uniswap v4ETH$410.0%AerodromeWETH$320.0%Uniswap v4ETH$210.0%

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
0x59aa…1875
Unlocked LP Held By
0xdb6d…9ab3

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (65.4% total → 31.4% effective; 8.7% in EOAs, 56.6% 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 = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

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
Ribbita by Virtuals (TIBBIR)High RiskPromptHigh RiskEURCHigh RiskCoinbase Wrapped XRP (CBXRP)High RiskCoinbase Wrapped BTC (CBBTC)High RiskZestHigh 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