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
0x21ca…a3bf
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit covers the TetherTokenV2 contract, an upgradeable ERC20 token with EIP-3009 authorization and a blocked list feature. The contract utilizes OpenZeppelin's upgradeable patterns and access control. Key findings include significant centralized control by the owner (a multisig), potential gas limit issues for batch transfers, and an incomplete `_permit` function in the provided source. The upgradeability mechanism is standard and well-implemented.

1 Critical1 High2 Medium1 Low1 Informational
Volume 24h
$4.59M
Liquidity
$1.63M
Price
$4461.7600
Token Age
4mo
Top 10 Holders
92.9%

Security Findings

1 Crit1 High2 Med1 Low1 Info
Critical

Centralized Control and Owner Privileges

C-01The contract owner (a 3/5 multisig) possesses extensive centralized control over the token supply and user funds. The owner can `mint` new tokens, `redeem` (burn) tokens from their own balance, `block` any address, and `destroyBlockedFunds` from blocked users. This level of control allows the owner to arbitrarily increase/decrease token supply and confiscate user assets, representing a significant economic and governance risk (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe contract owner (a 3/5 multisig) possesses extensive centralized control over the token supply and user funds. The owner can `mint` new tokens, `redeem` (burn) tokens from their own balance, `block` any address, and `destroyBlockedFunds` from blocked users. This level of control allows the owner to arbitrarily increase/decrease token supply and confiscate user assets, representing a significant economic and governance risk (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixClearly communicate the extent of owner privileges to all users and stakeholders. Consider implementing time-locks or community governance for critical functions like minting, burning, or fund destruction to decentralize control over time. Ensure robust operational security for the multisig wallet controlling the owner address.
StatusUnresolved
High

Potential Gas Limit Exceeded in `multiTransfer`

H-01The `multiTransfer` function iterates through arrays of recipients and values to perform multiple `transfer` calls. If the `_recipients` and `_values` arrays are excessively large, the transaction could exceed the block gas limit, causing the transaction to fail or become unusable for large batch operations (7.2 Code Security).
IssueThe `multiTransfer` function iterates through arrays of recipients and values to perform multiple `transfer` calls. If the `_recipients` and `_values` arrays are excessively large, the transaction could exceed the block gas limit, causing the transaction to fail or become unusable for large batch operations (7.2 Code Security).
FixImplement a mechanism to limit the number of transfers per transaction, or provide a way to process transfers in smaller batches. Alternatively, consider using a more gas-efficient batch transfer pattern if large-scale operations are a primary use case.
StatusUnresolved
Medium

Truncated `_permit` Function Source Code

M-01The provided source code for the `_permit` function in `TetherTokenV2.sol` is truncated. This prevents a complete security analysis of the ERC20 Permit functionality, which is critical for gasless transactions and involves signature verification (7.2 Code Security).
IssueThe provided source code for the `_permit` function in `TetherTokenV2.sol` is truncated. This prevents a complete security analysis of the ERC20 Permit functionality, which is critical for gasless transactions and involves signature verification (7.2 Code Security).
FixProvide the complete and verified source code for the `_permit` function to allow for a thorough security audit of its implementation, especially regarding signature validation, nonce management, and deadline checks.
StatusUnresolved
Medium

Owner Bypass for Blocked `from` Address in `_beforeTokenTransfer`

M-02The `_beforeTokenTransfer` hook contains a condition `require(!isBlocked[from] || msg.sender == owner(), 'TetherToken: from is blocked');`. This allows the contract owner to bypass the blocked list check and transfer tokens *from* a blocked address. While consistent with the `destroyBlockedFunds` functionality, this grants the owner additional power to move funds from blocked accounts without explicitly burning them, which might not be immediately obvious to users (7.3 Access Control).
IssueThe `_beforeTokenTransfer` hook contains a condition `require(!isBlocked[from] || msg.sender == owner(), 'TetherToken: from is blocked');`. This allows the contract owner to bypass the blocked list check and transfer tokens *from* a blocked address. While consistent with the `destroyBlockedFunds` functionality, this grants the owner additional power to move funds from blocked accounts without explicitly burning them, which might not be immediately obvious to users (7.3 Access Control).
FixClearly document this specific owner capability in user-facing materials and internal documentation. Ensure that the implications of this bypass are fully understood by all stakeholders, as it provides a mechanism for the owner to reallocate funds from blocked users.
StatusUnresolved
Low

Mixed Solidity Pragma Directives

L-01The `EIP3009.sol` file uses `pragma solidity >=0.6.12 <0.9.0;`, while `TetherToken.sol` and `TetherTokenV2.sol` use `pragma solidity 0.8.4;`. Although `0.8.4` falls within the specified range, using consistent and explicit pragma directives across all files is a best practice for clarity and to prevent unexpected compiler behavior with future versions (7.2 Code Security).
IssueThe `EIP3009.sol` file uses `pragma solidity >=0.6.12 <0.9.0;`, while `TetherToken.sol` and `TetherTokenV2.sol` use `pragma solidity 0.8.4;`. Although `0.8.4` falls within the specified range, using consistent and explicit pragma directives across all files is a best practice for clarity and to prevent unexpected compiler behavior with future versions (7.2 Code Security).
FixUnify the pragma directives to `pragma solidity 0.8.4;` across all contract files for consistency and to explicitly state the intended compiler version.
StatusUnresolved
Info

Unused `isTrusted` Mapping

I-01The `isTrusted` mapping is declared in `TetherToken.sol` but is not used anywhere in the provided contract code. This variable consumes storage space without serving any functional purpose (7.2 Code Security).
IssueThe `isTrusted` mapping is declared in `TetherToken.sol` but is not used anywhere in the provided contract code. This variable consumes storage space without serving any functional purpose (7.2 Code Security).
FixRemove the `isTrusted` mapping if it is not intended for future use, or implement its intended functionality. If it's a placeholder for future features, consider adding a comment to explain its purpose.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract leverages OpenZeppelin's upgradeable ERC20, Ownable, and Permit standards, enhancing code security and maintainability (7.2 Code Security). It implements EIP-3009 for signature-based transfers, which includes robust nonce and time-based validity checks to prevent replay attacks. However, the `multiTransfer` function could face gas limit issues with very large arrays, potentially hindering batch operations (7.2 Code Security). Additionally, the provided source code for the `_permit` function is truncated, preventing a full security assessment of this critical functionality (7.2 Code Security). Access control is managed via `OwnableUpgradeable`, with the owner having broad powers (7.3 Access Control).

GovernanceHigh1/10

The contract exhibits a high degree of centralization, with the owner (a 3/5 multisig) possessing extensive control over the token's economic parameters and user funds (7.4 Economic, 7.5 Governance). The owner can mint new tokens, redeem (burn) tokens from the owner's balance, block user addresses, and destroy funds held by blocked users. Specifically, the `destroyBlockedFunds` function allows the owner to confiscate tokens from blocked accounts, and the `_beforeTokenTransfer` hook allows the owner to transfer funds from a blocked address (7.4 Economic). While the use of a multisig for ownership mitigates single-point-of-failure, it does not diminish the inherent centralized power over the token supply and user assets.

UpgradesHigh1/10

The contract utilizes the TransparentUpgradeableProxy pattern from OpenZeppelin, a well-established and secure upgrade mechanism (7.7 Upgrades). The implementation contract correctly inherits from `Initializable` and includes `__gap` storage variables to prevent storage collisions in future upgrades. The proxy's admin is a multisig, adding an extra layer of security to the upgrade process (7.7 Upgrades). This setup ensures that future upgrades can be performed safely and with appropriate governance oversight.

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 → Multisig 3-of-5
ImplementationVerified source

Holder Composition

92.9% in top 10
83.8% in wallets9.0% in contracts
Effective Concentration87.5%

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

$3.55M across 16 pairs
Pancakeswap v3USDTanalysed$1.63M45.9%Pancakeswap v3WBNB$864.3K24.4%Pancakeswap v3USDT$860.4K24.2%Pancakeswap v3BTCB$139.2K3.9%Pancakeswap v2WBNB$38.9K1.1%Uniswap比特币$6.6K0.2%
Show 4 more pairsShow less
Pancakeswap v3USDT$2.6K0.1%UniswapWBNB$1.6K0.0%UniswapUSDT$1.5K0.0%Pancakeswap v3WBNB$1.5K0.0%

The 6 remaining pairs hold $2.3K 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 Holder44.1%
Top-3 Unlocked88.5%

Key Addresses

11 addresses
Deployer
0x1a63…d154
Unlocked LP Held By
0x9c16…4a6f0xfb87…c8740x4b18…c8db0xc13c…4b040x157a…fa210x188d…191b0x8f76…e5d90x4753…0e5b0xcaa7…c7ff0xe463…e6b9

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

What Raised This Score

10 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (92.9% total → 87.5% effective; 83.8% in EOAs, 9.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 88.5% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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
WIKI CAT (WKC)Critical RiskBlock Street (BSB)Critical RiskInvesqo QQQ (QQQB)Critical RiskLIGHTCritical RiskDexeCritical RiskArcium (ARX)Critical 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