Quantum Audit Logo
Launch App

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

Is Tether Gold Safe?

XAUTEthereum
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance4/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Low · 3 Info5
SummaryAI Copilot

The TetherToken contract implements an upgradeable ERC-20 token with a centralized ownership model, including minting, burning, and a blocked list functionality.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • OZ ProxyAdmin -> Admin is unclassified contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • OZ ProxyAdmin -> Admin is unclassified contract
  • Top-10 concentration > 50% (54.4% total → 50.6% effective; 48.0% in EOAs, 6.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
6.4%Contracts48.0%Wallets45.6%Everyone else
6.4%48.0%Wallets45.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
54.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.4%
  • Walletsanonymous holders, free to sell48.0%
  • Everyone elsethe rest of the supply45.6%
Effective concentrationwhat the score reads50.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$21.55M across 26 pairs
Show 4 more pairs

The 16 remaining pairs hold $509.1K between them and are not listed. 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$6.15MShare of depth28.6%
Top-1 Unlocked Holder9.3%
Top-3 Unlocked23.4%
Unlocked LP held by
0x842b…f03b0x1034…86970xabb8…99af0xc85b…0f930x7345…45920x31ed…a7660xcae2…6c1b0x766f…c7870x98fd…e6930xfeb6…22d5

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

Security Findings

1 High1 Low3 Info
High

Centralized Control over Token Supply and User Funds

The TetherToken contract grants the owner address extensive control over the token supply and user funds. The mint function allows the owner to create new tokens, and the redeem function allows the owner to burn tokens from their own balance. More critically, the destroyBlockedFunds function enables the owner to burn the entire balance of any address on the blocked list. This level of centralization introduces significant counterparty risk, as a compromised or malicious owner could manipulate the supply or seize user assets.H-01

Issue

The TetherToken contract grants the owner address extensive control over the token supply and user funds. The mint function allows the owner to create new tokens, and the redeem function allows the owner to burn tokens from their own balance. More critically, the destroyBlockedFunds function enables the owner to burn the entire balance of any address on the blocked list. This level of centralization introduces significant counterparty risk, as a compromised or malicious owner could manipulate the supply or seize user assets.

Fix

While this centralization is an inherent design choice for stablecoins like USDT, it's crucial that the owner key management is robust. Consider implementing a multi-signature wallet or a time-locked governance mechanism for critical functions like mint, redeem, addToBlockedList, removeFromBlockedList, and destroyBlockedFunds to mitigate the risk of a single point of failure.

Status

Unresolved

Low

Centralized Upgradeability Control

The contract uses a TransparentUpgradeableProxy pattern with an OpenZeppelin ProxyAdmin. The owner of the TetherToken contract (via OwnableUpgradeable) is the same address (0xc6cd…a828) that controls the ProxyAdmin, which is responsible for upgrading the implementation contract. This means a single entity has full control over both the operational logic and the upgradeability of the token.L-01

Issue

The contract uses a TransparentUpgradeableProxy pattern with an OpenZeppelin ProxyAdmin. The owner of the TetherToken contract (via OwnableUpgradeable) is the same address () that controls the ProxyAdmin, which is responsible for upgrading the implementation contract. This means a single entity has full control over both the operational logic and the upgradeability of the token.

Fix

While this is a common setup, for high-value or critical infrastructure contracts, it is recommended to separate the upgradeability control from the operational control. This could involve using a different multisig or a more decentralized governance mechanism for the ProxyAdmin owner.

Status

Unresolved

Info

Unused isTrusted Variable

The isTrusted mapping is declared but not used anywhere in the TetherToken contract logic. The comment explicitly states it is 'retained to preserve storage slots across upgrades.'I-01

Issue

The isTrusted mapping is declared but not used anywhere in the TetherToken contract logic. The comment explicitly states it is 'retained to preserve storage slots across upgrades.'

Fix

This is a good practice for upgradeable contracts to prevent storage collisions in future upgrades. No action is required, but ensure clear documentation of such design decisions.

Status

Resolved

Info

Reliance on External OpenZeppelin Libraries

The contract heavily relies on OpenZeppelin Contracts Upgradeable for core functionalities like ERC-20, Ownable, and Initializable patterns.I-02

Issue

The contract heavily relies on OpenZeppelin Contracts Upgradeable for core functionalities like ERC-20, Ownable, and Initializable patterns.

Fix

OpenZeppelin libraries are widely audited and considered industry-standard. Ensure that the specific versions used (0.8.4 compatible versions) are free from known vulnerabilities. Regular monitoring of OpenZeppelin security advisories is recommended.

Status

Resolved

Info

Blocked List Functionality and Scope

The WithBlockedList contract and its integration into TetherToken implement a mechanism to block specific addresses. The onlyNotBlocked modifier prevents blocked addresses from initiating transfer, transferFrom, and multiTransfer operations. Additionally, transferFrom explicitly prevents transfers from a blocked _sender. However, the design allows tokens to be transferred *to* a blocked address by an unblocked sender. The owner also has the ability to destroyBlockedFunds from any blocked address. This design implies the blocked list primarily restricts outbound transactions from blocked users and allows for asset seizure, rather than completely isolating blocked accounts f…I-03

Issue

The WithBlockedList contract and its integration into TetherToken implement a mechanism to block specific addresses. The onlyNotBlocked modifier prevents blocked addresses from initiating transfer, transferFrom, and multiTransfer operations. Additionally, transferFrom explicitly prevents transfers from a blocked _sender. However, the design allows tokens to be transferred *to* a blocked address by an unblocked sender. The owner also has the ability to destroyBlockedFunds from any blocked address. This design implies the blocked list primarily restricts outbound transactions from blocked users and allows for asset seizure, rather than completely isolating blocked accounts f…

Fix

Document this specific behavior clearly for users and integrators, especially regarding the ability to send funds *to* blocked addresses and the owner's power to destroy them. This ensures transparency about the system's censorship capabilities.

Status

Resolved

Analysis

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

The TetherToken contract implements an upgradeable ERC-20 token with a centralized ownership model, including minting, burning, and a blocked list functionality. The contract utilizes well-audited OpenZeppelin Upgradeable libraries for its core functionalities and upgradeability. While the technical implementation is robust, the high degree of centralization in control over token supply, user funds, and contract upgrades introduces significant governance and economic risks inherent to its design as a stablecoin.

Technical6/10Medium risk

The technical implementation of the TetherToken contract demonstrates good practices, leveraging battle-tested OpenZeppelin Upgradeable libraries for ERC-20, Ownable, and Initializable patterns (7.2 Code Security, 7.1 Architecture). Defensive checks, such as preventing transfers to the contract address, are appropriately implemented in transfer and transferFrom. The blocked list mechanism consistently prevents blocked users from initiating transfers, and the multiTransfer function is implemented securely. No reentrancy, integer overflow/underflow, or other common EVM vulnerabilities were identified.

Governance4/10Medium risk

The contract exhibits a high degree of centralization, with a single owner controlling critical functions (7.3 Access Control, 7.5 Governance). The owner has the sole ability to mint new tokens, redeem (burn) tokens from their own balance, and crucially, destroyBlockedFunds from any blocked user's account (7.4 Economic). This centralized control over token supply and user assets introduces significant counterparty risk, as a compromised or malicious owner could manipulate the token supply or seize funds. While this model is typical for stablecoins like USDT, it represents a substantial economic risk for users.

Upgrades1/10High risk

The contract is designed for upgradeability using the TransparentUpgradeableProxy pattern with an OpenZeppelin ProxyAdmin (7.7 Upgrades). The implementation correctly uses Initializable and __gap storage padding to prevent storage collisions during upgrades. The explicit retention of the isTrusted variable for storage slot preservation demonstrates awareness of upgradeability best practices. The upgrade mechanism itself is standard and technically sound, though control over upgrades is centralized under the same owner as the token's operational functions.

Final RecommendationWhat to do about this score

To enhance the security posture, consider implementing a multi-signature wallet or a time-locked governance mechanism for the owner address, especially for critical functions such as minting, burning, and managing the blocked list.

This would distribute control and introduce a delay for sensitive operations, mitigating the risk associated with a single point of failure. Additionally, ensure comprehensive documentation is available to users and integrators, clearly outlining the capabilities and limitations of the blocked list functionality and the owner's powers.

Contract & Record

2 audits on record
TypeTransparentUpgradeableProxy
NetworkEthereum
Token age9mo
Contract0x6874…2f38
Deployer0x341a…07ff
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Other-Contract
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Tether Gold 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 27, 202658Medium
  2. Jul 27, 202665High

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

Frequently Asked Questions

Is Tether Gold a scam?

Based on automated analysis, Tether Gold scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Tether Gold safe to buy?

Our scanner flagged a risk score of 65/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Tether Gold been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
MatrixMTX · Ethereum58MediumAnimecoinANIME · Ethereum58MediumCentrifugeCFG · Ethereum58MediumChainflipFLIP · Ethereum58MediumAPI3Ethereum58MediumRova ProtocolROVA · Ethereum58Medium

Would You Like a More Detailed Audit of Tether Gold?

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