Is ZigCoin (ZIG) Safe? Smart Contract Security Analysis

Security Findings

1 Med3 Info

Medium

Centralized Initial Token Supply

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.

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

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

StatusUnresolved

Info

Fixed Token Supply

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.

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

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

StatusUnresolved

Info

Older Solidity Version Used

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.

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

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

StatusUnresolved

Info

Lack of Emergency Pause/Blacklist Functionality

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh3/10

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.

UpgradesLow7/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

73.6% in top 10

17.1% in wallets56.4% in contracts

Effective Concentration39.7%

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

$124.6K across 3 pairs

Uniswap v2WETHanalysed$117.7K Uniswap v3WETH$6.3K Uniswap v4USDT$564

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 Holder99.8%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0x3bcd…41f6

Unlocked LP Held By

0x98a8…a71b0x466a…9b5b0xbb0c…70d80x1f2f…f387

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

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (73.6% total → 39.7% effective; 17.1% in EOAs, 56.4% in contracts — moderate)
LP top1 unlocked holder = 99.8% (independent LP — depth risk, pool = 95% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
LP claimed locked but only 0.0% actually locked
1 Medium 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 ZigCoin Safe?

Security Findings

Centralized Initial Token Supply

Fixed Token Supply

Older Solidity Version Used

Lack of Emergency Pause/Blacklist Functionality

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of ZigCoin?