Is Horizen (ZEN) Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low2 Info

Medium

Potential Centralization Risks Due to Owner Privileges

M-01While 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).

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

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

StatusUnresolved

Low

Reliance on Standard OpenZeppelin Contracts (Assumed)

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

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

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

StatusUnresolved

Info

Truncated Source Code Prevents Comprehensive Audit

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

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

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

StatusUnresolved

Info

Adoption of ERC-6093 Custom Errors

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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

UpgradesMedium5/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

70.8% in top 10

45.4% in wallets25.4% in contracts

Effective Concentration55.6%

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

$3.81M across 15 pairs

AerodromeWETHanalysed$2.37M AerodromecbBTC$1.42M Uniswap v3USDC$8.0K AerodromeUSDC$6.8K Hydrex CLAMMUSDC$4.0K AerodromeUSDC$1.1K

Show 4 more pairsShow less

AerodromeWETH$109 AerodromeAERO$89 AerodromeMORPHO$61 AerodromeUSDC$61

The 5 remaining pairs hold $73 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 Holder92.4%

Top-3 Unlocked98.3%

Key Addresses

10 addresses

Deployer

0x15e2…1c14

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.

What Raised This Score

8 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

Is Horizen Safe?

Security Findings

Potential Centralization Risks Due to Owner Privileges

Reliance on Standard OpenZeppelin Contracts (Assumed)

Truncated Source Code Prevents Comprehensive Audit

Adoption of ERC-6093 Custom Errors

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Horizen?