Quantum Audit Logo

Is ZK Coin Safe?

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

Is this your token? Publish your own audit on this page →

ZK Coin ZKC
0x0000…5555
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

2 High3 Medium1 Low
Volume 24h
$1.8K
Liquidity
$81.2K
Price
$0.04848
Token Age
11mo
Top 10 Holders
100.0%

Security Findings

2 High3 Med1 Low
High

Misleading `totalSupply()` Implementation

H-01The `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.
IssueThe `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.
FixIt 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.
StatusUnresolved
High

Centralization Risk of Initial Minting

H-02The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Critical `epoch0StartTime` Initialization

M-01The `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.
IssueThe `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.
FixEstablish 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.
StatusUnresolved
Medium

Reliance on Unaudited `Supply` Library for Core Tokenomics

M-02The 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.
IssueThe 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.
FixProvide 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.
StatusUnresolved
Medium

Centralized Control over Key Roles and Upgrades

M-03The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Low

Potential for Reward Claiming Logic Misinterpretation

L-01The 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.
IssueThe 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.
FixEnhance 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

100.0% in top 10
100.0% in wallets0.0% in contracts
Effective Concentration100.0%

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

$81.2K

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.

Key Addresses

1 addresses
Deployer
0x139c…2b69

What Raised This Score

7 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)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 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

Related Audits

6 more on the record
Eden Token (EDEN)Critical RiskGensyn (AI)Critical RiskRe Protocol reUSD (REUSD)Critical RiskCOTICritical Riskdmt-natCritical RiskAllora (ALLO)Critical Risk

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