Quantum Audit Logo
Launch App

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

Is Mr. Miggles Safe?

MIGGLESBase
Not verified This 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.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance9/10Upgrades10/10Checks passed5 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The Erc20 token contract implements a standard ERC-20 interface with an Ownable access control pattern.

Read the full analysis
What raised the score
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • 1 High finding(s) from audit
  • 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
9.7%Contracts13.2%Wallets77.1%Everyone else
9.7%13.2%Wallets77.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
22.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking9.7%
  • Walletsanonymous holders, free to sell13.2%
  • Everyone elsethe rest of the supply77.1%
Effective concentrationwhat the score reads17.1%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$584.8K across 16 pairs
Show 4 more pairs

The 6 remaining pairs hold $374 between them and are not listed. The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$528.0KShare of depth90.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0%
Unlocked LP held by
0xd505…797a0x9c4c…29dd0x2036…8d000x6ba3…d9ec0x9872…b4330x4423…9d3f0x65b0…e4650x26b7…597e0xab51…4e13

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control and Pre-Launch Transfer Restrictions

The Erc20 contract implements a launched state, controlled by the onlyOwner function launch(). Before launched is true, the _transferAllowed function prevents transfers to or from any contract address (from.isContract() || to.isContract()). This mechanism, while potentially intended to prevent sniping or control initial distribution, significantly centralizes control in the owner's hands and can block legitimate interactions with DEXes, aggregators, multisigs, or other DeFi protocols until the owner calls launch(). The transferFrom function also includes a special path allowing the owner to move tokens from an approved address to themselves before launch, further highlight…H-01

Issue

The Erc20 contract implements a launched state, controlled by the onlyOwner function launch(). Before launched is true, the _transferAllowed function prevents transfers to or from any contract address (from.isContract() || to.isContract()). This mechanism, while potentially intended to prevent sniping or control initial distribution, significantly centralizes control in the owner's hands and can block legitimate interactions with DEXes, aggregators, multisigs, or other DeFi protocols until the owner calls launch(). The transferFrom function also includes a special path allowing the owner to move tokens from an approved address to themselves before launch, further highlight…

Fix

Ensure comprehensive documentation clearly outlines the pre-launch phase, its implications for token holders, and how it affects interactions with other smart contracts. Consider if the isContract() check is overly restrictive; if specific contract types (e.g., known DEX routers) are intended to be allowed, a whitelist mechanism could be explored. Communicate the owner's role and the timing of the launch() function transparently.

Status

Unresolved

Medium

Non-Standard Self-Transfer Restriction

The _transfer function includes a require(from != to, "you cannot transfer to yourself"); check. While seemingly a minor restriction, standard ERC-20 implementations typically allow transfers from an address to itself. Some protocols, dApps, or internal accounting systems might expect or rely on the ability to perform self-transfers for various reasons, such as gas optimization or re-triggering hooks. This deviation from the ERC-20 standard could lead to unexpected reverts or integration issues.M-01

Issue

The _transfer function includes a require(from != to, "you cannot transfer to yourself"); check. While seemingly a minor restriction, standard ERC-20 implementations typically allow transfers from an address to itself. Some protocols, dApps, or internal accounting systems might expect or rely on the ability to perform self-transfers for various reasons, such as gas optimization or re-triggering hooks. This deviation from the ERC-20 standard could lead to unexpected reverts or integration issues.

Fix

Consider removing the require(from != to, "you cannot transfer to yourself"); check to align with standard ERC-20 behavior and improve compatibility with existing infrastructure. If this restriction is intentional, thoroughly document its purpose and potential implications for users and integrators.

Status

Unresolved

Low

Missing Event for launch() Function

The launch() function, which transitions the token from a restricted pre-launch state to a fully transferable state, does not emit an event upon successful execution. This makes it challenging for off-chain systems, such as block explorers, dApps, and analytics tools, to programmatically monitor the token's launch status and react accordingly without constantly polling the launched state variable.L-01

Issue

