Quantum Audit Logo

Is CZ Terminal Token Safe?

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

Is this your token? Publish your own audit on this page →

CZ Terminal Token CZT
0x9385…798c
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

This audit covers the provided partial source code for the CZTerminalToken contract. The contract implements a standard ERC20 token with Ownable access control and integrates with a DEX router. Key features include anti-whale mechanisms (maxBuyAmount, maxSellAmount, maxWalletAmount) and a 'swapping' flag, though the full implementation details for these features and potential fee-on-transfer logic are not available in the truncated code. The core ERC20 logic appears robust, utilizing OpenZeppelin patterns and safe `unchecked` blocks. However, the absence of complete code for critical tokenomic features and DEX interactions prevents a comprehensive assessment of their security and effectiveness.

1 High2 Medium2 Low1 Informational
Volume 24h
$7.6K
Liquidity
$40.1K
Price
$0.0007337
Token Age
14d
Top 10 Holders
18.2%

Security Findings

1 High2 Med2 Low1 Info
High

Incomplete Anti-Whale/Transaction Limit Implementation

H-01The contract declares `maxBuyAmount`, `maxSellAmount`, and `maxWalletAmount` variables, indicating an intention to implement anti-whale or transaction limit mechanisms. However, the provided `_transfer`, `_mint`, and `_burn` functions, which are the core logic for token movement, do not contain any checks or enforcement logic for these limits. Without proper implementation, these limits are ineffective and can be bypassed, potentially leading to market manipulation or concentrated holdings.
IssueThe contract declares `maxBuyAmount`, `maxSellAmount`, and `maxWalletAmount` variables, indicating an intention to implement anti-whale or transaction limit mechanisms. However, the provided `_transfer`, `_mint`, and `_burn` functions, which are the core logic for token movement, do not contain any checks or enforcement logic for these limits. Without proper implementation, these limits are ineffective and can be bypassed, potentially leading to market manipulation or concentrated holdings.
FixImplement comprehensive checks within the `_transfer`, `_mint`, and `_burn` functions (or their respective hooks like `_beforeTokenTransfer`) to enforce `maxBuyAmount`, `maxSellAmount`, and `maxWalletAmount` for all relevant transactions. Ensure these checks cover both direct transfers and transfers via `transferFrom`.
StatusUnresolved
Medium

Potential Reentrancy in DEX Interactions (Truncated Code)

M-01The contract includes a `swapping` flag, which is a common pattern for reentrancy protection. However, the full implementation of functions interacting with `IDexRouter` (e.g., `swapExactTokensForETHSupportingFeeOnTransferTokens`) is not provided. If external calls to the DEX router are made within critical state-changing functions without proper reentrancy guards (e.g., using the `swapping` flag correctly, Checks-Effects-Interactions pattern), it could expose the contract to reentrancy attacks.
IssueThe contract includes a `swapping` flag, which is a common pattern for reentrancy protection. However, the full implementation of functions interacting with `IDexRouter` (e.g., `swapExactTokensForETHSupportingFeeOnTransferTokens`) is not provided. If external calls to the DEX router are made within critical state-changing functions without proper reentrancy guards (e.g., using the `swapping` flag correctly, Checks-Effects-Interactions pattern), it could expose the contract to reentrancy attacks.
FixEnsure that all functions involving external calls, especially to `IDexRouter`, are protected against reentrancy. Verify that the `swapping` flag is correctly set before external calls and reset afterwards, and that all state changes occur before any external calls. Consider using OpenZeppelin's `ReentrancyGuard` for robust protection.
StatusUnresolved
Medium

Unverified Fee-on-Transfer Logic (Truncated Code)

M-02The `IDexRouter` interface includes `swapExactTokensForETHSupportingFeeOnTransferTokens`, implying that the token might implement a fee-on-transfer mechanism. While `_beforeTokenTransfer` and `_afterTokenTransfer` hooks are present, their implementation is empty in the provided code. Without the full logic, it's impossible to verify if fees are correctly handled, especially for transfers to/from DEX liquidity pools, to prevent issues like liquidity drain, failed swaps, or incorrect accounting for fee-exempt addresses.
IssueThe `IDexRouter` interface includes `swapExactTokensForETHSupportingFeeOnTransferTokens`, implying that the token might implement a fee-on-transfer mechanism. While `_beforeTokenTransfer` and `_afterTokenTransfer` hooks are present, their implementation is empty in the provided code. Without the full logic, it's impossible to verify if fees are correctly handled, especially for transfers to/from DEX liquidity pools, to prevent issues like liquidity drain, failed swaps, or incorrect accounting for fee-exempt addresses.
FixThoroughly implement and test the fee-on-transfer logic within `_beforeTokenTransfer` or `_afterTokenTransfer`. Ensure that transfers to/from the DEX router and other critical protocols (e.g., staking contracts) are properly exempted from fees to maintain compatibility and prevent unexpected behavior. Document the fee mechanism clearly.
StatusUnresolved
Low

