Honeypot, rug-pull and ownership checks

Is wojak a Scam?

WOJAK

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

30/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance6/10 Upgrades9/10 Checks passed5 of 5 Findings1 Critical · 2 High · 2 Medium · 1 Low6

SummaryAI Copilot

Read the full analysis

What raised the score

Top-10 concentration > 30%
1 Critical finding(s) from audit
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Top-10 concentration > 30% (40.5% total → 37.5% effective; 35.5% in EOAs, 5.1% in contracts — moderate)
1 Critical finding(s) from audit
2 High finding(s) from audit
2 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

Our automated scanner reviewed wojak (WOJAK) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

40.5%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking5.1%
Walletsanonymous holders, free to sell35.5%
Everyone elsethe rest of the supply59.5%

Effective concentrationwhat the score reads37.5%

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$1.02M 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$1.02MShare of depth99.8%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Unlocked LP held by

0xdbbf…b03d0xac74…d8a30xeb0c…493f0x1f2f…f387

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

Security Findings

1 Critical2 High2 Medium1 Low

Critical

Extreme Centralization and Honeypot Risk

The contract grants the owner extensive control over critical token parameters, including the ability to set arbitrary transaction and wallet limits, adjust transfer fees (tax and liquidity fees) up to 100%, mint new tokens, pause trading, and exclude specific addresses from all tokenomics. This level of control allows the owner to manipulate the token's economy at will, potentially creating a honeypot scenario where users can buy but are prevented from selling or face prohibitive fees. This impacts 7.3 Access Control, 7.4 Economic, 7.5 Governance, and 7.8 Operations.C-01

Issue

Fix

Implement a multi-signature wallet for ownership, introduce time-locks for critical parameter changes, or decentralize control through a governance mechanism. Clearly communicate the extent of owner privileges to users and consider capping fees and limits at reasonable, non-exploitable levels.

Status

Unresolved

High

Lack of Minimum Amount Out in Swaps

The _swapAndLiquify function, as well as swapTokensForEth and addLiquidity, use Uniswap's swapExactTokensForETHSupportingFeeOnTransferTokens without specifying a minAmountOut parameter. This omission exposes the swap operation to sandwich attacks and significant slippage, especially during periods of high volatility or low liquidity, potentially leading to a loss of value for the tokens being swapped. This impacts 7.2 Code Security and 7.4 Economic.H-01

Issue

Fix

Implement a minAmountOut parameter in all swap functions to protect against excessive slippage and front-running. This value should ideally be calculated based on current market conditions or a user-defined tolerance.

Status

Unresolved

High

Owner Can Drain Liquidity Pool Tokens

The _swapAndLiquify function adds liquidity to the Uniswap pair, and the resulting LP tokens are sent to the contract itself. The rescueERC20 function, callable by the owner, allows the owner to withdraw any ERC20 tokens held by the contract. This means the owner can withdraw the LP tokens, effectively removing liquidity from the pool and potentially rug-pulling investors. This impacts 7.3 Access Control and 7.4 Economic.H-02

Issue

Fix

Implement a mechanism to burn LP tokens or send them to a locked, unspendable address (e.g., the zero address) to ensure liquidity remains permanently locked. If LP tokens are intended to be managed, a transparent and secure governance or time-lock mechanism should be in place for their withdrawal.

Status

Unresolved

Medium

Configurable Router and Pair Addresses

The owner can update the uniswapV2Router and uniswapV2Pair addresses via updateUniswapV2Router and updateUniswapV2Pair functions. While this offers flexibility, a malicious or compromised owner could redirect token swaps and liquidity additions to a fraudulent router or pair contract, leading to loss of funds or manipulation of the token's market. This impacts 7.3 Access Control and 7.6 External.M-01

Issue

Fix

Consider making these addresses immutable after deployment or implementing a time-lock for changes to critical external contract addresses. If flexibility is required, ensure robust monitoring and transparency around such changes.

Status

Unresolved

Medium

Unchecked Return Values of External Calls

