Quantum Audit Logo

Is Yee Token Safe?

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

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

Yee Token YEE
0x9ac9…77fd
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The YEE token contract implements a standard ERC-20 interface with several custom features including dynamic transaction fees, anti-MEV mechanisms, a max wallet limit, and an automated swapback function. The contract utilizes the Ownable pattern for administrative control. Key risks identified include the use of `amountOutMin = 0` in Uniswap swaps, which exposes funds to significant slippage or MEV attacks, and an unreliable anti-MEV mechanism based on `extcodesize`. High transaction fees and centralized control also present economic and governance risks.

2 High2 Medium1 Low3 Informational
Volume 24h
$40.5K
Liquidity
$450.8K
Price
$0.003565
Token Age
3y
Top 10 Holders
18.5%

Security Findings

2 High2 Med1 Low3 Info
High

Lack of Slippage Protection in Swapback Function

H-01The `swapback` function calls `uniswapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens` with `amountOutMin` set to `0`. This means the contract accepts any amount of ETH in return for the tokens, regardless of how unfavorable the exchange rate is. This vulnerability can be exploited by front-running bots or MEV (Maximal Extractable Value) attacks, leading to significant losses of value during the swap process. (7.2 Code Security, 7.4 Economic)
IssueThe `swapback` function calls `uniswapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens` with `amountOutMin` set to `0`. This means the contract accepts any amount of ETH in return for the tokens, regardless of how unfavorable the exchange rate is. This vulnerability can be exploited by front-running bots or MEV (Maximal Extractable Value) attacks, leading to significant losses of value during the swap process. (7.2 Code Security, 7.4 Economic)
FixImplement a reasonable `amountOutMin` value in the `swapExactTokensForETHSupportingFeeOnTransferTokens` call within the `swapback` function. This value should be calculated based on the expected output amount and a tolerable slippage percentage, protecting the contract from unfavorable trades. Consider using Chainlink price feeds or a time-weighted average price (TWAP) oracle to determine a safe minimum output amount.
StatusUnresolved
High

Unreliable Anti-MEV Mechanism Using extcodesize

H-02The `ensureOneHuman` function, part of the anti-MEV mechanism, attempts to identify contracts using `extcodesize`. This method is unreliable because `extcodesize` returns 0 during a contract's constructor execution, allowing a malicious contract to bypass the check. Attackers can deploy contracts that interact with the token within their constructor, appearing as an EOA (Externally Owned Account) and circumventing the anti-MEV logic. (7.2 Code Security)
IssueThe `ensureOneHuman` function, part of the anti-MEV mechanism, attempts to identify contracts using `extcodesize`. This method is unreliable because `extcodesize` returns 0 during a contract's constructor execution, allowing a malicious contract to bypass the check. Attackers can deploy contracts that interact with the token within their constructor, appearing as an EOA (Externally Owned Account) and circumventing the anti-MEV logic. (7.2 Code Security)
FixRelying on `extcodesize` for security-critical decisions is a known anti-pattern. Re-evaluate the anti-MEV strategy. Consider alternative, more robust methods for bot detection or implement a time-based delay for new liquidity providers to mitigate front-running without relying on `extcodesize`.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The contract uses the `Ownable` pattern, granting the deployer (owner) significant control over critical contract functionalities. While specific setter functions are not fully provided, the presence of `tradingOpen`, `antiMEV`, `_blocked`, and `isContractExempt` flags suggests that the owner can enable/disable trading, anti-MEV, block addresses, or exempt addresses from certain rules. This centralization (7.3 Access Control, 7.5 Governance) introduces a single point of failure and a high degree of trust in the owner's actions, which could be a risk if the owner's private key is compromised or acts maliciously. (7.5 Governance)
IssueThe contract uses the `Ownable` pattern, granting the deployer (owner) significant control over critical contract functionalities. While specific setter functions are not fully provided, the presence of `tradingOpen`, `antiMEV`, `_blocked`, and `isContractExempt` flags suggests that the owner can enable/disable trading, anti-MEV, block addresses, or exempt addresses from certain rules. This centralization (7.3 Access Control, 7.5 Governance) introduces a single point of failure and a high degree of trust in the owner's actions, which could be a risk if the owner's private key is compromised or acts maliciously. (7.5 Governance)
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) as the contract owner to distribute control and require multiple approvals for sensitive operations. Alternatively, implement a time-locked governance mechanism for critical changes to provide transparency and allow the community to react to potentially malicious actions.
StatusUnresolved
Medium

High and Dynamic Transaction Fees

M-02The contract implements high transaction fees (25% buy tax, 25% sell tax) and an even higher sniper tax (49%) for early trades or blocked addresses. While intended to manage tokenomics, such high and dynamic fees can significantly deter legitimate trading, reduce liquidity, and make the token less attractive for long-term holders. It can also lead to unpredictable price movements and user frustration. (7.4 Economic)
IssueThe contract implements high transaction fees (25% buy tax, 25% sell tax) and an even higher sniper tax (49%) for early trades or blocked addresses. While intended to manage tokenomics, such high and dynamic fees can significantly deter legitimate trading, reduce liquidity, and make the token less attractive for long-term holders. It can also lead to unpredictable price movements and user frustration. (7.4 Economic)
FixEvaluate the long-term impact of such high transaction fees on token adoption and liquidity. Consider reducing the fees to a more sustainable level or implementing a more gradual fee reduction mechanism over time. Clearly communicate the fee structure and its purpose to users.
StatusUnresolved
Low

Unused State Variables

