On-chain security analysis — is it a scam or legit?
EthereumThe WootradeNetwork contract is an ERC-20-like token implementation.
Read the full analysisEach 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
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 6, 2026
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.
0x6c53…347f0x0c54…a93c0x254a…93660x8e1b…a5be0xd401…72fe0x40ae…f62f0x3ed1…b2380xa855…e5030xce97…56f30x826f…1e65No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
balances[_to] += _value; operation in both transfer and transferFrom functions lacks protection against integer overflow. In Solidity versions prior to 0.8.0, arithmetic operations do not automatically revert on overflow. A malicious actor could potentially cause an overflow if _value is sufficiently large and balances[_to] is near type(uint256).max, leading to an incorrect balance (wrapping around to a small number) and effectively minting tokens.C-01The balances[_to] += _value; operation in both transfer and transferFrom functions lacks protection against integer overflow. In Solidity versions prior to 0.8.0, arithmetic operations do not automatically revert on overflow. A malicious actor could potentially cause an overflow if _value is sufficiently large and balances[_to] is near type(uint256).max, leading to an incorrect balance (wrapping around to a small number) and effectively minting tokens.
Upgrade to Solidity 0.8.0 or higher, which includes built-in overflow/underflow checks. Alternatively, for older Solidity versions, use a SafeMath library for all arithmetic operations to prevent overflows and underflows.
Unresolved
approve Race Conditionapprove function is vulnerable to a known ERC-20 race condition. If a user approves an amount X for a spender, then decides to change it to Y (where Y < X), a front-running attacker could observe the transaction changing X to Y, quickly execute a transferFrom for amount X before the approve(Y) transaction is mined. The approve(Y) transaction would then proceed, leaving the spender with an allowance of Y after having already spent X, allowing the spender to spend more than intended. The approveAndCall function also sets allowed and is thus susceptible to this initial race condition before the external call.H-01The approve function is vulnerable to a known ERC-20 race condition. If a user approves an amount X for a spender, then decides to change it to Y (where Y < X), a front-running attacker could observe the transaction changing X to Y, quickly execute a transferFrom for amount X before the approve(Y) transaction is mined. The approve(Y) transaction would then proceed, leaving the spender with an allowance of Y after having already spent X, allowing the spender to spend more than intended. The approveAndCall function also sets allowed and is thus susceptible to this initial race condition before the external call.
Advise users to first set the allowance to zero with approve(spender, 0) and wait for that transaction to confirm before setting a new allowance. Alternatively, implement a decreaseAllowance and increaseAllowance pattern, or use a more robust approve mechanism that prevents this race condition.
Unresolved
^0.4.4, which is likely compiled with version 0.4.18 as per the provided metadata. This compiler version is significantly outdated and lacks many security features, optimizations, and bug fixes present in newer compilers (e.g., 0.8.x). Notably, it does not include built-in overflow/underflow checks for arithmetic operations, which is a major source of vulnerabilities if not manually mitigated (e.g., with SafeMath).H-02The contract uses Solidity ^0.4.4, which is likely compiled with version 0.4.18 as per the provided metadata. This compiler version is significantly outdated and lacks many security features, optimizations, and bug fixes present in newer compilers (e.g., 0.8.x). Notably, it does not include built-in overflow/underflow checks for arithmetic operations, which is a major source of vulnerabilities if not manually mitigated (e.g., with SafeMath).
Upgrade the contract to a modern Solidity compiler version (e.g., 0.8.x). This will automatically enable important security features like checked arithmetic, reducing the risk of integer overflows/underflows, and benefit from other compiler improvements and bug fixes.
Unresolved
approveAndCall External CallapproveAndCall function performs an external call to an arbitrary _spender address. While the allowance is updated before the call, external calls to untrusted contracts introduce risks. A malicious or buggy _spender contract could revert, causing the approveAndCall transaction to fail, or potentially attempt reentrancy (though less direct in this specific pattern due to state changes preceding the call). The use of keccak256 for selector generation is also an older, less explicit pattern compared to abi.encodeWithSelector.M-01The approveAndCall function performs an external call to an arbitrary _spender address. While the allowance is updated before the call, external calls to untrusted contracts introduce risks. A malicious or buggy _spender contract could revert, causing the approveAndCall transaction to fail, or potentially attempt reentrancy (though less direct in this specific pattern due to state changes preceding the call). The use of keccak256 for selector generation is also an older, less explicit pattern compared to abi.encodeWithSelector.
Ensure that any _spender contract called via approveAndCall is fully trusted and audited. Consider implementing reentrancy guards if the contract's logic were to involve more complex interactions. For new development, use abi.encodeWithSelector for clarity and type safety when encoding function calls.
Unresolved
totalSupply DeclarationtotalSupply state variable is declared multiple times across the inheritance chain: in Token, StandardToken, and WootradeNetwork. While the declaration in WootradeNetwork effectively shadows the others, this redundancy can lead to confusion for developers and is considered poor coding practice.L-01The totalSupply state variable is declared multiple times across the inheritance chain: in Token, StandardToken, and WootradeNetwork. While the declaration in WootradeNetwork effectively shadows the others, this redundancy can lead to confusion for developers and is considered poor coding practice.
Declare totalSupply only once in the base Token contract or the most appropriate contract in the inheritance hierarchy, and ensure derived contracts do not redeclare it. This improves code clarity and maintainability.
Unresolved
The WootradeNetwork contract is an ERC-20-like token implementation. The audit identified critical vulnerabilities related to integer overflows, a high-severity ERC-20 approve race condition, and the use of an outdated Solidity compiler version. These issues pose significant risks to token integrity and user funds.
The contract implements a basic ERC-20 token with an approveAndCall extension. Strengths include a fallback function that prevents accidental Ether transfers and basic checks for _value > 0 in transfers. However, significant technical risks exist, including a critical integer overflow vulnerability in balance additions (7.2 Code Security) and a high-severity ERC-20 approve race condition (7.3 Access Control). The use of an outdated Solidity compiler (7.2 Code Security) further exacerbates these risks by lacking modern security features.
The WootradeNetwork token is a standard ERC-20-like asset with no complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). The initial token supply is minted to the deployer, which is a common practice. There are no specific economic vulnerabilities identified beyond the technical issues affecting token integrity.
The WootradeNetwork contract is not designed to be upgradeable (7.7 Upgrades). It is a standard, non-proxy implementation, meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks but also means any discovered vulnerabilities cannot be patched without a new deployment and migration.
It is strongly recommended to migrate this contract to a newer Solidity version (e.g., 0.8.x) and implement robust integer overflow/underflow protection using SafeMath or similar libraries.
The ERC-20 approve function should be carefully reviewed, and users should be advised on the race condition. For the approveAndCall function, consider implementing reentrancy guards or ensuring the called contract is trusted and audited.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Wootrade Network (WOO) contract on Ethereum is 0x4691937a7508860f876c9c0a2a617e7d9e945d4b. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Wootrade Network is 70/100 (High risk) as of Sep 6, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 6, 2026). Total DEX liquidity: $1.25M.
As of Sep 6, 2026, the 10 largest holders own 76.0% of the supply. The Holders section on this page shows who they are by holder type.
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
