Is 4CHAN Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med1 Low1 Info

Critical

Renounced Ownership Bricks Critical Functions

C-01The 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-…

IssueThe 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-…

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

StatusUnresolved

High

Irreversible High Tax Rates and Centralized Parameters

H-01The 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).

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

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

StatusUnresolved

Medium

Aggressive Anti-Bot Mechanism May Block Legitimate Users

M-01The `_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 `preTrader`s 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).

IssueThe `_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 `preTrader`s 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).

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

StatusUnresolved

Low

Single Address for Development and Marketing Fees

L-01Both `_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).

IssueBoth `_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).

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

StatusUnresolved

Info

Redundant SafeMath Usage

I-01The 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).

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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

GovernanceLow8/10

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

UpgradesLow9/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

30.7% in top 10

20.6% in wallets10.1% in contracts

Effective Concentration24.6%

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

$741.9K across 2 pairs

Uniswap v2WETHanalysed$741.6K 0x3511…14b1WETH$235

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 Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

5 addresses

Deployer

0xad86…36e7

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.

What Raised This Score

5 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeRouter, Token

Audit History

1 audit on record

Aug 307

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

Is 4CHAN Safe?

Security Findings

Renounced Ownership Bricks Critical Functions

Irreversible High Tax Rates and Centralized Parameters

Aggressive Anti-Bot Mechanism May Block Legitimate Users

Single Address for Development and Marketing Fees

Redundant SafeMath Usage

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 4CHAN?