Quantum Audit Logo

Is Coinye West Safe?

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

Coinye West COINYE
0x0028…ca8b
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The CoinyeWest contract implements a standard ERC20 token with a fixed supply. The code is well-structured, follows OpenZeppelin patterns, and utilizes modern Solidity features like custom errors. No critical or high-severity vulnerabilities were identified. The design emphasizes decentralization with no administrative roles or upgradeability.

1 Low4 Informational
Volume 24h
$751.3300
Liquidity
$70.7K
Price
$0.0002901
Token Age
2y
Top 10 Holders
33.7%

Security Findings

1 Low4 Info
Low

Lack of Emergency Withdrawal Functionality

L-01The contract does not include a mechanism to recover accidentally sent ERC20 tokens or native currency (ETH) that might be sent to the contract address. While not directly impacting the core ERC20 functionality, such funds would be permanently locked and inaccessible (7.8 Operations).
IssueThe contract does not include a mechanism to recover accidentally sent ERC20 tokens or native currency (ETH) that might be sent to the contract address. While not directly impacting the core ERC20 functionality, such funds would be permanently locked and inaccessible (7.8 Operations).
FixImplement a function, callable by a trusted address (e.g., the deployer or a multisig), to withdraw accidentally sent ERC20 tokens or native currency from the contract. This function should include checks to prevent draining legitimate contract balances.
StatusUnresolved
Info

Fixed Supply Token

I-01The CoinyeWest token has a fixed total supply of 1,000,000,000 COINYE, all minted to the contract deployer during construction. There are no public functions to mint or burn tokens after deployment (7.4 Economic).
IssueThe CoinyeWest token has a fixed total supply of 1,000,000,000 COINYE, all minted to the contract deployer during construction. There are no public functions to mint or burn tokens after deployment (7.4 Economic).
FixThis is a design choice that ensures scarcity and predictability. Confirm that a fixed supply model aligns with the project's long-term economic strategy.
StatusUnresolved
Info

No Administrative Privileges

I-02The contract lacks any administrative roles such as an owner, minter, pauser, or blacklister. This design promotes decentralization and immutability (7.3 Access Control, 7.5 Governance).
IssueThe contract lacks any administrative roles such as an owner, minter, pauser, or blacklister. This design promotes decentralization and immutability (7.3 Access Control, 7.5 Governance).
FixThis design choice eliminates risks associated with centralized control but means there is no mechanism to pause transfers, recover accidentally sent tokens (as noted in L-01), or address potential future issues requiring administrative intervention. Ensure this level of decentralization is desired.
StatusUnresolved
Info

Use of Custom Errors

I-03The contract utilizes custom error types (e.g., `ERC20InsufficientBalance`, `ERC20InvalidSender`) instead of traditional `require` statements with string messages. This is a modern Solidity best practice (7.2 Code Security).
IssueThe contract utilizes custom error types (e.g., `ERC20InsufficientBalance`, `ERC20InvalidSender`) instead of traditional `require` statements with string messages. This is a modern Solidity best practice (7.2 Code Security).
FixThis approach improves gas efficiency and provides more structured, machine-readable error information, which is beneficial for dApp integration and debugging. No action required.
StatusUnresolved
Info

Appropriate Use of `unchecked` Blocks

I-04The contract employs `unchecked` blocks for arithmetic operations, specifically for `_balances[from] = fromBalance - value;`, `_balances[to] += value;`, and `_totalSupply -= value;`. In cases of subtraction, prior checks (`if (fromBalance < value)`) prevent underflow. For addition, `uint256` capacity is practically sufficient for the token's scale (7.2 Code Security).
IssueThe contract employs `unchecked` blocks for arithmetic operations, specifically for `_balances[from] = fromBalance - value;`, `_balances[to] += value;`, and `_totalSupply -= value;`. In cases of subtraction, prior checks (`if (fromBalance < value)`) prevent underflow. For addition, `uint256` capacity is practically sufficient for the token's scale (7.2 Code Security).
FixThe use of `unchecked` blocks here is a gas optimization technique and appears to be safe given the context and preceding checks. No action required.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical implementation of the CoinyeWest token is robust, adhering closely to the ERC20 standard and OpenZeppelin best practices. The contract effectively uses custom errors for improved gas efficiency and clarity (7.2 Code Security). Arithmetic operations within `unchecked` blocks are appropriately safeguarded by prior checks, preventing common integer overflow/underflow issues (7.2 Code Security). The architecture is simple and well-defined, with no complex external dependencies (7.1 Architecture). No reentrancy or other common EVM vulnerabilities were found.

GovernanceMedium6/10

The economic model is straightforward: a fixed supply token minted entirely to the deployer at creation (7.4 Economic). There are no governance mechanisms or administrative roles, promoting a highly decentralized and immutable token (7.5 Governance). This design choice eliminates risks associated with centralized control but also removes flexibility for future protocol adjustments or emergency interventions.

UpgradesLow7/10

The CoinyeWest contract is not designed to be upgradeable, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates all risks associated with proxy patterns, upgradeability bugs, or malicious upgrades. However, it also means that any discovered bugs or desired feature changes would require a new contract deployment and migration.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

33.7% in top 10
16.9% in wallets16.9% in contracts
Effective Concentration23.6%

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

$83.7K across 2 pairs
Uniswap v3WETHanalysed$70.7K84.5%Uniswap v2VIRTUAL$13.0K15.5%

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 Locked100.0% · UNCX Locker

Key Addresses

2 addresses
Deployer
0xbe4b…5e19
Unlocked LP Held By
0x159c…b329

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

What Raised This Score

3 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (33.7% total → 23.6% effective; 16.9% in EOAs, 16.9% in contracts — mild)
  • 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

Related Audits

6 more on the record
Briun Armstrung (BRIUN)Low RiskDebtReliefBot (DRB)Low RiskRUSSELLLow RiskVEIL Token (VEIL)Low RiskClawBankLow RiskToshiLow Risk

Would You Like a More Detailed Audit of Coinye West?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit