Quantum Audit Logo

Is CZ'S DOG Safe?

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

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

CZ'S DOG BROCCOLI
0x6d5a…6714
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of the Token contract identified a critical vulnerability where the token becomes permanently unusable if ownership is renounced while transfer restrictions are active. This is compounded by the initial `MODE_TRANSFER_RESTRICTED` state and the provided `ownership_renounced: true` status. Additional findings include a potential revert in `increaseAllowance`, an irreversible design choice for transfer modes, and minor best practice recommendations.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$175.9K
Liquidity
$1.99M
Price
$0.01859
Token Age
1y
Top 10 Holders
81.4%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Token Permanently Unusable Due to Renounced Ownership and Transfer Restrictions

C-01The `Token` contract initializes with `_mode = MODE_TRANSFER_RESTRICTED`, preventing all transfers. The `setMode` function, which can change `_mode` to `MODE_NORMAL` (allowing free transfers), is protected by `onlyOwner`. According to the provided information, ownership has been renounced (`ownership_renounced: true`), meaning `owner()` is `address(0)`. Consequently, `setMode` can no longer be called. If `_mode` was not set to `MODE_NORMAL` *before* ownership renunciation, the token is permanently stuck in `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED` (where transfers are only to/from `address(0)`), rendering it completely unusable for its intended purpose.
IssueThe `Token` contract initializes with `_mode = MODE_TRANSFER_RESTRICTED`, preventing all transfers. The `setMode` function, which can change `_mode` to `MODE_NORMAL` (allowing free transfers), is protected by `onlyOwner`. According to the provided information, ownership has been renounced (`ownership_renounced: true`), meaning `owner()` is `address(0)`. Consequently, `setMode` can no longer be called. If `_mode` was not set to `MODE_NORMAL` *before* ownership renunciation, the token is permanently stuck in `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED` (where transfers are only to/from `address(0)`), rendering it completely unusable for its intended purpose.
FixFor any token intended for general use, ensure that transfer restrictions are lifted (i.e., `setMode(MODE_NORMAL)` is called) *before* renouncing ownership. If ownership renunciation is a project goal, a mechanism to manage critical parameters like `_mode` without an owner should be considered, such as a time-locked governance or a pre-defined transition schedule.
StatusUnresolved
High

`increaseAllowance` Potential Revert on Overflow

H-01The `increaseAllowance` function calculates `allowance(owner, spender) + addedValue`. If the sum exceeds `type(uint256).max`, the transaction will revert. While this prevents an overflow, it can lead to unexpected reverts for users attempting to increase allowance to a very large value, especially if the current allowance is already substantial. This behavior deviates from common ERC20 implementations where `increaseAllowance` often allows for "infinite" approvals (by setting to `type(uint256).max`) or handles large additions without reverting. This could disrupt user experience for high-value operations.
IssueThe `increaseAllowance` function calculates `allowance(owner, spender) + addedValue`. If the sum exceeds `type(uint256).max`, the transaction will revert. While this prevents an overflow, it can lead to unexpected reverts for users attempting to increase allowance to a very large value, especially if the current allowance is already substantial. This behavior deviates from common ERC20 implementations where `increaseAllowance` often allows for "infinite" approvals (by setting to `type(uint256).max`) or handles large additions without reverting. This could disrupt user experience for high-value operations.
FixTo align with common ERC20 behavior and prevent unexpected reverts for large allowance increases, consider wrapping the addition `allowance(owner, spender) + addedValue` in an `unchecked` block. Alternatively, explicitly check for overflow and revert with a more specific error message if a maximum allowance is intended, or cap the `addedValue`.
StatusUnresolved
Medium

Immutability of `_mode` to `MODE_NORMAL`

M-01The `setMode` function includes the condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This design means that once the token's `_mode` is set to `MODE_NORMAL`, it cannot be changed back to `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`. This makes the token's transferability permanently unrestricted once `MODE_NORMAL` is activated, which is an irreversible decision with long-term implications for project control and potential future incident response.
IssueThe `setMode` function includes the condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This design means that once the token's `_mode` is set to `MODE_NORMAL`, it cannot be changed back to `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`. This makes the token's transferability permanently unrestricted once `MODE_NORMAL` is activated, which is an irreversible decision with long-term implications for project control and potential future incident response.
FixConfirm that this permanent immutability of `MODE_NORMAL` is an intentional design decision. If there's a possibility that future restrictions might be required (e.g., in response to security incidents or regulatory changes), the logic in `setMode` should be adjusted to allow for re-enabling restrictions by the owner (if an owner exists).
StatusUnresolved
Low

