On-chain security analysis — is it a scam or legit?
EthereumThe ZigCoin contract is a standard ERC-20 token implementation utilizing SafeMath for arithmetic operations.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x98a8…a71b0x466a…9b5b0xbb0c…70d80x1f2f…f387No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
msg.sender (the contract deployer) in the constructor. This centralizes the initial control of all tokens to a single address.M-01The entire supply of 2,000,000,000 ZIG tokens is minted to the msg.sender (the contract deployer) in the constructor. This centralizes the initial control of all tokens to a single address.
While a common pattern for new tokens, it is recommended to manage this large initial supply with robust security practices, such as a multi-signature wallet, to reduce the risk of a single point of failure or compromise. Transparency regarding the distribution plan for these tokens is also advised.
Unresolved
_mint and _burn functions are internal and not exposed.I-01The contract implements a fixed total supply of tokens, with no external functions for additional minting or burning after the initial deployment. The _mint and _burn functions are internal and not exposed.
This is a design choice that ensures a predictable token supply. Ensure this fixed supply model aligns with the project's long-term economic strategy and communicate this clearly to the community.
Unresolved
^0.7.6. While this version is functional, newer Solidity versions (e.g., 0.8.x) include additional safety checks by default (like arithmetic overflow/underflow checks) and performance improvements.I-02The contract is compiled with Solidity version ^0.7.6. While this version is functional, newer Solidity versions (e.g., 0.8.x) include additional safety checks by default (like arithmetic overflow/underflow checks) and performance improvements.
Consider upgrading to a more recent Solidity version (e.g., 0.8.x) for future contract deployments to benefit from enhanced compiler optimizations and built-in security features. If upgrading, ensure thorough testing as syntax and behavior might differ slightly.
Unresolved
The ZigCoin contract is a basic ERC-20 implementation and does not include any mechanisms for pausing transfers or blacklisting malicious addresses. This means that in the event of a critical vulnerability or exploit, there is no built-in way to halt operations or freeze compromised accounts.
For simple, immutable tokens, this design choice reduces complexity and centralization. However, for more complex protocols or those handling significant value, consider if a limited, multi-sig controlled pause or blacklist mechanism might be beneficial for emergency response, carefully weighing the trade-offs with centralization.
Unresolved
The ZigCoin contract is a standard ERC-20 token implementation utilizing SafeMath for arithmetic operations. The primary risk identified is the centralized distribution of the entire token supply to the deployer at creation. The contract is not upgradeable and lacks advanced features like pausing or role-based access control, which simplifies its attack surface but also limits emergency response capabilities.
The technical architecture (7.1) is a straightforward ERC-20 token, inheriting from a custom ERC20 implementation that includes SafeMath. Code security (7.2) is robust for arithmetic operations due to the diligent use of SafeMath, mitigating common integer overflow/underflow vulnerabilities. Access control (7.3) is minimal, limited to standard ERC-20 approval mechanisms, with no privileged roles beyond the initial deployer receiving all tokens. External interactions (7.6) are limited to standard token transfers, and operational complexity (7.8) is low, reducing the attack surface. The use of Solidity 0.7.6 is an older version, but does not introduce specific vulnerabilities for this simple contract.
The economic model (7.4) of ZigCoin involves a fixed total supply, with all tokens minted to the deployer's address during contract creation. This design choice centralizes the initial distribution, giving the deployer significant control over the token's initial liquidity and market dynamics. There are no governance mechanisms (7.5) implemented within the contract, meaning no on-chain voting or community-driven changes are possible. The absence of features like pausing or blacklisting, while simplifying the contract, also means there's no emergency response mechanism for potential exploits or malicious activity involving token holders.
The ZigCoin contract is not designed with upgradeability (7.7) in mind, meaning it is immutable once deployed. This eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs, upgrade path vulnerabilities, or administrative key compromises. While this provides immutability and predictability, it also means that any discovered bugs or desired feature enhancements cannot be implemented without deploying a new contract.
It is recommended to clearly communicate the centralized nature of the initial token distribution to all stakeholders.
Consider implementing a multi-signature wallet for the deployer's address holding the initial token supply to mitigate single point of failure risks. For future projects, evaluate the necessity of upgradeability and emergency pause mechanisms based on the project's complexity and risk profile.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The ZigCoin (ZIG) contract on Ethereum is 0xb2617246d0c6c0087f18703d576831899ca94f01. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for ZigCoin is 38/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $124.6K.
As of Sep 4, 2026, the 10 largest holders own 73.6% of the supply. The Holders section on this page shows who they are by holder type.
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
