Quantum Audit Logo
Launch App

Early-stage security check — honeypot & rug-pull analysis

Is Mirex a Scam?

MRXBNB 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 · 1 audit on recordNew Launch · 20h old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades6/10Checks passed5 of 7Findings1 High · 3 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The MRXToken contract implements an ERC-20 token with custom tokenomics features including transaction fees, maximum transaction/holding limits, cooldowns, and a swap-back mechanism for collected fees.

Read the full analysis
What raised the score
  • Ownership not renounced
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • LP claimed locked but only 0.0% actually locked
  • Token age < 24h
  • 1 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • LP claimed locked but only 0.0% actually locked
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High finding(s) from audit
  • 3 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

Early-stage analysis. This token has limited on-chain history (20h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax1.5% / 3.5%

Holders

as of audit · Sep 4, 2026
11.0%Wallets88.8%Everyone else
11.0%88.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
11.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking0.2%
  • Walletsanonymous holders, free to sell11.0%
  • Everyone elsethe rest of the supply88.8%
Effective concentrationwhat the score reads11.0%
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$104.8K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$104.8KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xe755…df04

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

Security Findings

1 High3 Medium1 Low1 Info
High

High Centralization of Control in Admin Role

The admin role, controlled by a single address, possesses extensive authority over critical contract parameters and functionalities. This includes the ability to set buy/sell fees, max transaction/holding limits, cooldown timers, enable/disable trading, enable/disable the swap-back mechanism, and exempt any address from these rules. This high degree of centralization introduces a single point of failure and potential for malicious action or compromise.H-01

Issue

The admin role, controlled by a single address, possesses extensive authority over critical contract parameters and functionalities. This includes the ability to set buy/sell fees, max transaction/holding limits, cooldown timers, enable/disable trading, enable/disable the swap-back mechanism, and exempt any address from these rules. This high degree of centralization introduces a single point of failure and potential for malicious action or compromise.

Fix

Implement a multi-signature wallet for the admin role to distribute control and reduce the risk of a single point of compromise or malicious action. Consider a time-lock for critical parameter changes to allow for community review and reaction time.

Status

Unresolved

Medium

Inconsistent Use of USDT in Swap-Back Mechanism

The constructor takes a _usdt address, which is used in the calculateFee function's getAmountsOut path for fee valuation. However, the actual swap-back mechanism in _swapTokensForEth uses router.swapExactTokensForETHSupportingFeeOnTransferTokens with a path of [address(this), router.WETH()], effectively swapping MRX for WETH, not USDT. This inconsistency could lead to discrepancies between the calculated fee value (based on USDT) and the actual value obtained from the swap (based on WETH), impacting project treasury if price ratios diverge.M-01

Issue

The constructor takes a _usdt address, which is used in the calculateFee function's getAmountsOut path for fee valuation. However, the actual swap-back mechanism in _swapTokensForEth uses router.swapExactTokensForETHSupportingFeeOnTransferTokens with a path of [address(this), router.WETH()], effectively swapping MRX for WETH, not USDT. This inconsistency could lead to discrepancies between the calculated fee value (based on USDT) and the actual value obtained from the swap (based on WETH), impacting project treasury if price ratios diverge.

Fix

Clarify the intended stablecoin for fee conversion. If USDT is intended, modify _swapTokensForEth to swap for USDT. If WETH is intended, ensure calculateFee accurately reflects WETH-based valuation or remove the _usdt parameter if it's not used for actual swaps.

Status

Unresolved

Medium

Lack of Slippage Protection in Swap-Back

The _swapTokensForEth function calls router.swapExactTokensForETHSupportingFeeOnTransferTokens without specifying an amountOutMin parameter. This means the swap operation has no slippage protection. In scenarios of low liquidity, high market volatility, or large swap amounts, the transaction could suffer from significant slippage, resulting in fewer ETH being received than expected for the collected fees, directly impacting the project's treasury.M-02

Issue

The _swapTokensForEth function calls router.swapExactTokensForETHSupportingFeeOnTransferTokens without specifying an amountOutMin parameter. This means the swap operation has no slippage protection. In scenarios of low liquidity, high market volatility, or large swap amounts, the transaction could suffer from significant slippage, resulting in fewer ETH being received than expected for the collected fees, directly impacting the project's treasury.

Fix

Implement slippage protection by calculating a reasonable amountOutMin based on current market conditions and a predefined acceptable slippage tolerance. This can be achieved by querying getAmountsOut with the desired path and applying a slippage factor.

Status

Unresolved

Medium

Potential for Abuse of Exclusion Lists

The admin role has the ability to add or remove any address from isFeeExempt, _isExcludedFromMaxTxn, _isExcludedMaxHolding, and isExcludedFromCooldown lists. While intended for legitimate operational purposes, this power could be abused to grant unfair advantages to specific users or wallets, bypassing tokenomics rules and potentially leading to market manipulation or a perception of unfairness.M-03

Issue

The admin role has the ability to add or remove any address from isFeeExempt, _isExcludedFromMaxTxn, _isExcludedMaxHolding, and isExcludedFromCooldown lists. While intended for legitimate operational purposes, this power could be abused to grant unfair advantages to specific users or wallets, bypassing tokenomics rules and potentially leading to market manipulation or a perception of unfairness.

Fix

Clearly document the intended use cases for these exclusion lists. Consider implementing a governance mechanism or a multi-signature approval process for adding/removing addresses from these critical lists, especially for non-protocol-owned addresses.

Status

Unresolved

Low

Fixed feeDenominator

The feeDenominator is hardcoded to 100_00 (10000), implying fees are calculated in basis points. While this is a common practice, the contract does not provide a mechanism to change this denominator. If future tokenomics require a different fee granularity (e.g., per mille), this would necessitate a new contract deployment.L-01

Issue

The feeDenominator is hardcoded to 100_00 (10000), implying fees are calculated in basis points. While this is a common practice, the contract does not provide a mechanism to change this denominator. If future tokenomics require a different fee granularity (e.g., per mille), this would necessitate a new contract deployment.

Fix

If flexibility in fee granularity is desired, consider making feeDenominator a configurable parameter by the admin, similar to other fee-related settings. Otherwise, ensure the current basis point system is sufficient for all foreseeable tokenomics.

Status

Unresolved

Info

Unused usdt parameter in _swapTokensForEth context

The usdt address is passed in the constructor and used in calculateFee for getAmountsOut path. However, the _swapTokensForEth function, which performs the actual swap, hardcodes the path to [address(this), router.WETH()], effectively ignoring the usdt address for the swap. This creates a discrepancy where the fee calculation might be based on a USDT path, but the actual swap is for WETH.I-01

Issue

The usdt address is passed in the constructor and used in calculateFee for getAmountsOut path. However, the _swapTokensForEth function, which performs the actual swap, hardcodes the path to [address(this), router.WETH()], effectively ignoring the usdt address for the swap. This creates a discrepancy where the fee calculation might be based on a USDT path, but the actual swap is for WETH.

Fix

Review the intended functionality. If the goal is to swap for USDT, the _swapTokensForEth function should use usdt in its path and call the appropriate router function. If the goal is to swap for WETH, the usdt parameter's role in calculateFee should be re-evaluated for consistency.

Status

Unresolved

Analysis

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

The MRXToken contract implements an ERC-20 token with custom tokenomics features including transaction fees, maximum transaction/holding limits, cooldowns, and a swap-back mechanism for collected fees. The contract utilizes OpenZeppelin's AccessControl for role-based permissions and SafeMath for arithmetic safety. While core ERC-20 functionality appears sound, the audit identified a high degree of centralization in the admin role, inconsistencies in the fee swap mechanism, and a lack of slippage protection, leading to a Medium overall risk level.

Technical6/10Medium risk

The contract demonstrates good practices such as using SafeMath for arithmetic operations and implementing a reentrancy guard for external swap calls (7.2 Code Security). However, the swap-back mechanism exhibits an inconsistency where fee calculation uses a USDT path, but the actual swap is for WETH, potentially leading to unexpected economic outcomes (7.2 Code Security, 7.4 Economic). Additionally, the swap-back lacks explicit slippage protection, which could result in value loss during volatile market conditions (7.2 Code Security). The overall architecture is a standard ERC-20 with added tokenomics features (7.1 Architecture).

Governance1/10High risk

The contract design grants significant power to a single admin address, which can unilaterally modify critical tokenomics parameters such as fees, transaction/holding limits, cooldowns, and trading status (7.3 Access Control, 7.4 Economic). This high centralization introduces a single point of failure and potential for manipulation or abuse. The ability to exempt specific addresses from fees, limits, and cooldowns further exacerbates this centralization risk (7.3 Access Control, 7.4 Economic). While initial token allocations are clearly defined, the control over these wallets by the admin also contributes to the centralized governance model (7.5 Governance).

Upgrades6/10Medium risk

The MRXToken contract is implemented as a standard, non-upgradeable contract. Therefore, there are no specific upgrade-related risks or complexities to consider (7.7 Upgrades). Any future changes to the contract logic would require a new deployment and migration of assets.

Final RecommendationWhat to do about this score

To mitigate the identified risks, it is strongly recommended to implement a multi-signature wallet for the admin role to decentralize control and enhance security.

Critical parameter changes should ideally be subject to a time-lock mechanism to provide transparency and allow for community review. Furthermore, the fee swap mechanism should be reviewed for consistency, ensuring that the intended asset (USDT or WETH) is used for both fee calculation and actual swaps, and robust slippage protection should be added to safeguard against value loss during swaps.

Contract & Record

1 audit on record
TypeMRXToken
NetworkBNB Chain
Token age20h
Contract0xa605…d89e
Deployer0xf0d1…e5f0
Badge for your website
Mirex 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 2, 202671High

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

Related Audits

6 more on the recordAll audits
AnomaXAN · BNB Chain71HighPlasmaXPL · BNB Chain71HighCoinMarketCap 20 Index DTFCMC20 · BNB Chain71HighKGSTBNB Chain71HighPancakeSwap TokenCAKE · BNB Chain72HighSubsquidSQD · BNB Chain72High

Would You Like a More Detailed Audit of Mirex?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

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