Quantum Audit Logo
Launch App

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

Is 4CHAN Safe?

Ethereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance8/10Upgrades9/10Checks passed7 of 7Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The FourChan token contract is an ERC-20 compliant token with reflection mechanics, high transaction taxes, and anti-bot features.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (30.7% total → 24.6% effective; 20.6% in EOAs, 10.1% in contracts — mild)
  • 1 Critical finding(s) from audit
  • 1 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

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
10.1%Contracts20.6%Wallets69.3%Everyone else
10.1%20.6%Wallets69.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
30.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking10.1%
  • Walletsanonymous holders, free to sell20.6%
  • Everyone elsethe rest of the supply69.3%
Effective concentrationwhat the score reads24.6%
How holder types affect the score

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 4, 2026

Liquidity

as of audit · Sep 4$741.9K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$741.6KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0xb190…aaf00x9f45…e19a0x6304…75790x5662…70cf

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

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Renounced Ownership Bricks Critical Functions

The contract's ownership has been renounced, as indicated by the ownership_renounced: true prefill data. This renders all functions protected by the onlyOwner modifier unusable. These functions include setTaxFeePercent, setRedisFeePercent, setMaxTxAmount, setMaxWalletSize, excludeFromFee, includeInFee, setDevelopmentAddress, setMarketingAddress, openTrading, setSwapEnabled, addBot, removeBot, addPreTrader, removePreTrader, and updateBuyMap. The inability to modify these critical parameters or manage operational aspects means the contract is rigid and cannot adapt to market changes, fix potential issues, or update fee recipients, severely impacting its long-…C-01

Issue

The contract's ownership has been renounced, as indicated by the ownership_renounced: true prefill data. This renders all functions protected by the onlyOwner modifier unusable. These functions include setTaxFeePercent, setRedisFeePercent, setMaxTxAmount, setMaxWalletSize, excludeFromFee, includeInFee, setDevelopmentAddress, setMarketingAddress, openTrading, setSwapEnabled, addBot, removeBot, addPreTrader, removePreTrader, and updateBuyMap. The inability to modify these critical parameters or manage operational aspects means the contract is rigid and cannot adapt to market changes, fix potential issues, or update fee recipients, severely impacting its long-…

Fix

For future projects, if ownership renunciation is intended, ensure that all critical parameters are optimally configured and thoroughly tested beforehand. Consider implementing a timelock or a multi-signature wallet for critical administrative functions if some level of post-deployment control is desired without full centralization. For this specific contract, given the renounced ownership, this issue is irreversible.

Status

Unresolved

High

Irreversible High Tax Rates and Centralized Parameters

The contract is designed with high buy (20%) and sell (35%) taxes, and critical parameters such as _maxTxAmount, _maxWalletSize, and fee recipient addresses are controlled by the owner. Given that ownership is renounced, these parameters are now immutable. This means the project cannot adjust to market conditions, reduce taxes, or change fee recipients, which could negatively impact token utility, adoption, and the project's ability to respond to future needs or security concerns (7.4 Economic, 7.5 Governance).H-01

Issue

The contract is designed with high buy (20%) and sell (35%) taxes, and critical parameters such as _maxTxAmount, _maxWalletSize, and fee recipient addresses are controlled by the owner. Given that ownership is renounced, these parameters are now immutable. This means the project cannot adjust to market conditions, reduce taxes, or change fee recipients, which could negatively impact token utility, adoption, and the project's ability to respond to future needs or security concerns (7.4 Economic, 7.5 Governance).

Fix

For future projects, carefully evaluate the long-term implications of fixed high tax rates and other critical parameters. If ownership is to be renounced, consider a mechanism for community governance or a timelock to allow for parameter adjustments, or ensure that initial parameters are sustainable and acceptable for the project's lifespan. For this contract, these parameters are permanently fixed.

Status

Unresolved

Medium

Aggressive Anti-Bot Mechanism May Block Legitimate Users

The _transfer function includes an aggressive anti-bot mechanism: require(_buyMap[from] == 0 || preTrader[from], "Bot detected");. This logic prevents any address from making a second buy transaction unless that address is explicitly added to the preTrader whitelist by the owner. This could inadvertently block legitimate users who are not preTraders from making subsequent purchases, leading to a poor user experience and potential loss of trust. Furthermore, the preTrader list itself is centrally controlled by the owner (7.2 Code Security, 7.3 Access Control).M-01

Issue

The _transfer function includes an aggressive anti-bot mechanism: require(_buyMap[from] == 0 || preTrader[from], "Bot detected");. This logic prevents any address from making a second buy transaction unless that address is explicitly added to the preTrader whitelist by the owner. This could inadvertently block legitimate users who are not preTraders from making subsequent purchases, leading to a poor user experience and potential loss of trust. Furthermore, the preTrader list itself is centrally controlled by the owner (7.2 Code Security, 7.3 Access Control).

Fix

Review the anti-bot mechanism to ensure it does not unfairly penalize legitimate users. Consider alternative, less restrictive anti-bot strategies or implement a more transparent and decentralized process for managing whitelists. Given renounced ownership, this mechanism cannot be modified, so clear communication to users about this restriction is vital.

