Quantum Audit Logo

Is ODEI AI Safe?

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

ODEI AI ODAI
0x0086…d959
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? → Medium Risk
Executive SummaryAI Copilot

The Memecoin contract, serving as an upgradeable ERC20 token, demonstrates a solid foundation built upon OpenZeppelin's battle-tested libraries and Solidity 0.8+. It integrates cross-chain functionality and ERC20Votes for potential governance. However, the contract exhibits significant centralization risks due to its heavy reliance on the Flaunch contract for critical functions like minting and metadata management. The audit also identified a design choice regarding irreversible infinite allowance for Permit2 and noted the incomplete Flaunch contract code, which limits a full assessment of external dependencies.

1 High2 Medium1 Low1 Informational
Volume 24h
$39.4K
Liquidity
$144.4K
Price
$0.000004532
Token Age
7mo
Top 10 Holders
37.1%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control over Token Supply and Metadata

H-01The `mint` and `setMetadata` functions in the Memecoin contract are restricted to the `Flaunch` contract via the `onlyFlaunch` modifier. This grants the `Flaunch` contract, and by extension its owner, complete and centralized control over the token's total supply (through arbitrary minting) and its public metadata (name and symbol). A compromise of the `Flaunch` contract or a malicious action by its owner could lead to arbitrary token inflation or misleading token information, severely undermining the Memecoin's integrity and value.
IssueThe `mint` and `setMetadata` functions in the Memecoin contract are restricted to the `Flaunch` contract via the `onlyFlaunch` modifier. This grants the `Flaunch` contract, and by extension its owner, complete and centralized control over the token's total supply (through arbitrary minting) and its public metadata (name and symbol). A compromise of the `Flaunch` contract or a malicious action by its owner could lead to arbitrary token inflation or misleading token information, severely undermining the Memecoin's integrity and value.
FixImplement a more decentralized or time-locked approach for critical functions like minting and metadata changes. Consider introducing a multi-signature wallet or a governance mechanism (e.g., via ERC20Votes) for `Flaunch`'s owner to approve such actions. If full decentralization is not feasible, ensure the `Flaunch` contract itself is secured with robust access controls and audited thoroughly.
StatusUnresolved
Medium

Irreversible Infinite Allowance for Permit2

M-01The Memecoin contract implements special logic for the `_PERMIT2` address (0x00...8BA3). The `allowance` function is overridden to always return `type(uint).max` for `_PERMIT2`, and the `approve` function reverts if an approval for `_PERMIT2` is attempted with any amount other than `type(uint).max`. This design choice means that once a user interacts with Permit2 for this token, they effectively grant an irreversible infinite allowance to Permit2, which cannot be revoked or reduced. While this is a common pattern for Permit2 integration, it represents a significant security consideration for users who might not fully understand the implications of granting such an allowance.
IssueThe Memecoin contract implements special logic for the `_PERMIT2` address (0x00...8BA3). The `allowance` function is overridden to always return `type(uint).max` for `_PERMIT2`, and the `approve` function reverts if an approval for `_PERMIT2` is attempted with any amount other than `type(uint).max`. This design choice means that once a user interacts with Permit2 for this token, they effectively grant an irreversible infinite allowance to Permit2, which cannot be revoked or reduced. While this is a common pattern for Permit2 integration, it represents a significant security consideration for users who might not fully understand the implications of granting such an allowance.
FixClearly communicate this irreversible infinite allowance behavior to users interacting with Permit2. Consider adding documentation or warnings within the dApp interface to ensure users are fully aware of the implications before approving Permit2. While a design choice, transparency is key to user security.
StatusUnresolved
Medium

High Dependency on External Flaunch Contract Security

M-02The Memecoin contract exhibits a high degree of dependency on the external `Flaunch` contract. Critical functionalities such as token minting permissions (`onlyFlaunch` modifier), retrieving the token's creator (`creator()`), and determining the treasury address (`treasury()`) all rely on calls to the `Flaunch` contract. The security and correct functioning of Memecoin are therefore directly tied to the security and integrity of the `Flaunch` contract. Any vulnerability, exploit, or malicious action within `Flaunch` could directly compromise the Memecoin contract and its ecosystem.
IssueThe Memecoin contract exhibits a high degree of dependency on the external `Flaunch` contract. Critical functionalities such as token minting permissions (`onlyFlaunch` modifier), retrieving the token's creator (`creator()`), and determining the treasury address (`treasury()`) all rely on calls to the `Flaunch` contract. The security and correct functioning of Memecoin are therefore directly tied to the security and integrity of the `Flaunch` contract. Any vulnerability, exploit, or malicious action within `Flaunch` could directly compromise the Memecoin contract and its ecosystem.
FixConduct a comprehensive and independent security audit of the `Flaunch` contract to identify and mitigate any potential vulnerabilities. Ensure that `Flaunch` adheres to best security practices, including robust access control, reentrancy protection, and secure handling of external calls. Implement monitoring for `Flaunch` to detect any unusual activity.
StatusUnresolved
Low

