Quantum Audit Logo

Is Morpho Safe?

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

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

Morpho MORPHO
0x58d9…c2b2
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers an ERC-1967 (UUPS) proxy contract, which is a standard OpenZeppelin implementation. The proxy itself is robust and adheres to established upgradeability patterns. However, the critical finding is that the implementation contract, to which all calls are delegated, is not source verified. This introduces significant security risks as its functionality, upgrade authorization, and potential vulnerabilities are unknown. The overall risk is High due to this lack of transparency and verifiability of the underlying logic.

1 Critical1 High1 Low2 Informational
Volume 24h
$190.5K
Liquidity
$797.2K
Price
$2.4700
Token Age
1y
Top 10 Holders
64.1%

Security Findings

1 Crit1 High1 Low2 Info
Critical

Unverified Implementation Contract

C-01The proxy contract (0x58d9…c2b2) delegates all calls to an implementation contract at 0x4364…4852. The source code for this implementation contract is not verified on the blockchain explorer. This means the actual logic executed by the proxy is unknown and cannot be publicly audited or verified, posing an extreme risk to users and the protocol's integrity (7.2 Code Security, 7.6 External).
IssueThe proxy contract () delegates all calls to an implementation contract at . The source code for this implementation contract is not verified on the blockchain explorer. This means the actual logic executed by the proxy is unknown and cannot be publicly audited or verified, posing an extreme risk to users and the protocol's integrity (7.2 Code Security, 7.6 External).
FixImmediately verify the source code of the implementation contract on Etherscan. Once verified, conduct a comprehensive security audit of the implementation to ensure it is free from vulnerabilities, backdoors, or malicious logic. Public transparency is crucial for user trust and security.
StatusUnresolved
High

Undetermined Upgrade Authorization Logic

H-01As an ERC-1967 (UUPS) proxy, the authorization for upgrading the implementation contract resides within the implementation itself, typically via an `_authorizeUpgrade` function. Since the implementation contract (0x4364…4852) is unverified, the specific access control (7.3) and governance (7.5) mechanisms for authorizing upgrades are unknown. This could lead to unauthorized upgrades, single points of failure, or a compromised upgrade path (7.7 Upgrades).
IssueAs an ERC-1967 (UUPS) proxy, the authorization for upgrading the implementation contract resides within the implementation itself, typically via an `_authorizeUpgrade` function. Since the implementation contract () is unverified, the specific access control (7.3) and governance (7.5) mechanisms for authorizing upgrades are unknown. This could lead to unauthorized upgrades, single points of failure, or a compromised upgrade path (7.7 Upgrades).
FixAfter verifying the implementation contract, thoroughly review its `_authorizeUpgrade` function and any associated access control mechanisms. Ensure that upgrade permissions are restricted to a secure, multi-signature wallet or a robust governance system with appropriate time-locks to prevent malicious or hasty upgrades.
StatusUnresolved
Low

Potential for Storage Collisions with Custom Implementations

L-01While OpenZeppelin's `ERC1967Proxy` correctly isolates its storage slots for `implementation`, `admin`, and `beacon` using ERC-1967 standard hashes, custom implementation contracts must be designed carefully to avoid storage collisions with these proxy-specific slots. If the unverified implementation contract (0x4364…4852) does not adhere to best practices for upgradeable contract storage, it could lead to critical state corruption (7.1 Architecture, 7.2 Code Security).
IssueWhile OpenZeppelin's `ERC1967Proxy` correctly isolates its storage slots for `implementation`, `admin`, and `beacon` using ERC-1967 standard hashes, custom implementation contracts must be designed carefully to avoid storage collisions with these proxy-specific slots. If the unverified implementation contract () does not adhere to best practices for upgradeable contract storage, it could lead to critical state corruption (7.1 Architecture, 7.2 Code Security).
FixWhen designing or auditing implementation contracts for UUPS proxies, always ensure that the storage layout is compatible with the proxy pattern. Use OpenZeppelin's `UUPSUpgradeable` base contract or manually ensure that the first storage slots of the implementation do not overlap with the proxy's reserved slots. A storage collision analysis should be performed once the implementation source is available.
StatusUnresolved
Info

Adherence to ERC-1967 Standard for Upgradeability

