Quantum Audit Logo
Launch App

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

Is Banana For Scale Safe?

BANANAS31BNB 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 record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance8/10Upgrades10/10Checks passed5 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The Token contract implements a standard ERC20 token with an Ownable pattern and a unique transfer mode mechanism.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • LP top1 unlocked holder = 51.9%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (31.3% total → 28.3% effective; 26.3% in EOAs, 5.0% in contracts — mild)
  • LP top1 unlocked holder = 51.9% (independent LP — depth risk)
  • 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

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
5.0%Contracts26.3%Wallets68.7%Everyone else
5.0%26.3%Wallets68.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
31.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.0%
  • Walletsanonymous holders, free to sell26.3%
  • Everyone elsethe rest of the supply68.7%
Effective concentrationwhat the score reads28.3%
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$4.20M across 11 pairs
Show 3 more pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$4.20MShare of depth100.0%
LP Burned47.7%
LP Locked47.7% · Dead Address
Top-1 Unlocked Holder51.9%
Top-3 Unlocked52.3%
Unlocked LP held by
0x5036…6a200xaded…46b60x59eb…d05f0xfe73…147a0xcc5e…b66e0x3cfe…27810xd5e4…2d600x2bc2…bb9d

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

Security Findings

1 High1 Medium1 Low1 Info
High

Irreversible Transfer Mode Transition

The setMode function includes a condition if (_mode != MODE_NORMAL) { _mode = v; }. This logic prevents the owner from changing the transfer mode back from MODE_NORMAL (0) to MODE_TRANSFER_RESTRICTED (1) or MODE_TRANSFER_CONTROLLED (2) once MODE_NORMAL has been set. This means that once transfers are fully enabled, the ability to re-introduce restrictions (e.g., for security incidents, regulatory changes, or specific operational needs) is permanently lost. This design choice significantly limits future governance flexibility and could pose a risk if the protocol ever needs to pause or control transfers again.H-01

Issue

The setMode function includes a condition if (_mode != MODE_NORMAL) { _mode = v; }. This logic prevents the owner from changing the transfer mode back from MODE_NORMAL (0) to MODE_TRANSFER_RESTRICTED (1) or MODE_TRANSFER_CONTROLLED (2) once MODE_NORMAL has been set. This means that once transfers are fully enabled, the ability to re-introduce restrictions (e.g., for security incidents, regulatory changes, or specific operational needs) is permanently lost. This design choice significantly limits future governance flexibility and could pose a risk if the protocol ever needs to pause or control transfers again.

Fix

If the intention is to allow the owner to re-introduce transfer restrictions, remove the if (_mode != MODE_NORMAL) condition from the setMode function. This would allow the owner to freely switch between all defined modes. Alternatively, if the irreversible transition is intentional, ensure this design choice is clearly documented and understood by all stakeholders, acknowledging the permanent loss of control over transfer restrictions.

Status

Unresolved

Medium

Initial Restricted Transfer Mode Requires Owner Action

The token contract is initialized with _mode = MODE_TRANSFER_RESTRICTED in its constructor. This means that immediately after deployment, all token transfers will revert with the message 'Token: Transfer is restricted'. The token will remain unusable for transfers until the owner explicitly calls setMode(MODE_NORMAL) to enable full transferability. This introduces an essential post-deployment operational step that, if missed or delayed, could lead to user confusion and hinder the token's initial utility.M-01

Issue

The token contract is initialized with _mode = MODE_TRANSFER_RESTRICTED in its constructor. This means that immediately after deployment, all token transfers will revert with the message 'Token: Transfer is restricted'. The token will remain unusable for transfers until the owner explicitly calls setMode(MODE_NORMAL) to enable full transferability. This introduces an essential post-deployment operational step that, if missed or delayed, could lead to user confusion and hinder the token's initial utility.

Fix

Ensure that the deployment process includes a clear step for the owner to call setMode(MODE_NORMAL) immediately after deployment to enable token transfers. Provide clear documentation for users and operators regarding this initial restricted state and the necessary owner action. Alternatively, consider initializing the token in MODE_NORMAL if immediate transferability is desired, or provide a time-locked mechanism for the mode change.

Status

Unresolved

Low

Fixed Supply and No Public Mint/Burn Functions

The _mint function is only invoked once during the contract's constructor to mint the initial totalSupply to the owner. There are no public or owner-controlled functions (e.g., mint(), burn()) provided in the Token contract to allow for additional token creation or destruction after deployment. This design results in a fixed total supply for the token, which might be an intentional design choice but limits flexibility for future tokenomics adjustments, such as inflation, deflation, or treasury management.L-01

Issue

