On-chain security analysis — is it a scam or legit?

Is ZygoSwap Safe?

ZSWAP

BNB Chain

Not verified

This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →

Last checked Sep 4, 2026 · 1 audit on record

Chart

21/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance8/10 Upgrades8/10 Checks passed5 of 5 Findings2 Critical · 1 Medium · 1 Info4

SummaryAI Copilot

The FourERC20 contract implements a standard ERC-20 token using OpenZeppelin's battle-tested patterns.

Read the full analysis

What raised the score

Top-10 concentration > 20%
2 Critical finding(s) from audit
1 Medium finding(s) from audit

Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

28.5%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking14.2%
Walletsanonymous holders, free to sell14.4%
Everyone elsethe rest of the supply71.5%

Effective concentrationwhat the score reads20.0%

How holder types affect the score

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

Liquidity

as of audit · Sep 4$147.1K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$132.2KShare of depth89.8%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

2 Critical1 Medium1 Info

Critical

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)C-01

Issue

Fix

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

Status

Unresolved

Critical

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)C-02

Issue

Fix

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.

Status

Unresolved

Medium

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)M-01

Issue

Fix

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.

Status

Unresolved

Info

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)I-01

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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

Governance8/10Low risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

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.