I-01The contract correctly implements the ERC-1967 (UUPS) proxy standard, utilizing OpenZeppelin's battle-tested libraries. This provides a robust and widely accepted mechanism for contract upgradeability, separating the proxy's logic from its implementation and ensuring storage compatibility (7.1 Architecture, 7.7 Upgrades).
IssueThe contract correctly implements the ERC-1967 (UUPS) proxy standard, utilizing OpenZeppelin's battle-tested libraries. This provides a robust and widely accepted mechanism for contract upgradeability, separating the proxy's logic from its implementation and ensuring storage compatibility (7.1 Architecture, 7.7 Upgrades).
FixContinue to leverage well-audited and standard libraries like OpenZeppelin for core infrastructure components. Ensure that any custom modifications or integrations maintain the integrity and security principles of the ERC-1967 standard.
StatusResolved
Info

Constructor `msg.value` Handling in `upgradeToAndCall`

I-02The `ERC1967Proxy` constructor is `payable` and calls `ERC1967Utils.upgradeToAndCall`. If `_data` is empty in this call, `_checkNonPayable()` is invoked, which reverts if `msg.value > 0`. This is a safety mechanism to prevent accidental loss of funds if no initialization call is made. Deployers should be aware that sending Ether with an empty `_data` parameter during proxy deployment will cause a revert (7.8 Operations).
IssueThe `ERC1967Proxy` constructor is `payable` and calls `ERC1967Utils.upgradeToAndCall`. If `_data` is empty in this call, `_checkNonPayable()` is invoked, which reverts if `msg.value > 0`. This is a safety mechanism to prevent accidental loss of funds if no initialization call is made. Deployers should be aware that sending Ether with an empty `_data` parameter during proxy deployment will cause a revert (7.8 Operations).
FixWhen deploying the proxy, ensure that if `msg.value` is greater than zero, the `_data` parameter for the constructor is also non-empty, typically containing an encoded function call to an `initialize` function in the implementation. If no initialization data is required, ensure `msg.value` is zero.
StatusResolved

Category Ratings

TechnicalMedium4/10

The technical architecture (7.1) utilizes the battle-tested OpenZeppelin ERC-1967 (UUPS) proxy pattern, which is a strong foundation for upgradeability. The code security (7.2) of the proxy contracts themselves is high, benefiting from extensive audits and community review. However, a critical technical risk arises because the implementation contract () is not source verified, making its internal logic and potential vulnerabilities unknown. This lack of transparency significantly impacts the overall code security and external interaction (7.6) assessment.

GovernanceHigh2/10

The governance (7.5) and economic (7.4) security of the system are heavily dependent on the implementation contract. While the ERC-1967 standard provides a framework for upgrade control, the specific authorization logic (e.g., who can call `_authorizeUpgrade`) resides within the unverified implementation. This means the mechanisms for changing the implementation, and thus controlling the protocol's behavior and economic parameters, are opaque. Without visibility into the implementation, the governance and economic risks are elevated.

UpgradesHigh1/10

The contract implements the ERC-1967 (UUPS) upgrade pattern (7.7), which is a secure and widely adopted standard for upgradeability. This pattern delegates upgrade authorization to the implementation contract itself, allowing for flexible governance over upgrades. However, the primary risk is that the implementation contract () is not source verified. This prevents any assessment of the `_authorizeUpgrade` function, leaving the upgrade path's security and access control (7.3) unknown and potentially vulnerable.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

64.1% in top 10
7.9% in wallets56.3% in contracts
Effective Concentration30.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

$1.09M across 9 pairs
Uniswap v4ETHanalysed$797.2K73.2%Uniswap v3WETH$184.4K16.9%Uniswap v3WETH$49.8K4.6%Uniswap v4USDC$26.7K2.5%Uniswap v4USDC$22.1K2.0%Uniswap v4USDC$5.3K0.5%
Show 3 more pairsShow less
Uniswap v4ETH$3.0K0.3%SupernovaWETH$880.0%Uniswap v4sUSDS$20.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
0x937c…fed5
Unlocked LP Held By
0x9b81…7db9

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

What Raised This Score

10 factors
  • Ownership NOT renounced — strong Multisig (5-of-9)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (64.1% total → 30.4% effective; 7.9% 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 = 73% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High 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
BeamHigh RiskSuperVerse (SUPER)High Risk00 Token (00)High RiskIxs Token (IXS)High RiskAlberich Token (ALBRH)High RiskSpice (SFI)High Risk

Would You Like a More Detailed Audit of Morpho?

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

Get Detailed Audit