Quantum Audit Logo

Is TornadoCash Safe?

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

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

TornadoCash TORN
0x7777…116c
Ethereum
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The TORN token contract implements the ERC20 standard, utilizing the SafeMath library for arithmetic operations to prevent common integer overflow/underflow vulnerabilities. It includes functions to mitigate the ERC20 approve race condition. However, the contract uses an older Solidity compiler version and lacks a pause mechanism. Potential centralization risks exist if minting/burning functions in derived contracts are not properly secured.

2 Medium1 Low1 Informational
Volume 24h
$218.0K
Liquidity
$362.8K
Price
$7.6000
Token Age
5y
Top 10 Holders
90.7%

Security Findings

2 Med1 Low1 Info
Medium

ERC20 Approve Race Condition Vulnerability

M-01The standard ERC20 `approve` function is susceptible to a front-running attack known as the 'approve race condition'. If a user approves an amount for a spender, and then wishes to change that approved amount, they must first set the allowance to zero before setting a new allowance. If they directly call `approve` with a new amount, a malicious spender could front-run the transaction, spend the original allowance, and then spend the newly approved allowance, effectively spending double the intended amount. While the contract includes `increaseAllowance` and `decreaseAllowance` to mitigate this, direct `approve` calls remain vulnerable.
IssueThe standard ERC20 `approve` function is susceptible to a front-running attack known as the 'approve race condition'. If a user approves an amount for a spender, and then wishes to change that approved amount, they must first set the allowance to zero before setting a new allowance. If they directly call `approve` with a new amount, a malicious spender could front-run the transaction, spend the original allowance, and then spend the newly approved allowance, effectively spending double the intended amount. While the contract includes `increaseAllowance` and `decreaseAllowance` to mitigate this, direct `approve` calls remain vulnerable.
FixAdvise users to exclusively use `increaseAllowance` and `decreaseAllowance` when modifying allowances. If direct `approve` must be used, users should first set the allowance to zero and wait for that transaction to confirm before setting a new allowance. Consider adding a warning in the contract's documentation or UI about this standard ERC20 vulnerability.
StatusUnresolved
Medium

Potential Centralization of Mint/Burn Functions in Derived Contracts

