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.

On-chain security analysis — is it a scam or legit?
Is Wrapped TAO Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking10.6%
- Walletsanonymous holders, free to sell12.3%
- Everyone elsethe rest of the supply77.1%
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- Uniswap v3WETHAnalysed$2.23M56.2%
- Uniswap v3USDC$907.5K22.9%
- Uniswap v3WETH$353.0K8.9%
- Uniswap v4ETH$303.5K7.6%
- Uniswap v3USDC$88.8K2.2%
- Uniswap v4USDC$62.8K1.6%
Show 2 more pairs
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x32c8…97680x99d5…7d3a0xf769…0c280x3496…d5430xe826…cead0x144b…10790x51bc…eb770xb41b…1af70x0468…69ae0x0001…bcccNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized 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
LowMisleading 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
BITTENSOR_FEE NamingIssue
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
InfoRedundant 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
SafeMath UsageIssue
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 4The 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.
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.
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202626Low
- 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