Quantum Audit Logo
Launch App

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

Is Build On BNB Safe?

BOBBNB 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
Technical7/10Governance7/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 1 High · 2 Medium · 1 Low · 1 Info6
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.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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
74.1%Contracts4.4%21.6%Everyone else
74.1%Contracts21.6%
ContractsWalletsEveryone elseBubble area = share of supply
78.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking74.1%
  • Walletsanonymous holders, free to sell4.4%
  • Everyone elsethe rest of the supply21.6%
Effective concentrationwhat the score reads34.0%
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$1.29M across 8 pairs
Show 1 more pair

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$1.29MShare of depth99.9%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9%
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.

Security Findings

1 Critical1 High2 Medium1 Low1 Info
Critical

Unmanageable Trading & Liquidity Setup After Ownership Renunciation

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

High

Missing receive()/fallback() Function

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Fixed and High Initial Taxes

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Fixed Tax Wallet Address

The _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.M-02

Issue

The _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.

Fix

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

Status

Unresolved

Low

tx.origin Usage for Anti-Bot Measure

The _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.L-01

Issue

The _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.

Fix

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

Status

Unresolved

Info

Redundant SafeMath Library

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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

Governance7/10Low risk

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

Upgrades9/10Low risk

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.

Final RecommendationWhat to do about this score

Address the critical issue of uninitialized trading and liquidity parameters by ensuring uniswapV2Router, uniswapV2Pair, tradingOpen, and swapEnabled are properly set in the constructor or via a one-time initialization function callable before ownership renunciation.

Implement a receive() or fallback() function to securely handle incoming ETH from swap operations. Reconsider the use of SafeMath for Solidity 0.8+ to reduce bytecode size. Evaluate the implications of renounced ownership on the immutability of high initial taxes and the fixed tax wallet, ensuring these parameters align with long-term project goals and do not create unmanageable situations.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkBNB Chain
Token age1y
Contract0x5136…560e
Deployer0xd8b1…515f
Badge for your website
Build On BNB 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. Jul 23, 202615Low
  2. Jul 23, 202660Medium

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

Frequently Asked Questions

What is the BOB contract address?

The Build On BNB (BOB) contract on BNB Chain is 0x51363f073b1e4920fda7aa9e9d84ba97ede1560e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Build On BNB a scam?

Quantum Audit's risk score for Build On BNB is 15/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BOB liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $1.29M.

Who holds BOB?

As of Sep 4, 2026, the 10 largest holders own 78.4% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
比特币社区BNB Chain15Low你们的胆子真是肥嘟嘟的肥嘟嘟 · BNB Chain16Low币恩宝BNBO · BNB Chain16LowStonksBNB Chain16LowBreak And ReclaimBAN · BNB Chain14Low人生K线BNB Chain14Low

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 Is this your token? Publish your own audit on this page