M-02The `_mint` and `_burn` functions are internal virtual functions within the `ERC20` contract. While this base contract itself does not expose them publicly, any derived contract (e.g., the final TORN token contract) that implements or exposes these functions must ensure robust access control. Without proper protection (e.g., `onlyOwner` or `onlyMinter` modifiers), these functions could be called by unauthorized entities, leading to uncontrolled token supply manipulation, which poses a significant economic risk to the token holders.
IssueThe `_mint` and `_burn` functions are internal virtual functions within the `ERC20` contract. While this base contract itself does not expose them publicly, any derived contract (e.g., the final TORN token contract) that implements or exposes these functions must ensure robust access control. Without proper protection (e.g., `onlyOwner` or `onlyMinter` modifiers), these functions could be called by unauthorized entities, leading to uncontrolled token supply manipulation, which poses a significant economic risk to the token holders.
FixFor any contract inheriting from `ERC20` and exposing `_mint` or `_burn` functionality, implement strict access control mechanisms (e.g., using OpenZeppelin's Ownable or AccessControl contracts) to restrict these operations to authorized addresses only. Clearly document the roles and permissions associated with these critical functions.
StatusUnresolved
Low

Lack of Pausability Mechanism

L-01The contract does not include a mechanism to pause token transfers or other critical operations. In the event of an emergency, such as a discovered vulnerability in an integrated DeFi protocol, a major exploit, or a critical bug in the token contract itself, the inability to pause operations could lead to significant and irreversible losses for users and the protocol. While not strictly a vulnerability, it is a common security feature in many modern token contracts.
IssueThe contract does not include a mechanism to pause token transfers or other critical operations. In the event of an emergency, such as a discovered vulnerability in an integrated DeFi protocol, a major exploit, or a critical bug in the token contract itself, the inability to pause operations could lead to significant and irreversible losses for users and the protocol. While not strictly a vulnerability, it is a common security feature in many modern token contracts.
FixConsider implementing a pausability mechanism (e.g., using OpenZeppelin's Pausable contract) in a derived contract. This would allow an authorized entity (e.g., a multi-sig wallet or governance) to temporarily halt critical operations during emergencies, providing time to address issues and prevent further damage.
StatusUnresolved
Info

Use of Older Solidity Compiler Version

I-01The contract is compiled with Solidity version `^0.6.0`. While `SafeMath` is used to mitigate integer overflow/underflow, newer Solidity versions (e.g., 0.8.x and above) include built-in overflow and underflow checks by default, making `SafeMath` redundant and potentially reducing gas costs. Newer versions also offer various language improvements, optimizations, and security features that are not available in older versions.
IssueThe contract is compiled with Solidity version `^0.6.0`. While `SafeMath` is used to mitigate integer overflow/underflow, newer Solidity versions (e.g., 0.8.x and above) include built-in overflow and underflow checks by default, making `SafeMath` redundant and potentially reducing gas costs. Newer versions also offer various language improvements, optimizations, and security features that are not available in older versions.
FixConsider upgrading the Solidity compiler version to 0.8.x or higher. This would allow for the removal of the `SafeMath` library, simplifying the code and potentially reducing gas costs, while benefiting from the latest compiler-level security enhancements and features. Thorough testing would be required after such an upgrade.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good architectural design by adhering to the ERC20 standard (7.1 Architecture) and employing the SafeMath library to prevent integer overflows/underflows (7.2 Code Security). The inclusion of `increaseAllowance` and `decreaseAllowance` functions helps mitigate the common ERC20 approve race condition (7.2 Code Security). However, the use of an older Solidity compiler version (7.2 Code Security) means missing out on newer security features and optimizations. Additionally, the internal `_mint` and `_burn` functions, if exposed in inheriting contracts without robust access control, could introduce centralization risks (7.3 Access Control).

GovernanceHigh2/10

The contract provides standard ERC20 token functionality, which is well-understood and widely adopted, contributing to a predictable economic model (7.4 Economic). There are no complex governance mechanisms directly implemented within this base ERC20 contract, simplifying its operational scope (7.5 Governance). A notable design choice is the absence of a pause mechanism, which could be beneficial for emergency response in case of unforeseen vulnerabilities or market events (7.4 Economic).

UpgradesMedium6/10

The contract is not designed as a proxy (7.7 Upgrades), which simplifies its deployment and eliminates the specific attack vectors associated with upgradeability, such as storage collisions or improper initialization. This design choice ensures immutability post-deployment. However, as a non-upgradeable contract, any critical vulnerabilities discovered after deployment would necessitate a new contract deployment and a potentially costly and disruptive token migration process (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

90.7% in top 10
1.9% in wallets88.8% in contracts
Effective Concentration37.4%

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

$856.6K across 9 pairs
Uniswap v3WETHanalysed$362.8K42.4%Uniswap v4ETH$273.7K32.0%Uniswap v2WETH$185.6K21.7%SushiswapWETH$17.2K2.0%Pancakeswap v3WETH$11.7K1.4%Uniswap v3WETH$2.6K0.3%
Show 3 more pairsShow less
Uniswap v3DAI$2.2K0.3%Uniswap v3USDC$6840.1%SwaprWETH$170.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 Holder61.3%
Top-3 Unlocked88.5%

Key Addresses

11 addresses
Deployer
0xce00…cf9f
Unlocked LP Held By
0x8f30…d7180xabc9…b0ea0x99bc…daa20xef50…d1a90x00bd…a8bf0x8d83…0dc90x1a03…3ebe0x2ffa…1a920x5a9b…07c20x9dd5…d61c

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

What Raised This Score

7 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Top-10 concentration > 30% (90.7% total → 37.4% effective; 1.9% in EOAs, 88.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 61.3% (independent LP — depth risk, pool = 42% of DEX liquidity)
  • LP top3 unlocked holders = 88.5% (independent LP — depth risk, pool = 42% of DEX liquidity)
  • 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
Asentum (ASE)High RiskSafe Token (SAFE)High RiskLQTYHigh RiskBiconomy (BICO)Medium RiskVestra DAO (VSTR)High RiskMOMOHigh Risk

Would You Like a More Detailed Audit of TornadoCash?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit