Quantum Audit Logo

Is Build On BNB Safe?

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

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

Build On BNB BOB
0x5136…560e
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The Build On BNB (BOB) token contract is an ERC-20 implementation with custom tokenomics including taxes, max transaction limits, and an anti-bot transfer delay. The audit identified a critical vulnerability related to uninitialized trading parameters combined with renounced ownership, which could render the token untradable. High-severity issues include the absence of a `receive()` function, potentially locking ETH. Economic risks stem from fixed high initial taxes and an immutable tax wallet. The contract is not upgradeable, making any post-deployment fixes impossible without redeployment.

1 Critical1 High2 Medium1 Low1 Informational
Volume 24h
$104.0K
Liquidity
$1.29M
Price
$0.0000000171
Token Age
1y
Top 10 Holders
78.4%

Security Findings

1 Crit1 High2 Med1 Low1 Info
Critical

Unmanageable Trading & Liquidity Setup After Ownership Renunciation

C-01The contract relies on `uniswapV2Router`, `uniswapV2Pair`, `tradingOpen`, and `swapEnabled` for its core trading and liquidity functions. These variables are not initialized in the provided constructor. If their setter functions are `onlyOwner` and ownership has been renounced (as indicated by `ownership_renounced: true`), these critical parameters can never be set. This would render the token untradable and prevent liquidity provision, effectively bricking the token's functionality.
IssueThe contract relies on `uniswapV2Router`, `uniswapV2Pair`, `tradingOpen`, and `swapEnabled` for its core trading and liquidity functions. These variables are not initialized in the provided constructor. If their setter functions are `onlyOwner` and ownership has been renounced (as indicated by `ownership_renounced: true`), these critical parameters can never be set. This would render the token untradable and prevent liquidity provision, effectively bricking the token's functionality.
FixEnsure all critical trading and liquidity parameters (`uniswapV2Router`, `uniswapV2Pair`, `tradingOpen`, `swapEnabled`) are initialized within the constructor or through a dedicated, one-time initialization function that is called immediately after deployment and before ownership is renounced.
StatusUnresolved
High

Missing `receive()`/`fallback()` Function

H-01The contract is designed to interact with Uniswap for swapping tokens to ETH and potentially adding liquidity. If the contract itself is the recipient of ETH during these operations (e.g., `swapExactTokensForETHSupportingFeeOnTransferTokens` sends ETH to the contract), a `receive()` or `fallback()` function is required to accept the ETH. Without such a function, incoming ETH will be locked in the router or revert the transaction, leading to loss of funds or operational failure.
IssueThe contract is designed to interact with Uniswap for swapping tokens to ETH and potentially adding liquidity. If the contract itself is the recipient of ETH during these operations (e.g., `swapExactTokensForETHSupportingFeeOnTransferTokens` sends ETH to the contract), a `receive()` or `fallback()` function is required to accept the ETH. Without such a function, incoming ETH will be locked in the router or revert the transaction, leading to loss of funds or operational failure.
FixImplement a `receive() external payable` function to allow the contract to accept incoming ETH. This is crucial for the proper functioning of the swap and liquidity mechanisms.
StatusUnresolved
Medium

Fixed and High Initial Taxes

M-01The contract implements high initial buy/sell taxes (22%). While these taxes are designed to reduce to 0% over time, the initial high rate can deter early adoption and trading. With ownership renounced, these tax parameters are immutable, meaning the initial high tax phase cannot be adjusted or removed by an owner, regardless of market conditions or community feedback.
IssueThe contract implements high initial buy/sell taxes (22%). While these taxes are designed to reduce to 0% over time, the initial high rate can deter early adoption and trading. With ownership renounced, these tax parameters are immutable, meaning the initial high tax phase cannot be adjusted or removed by an owner, regardless of market conditions or community feedback.
FixConsider if the initial tax rates are appropriate for the project's long-term goals, especially given their immutability. If flexibility is desired, an owner-controlled mechanism to adjust these parameters would be necessary, but this conflicts with renounced ownership. Ensure the community is fully aware of the fixed tax structure.
StatusUnresolved
Medium

Fixed Tax Wallet Address

M-02The `_taxWallet` address is set in the constructor and cannot be changed after deployment. If this address becomes compromised, inaccessible, or the intended recipient changes (e.g., due to a multi-sig upgrade or a new treasury address), all collected taxes will be sent to an unrecoverable or incorrect address. With ownership renounced, this address cannot be updated.
IssueThe `_taxWallet` address is set in the constructor and cannot be changed after deployment. If this address becomes compromised, inaccessible, or the intended recipient changes (e.g., due to a multi-sig upgrade or a new treasury address), all collected taxes will be sent to an unrecoverable or incorrect address. With ownership renounced, this address cannot be updated.
FixIf the project requires flexibility for the tax wallet, consider implementing an owner-controlled function to update the `_taxWallet` address. However, this would require ownership not to be renounced. If ownership remains renounced, ensure the `_taxWallet` is a highly secure, multi-signature controlled address that is intended for permanent use.
StatusUnresolved
Low

