Is Zcash Token (ZEC) Safe? Smart Contract Security Analysis

Security Findings

2 Med1 Low1 Info

Medium

Centralized Minting Capability

M-01The `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This grants the owner the unilateral ability to increase the total token supply at any time. This centralization introduces a significant economic risk, as a compromised owner key or a malicious owner could lead to arbitrary inflation, devaluing existing token holders' assets (7.3 Access Control, 7.4 Economic).

IssueThe `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This grants the owner the unilateral ability to increase the total token supply at any time. This centralization introduces a significant economic risk, as a compromised owner key or a malicious owner could lead to arbitrary inflation, devaluing existing token holders' assets (7.3 Access Control, 7.4 Economic).

FixConsider if the minting capability is strictly necessary. If so, implement a more decentralized control mechanism, such as a multi-signature wallet for the owner address, a time-locked minting schedule, or a community governance system. If not essential, remove the `mint` function entirely to establish a fixed supply.

StatusUnresolved

Medium

Outdated Solidity Compiler Version

M-02The contract is compiled with Solidity version `0.5.16`. While `SafeMath` mitigates common integer issues, older compiler versions may lack recent security patches, optimizations, or introduce subtle vulnerabilities that have been addressed in newer versions (e.g., 0.8.x series). Using an outdated compiler can expose the contract to known or undiscovered compiler-level bugs (7.2 Code Security).

IssueThe contract is compiled with Solidity version `0.5.16`. While `SafeMath` mitigates common integer issues, older compiler versions may lack recent security patches, optimizations, or introduce subtle vulnerabilities that have been addressed in newer versions (e.g., 0.8.x series). Using an outdated compiler can expose the contract to known or undiscovered compiler-level bugs (7.2 Code Security).

FixUpgrade the Solidity compiler to a more recent, stable version (e.g., 0.8.x). This would require careful testing and adaptation of the code, especially regarding `SafeMath` (which is often no longer needed in 0.8.x due to default overflow/underflow checks) and other syntax changes.

StatusUnresolved

Low

Standard ERC-20 `approve` Race Condition

L-01The `approve` function is susceptible to a known ERC-20 front-running vulnerability. If a user calls `approve(spender, newAmount)` while the `spender` is concurrently trying to `transferFrom` an existing allowance, the `spender` might be able to spend both the old and new allowance. While the contract includes `increaseAllowance` and `decreaseAllowance` which mitigate this for users who utilize them, direct `approve` calls remain vulnerable (7.2 Code Security).

IssueThe `approve` function is susceptible to a known ERC-20 front-running vulnerability. If a user calls `approve(spender, newAmount)` while the `spender` is concurrently trying to `transferFrom` an existing allowance, the `spender` might be able to spend both the old and new allowance. While the contract includes `increaseAllowance` and `decreaseAllowance` which mitigate this for users who utilize them, direct `approve` calls remain vulnerable (7.2 Code Security).

FixEducate users to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. For new allowances, `approve` is safe. This is a common ERC-20 pattern, and the provided mitigation functions are good practice.

StatusUnresolved

Info

Unused Code and Redundant Function

I-01The contract contains several pieces of code that are either unused or redundant: 1. The internal function `_burnFrom` is defined but never called by any public or internal function within `BEP20Zcash`. 2. The `getOwner()` external view function simply calls the inherited `owner()` function from `Ownable`, adding an unnecessary layer of abstraction. 3. The `_msgData()` function in the `Context` library is not used by `BEP20Zcash`, and the `this;` statement within `_msgData()` is a no-op. These elements increase contract size and complexity without providing functionality (7.2 Code Security, 7.1 Architecture).

IssueThe contract contains several pieces of code that are either unused or redundant: 1. The internal function `_burnFrom` is defined but never called by any public or internal function within `BEP20Zcash`. 2. The `getOwner()` external view function simply calls the inherited `owner()` function from `Ownable`, adding an unnecessary layer of abstraction. 3. The `_msgData()` function in the `Context` library is not used by `BEP20Zcash`, and the `this;` statement within `_msgData()` is a no-op. These elements increase contract size and complexity without providing functionality (7.2 Code Security, 7.1 Architecture).

FixRemove the unused `_burnFrom` function, the redundant `getOwner()` function, and the unused `_msgData()` function along with its `this;` statement. This will reduce contract size, improve readability, and potentially save gas during deployment.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates solid technical foundations, utilizing the `SafeMath` library to prevent common integer overflow/underflow vulnerabilities (7.2 Code Security). It implements the BEP-20 standard correctly, including `increaseAllowance` and `decreaseAllowance` to mitigate the `approve` race condition (7.2 Code Security). However, the use of an outdated Solidity compiler version (0.5.16) could expose the contract to potential, yet unknown, vulnerabilities or inefficiencies (7.2 Code Security). Additionally, minor code quality issues like unused functions and redundant code exist (7.2 Code Security).

GovernanceHigh1/10

The economic model is straightforward, with a fixed initial supply and standard BEP-20 token transfers (7.4 Economic). The `Ownable` pattern provides clear access control for critical functions, such as `mint` and `transferOwnership` (7.3 Access Control). A significant economic risk lies in the centralized `mint` function, which allows the contract owner to increase the total supply at will, potentially devaluing existing tokens (7.4 Economic). This central point of control introduces a single point of failure and governance risk (7.5 Governance).

UpgradesHigh3/10

This contract is not designed with an upgrade mechanism, meaning its logic is immutable once deployed (7.7 Upgrades). This provides certainty regarding the contract's behavior over its lifetime. However, any discovered critical vulnerabilities would necessitate a redeployment and migration of assets, which can be a complex and costly process (7.7 Upgrades).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

84.8% in top 10

84.8% in wallets0.0% in contracts

Effective Concentration84.8%

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.35M across 29 pairs

UniswapUSDTanalysed$966.6K Pancakeswap v3BTCB$603.1K Pancakeswap v3USDT$437.7K Pancakeswap v3PIRATE$327.5K UniswapBTCB$213.4K Pancakeswap v3WBNB$117.6K

Show 4 more pairsShow less

Pancakeswap v3USDT$117.4K UniswapWBNB$116.0K Pancakeswap v3WBNB$95.2K Pancakeswap v3USDT$92.8K

The 19 remaining pairs hold $258.8K 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 Holder33.7%

Top-3 Unlocked63.2%

Key Addresses

11 addresses

Deployer

0x88ef…0566

Unlocked LP Held By

0x8df4…abf50x892f…7b180xc3f6…fd9b0x95a2…a8d60xd242…acc70xa427…e0280x66c4…ea170xac70…b1a80xa5f3…4cf20x120c…0a15

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 NOT renounced — owner is an EOA (single private key)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 70% (84.8% total → 84.8% effective; 84.8% in EOAs, 0.0% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
2 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

Not Signed In

Is Zcash Token Safe?

Security Findings

Centralized Minting Capability

Outdated Solidity Compiler Version

Standard ERC-20 `approve` Race Condition

Unused Code and Redundant Function

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 Zcash Token?