Quantum Audit Logo

Is Tagger Safe?

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

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

Tagger TAG
0x208b…2025
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 Low4 Informational
Volume 24h
$2.49M
Liquidity
$2.17M
Price
$0.0007189
Token Age
1y
Top 10 Holders
86.9%

Security Findings

1 Low4 Info
Low

ERC20 Approval Race Condition

L-01The 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.
IssueThe 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.
FixAdvise 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.
StatusUnresolved
Info

Reliance on Well-Audited OpenZeppelin Libraries

I-01The 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).
IssueThe 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).
FixContinue 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.
StatusUnresolved
Info

Adherence to ERC20 Standard

I-02The `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).
IssueThe `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).
FixMaintain strict adherence to the ERC20 standard in any further modifications or extensions to ensure continued interoperability and predictable behavior.
StatusUnresolved
Info

Robust Reentrancy Protection

I-03The `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).
IssueThe `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).
FixEnsure that any functions in the `TaggerToken` contract that perform external calls or transfer assets are appropriately protected with the `nonReentrant` modifier, if applicable.
StatusUnresolved
Info

Incomplete Contract Code Provided for Audit

I-04The 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).
IssueThe 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).
FixFor 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.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceMedium6/10

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.

UpgradesLow9/10

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.

Security Checklist

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

Holder Composition

86.9% in top 10
11.9% in wallets75.0% in contracts
Effective Concentration41.9%

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.17M across 7 pairs
Pancakeswap v3WBNBanalysed$2.17M100.0%Pancakeswap v3USD1$930.0%Pancakeswap v2WBNB$200.0%Pancakeswap v2TUT$170.0%Pancakeswap v2Subject 3$140.0%Pancakeswap v3USDT$00.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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xe096…f603
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.

What Raised This Score

5 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

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 record
Smart Solve Token (SST)Low RiskMarscoin (MARS)Low RiskBanana For Scale (BANANAS31)Low RiskBroccoliLow RiskPaluLow Risk哈基米Low Risk

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