Quantum Audit Logo

Is TAOT Safe?

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

TAOT TAOT
0x7f2f…ff3e
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Medium1 Low2 Informational
Volume 24h
$16.5K
Liquidity
$292.1K
Price
$0.2884
Token Age
1mo
Top 10 Holders
76.4%

Security Findings

1 Med1 Low2 Info
Medium

Centralization Risk via AccessControl

M-01The 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).
IssueThe 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).
FixImplement 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.
StatusUnresolved
Low

Potential `_totalSupply` Underflow in `_burn` (Unchecked Arithmetic)

L-01In 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).
IssueIn 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).
FixWhile 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)`.
StatusUnresolved
Info

Incomplete Source Code Provided

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

ERC20 Standard Limitations (Front-Running on `approve`)

I-02The 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).
IssueThe 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).
FixUsers 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh1/10

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

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

76.4% in top 10
71.7% in wallets4.7% in contracts
Effective Concentration73.6%

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

$355.7K across 2 pairs
AerodromeUSDCanalysed$292.1K82.1%AerodromeUSDC$63.6K17.9%

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

2 addresses
Deployer
0x1fe8…08f0
Unlocked LP Held By
0x3662…ba86

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

What Raised This Score

7 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

Related Audits

6 more on the record
AUTONOMOPOLY (AUTONO)High RiskSolana (SOL)High RiskCheckmate (CHECK)High RiskSoSoValue (SOSO)High RiskSally (A1C)High RiskHOMEHigh Risk

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