Quantum Audit Logo

Is Tether Gold Safe?

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

Is this your token? Publish your own audit on this page →

Tether Gold XAUT
0x6874…2f38
Ethereum Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Low3 Informational
Volume 24h
$3.74M
Liquidity
$6.15M
Price
$4462.2600
Token Age
9mo
Top 10 Holders
54.4%

Security Findings

1 High1 Low3 Info
High

Centralized Control over Token Supply and User Funds

H-01The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Low

Centralized Upgradeability Control

L-01The 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.
IssueThe 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.
FixWhile 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.
StatusUnresolved
Info

Unused `isTrusted` Variable

I-01The `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.'
IssueThe `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.'
FixThis 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.
StatusResolved
Info

Reliance on External OpenZeppelin Libraries

I-02The contract heavily relies on OpenZeppelin Contracts Upgradeable for core functionalities like ERC-20, Ownable, and Initializable patterns.
IssueThe contract heavily relies on OpenZeppelin Contracts Upgradeable for core functionalities like ERC-20, Ownable, and Initializable patterns.
FixOpenZeppelin 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.
StatusResolved
Info

Blocked List Functionality and Scope

I-03The `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…
IssueThe `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…
FixDocument 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.
StatusResolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceMedium4/10

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.

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

54.4% in top 10
48.0% in wallets6.4% in contracts
Effective Concentration50.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

$21.55M across 26 pairs
Uniswap v3PAXGanalysed$6.15M28.6%Uniswap v4USDC$3.60M16.7%Uniswap v3PAXG$3.52M16.3%Uniswap v4USDT$2.68M12.4%Uniswap v3USDT$2.40M11.1%Uniswap v3WBTC$1.01M4.7%
Show 4 more pairsShow less
Uniswap v4WBTC$581.2K2.7%Uniswap v4ETH$525.8K2.4%Uniswap v3USDT$295.7K1.4%Uniswap v3USDC$276.0K1.3%

The 16 remaining pairs hold $509.1K 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.

LP Distribution

Top-1 Unlocked Holder9.3%
Top-3 Unlocked23.4%

Key Addresses

11 addresses
Deployer
0x341a…07ff
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.

What Raised This Score

8 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

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 record
Matrix (MTX)High RiskAnimecoin (ANIME)High RiskCentrifuge (CFG)High RiskToken Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskPrismHigh Risk

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