The launch() function, which transitions the token from a restricted pre-launch state to a fully transferable state, does not emit an event upon successful execution. This makes it challenging for off-chain systems, such as block explorers, dApps, and analytics tools, to programmatically monitor the token's launch status and react accordingly without constantly polling the launched state variable.

Fix

Emit an event (e.g., event Launched(address indexed caller, uint256 timestamp);) when the launch() function is successfully called. This provides a clear, auditable, and easily monitorable signal for off-chain services.

Status

Unresolved

Info

Assembly Usage in _revert Function

The _revert function within the Address library uses inline assembly to handle reverts with custom error data. While this approach is functional and can be efficient for forwarding raw revert data, direct assembly usage can sometimes reduce code readability and increase the potential for subtle errors compared to higher-level Solidity constructs. In Solidity 0.8.x, abi.decode and revert can often achieve similar results for string error messages.I-01

Issue

The _revert function within the Address library uses inline assembly to handle reverts with custom error data. While this approach is functional and can be efficient for forwarding raw revert data, direct assembly usage can sometimes reduce code readability and increase the potential for subtle errors compared to higher-level Solidity constructs. In Solidity 0.8.x, abi.decode and revert can often achieve similar results for string error messages.

Fix

Review if the assembly usage in _revert is strictly necessary for its intended purpose. If a more idiomatic Solidity approach can achieve the same functionality with improved readability and maintainability, consider refactoring. However, for a utility library function designed for precise error forwarding, the current implementation may be acceptable.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Erc20 token contract implements a standard ERC-20 interface with an Ownable access control pattern. It includes a unique 'launched' state mechanism that restricts transfers to/from contracts before launch, providing a controlled distribution phase. The contract utilizes Solidity 0.8.24, benefiting from built-in overflow/underflow protections. Identified issues primarily relate to the implications of the pre-launch transfer restrictions and a non-standard self-transfer prohibition.

Technical9/10Low risk

The contract is written in Solidity 0.8.24, which includes built-in overflow/underflow checks, enhancing code security (7.2 Code Security). It uses the Address library for safe low-level calls. A key architectural feature is the 'launched' state, which restricts transfers to/from contracts before activation, potentially causing integration issues for dApps or DEXes (7.1 Architecture). Additionally, the contract explicitly disallows self-transfers, deviating from standard ERC-20 behavior (7.2 Code Security).

Governance9/10Low risk

The contract employs the Ownable pattern, granting the deployer significant control, particularly over the 'launch' function (7.3 Access Control). Before the token is 'launched', transfers to or from any contract address are prohibited, which is an economic control mechanism to manage initial distribution (7.4 Economic). The owner also has a special transferFrom privilege before launch. This centralized control over the launch phase introduces a medium governance risk, as the owner's action dictates the token's full functionality (7.5 Governance).

Upgrades10/10Low risk

The contract is not designed to be upgradeable; it does not implement any proxy patterns (7.7 Upgrades). This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or logic errors during upgrades. The use of immutable for totalSupply and decimals confirms its non-upgradeable nature.

Final RecommendationWhat to do about this score

It is recommended to thoroughly document the pre-launch transfer restrictions and the self-transfer prohibition to ensure all users and integrating protocols are aware of these non-standard behaviors.

Consider emitting an event when the launch() function is called to provide better off-chain monitoring capabilities. Review the necessity of disallowing self-transfers to maintain broader ERC-20 compatibility.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2y
Contract0xb1a0…f25d
Deployer0xe656…97ac
Badge for your website
Mr. Miggles security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 17, 20260Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the MIGGLES contract address?

The Mr. Miggles (MIGGLES) contract on Base is 0xb1a03eda10342529bbf8eb700a06c60441fef25d. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Mr. Miggles a scam?

Quantum Audit's risk score for Mr. Miggles 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.

Is MIGGLES liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $584.8K.

Who holds MIGGLES?

As of Sep 4, 2026, the 10 largest holders own 22.9% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Unit 00 - ReiREI · Base0LowBrettBase0LowKeyboard CatKEYCAT · Base1Lowmfercoin$MFER · Base3LowdoginmeBase3LowToshiBase5Low

Would You Like a More Detailed Audit of Mr. Miggles?

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