Unlocked Solidity Pragma

L-01The contract uses `pragma solidity ^0.8.0;`. This allows compilation with any compiler version from 0.8.0 up to, but not including, 0.9.0. Using a floating pragma can lead to inconsistent bytecode if different compiler versions are used, potentially introducing subtle bugs or unexpected behavior due to compiler updates.
IssueThe contract uses `pragma solidity ^0.8.0;`. This allows compilation with any compiler version from 0.8.0 up to, but not including, 0.9.0. Using a floating pragma can lead to inconsistent bytecode if different compiler versions are used, potentially introducing subtle bugs or unexpected behavior due to compiler updates.
FixLock the Solidity pragma to the specific compiler version used for deployment (e.g., `pragma solidity 0.8.20;`) to ensure deterministic compilation and prevent potential issues with future compiler versions.
StatusUnresolved
Info

Missing Event for `setMode`

I-01The `setMode` function modifies the critical `_mode` state variable, which dictates the token's transferability. However, no event is emitted when the mode is changed. Emitting an event would provide crucial on-chain transparency and allow off-chain monitoring tools and users to track changes in the token's operational status.
IssueThe `setMode` function modifies the critical `_mode` state variable, which dictates the token's transferability. However, no event is emitted when the mode is changed. Emitting an event would provide crucial on-chain transparency and allow off-chain monitoring tools and users to track changes in the token's operational status.
FixAdd an event, such as `event ModeChanged(uint256 oldMode, uint256 newMode);`, and emit it within the `setMode` function after the `_mode` variable is updated.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract implements a standard ERC20 token with `Ownable` access control. It correctly uses `unchecked` blocks for most arithmetic operations after necessary checks, preventing common integer overflows/underflows (7.2 Code Security). However, the `increaseAllowance` function lacks an `unchecked` block for addition, potentially causing reverts for large values. The `_beforeTokenTransfer` hook is effectively used to implement custom transfer restrictions (7.1 Architecture).

GovernanceMedium4/10

The token incorporates a `_mode` mechanism to control transferability, allowing for restricted, controlled, or normal modes (7.4 Economic). The `setMode` function is `onlyOwner`, providing centralized control over this critical parameter (7.3 Access Control). A significant risk arises if ownership is renounced while the token is in a restricted mode, as the `setMode` function becomes inaccessible, permanently locking the token's transferability (7.5 Governance). The initial `_mode` is `MODE_TRANSFER_RESTRICTED`, making this a critical concern.

UpgradesLow8/10

The contract is not designed with an upgradeability pattern (e.g., proxy) and is therefore immutable once deployed. This simplifies its architecture by removing upgrade-related complexities and risks (7.7 Upgrades). Any changes to the contract's logic would require a new deployment and migration of assets.

Security Checklist

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

Holder Composition

81.4% in top 10
72.1% in wallets9.3% in contracts
Effective Concentration75.8%

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

$2.65M across 12 pairs
Pancakeswap v3WBNBanalysed$1.99M75.0%Pancakeswap v2WBNB$660.5K24.9%Squadswap v2WBNB$2.2K0.1%Pancakeswap v3USDC$1.1K0.0%Pancakeswap v3USDT$4770.0%UniswapWBNB$1020.0%
Show 4 more pairsShow less
MdexWBNB$80.0%0xb7E5…039CWBNB$50.0%Pancakeswap v2USD1$10.0%UniswapUSDT$10.0%

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 Locked68.8% · GoPlus SafeToken Locker
Top-1 Unlocked Holder20.2%
Top-3 Unlocked31.1%

Key Addresses

10 addresses
Deployer
0x392e…3924
Unlocked LP Held By
0x7497…36d00x5036…6a200xaded…46b60x556b…d59e0x966d…e41a0xf7b5…787d0x8e0a…76c10xb262…eeed0x7137…bcaf

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

What Raised This Score

5 factors
  • Top-10 concentration > 70% (81.4% total → 75.8% effective; 72.1% in EOAs, 9.3% in contracts — extreme)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 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
Bitway Token (BTW)Medium RiskMarsCoinMedium RiskCharacterX (CAI)Medium RiskMame Inu (MAME)Medium RiskAPRO oracle Token (AT)Medium Riskutility token (UTILITY)Medium Risk

Would You Like a More Detailed Audit of CZ'S DOG?

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

Get Detailed Audit