Quantum Audit Logo

Is Binance bibi Safe?

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

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

Binance bibi BIBI
0x0b6d…4444
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FourERC20 contract implements a standard ERC-20 token using OpenZeppelin's battle-tested patterns. It adheres to best practices for token functionality and includes mitigations for common ERC-20 allowance issues. The contract is designed as a base implementation, requiring a derived contract to define specific supply management (minting/burning) mechanisms. Overall, the contract exhibits high code quality and low inherent risk.

1 Low2 Informational
Volume 24h
$157.8K
Liquidity
$155.3K
Price
$0.0009897
Token Age
1mo
Top 10 Holders
84.8%

Security Findings

1 Low2 Info
Low

Standard ERC-20 `approve` Front-Running Risk (Mitigated)

L-01The standard ERC-20 `approve` function is susceptible to a front-running attack where an attacker can sandwich a user's `approve` transaction to steal tokens. If a user approves an amount, then approves a different amount, an attacker can front-run the second approval, transfer the original approved amount, and then allow the second approval to go through, effectively getting two transfers for one approval. This contract provides `increaseAllowance` and `decreaseAllowance` functions which mitigate this risk by allowing atomic adjustments to allowances.
IssueThe standard ERC-20 `approve` function is susceptible to a front-running attack where an attacker can sandwich a user's `approve` transaction to steal tokens. If a user approves an amount, then approves a different amount, an attacker can front-run the second approval, transfer the original approved amount, and then allow the second approval to go through, effectively getting two transfers for one approval. This contract provides `increaseAllowance` and `decreaseAllowance` functions which mitigate this risk by allowing atomic adjustments to allowances.
FixEducate users to prefer `increaseAllowance` and `decreaseAllowance` over directly calling `approve` when adjusting existing allowances. If `approve` must be used to change an existing allowance, users should first set the allowance to zero and wait for that transaction to confirm before setting the new allowance.
StatusUnresolved
Info

Base Contract Requires Extension for Supply Management

I-01The `FourERC20` contract provides the core ERC-20 logic but does not include public functions for minting or burning tokens. These functionalities are exposed only via internal `_mint` and `_burn` functions. This design choice means that a derived contract must be implemented to provide the actual supply mechanism (e.g., a minter role, a fixed supply, or a burn function).
IssueThe `FourERC20` contract provides the core ERC-20 logic but does not include public functions for minting or burning tokens. These functionalities are exposed only via internal `_mint` and `_burn` functions. This design choice means that a derived contract must be implemented to provide the actual supply mechanism (e.g., a minter role, a fixed supply, or a burn function).
FixThis is an intentional design pattern for a base ERC-20 implementation. Ensure that any contract inheriting from `FourERC20` implements its supply management (minting/burning) functions with appropriate access control and economic considerations.
StatusUnresolved
Info

Potential Re-initialization if Used as Proxy Implementation

I-02The `_init` function is used to set `_name` and `_symbol`. While this contract is not explicitly a proxy implementation, if it were to be used as one in the future without proper initializer safeguards (e.g., an `initializer` modifier or an `_initialized` flag), the `_init` function could be called multiple times by malicious actors, potentially altering the token's name and symbol.
IssueThe `_init` function is used to set `_name` and `_symbol`. While this contract is not explicitly a proxy implementation, if it were to be used as one in the future without proper initializer safeguards (e.g., an `initializer` modifier or an `_initialized` flag), the `_init` function could be called multiple times by malicious actors, potentially altering the token's name and symbol.
FixIf this contract is ever intended to be used as an implementation contract for an upgradeable proxy, ensure that the `_init` function is protected by an `initializer` modifier (e.g., from OpenZeppelin's `Initializable` contract) to prevent multiple invocations and re-initialization attacks.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical implementation of the FourERC20 token is robust, leveraging OpenZeppelin's well-audited ERC-20 base (7.1 Architecture). It correctly handles token transfers and allowance mechanisms (7.2 Code Security), including `increaseAllowance` and `decreaseAllowance` to mitigate front-running risks associated with `approve`. The use of Solidity 0.8.0+ inherently protects against integer overflows/underflows, and the `unchecked` block is used safely. The contract lacks specific access control (7.3 Access Control) beyond standard ERC-20 roles, as it's intended as a base implementation.

GovernanceLow9/10

The FourERC20 contract is a foundational ERC-20 token and does not implement complex economic models or governance mechanisms (7.5 Governance). Its economic stability (7.4 Economic) is therefore dependent on the broader protocol it integrates with, rather than internal logic. There are no specific parameters or fees managed within this contract that could introduce economic vulnerabilities. External dependencies (7.6 External) are limited to the well-vetted OpenZeppelin contracts.

UpgradesLow10/10

The FourERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades) and does not contain any proxy-related logic. It is a standard, non-upgradeable implementation. If future upgradeability is desired, a separate proxy pattern (e.g., UUPS or Transparent) would need to be implemented, with careful consideration for initializer functions to prevent re-initialization.

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

84.8% in top 10
4.6% in wallets80.2% in contracts
Effective Concentration36.7%

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

$159.7K across 2 pairs
Pancakeswap v2WBNBanalysed$155.3K97.2%Uniswap v2fBOMB$4.4K2.8%

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 Burned99.8% · ≈ permanent lock
LP Locked99.8% · Null Address

Key Addresses

2 addresses
Deployer
0x36b8…9464
Unlocked LP Held By
0x0ed9…9706

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

What Raised This Score

2 factors
  • Top-10 concentration > 30% (84.8% total → 36.7% effective; 4.6% in EOAs, 80.2% in contracts — moderate)
  • 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
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

Would You Like a More Detailed Audit of Binance bibi?

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

Get Detailed Audit