Quantum Audit Logo

Is Banana For Scale Safe?

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

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

Banana For Scale BANANAS31
0x3d4f…a760
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$1.53M
Liquidity
$4.20M
Price
$0.008154
Token Age
1y
Top 10 Holders
31.3%

Security Findings

1 High1 Med1 Low1 Info
High

Irreversible Transfer Mode Transition

H-01The `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.
IssueThe `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.
FixIf 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.
StatusUnresolved
Medium

Initial Restricted Transfer Mode Requires Owner Action

M-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Low

Fixed Supply and No Public Mint/Burn Functions

L-01The `_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.
IssueThe `_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.
FixIf 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.
StatusUnresolved
Info

Renouncing Ownership Permanently Locks Transfer Mode

I-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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

GovernanceLow8/10

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

UpgradesLow10/10

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.

Security Checklist

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

Holder Composition

31.3% in top 10
26.3% in wallets5.0% in contracts
Effective Concentration28.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

$4.20M across 11 pairs
Pancakeswap v3WBNBanalysed$4.20M100.0%Squadswap v2WBNB$3610.0%Pancakeswap v2SEKA$670.0%Pancakeswap v3USDT$600.0%Pancakeswap v2ESP$170.0%Pancakeswap v2Subject 3$170.0%
Show 3 more pairsShow less
Pancakeswap v2WBNB$140.0%Pancakeswap v2SHIB$100.0%Pancakeswap v2USDT$50.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 Burned47.7%
LP Locked47.7% · Dead Address
Top-1 Unlocked Holder51.9%
Top-3 Unlocked52.3%

Key Addresses

9 addresses
Deployer
0xf167…7703
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.

What Raised This Score

5 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

Related Audits

6 more on the record
BroccoliLow RiskMomentum (MNTM)Low RiskTagger (TAG)Low RiskSmart Solve Token (SST)Low RiskMarscoin (MARS)Low RiskWorld of Dypians (WOD)Low Risk

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