Quantum Audit Logo
Launch App

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

Is CZ'S DOG Safe?

BROCCOLIBNB 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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance4/10Upgrades8/10Checks passed5 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
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.

Read the full analysis
What raised the score
  • Top-10 concentration > 70%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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
9.3%Contracts72.1%Wallets18.6%Everyone else
9.3%72.1%Wallets18.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
81.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking9.3%
  • Walletsanonymous holders, free to sell72.1%
  • Everyone elsethe rest of the supply18.6%
Effective concentrationwhat the score reads75.8%
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$2.65M across 12 pairs
Show 4 more pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$1.99MShare of depth75.0%
LP Locked68.8% · GoPlus SafeToken Locker
Top-1 Unlocked Holder20.2%
Top-3 Unlocked31.1%
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.

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Token Permanently Unusable Due to Renounced Ownership and Transfer Restrictions

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

High

increaseAllowance Potential Revert on Overflow

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Immutability of _mode to MODE_NORMAL

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Unlocked Solidity Pragma

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Missing Event for setMode

The 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.I-01

Issue

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

Fix

Add an event, such as event ModeChanged(uint256 oldMode, uint256 newMode);, and emit it within the setMode function after the _mode variable is updated.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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

Governance4/10Medium risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

Prioritize addressing the critical issue of token usability.

If the token is intended for general circulation, ensure setMode(MODE_NORMAL) is called *before* ownership is renounced. For future deployments, consider a more robust mechanism for managing critical parameters like transfer modes if ownership renunciation is a goal, potentially involving a multi-sig or time-locked contract. Additionally, review the increaseAllowance implementation to prevent unexpected reverts and consider adding events for critical state changes like setMode for enhanced transparency.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x6d5a…6714
Deployer0x392e…3924
Badge for your website
CZ'S DOG security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 11, 202639Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
Bitway TokenBTW · BNB Chain39MediumMarsCoinBNB Chain39MediumCharacterXCAI · BNB Chain39Medium永生果蝇果蝇 · BNB Chain39MediumFetchFET · BNB Chain39MediumR2BNB Chain39Medium

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 Is this your token? Publish your own audit on this page