Quantum Audit Logo
Launch App

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

Is ZK Coin Safe?

ZKCEthereum
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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed4 of 7Findings2 High · 3 Medium · 1 Low6
SummaryAI Copilot

The ZKC token contract implements an upgradeable ERC-20 token with a custom epoch-based emission schedule and role-based access control.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Top-10 concentration > 70%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 2 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 2 High finding(s) from audit
  • 3 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockUnknown
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
100.0%Wallets
100.0%Wallets
WalletsBubble area = share of supply
100.0%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell100.0%
Effective concentrationwhat the score reads100.0%
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$81.2K

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$81.2KShare of depth100.0%

Security Findings

2 High3 Medium1 Low
High

Misleading totalSupply() Implementation

The totalSupply() function overrides the standard ERC-20 behavior by returning a *projected* supply based on the current epoch's calculated emissions (getSupplyAtEpochStart(getCurrentEpoch())), rather than the actual number of tokens minted and in circulation (super.totalSupply()). This deviation from the ERC-20 standard can lead to significant confusion for users, incorrect calculations by external protocols, and misrepresentation of the token's true circulating supply. The actual minted supply is available via claimedTotalSupply(), but this requires specific knowledge of the contract's non-standard implementation.H-01

Issue

The totalSupply() function overrides the standard ERC-20 behavior by returning a *projected* supply based on the current epoch's calculated emissions (getSupplyAtEpochStart(getCurrentEpoch())), rather than the actual number of tokens minted and in circulation (super.totalSupply()). This deviation from the ERC-20 standard can lead to significant confusion for users, incorrect calculations by external protocols, and misrepresentation of the token's true circulating supply. The actual minted supply is available via claimedTotalSupply(), but this requires specific knowledge of the contract's non-standard implementation.

Fix

It is highly recommended to align totalSupply() with the ERC-20 standard by returning the actual minted supply (super.totalSupply()). If a projected supply is necessary for specific use cases, it should be provided through a clearly named, separate function (e.g., getProjectedSupply()) to avoid ambiguity and maintain ERC-20 compliance.

Status

Unresolved

High

Centralization Risk of Initial Minting

The initialMint function allows initialMinter1 or initialMinter2 to mint the entire INITIAL_SUPPLY to any specified recipients. If either of these initial minter addresses is compromised or acts maliciously, they could mint the entire initial supply to themselves or other unauthorized addresses, leading to a complete loss of control over the initial token distribution.H-02

Issue

The initialMint function allows initialMinter1 or initialMinter2 to mint the entire INITIAL_SUPPLY to any specified recipients. If either of these initial minter addresses is compromised or acts maliciously, they could mint the entire initial supply to themselves or other unauthorized addresses, leading to a complete loss of control over the initial token distribution.

Fix

Implement multi-signature control for the initialMinter1 and initialMinter2 roles to distribute trust and prevent single points of failure. Alternatively, consider a more decentralized initial distribution mechanism or a time-locked release schedule for the initial supply.

Status

Unresolved

Medium

Critical epoch0StartTime Initialization

The epoch0StartTime variable, which dictates the entire token emission schedule, is set only once via the initializeV3() reinitializer. This function is restricted to the ADMIN_ROLE. The precise timing of this initialization is critical; an accidental delay or premature call could significantly alter the intended tokenomics and emission curve. This represents a single point of operational risk.M-01

Issue

The epoch0StartTime variable, which dictates the entire token emission schedule, is set only once via the initializeV3() reinitializer. This function is restricted to the ADMIN_ROLE. The precise timing of this initialization is critical; an accidental delay or premature call could significantly alter the intended tokenomics and emission curve. This represents a single point of operational risk.

Fix

Establish clear, documented operational procedures for the initializeV3() call, including a specific window for execution. Consider adding a time-lock or a multi-signature requirement for this critical function to ensure careful deliberation before execution. Implement monitoring to detect any unintended delays or premature calls.

Status

Unresolved

Medium

Reliance on Unaudited Supply Library for Core Tokenomics

The contract's core tokenomics, including the calculation of total supply at each epoch (getSupplyAtEpochStart) and epoch-specific emissions (getEmissionsForEpoch), are delegated to an external Supply library. The source code for this library was not provided for audit. Without a thorough review of the Supply library, the accuracy, security, and economic soundness of the token's emission schedule cannot be fully verified. Any vulnerabilities or incorrect logic within this library would directly impact the ZKC token.M-02

Issue

The contract's core tokenomics, including the calculation of total supply at each epoch (getSupplyAtEpochStart) and epoch-specific emissions (getEmissionsForEpoch), are delegated to an external Supply library. The source code for this library was not provided for audit. Without a thorough review of the Supply library, the accuracy, security, and economic soundness of the token's emission schedule cannot be fully verified. Any vulnerabilities or incorrect logic within this library would directly impact the ZKC token.

Fix

Provide the complete source code for the Supply library for a comprehensive security and economic audit. Ensure the library's logic is thoroughly tested, especially for edge cases in epoch calculations and emission rates.

Status

Unresolved

Medium

Centralized Control over Key Roles and Upgrades

The ADMIN_ROLE holds extensive power, including the ability to grant POVW_MINTER_ROLE and STAKING_MINTER_ROLE, set the critical epoch0StartTime, and authorize contract upgrades via _authorizeUpgrade. This high degree of centralization means that a compromise of the ADMIN_ROLE address could lead to significant security breaches, including unauthorized minting, alteration of tokenomics, or malicious contract upgrades.M-03

