Quantum Audit Logo

Is WIKI CAT a Scam?

Honeypot, rug-pull and ownership checks

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

WIKI CAT WKC
0x6ec9…8edb
BNB Chain
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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The CoinToken contract implements a standard ERC-20 token with added features such as transaction fees, burn fees, pausing functionality, and a blacklist. The contract utilizes an outdated Solidity compiler version and exhibits significant centralization. A critical vulnerability exists where the `burn` function calls an undefined internal function, rendering it non-functional. Additionally, the fee calculation logic is prone to precision errors, and the `updateFee` function is truncated in the provided source.

1 Critical2 High1 Medium1 Low1 Informational
i Our automated scanner reviewed WIKI CAT (WKC) on BNB Chain. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$145.9K
Liquidity
$1.32M
Price
$0.0000000934
Age
4y
Top 10 Holders
42.9%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Missing `_burn` Function Implementation

C-01The `CoinToken` contract's `burn` function calls an internal function `_burn(msg.sender, _value);`. However, the `_burn` function is not defined anywhere in the `CoinToken` contract or its inherited contracts (`PausableToken`, `StandardToken`, `ERC20`, `ERC20Basic`, `Pausable`, `Ownable`). This will cause the `burn` function to always revert when called, rendering the token's burn mechanism completely non-functional.
IssueThe `CoinToken` contract's `burn` function calls an internal function `_burn(msg.sender, _value);`. However, the `_burn` function is not defined anywhere in the `CoinToken` contract or its inherited contracts (`PausableToken`, `StandardToken`, `ERC20`, `ERC20Basic`, `Pausable`, `Ownable`). This will cause the `burn` function to always revert when called, rendering the token's burn mechanism completely non-functional.
FixImplement the `_burn` function in `CoinToken` or one of its parent contracts, ensuring it correctly reduces `balances[burner]` and `totalSupply`, and emits a `Burn` event. For example, `function _burn(address _burner, uint256 _value) internal { require(_value <= balances[_burner]); balances[_burner] = balances[_burner].sub(_value); totalSupply = totalSupply.sub(_value); emit Burn(_burner, _value); emit Transfer(_burner, address(0), _value); }`
StatusUnresolved
High

Inaccurate and Error-Prone Fee Calculation Logic

H-01The transaction and burn fee calculations use `tempValue.div(uint256(100 / txFee))` and `tempValue.div(uint256(100 / burnFee))`. This approach is problematic because the intermediate division `100 / txFee` (or `100 / burnFee`) performs integer truncation. For example, if `txFee` is 3, `100 / 3` truncates to 33, resulting in a fee of `tempValue / 33` (approx. 3.03%) instead of `tempValue * 3 / 100` (3%). This leads to inaccurate fee collection and unexpected behavior for non-divisor fee percentages. Additionally, if `txFee` or `burnFee` are not positive, the `100 / fee` operation would revert, although a `txFee > 0` check is present.
IssueThe transaction and burn fee calculations use `tempValue.div(uint256(100 / txFee))` and `tempValue.div(uint256(100 / burnFee))`. This approach is problematic because the intermediate division `100 / txFee` (or `100 / burnFee`) performs integer truncation. For example, if `txFee` is 3, `100 / 3` truncates to 33, resulting in a fee of `tempValue / 33` (approx. 3.03%) instead of `tempValue * 3 / 100` (3%). This leads to inaccurate fee collection and unexpected behavior for non-divisor fee percentages. Additionally, if `txFee` or `burnFee` are not positive, the `100 / fee` operation would revert, although a `txFee > 0` check is present.
FixRevise the fee calculation to use a standard and precise method, such as `feeAmount = tempValue.mul(txFee).div(100);` where `txFee` represents the percentage (e.g., 1 for 1%, 5 for 5%). This ensures accurate fee application regardless of the percentage value.
StatusUnresolved
High

High Centralization and Extensive Owner Privileges

H-02The `owner` address holds significant control over the contract's operations. This includes the ability to pause all token transfers, blacklist any address (preventing them from transferring tokens), and unilaterally modify the `txFee`, `burnFee`, and `FeeAddress` through the `updateFee` function. Such extensive centralization introduces a single point of failure and high governance risk, as a compromised owner key could lead to a complete shutdown of token transfers, censorship, or arbitrary fee changes.
IssueThe `owner` address holds significant control over the contract's operations. This includes the ability to pause all token transfers, blacklist any address (preventing them from transferring tokens), and unilaterally modify the `txFee`, `burnFee`, and `FeeAddress` through the `updateFee` function. Such extensive centralization introduces a single point of failure and high governance risk, as a compromised owner key could lead to a complete shutdown of token transfers, censorship, or arbitrary fee changes.
FixConsider implementing a multi-signature wallet for the `owner` role to distribute control and reduce the risk associated with a single compromised key. For critical functions like `blackListAddress` or `updateFee`, explore decentralized governance mechanisms or time-locked changes to provide transparency and allow community reaction.
StatusUnresolved
Medium

Outdated Solidity Compiler Version