The _swapAndLiquify and swapTokensForEth functions call IERC20(token).approve(address(this), type(uint256).max) without checking the boolean return value. While many ERC20 tokens revert on failure, some older or non-standard implementations might return false instead. Ignoring this return value could lead to a false assumption that the approval succeeded, potentially causing subsequent operations to fail unexpectedly. This impacts 7.2 Code Security.M-02

Issue

Fix

Always check the boolean return value of external ERC20 calls, especially transfer, transferFrom, and approve, to ensure the operation was successful. For example, require(IERC20(token).approve(...), "ERC20: approve failed");.

Status

Unresolved

Low

Lack of Events for Critical Parameter Changes

Several owner-controlled functions that modify critical parameters, such as setMaxTxAmount, setMaxWalletAmount, setSwapAndLiquifyThreshold, setNumTokensSellToAddToLiquidity, setRouterAddress, setPairAddress, setTradingOpen, excludeFromMaxTx, includeInMaxTx, excludeFromMaxWallet, includeInMaxWallet, excludeFromSwap, includeInSwap, do not emit events. This makes it difficult for off-chain monitoring tools and users to track changes to the token's behavior and parameters, reducing transparency. This impacts 7.8 Operations.L-01

Issue

Fix

Emit explicit events for all functions that modify critical contract state variables. This enhances transparency and allows for easier monitoring and auditing of contract behavior.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The Wojak Token contract is an ERC-20 token implementation with extensive owner-controlled features, including configurable transaction fees, maximum transaction/wallet limits, minting capabilities, and a liquidity generation mechanism. While leveraging OpenZeppelin's secure base contracts, the high degree of centralization introduces significant economic and operational risks. The owner possesses the ability to drastically alter tokenomics, potentially leading to a honeypot scenario or liquidity rug-pull. Technical aspects like unchecked external call return values and lack of slippage protection in swaps also present vulnerabilities.

Technical6/10Medium risk

The contract utilizes OpenZeppelin's battle-tested ERC20 and Ownable implementations, providing a solid foundation (7.1 Architecture, 7.2 Code Security). A reentrancy guard (inSwapAndLiquify) is correctly implemented for the swap and liquify mechanism, mitigating a common vulnerability (7.2 Code Security). However, the contract lacks minimum amount out parameters in its swap functions, exposing users to high slippage and front-running (7.2 Code Security). Additionally, some external ERC20 calls do not check their return values, which could lead to unexpected behavior (7.2 Code Security).

Governance6/10Medium risk

The contract exhibits extreme centralization, with the owner having unilateral control over critical token parameters (7.3 Access Control, 7.5 Governance). The owner can set arbitrary transaction fees (tax and liquidity fees up to 100%), define maximum transaction and wallet amounts, mint new tokens, pause trading, and exclude any address from all tokenomics (7.4 Economic). This level of control creates a significant honeypot risk, where the owner could prevent users from selling or drain liquidity (7.4 Economic). The owner can also rescue LP tokens from the contract, enabling a rug-pull (7.4 Economic).

Upgrades9/10Low risk

The contract is not designed with an upgrade mechanism (7.7 Upgrades). This means its logic is immutable after deployment, eliminating upgrade-related risks but also preventing future bug fixes or feature enhancements without a new deployment.

Final RecommendationWhat to do about this score

Given the extreme centralization, it is crucial for the project to clearly communicate the extent of owner privileges to all potential users and investors.

Consider implementing a multi-signature wallet for ownership and introducing time-locks for critical parameter changes to reduce single-point-of-failure risks and increase transparency. For all swap operations, implement a minAmountOut parameter to protect against slippage and front-running. Ensure that all external ERC20 calls check their return values to prevent unexpected failures. For enhanced transparency and off-chain monitoring, emit events for all state-changing functions, especially those modifying critical token parameters.

Contract & Record

1 audit on record

TypeToken

NetworkEthereum

Token age3mo

Contract0x8de3…31ef

Deployer0x93aa…6362

Badge for your website

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

Sep 4, 202630Low
Jul 23, 202632Low

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

Frequently Asked Questions

What is the WOJAK contract address?

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