Quantum Audit Logo
Launch App

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

Is Tether USD Safe?

USDTBase
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
SummaryAI Copilot

The audited contract is an ERC-20 token implementation, leveraging OpenZeppelin Contracts v3.4.1 for standard functionalities like ERC20, Ownable, Pausable, and SafeMath.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (25.5% total → 20.9% effective; 17.9% in EOAs, 7.7% in contracts — mild)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockUnknown
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
7.7%Contracts17.9%Wallets74.5%Everyone else
7.7%17.9%74.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
25.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking7.7%
  • Walletsanonymous holders, free to sell17.9%
  • Everyone elsethe rest of the supply74.5%
Effective concentrationwhat the score reads20.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$1.01M across 30 pairs
LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$192.6KShare of depth19.1%

Security Findings

1 High1 Medium1 Low1 Info
High

Extensive Centralized Control

The _owner possesses significant control, including the ability to mint and burn tokens, directly influencing the total supply and token value. Additionally, the _pauser can pause and unpause all core token operations (transfers, approvals, minting, burning), leading to potential denial of service for users. This design introduces high trust assumptions and a single point of failure (7.3 Access Control, 7.4 Economic, 7.8 Operations).H-01

Issue

The _owner possesses significant control, including the ability to mint and burn tokens, directly influencing the total supply and token value. Additionally, the _pauser can pause and unpause all core token operations (transfers, approvals, minting, burning), leading to potential denial of service for users. This design introduces high trust assumptions and a single point of failure (7.3 Access Control, 7.4 Economic, 7.8 Operations).

Fix

Implement a multi-signature wallet for the _owner and _pauser roles to distribute control and reduce the risk of a single point of compromise. Clearly communicate the extent of centralized control to users and stakeholders.

Status

Unresolved

Medium

ERC-20 approve Race Condition

The standard approve function is susceptible to a known front-running attack. If a user approves an amount, then approves a different amount without first setting the allowance to zero, a malicious actor could potentially spend both the old and new allowances. While increaseAllowance and decreaseAllowance are provided as safer alternatives, the direct approve function remains (7.2 Code Security).M-01

Issue

The standard approve function is susceptible to a known front-running attack. If a user approves an amount, then approves a different amount without first setting the allowance to zero, a malicious actor could potentially spend both the old and new allowances. While increaseAllowance and decreaseAllowance are provided as safer alternatives, the direct approve function remains (7.2 Code Security).

Fix

Educate users to primarily use increaseAllowance and decreaseAllowance instead of directly calling approve when modifying existing allowances. If approve must be used, advise users to first set the allowance to zero before setting a new value.

Status

Unresolved

Low

Immutability of Core Token Parameters

The token's name, symbol, and decimals are set during construction and cannot be modified post-deployment. While standard for ERC-20 tokens, this means any initial misconfiguration of these parameters would require a new contract deployment (7.1 Architecture).L-01

Issue

The token's name, symbol, and decimals are set during construction and cannot be modified post-deployment. While standard for ERC-20 tokens, this means any initial misconfiguration of these parameters would require a new contract deployment (7.1 Architecture).

Fix

Ensure thorough verification of all constructor parameters, especially token name, symbol, and decimals, before deployment to prevent irreversible misconfigurations.

Status

Unresolved

Info

Use of OpenZeppelin Contracts v3.4.1

The contract leverages well-audited OpenZeppelin libraries (Context, IERC20, SafeMath, ERC20, Ownable, Pausable) version 3.4.1. This significantly reduces the risk of common vulnerabilities by using battle-tested code, but means the contract inherits any potential, albeit unlikely, issues within these specific library versions (7.6 External).I-01

Issue

The contract leverages well-audited OpenZeppelin libraries (Context, IERC20, SafeMath, ERC20, Ownable, Pausable) version 3.4.1. This significantly reduces the risk of common vulnerabilities by using battle-tested code, but means the contract inherits any potential, albeit unlikely, issues within these specific library versions (7.6 External).

Fix

Regularly monitor OpenZeppelin security advisories for the specific versions used. Consider upgrading to newer, actively maintained versions of OpenZeppelin Contracts if feasible and beneficial for new deployments, as they often include further optimizations and security enhancements.

Status

Unresolved

Analysis

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

The audited contract is an ERC-20 token implementation, leveraging OpenZeppelin Contracts v3.4.1 for standard functionalities like ERC20, Ownable, Pausable, and SafeMath. The contract exhibits robust technical security due to the use of battle-tested libraries, including proper handling of integer overflows/underflows. However, it features a highly centralized control model, where an owner can mint, burn, and pause operations, which introduces significant governance and economic risks. The standard ERC-20 approve race condition is present, though mitigated by increaseAllowance and decreaseAllowance functions.

Technical7/10Low risk

The contract demonstrates good technical security (7.2 Code Security) by utilizing OpenZeppelin Contracts v3.4.1, which include SafeMath for all arithmetic operations, effectively preventing integer overflow/underflow vulnerabilities. The ERC-20 implementation is standard and adheres to best practices. However, the standard ERC-20 approve function (7.2 Code Security) still carries a known front-running risk, despite the provision of increaseAllowance and decreaseAllowance as safer alternatives.

Governance3/10High risk

The contract exhibits a high degree of centralization (7.3 Access Control, 7.4 Economic, 7.5 Governance). The _owner role has extensive privileges, including the ability to mint and burn tokens, directly impacting the total supply and economic stability. Additionally, the _pauser role can pause all token transfers and operations, introducing a single point of failure and potential for denial of service (7.8 Operations). This centralized control requires significant trust in the contract administrators.

Upgrades3/10High risk

The contract is not designed with an upgrade mechanism (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations or logic bugs introduced during upgrades. Any changes to the token's functionality would require a new deployment.

Final RecommendationWhat to do about this score

It is recommended to carefully manage the private keys associated with the _owner and _pauser roles due to their extensive control over the token's supply and operational status.

Consider implementing a multi-signature wallet for these critical roles to enhance security and decentralization. For users, it is advisable to prefer increaseAllowance and decreaseAllowance over the direct approve function to mitigate front-running risks.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0xfde4…9bb2
Deployer0x0859…8b89
Badge for your website
Tether USD 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 23, 202658Medium
  2. Jul 23, 202650Medium

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

Would You Like a More Detailed Audit of Tether USD?

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