The _mint function is only invoked once during the contract's constructor to mint the initial totalSupply to the owner. There are no public or owner-controlled functions (e.g., mint(), burn()) provided in the Token contract to allow for additional token creation or destruction after deployment. This design results in a fixed total supply for the token, which might be an intentional design choice but limits flexibility for future tokenomics adjustments, such as inflation, deflation, or treasury management.

Fix

If a fixed supply is the intended design, no changes are necessary, but this should be explicitly documented. If future flexibility for supply management (minting/burning) is desired, consider adding owner-controlled functions to call the internal _mint and _burn methods, potentially with rate limits or other safeguards.

Status

Unresolved

Info

Renouncing Ownership Permanently Locks Transfer Mode

The contract inherits renounceOwnership() from Ownable. If the current owner calls this function, the contract's ownership will be transferred to the zero address, making the setMode function (which is onlyOwner) inaccessible. Given the irreversible nature of setting MODE_NORMAL (as described in H-01), renouncing ownership would permanently lock the token's transfer mode to its state at the time of renunciation. If MODE_NORMAL was set, it can never be restricted again; if it was RESTRICTED or CONTROLLED and MODE_NORMAL was never set, it could remain in that state indefinitely.I-01

Issue

The contract inherits renounceOwnership() from Ownable. If the current owner calls this function, the contract's ownership will be transferred to the zero address, making the setMode function (which is onlyOwner) inaccessible. Given the irreversible nature of setting MODE_NORMAL (as described in H-01), renouncing ownership would permanently lock the token's transfer mode to its state at the time of renunciation. If MODE_NORMAL was set, it can never be restricted again; if it was RESTRICTED or CONTROLLED and MODE_NORMAL was never set, it could remain in that state indefinitely.

Fix

Ensure that the implications of renounceOwnership() are fully understood in the context of the setMode function's logic. If ownership is to be renounced, the owner should carefully consider the desired final transfer mode before doing so. Document this interaction clearly for future reference.

Status

Unresolved

Analysis

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

The Token contract implements a standard ERC20 token with an Ownable pattern and a unique transfer mode mechanism. The contract initializes in a restricted transfer state, requiring owner action to enable transfers. A key design choice is the irreversible transition to a fully normal transfer mode, which prevents future re-introduction of transfer restrictions. This audit identified a High severity issue related to this irreversible mode transition, alongside other Medium and Low severity findings concerning operational aspects and design choices.

Technical9/10Low risk

The contract leverages OpenZeppelin's ERC20 and Ownable patterns, providing a solid foundation for token functionality and access control (7.1 Architecture). The use of unchecked blocks is consistent with gas optimization practices in secure contexts (7.2 Code Security). However, the setMode function's logic, specifically the if (_mode != MODE_NORMAL) condition, introduces an irreversible state transition, preventing the owner from re-enabling transfer restrictions once MODE_NORMAL is set (7.3 Access Control).

Governance8/10Low risk

The token's economic model features a fixed supply after initial minting, with no further minting or burning capabilities (7.4 Economic). The initial MODE_TRANSFER_RESTRICTED requires the owner to explicitly enable transfers post-deployment, which is an important operational consideration (7.8 Operations). The irreversible nature of the MODE_NORMAL setting means the token's transferability governance is a one-way decision, impacting future flexibility and potentially leading to a loss of control over token flow (7.5 Governance).

Upgrades10/10Low risk

The contract is not designed with upgradeability patterns (e.g., proxies) (7.7 Upgrades). This means its logic is immutable once deployed, which simplifies the architecture by removing upgrade-related risks but requires careful consideration of all functionalities, especially the irreversible setMode logic, as no future modifications are possible.

Final RecommendationWhat to do about this score

Review the intended long-term governance model for token transfers, particularly the irreversible nature of setting MODE_NORMAL.

If future flexibility to re-introduce transfer restrictions is desired, modify the setMode function to allow bidirectional transitions. Ensure clear communication to token holders regarding the initial restricted transfer state and the owner's role in enabling transfers. Consider the implications of renounceOwnership in conjunction with the setMode logic, as renouncing ownership would permanently lock the current transfer mode.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x3d4f…a760
Deployer0xf167…7703
Badge for your website
Banana For Scale 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, 20267Low
  2. Aug 11, 20260Low

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

Related Audits

6 more on the recordAll audits
Mame InuMAME · BNB Chain7LowBroccoliBNB Chain8LowMomentumMNTM · BNB Chain8LowHachiko InuHACHIKO · BNB Chain8LowEGL1BNB Chain8LowUSDABNB Chain8Low

Would You Like a More Detailed Audit of Banana For Scale?

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

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