Is Mame Inu (MAME) a Scam? Security Analysis

Security Findings

1 Crit2 High1 Med1 Low1 Info

Critical

Lack of Slippage Protection in Token Swaps

C-01The `_swapTokensForEth` function, responsible for converting collected fees into BNB, calls `router.swapExactTokensForETHSupportingFeeOnTransferTokens` without specifying an `amountOutMin` parameter. This omission means the swap can execute with arbitrary slippage, potentially resulting in a significant loss of value for the marketing and team wallets, especially during periods of high volatility or low liquidity. An attacker could front-run these transactions to cause extreme slippage and drain value.

IssueThe `_swapTokensForEth` function, responsible for converting collected fees into BNB, calls `router.swapExactTokensForETHSupportingFeeOnTransferTokens` without specifying an `amountOutMin` parameter. This omission means the swap can execute with arbitrary slippage, potentially resulting in a significant loss of value for the marketing and team wallets, especially during periods of high volatility or low liquidity. An attacker could front-run these transactions to cause extreme slippage and drain value.

FixImplement a minimum output amount (`amountOutMin`) for `swapExactTokensForETHSupportingFeeOnTransferTokens` to protect against excessive slippage and front-running attacks. This value should be carefully calculated based on current market conditions or a reasonable tolerance, potentially configurable by the owner.

StatusUnresolved

High

High Centralization of Owner Privileges

H-01The contract grants extensive control to the `owner` address, including the ability to set marketing and team wallets, change swap thresholds, enable/disable swaps, exclude/include addresses from fees and rewards, open trading, and rescue any foreign ERC20 tokens or stuck BNB. This high degree of centralization introduces a single point of failure and relies heavily on the owner's integrity and security. A compromised owner key could lead to significant fund loss or manipulation of the token's economic parameters (7.3 Access Control, 7.5 Governance).

IssueThe contract grants extensive control to the `owner` address, including the ability to set marketing and team wallets, change swap thresholds, enable/disable swaps, exclude/include addresses from fees and rewards, open trading, and rescue any foreign ERC20 tokens or stuck BNB. This high degree of centralization introduces a single point of failure and relies heavily on the owner's integrity and security. A compromised owner key could lead to significant fund loss or manipulation of the token's economic parameters (7.3 Access Control, 7.5 Governance).

FixConsider implementing a multi-signature wallet for critical owner functions or introducing a time-lock mechanism for sensitive parameter changes to reduce the risk associated with a single point of control and enhance governance transparency.

StatusUnresolved

High

Dynamic and High Initial Transaction Taxes

H-02The token implements a dynamic fee structure where transaction taxes are extremely high during the initial phase (`PHASE1_START_BPS` is 90% for the first 300 seconds). While this might be intended as an anti-bot measure, such high taxes can severely deter legitimate trading, create significant price impact, and lead to user confusion or unexpected losses for early buyers who are unaware of the rapidly decreasing tax (7.4 Economic).

IssueThe token implements a dynamic fee structure where transaction taxes are extremely high during the initial phase (`PHASE1_START_BPS` is 90% for the first 300 seconds). While this might be intended as an anti-bot measure, such high taxes can severely deter legitimate trading, create significant price impact, and lead to user confusion or unexpected losses for early buyers who are unaware of the rapidly decreasing tax (7.4 Economic).

FixClearly communicate the dynamic fee structure and its implications to users through official documentation and interfaces. Evaluate if such an extreme initial tax is truly necessary, as it can negatively impact legitimate trading and user perception. Ensure the fee calculation logic is robust and thoroughly tested.

StatusUnresolved

Medium

Potential for Manipulation of Excluded Addresses

M-01The `owner` can exclude any address from fees (`_isExcludedFromFee`) and rewards (`_isExcludedFromReward`). While there's a `MAX_EXCLUDED` limit of 30 for the reward exclusion list, the fee exclusion list has no such explicit limit on its size. This power, if misused, could allow the owner to grant preferential treatment to certain addresses or manipulate the fee collection mechanism, potentially impacting the token's economics or creating an unfair advantage (7.3 Access Control, 7.4 Economic).

IssueThe `owner` can exclude any address from fees (`_isExcludedFromFee`) and rewards (`_isExcludedFromReward`). While there's a `MAX_EXCLUDED` limit of 30 for the reward exclusion list, the fee exclusion list has no such explicit limit on its size. This power, if misused, could allow the owner to grant preferential treatment to certain addresses or manipulate the fee collection mechanism, potentially impacting the token's economics or creating an unfair advantage (7.3 Access Control, 7.4 Economic).

FixReview the necessity of excluding addresses from fees without a clear limit. If exclusions are critical, consider implementing a more transparent and auditable process for managing these lists, or further restricting the owner's ability to arbitrarily add/remove addresses.

StatusUnresolved

Low

Unused `_tFeeTotal` Variable

L-01The `_tFeeTotal` variable is incremented in the `_reflectFee` function, but its value is only exposed via the `totalFees()` view function and does not appear to be used in any core logic that affects token supply, reflection calculations, or fee distribution. This variable consumes storage without a clear functional purpose within the token's mechanics (7.2 Code Security).

IssueThe `_tFeeTotal` variable is incremented in the `_reflectFee` function, but its value is only exposed via the `totalFees()` view function and does not appear to be used in any core logic that affects token supply, reflection calculations, or fee distribution. This variable consumes storage without a clear functional purpose within the token's mechanics (7.2 Code Security).

FixEither remove the `_tFeeTotal` variable if it serves no functional purpose, or clarify its intended use and integrate it into the contract's logic if it is meant to play a role in the tokenomics.

StatusUnresolved

Info

Hardcoded Router and Factory Addresses

I-01The contract hardcodes the addresses for the PancakeSwap V2 Router (`ROUTER`) and Factory (`FACTORY`). While these are standard addresses on BSC, hardcoding them means the contract cannot adapt to potential future changes in the DEX infrastructure (e.g., if PancakeSwap upgrades its router to a new address or if the project decides to migrate to a different DEX) (7.6 External).

IssueThe contract hardcodes the addresses for the PancakeSwap V2 Router (`ROUTER`) and Factory (`FACTORY`). While these are standard addresses on BSC, hardcoding them means the contract cannot adapt to potential future changes in the DEX infrastructure (e.g., if PancakeSwap upgrades its router to a new address or if the project decides to migrate to a different DEX) (7.6 External).

FixFor future flexibility, consider making the router and factory addresses configurable by the owner (e.g., via an `onlyOwner` function) during deployment or post-deployment, while ensuring proper validation of new addresses.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good practices such as using Solidity 0.8.25 for checked arithmetic and implementing a reentrancy guard (`_inSwap`) for critical swap operations. The ERC-20 standard implementation, including reflection mechanics, appears generally sound. However, a critical vulnerability exists in the `_swapTokensForEth` function, which lacks slippage protection (`amountOutMin`) when interacting with the DEX router, exposing collected fees to potential significant value loss. Additionally, the `_tFeeTotal` variable is unused, indicating minor code inefficiency.

GovernanceMedium5/10

The MAMEINU token incorporates a dynamic fee structure with extremely high initial transaction taxes (up to 90%), designed to deter bots but potentially impacting legitimate users. The contract's economic model relies heavily on the `owner` address, which possesses extensive control over critical parameters such as fee exclusions, swap thresholds, and wallet addresses. This high degree of centralization introduces significant governance risk, as a compromised owner key could lead to severe economic manipulation or fund loss.

UpgradesLow8/10

The MAMEINU contract is not designed with an upgrade mechanism, meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy implementation vulnerabilities or administrative key compromises affecting future contract behavior. However, it also means that any discovered vulnerabilities or desired feature enhancements cannot be patched or implemented without a complete redeployment and migration.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

59.5% in top 10

44.7% in wallets14.8% in contracts

Effective Concentration50.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

$558.2K across 3 pairs

Pancakeswap v2WBNBanalysed$558.2K Pancakeswap v3USDT$19

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

1 addresses

Deployer

0x0d16…b708

What Raised This Score

5 factors

Top-10 concentration > 50% (59.5% total → 50.6% effective; 44.7% in EOAs, 14.8% in contracts — heavy)
1 Critical finding(s) from audit
2 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

Is Mame Inu a Scam?

Security Findings

Lack of Slippage Protection in Token Swaps

High Centralization of Owner Privileges

Dynamic and High Initial Transaction Taxes

Potential for Manipulation of Excluded Addresses

Unused `_tFeeTotal` Variable

Hardcoded Router and Factory Addresses

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Mame Inu?