Issue

The ADMIN_ROLE holds extensive power, including the ability to grant POVW_MINTER_ROLE and STAKING_MINTER_ROLE, set the critical epoch0StartTime, and authorize contract upgrades via _authorizeUpgrade. This high degree of centralization means that a compromise of the ADMIN_ROLE address could lead to significant security breaches, including unauthorized minting, alteration of tokenomics, or malicious contract upgrades.

Fix

Implement multi-signature control for the ADMIN_ROLE to distribute trust and reduce the risk associated with a single point of failure. Consider separating critical responsibilities into distinct roles with different access policies, if feasible, to further decentralize control.

Status

Unresolved

Low

Potential for Reward Claiming Logic Misinterpretation

The functions getTotalPoVWEmissionsAtEpochStart and getTotalStakingEmissionsAtEpochStart calculate the *cumulative* total emissions available up to a given epoch. These are then used to check against poVWClaimed and stakingClaimed, which are also *cumulative* totals of claimed rewards. While this logic appears consistent for cumulative tracking, the function names might be misinterpreted by developers or auditors as representing *epoch-specific* emissions, potentially leading to confusion or incorrect assumptions about the reward distribution mechanism.L-01

Issue

The functions getTotalPoVWEmissionsAtEpochStart and getTotalStakingEmissionsAtEpochStart calculate the *cumulative* total emissions available up to a given epoch. These are then used to check against poVWClaimed and stakingClaimed, which are also *cumulative* totals of claimed rewards. While this logic appears consistent for cumulative tracking, the function names might be misinterpreted by developers or auditors as representing *epoch-specific* emissions, potentially leading to confusion or incorrect assumptions about the reward distribution mechanism.

Fix

Enhance clarity by either renaming the functions to explicitly indicate cumulative totals (e.g., getOverallPoVWEmissionsUpToEpoch) or by adding comprehensive NatSpec documentation to explain that these functions return cumulative values, not epoch-specific ones.

Status

Unresolved

Analysis

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

The ZKC token contract implements an upgradeable ERC-20 token with a custom epoch-based emission schedule and role-based access control. The audit identified several high and medium severity issues primarily related to tokenomics design, centralization of control, and potential for misinterpretation of core functions. Key concerns include a non-standard totalSupply() implementation, significant centralization risks in initial token distribution and critical parameter initialization, and reliance on an unaudited external library for core emission logic.

Technical6/10Medium risk

The contract leverages battle-tested OpenZeppelin upgradeable libraries for ERC-20, access control, and UUPS proxy patterns, contributing to a robust technical foundation (7.1 Architecture, 7.2 Code Security). Solidity 0.8.26 mitigates common integer overflow/underflow risks. However, a critical design choice for totalSupply() deviates from the ERC-20 standard, returning a projected value instead of the actual minted supply, which can cause integration issues (7.1 Architecture, 7.2 Code Security). The reliance on an unaudited Supply library for core emission calculations introduces an unverified dependency (7.6 External).

Governance1/10High risk

The tokenomics design includes an epoch-based emission schedule with distinct roles for PoVW and Staking minters (7.4 Economic). Initial token distribution is managed by two designated minters, which presents a high centralization risk if these addresses are compromised (7.3 Access Control). The ADMIN_ROLE holds significant power, controlling critical parameters like epoch0StartTime and all minter roles, creating a single point of failure (7.3 Access Control, 7.5 Governance). While the reward claiming logic appears cumulatively consistent, its naming could lead to misinterpretation regarding epoch-specific allocations (7.4 Economic).

Upgrades1/10High risk

The contract utilizes the UUPS upgradeable proxy pattern, allowing for future logic updates (7.7 Upgrades). Upgrade authorization is appropriately restricted to the ADMIN_ROLE via _authorizeUpgrade, ensuring controlled evolution of the contract (7.3 Access Control, 7.7 Upgrades). The use of OpenZeppelin's Initializable and reinitializer patterns helps manage state transitions across upgrades. However, the centralized control of the ADMIN_ROLE for upgrades means that a compromise of this role could lead to unauthorized and potentially malicious contract changes (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is strongly recommended to address the high-severity issues, particularly the non-standard totalSupply() implementation and the centralization risks associated with initial minters.

A thorough audit of the Supply library is crucial to validate the core tokenomics. Consider implementing multi-signature control for critical roles like ADMIN_ROLE and initial minters to mitigate centralization risks. Enhance documentation for the totalSupply() function and reward claiming logic to prevent misinterpretation by integrators and users. Ensure robust operational procedures are in place for the epoch0StartTime initialization.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age11mo
Contract0x0000…5555
Deployer0x139c…2b69
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
ZK Coin 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, 202683High
  2. Aug 31, 202684High

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

Frequently Asked Questions

What is the ZKC contract address?

The ZK Coin (ZKC) contract on Ethereum is 0x000006c2a22ff4a44ff1f5d0f2ed65f781f55555. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is ZK Coin a scam?

Quantum Audit's risk score for ZK Coin is 83/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Who holds ZKC?

As of Sep 4, 2026, the 10 largest holders own 100.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
apyUSDEthereum83HighRe Protocol reUSDREUSD · Ethereum82HighSparkSPK · Ethereum84HighPepinaEthereum84HighEden TokenEDEN · Ethereum85CriticalGlobal DollarUSDG · Ethereum81High

Would You Like a More Detailed Audit of ZK Coin?

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