Quantum Audit Logo
Launch App

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

Is Brad Safe?

BRADBNB 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
Technical10/10Governance8/10Upgrades10/10Checks passed5 of 5Findings1 Low · 2 Info3
SummaryAI Copilot

The FourERC20 contract is a standard ERC-20 token implementation, largely based on OpenZeppelin Contracts.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $50k
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (59.7% total → 30.1% effective; 10.3% in EOAs, 49.4% in contracts — moderate)
  • Liquidity < $50k ($30,551 across 1 pairs — thin market)
  • 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
49.4%Contracts10.3%Wallets40.3%Everyone else
49.4%Contracts10.3%40.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
59.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking49.4%
  • Walletsanonymous holders, free to sell10.3%
  • Everyone elsethe rest of the supply40.3%
Effective concentrationwhat the score reads30.1%
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$30.6K

The risk score reads depth across every pair.

LP tokensLocked

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

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

Security Findings

1 Low2 Info
Low

Uninitialized Metadata on Direct Deployment

The FourERC20 contract includes an internal _init(string memory name_, string memory symbol_) function to set the token's name and symbol. However, the contract itself does not have a public constructor that calls this _init function. If FourERC20 is deployed directly without a constructor, the _name and _symbol state variables will remain empty strings, causing name() and symbol() functions to return empty values, which is unusual for an ERC-20 token.L-01

Issue

The FourERC20 contract includes an internal _init(string memory name_, string memory symbol_) function to set the token's name and symbol. However, the contract itself does not have a public constructor that calls this _init function. If FourERC20 is deployed directly without a constructor, the _name and _symbol state variables will remain empty strings, causing name() and symbol() functions to return empty values, which is unusual for an ERC-20 token.

Fix

Implement a public constructor in the FourERC20 contract or a derived contract that calls _init(string memory name_, string memory symbol_) to properly set the token's metadata upon deployment. For example: `constructor(string memory name_, string memory symbol_) { _init(name_, symbol_); }`.

Status

Unresolved

Info

Base Contract Design - Missing Supply Mechanism

The FourERC20 contract is designed as a base implementation for an ERC-20 token. It provides core functionalities like transfer, approve, and balanceOf, but intentionally lacks a public mechanism for minting or burning tokens. The _mint and _burn functions are internal, requiring a derived contract to implement the token's supply mechanism. This design choice means the contract, as-is, cannot create new tokens or destroy existing ones publicly.I-01

Issue

The FourERC20 contract is designed as a base implementation for an ERC-20 token. It provides core functionalities like transfer, approve, and balanceOf, but intentionally lacks a public mechanism for minting or burning tokens. The _mint and _burn functions are internal, requiring a derived contract to implement the token's supply mechanism. This design choice means the contract, as-is, cannot create new tokens or destroy existing ones publicly.

Fix

A derived contract must be implemented to define and control the token's supply mechanism (e.g., through a Minter role or a fixed supply at deployment). This is a design consideration rather than a vulnerability, but it's crucial for the token's intended utility.

Status

Unresolved

Info

EIP-2771 Context Suffix Not Configured

The contract inherits from OpenZeppelin's Context.sol, which includes the virtual function _contextSuffixLength(). This function is part of the infrastructure for supporting EIP-2771 (meta-transactions) by indicating the length of the suffix appended to msg.data. The current implementation in Context (and thus in FourERC20) returns 0, meaning EIP-2771 is not actively configured or supported by this contract. While not a vulnerability, it indicates a lack of meta-transaction support.I-02

Issue

The contract inherits from OpenZeppelin's Context.sol, which includes the virtual function _contextSuffixLength(). This function is part of the infrastructure for supporting EIP-2771 (meta-transactions) by indicating the length of the suffix appended to msg.data. The current implementation in Context (and thus in FourERC20) returns 0, meaning EIP-2771 is not actively configured or supported by this contract. While not a vulnerability, it indicates a lack of meta-transaction support.

Fix

If EIP-2771 meta-transactions are intended to be supported, a derived contract must override the _contextSuffixLength() function to return the correct suffix length, and integrate with a trusted forwarder. If meta-transactions are not a requirement, this can be disregarded.

Status

Unresolved

Analysis

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

The FourERC20 contract is a standard ERC-20 token implementation, largely based on OpenZeppelin Contracts. It provides core token functionalities and includes mitigations for common ERC-20 allowance issues. The contract itself is a base implementation and lacks a public supply mechanism or a constructor to initialize its name and symbol, requiring a derived contract for full functionality. No critical or high-severity vulnerabilities were identified.

Technical10/10Low risk

The contract implements the ERC-20 standard using well-vetted OpenZeppelin libraries, ensuring strong code security (7.2 Code Security) and adherence to best practices. It includes increaseAllowance and decreaseAllowance functions to mitigate front-running risks associated with approve. The internal _transfer, _mint, and _burn functions include appropriate zero-address checks and event emissions. The primary technical observation is that FourERC20 is a base contract, lacking a public constructor or minting mechanism (7.1 Architecture), meaning it requires a derived contract for full operational capability.

Governance8/10Low risk

The contract itself does not implement any governance mechanisms (7.5 Governance) or complex economic models (7.4 Economic), functioning purely as a standard token. Its economic stability depends entirely on the supply mechanism implemented by a derived contract. There are no privileged roles or centralized control points within this specific contract, as _mint and _burn are internal functions.

Upgrades10/10Low risk

The contract is not designed as an upgradeable proxy (7.7 Upgrades) and does not include any proxy-related logic. If deployed directly, it is not upgradeable, and thus upgrade safety is not a direct concern for this specific contract instance. The internal _init function is a common pattern in base contracts that might be extended by a proxy implementation, but without explicit proxy integration, it does not introduce upgradeability risks or benefits.

Final RecommendationWhat to do about this score

Ensure that a derived contract properly implements a constructor to set the token's name and symbol, and to establish a controlled supply mechanism (minting/burning).

This will ensure the token is fully functional upon deployment. If there is an intention to make this token upgradeable in the future, a separate proxy contract would be required, and the FourERC20 contract would need to be adapted to include an initialize function with appropriate access control and an initializer modifier to prevent re-initialization vulnerabilities.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age2mo
Contract0x3db1…4444
Deployer0xa65a…f01d
Badge for your website
Brad 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. Aug 12, 20260Low

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

Frequently Asked Questions

What is the BRAD contract address?

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

Is Brad a scam?

Quantum Audit's risk score for Brad is 0/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 BRAD liquidity locked?

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

Who holds BRAD?

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

Related Audits

6 more on the recordAll audits
TCryptochicksTCC · BNB Chain0Low币安人生BNB Chain0LowSKYAIBNB Chain0LowBBNB Chain0LowDOYRBNB Chain0LowCREPEBNB Chain0Low

Would You Like a More Detailed Audit of Brad?

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