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.
On-chain security analysis — is it a scam or legit?
Is Tether USD Safe?
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 →The audited contract is an ERC-20 token implementation, leveraging OpenZeppelin Contracts v3.4.1 for standard functionalities like ERC20, Ownable, Pausable, and SafeMath.
- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking7.7%
- Walletsanonymous holders, free to sell17.9%
- Everyone elsethe rest of the supply74.5%
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- 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 pairs
The 20 remaining pairs hold $53.0K between them and are not listed. The risk score reads depth across every pair.
Whether the LP tokens are locked could not be determined.
Security Findings
HighExtensive 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
MediumERC-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
approve Race ConditionIssue
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
LowImmutability 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
InfoUse 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 4The 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.
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.
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Jul 23, 202658Medium
- 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