M-01The contract is compiled with Solidity version `^0.4.24`. This is a significantly outdated compiler version. Newer Solidity versions (e.g., 0.8.x) include important security enhancements, bug fixes, and gas optimizations. For instance, `assert` statements in older versions consume all remaining gas on failure, whereas `require` (and `revert`) refund unused gas, making error handling less efficient. Using an old compiler might expose the contract to known compiler-level vulnerabilities or lead to less efficient code.
IssueThe contract is compiled with Solidity version `^0.4.24`. This is a significantly outdated compiler version. Newer Solidity versions (e.g., 0.8.x) include important security enhancements, bug fixes, and gas optimizations. For instance, `assert` statements in older versions consume all remaining gas on failure, whereas `require` (and `revert`) refund unused gas, making error handling less efficient. Using an old compiler might expose the contract to known compiler-level vulnerabilities or lead to less efficient code.
FixUpgrade the Solidity compiler version to a recent stable release (e.g., 0.8.x). This will require careful review and testing of the code for breaking changes and potential new warnings, especially regarding integer overflow/underflow checks which are default in 0.8.x.
StatusUnresolved
Low

Truncated Code in `updateFee` Function

L-01The provided source code for the `updateFee` function in `CoinToken` is incomplete, ending abruptly with `FeeAddr...`. This truncation prevents a full security analysis of how the `FeeAddress` is updated and whether proper validation or event emission is included in this critical function.
IssueThe provided source code for the `updateFee` function in `CoinToken` is incomplete, ending abruptly with `FeeAddr...`. This truncation prevents a full security analysis of how the `FeeAddress` is updated and whether proper validation or event emission is included in this critical function.
FixProvide the complete and untruncated source code for all functions to enable a comprehensive security audit. Ensure that the `updateFee` function includes appropriate validation (e.g., `require(_FeeAddress != address(0))`) and emits an event to log the fee changes.
StatusUnresolved
Info

Misleading Variable Naming for Fees

I-01The variables `txFee` and `burnFee` are named in a way that typically implies a percentage numerator (e.g., `txFee = 5` for 5%). However, their usage in the calculation `tempValue.div(uint256(100 / txFee))` implies they are effectively the denominator of the percentage rate (e.g., if `txFee = 1`, it means 1% because `100/1 = 100`, so `value/100`). This discrepancy between common naming conventions and actual usage can lead to confusion and misconfiguration.
IssueThe variables `txFee` and `burnFee` are named in a way that typically implies a percentage numerator (e.g., `txFee = 5` for 5%). However, their usage in the calculation `tempValue.div(uint256(100 / txFee))` implies they are effectively the denominator of the percentage rate (e.g., if `txFee = 1`, it means 1% because `100/1 = 100`, so `value/100`). This discrepancy between common naming conventions and actual usage can lead to confusion and misconfiguration.
FixRename `txFee` and `burnFee` to reflect their role as percentage numerators (e.g., `txFeeRate`) and adjust the calculation to `tempValue.mul(txFeeRate).div(100)`. Alternatively, if the current calculation logic is strictly desired, rename the variables to clarify their role as divisors (e.g., `txFeeDivisor`).
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract's technical foundation is based on an outdated Solidity compiler (0.4.24), which introduces potential vulnerabilities and inefficiencies (7.2 Code Security). A critical flaw is present in the `CoinToken.burn` function, which attempts to call an undefined internal `_burn` function, causing it to always revert (7.2 Code Security). The fee calculation mechanism for `txFee` and `burnFee` is susceptible to truncation errors, leading to inaccurate fee application (7.4 Economic). While SafeMath is used, its reliance on `assert` instead of `require` for error handling is less gas-efficient in older Solidity versions (7.2 Code Security).

GovernanceHigh2/10

The contract exhibits a high degree of centralization, with the `owner` possessing extensive control over critical functions (7.3 Access Control, 7.5 Governance). The owner can pause all token transfers, blacklist any address, and unilaterally modify the transaction fee, burn fee, and the fee recipient address via `updateFee` (7.3 Access Control, 7.4 Economic). This centralized control introduces significant governance risk, as a compromised owner key could lead to severe economic consequences for token holders (7.5 Governance). The imprecise fee calculation also poses an economic risk by potentially miscalculating token deductions (7.4 Economic).

UpgradesHigh3/10

The provided contract does not implement any proxy or upgradeability patterns (7.7 Upgrades). Therefore, the contract is immutable once deployed, meaning its logic cannot be changed or updated. This eliminates upgrade-related risks but also prevents bug fixes or feature enhancements post-deployment.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedPass
Not a ProxyPass

Holder Composition

42.9% in top 10
40.6% in wallets2.3% in contracts
Effective Concentration41.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

$1.35M across 9 pairs
Pancakeswap v2WBNBanalysed$1.32M97.9%Pancakeswap v2BUSD$27.1K2.0%Pancakeswap v2USDC$1.5K0.1%Pancakeswap v2USDT$520.0%Pancakeswap v2ETH$30.0%Pancakeswap v2Cake$10.0%
Show 2 more pairsShow less
Uniswap v2WBNB$10.0%Pancakeswap v2DAI$00.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

LP Burned37.2%
LP Locked99.1% · UNCX
Top-1 Unlocked Holder0.3%

Key Addresses

9 addresses
Deployer
0x1e12…e0c1
Unlocked LP Held By
0xa095…108b0xc83c…499e0x0ed9…97060x6dbb…ab6c0xbc49…2e2b0xaf8a…706f0x7558…efd20x4a11…4f01

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 — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (42.9% total → 41.5% effective; 40.6% in EOAs, 2.3% in contracts — moderate)
  • 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

Related Audits

6 more on the record
Tether Gold (XAUT)Critical RiskBlock Street (BSB)Critical RiskInvesqo QQQ (QQQB)Critical RiskLIGHTCritical RiskCea Industries (BNC4)Critical RiskDexeCritical Risk

Would You Like a More Detailed Audit of WIKI CAT?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit