Is Zora Safe? Smart Contract Security Analysis

Security Findings

1 High2 Low2 Info

High

Centralized Initial Minting and URI Setting

H-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Missing Event for Contract URI Setting

L-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Low

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

L-02The `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.

IssueThe `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.

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

StatusUnresolved

Info

Use of `Initializable` without Proxy Pattern

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

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

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

StatusUnresolved

Info

High Solidity Compiler Version (0.8.28)

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/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 Security) correctly uses `require` statements for input validation and access control. A key technical risk is the centralized `initializerAccount` (7.3 Access Control) which performs the entire initial minting and contract URI setup, concentrating significant power in a single address.

GovernanceHigh2/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 single, immutable address. While immutability prevents changes to the account, it places a high degree of trust in this single entity for the foundational setup of the token's economy and identity.

UpgradesMedium6/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 `Initializable` is solely for a secure, one-time setup of the contract's state.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

57.6% in top 10

55.3% in wallets2.4% in contracts

Effective Concentration56.2%

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

$243.7K across 30 pairs

Uniswap v3USDCanalysed$89.2K AerodromeUSDC$61.4K AerodromeWETH$37.5K Uniswap v3WETH$22.7K AerodromeMAMO$20.8K Uniswap v4ETH$4.0K

Show 4 more pairsShow less

Hydrex CLAMMWETH$1.4K PancakeswapWETH$1.3K Uniswap v3USDC$1.3K AerodromeHERO$688

The 20 remaining pairs hold $3.5K 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 Holder37.3%

Top-3 Unlocked56.0%

Key Addresses

11 addresses

Deployer

0xbebe…2712

Unlocked LP Held By

0xe387…42450x4d84…31220x9a88…bd090xe704…d7920x797c…682c0x48d1…93fa0xc445…98050xc873…88a60x6270…f3db0x9e9f…6303

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

What Raised This Score

5 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 50% (57.6% total → 56.2% effective; 55.3% in EOAs, 2.4% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
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

Is Zora Safe?

Security Findings

Centralized Initial Minting and URI Setting

Missing Event for Contract URI Setting

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

Use of `Initializable` without Proxy Pattern

High Solidity Compiler Version (0.8.28)

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Zora?