Quantum Audit Logo

Is Wrapped TAO Safe?

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

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

Wrapped TAO WTAO
0x77e0…0a44
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

1 High1 Low1 Informational
Volume 24h
$749.1K
Liquidity
$2.23M
Price
$227.2500
Token Age
3y
Top 10 Holders
22.9%

Security Findings

1 High1 Low1 Info
High

Centralized Control Over Bridge Role and Funds

H-01The 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…
IssueThe 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…
FixImplement 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.
StatusUnresolved
Low

Misleading `BITTENSOR_FEE` Naming

L-01The `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).
IssueThe `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).
FixRename 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.
StatusUnresolved
Info

Redundant `SafeMath` Usage

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

Category Ratings

TechnicalLow9/10

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.

GovernanceMedium4/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

22.9% in top 10
12.3% in wallets10.6% in contracts
Effective Concentration16.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.97M across 8 pairs
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 pairsShow less
Uniswap v4USDC$21.6K0.5%BlueprintWETH$250.0%

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 Holder18.7%
Top-3 Unlocked48.7%

Key Addresses

11 addresses
Deployer
0x5db4…3b14
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.

What Raised This Score

4 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

Related Audits

6 more on the record
Shiba Inu (SHIB)Medium RiskGrand Theft Auto VI (GTAVI)Medium RiskUnipeg (UPEG)Medium RiskMog Coin (MOG)Medium RiskTelcoin (TEL)Medium RiskStockereum.fun (STOCKER)Medium Risk

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