Is Zora Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2255Jul 2341

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

Audit Summary

The Zora token contract is an ERC20 token with voting and permit functionalities, built upon OpenZeppelin's battle-tested libraries. The contract utilizes an immutable `initializerAccount` for a one-time initial minting of the entire token supply and setting of the contract URI. While the architecture is straightforward and leverages robust components, the centralized control over initial supply distribution and metadata setting by a single account presents a high trust requirement. The contract is not designed for proxy upgrades, using `Initializable` solely for single-call setup.

Final Recommendation: It is recommended to enhance the security posture by distributing critical initial control. Consider using a multi-signature wallet for the `initializerAccount` to mitigate the risk associated with a single point of failure for the initial token distribution and metadata setting. Additionally, implement event emissions for all significant state changes, such as the setting of the `_contractURI`, to improve transparency and on-chain verifiability.

Category Ratings

TechnicalLow

8/10

The contract (7.1 Architecture) is a standard ERC20 token inheriting from OpenZeppelin's ERC20, ERC20Permit, ERC20Votes, and Initializable, which are well-audited components. Custom logic for `_update` and `nonces` correctly handles multiple inheritance. The `initialize` function (7.2 Code Secu

GovernanceHigh

1/10

The `initializerAccount` (7.4 Economic) holds significant power, being solely responsible for minting the entire token supply and setting the permanent `_contractURI` during the `initialize` call. This design choice centralizes initial economic control and metadata definition (7.5 Governance) to a s

UpgradesMedium

6/10

The contract utilizes the `Initializable` base contract (7.7 Upgrades) to ensure the `initialize` function can only be called once. However, this contract is not designed as an upgradeable proxy. Therefore, it does not introduce upgrade-specific risks associated with proxy patterns. The use of `Init

LP Distribution

Top-1 Unlocked Holder65.5%

Top-3 Unlocked81.1%

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 50% (55.4% total → 54.0% effective; 53.1% in EOAs, 2.4% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 65.5% (independent LP — depth risk, pool = 31% of DEX liquidity)
LP top3 unlocked holders = 81.1% (independent LP — depth risk, pool = 31% of DEX liquidity)
1 High finding(s) from audit
2 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 High 2 Low 2 Info

H-01HighUnresolved

Centralized Initial Minting and URI Setting

The `initialize` function, which is responsible for minting the entire token supply and setting the permanent `_contractURI`, can only be called by the `immutable initializerAccount`. This grants significant, centralized power to a single external account for the initial setup of the token's core properties. If this account were compromised or malicious, the entire initial token distribution and metadata could be adversely affected.

Recommendation: Consider using a multi-signature wallet for the `initializerAccount` to distribute trust and reduce the risk of a single point of failure. This would require multiple approvals for the critical `initialize` call, enhancing security.

L-01LowUnresolved

Missing Event for Contract URI Setting

The `_contractURI` is a crucial piece of token metadata set during initialization, but no event is emitted to log this action on-chain. While the `contractURI()` function allows retrieval, an event provides a transparent, immutable, and easily verifiable historical record of when and what URI was set, which is beneficial for off-chain indexing and monitoring.

Recommendation: Emit an event, such as `event ContractURISet(string indexed contractURI)`, within the `initialize` function immediately after `_contractURI` is set. This improves transparency and auditability.

L-02LowUnresolved

Potential for High Gas Usage in `initialize` with Large Arrays

The `initialize` function iterates through the `tos` and `amounts` arrays to mint tokens. If these arrays contain an extremely large number of elements, the transaction's gas cost could exceed the block gas limit, preventing the successful execution of the initialization. While unlikely for typical initial distributions, it's a design consideration for very large-scale token launches.

Recommendation: Ensure that the expected number of recipients and amounts for the initial distribution will not cause the transaction to exceed the block gas limit. If a very large distribution is anticipated, consider breaking it into multiple transactions (if the design allows) or using an alternative distribution mechanism that handles large batches more efficiently.

I-01InformationalUnresolved

Use of `Initializable` without Proxy Pattern

The contract inherits from OpenZeppelin's `Initializable` but is not part of a proxy upgrade system. While `Initializable` correctly prevents re-initialization of the `initialize` function, its primary purpose in OpenZeppelin is for upgradeable proxy contracts. This usage is technically correct for ensuring a single-call initialization, but it might lead to confusion regarding the contract's upgradeability if not clearly documented.

Recommendation: Clearly document the intent behind using `Initializable` if the contract is not intended to be upgradeable via a proxy. This clarifies that `Initializable` is used solely for secure, one-time setup and not for future contract upgrades.

I-02InformationalUnresolved

High Solidity Compiler Version (0.8.28)

The contract is compiled with Solidity 0.8.28, which is a very recent version. While this benefits from the latest compiler optimizations and security features (e.g., default checked arithmetic), it also means it has had less time to be battle-tested in production environments compared to slightly older, more established stable versions (e.g., 0.8.20).

Recommendation: Ensure thorough testing across various scenarios and consider the trade-offs of using the absolute latest compiler version for production deployments. While generally safe, newer versions might occasionally introduce subtle, undiscovered compiler-specific behaviors.

Is Zora Safe? ZORA