Quantum Audit Logo
Launch App

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

Is Brok Safe?

BROKBNB 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
SummaryAI Copilot

The FourERC20 contract is an incomplete implementation of an ERC-20 token, lacking essential core functionality such as balance updates, token minting, and burning.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $10k
  • 1 Critical finding(s) from audit
  • 3 High finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (86.2% total → 38.7% effective; 7.1% in EOAs, 79.2% in contracts — moderate)
  • Liquidity < $10k ($8,007 across 1 pairs — easily drained)
  • 1 Critical finding(s) from audit
  • 3 High 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
79.2%Contracts7.1%13.8%Everyone else
79.2%Contracts7.1%13.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
86.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking79.2%
  • Walletsanonymous holders, free to sell7.1%
  • Everyone elsethe rest of the supply13.8%
Effective concentrationwhat the score reads38.7%
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$8.0K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$8.0KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical3 High
Critical

Incomplete Core Token Logic (_update function)

The _update internal virtual function, which is fundamental for all balance modifications (minting, burning, transferring), is not implemented in the FourERC20 contract. This omission renders the entire ERC-20 contract non-functional, as no tokens can be created, moved between accounts, or destroyed. Any attempt to call functions like transfer, transferFrom, _mint, or _burn will fail at runtime.C-01

Issue

The _update internal virtual function, which is fundamental for all balance modifications (minting, burning, transferring), is not implemented in the FourERC20 contract. This omission renders the entire ERC-20 contract non-functional, as no tokens can be created, moved between accounts, or destroyed. Any attempt to call functions like transfer, transferFrom, _mint, or _burn will fail at runtime.

Fix

Implement the _update internal virtual function to handle the actual balance changes for from and to addresses, including checks for zero addresses and sufficient balances. This is the foundational logic for all token movements.

Status

Unresolved

High

Uninitialized Token Metadata

The _init internal function, responsible for setting the token's _name and _symbol, is not called within the FourERC20 contract. Consequently, the name() and symbol() public view functions will return empty strings. This leads to poor user experience, potential display issues in wallets and explorers, and integration problems with exchanges or other DeFi protocols that rely on this metadata.H-01

Issue

The _init internal function, responsible for setting the token's _name and _symbol, is not called within the FourERC20 contract. Consequently, the name() and symbol() public view functions will return empty strings. This leads to poor user experience, potential display issues in wallets and explorers, and integration problems with exchanges or other DeFi protocols that rely on this metadata.

Fix

Ensure that the _init function is called in the constructor of a derived contract, passing the desired name_ and symbol_ values. This will properly initialize the token's metadata upon deployment.

Status

Unresolved

High

Missing Minting Mechanism

The _mint internal virtual function, which is responsible for increasing the total supply and an account's balance, lacks a concrete implementation. Without this, no new tokens can be introduced into circulation, preventing the token from having any initial supply or dynamic supply management. This issue is a direct consequence of the unimplemented _update function.H-02

Issue

The _mint internal virtual function, which is responsible for increasing the total supply and an account's balance, lacks a concrete implementation. Without this, no new tokens can be introduced into circulation, preventing the token from having any initial supply or dynamic supply management. This issue is a direct consequence of the unimplemented _update function.

Fix

Implement the _mint function, which should internally call the _update function (once _update is implemented) to correctly adjust the _totalSupply and the recipient's balance. Consider adding access control to the public-facing minting function in a derived contract.

Status

Unresolved

High

Missing Burning Mechanism

Similar to minting, the _burn internal virtual function, which is responsible for decreasing the total supply and an account's balance, is not implemented. This prevents any tokens from being removed from circulation, which can be necessary for various tokenomics models or to recover from errors. This issue is also a direct consequence of the unimplemented _update function.H-03

Issue

Similar to minting, the _burn internal virtual function, which is responsible for decreasing the total supply and an account's balance, is not implemented. This prevents any tokens from being removed from circulation, which can be necessary for various tokenomics models or to recover from errors. This issue is also a direct consequence of the unimplemented _update function.

Fix

Implement the _burn function, which should internally call the _update function (once _update is implemented) to correctly adjust the _totalSupply and the sender's balance. Ensure proper checks, such as requiring sufficient balance, are in place.

Status

Unresolved

Analysis

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

The FourERC20 contract is an incomplete implementation of an ERC-20 token, lacking essential core functionality such as balance updates, token minting, and burning. While it leverages OpenZeppelin's robust base for standard ERC-20 interfaces, its current state renders it non-functional as a standalone token. Critical issues prevent any token supply management or transfers, making the contract unusable.

Technical5/10Medium risk

The contract utilizes OpenZeppelin's Context, IERC20, and IERC20Metadata components, providing a structured foundation (7.2 Code Security). However, the FourERC20 contract is an incomplete implementation, critically missing the concrete implementation of the _update internal virtual function, which is essential for all balance modifications (7.1 Architecture). This directly prevents token minting, burning, and transfers. Additionally, the token's name and symbol are not initialized, leading to empty metadata (7.8 Operations).

Governance2/10High risk

The economic model is severely impacted as the token is non-functional; no tokens can be minted, transferred, or burned, rendering it without any intrinsic value or utility (7.4 Economic). This prevents any form of economic activity or value accrual. The contract does not include any specific governance mechanisms (7.5 Governance).

Upgrades8/10Low risk

The provided contract is a standard, non-upgradeable implementation and does not incorporate any proxy patterns (7.7 Upgrades). Therefore, direct upgrade risks are not applicable. Any future modifications would necessitate a new contract deployment and a migration process.

Final RecommendationWhat to do about this score

The FourERC20 contract requires substantial development to become a functional ERC-20 token.

It is critical to implement the _update internal virtual function to enable all balance-modifying operations (minting, burning, transfers). Ensure the _init function is called within a constructor of a derived contract to properly set the token's name and symbol. Consider using a complete OpenZeppelin ERC20 implementation (e.g., ERC20PresetMinterPauser) or a fully custom, audited implementation if specific functionalities are required.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age4mo
Contract0xcedf…4444
Deployer0x9933…8062
Badge for your website
Brok 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, 202648Medium
  2. Aug 16, 202642Medium

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

Frequently Asked Questions

What is the BROK contract address?

The Brok contract on BNB Chain is 0xcedfec92cdda4f49541872543c18e97c587a4444. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Brok a scam?

Quantum Audit's risk score for Brok is 48/100 (Medium 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 BROK liquidity locked?

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

Who holds BROK?

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

Would You Like a More Detailed Audit of Brok?

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