Centralization Risk with Owner Privileges

L-01The contract uses the `Ownable` pattern, granting the `owner` address exclusive control over sensitive functions (e.g., `transferOwnership`, `renounceOwnership`). While standard, this introduces a single point of failure. If the owner's private key is compromised, a malicious actor could gain full control over these administrative functions, potentially leading to severe consequences for the protocol.
IssueThe contract uses the `Ownable` pattern, granting the `owner` address exclusive control over sensitive functions (e.g., `transferOwnership`, `renounceOwnership`). While standard, this introduces a single point of failure. If the owner's private key is compromised, a malicious actor could gain full control over these administrative functions, potentially leading to severe consequences for the protocol.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the `owner` address to distribute control and reduce the risk associated with a single point of failure. Alternatively, explore a time-locked ownership transfer mechanism for critical operations.
StatusUnresolved
Low

Standard ERC20 `approve` Front-Running Vulnerability

L-02The standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user approves an amount, then decides to decrease that allowance and sends a `decreaseAllowance` transaction, a malicious actor could front-run the `decreaseAllowance` by spending the original approved amount. This allows the attacker to spend the original allowance, and then the `decreaseAllowance` transaction will still execute, potentially allowing the attacker to spend the new (lower) allowance as well.
IssueThe standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user approves an amount, then decides to decrease that allowance and sends a `decreaseAllowance` transaction, a malicious actor could front-run the `decreaseAllowance` by spending the original approved amount. This allows the attacker to spend the original allowance, and then the `decreaseAllowance` transaction will still execute, potentially allowing the attacker to spend the new (lower) allowance as well.
FixWhile `increaseAllowance` and `decreaseAllowance` mitigate this for most use cases, users should be advised to set allowances to zero before increasing them if they are concerned about this specific front-running vector with the base `approve` function. For critical operations, consider a two-step approval process.
StatusUnresolved
Info

Missing Specific Events for Minting and Burning

I-01The `_mint` and `_burn` functions emit standard `Transfer` events (from address(0) for mint, to address(0) for burn). While technically correct according to ERC20, having specific `Mint` and `Burn` events (e.g., `event Mint(address indexed to, uint256 amount);`) could provide clearer and more granular off-chain monitoring and indexing capabilities for these distinct token lifecycle operations.
IssueThe `_mint` and `_burn` functions emit standard `Transfer` events (from address(0) for mint, to address(0) for burn). While technically correct according to ERC20, having specific `Mint` and `Burn` events (e.g., `event Mint(address indexed to, uint256 amount);`) could provide clearer and more granular off-chain monitoring and indexing capabilities for these distinct token lifecycle operations.
FixConsider adding dedicated `Mint` and `Burn` events within the `_mint` and `_burn` functions, respectively. This would enhance transparency and simplify off-chain analysis of token supply changes.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract utilizes OpenZeppelin's `Context` and `ERC20` implementations, providing a solid foundation for token functionality (7.1 Architecture, 7.2 Code Security). Solidity 0.8.x's default overflow/underflow checks are leveraged, with `unchecked` blocks used safely after explicit `require` checks. However, the provided code is truncated, leaving critical parts of the token's logic, such as the enforcement of `maxBuyAmount`, `maxSellAmount`, and `maxWalletAmount`, unverified (7.2 Code Security). The presence of a `swapping` flag suggests reentrancy protection, but its full implementation and coverage for DEX interactions are not visible, posing a potential risk (7.2 Code Security).

GovernanceLow8/10

The contract employs the `Ownable` pattern, granting the deployer significant control over the contract's parameters and potentially critical functions (7.3 Access Control). This introduces a centralization risk, as a compromised owner key could lead to severe consequences (7.5 Governance). The contract defines `maxBuyAmount`, `maxSellAmount`, and `maxWalletAmount` to implement anti-whale or transaction limits, which are crucial for the token's economic model (7.4 Economic). However, the enforcement logic for these limits is not present in the provided code, making their effectiveness uncertain and potentially bypassable (7.4 Economic).

UpgradesLow10/10

The contract is not designed as an upgradeable proxy, as indicated by `is_proxy: false` in the prefill. Therefore, upgrade safety concerns are not applicable to this specific deployment (7.7 Upgrades). Any future changes would require deploying a new contract and migrating assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

18.2% in top 10
10.6% in wallets7.6% in contracts
Effective Concentration13.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

$40.1K

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% · Null Address, PinkLock02

Key Addresses

2 addresses
Deployer
0x7703…a1a2
Unlocked LP Held By
0x7703…a1a2

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

5 factors
  • Liquidity < $50k ($40,054 across 1 pairs — thin market)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
IBSLow RiskBEMLow RiskZygoSwap (ZSWAP)Medium RiskSIRENMedium RiskDBURNLow RiskANDYMedium Risk

Would You Like a More Detailed Audit of CZ Terminal Token?

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

Get Detailed Audit