Is ZygoSwap (ZSWAP) Safe? Smart Contract Security Analysis

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Audit History

2 audits on record

Jul 2322

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The FourERC20 contract implements a standard ERC-20 token using OpenZeppelin's battle-tested patterns. While the core token logic for transfers and allowances is robust, the contract suffers from critical architectural flaws. It lacks a public constructor to initialize its name and symbol, and crucially, it provides no public mechanism for minting tokens. These omissions render the token non-functional and unusable as a standalone ERC-20 asset, as its total supply will remain zero and its metadata uninitialized.

Final Recommendation: To make the FourERC20 token functional, a public constructor must be added to properly initialize the token's name and symbol. Furthermore, public functions with appropriate access control should be implemented to allow for the minting and burning of tokens, enabling supply management. Consider integrating an access control mechanism like OpenZeppelin's Ownable for administrative functions.

Category Ratings

TechnicalMedium

6/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

GovernanceLow

8/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 A

UpgradesLow

8/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 pers

LP Distribution

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

What Raised This Score

3 factors

Top-10 concentration > 20% (33.0% total → 25.2% effective; 20.0% in EOAs, 12.9% 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

Security Findings

4 total

2 Critical 1 Medium 1 Info

C-01CriticalUnresolved

Missing Constructor for Initialization

The `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)

Recommendation: Implement 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_); }`

C-02CriticalUnresolved

No Public Minting Mechanism

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

Recommendation: Implement 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.

M-01MediumUnresolved

Lack of Administrative Control Functions

The `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)

Recommendation: Consider 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.

I-01InformationalUnresolved

Missing Events for Initialization

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

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

Is ZygoSwap Safe? ZSWAP