Is Mr. Miggles (MIGGLES) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Control and Pre-Launch Transfer Restrictions

H-01The `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…

IssueThe `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…

FixEnsure 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.

StatusUnresolved

Medium

Non-Standard Self-Transfer Restriction

M-01The `_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.

IssueThe `_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.

FixConsider 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.

StatusUnresolved

Low

Missing Event for `launch()` Function

L-01The `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.

IssueThe `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.

FixEmit 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.

StatusUnresolved

Info

Assembly Usage in `_revert` Function

I-01The `_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.

IssueThe `_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.

FixReview 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.

StatusUnresolved

Category Ratings

TechnicalLow9/10

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).

GovernanceLow9/10

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).

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

22.9% in top 10

13.2% in wallets9.7% in contracts

Effective Concentration17.1%

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

$584.8K across 16 pairs

Uniswap v2WETHanalysed$528.0K Uniswap v3WETH$18.8K Uniswap v4USDC$15.2K Uniswap v4USDC$14.4K AerodromeWETH$3.7K Uniswap v3USDC$1.5K

Show 4 more pairsShow less

Hydrex CLAMMWETH$1.1K 0xba34…EEF9WETH$748 Uniswap v4ETH$572 Uniswap v3WETH$350

The 6 remaining pairs hold $374 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

LP Burned100.0% · ≈ permanent lock

LP Locked100.0%

Key Addresses

10 addresses

Deployer

0xe656…97ac

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.

What Raised This Score

3 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

Is Mr. Miggles Safe?

Security Findings

Centralized Control and Pre-Launch Transfer Restrictions

Non-Standard Self-Transfer Restriction

Missing Event for `launch()` Function

Assembly Usage in `_revert` Function

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

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