Potential for `flaunch` Address Misconfiguration During Upgrade

L-01The `flaunch` address, which is critical for access control and functionality, is set during the `initialize` function. While OpenZeppelin's `initializer` modifier prevents re-initialization of the same function, there is a theoretical risk during future contract upgrades. If a new `initialize` function is introduced in an upgrade, or if a vulnerability allows bypassing the `initializer` modifier, the `flaunch` address could be reset to an arbitrary or malicious address. This could lead to an attacker gaining control over minting and metadata functions.
IssueThe `flaunch` address, which is critical for access control and functionality, is set during the `initialize` function. While OpenZeppelin's `initializer` modifier prevents re-initialization of the same function, there is a theoretical risk during future contract upgrades. If a new `initialize` function is introduced in an upgrade, or if a vulnerability allows bypassing the `initializer` modifier, the `flaunch` address could be reset to an arbitrary or malicious address. This could lead to an attacker gaining control over minting and metadata functions.
FixWhen performing upgrades, meticulously review all new code, especially any `initialize` functions or constructor logic, to ensure that the `flaunch` address cannot be inadvertently or maliciously reset. Adhere strictly to upgradeable contract best practices, including using `_gap` storage for future state variables to prevent storage collisions and thorough testing of upgrade paths.
StatusUnresolved
Info

Incomplete Flaunch Contract Code Provided

I-01The provided source code for the `Flaunch` contract is truncated. As the `Memecoin` contract heavily relies on `Flaunch` for critical functionalities such as minting permissions, creator information, and treasury addresses, a full security assessment of `Memecoin`'s external dependencies, especially the `Flaunch` contract's logic, could not be completed. This limits the scope of the current audit regarding the overall ecosystem's security.
IssueThe provided source code for the `Flaunch` contract is truncated. As the `Memecoin` contract heavily relies on `Flaunch` for critical functionalities such as minting permissions, creator information, and treasury addresses, a full security assessment of `Memecoin`'s external dependencies, especially the `Flaunch` contract's logic, could not be completed. This limits the scope of the current audit regarding the overall ecosystem's security.
FixProvide the complete and verified source code for the `Flaunch` contract to enable a comprehensive security audit of the entire system. This is crucial for understanding the full risk profile of the Memecoin token.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The Memecoin contract demonstrates robust technical foundations, leveraging battle-tested OpenZeppelin upgradeable contracts and Solidity 0.8+ for arithmetic safety (7.2 Code Security). It integrates cross-chain functionality via Optimism's `SUPERCHAIN_TOKEN_BRIDGE` for secure cross-chain minting/burning (7.6 External). However, a significant concern is the centralized control granted to the `Flaunch` contract, which can arbitrarily `mint` tokens and `setMetadata` (7.3 Access Control). This high dependency on `Flaunch` introduces a single point of failure for the token's integrity (7.1 Architecture).

GovernanceMedium6/10

The Memecoin contract incorporates `ERC20VotesUpgradeable`, enabling potential on-chain governance mechanisms and automatic delegation upon transfer, which is a positive for decentralized control (7.5 Governance). However, the economic stability is heavily reliant on the `Flaunch` contract's minting policies, which are not fully auditable due to truncated code, posing an unknown risk to token supply (7.4 Economic). Furthermore, the irreversible infinite allowance granted to `_PERMIT2` is a design choice that could lead to unexpected user behavior or perceived loss of control over allowances (7.4 Economic).

UpgradesMedium6/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `Initializable` pattern, ensuring a secure upgrade path (7.7 Upgrades). The `_disableInitializers` in the constructor and the `initializer` modifier mitigate re-initialization risks. However, careful consideration must be given to storage slot management in future upgrades to prevent collisions, especially if new state variables are introduced (7.7 Upgrades). Additionally, the `flaunch` address, set during initialization, could be vulnerable to misconfiguration if an upgrade introduces a new `initialize` function or bypasses existing safeguards (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

37.1% in top 10
4.7% in wallets32.4% in contracts
Effective Concentration17.6%

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

$144.6K across 3 pairs
Uniswap v4flETHanalysed$144.4K99.8%Uniswap v4ETH$2010.1%Uniswap v4USDC$240.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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xf1a7…56f9
Unlocked LP Held By
0x48d1…93fa

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

What Raised This Score

7 factors
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 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
Aave Token (AAVE)Medium RiskBaseUncMedium RiskRollMedium RiskOpenGradient (OPG)Medium RiskZoraMedium RiskHorizen (ZEN)Medium Risk

Would You Like a More Detailed Audit of ODEI AI?

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

Get Detailed Audit