Quantum Audit Logo
Launch App

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

Is Wrapped TAO Safe?

WTAOEthereum
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
SummaryAI Copilot

The wTAO contract implements an ERC20 token with bridging functionalities, leveraging OpenZeppelin's secure libraries for token standards, access control, and safe math.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • 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 an EOA (single private key)
  • 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
10.6%Contracts12.3%Wallets77.1%Everyone else
10.6%12.3%Wallets77.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
22.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking10.6%
  • Walletsanonymous holders, free to sell12.3%
  • Everyone elsethe rest of the supply77.1%
Effective concentrationwhat the score reads16.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.97M across 8 pairs
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$2.23MShare of depth56.2%
Top-1 Unlocked Holder18.7%
Top-3 Unlocked48.7%
Unlocked LP held by
0x32c8…97680x99d5…7d3a0xf769…0c280x3496…d5430xe826…cead0x144b…10790x51bc…eb770xb41b…1af70x0468…69ae0x0001…bccc

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

Security Findings

1 High1 Low1 Info
High

Centralized Control Over Bridge Role and Funds

The contract owner (and DEFAULT_ADMIN_ROLE) possesses exclusive control over critical functions. The setBridge function, callable only by the owner, assigns the BRIDGE_ROLE, which is the sole entity authorized to mint new wTAO tokens via bridgedTo. Additionally, the reclaimToken function allows the owner to transfer any ERC20 tokens or native ETH held by the contract to their address. This high degree of centralization means that a compromised owner key could lead to arbitrary token minting, manipulation of the token supply, and theft of all funds held within the contract, posing a significant economic and operational risk (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.8 Ope…H-01

Issue

The contract owner (and DEFAULT_ADMIN_ROLE) possesses exclusive control over critical functions. The setBridge function, callable only by the owner, assigns the BRIDGE_ROLE, which is the sole entity authorized to mint new wTAO tokens via bridgedTo. Additionally, the reclaimToken function allows the owner to transfer any ERC20 tokens or native ETH held by the contract to their address. This high degree of centralization means that a compromised owner key could lead to arbitrary token minting, manipulation of the token supply, and theft of all funds held within the contract, posing a significant economic and operational risk (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.8 Ope…

Fix

Implement a multi-signature wallet or a decentralized autonomous organization (DAO) governance system to manage the contract's ownership and DEFAULT_ADMIN_ROLE. This would require multiple approvals for critical actions, distributing control and significantly reducing the risk associated with a single point of failure. Consider a timelock for sensitive operations to allow community review.

Status

Unresolved

Low

Misleading BITTENSOR_FEE Naming

The BITTENSOR_FEE variable is used within the bridgeBack function as a minimum amount that must be burned (require(_amount > BITTENSOR_FEE)). However, the term 'FEE' typically implies an amount that is collected or transferred to a specific address. In this contract, the BITTENSOR_FEE is merely a threshold, and no actual fee is collected by the contract or any other entity. This naming convention could lead to confusion for users or integrators regarding the token's economic model (7.4 Economic).L-01

Issue

The BITTENSOR_FEE variable is used within the bridgeBack function as a minimum amount that must be burned (require(_amount > BITTENSOR_FEE)). However, the term 'FEE' typically implies an amount that is collected or transferred to a specific address. In this contract, the BITTENSOR_FEE is merely a threshold, and no actual fee is collected by the contract or any other entity. This naming convention could lead to confusion for users or integrators regarding the token's economic model (7.4 Economic).

Fix

Rename the BITTENSOR_FEE variable to something more descriptive of its actual function, such as MIN_BRIDGE_BACK_AMOUNT or MIN_BURN_THRESHOLD. Additionally, update any associated comments or documentation to clearly explain its purpose.

Status

Unresolved

Info

Redundant SafeMath Usage

The contract explicitly imports and uses SafeMath for uint256 operations (e.g., cumulative_bridged.add(_amounts[i])). While this practice is harmless, Solidity versions 0.8.0 and above, which this contract uses (pragma solidity ^0.8.0;), include built-in overflow and underflow checks by default for all arithmetic operations. This makes the explicit use of SafeMath redundant for preventing these types of vulnerabilities (7.2 Code Security).I-01

Issue

The contract explicitly imports and uses SafeMath for uint256 operations (e.g., cumulative_bridged.add(_amounts[i])). While this practice is harmless, Solidity versions 0.8.0 and above, which this contract uses (pragma solidity ^0.8.0;), include built-in overflow and underflow checks by default for all arithmetic operations. This makes the explicit use of SafeMath redundant for preventing these types of vulnerabilities (7.2 Code Security).

Fix

Consider removing the SafeMath import and usage. The contract will still be protected against integer overflows/underflows by Solidity's default behavior. This can slightly reduce contract size and improve readability without compromising security.

Status

Unresolved

Analysis

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

The wTAO contract implements an ERC20 token with bridging functionalities, leveraging OpenZeppelin's secure libraries for token standards, access control, and safe math. While the code quality is high and standard vulnerabilities like reentrancy and integer overflows are mitigated, the contract exhibits a high degree of centralization. The owner has significant control over critical functions, including setting the bridge role (which controls token minting) and reclaiming any tokens or native ETH sent to the contract. This centralization introduces substantial economic and operational risks.

Technical9/10Low risk

The contract demonstrates good technical security practices (7.2 Code Security), utilizing battle-tested OpenZeppelin libraries for ERC20, Ownable, and AccessControl. Array length checks are correctly implemented in bridgedTo, and SafeMath is used for arithmetic operations, although redundant in Solidity 0.8.0+. The architecture (7.1 Architecture) is straightforward, providing a wrapped token with clear bridging mechanisms. However, the centralized control over the BRIDGE_ROLE by the owner (7.3 Access Control) is a significant design choice that introduces a technical risk, as a compromised owner key could lead to unauthorized minting.

Governance4/10Medium risk

The economic and governance model (7.4 Economic, 7.5 Governance) presents a high centralization risk. The contract owner, currently an EOA, holds exclusive power to set the BRIDGE_ROLE, which is the sole entity authorized to mint new wTAO tokens via bridgedTo. Furthermore, the owner can reclaim any ERC20 tokens or native ETH accidentally sent to the contract using reclaimToken. This concentration of power means a single point of failure; a compromised owner key could lead to arbitrary token minting, supply manipulation, and theft of funds. The BITTENSOR_FEE variable, while not a direct vulnerability, is misleadingly named as it represents a minimum burn amount rather than a collected fee.

Upgrades6/10Medium risk

The wTAO contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, it does not inherently carry upgrade-related risks such as proxy misconfigurations or storage collisions. Any future changes to the contract logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Final RecommendationWhat to do about this score

To mitigate the high centralization risk, consider transitioning the contract ownership and DEFAULT_ADMIN_ROLE to a multi-signature wallet or a robust DAO governance mechanism.

This would distribute control and require multiple approvals for critical operations like setting the bridge role or reclaiming funds, significantly enhancing the protocol's security and resilience against single points of failure. Additionally, clarify the purpose of BITTENSOR_FEE in documentation or rename the variable to accurately reflect its function as a minimum burn threshold, improving transparency for users and integrators.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age3y
Contract0x77e0…0a44
Deployer0x5db4…3b14
Badge for your website
Wrapped TAO 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, 202626Low
  2. Aug 12, 202638Medium

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

Frequently Asked Questions

What is the WTAO contract address?

The Wrapped TAO (WTAO) contract on Ethereum is 0x77e06c9eccf2e797fd462a92b6d7642ef85b0a44. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Wrapped TAO a scam?

Quantum Audit's risk score for Wrapped TAO is 26/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is WTAO liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $3.97M.

Who holds WTAO?

As of Sep 4, 2026, the 10 largest holders own 22.9% of the supply. The Holders section on this page shows who they are by holder type.

Would You Like a More Detailed Audit of Wrapped TAO?

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