Is Wootrade Network (WOO) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High1 Med1 Low

Critical

Integer Overflow in Token Balances

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.

IssueThe `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.

FixUpgrade 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.

StatusUnresolved

High

ERC-20 `approve` Race Condition

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.

IssueThe `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.

FixAdvise 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.

StatusUnresolved

High

Outdated Solidity Compiler Version

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).

IssueThe 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).

FixUpgrade 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.

StatusUnresolved

Medium

Risky `approveAndCall` External Call

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`.

IssueThe `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`.

FixEnsure 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.

StatusUnresolved

Low

Redundant `totalSupply` Declaration

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.

IssueThe `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.

FixDeclare `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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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.

UpgradesMedium5/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

76.0% in top 10

38.9% in wallets37.1% in contracts

Effective Concentration53.7%

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

$1.25M across 7 pairs

Uniswap v2WETHanalysed$638.8K Uniswap v4ETH$599.3K Uniswap v3WETH$5.0K SushiswapUSDC$1.3K Uniswap v4USDC$1.0K SushiswapWETH$73

Show 1 more pairShow less

Uniswap v4USDT$60

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 Holder98.6%

Top-3 Unlocked99.5%

Key Addresses

11 addresses

Deployer

0xe64e…c91b

Unlocked LP Held By

0x6c53…347f0x0c54…a93c0x254a…93660x8e1b…a5be0xd401…72fe0x40ae…f62f0x3ed1…b2380xa855…e5030xce97…56f30x826f…1e65

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

What Raised This Score

9 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 50% (76.0% total → 53.7% effective; 38.9% in EOAs, 37.1% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 98.6% (independent LP — depth risk, pool = 51% of DEX liquidity)
LP top3 unlocked holders = 99.5% (independent LP — depth risk, pool = 51% of DEX liquidity)
1 Critical finding(s) from audit
2 High finding(s) from audit
1 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

Is Wootrade Network Safe?

Security Findings

Integer Overflow in Token Balances

ERC-20 `approve` Race Condition

Outdated Solidity Compiler Version

Risky `approveAndCall` External Call

Redundant `totalSupply` Declaration

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Wootrade Network?