Is BREW Safe? Smart Contract Security Analysis

Security Findings

2 Low2 Info

Low

Centralized Initial Token Distribution

L-01During deployment, the entire `totalSupply_` is minted to a single `recipient_` address. While common for initial token launches, this represents a centralized point of control for the entire token supply at inception (7.4 Economic). The security of this single address is paramount for the integrity of the token supply.

IssueDuring deployment, the entire `totalSupply_` is minted to a single `recipient_` address. While common for initial token launches, this represents a centralized point of control for the entire token supply at inception (7.4 Economic). The security of this single address is paramount for the integrity of the token supply.

FixEnsure the `recipient_` address is a secure, multi-signature wallet or a well-audited distribution mechanism to mitigate risks associated with a single point of failure and potential compromise of the initial token supply.

StatusUnresolved

Low

Non-Upgradeability of Contract

L-02The `BrewToken` contract is implemented as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified or updated. While this removes risks associated with upgrade mechanisms (7.7 Upgrades), it also means that any discovered vulnerabilities or desired feature enhancements would require deploying an entirely new token contract, which can be disruptive and costly.

IssueThe `BrewToken` contract is implemented as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified or updated. While this removes risks associated with upgrade mechanisms (7.7 Upgrades), it also means that any discovered vulnerabilities or desired feature enhancements would require deploying an entirely new token contract, which can be disruptive and costly.

FixProjects should carefully consider their long-term needs. If future modifications or bug fixes are anticipated, a proxy pattern (e.g., UUPS) should be considered for future contracts. For this specific contract, acknowledge the immutability and plan accordingly for its lifecycle.

StatusUnresolved

Info

Standard OpenZeppelin ERC-20 Implementation

I-01The `BrewToken` contract correctly implements the ERC-20 standard by inheriting from OpenZeppelin's battle-tested `ERC20` contract. This significantly reduces the likelihood of common ERC-20 vulnerabilities (7.2 Code Security). The contract also uses Solidity 0.8.x, benefiting from default overflow/underflow checks and explicit `unchecked` blocks where appropriate.

IssueThe `BrewToken` contract correctly implements the ERC-20 standard by inheriting from OpenZeppelin's battle-tested `ERC20` contract. This significantly reduces the likelihood of common ERC-20 vulnerabilities (7.2 Code Security). The contract also uses Solidity 0.8.x, benefiting from default overflow/underflow checks and explicit `unchecked` blocks where appropriate.

FixNo specific recommendation, as this is a strength of the contract's design and implementation.

StatusUnresolved

Info

Immutability of Key Parameters

I-02The `creator`, `brewFactory`, and `metadataURI` variables are declared as `immutable` and set only during the constructor. This ensures that these critical parameters cannot be changed after deployment, providing predictability and reducing potential attack vectors related to parameter manipulation (7.3 Access Control).

IssueThe `creator`, `brewFactory`, and `metadataURI` variables are declared as `immutable` and set only during the constructor. This ensures that these critical parameters cannot be changed after deployment, providing predictability and reducing potential attack vectors related to parameter manipulation (7.3 Access Control).

FixNo specific recommendation, as this design choice enhances the security and predictability of the contract.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1 Architecture) of BrewToken is straightforward, implementing a standard ERC-20 token. It leverages OpenZeppelin's secure and audited ERC-20 library, significantly enhancing code security (7.2 Code Security) and mitigating common vulnerabilities like reentrancy and integer overflows. Access control (7.3 Access Control) is minimal, limited to the standard ERC-20 functions, with key parameters like `creator`, `brewFactory`, and `metadataURI` being immutable after deployment, which is a strength. No complex external interactions (7.6 External) are present.

GovernanceHigh3/10

The economic model (7.4 Economic) involves a single initial minting event to a specified recipient, leading to a centralized initial token distribution. There are no explicit governance mechanisms (7.5 Governance) or operational roles (7.8 Operations) defined within the contract itself, simplifying its structure but placing responsibility for the initial token holder's security. The immutability of `creator` and `brewFactory` provides clarity on key addresses.

UpgradesMedium6/10

The BrewToken contract is not designed with upgradeability (7.7 Upgrades) in mind, meaning its logic cannot be modified post-deployment. This eliminates risks associated with proxy patterns and upgrade mechanisms, such as improper upgrade paths or malicious upgrades. However, it also means that any future bug fixes or feature enhancements would necessitate a new contract deployment, which could be disruptive.

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

25.6% in top 10

10.6% in wallets15.0% in contracts

Effective Concentration16.6%

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

$1.17M across 4 pairs

Pancakeswap v3WBNBanalysed$858.0K Pancakeswap v3USDT$232.4K UniswapUSDT$76.0K Pancakeswap v2USDT$0

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 Holder77.6%

Top-3 Unlocked92.6%

Key Addresses

11 addresses

Deployer

0x97b8…86f8

Unlocked LP Held By

0x3366…f0d40xcd81…36e30xfea9…43880x2e44…97aa0x96da…66000xa156…24d90x7953…78e40xadab…f5940x689a…503c0x20ab…35fa

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)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 77.6% (independent LP — depth risk, pool = 74% of DEX liquidity)
LP top3 unlocked holders = 92.6% (independent LP — depth risk, pool = 74% of DEX liquidity)
Token age < 30 days (still settling)
2 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

Not Signed In

Is BREW Safe?

Security Findings

Centralized Initial Token Distribution

Non-Upgradeability of Contract

Standard OpenZeppelin ERC-20 Implementation

Immutability of Key Parameters

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of BREW?