Quantum Audit Logo
Launch App

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

Is TAOT Safe?

Base
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
Technical8/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

The TAOT Token contract implements a standard ERC20 token leveraging OpenZeppelin's battle-tested libraries for token functionality and access control.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 70%
  • 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 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (76.4% total → 73.6% effective; 71.7% in EOAs, 4.7% in contracts — extreme)
  • 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, pool = 82% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 82% of DEX liquidity)
  • 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
4.7%71.7%Wallets23.6%Everyone else
4.7%71.7%Wallets23.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
76.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking4.7%
  • Walletsanonymous holders, free to sell71.7%
  • Everyone elsethe rest of the supply23.6%
Effective concentrationwhat the score reads73.6%
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$355.7K across 2 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$292.1KShare of depth82.1%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x3662…ba86

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

Security Findings

1 Medium1 Low2 Info
Medium

Centralization Risk via AccessControl

The contract utilizes OpenZeppelin's AccessControl, which assigns significant power to the DEFAULT_ADMIN_ROLE. This role, typically held by a single address or a multisig, can grant or revoke other roles, and if _mint or _burn functions are exposed with onlyRole modifiers, it can control the token's total supply. This centralization introduces a single point of failure, where compromise of the admin key could lead to severe consequences for the token's integrity and value (7.3 Access Control, 7.4 Economic, 7.5 Governance).M-01

Issue

The contract utilizes OpenZeppelin's AccessControl, which assigns significant power to the DEFAULT_ADMIN_ROLE. This role, typically held by a single address or a multisig, can grant or revoke other roles, and if _mint or _burn functions are exposed with onlyRole modifiers, it can control the token's total supply. This centralization introduces a single point of failure, where compromise of the admin key could lead to severe consequences for the token's integrity and value (7.3 Access Control, 7.4 Economic, 7.5 Governance).

Fix

Implement robust security practices for the DEFAULT_ADMIN_ROLE key, such as using a hardware wallet or a well-secured multisig. Consider decentralizing control over time by transferring administrative roles to a DAO or a more distributed set of entities. Clearly document the responsibilities and powers associated with each role.

Status

Unresolved

Low

Potential _totalSupply Underflow in _burn (Unchecked Arithmetic)

In the _update function, when to == address(0) (representing a burn operation), the _totalSupply -= value operation is performed within an unchecked block. While the _balances[from] check ensures the sender has sufficient tokens, there is no explicit check that _totalSupply is greater than or equal to value before decrementing _totalSupply. Although OpenZeppelin's ERC20 design generally ensures _totalSupply remains consistent with the sum of balances, a desynchronization could theoretically lead to an underflow (7.2 Code Security).L-01

Issue

In the _update function, when to == address(0) (representing a burn operation), the _totalSupply -= value operation is performed within an unchecked block. While the _balances[from] check ensures the sender has sufficient tokens, there is no explicit check that _totalSupply is greater than or equal to value before decrementing _totalSupply. Although OpenZeppelin's ERC20 design generally ensures _totalSupply remains consistent with the sum of balances, a desynchronization could theoretically lead to an underflow (7.2 Code Security).

Fix

While highly unlikely to be exploitable in a standard OpenZeppelin setup, for maximum robustness, consider adding an explicit require(_totalSupply >= value, 'ERC20InsufficientTotalSupply'); check before the unchecked block for _totalSupply -= value in the _update function when to == address(0).

Status

Unresolved

Info

Incomplete Source Code Provided

The provided Solidity source code is truncated, specifically within the AccessControl contract definition. This prevents a complete and thorough audit of all functionalities, especially any custom logic or full implementation details of the access control mechanisms (7.1 Architecture, 7.2 Code Security).I-01

Issue

The provided Solidity source code is truncated, specifically within the AccessControl contract definition. This prevents a complete and thorough audit of all functionalities, especially any custom logic or full implementation details of the access control mechanisms (7.1 Architecture, 7.2 Code Security).

Fix

Provide the complete and verified source code for all contracts to enable a comprehensive security assessment. Ensure that the deployed bytecode matches the provided source code exactly.

Status

Unresolved

Info

ERC20 Standard Limitations (Front-Running on approve)

The ERC20 approve function is susceptible to a known front-running vulnerability. If a user increases an allowance from X to Y, a malicious actor could front-run this transaction, spend the original X allowance, and then the user's transaction would set the allowance to Y, effectively allowing the malicious actor to spend X+Y. While OpenZeppelin's _spendAllowance mitigates some risks by checking currentAllowance < value, the core approve pattern remains vulnerable to this specific sequence (7.2 Code Security, 7.4 Economic).I-02

Issue

The ERC20 approve function is susceptible to a known front-running vulnerability. If a user increases an allowance from X to Y, a malicious actor could front-run this transaction, spend the original X allowance, and then the user's transaction would set the allowance to Y, effectively allowing the malicious actor to spend X+Y. While OpenZeppelin's _spendAllowance mitigates some risks by checking currentAllowance < value, the core approve pattern remains vulnerable to this specific sequence (7.2 Code Security, 7.4 Economic).

Fix

Users should be advised to set allowances to zero before increasing them, or to use increaseAllowance/decreaseAllowance functions if available in a derived contract. Developers should be aware of this limitation when designing systems that rely on ERC20 allowances.

Status

Unresolved

Analysis

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

The TAOT Token contract implements a standard ERC20 token leveraging OpenZeppelin's battle-tested libraries for token functionality and access control. The code demonstrates good practices such as custom error handling and careful use of unchecked arithmetic. However, the provided source code is incomplete, which limits the scope of a full security assessment. The AccessControl pattern introduces centralization, and a theoretical underflow risk in _totalSupply during burning was identified.

Technical8/10Low risk

The contract implements a standard ERC20 token using OpenZeppelin's robust patterns, including custom error handling (7.2 Code Security). It correctly utilizes unchecked blocks for arithmetic operations after necessary checks, minimizing overflow/underflow risks in balance updates. However, the _totalSupply decrement in _update for burning lacks an an explicit check for _totalSupply >= value before the unchecked block, presenting a theoretical, albeit low-probability, underflow risk (7.2 Code Security). The provided code is also truncated, limiting a full technical assessment (7.1 Architecture).

Governance1/10High risk

The contract incorporates OpenZeppelin's AccessControl, providing a structured permission system for administrative functions (7.3 Access Control). The DEFAULT_ADMIN_ROLE is established, allowing for controlled management of sensitive operations like potential minting or burning functions if exposed (7.5 Governance). However, this design introduces a degree of centralization, as the holder(s) of the DEFAULT_ADMIN_ROLE possess significant control over the token's supply and parameters, which could pose a single point of failure or trust risk (7.4 Economic).

Upgrades6/10Medium risk

The contract is deployed as a standard, non-proxy implementation, meaning it is not inherently upgradeable (7.7 Upgrades). This simplifies the architecture by removing upgrade-related complexities and risks, such as storage collisions or logic errors during an upgrade. However, any future modifications to the token's logic would require a new deployment and migration of assets, which can be a complex and costly process.

Final RecommendationWhat to do about this score

It is recommended to complete the provided source code to allow for a comprehensive security review of all contract functionalities, especially any custom logic or role-protected functions.

Project teams should carefully consider the implications of centralized control granted by the AccessControl pattern and implement robust operational security measures for managing administrative roles. Ensure that all external interactions and dependencies are thoroughly vetted.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1mo
Contract0x7f2f…ff3e
Deployer0x1fe8…08f0
Badge for your website
TAOT 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. Sep 4, 202653Medium
  2. Aug 11, 202646Medium

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

Related Audits

6 more on the recordAll audits
AUTONOMOPOLYAUTONO · Base53MediumSolanaSOL · Base53MediumCheckmateCHECK · Base53MediumSoSoValueSOSO · Base53MediumSallyA1C · Base53MediumOFCBase53Medium

Would You Like a More Detailed Audit of TAOT?

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