Quantum Audit Logo

Is Morpho Token Safe?

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

Morpho Token MORPHO
0xbaa5…0842
Base Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

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.

1 Critical2 High
Volume 24h
$2.22M
Liquidity
$1.30M
Price
$2.4700
Token Age
1y
Top 10 Holders
83.8%

Security Findings

Critical

Unverified Implementation Contract Source Code

C-01The 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.
IssueThe 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.
FixImmediately 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.
StatusUnresolved
High

Unknown Upgrade Authorization Mechanism

H-01As 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.
IssueAs 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.
FixUpon 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.
StatusUnresolved
High

Potential Storage Collisions in Unverified Implementation

H-02The 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.
IssueThe 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.
FixAfter 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.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

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.

GovernanceHigh1/10

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.

UpgradesHigh1/10

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.

Security Checklist

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

34.8% in wallets49.0% in contracts
Effective Concentration54.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

Show 4 more pairsShow less

The 11 remaining pairs hold $2.2K between them and are not listed.

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 Holder64.1%
Top-3 Unlocked80.0%

Key Addresses

Deployer
0x937c…fed5
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.

What Raised This Score

  • 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

Related Audits

Tether USD (USDT)High RiskevoHigh RiskBIOHigh RiskHydrex (HYDX)High RiskAavegotchi GHST Token (GHST)High RiskFree Bots (BOTS)High Risk

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