Quantum Audit Logo

Is Tether USD Safe?

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

Tether USD USDT
0xfde4…9bb2
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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`. 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.

1 High1 Medium1 Low1 Informational
Volume 24h
$324.4K
Liquidity
$192.6K
Price
$0.999
Token Age
1y
Top 10 Holders
25.5%

Security Findings

1 High1 Med1 Low1 Info
High

Extensive Centralized Control

H-01The `_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).
IssueThe `_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).
FixImplement 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.
StatusUnresolved
Medium

ERC-20 `approve` Race Condition

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

Immutability of Core Token Parameters

L-01The 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).
IssueThe 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).
FixEnsure thorough verification of all constructor parameters, especially token name, symbol, and decimals, before deployment to prevent irreversible misconfigurations.
StatusUnresolved
Info

Use of OpenZeppelin Contracts v3.4.1

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

Category Ratings

TechnicalLow7/10

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.

GovernanceHigh2/10

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.

UpgradesHigh2/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

25.5% in top 10
17.9% in wallets7.7% in contracts
Effective Concentration20.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

$1.01M across 30 pairs
Uniswap v3USDCanalysed$192.6K19.1%Uniswap v3WETH$142.8K14.2%Uniswap v4USDC$135.9K13.5%Quickswap v4USDC$132.8K13.2%Uniswap v4USDC$103.1K10.2%Quickswap v4USDbC$80.9K8.0%
Show 4 more pairsShow less
PancakeswapEURC$65.5K6.5%PancakeswapUSDC$60.5K6.0%Uniswap v3WETH$28.8K2.9%SolidlycomUSDC$12.9K1.3%

The 20 remaining pairs hold $53.0K between them and are not listed.

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.

Key Addresses

1 addresses
Deployer
0x0859…8b89

What Raised This Score

7 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)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 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

Related Audits

6 more on the record
Morpho Token (MORPHO)High RiskevoHigh RiskBIOHigh RiskHydrex (HYDX)High RiskAavegotchi GHST Token (GHST)High RiskFree Bots (BOTS)High Risk

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