Quantum Audit Logo

Is Brad Safe?

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

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

Brad BRAD
0x3db1…4444
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 Low2 Informational
Volume 24h
$27.1K
Liquidity
$30.6K
Price
$0.00005553
Token Age
2mo
Top 10 Holders
59.7%

Security Findings

1 Low2 Info
Low

Uninitialized Metadata on Direct Deployment

L-01The `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.
IssueThe `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.
FixImplement 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_); }`.
StatusUnresolved
Info

Base Contract Design - Missing Supply Mechanism

I-01The `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.
IssueThe `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.
FixA 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.
StatusUnresolved
Info

EIP-2771 Context Suffix Not Configured

I-02The 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.
IssueThe 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.
FixIf 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.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceLow8/10

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.

UpgradesLow10/10

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.

Security Checklist

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

Holder Composition

59.7% in top 10
10.3% in wallets49.4% in contracts
Effective Concentration30.1%

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

$30.6K

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0xa65a…f01d

What Raised This Score

3 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

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 Brad?

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

Get Detailed Audit