`tx.origin` Usage for Anti-Bot Measure

L-01The `_holderLastTransferTimestamp` mechanism uses `tx.origin` to enforce a transfer delay, intended as an anti-bot measure. While `tx.origin` is generally discouraged in smart contracts due to potential phishing attack vectors if used for access control, in this specific context, it's used for an anti-bot measure. However, it means that if a contract calls `transfer`, the `tx.origin` will be the EOA that initiated the transaction, not the contract itself, which might have unintended side effects for complex interactions.
IssueThe `_holderLastTransferTimestamp` mechanism uses `tx.origin` to enforce a transfer delay, intended as an anti-bot measure. While `tx.origin` is generally discouraged in smart contracts due to potential phishing attack vectors if used for access control, in this specific context, it's used for an anti-bot measure. However, it means that if a contract calls `transfer`, the `tx.origin` will be the EOA that initiated the transaction, not the contract itself, which might have unintended side effects for complex interactions.
FixWhile the risk is low in this specific implementation, it's generally recommended to use `msg.sender` for all address-related checks to avoid `tx.origin` related complexities and potential misunderstandings. If the anti-bot logic specifically requires `tx.origin`, ensure its implications are fully understood and documented.
StatusUnresolved
Info

Redundant SafeMath Library

I-01The contract uses the `SafeMath` library for arithmetic operations. However, Solidity version `^0.8.8` includes built-in overflow and underflow checks by default, making the `SafeMath` library redundant. This adds unnecessary bytecode to the contract and slightly increases deployment and transaction gas costs without providing additional security benefits.
IssueThe contract uses the `SafeMath` library for arithmetic operations. However, Solidity version `^0.8.8` includes built-in overflow and underflow checks by default, making the `SafeMath` library redundant. This adds unnecessary bytecode to the contract and slightly increases deployment and transaction gas costs without providing additional security benefits.
FixRemove the `SafeMath` library and its `using SafeMath for uint256;` directive. Rely on Solidity's native overflow/underflow protection for `uint256` operations in version 0.8.0 and higher.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract utilizes `SafeMath` for arithmetic, although it's redundant in Solidity 0.8+. A critical vulnerability exists where core trading and liquidity parameters (`uniswapV2Router`, `uniswapV2Pair`, `tradingOpen`, `swapEnabled`) are uninitialized in the constructor and, if their setters are `onlyOwner`, cannot be set after ownership renunciation (7.2 Code Security, C-01). Additionally, the contract lacks a `receive()` or `fallback()` function, which is necessary to accept ETH from Uniswap swaps (7.2 Code Security, H-01), potentially locking funds. The use of `tx.origin` for transfer delay is a minor concern (7.2 Code Security, L-01).

GovernanceLow7/10

The tokenomics feature high initial buy/sell taxes (22%) that reduce over time, along with max transaction and wallet size limits. With ownership renounced, these parameters are immutable, preventing any adjustments to the initial high tax phase (7.4 Economic, M-01) or the fixed `_taxWallet` address (7.4 Economic, M-02). This immutability, while preventing malicious owner actions, introduces significant inflexibility and operational risks, especially if the initial configuration is flawed or requires future adjustments (7.5 Governance).

UpgradesLow9/10

The contract is not designed with any upgradeability mechanisms, as indicated by `is_proxy: false` (7.7 Upgrades). This means the contract's logic is immutable once deployed. While this eliminates upgrade-related risks like proxy misconfigurations or malicious upgrades, it also means that any discovered vulnerabilities or desired feature enhancements cannot be implemented without a complete redeployment and migration, which can be costly and disruptive.

Security Checklist

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

Holder Composition

78.4% in top 10
4.4% in wallets74.1% in contracts
Effective Concentration34.0%

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

$1.29M across 8 pairs
Pancakeswap v2WBNBanalysed$1.29M99.9%UniswapUSDT$8170.1%Squadswap v2WBNB$4140.0%Pancakeswap v3CZ9K$1900.0%Pancakeswap v3USDT$1750.0%Pancakeswap v3WBNB$1080.0%
Show 1 more pairShow less
UniswapUSDT$70.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 Burned99.9% · ≈ permanent lock
LP Locked99.9%

Key Addresses

10 addresses
Deployer
0xd8b1…515f
Unlocked LP Held By
0x0ed9…97060x2877…0d390x55e9…37040xc57f…e5530xf653…23c20xbed2…636d0x40e9…aa9d0x3b3a…ee070xcac7…b2c8

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 > 30% (78.4% total → 34.0% effective; 4.4% in EOAs, 74.1% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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
你们的胆子真是肥嘟嘟的 (肥嘟嘟)Low Risk币恩宝 (BNBO)Low RiskFrippyLow RiskGiggle Mascot (MAX)Low RiskOKZOO (AIOT)Low RiskDBURNLow Risk

Would You Like a More Detailed Audit of Build On BNB?

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

Get Detailed Audit