Quantum Audit Logo
Launch App

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

Is Zora Safe?

ZORABase
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
SummaryAI Copilot

The Zora token contract is an ERC20 token with voting and permit functionalities, built upon OpenZeppelin's battle-tested libraries.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 50%
  • 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
Exact 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
55.3%Wallets42.4%Everyone else
55.3%Wallets42.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
57.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking2.4%
  • Walletsanonymous holders, free to sell55.3%
  • Everyone elsethe rest of the supply42.4%
Effective concentrationwhat the score reads56.2%
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$243.7K across 30 pairs
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$89.2KShare of depth36.6%
Top-1 Unlocked Holder37.3%
Top-3 Unlocked56.0%
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.

Security Findings

1 High2 Low2 Info
High

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

Issue

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.

Fix

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.

Status

Unresolved

Low

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.L-01

Issue

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.

Fix

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

Status

Unresolved

Low

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

Issue

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.

Fix

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.

Status

Unresolved

Info

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

Issue

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.

Fix

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.

Status

Unresolved

Info

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

Issue

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

Fix

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.

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance2/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

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.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0x1111…fc69
Deployer0xbebe…2712
Badge for your website
Zora 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, 202637Medium
  2. Jul 23, 202641Medium
  3. Jul 22, 202655Medium

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

Would You Like a More Detailed Audit of Zora?

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