Quantum Audit Logo
Launch App

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

Is Morpho Safe?

MORPHOEthereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance2/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Low · 2 Info5
SummaryAI Copilot

This audit covers an ERC-1967 (UUPS) proxy contract, which is a standard OpenZeppelin implementation.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • 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%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
56.3%Contracts7.9%35.9%Everyone else
56.3%Contracts7.9%35.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
64.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking56.3%
  • Walletsanonymous holders, free to sell7.9%
  • Everyone elsethe rest of the supply35.9%
Effective concentrationwhat the score reads30.4%
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$1.09M across 9 pairs
Show 3 more pairs

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$797.2KShare of depth73.2%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x9b81…7db9

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

Security Findings

1 Critical1 High1 Low2 Info
Critical

Unverified Implementation Contract

The 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).C-01

Issue

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

Fix

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

Status

Unresolved

High

Undetermined Upgrade Authorization Logic

As 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).H-01

Issue

As 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).

Fix

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

Status

Unresolved

Low

Potential for Storage Collisions with Custom Implementations

While 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).L-01

Issue

While 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).

Fix

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

Status

Unresolved

Info

Adherence to ERC-1967 Standard for Upgradeability

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

Issue

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

Fix

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

Status

Resolved

Info

Constructor msg.value Handling in upgradeToAndCall

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

Issue

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

Fix

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

Status

Resolved

Analysis

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

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.

Technical4/10Medium risk

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.

Governance2/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

The most critical recommendation is to immediately verify the source code of the implementation contract () on Etherscan or a similar block explorer.

Once verified, a thorough security audit of the implementation contract should be conducted to identify and mitigate any vulnerabilities, especially concerning access control for critical functions and the upgrade authorization mechanism. Ensure that the upgrade path is secured by a robust, multi-signature or time-locked governance process.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age1y
Contract0x58d9…c2b2
Deployer0x937c…fed5
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Morpho 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, 202654Medium
  2. Jul 23, 202648Medium
  3. Jul 23, 202652Medium

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

Frequently Asked Questions

What is the MORPHO contract address?

The Morpho contract on Ethereum is 0x58d97b57bb95320f9a05dc918aef65434969c2b2. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Morpho a scam?

Quantum Audit's risk score for Morpho is 54/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is MORPHO liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.09M.

Who holds MORPHO?

As of Sep 4, 2026, the 10 largest holders own 64.1% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
BeamEthereum54MediumSuperVerseSUPER · Ethereum54Medium00 Token00 · Ethereum54MediumIxs TokenIXS · Ethereum54MediumAlberich TokenALBRH · Ethereum54MediumSpiceSFI · Ethereum54Medium

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