Quantum Audit Logo

Is This Is My Iguana Safe?

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

This Is My Iguana TIMI
0x9bee…3777
Base
Not verifiedThis 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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The Erc20 token contract implements standard ERC-20 functionality with an Ownable access control pattern. While leveraging Solidity 0.8.24 for built-in safety and a robust Address library, the contract exhibits critical centralization risks. Specifically, the owner possesses an unrestricted ability to transfer tokens from any address to their own before the token is officially 'launched', bypassing standard ERC-20 approvals. Additionally, the owner has complete control over the token's launch state, which dictates its ability to interact with other smart contracts, and holds the entire initial token supply. These factors introduce significant potential for rug pulls and market manipulation.

1 Critical1 High1 Medium1 Low
Volume 24h
$45.8K
Liquidity
$50.0K
Price
$0.0001009
Token Age
2y
Top 10 Holders
43.6%

Security Findings

1 Crit1 High1 Med1 Low
Critical

Owner's Unrestricted `transferFrom` Before Launch

C-01The `transferFrom` function contains a condition `if (launched == false && to == owner() && msg.sender == owner())` that allows the contract owner to transfer any amount of tokens from any `from` address to their own address (`owner()`) without requiring prior approval (`_allowed`). This bypasses the standard ERC-20 allowance mechanism and grants the owner arbitrary token transfer capabilities before the token is launched, posing a critical centralization risk and potential for a rug pull.
IssueThe `transferFrom` function contains a condition `if (launched == false && to == owner() && msg.sender == owner())` that allows the contract owner to transfer any amount of tokens from any `from` address to their own address (`owner()`) without requiring prior approval (`_allowed`). This bypasses the standard ERC-20 allowance mechanism and grants the owner arbitrary token transfer capabilities before the token is launched, posing a critical centralization risk and potential for a rug pull.
FixRemove the special condition `if (launched == false && to == owner() && msg.sender == owner())` from the `transferFrom` function. All `transferFrom` operations should strictly adhere to the `_allowed` mapping, regardless of the `launched` state or the `msg.sender`.
StatusUnresolved
High

Centralized Control Over Token Launch and Contract Interactions

H-01The `launched` state, controlled solely by the `onlyOwner` function `launch()`, dictates whether the token can interact with other smart contracts (e.g., DEXes, DeFi protocols) via the `_transferAllowed` function. If the owner chooses not to call `launch()`, the token remains unusable in the broader DeFi ecosystem, severely impacting its utility and liquidity. This grants the owner significant power to control the token's market viability and adoption.
IssueThe `launched` state, controlled solely by the `onlyOwner` function `launch()`, dictates whether the token can interact with other smart contracts (e.g., DEXes, DeFi protocols) via the `_transferAllowed` function. If the owner chooses not to call `launch()`, the token remains unusable in the broader DeFi ecosystem, severely impacting its utility and liquidity. This grants the owner significant power to control the token's market viability and adoption.
FixConsider implementing a decentralized mechanism or a timelock for the `launch()` function to reduce single-point-of-failure risk. Alternatively, clearly document this centralized control and its implications for users and potential integrators.
StatusUnresolved
Medium

Initial Token Distribution Centralization

M-01The entire `totalSupply` is minted to the `owner()` address in the constructor (`_balances[owner()] += _totalSupply;`). While common for new tokens, this high degree of centralization, especially when combined with the owner's ability to bypass `transferFrom` approvals before launch (C-01), means the owner has complete control over the token supply and its initial distribution. This could lead to market manipulation or a rug pull scenario.
IssueThe entire `totalSupply` is minted to the `owner()` address in the constructor (`_balances[owner()] += _totalSupply;`). While common for new tokens, this high degree of centralization, especially when combined with the owner's ability to bypass `transferFrom` approvals before launch (C-01), means the owner has complete control over the token supply and its initial distribution. This could lead to market manipulation or a rug pull scenario.
FixImplement a more distributed initial token allocation strategy, such as vesting schedules, airdrops, or a public sale, to reduce the concentration of tokens in a single address. If full centralization is intended, ensure this is explicitly communicated to all users.
StatusUnresolved
Low

Lack of Event Emission for `_transferAllowed` Restrictions

L-01The `_transferAllowed` function implements critical logic that restricts transfers to/from contract addresses before the token is launched. However, there's no event emitted when a transfer is blocked due to these restrictions. This lack of visibility makes it harder for users and off-chain systems to understand why a transfer failed, potentially leading to confusion or a poor user experience.
IssueThe `_transferAllowed` function implements critical logic that restricts transfers to/from contract addresses before the token is launched. However, there's no event emitted when a transfer is blocked due to these restrictions. This lack of visibility makes it harder for users and off-chain systems to understand why a transfer failed, potentially leading to confusion or a poor user experience.
FixConsider emitting a custom event (e.g., `TransferRestricted(address indexed from, address indexed to, uint256 value, string reason)`) within the `_transfer` function when `_transferAllowed` returns `false`. This would provide clearer debugging information and transparency.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages Solidity 0.8.24, providing built-in overflow/underflow protection, and incorporates the robust `Address` library for safe low-level calls (7.2 Code Security). The `Ownable` pattern is correctly implemented for access control (7.3 Access Control). However, a critical flaw exists in `transferFrom` allowing the owner to bypass allowances before launch (7.3 Access Control), and the `launched` state introduces significant centralized control over token functionality (7.1 Architecture).

GovernanceLow8/10

The token's economic model is highly centralized, with the entire initial supply minted to the owner (7.4 Economic). This, combined with a critical `transferFrom` bypass for the owner before the token is launched, creates a severe rug pull risk (7.4 Economic). Furthermore, the owner retains sole control over the `launch()` function, which dictates the token's ability to interact with other contracts and DEXes, significantly impacting its market viability and liquidity (7.5 Governance).

UpgradesLow9/10

The contract is not designed with upgradeability in mind, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates upgrade-related risks such as proxy misconfigurations or malicious implementation changes. However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a new deployment.

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

43.6% in top 10
17.4% in wallets26.2% in contracts
Effective Concentration27.9%

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

$50.2K across 4 pairs
Uniswap v2WETHanalysed$50.0K99.7%AerodromeWETH$1580.3%Uniswap v3WETH$160.0%AerodromeBRETT$00.0%

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

2 addresses
Deployer
0xd72c…48c4
Unlocked LP Held By
0x10c4…ddae

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

What Raised This Score

5 factors
  • Top-10 concentration > 20% (43.6% total → 27.9% effective; 17.4% in EOAs, 26.2% in contracts — mild)
  • 1 Critical finding(s) from audit
  • 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

Related Audits

6 more on the record
ClawBankLow RiskRUSSELLLow RiskBasecatLow RiskSKI MASK DOG (SKI)Low RiskDebtReliefBot (DRB)Low RiskSPARKLow Risk

Would You Like a More Detailed Audit of This Is My Iguana?

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

Get Detailed Audit