Quantum Audit Logo
Launch App

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

Is Tagger Safe?

TAGBNB 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 · 2 audits on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance6/10Upgrades9/10Checks passed4 of 5Findings1 Low · 4 Info5
SummaryAI Copilot

This audit focuses on the provided Solidity source code snippets, which include OpenZeppelin's standard ReentrancyGuard and ERC20 implementations.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (86.9% total → 41.9% effective; 11.9% in EOAs, 75.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
75.0%Contracts11.9%Wallets13.1%Everyone else
75.0%Contracts11.9%13.1%
ContractsWalletsEveryone elseBubble area = share of supply
86.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking75.0%
  • Walletsanonymous holders, free to sell11.9%
  • Everyone elsethe rest of the supply13.1%
Effective concentrationwhat the score reads41.9%
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.17M across 7 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$2.17MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x63b5…bf240xd8a4…24c8

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

Security Findings

1 Low4 Info
Low

ERC20 Approval Race Condition

The standard approve() function in ERC20 tokens is susceptible to a known race condition. If a user approves an amount, and then attempts to change that approval to a different amount, an attacker observing the transaction might front-run the second approve() call. They could then spend the original allowance before the new allowance takes effect, and then spend the new allowance, effectively spending more than intended (7.2 Code Security, 7.4 Economic). OpenZeppelin mitigates this with increaseAllowance and decreaseAllowance, but the base approve function still carries this risk.L-01

Issue

The standard approve() function in ERC20 tokens is susceptible to a known race condition. If a user approves an amount, and then attempts to change that approval to a different amount, an attacker observing the transaction might front-run the second approve() call. They could then spend the original allowance before the new allowance takes effect, and then spend the new allowance, effectively spending more than intended (7.2 Code Security, 7.4 Economic). OpenZeppelin mitigates this with increaseAllowance and decreaseAllowance, but the base approve function still carries this risk.

Fix

Advise users to use increaseAllowance() and decreaseAllowance() functions instead of directly calling approve() when modifying an existing allowance. If approve() must be used, recommend setting the allowance to zero first, then to the desired new value.

Status

Unresolved

Info

Reliance on Well-Audited OpenZeppelin Libraries

The provided contract code utilizes standard and extensively audited OpenZeppelin libraries for ReentrancyGuard and ERC20 functionality. These libraries are industry-standard and have a strong track record of security, significantly reducing the risk of vulnerabilities in these core components (7.2 Code Security).I-01

Issue

The provided contract code utilizes standard and extensively audited OpenZeppelin libraries for ReentrancyGuard and ERC20 functionality. These libraries are industry-standard and have a strong track record of security, significantly reducing the risk of vulnerabilities in these core components (7.2 Code Security).

Fix

Continue to leverage well-maintained and audited libraries. Ensure that any custom logic built upon these libraries is also thoroughly reviewed and tested to maintain the overall security posture.

Status

Unresolved

Info

Adherence to ERC20 Standard

The ERC20 contract implementation adheres to the official ERC20 token standard (EIP-20), including required functions like totalSupply, balanceOf, transfer, transferFrom, approve, and associated events. This ensures compatibility with a wide range of wallets, exchanges, and DeFi protocols (7.1 Architecture).I-02

Issue

The ERC20 contract implementation adheres to the official ERC20 token standard (EIP-20), including required functions like totalSupply, balanceOf, transfer, transferFrom, approve, and associated events. This ensures compatibility with a wide range of wallets, exchanges, and DeFi protocols (7.1 Architecture).

Fix

Maintain strict adherence to the ERC20 standard in any further modifications or extensions to ensure continued interoperability and predictable behavior.

Status

Unresolved

Info

Robust Reentrancy Protection

The ReentrancyGuard contract provides a robust and widely accepted mechanism to prevent reentrancy attacks. The nonReentrant modifier ensures that a function cannot be called again before its previous execution has completed, effectively mitigating a common class of critical vulnerabilities (7.2 Code Security).I-03

Issue

The ReentrancyGuard contract provides a robust and widely accepted mechanism to prevent reentrancy attacks. The nonReentrant modifier ensures that a function cannot be called again before its previous execution has completed, effectively mitigating a common class of critical vulnerabilities (7.2 Code Security).