L-01The contract declares state variables `preLaunch` and `tradeCooldown` but they are not used anywhere in the provided code snippet. Unused variables can indicate incomplete features, dead code, or potential for future functionality that was not fully implemented. While not a direct security vulnerability, it adds unnecessary complexity and consumes gas for storage. (7.2 Code Security)
IssueThe contract declares state variables `preLaunch` and `tradeCooldown` but they are not used anywhere in the provided code snippet. Unused variables can indicate incomplete features, dead code, or potential for future functionality that was not fully implemented. While not a direct security vulnerability, it adds unnecessary complexity and consumes gas for storage. (7.2 Code Security)
FixRemove unused state variables to reduce contract size, optimize gas consumption, and improve code clarity. If these variables are intended for future features, ensure they are properly documented or implemented.
StatusUnresolved
Info

Hardcoded Uniswap Router Address

I-01The Uniswap V2 Router address (0x7a25…488D) is hardcoded as an `immutable` constant. While this is common for well-established protocols, it means the contract cannot adapt if Uniswap's router address changes or if the project wishes to migrate to a different DEX or a newer version of Uniswap. (7.6 External)
IssueThe Uniswap V2 Router address () is hardcoded as an `immutable` constant. While this is common for well-established protocols, it means the contract cannot adapt if Uniswap's router address changes or if the project wishes to migrate to a different DEX or a newer version of Uniswap. (7.6 External)
FixFor future flexibility, consider making critical external contract addresses configurable by the owner, perhaps through an `onlyOwner` setter function. This allows for adaptability to ecosystem changes without requiring a full contract redeployment. However, for immutable addresses like Uniswap V2, this is often an acceptable design choice.
StatusUnresolved
Info

Large Allowance in Swapback Function

I-02The `swapback` function approves the Uniswap router for `_totalSupply` (1 billion tokens) if the current allowance is insufficient. While this is a common pattern to avoid repeated approvals, it grants the router a very large, potentially unlimited, allowance. If the Uniswap router contract were to be compromised, it could theoretically drain the entire token balance held by the YEE contract. (7.2 Code Security)
IssueThe `swapback` function approves the Uniswap router for `_totalSupply` (1 billion tokens) if the current allowance is insufficient. While this is a common pattern to avoid repeated approvals, it grants the router a very large, potentially unlimited, allowance. If the Uniswap router contract were to be compromised, it could theoretically drain the entire token balance held by the YEE contract. (7.2 Code Security)
FixConsider approving only the exact `tokenAmount` required for the swap, or a more conservative, yet sufficient, amount. While the risk of the Uniswap router being compromised is low, minimizing exposure is a good security practice. Alternatively, ensure the `swapback` function's logic is robust against reentrancy or unexpected external calls.
StatusUnresolved
Info

Renounce Ownership Functionality

I-03The `renounceOwnership` function is present, allowing the owner to transfer ownership to the zero address. If this function is called, the contract will become unowned, and all `onlyOwner` functions will become permanently inaccessible. This could lead to a 'rug pull' scenario if critical parameters are not set correctly before renouncing, or if future maintenance is required. (7.3 Access Control, 7.5 Governance)
IssueThe `renounceOwnership` function is present, allowing the owner to transfer ownership to the zero address. If this function is called, the contract will become unowned, and all `onlyOwner` functions will become permanently inaccessible. This could lead to a 'rug pull' scenario if critical parameters are not set correctly before renouncing, or if future maintenance is required. (7.3 Access Control, 7.5 Governance)
FixEnsure all critical configurations are finalized and immutable before considering renouncing ownership. If renouncing ownership is part of the project's decentralization roadmap, clearly communicate the implications to the community. Consider transferring ownership to a community-governed multi-signature wallet or a DAO instead of renouncing it entirely.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The YEE token contract (7.1 Architecture) extends ERC-20 with custom transfer logic, including dynamic fees, anti-MEV measures, and an automated swapback to ETH. The `_transfer` function handles complex conditional logic for fees and wallet limits. A significant concern (7.2 Code Security) is the `swapback` function's use of `amountOutMin = 0` when interacting with Uniswap, which can lead to severe losses due to slippage or front-running. Additionally, the anti-MEV mechanism (7.2 Code Security) relies on `extcodesize` to identify contracts, which is an unreliable method and can be bypassed. The contract also contains unused state variables (7.2 Code Security) like `preLaunch` and `tradeCooldown` which could indicate incomplete features or dead code.

GovernanceLow8/10

The contract employs the Ownable pattern (7.3 Access Control), granting the deployer significant control over critical parameters such as `tradingOpen`, `antiMEV`, and potentially fee structures (though setters are not provided in the snippet). This centralization (7.5 Governance) introduces a single point of failure and trust. Economically (7.4 Economic), the token features high transaction taxes (25% buy/sell, 49% sniper tax) and a max wallet amount, which can impact liquidity and deter legitimate trading. The `YEETreasury` address is hardcoded, directing all swapback ETH to a single, immutable destination (7.8 Operations).

UpgradesLow10/10

The YEE token contract is not designed with an upgradeability pattern (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 removes the flexibility to fix bugs or introduce new features without a new deployment and migration.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

18.5% in top 10
8.2% in wallets10.4% in contracts
Effective Concentration12.3%

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

$454.0K across 4 pairs
Uniswap v2WETHanalysed$450.8K99.3%Uniswap v3WETH$2.5K0.6%Uniswap v4WBTC$5820.1%Uniswap v4PNDC$860.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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

4 addresses
Deployer
0xa428…58f3
Unlocked LP Held By
0xb3ac…68a00x1f2f…f3870x87c0…36d6

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

What Raised This Score

3 factors
  • 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

Related Audits

6 more on the record
AsteroidLow RiskAmerica Pac (PAC)Low RiskJerry The Turtle By Matt Furie (JYAI)Low RiskNon-Playable Coin (NPC)Low RiskPikachuLow RiskpepeCoinLow Risk

Would You Like a More Detailed Audit of Yee Token?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit