Quantum Audit Logo
Launch App

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

Is Tether Gold Safe?

XAUTBNB Chain
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 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 2 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The audit covers the TetherTokenV2 contract, an upgradeable ERC20 token with EIP-3009 authorization and a blocked list feature.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 88.5%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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
9.0%Contracts83.8%Wallets7.1%
9.0%83.8%Wallets7.1%
ContractsWalletsEveryone elseBubble area = share of supply
92.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking9.0%
  • Walletsanonymous holders, free to sell83.8%
  • Everyone elsethe rest of the supply7.1%
Effective concentrationwhat the score reads87.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$3.55M across 16 pairs
Show 4 more pairs

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

Security Findings

1 Critical1 High2 Medium1 Low1 Info
Critical

Centralized Control and Owner Privileges

The 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).C-01

Issue

The 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).

Fix

Clearly 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.

Status

Unresolved

High

Potential Gas Limit Exceeded in multiTransfer

The 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).H-01

Issue

The 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).

Fix

Implement 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.

Status

Unresolved

Medium

Truncated _permit Function Source Code

The 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).M-01

Issue

The 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).

Fix

Provide 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.

Status

Unresolved

Medium

Owner Bypass for Blocked from Address in _beforeTokenTransfer

The _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).M-02

Issue

The _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).

Fix

Clearly 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.

Status

Unresolved

Low

Mixed Solidity Pragma Directives

The 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).L-01

Issue

The 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).

Fix

Unify the pragma directives to pragma solidity 0.8.4; across all contract files for consistency and to explicitly state the intended compiler version.

Status

Unresolved

Info

Unused isTrusted Mapping

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

Issue

The 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).

Fix

Remove 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.

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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).

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is crucial for users to be fully aware of the significant centralized control exercised by the contract owner, including the ability to mint, burn, block users, and confiscate funds.

Ensure the full and verified source code for all functionalities, especially _permit, is available for comprehensive auditing. Consider implementing mechanisms to mitigate potential gas limit issues for multiTransfer if large batch operations are anticipated. Maintain clear documentation regarding the owner's capabilities and the implications for token holders.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age4mo
Contract0x21ca…a3bf
Deployer0x1a63…d154
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
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. Sep 4, 202687Critical
  2. Aug 11, 202685Critical

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

Related Audits

6 more on the recordAll audits
WIKI CATWKC · BNB Chain87CriticalBlock StreetBSB · BNB Chain85CriticalInvesqo QQQQQQB · BNB Chain89CriticalLIGHTBNB Chain85CriticalCea IndustriesBNC4 · BNB Chain85CriticalDexeBNB Chain84High

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