Quantum Audit Logo

Is Shrub Safe?

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

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

Shrub SHRUB
0x3b99…c256
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

This audit covers a standard ERC20 token contract. The contract implements basic token functionalities, including transfers, approvals, and supply management, adhering largely to the ERC20 standard. Key observations include redundant SafeMath usage, internal mint/burn functions, and an unexpected ETH balance. No critical vulnerabilities were identified.

1 Medium1 Low2 Informational
Volume 24h
$85.3K
Liquidity
$414.8K
Price
$0.00204
Token Age
2y
Top 10 Holders
29.1%

Security Findings

1 Med1 Low2 Info
Medium

Unexpected ETH Balance Without Withdrawal Mechanism

M-01The contract holds an Ether balance of approximately 5.3 ETH (5337572695930628067 wei) but lacks any explicit functionality for receiving, holding, or withdrawing ETH. This suggests that the ETH may have been sent to the contract accidentally or without a clear purpose. Without a withdrawal function, these funds are effectively locked and inaccessible, representing a potential loss of assets. (7.8 Operations)
IssueThe contract holds an Ether balance of approximately 5.3 ETH (5337572695930628067 wei) but lacks any explicit functionality for receiving, holding, or withdrawing ETH. This suggests that the ETH may have been sent to the contract accidentally or without a clear purpose. Without a withdrawal function, these funds are effectively locked and inaccessible, representing a potential loss of assets. (7.8 Operations)
FixImplement a secure and permissioned function to allow authorized parties (e.g., a designated owner or multisig) to withdraw any ETH held by the contract. Ensure this function includes appropriate access control and event logging.
StatusUnresolved
Low

Redundant SafeMath Usage

L-01The contract explicitly uses the `SafeMath` library for arithmetic operations (e.g., `add`, `sub`). However, the contract is compiled with `pragma solidity ^0.8.17;`, and Solidity versions 0.8.0 and higher include built-in overflow and underflow checks by default. The use of `SafeMath` is therefore redundant, increasing bytecode size and gas costs without providing additional security benefits in this context. (7.2 Code Security)
IssueThe contract explicitly uses the `SafeMath` library for arithmetic operations (e.g., `add`, `sub`). However, the contract is compiled with `pragma solidity ^0.8.17;`, and Solidity versions 0.8.0 and higher include built-in overflow and underflow checks by default. The use of `SafeMath` is therefore redundant, increasing bytecode size and gas costs without providing additional security benefits in this context. (7.2 Code Security)
FixRemove the `using SafeMath for uint256;` directive and associated SafeMath function calls. Rely on Solidity's native overflow/underflow checks for arithmetic operations, which are enabled by default in version 0.8.0 and above.
StatusUnresolved
Info

Internal Mint and Burn Functions

I-01The `_mint` and `_burn` functions are declared as `internal virtual`. This means they can only be called by the contract itself or by inheriting contracts, and are not directly accessible from external accounts. As a base ERC20 contract, this design implies that the token supply is fixed after initial deployment unless an inheriting contract provides public or external functions to expose these minting/burning capabilities. If a dynamic supply is intended, further implementation is required. (7.1 Architecture)
IssueThe `_mint` and `_burn` functions are declared as `internal virtual`. This means they can only be called by the contract itself or by inheriting contracts, and are not directly accessible from external accounts. As a base ERC20 contract, this design implies that the token supply is fixed after initial deployment unless an inheriting contract provides public or external functions to expose these minting/burning capabilities. If a dynamic supply is intended, further implementation is required. (7.1 Architecture)
FixIf a dynamic token supply is desired, ensure that an inheriting contract implements properly permissioned external functions (e.g., `mint`, `burn`) that call these internal `_mint` and `_burn` functions. These external functions should include robust access control mechanisms (e.g., `onlyOwner`, role-based access control) to prevent unauthorized supply manipulation.
StatusUnresolved
Info

Unused Uniswap V2 Interfaces

I-02The contract includes interfaces for `IUniswapV2Pair` and `IUniswapV2Factory`. However, within the provided `ERC20` implementation, these interfaces are not utilized in any function calls or logic. This suggests that the contract might be part of a larger system where these interactions occur in other modules, or it serves as a base for a token intended to interact with Uniswap V2, but the current snippet does not demonstrate these interactions. (7.1 Architecture)
IssueThe contract includes interfaces for `IUniswapV2Pair` and `IUniswapV2Factory`. However, within the provided `ERC20` implementation, these interfaces are not utilized in any function calls or logic. This suggests that the contract might be part of a larger system where these interactions occur in other modules, or it serves as a base for a token intended to interact with Uniswap V2, but the current snippet does not demonstrate these interactions. (7.1 Architecture)
FixIf the Uniswap V2 interfaces are not intended for use within this specific contract, consider removing them to reduce bytecode size and improve clarity. If they are part of a larger system, ensure that the overall architecture clearly defines how and where these interfaces are used for external interactions.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract provides a solid foundation for an ERC20 token, implementing standard functionalities like `transfer`, `approve`, and `balanceOf` correctly (7.2 Code Security). It utilizes SafeMath for arithmetic operations, which, while redundant in Solidity 0.8.17+, ensures protection against integer overflows/underflows (7.2 Code Security). A notable issue is the presence of an unexpected ETH balance in the contract, which lacks a withdrawal mechanism (7.8 Operations). The `_mint` and `_burn` functions are internal, indicating a fixed supply unless extended by an inheriting contract (7.1 Architecture).

GovernanceLow10/10

No specific governance or advanced economic models are implemented within this base ERC20 contract (7.5 Governance, 7.4 Economic). The token functions as a standard transferrable asset. The internal nature of `_mint` and `_burn` functions suggests a fixed supply after initial deployment, limiting dynamic economic control unless an inheriting contract provides external access.

UpgradesLow10/10

The contract is not designed as an upgradeable proxy, meaning its logic cannot be modified post-deployment (7.7 Upgrades). This simplifies the architecture by removing upgrade-related risks such as proxy storage collisions or improper initialization. However, any future feature additions or bug fixes would necessitate a new deployment and migration of assets.

Security Checklist

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

Holder Composition

29.1% in top 10
14.7% in wallets14.4% in contracts
Effective Concentration20.4%

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

$455.3K across 4 pairs
Uniswap v2WETHanalysed$414.8K91.1%Uniswap v3WETH$19.1K4.2%Uniswap v4USDC$18.5K4.1%Uniswap v4ETH$2.9K0.6%

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

3 addresses
Deployer
0x0cc3…5551
Unlocked LP Held By
0xcc8d…d6fe0xdc46…c382

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

What Raised This Score

3 factors
  • Top-10 concentration > 20% (29.1% total → 20.4% effective; 14.7% in EOAs, 14.4% in contracts — mild)
  • 1 Medium finding(s) from audit
  • 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
AsteroidLow RiskAmerica Pac (PAC)Low RiskJerry The Turtle By Matt Furie (JYAI)Low RiskNon-Playable Coin (NPC)Low RiskYee Token (YEE)Low RiskPikachuLow Risk

Would You Like a More Detailed Audit of Shrub?

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

Get Detailed Audit