Is Morpho Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

3 audits on record

Jul 2352Jul 2348

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: The most critical recommendation is to immediately verify the source code of the implementation contract (0x4364fd2371b6318159366abfa51f190df5c24852) 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.

Category Ratings

TechnicalMedium

4/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 techn

GovernanceMedium

4/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 implement

UpgradesHigh

1/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 t

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder48.0%

Top-3 Unlocked79.8%

What Raised This Score

8 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.9% total → 31.0% effective; 8.4% in EOAs, 56.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
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 Findings

5 total

1 Critical 1 High 1 Low 2 Info

C-01CriticalUnresolved

Unverified Implementation Contract

The proxy contract (0x58d97b57bb95320f9a05dc918aef65434969c2b2) delegates all calls to an implementation contract at 0x4364fd2371b6318159366abfa51f190df5c24852. 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).

Recommendation: 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.

H-01HighUnresolved

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 (0x4364fd2371b6318159366abfa51f190df5c24852) 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).

Recommendation: 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.

L-01LowUnresolved

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 (0x4364fd2371b6318159366abfa51f190df5c24852) does not adhere to best practices for upgradeable contract storage, it could lead to critical state corruption (7.1 Architecture, 7.2 Code Security).

Recommendation: 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.

I-01InformationalResolved

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

Recommendation: 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.

I-02InformationalResolved

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

Recommendation: 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.

Is Morpho Safe? MORPHO