Quantum Audit Logo
Launch App

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

Is Horizen Safe?

ZENBase
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades5/10Checks passed2 of 5Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

This audit covers the ZenToken contract. Due to the provided source code being truncated, a comprehensive security analysis could not be performed.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.4%
  • LP top3 unlocked holders = 98.3%
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 50% (70.8% total → 55.6% effective; 45.4% in EOAs, 25.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.4% (independent LP — depth risk, pool = 62% of DEX liquidity)
  • LP top3 unlocked holders = 98.3% (independent LP — depth risk, pool = 62% of DEX liquidity)
  • 1 Medium 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 Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
25.4%Contracts45.4%Wallets29.2%Everyone else
25.4%Contracts45.4%Wallets29.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
70.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking25.4%
  • Walletsanonymous holders, free to sell45.4%
  • Everyone elsethe rest of the supply29.2%
Effective concentrationwhat the score reads55.6%
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$3.81M across 15 pairs
Show 4 more pairs

The 5 remaining pairs hold $73 between them and are not listed. The risk score reads depth across every pair.

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$2.37MShare of depth62.2%
Top-1 Unlocked Holder92.4%
Top-3 Unlocked98.3%
Unlocked LP held by
0xf945…0d2a0xb834…45ae0xaee5…5c040x438b…34410x7327…b38f0x2828…99520x0fd6…afce0xe9c9…12af0x8f1b…182a

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

Security Findings

1 Medium1 Low2 Info
Medium

Potential Centralization Risks Due to Owner Privileges

While the full contract code is unavailable, most custom ERC-20 token implementations include privileged functions (e.g., mint, pause, blacklist, setFees) that can only be called by an owner or administrator. Such centralization introduces a single point of failure and potential for abuse or compromise. If these functions exist without proper safeguards, a compromised owner key could lead to significant asset loss or protocol manipulation (7.3 Access Control, 7.4 Economic).M-01

Issue

While the full contract code is unavailable, most custom ERC-20 token implementations include privileged functions (e.g., mint, pause, blacklist, setFees) that can only be called by an owner or administrator. Such centralization introduces a single point of failure and potential for abuse or compromise. If these functions exist without proper safeguards, a compromised owner key could lead to significant asset loss or protocol manipulation (7.3 Access Control, 7.4 Economic).

Fix

If privileged functions exist, implement robust access control mechanisms, such as a multi-signature wallet for ownership, and consider adding timelocks for critical operations. Clearly document all privileged roles and their associated capabilities. Review the necessity and scope of each privileged function.

Status

Unresolved

Low

Reliance on Standard OpenZeppelin Contracts (Assumed)

The visible code includes OpenZeppelin interfaces (IERC20, IERC20Errors, etc.), suggesting that the ZenToken contract likely inherits from battle-tested OpenZeppelin ERC-20 implementations. While this significantly reduces the risk of common vulnerabilities found in custom token implementations, any custom logic added on top of these standard contracts would still require careful scrutiny. The security of the contract heavily relies on the correct and unmodified integration of these standard components (7.2 Code Security).L-01

Issue

The visible code includes OpenZeppelin interfaces (IERC20, IERC20Errors, etc.), suggesting that the ZenToken contract likely inherits from battle-tested OpenZeppelin ERC-20 implementations. While this significantly reduces the risk of common vulnerabilities found in custom token implementations, any custom logic added on top of these standard contracts would still require careful scrutiny. The security of the contract heavily relies on the correct and unmodified integration of these standard components (7.2 Code Security).

Fix

Ensure that any custom logic added to the OpenZeppelin base implementation is thoroughly reviewed for vulnerabilities. Avoid modifying core OpenZeppelin logic directly; instead, extend or override functions carefully. Maintain up-to-date OpenZeppelin dependencies.

Status

Unresolved

Info

Truncated Source Code Prevents Comprehensive Audit

The provided Solidity source code for the ZenToken contract is truncated. Only interfaces and the beginning of the ZenToken contract definition are available. This limitation prevents a full and comprehensive security audit, as critical implementation details, custom logic, state variables, and function bodies are missing. Without the complete code, it is impossible to identify potential vulnerabilities such as reentrancy, access control flaws, integer overflows/underflows in custom logic, or economic exploits.I-01

Issue

The provided Solidity source code for the ZenToken contract is truncated. Only interfaces and the beginning of the ZenToken contract definition are available. This limitation prevents a full and comprehensive security audit, as critical implementation details, custom logic, state variables, and function bodies are missing. Without the complete code, it is impossible to identify potential vulnerabilities such as reentrancy, access control flaws, integer overflows/underflows in custom logic, or economic exploits.

Fix

Provide the complete, untruncated source code for the ZenToken contract to enable a thorough security audit. This includes all inherited contracts and libraries.

Status

Unresolved

Info

Adoption of ERC-6093 Custom Errors

The contract utilizes interfaces for ERC-6093 custom errors (IERC20Errors, IERC721Errors, IERC1155Errors). This is a good practice that improves the clarity and specificity of error messages, making it easier for users and dApps to understand transaction failures. Custom errors are also generally more gas-efficient than revert strings (7.2 Code Security).I-02

Issue

The contract utilizes interfaces for ERC-6093 custom errors (IERC20Errors, IERC721Errors, IERC1155Errors). This is a good practice that improves the clarity and specificity of error messages, making it easier for users and dApps to understand transaction failures. Custom errors are also generally more gas-efficient than revert strings (7.2 Code Security).

Fix

Continue to use and expand upon custom error types for all relevant revert conditions within the contract's custom logic. Ensure error messages are clear and provide sufficient context for debugging.

Status

Unresolved

Analysis

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

This audit covers the ZenToken contract. Due to the provided source code being truncated, a comprehensive security analysis could not be performed. The visible portion indicates a standard ERC-20 token structure, likely leveraging OpenZeppelin contracts, and incorporates ERC-6093 custom errors. However, the absence of the full implementation prevents a thorough assessment of custom logic, access control, and potential economic vulnerabilities.

Technical8/10Low risk

The technical architecture appears to follow the well-established ERC-20 standard, utilizing OpenZeppelin interfaces for robust token functionality (7.1 Architecture). The inclusion of ERC-6093 custom errors is a positive step for improved error handling and gas efficiency. However, the truncated source code prevents a full review of the ZenToken's specific implementation details, custom logic, and potential vulnerabilities like reentrancy or integer overflows (7.2 Code Security). Without the complete code, the security of critical functions cannot be fully verified.

Governance1/10High risk

The economic model of a standard ERC-20 token is generally straightforward, relying on supply and demand dynamics (7.4 Economic). However, most custom tokens introduce owner-controlled functions such as minting, burning, pausing, or fee adjustments, which can introduce centralization risks and potential economic manipulation if not properly secured (7.3 Access Control). Without the full contract code, the specific governance mechanisms and their associated economic risks cannot be fully evaluated (7.5 Governance).

Upgrades5/10Medium risk

The contract is not identified as a proxy and does not appear to implement any explicit upgrade mechanisms (7.7 Upgrades). This means the contract's logic is immutable once deployed, eliminating risks associated with upgradeability patterns such as proxy storage collisions or faulty upgrade implementations. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a new contract deployment and migration.

Final RecommendationWhat to do about this score

It is strongly recommended to provide the complete, untruncated source code for a thorough security audit.

A full audit would allow for a detailed review of all custom logic, access control mechanisms, and potential economic implications. Ensure that all administrative functions, if any, are protected by robust access control (e.g., OpenZeppelin's Ownable or AccessControl) and that critical operations have appropriate timelocks or multi-signature requirements to mitigate centralization risks.

Contract & Record

2 audits on record
TypeZenToken
NetworkBase
Token age1y
Contract0xf43e…9229
Deployer0x15e2…1c14
Badge for your website
Horizen 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, 202639Medium
  2. Jul 27, 202634Low
  3. Jul 27, 202663Medium

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

Frequently Asked Questions

Is Horizen a scam?

Based on automated analysis, Horizen scores 63/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Horizen safe to buy?

Our scanner flagged a risk score of 63/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Horizen been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
SquidQUID · Base39MediumENABase39MediumAave TokenAAVE · Base38MediumHandlPayHANDL · Base40MediumBaseUncBase38MediumRollBase38Medium

Would You Like a More Detailed Audit of Horizen?

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