On-chain security analysis — is it a scam or legit?
EthereumThis 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.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xcc8d…d6fe0xdc46…c382No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The 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)
Implement 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.
Unresolved
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)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)
Remove 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.
Unresolved
_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)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)
If 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.
Unresolved
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)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)
If 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.
Unresolved
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.
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).
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.
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.
It is recommended to implement a secure withdrawal mechanism for any ETH held by the contract to prevent funds from being permanently locked.
Additionally, consider removing the redundant SafeMath library for Solidity versions 0.8.0 and above to optimize gas usage and simplify the codebase. If a dynamic token supply is desired, ensure that _mint and _burn functionalities are exposed through properly permissioned external functions in an inheriting contract.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Shrub contract on Ethereum is 0x3b991130eae3cca364406d718da22fa1c3e7c256. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Shrub is 0/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $455.3K.
As of Sep 4, 2026, the 10 largest holders own 29.1% of the supply. The Holders section on this page shows who they are by holder type.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
