Quantum Audit Logo

Is BREWCAT a Scam?

Honeypot, rug-pull and ownership checks

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

BREWCAT BREWCAT
0x9b2b…cfea
BNB Chain
Not verifiedThis 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 8d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The BrewToken contract is a standard ERC-20 token implementation, inheriting from battle-tested OpenZeppelin libraries. It features a fixed total supply minted at deployment and immutable metadata. The contract's simplicity and reliance on audited components contribute to a low overall risk profile. No critical or high-severity vulnerabilities were identified.

4 Informational
i Our automated scanner reviewed BREWCAT (BREWCAT) on BNB Chain. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$140.2K
Liquidity
$89.6K
Price
$0.0003307
Age
8d
Top 10 Holders
37.6%

Security Findings

4 Info
Info

Unusual `tokenURI` Function for ERC-20

I-01The `BrewToken` contract includes a public `tokenURI()` function, which is typically associated with ERC-721 or ERC-1155 NFTs for retrieving metadata. While not a vulnerability, its presence on an ERC-20 token is unconventional and might lead to confusion or misinterpretation of the token's nature or capabilities by users or platforms expecting standard ERC-20 behavior. This falls under 7.1 Architecture.
IssueThe `BrewToken` contract includes a public `tokenURI()` function, which is typically associated with ERC-721 or ERC-1155 NFTs for retrieving metadata. While not a vulnerability, its presence on an ERC-20 token is unconventional and might lead to confusion or misinterpretation of the token's nature or capabilities by users or platforms expecting standard ERC-20 behavior. This falls under 7.1 Architecture.
FixClarify the purpose of the `tokenURI()` function in documentation. If it serves no specific purpose for an ERC-20, consider removing it to avoid confusion and adhere strictly to ERC-20 standards. If it's intended for specific off-chain integrations, ensure those integrations are well-documented.
StatusUnresolved
Info

Immutable `metadataURI` Post-Deployment

I-02The `metadataURI` variable is set only during the contract's construction and has no setter function, making it immutable after deployment. This means the token's associated metadata URI cannot be updated or changed in the future. This falls under 7.4 Economic and 7.8 Operations.
IssueThe `metadataURI` variable is set only during the contract's construction and has no setter function, making it immutable after deployment. This means the token's associated metadata URI cannot be updated or changed in the future. This falls under 7.4 Economic and 7.8 Operations.
FixConfirm if the immutability of `metadataURI` is an intentional design choice. If there's a future need for dynamic metadata, consider implementing an owner-controlled function to update this URI. However, for a simple, static token, immutability can be a feature, ensuring predictability.
StatusUnresolved
Info

Fixed Supply and Decentralized Control

I-03The `BrewToken` contract mints a fixed total supply to a specified recipient during deployment and lacks any further minting or burning capabilities exposed to external users. The `creator` and `brewFactory` addresses are immutable and hold no special privileges post-deployment. This design promotes a decentralized and predictable token economy, as no single entity can alter the supply or control core token functions after deployment. This is a strength in terms of 7.3 Access Control and 7.4 Economic.
IssueThe `BrewToken` contract mints a fixed total supply to a specified recipient during deployment and lacks any further minting or burning capabilities exposed to external users. The `creator` and `brewFactory` addresses are immutable and hold no special privileges post-deployment. This design promotes a decentralized and predictable token economy, as no single entity can alter the supply or control core token functions after deployment. This is a strength in terms of 7.3 Access Control and 7.4 Economic.
FixNo specific recommendation, as this is a positive security characteristic. Maintain clear documentation regarding the fixed supply and lack of administrative control post-deployment to manage user expectations.
StatusUnresolved
Info

Reliance on Battle-Tested OpenZeppelin Libraries

I-04The `BrewToken` contract inherits its core ERC-20 functionality from OpenZeppelin's `ERC20` implementation. OpenZeppelin contracts are widely adopted, rigorously audited, and continuously reviewed by the community, significantly reducing the likelihood of common ERC-20 vulnerabilities such as reentrancy, integer overflows/underflows, and standard compliance issues. This contributes positively to 7.2 Code Security.
IssueThe `BrewToken` contract inherits its core ERC-20 functionality from OpenZeppelin's `ERC20` implementation. OpenZeppelin contracts are widely adopted, rigorously audited, and continuously reviewed by the community, significantly reducing the likelihood of common ERC-20 vulnerabilities such as reentrancy, integer overflows/underflows, and standard compliance issues. This contributes positively to 7.2 Code Security.
FixContinue to monitor OpenZeppelin's security advisories and updates. Ensure that the specific version of OpenZeppelin contracts used (`^0.8.20`) remains secure and compatible with the chosen Solidity compiler version.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1 Architecture) of BrewToken is straightforward, implementing a standard ERC-20 token. Code security (7.2 Code Security) is robust due to its reliance on OpenZeppelin's extensively audited ERC20 library, which mitigates common vulnerabilities like reentrancy and integer overflows. For instance, the `_update` function in ERC20 uses `unchecked` blocks safely after explicit balance checks. The contract includes an unconventional `tokenURI()` function, typically found in NFTs, which returns a static `metadataURI` (I-01).

GovernanceHigh3/10

The economic model (7.4 Economic) of BrewToken is simple and predictable: a fixed total supply is minted once during deployment to a specified recipient. There are no post-deployment minting or burning mechanisms exposed, ensuring a stable supply. Access control (7.3 Access Control) is minimal, with `creator` and `brewFactory` addresses being immutable and holding no special privileges after deployment, which promotes decentralization (I-03). The `metadataURI` is also immutable post-deployment (I-02), preventing any changes to the token's associated metadata.

UpgradesMedium6/10

The BrewToken contract is not designed to be upgradeable (7.7 Upgrades), as it does not implement any proxy patterns. This eliminates the risks associated with upgradeability, such as proxy misconfigurations or logic errors during upgrades. The contract's immutability ensures its behavior remains constant post-deployment.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

37.6% in top 10
14.8% in wallets22.8% in contracts
Effective Concentration23.9%

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

$89.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

Top-1 Unlocked Holder99.0%
Top-3 Unlocked99.8%

Key Addresses

11 addresses
Deployer
0x3c35…8f7c
Unlocked LP Held By
0x3366…f0d40xcc7f…ab080x4219…3be50xb262…eeed0xe9a0…cd4c0xa395…f4570x5ad1…2cb00x8020…66370x2a5d…724a0x2ee3…3c7f

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (37.6% total → 23.9% effective; 14.8% in EOAs, 22.8% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 99.8% (independent LP — depth risk)
  • Token age < 30 days (still settling)

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
Tutorial (TUT)Medium RiskBnb Tiger Inu (BNBTIGER)Medium RiskARKMedium RiskmubarakMedium RiskAlaya Governance Token (AGT)Medium RiskCheese Head (CHEESE)Medium Risk

Would You Like a More Detailed Audit of BREWCAT?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit