Quantum Audit Logo
Launch App

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

Is Yee Token Safe?

YEEEthereum
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
Technical8/10Governance8/10Upgrades10/10Checks passed5 of 5Findings2 High · 2 Medium · 1 Low · 3 Info8
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.

Read the full analysis
What raised the score
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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
10.4%Contracts8.2%Wallets81.5%Everyone else
10.4%8.2%81.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
18.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking10.4%
  • Walletsanonymous holders, free to sell8.2%
  • Everyone elsethe rest of the supply81.5%
Effective concentrationwhat the score reads12.3%
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$454.0K across 4 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$450.8KShare of depth99.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
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.

Security Findings

2 High2 Medium1 Low3 Info
High

Lack of Slippage Protection in Swapback Function

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

Issue

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

Fix

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

Status

Unresolved

High

Unreliable Anti-MEV Mechanism Using extcodesize

The 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)H-02

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Control by Owner

The 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)M-01

Issue

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

Fix

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

Status

Unresolved

Medium

High and Dynamic Transaction Fees

The 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)M-02

Issue

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

Fix

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

Status

Unresolved

Low

Unused State Variables

The 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)L-01

Issue

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

Fix

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

Status

Unresolved

Info

Hardcoded Uniswap Router Address

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

Issue

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

Fix

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

Status

Unresolved

Info

Large Allowance in Swapback Function

The 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)I-02

Issue

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

Fix

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

Status

Unresolved

Info

Renounce Ownership Functionality

The 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)I-03

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance8/10Low risk

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

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical security vulnerabilities related to the swapback function's amountOutMin parameter to prevent potential financial losses from MEV or high slippage.

The anti-MEV mechanism relying on extcodesize should be re-evaluated and replaced with more robust, decentralized, or proven solutions. Furthermore, consider implementing multi-signature control for the owner functions to mitigate centralization risks and enhance operational security. Review the economic parameters, especially the high transaction fees, to ensure they align with the project's long-term sustainability and user adoption goals.

Contract & Record

1 audit on record
TypeVault, Router, Token
NetworkEthereum
Token age3y
Contract0x9ac9…77fd
Deployer0xa428…58f3
Badge for your website
Yee Token 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 13, 20260Low

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

Frequently Asked Questions

What is the YEE contract address?

The Yee Token (YEE) contract on Ethereum is 0x9ac9468e7e3e1d194080827226b45d0b892c77fd. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Yee Token a scam?

Quantum Audit's risk score for Yee Token is 0/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. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is YEE liquidity locked?

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

Who holds YEE?

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

Related Audits

6 more on the recordAll audits
AsteroidEthereum0LowAmerica PacPAC · Ethereum0LowJerry The Turtle By Matt FurieJYAI · Ethereum0LowNon-Playable CoinNPC · Ethereum0LowPikachuEthereum0LowpepeCoinEthereum0Low

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 Is this your token? Publish your own audit on this page