Is ZygoSwap (ZSWAP) Safe? Smart Contract Security Analysis

Security Findings

2 Crit1 Med1 Info

Critical

Missing Constructor for Initialization

C-01The `FourERC20` contract includes an internal `_init` function for setting the token's name and symbol, but it lacks a public constructor to call this function. Consequently, upon deployment, the `_name` and `_symbol` state variables will remain uninitialized (empty strings), making the token non-compliant with standard ERC-20 metadata expectations and difficult to identify on block explorers. (7.1 Architecture, 7.8 Operations)

IssueThe `FourERC20` contract includes an internal `_init` function for setting the token's name and symbol, but it lacks a public constructor to call this function. Consequently, upon deployment, the `_name` and `_symbol` state variables will remain uninitialized (empty strings), making the token non-compliant with standard ERC-20 metadata expectations and difficult to identify on block explorers. (7.1 Architecture, 7.8 Operations)

FixImplement a public constructor in `FourERC20` that calls `_init(name_, symbol_)` to properly set the token's metadata at deployment. For example: `constructor(string memory name_, string memory symbol_) { _init(name_, symbol_); }`

StatusUnresolved

Critical

No Public Minting Mechanism

C-02The contract provides an internal `_mint` function but does not expose any public or external function to invoke it. As a result, the `_totalSupply` will always remain zero, and no tokens can ever be created or distributed. This renders the ERC-20 token completely non-functional and unusable for its intended purpose. (7.1 Architecture, 7.4 Economic, 7.8 Operations)

IssueThe contract provides an internal `_mint` function but does not expose any public or external function to invoke it. As a result, the `_totalSupply` will always remain zero, and no tokens can ever be created or distributed. This renders the ERC-20 token completely non-functional and unusable for its intended purpose. (7.1 Architecture, 7.4 Economic, 7.8 Operations)

FixImplement a public function (e.g., `mint(address to, uint256 amount)`) that calls the internal `_mint` function. This function should include appropriate access control (e.g., `onlyOwner`) to restrict who can mint new tokens.

StatusUnresolved

Medium

Lack of Administrative Control Functions

M-01The `FourERC20` contract does not inherit from `Ownable` or implement any custom access control mechanisms. This means there are no administrative functions to manage critical aspects such as pausing transfers, setting a minter role, or upgrading the contract (if it were part of a proxy system). This limits operational flexibility and the ability to respond to emergencies or evolving protocol needs. (7.3 Access Control, 7.8 Operations)

IssueThe `FourERC20` contract does not inherit from `Ownable` or implement any custom access control mechanisms. This means there are no administrative functions to manage critical aspects such as pausing transfers, setting a minter role, or upgrading the contract (if it were part of a proxy system). This limits operational flexibility and the ability to respond to emergencies or evolving protocol needs. (7.3 Access Control, 7.8 Operations)

FixConsider inheriting from OpenZeppelin's `Ownable` or `AccessControl` to implement administrative roles. This would allow for controlled execution of sensitive functions, such as a `pause` mechanism or a designated minter role, if such functionalities are desired.

StatusUnresolved

Info

Missing Events for Initialization

I-01The internal `_init` function, which sets the token's name and symbol, does not emit any event. While not a direct vulnerability, emitting an event (e.g., `Initialized(string name, string symbol)`) upon successful initialization would provide a clear on-chain record of these critical parameters, aiding off-chain monitoring and indexing services. (7.8 Operations)

IssueThe internal `_init` function, which sets the token's name and symbol, does not emit any event. While not a direct vulnerability, emitting an event (e.g., `Initialized(string name, string symbol)`) upon successful initialization would provide a clear on-chain record of these critical parameters, aiding off-chain monitoring and indexing services. (7.8 Operations)

FixAdd an event emission within the `_init` function to log the token's name and symbol upon initialization.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin ERC-20 implementations for core functionalities like `transfer` and `approve`, which inherently reduces common code security risks (7.2 Code Security). However, a critical architectural flaw (7.1 Architecture) exists where the contract lacks a public constructor to initialize its name and symbol, and no public functions are provided for minting or burning tokens, rendering the token non-functional. The internal `_mint` and `_burn` functions are inaccessible, preventing any supply management (7.8 Operations).

GovernanceLow8/10

The contract implements a basic ERC-20 token with no complex economic model or governance mechanisms (7.4 Economic, 7.5 Governance). This simplicity reduces the attack surface related to economic manipulation or governance exploits. However, the absence of any administrative control functions (7.3 Access Control) means there is no mechanism to manage token supply or respond to emergencies, which could be a limitation for certain use cases.

UpgradesLow8/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), which eliminates risks associated with proxy implementation, storage collisions, or upgrade path vulnerabilities. This design choice simplifies the deployment and reduces the complexity of long-term maintenance from an upgrade perspective, as no upgrade mechanisms need to be secured.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

28.5% in top 10

14.4% in wallets14.2% in contracts

Effective Concentration20.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

$147.1K across 3 pairs

Pancakeswap v2WBNBanalysed$132.2K 0xc8A1…12C3WBNB$14.9K

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

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

1 addresses

Deployer

0xd9a6…d540

What Raised This Score

3 factors

Top-10 concentration > 20% (28.5% total → 20.0% effective; 14.4% in EOAs, 14.2% in contracts — mild)
2 Critical finding(s) from audit
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 ZygoSwap Safe?

Security Findings

Missing Constructor for Initialization

No Public Minting Mechanism

Lack of Administrative Control Functions

Missing Events for Initialization

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 ZygoSwap?