Status

Unresolved

Low

Single Address for Development and Marketing Fees

Both _developmentAddress and _marketingAddress are set to the same address (0xB2e0…3FCD). While this might be intentional, it centralizes the destination of all collected fees into a single wallet. This increases the single point of failure risk, as compromise of this one address would lead to the loss of all accumulated development and marketing funds (7.4 Economic, 7.8 Operations).L-01

Issue

Both _developmentAddress and _marketingAddress are set to the same address (). While this might be intentional, it centralizes the destination of all collected fees into a single wallet. This increases the single point of failure risk, as compromise of this one address would lead to the loss of all accumulated development and marketing funds (7.4 Economic, 7.8 Operations).

Fix

For future projects, consider using separate addresses for different fund allocations to diversify risk. Ideally, these addresses would be multi-signature wallets to enhance security. Given renounced ownership, this configuration is immutable for this contract.

Status

Unresolved

Info

Redundant SafeMath Usage

The contract explicitly uses the SafeMath library for arithmetic operations (e.g., amount.sub(...)). However, the contract is compiled with Solidity ^0.8.14, which includes built-in overflow and underflow checks by default. Therefore, the explicit use of SafeMath is redundant and adds unnecessary code complexity without providing additional security benefits (7.2 Code Security).I-01

Issue

The contract explicitly uses the SafeMath library for arithmetic operations (e.g., amount.sub(...)). However, the contract is compiled with Solidity ^0.8.14, which includes built-in overflow and underflow checks by default. Therefore, the explicit use of SafeMath is redundant and adds unnecessary code complexity without providing additional security benefits (7.2 Code Security).

Fix

For future contracts compiled with Solidity 0.8.0 or higher, SafeMath can be safely removed to reduce code size and improve readability, as the compiler handles overflow/underflow checks automatically. This is an informational finding and does not pose a security risk to the current contract.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The FourChan token contract is an ERC-20 compliant token with reflection mechanics, high transaction taxes, and anti-bot features. A critical vulnerability arises from the renounced ownership, which renders all owner-controlled functions immutable, including critical parameter adjustments and fee management. This severely limits the project's adaptability and ability to respond to market changes or security incidents. Additionally, the contract features aggressive anti-bot measures that could inadvertently block legitimate users and high, irreversible tax rates.

Technical7/10Low risk

The contract demonstrates a structured approach to tokenomics, incorporating reflection and fee mechanisms. It utilizes SafeMath for arithmetic operations, although redundant in Solidity 0.8+, and includes a reentrancy guard (inSwap) for its swapAndLiquify function (7.2 Code Security). However, the custom anti-bot mechanism, specifically the _buyMap logic, is highly restrictive and could lead to legitimate users being blocked (7.2 Code Security). The overall architecture is standard for a deflationary token, but its rigidity due to renounced ownership presents significant operational challenges (7.1 Architecture).

Governance8/10Low risk

The contract's economic model is characterized by high buy (20%) and sell (35%) taxes, which are designed to fund development and marketing (7.4 Economic). However, with ownership renounced, these tax rates are immutable, preventing any adjustments to adapt to market conditions or community feedback (7.5 Governance). The centralized control over critical parameters, now permanently fixed, poses a high risk to the project's long-term viability and flexibility (7.3 Access Control). Furthermore, both development and marketing fees are directed to a single address, centralizing fund distribution (7.4 Economic).

Upgrades9/10Low risk

The FourChan contract is not designed with any upgradeability mechanism (7.7 Upgrades). This means its logic and parameters are immutable once deployed and ownership is renounced. While this eliminates upgrade-related risks, it also prevents any future bug fixes, feature enhancements, or parameter adjustments, contributing to the overall rigidity of the protocol.

Final RecommendationWhat to do about this score

Given the renounced ownership, the project's ability to adapt or correct issues is severely limited.

It is crucial for users to understand that all owner-controlled parameters, including tax rates and anti-bot mechanisms, are permanently fixed. Future projects should carefully consider the implications of renouncing ownership, especially for highly configurable tokens, and ensure that all critical parameters are set optimally before doing so. If such a design is intentional, clear communication to the community about the immutability of these parameters is essential.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age3y
Contract0xe0a4…7885
Deployer0xad86…36e7
Badge for your website
4CHAN security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 30, 20267Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the 4CHAN contract address?

The 4CHAN contract on Ethereum is 0xe0a458bf4acf353cb45e211281a334bb1d837885. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is 4CHAN a scam?

Quantum Audit's risk score for 4CHAN is 7/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: 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.

Is 4CHAN liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $741.9K.

Who holds 4CHAN?

As of Sep 4, 2026, the 10 largest holders own 30.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
MOO DENGMOODENG · Ethereum7LowPAAL AI$PAAL · Ethereum7LowVeridiaEthereum7LowUnity SoftwareUNITY · Ethereum8LowArtificial PepeAP · Ethereum6LowzipcoinZC · Ethereum6Low

Would You Like a More Detailed Audit of 4CHAN?

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