Fix

Ensure that any functions in the TaggerToken contract that perform external calls or transfer assets are appropriately protected with the nonReentrant modifier, if applicable.

Status

Unresolved

Info

Incomplete Contract Code Provided for Audit

The audit was conducted on partial source code, specifically OpenZeppelin's ReentrancyGuard and ERC20 base contracts. The full implementation of the TaggerToken contract, which would contain specific business logic, state variables, and interactions, was not provided. This limits the scope of the audit to the foundational components only (7.1 Architecture, 7.2 Code Security).I-04

Issue

The audit was conducted on partial source code, specifically OpenZeppelin's ReentrancyGuard and ERC20 base contracts. The full implementation of the TaggerToken contract, which would contain specific business logic, state variables, and interactions, was not provided. This limits the scope of the audit to the foundational components only (7.1 Architecture, 7.2 Code Security).

Fix

For a comprehensive security assessment, the complete and final source code of the TaggerToken contract, including all inherited contracts and custom logic, must be provided for a full audit.

Status

Unresolved

Analysis

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

This audit focuses on the provided Solidity source code snippets, which include OpenZeppelin's standard ReentrancyGuard and ERC20 implementations. These components are widely used and have undergone extensive community review and audits, demonstrating high security standards. However, the specific implementation code for the TaggerToken contract, which would inherit from or utilize these components, was not provided. Therefore, this report assesses the security of the provided base components and highlights the limitations due to the absence of the full contract logic.

Technical10/10Low risk

The technical architecture relies on well-established and thoroughly audited OpenZeppelin libraries for ERC20 token functionality and reentrancy protection (7.1 Architecture, 7.2 Code Security). The ERC20 contract adheres to the standard, ensuring predictable behavior and broad compatibility. The ReentrancyGuard module provides a robust and proven mechanism to prevent reentrant calls, enhancing the security of functions that interact with external contracts. Without the full TaggerToken contract code, specific implementation-level vulnerabilities cannot be assessed, but the foundational components are strong.

Governance6/10Medium risk

The provided ReentrancyGuard and ERC20 contracts are foundational components and do not inherently contain governance or complex economic logic (7.4 Economic, 7.5 Governance). Therefore, a direct assessment of governance and economic risks for these specific snippets is not applicable. Any such risks would stem from the specific implementation of the TaggerToken contract, which was not available for review. It is assumed that the TaggerToken contract would define its own economic model and governance mechanisms.

Upgrades9/10Low risk

The provided contract snippets are not designed as upgradeable proxies, and the prefill indicates is_proxy: false (7.7 Upgrades). Therefore, upgrade safety concerns for these specific components are not applicable. Any upgradeability considerations would depend on the TaggerToken contract's design and deployment strategy, which was not part of this audit's scope. If TaggerToken were to be upgradeable, a separate audit of its proxy implementation would be crucial.

Final RecommendationWhat to do about this score

It is highly recommended to ensure that the full TaggerToken contract, including any custom logic, inheritance, and external interactions, undergoes a comprehensive security audit.

While the foundational OpenZeppelin components are secure, vulnerabilities often arise in the integration of these components or in custom business logic. Implement robust testing, including unit, integration, and fuzz testing, for the entire system. Pay close attention to access control mechanisms, potential for economic manipulation, and any external dependencies within the TaggerToken implementation.

Contract & Record

2 audits on record
TypeTaggerToken
NetworkBNB Chain
Token age1y
Contract0x208b…2025
Deployer0xe096…f603
Badge for your website
Tagger 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. Jul 27, 20265Low
  2. Jul 24, 202664Medium

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

Frequently Asked Questions

Is Tagger a scam?

Based on automated analysis, Tagger scores 64/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Tagger safe to buy?

Our scanner flagged a risk score of 64/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Tagger been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
Smart Solve TokenSST · BNB Chain5LowMarscoinMARS · BNB Chain4LowosbookBNB Chain4LowBanana For ScaleBANANAS31 · BNB Chain7LowMame InuMAME · BNB Chain7LowUpscreenerUPS · BNB Chain3Low

Would You Like a More Detailed Audit of Tagger?

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