Quantum Audit Logo
Launch App

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

Is Morpho Token Safe?

MORPHOBase
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
Technical3/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 2 High3
SummaryAI Copilot

This audit covers an ERC1967Proxy contract, which is a standard OpenZeppelin UUPS proxy.

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 > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 64.1%
  • LP top3 unlocked holders = 80.0%
  • 1 Critical finding(s) from audit
  • 2 High 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 > 50% (83.8% total → 54.4% effective; 34.8% in EOAs, 49.0% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 64.1% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • LP top3 unlocked holders = 80.0% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High 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
49.0%Contracts34.8%Wallets16.2%Everyone else
49.0%Contracts34.8%Wallets16.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
83.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking49.0%
  • Walletsanonymous holders, free to sell34.8%
  • Everyone elsethe rest of the supply16.2%
Effective concentrationwhat the score reads54.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$2.01M across 21 pairs
Show 4 more pairs

The 11 remaining pairs hold $2.2K 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$1.30MShare of depth65.0%
Top-1 Unlocked Holder64.1%
Top-3 Unlocked80.0%
Unlocked LP held by
0xd838…4ced0xdec1…63760x7b8d…88a50x778c…09950x7a48…911c0x3c2f…1e1c0x7d27…fd550x6155…fcc40x718f…4a930xb362…b29c

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

Security Findings

1 Critical2 High
Critical

Unverified Implementation Contract Source Code

The implementation contract at 0xa860…fb18, which the ERC1967Proxy delegates all calls to, has unverified source code on the blockchain explorer. This prevents any security analysis of the core business logic, potential vulnerabilities, or malicious functionality. Users cannot independently verify what code they are interacting with, leading to a complete lack of trust and transparency.C-01

Issue

The implementation contract at , which the ERC1967Proxy delegates all calls to, has unverified source code on the blockchain explorer. This prevents any security analysis of the core business logic, potential vulnerabilities, or malicious functionality. Users cannot independently verify what code they are interacting with, leading to a complete lack of trust and transparency.

Fix

Immediately verify and publish the full source code of the implementation contract on the blockchain explorer. Once verified, a thorough security audit of the implementation contract should be conducted to ensure its integrity and security.

Status

Unresolved

High

Unknown Upgrade Authorization Mechanism

As an ERC1967 (UUPS) proxy, the authorization logic for upgrades resides within the implementation contract. With the implementation's source code unverified, the specific mechanism (e.g., an owner address, a multisig, a governance contract) that controls the ability to upgrade the proxy is unknown. This poses a significant risk, as an attacker who discovers or exploits this unknown mechanism could unilaterally upgrade the contract to a malicious version, potentially draining funds or seizing control.H-01

Issue

As an ERC1967 (UUPS) proxy, the authorization logic for upgrades resides within the implementation contract. With the implementation's source code unverified, the specific mechanism (e.g., an owner address, a multisig, a governance contract) that controls the ability to upgrade the proxy is unknown. This poses a significant risk, as an attacker who discovers or exploits this unknown mechanism could unilaterally upgrade the contract to a malicious version, potentially draining funds or seizing control.

Fix

Upon verification of the implementation contract's source code, clearly document and audit the upgrade authorization mechanism. Ensure that upgrade permissions are secured by robust access control, ideally a multi-signature wallet or a well-tested governance system, to prevent single points of failure.

Status

Unresolved

High

Potential Storage Collisions in Unverified Implementation

The pre-analysis notes indicate a 'non-standard storage layout' for the implementation contract. In UUPS proxies, the implementation contract must carefully manage its storage to avoid collisions with the proxy's reserved storage slots (e.g., for implementation address, admin address). Without verified source code, it's impossible to confirm if the implementation correctly adheres to ERC-1967 storage slot conventions or if its custom layout could inadvertently overwrite critical proxy state variables, leading to severe data corruption or loss of control.H-02

Issue

The pre-analysis notes indicate a 'non-standard storage layout' for the implementation contract. In UUPS proxies, the implementation contract must carefully manage its storage to avoid collisions with the proxy's reserved storage slots (e.g., for implementation address, admin address). Without verified source code, it's impossible to confirm if the implementation correctly adheres to ERC-1967 storage slot conventions or if its custom layout could inadvertently overwrite critical proxy state variables, leading to severe data corruption or loss of control.

Fix

After verifying the implementation's source code, conduct a detailed storage layout analysis to confirm that there are no potential collisions with the ERC-1967 proxy's reserved slots. Ensure that the implementation's storage variables are declared in a way that is compatible with the proxy pattern, especially if custom storage patterns are used.

Status

Unresolved

Analysis

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

This audit covers an ERC1967Proxy contract, which is a standard OpenZeppelin UUPS proxy. While the proxy contract itself is robust and well-audited, the critical finding is that its associated implementation contract (0xa860498f8a299526174b539fcc49f13cc082fb18) has unverified source code. This lack of transparency prevents a full security assessment of the system's core logic and introduces significant risks, including unknown vulnerabilities, potential malicious behavior, and unverified upgrade mechanisms.

Technical3/10High risk

The proxy contract (7.1 Architecture) utilizes well-vetted OpenZeppelin libraries for its core functionality, ensuring a high standard of code security for the proxy itself (7.2 Code Security). However, the primary technical risk stems from the unverified source code of the implementation contract (7.6 External). This prevents any assessment of its internal logic, potential vulnerabilities (e.g., reentrancy, integer overflows), or adherence to secure coding practices. The 'non-standard storage layout' note for the implementation further raises concerns about potential storage collisions with the proxy's reserved slots.

Governance1/10High risk

Without access to the implementation contract's source code, the governance and economic models (7.4 Economic, 7.5 Governance) cannot be assessed. Specifically, the mechanism for authorizing upgrades (7.3 Access Control) is unknown, posing a significant risk. This lack of transparency means that the control over critical functions, potential fee structures, or asset management within the protocol remains unverified, potentially exposing users to unauthorized changes or economic manipulation.

Upgrades1/10High risk

The contract employs the ERC-1967 (UUPS) proxy pattern (7.7 Upgrades), which is a robust standard for upgradeability. However, the control mechanism for authorizing upgrades resides within the unverified implementation contract. This means the identity of the entity or mechanism (e.g., multisig, governance contract) authorized to perform upgrades is unknown. An attacker gaining control of this unknown upgrade mechanism could replace the implementation with malicious code, leading to a complete compromise of the protocol and user funds.

Final RecommendationWhat to do about this score

It is imperative that the source code for the implementation contract () be verified and made publicly available.

A comprehensive security audit of the implementation contract is strongly recommended to identify and mitigate any vulnerabilities, assess its access control mechanisms, and confirm its adherence to secure development practices. Users should exercise extreme caution when interacting with this contract until the implementation's code is fully transparent and audited.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkBase
Token age1y
Contract0xbaa5…0842
Deployer0x937c…fed5
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Morpho Token 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, 202660Medium
  2. Jul 23, 202650Medium
  3. Jul 22, 202676High

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

Related Audits

6 more on the recordAll audits
Tether USDUSDT · Base60MediumevoBase60MediumBIOBase60MediumHydrexHYDX · Base60MediumAavegotchi GHST TokenGHST · Base60MediumFree BotsBOTS · Base60Medium

Would You Like a More Detailed Audit of Morpho Token?

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