Quantum Audit Logo

Is Brett a Scam?

Honeypot, rug-pull and ownership checks

Brett BRETT
0x532f…42e4
Base
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.
Last checked 5d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The audited contract implements a standard ERC20 token, leveraging common patterns for context, ownership, and token functionality. The code is well-structured and adheres to Solidity 0.8.17 best practices, including native overflow/underflow checks. A key security feature is the renounced ownership, which enhances decentralization by removing a single point of control. The token's supply mechanism is fixed, as no public minting or burning functions are exposed in this base contract.

4 Informational
i Our automated scanner reviewed Brett (BRETT) on Base. 4 of 5 security checks passed — see the full breakdown below.
Volume 24h
$36.7K
Liquidity
$1.15M
Price
$0.004694
Age
2y
Top 10 Holders
33.7%

Security Findings

4 Info
Info

Redundant SafeMath Library

I-01The `SafeMath` library is included in the contract but its functions are not explicitly utilized within the `ERC20` implementation. Solidity 0.8.x and later versions include default overflow/underflow checks for all arithmetic operations, rendering external `SafeMath` libraries largely redundant unless specific `unchecked` blocks are used without prior validation. In this contract, `unchecked` blocks are used correctly after validation.
IssueThe `SafeMath` library is included in the contract but its functions are not explicitly utilized within the `ERC20` implementation. Solidity 0.8.x and later versions include default overflow/underflow checks for all arithmetic operations, rendering external `SafeMath` libraries largely redundant unless specific `unchecked` blocks are used without prior validation. In this contract, `unchecked` blocks are used correctly after validation.
FixConsider removing the `SafeMath` library to reduce contract size and deployment costs, as its functionality is natively handled by the Solidity compiler version 0.8.17.
StatusUnresolved
Info

Fixed Token Decimals

I-02The `decimals()` function is hardcoded to return `18`. While `18` is the common standard for ERC20 tokens and widely supported by exchanges and wallets, making this value configurable via the constructor could offer greater flexibility for future token designs or specific use cases that might require a different decimal precision.
IssueThe `decimals()` function is hardcoded to return `18`. While `18` is the common standard for ERC20 tokens and widely supported by exchanges and wallets, making this value configurable via the constructor could offer greater flexibility for future token designs or specific use cases that might require a different decimal precision.
FixIf future flexibility is desired, consider allowing the `decimals` value to be set during contract construction. For a standard token, the current implementation is acceptable.
StatusUnresolved
Info

Renounced Ownership for Decentralization

I-03The provided information indicates that the contract's ownership has been renounced. This means the `owner` address is set to `address(0)`, preventing any further calls to `onlyOwner` functions, including `transferOwnership` and `renounceOwnership`. This design choice enhances decentralization by removing a single point of control for administrative functions, making the contract more immutable and trustless.
IssueThe provided information indicates that the contract's ownership has been renounced. This means the `owner` address is set to `address(0)`, preventing any further calls to `onlyOwner` functions, including `transferOwnership` and `renounceOwnership`. This design choice enhances decentralization by removing a single point of control for administrative functions, making the contract more immutable and trustless.
FixThis is a positive security feature that contributes to the decentralization and immutability of the token. No action is required.
StatusUnresolved
Info

Fixed Token Supply Mechanism

I-04The `ERC20` base contract provides internal `_mint` and `_burn` functions but does not expose any public or external functions to call them. This implies that the token's total supply is fixed at the time of deployment (via the inheriting contract's constructor) and cannot be increased or decreased thereafter by external parties. This design choice ensures a predictable and non-inflationary/deflationary token supply.
IssueThe `ERC20` base contract provides internal `_mint` and `_burn` functions but does not expose any public or external functions to call them. This implies that the token's total supply is fixed at the time of deployment (via the inheriting contract's constructor) and cannot be increased or decreased thereafter by external parties. This design choice ensures a predictable and non-inflationary/deflationary token supply.
FixThis is a common and secure design for many tokens, providing clarity on tokenomics. Ensure that the initial supply minted in the inheriting contract's constructor is correct and aligns with the project's economic model.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical implementation (7.2 Code Security) is robust, utilizing Solidity 0.8.17's native arithmetic safety features, which largely mitigates integer overflow/underflow risks. The ERC20 standard implementation is complete and follows established patterns. While the `SafeMath` library is included, it is redundant given the compiler version's default checks (I-01). The `decimals()` function is hardcoded to 18 (I-02), which is standard but could be configurable for flexibility.

GovernanceMedium6/10

From an economic and governance perspective (7.4 Economic, 7.5 Governance), the contract exhibits strong decentralization. The ownership has been renounced (I-03), meaning no single entity retains administrative control over the `Ownable` functions. The token supply is fixed (I-04) as there are no public minting or burning mechanisms, which provides predictability for token holders. The contract's design aligns with a decentralized, immutable token model.

UpgradesLow9/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations, storage collisions, or malicious upgrade paths. The lack of upgradeability contributes to the contract's overall security and predictability.

Security Checklist

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

Holder Composition

33.7% in top 10
29.2% in wallets4.6% in contracts
Effective Concentration31.0%

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

$2.29M across 29 pairs
Uniswap v3WETHanalysed$1.15M50.1%AerodromeWETH$795.5K34.7%PancakeswapWETH$172.4K7.5%Uniswap v3WETH$87.9K3.8%Uniswap v3USDC$32.2K1.4%AerodromeAERO$25.3K1.1%
Show 4 more pairsShow less
Uniswap v4AIOCTO$6.2K0.3%Uniswap v4ETH$5.0K0.2%SushiswapWETH$4.1K0.2%AerodromeAERO$3.5K0.2%

The 19 remaining pairs hold $11.4K between them and are not listed.

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 Holder64.9%
Top-3 Unlocked94.8%

Key Addresses

11 addresses
Deployer
0x21c3…3633
Unlocked LP Held By
0x18a8…83330xc216…57430x3521…ab800x0474…74f20x05b1…e3cd0x24d8…ebc50x7d27…fd550xeed7…03af0x7dd6…ebba0xf502…c80d

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

What Raised This Score

4 factors
  • Top-10 concentration > 30% (33.7% total → 31.0% effective; 29.2% in EOAs, 4.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 64.9% (independent LP — depth risk, pool = 50% of DEX liquidity)
  • LP top3 unlocked holders = 94.8% (independent LP — depth risk, pool = 50% of DEX liquidity)

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
Unit 00 - Rei (REI)Low RiskMr. Miggles (MIGGLES)Low RiskKeyboard Cat (KEYCAT)Low Riskmfercoin ($MFER)Low RiskdoginmeLow RiskToshiLow Risk

Would You Like a More Detailed Audit of Brett?

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

Get Detailed Audit