Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Mame Inu a Scam?

MAMEBNB Chain
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance5/10Upgrades8/10Checks passed5 of 5Findings1 Critical · 2 High · 1 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The MAMEINU token contract implements an ERC-20 standard with reflection mechanics, dynamic transaction fees, and an automated swap-and-distribute mechanism for collected fees.

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

Our automated scanner reviewed Mame Inu (MAME) on BNB Chain. 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
14.8%Contracts44.7%Wallets40.5%Everyone else
14.8%Contracts44.7%Wallets40.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
59.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking14.8%
  • Walletsanonymous holders, free to sell44.7%
  • Everyone elsethe rest of the supply40.5%
Effective concentrationwhat the score reads50.6%
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$558.2K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$558.2KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical2 High1 Medium1 Low1 Info
Critical

Lack of Slippage Protection in Token Swaps

The _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.C-01

Issue

The _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.

Fix

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

Status

Unresolved

High

High Centralization of Owner Privileges

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

Issue

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

Fix

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

Status

Unresolved

High

Dynamic and High Initial Transaction Taxes

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

Issue

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

Fix

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

Status

Unresolved

Medium

Potential for Manipulation of Excluded Addresses

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

Issue

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

Fix

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

Status

Unresolved

Low

Unused _tFeeTotal Variable

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

Issue

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

Fix

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

Status

Unresolved

Info

Hardcoded Router and Factory Addresses

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

The MAMEINU token contract implements an ERC-20 standard with reflection mechanics, dynamic transaction fees, and an automated swap-and-distribute mechanism for collected fees. While the contract utilizes modern Solidity features and includes reentrancy protection, a critical vulnerability was identified regarding the lack of slippage protection in its token swap function. Additionally, the contract exhibits high centralization of control under the owner, and its dynamic fee structure includes extremely high initial taxes, posing significant economic and governance risks.

Technical6/10Medium risk

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.

Governance5/10Medium risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

It is critical to address the lack of slippage protection in the token swap function to prevent significant value loss during fee processing.

Implementing a minimum output amount for swaps is essential. Furthermore, consider decentralizing control over critical contract parameters by adopting multi-signature wallets or time-lock mechanisms for sensitive operations to mitigate the risks associated with a single point of failure. Clearly communicate the dynamic fee structure to users to manage expectations and avoid confusion.

Contract & Record

2 audits on record
TypeStaking, Router, Token
NetworkBNB Chain
Token age1mo
Contract0xe92f…2302
Deployer0x0d16…b708
Badge for your website
Mame Inu 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. Sep 4, 202638Medium
  2. Jul 27, 202630Low
  3. Jul 26, 202667High

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

Frequently Asked Questions

Is Mame Inu a scam?

Based on automated analysis, Mame Inu scores 67/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Mame Inu safe to buy?

Our scanner flagged a risk score of 67/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Mame Inu been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
OLAXBTAIO · BNB Chain38MediumLUNABNB Chain38Medium中国人能飞火箭中国人能飞 · BNB Chain38MediumBitway TokenBTW · BNB Chain39MediumMarsCoinBNB Chain39MediumCZ'S DOGBROCCOLI · BNB Chain39Medium

Would You Like a More Detailed Audit of Mame Inu?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page