Quantum Audit Logo

Is mubarak Safe?

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

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

mubarak MUBARAK
0x5c85…46f6
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers a custom ERC20 token contract with added transfer control mechanisms. The contract implements standard ERC20 functionalities and introduces a `_mode` variable to restrict transfers. Key findings include an irreversible state change in the transfer mode mechanism and significant centralization of control over token transfers by the owner.

1 High1 Medium1 Low
Volume 24h
$7.41M
Liquidity
$2.35M
Price
$0.03003
Token Age
1y
Top 10 Holders
86.6%

Security Findings

1 High1 Med1 Low
High

Irreversible Transfer Mode Change

H-01The `setMode` function contains a condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This logic prevents the owner from changing the transfer mode once it has been set to `MODE_NORMAL`. If the owner ever sets the token to `MODE_NORMAL`, they permanently lose the ability to re-enable `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`, even in emergency situations. This represents an irreversible loss of a critical control mechanism (7.3 Access Control, 7.4 Economic).
IssueThe `setMode` function contains a condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This logic prevents the owner from changing the transfer mode once it has been set to `MODE_NORMAL`. If the owner ever sets the token to `MODE_NORMAL`, they permanently lose the ability to re-enable `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`, even in emergency situations. This represents an irreversible loss of a critical control mechanism (7.3 Access Control, 7.4 Economic).
FixRemove the `if (_mode != MODE_NORMAL)` condition from the `setMode` function if the intention is for the owner to always retain full control over the transfer mode. Alternatively, if the irreversible transition is intended, ensure this design choice is clearly documented and understood by all stakeholders, acknowledging the permanent loss of control.
StatusUnresolved
Medium

Centralized Control over Token Transfers

M-01The `owner()` address has complete control over the token's transferability through the `setMode` function and the `_beforeTokenTransfer` hook. The owner can pause all transfers (`MODE_TRANSFER_RESTRICTED`) or restrict them to only involve the owner (`MODE_TRANSFER_CONTROLLED`). This introduces a single point of failure, as a compromised owner key could lead to censorship or manipulation of token transfers (7.3 Access Control, 7.5 Governance).
IssueThe `owner()` address has complete control over the token's transferability through the `setMode` function and the `_beforeTokenTransfer` hook. The owner can pause all transfers (`MODE_TRANSFER_RESTRICTED`) or restrict them to only involve the owner (`MODE_TRANSFER_CONTROLLED`). This introduces a single point of failure, as a compromised owner key could lead to censorship or manipulation of token transfers (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet for the `owner` role or introducing a time-lock mechanism for critical functions like `setMode`. This would distribute control and provide a delay for users to react to potentially malicious actions, enhancing security and decentralization.
StatusUnresolved
Low

Initial Restricted Transfer State

L-01Upon deployment, the token's `_mode` is initialized to `MODE_TRANSFER_RESTRICTED`. This means that immediately after deployment, no transfers of the token are possible until the owner explicitly calls `setMode` to change it to `MODE_NORMAL` or `MODE_TRANSFER_CONTROLLED`. This requires an immediate operational step from the owner for the token to become functional for general use (7.8 Operations).
IssueUpon deployment, the token's `_mode` is initialized to `MODE_TRANSFER_RESTRICTED`. This means that immediately after deployment, no transfers of the token are possible until the owner explicitly calls `setMode` to change it to `MODE_NORMAL` or `MODE_TRANSFER_CONTROLLED`. This requires an immediate operational step from the owner for the token to become functional for general use (7.8 Operations).
FixEnsure that the operational team is aware of this initial state and has a clear plan for calling `setMode` to the desired initial operational mode shortly after deployment. Document this step in the deployment checklist.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract utilizes standard OpenZeppelin patterns for ERC20 and Ownable functionalities, demonstrating a solid foundation (7.1 Architecture, 7.2 Code Security). The use of `unchecked` blocks is appropriately guarded by `require` statements, mitigating common integer overflow/underflow risks. However, the custom `_beforeTokenTransfer` logic introduces specific access control and state management complexities that require careful attention (7.3 Access Control).

GovernanceMedium4/10

The token's economic model is heavily reliant on the owner's control over transferability (7.4 Economic). The `setMode` function allows the owner to permanently disable transfer restrictions by setting the mode to `MODE_NORMAL`, without the ability to re-enable them. This introduces a significant, irreversible change in the token's core utility. The owner also has centralized control over all transfers, which could lead to censorship or manipulation (7.5 Governance).

UpgradesLow10/10

The contract is not designed with upgradeability in mind (7.7 Upgrades). It is a standard implementation contract without proxy patterns. Therefore, any identified issues or desired feature changes would require a new deployment and migration, which is a common characteristic for non-upgradeable tokens.

Security Checklist

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

Holder Composition

86.6% in top 10
82.6% in wallets3.9% in contracts
Effective Concentration84.2%

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

$2.36M across 13 pairs
Pancakeswap v3WBNBanalysed$2.35M99.8%Pancakeswap v3WBNB$4.5K0.2%Pancakeswap v2WBNB$890.0%Pancakeswap v2USDT$450.0%Pancakeswap v3USDT$440.0%Pancakeswap v2Subject 3$310.0%
Show 4 more pairsShow less
Pancakeswap v2$D.O.G.E$70.0%Pancakeswap v2Taichi$10.0%Pancakeswap v2burn$10.0%Pancakeswap v2GOUT$00.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 Locked33.0% · GoPlus SafeToken Locker
Top-1 Unlocked Holder62.2%
Top-3 Unlocked66.8%

Key Addresses

10 addresses
Deployer
0xeabf…642a
Unlocked LP Held By
0x5036…6a200xa532…943f0x2a0b…23f10xe9a4…062b0x09c1…1c9d0xf58b…88d30x355c…fe6c0x6440…5f570xaab0…51d0

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

What Raised This Score

5 factors
  • Top-10 concentration > 70% (86.6% total → 84.2% effective; 82.6% in EOAs, 3.9% in contracts — extreme)
  • LP top1 unlocked holder = 62.2% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 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

Related Audits

6 more on the record
Alaya Governance Token (AGT)Medium RiskCheese Head (CHEESE)Medium RiskAsterMedium RiskTutorial (TUT)Medium RiskMYXMedium RiskBluwhale AI (BLUAI)Medium Risk

Would You Like a More Detailed Audit of mubarak?

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

Get Detailed Audit