Is Mubarakah Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med

Critical

Irreversible Loss of Transfer Control Mechanism

C-01The `setMode` function contains a conditional check `if (_mode != MODE_NORMAL)` before allowing the mode to be updated. This means that once the token's `_mode` is set to `MODE_NORMAL` (0), the condition `_mode != MODE_NORMAL` becomes false, and the `_mode` variable can never be changed again. This permanently removes the owner's ability to re-enable transfer restrictions (e.g., `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`) in case of an emergency, exploit, or necessary protocol upgrade, leading to a critical loss of control over token transfers.

IssueThe `setMode` function contains a conditional check `if (_mode != MODE_NORMAL)` before allowing the mode to be updated. This means that once the token's `_mode` is set to `MODE_NORMAL` (0), the condition `_mode != MODE_NORMAL` becomes false, and the `_mode` variable can never be changed again. This permanently removes the owner's ability to re-enable transfer restrictions (e.g., `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`) in case of an emergency, exploit, or necessary protocol upgrade, leading to a critical loss of control over token transfers.

FixRemove the conditional check `if (_mode != MODE_NORMAL)` from the `setMode` function to allow the owner to freely change the token's mode between all defined states at any time. This ensures that emergency controls remain available throughout the token's lifecycle.

StatusUnresolved

High

Initial Transfer Restriction Requires Manual Activation

H-01The token's constructor initializes `_mode` to `MODE_TRANSFER_RESTRICTED` (1). In this mode, all transfers are reverted with the message 'Token: Transfer is restricted'. This means the token is non-functional for transfers immediately after deployment until the owner explicitly calls `setMode(MODE_NORMAL)`. If the owner fails to perform this action, or if the owner's key is compromised before this action, the tokens could remain permanently locked and untransferable.

IssueThe token's constructor initializes `_mode` to `MODE_TRANSFER_RESTRICTED` (1). In this mode, all transfers are reverted with the message 'Token: Transfer is restricted'. This means the token is non-functional for transfers immediately after deployment until the owner explicitly calls `setMode(MODE_NORMAL)`. If the owner fails to perform this action, or if the owner's key is compromised before this action, the tokens could remain permanently locked and untransferable.

FixEnsure robust operational procedures are in place for the initial deployment and activation of the token. Consider adding a time-lock or a multi-signature requirement for the initial `setMode` call to `MODE_NORMAL` to prevent hasty or unauthorized activation. Clearly document this critical post-deployment step.

StatusUnresolved

Medium

Centralized Control by Owner

M-01The contract inherits `Ownable`, granting a single external address (the `owner`) exclusive control over critical functions such as `setMode` and `transferOwnership`. This centralization introduces a single point of failure; if the owner's private key is compromised, lost, or becomes inaccessible, the protocol's functionality could be severely impacted or halted.

IssueThe contract inherits `Ownable`, granting a single external address (the `owner`) exclusive control over critical functions such as `setMode` and `transferOwnership`. This centralization introduces a single point of failure; if the owner's private key is compromised, lost, or becomes inaccessible, the protocol's functionality could be severely impacted or halted.

FixConsider migrating ownership to a multi-signature wallet (e.g., Gnosis Safe) or a decentralized autonomous organization (DAO) to distribute control and reduce the risk associated with a single point of failure. If a multi-sig is not feasible, ensure the owner's private key is secured with the highest industry standards.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract implements a standard ERC20 token with custom transfer modes (7.1 Architecture). The `_beforeTokenTransfer` hook correctly enforces these modes. The `ERC20` base contract uses `unchecked` blocks appropriately, guarded by `require` statements, mitigating integer overflow/underflow risks (7.2 Code Security). However, the `setMode` function contains a critical flaw: once the token's mode is set to `MODE_NORMAL`, it cannot be changed back to a restricted state, permanently removing a key control mechanism (7.3 Access Control).

GovernanceMedium6/10

The token's economic model relies on centralized control by an `owner` address (7.5 Governance). The initial state `MODE_TRANSFER_RESTRICTED` means the token is untransferable until the owner explicitly calls `setMode(MODE_NORMAL)`, which is an operational risk (7.8 Operations). The most significant economic risk stems from the `setMode` function's design, which permanently removes the ability to re-enable transfer restrictions once `MODE_NORMAL` is activated. This means the owner loses the ability to pause or control transfers in an emergency, posing a severe economic risk (7.4 Economic).

UpgradesLow8/10

The contract is not designed with upgradeability patterns (e.7.7 Upgrades). This means its logic is immutable after deployment. While not a direct upgrade vulnerability, the permanent nature of the `setMode` function's effect (once `MODE_NORMAL` is set) means that the critical transfer control mechanism cannot be re-introduced or modified without a full redeployment.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

86.5% in top 10

47.9% in wallets38.6% in contracts

Effective Concentration63.3%

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

$105.3K across 6 pairs

Pancakeswap v3WBNBanalysed$96.6K Pancakeswap v3USDT$5.1K UniswapUSDT$3.6K Pancakeswap v2Subject 3$26 UniswapUSDT$0 Pancakeswap v2WBNB$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 Locked99.8% · GoPlus SafeToken Locker

Top-1 Unlocked Holder0.2%

Key Addresses

2 addresses

Deployer

0x05b0…3636

Unlocked LP Held By

0xa7a2…0c23

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

What Raised This Score

4 factors

Top-10 concentration > 50% (86.5% total → 63.3% effective; 47.9% in EOAs, 38.6% in contracts — heavy)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium 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

Not Signed In

Is Mubarakah Safe?

Security Findings

Irreversible Loss of Transfer Control Mechanism

Initial Transfer Restriction Requires Manual Activation

Centralized Control by Owner

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Mubarakah?