On-chain security analysis — is it a scam or legit?
BNB ChainThe GIGGLE token contract is a standard ERC-20 implementation.
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.
0x5e1e…9f450x0ed9…97060xcff4…da570xa62e…db450x6f7d…dee5No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approve() Front-Running Riskapprove() function is susceptible to a known front-running vulnerability. If a user approves an amount for a spender and then attempts to change that approval to a different amount, a malicious actor could front-run the second transaction. This allows the attacker to spend the original approved amount before the new approval takes effect, potentially leading to the malicious actor spending both the original and the new approved amounts. While increaseAllowance() and decreaseAllowance() mitigate this for specific use cases, the base approve() function remains.L-01The standard ERC-20 approve() function is susceptible to a known front-running vulnerability. If a user approves an amount for a spender and then attempts to change that approval to a different amount, a malicious actor could front-run the second transaction. This allows the attacker to spend the original approved amount before the new approval takes effect, potentially leading to the malicious actor spending both the original and the new approved amounts. While increaseAllowance() and decreaseAllowance() mitigate this for specific use cases, the base approve() function remains.
Users should be aware of this inherent risk when interacting with approve(). For critical operations, consider using increaseAllowance() and decreaseAllowance() or a 'permit' style approval (not implemented here) which offers a more secure alternative to direct approve() calls.
Unresolved
SafeMath library is imported and declared but not utilized within the ERC20 contract. Solidity 0.8.11 automatically includes overflow/underflow checks, making SafeMath redundant unless specific unchecked blocks are used without prior validation. In this contract, all unchecked blocks are correctly guarded by require statements, rendering SafeMath unnecessary.I-01The SafeMath library is imported and declared but not utilized within the ERC20 contract. Solidity 0.8.11 automatically includes overflow/underflow checks, making SafeMath redundant unless specific unchecked blocks are used without prior validation. In this contract, all unchecked blocks are correctly guarded by require statements, rendering SafeMath unnecessary.
Remove the SafeMath library import and declaration to reduce contract size, optimize deployment costs, and improve code clarity, as its functionality is not needed or used.
Unresolved
IUniswapV2Pair and IUniswapV2Factory interfaces are defined within the contract file but are not referenced or used by the ERC20 contract itself. This indicates either incomplete code, vestigial declarations, or interfaces intended for external interaction not directly implemented here.I-02The IUniswapV2Pair and IUniswapV2Factory interfaces are defined within the contract file but are not referenced or used by the ERC20 contract itself. This indicates either incomplete code, vestigial declarations, or interfaces intended for external interaction not directly implemented here.
Remove unused interfaces to reduce contract size and improve code clarity. If these interfaces are intended for future integration or external interaction, ensure they are properly documented to explain their purpose.
Unresolved
_mint and _burn functions are declared as internal virtual. This design choice means they can only be called by the ERC20 contract itself or by contracts that inherit from ERC20. There are no public or external functions provided in this contract that expose minting or burning capabilities to external users. This implies that the token has a fixed supply unless a derived contract explicitly adds such functionality.I-03The _mint and _burn functions are declared as internal virtual. This design choice means they can only be called by the ERC20 contract itself or by contracts that inherit from ERC20. There are no public or external functions provided in this contract that expose minting or burning capabilities to external users. This implies that the token has a fixed supply unless a derived contract explicitly adds such functionality.
Document this design choice clearly for users and future developers. If a variable supply is intended, ensure that derived contracts implement secure access control for any externally exposed minting and burning functions.
Unresolved
The GIGGLE token contract is a standard ERC-20 implementation. The code adheres to common patterns and best practices for token contracts. No critical or high-severity vulnerabilities were identified. Minor informational findings relate to unused code and inherent ERC-20 design considerations. The contract appears robust for its intended purpose as a basic token.
The technical architecture is a straightforward ERC-20 token, inheriting from Context and implementing IERC20 and IERC20Metadata. The code security is high, utilizing Solidity 0.8.11's default overflow/underflow checks, with unchecked blocks correctly guarded by require statements (7.2 Code Security). Access control (7.3 Access Control) is standard for an ERC-20 token, with _mint and _burn functions being internal, preventing unauthorized supply manipulation. Minor issues include unused SafeMath and Uniswap interfaces, which do not pose security risks but affect code clarity.
The contract implements a basic ERC-20 token without complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). The supply is fixed as _mint and _burn functions are internal and not exposed externally, preventing arbitrary token creation or destruction. There are no owner-controlled parameters or special roles that could introduce centralized economic risks. The economic model is simple and transparent, relying on standard token transfer mechanics.
The contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation. This design choice eliminates risks associated with upgrade mechanisms, such as proxy storage collisions or insecure upgrade paths. Users should be aware that the contract's logic cannot be modified post-deployment.
The GIGGLE token contract is a well-implemented standard ERC-20 token.
The identified issues are minor and do not pose significant security risks. It is recommended to address the informational findings by removing unused code to optimize contract size and improve readability. For users interacting with the token, awareness of the inherent ERC-20 approve() front-running risk is advisable, though this is a standard consideration for all ERC-20 tokens.
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 Giggle Fund (GIGGLE) contract on BNB Chain is 0x20d6015660b3fe52e6690a889b5c51f69902ce0e. 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 Giggle Fund 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. 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: $887.7K.
As of Sep 4, 2026, the 10 largest holders own 92.3% 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
