Quantum Audit Logo

Is iPod Safe?

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

iPod IPOD
0xa6af…fee1
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 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract is an upgradeable ERC20 token with vesting functionalities, built using Solady libraries. It includes features for managing vesting schedules, allocating tokens to beneficiaries, and a temporary balance limit mechanism. The contract exhibits good adherence to ERC20 standards and utilizes custom error handling. Key areas of concern include the high degree of centralized control by the owner and controller roles, potential gas limitations for beneficiaries with numerous vesting schedules, and the hardcoded nature of critical economic parameters. The balance limit mechanism, while present, has a significantly narrowed scope due to numerous explicit exclusions.

1 High1 Medium1 Low2 Informational
Volume 24h
$356.2K
Liquidity
$458.9K
Price
$0.001634
Token Age
15d
Top 10 Holders
49.8%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control by Owner and Controller Roles

H-01The `owner` and `controller` roles possess significant power over the contract's critical functionalities. The `owner` can `lockPool`, `unlockPool`, and `updateTokenURI`. The `controller` can `disableBalanceLimit`. While the owner is noted to be an `OZ_ProxyAdmin` (likely a multisig), the contract's architecture still grants these single addresses extensive control, posing a centralization risk. A malicious or compromised owner/controller could significantly impact the protocol's integrity and user funds.
IssueThe `owner` and `controller` roles possess significant power over the contract's critical functionalities. The `owner` can `lockPool`, `unlockPool`, and `updateTokenURI`. The `controller` can `disableBalanceLimit`. While the owner is noted to be an `OZ_ProxyAdmin` (likely a multisig), the contract's architecture still grants these single addresses extensive control, posing a centralization risk. A malicious or compromised owner/controller could significantly impact the protocol's integrity and user funds.
FixImplement a robust multi-signature governance mechanism for all critical administrative functions, including `lockPool`, `unlockPool`, `updateTokenURI`, and `disableBalanceLimit`. This would require multiple trusted parties to approve sensitive operations, significantly reducing the risk associated with a single point of failure or compromise.
StatusUnresolved
Medium

Potential Gas Limit Exceeded for `_releaseAllFor` Iteration

M-01The `_releaseAllFor` function (implied by the external `release` and `releaseFor` functions, and the `getScheduleIdsOf` view function) iterates through all `scheduleIds` associated with a beneficiary via `_scheduleIdsOf[beneficiary]`. If a beneficiary accumulates a very large number of distinct vesting schedules, this loop could potentially consume excessive gas, causing the transaction to exceed the block gas limit and preventing the beneficiary from releasing all their vested tokens in a single transaction.
IssueThe `_releaseAllFor` function (implied by the external `release` and `releaseFor` functions, and the `getScheduleIdsOf` view function) iterates through all `scheduleIds` associated with a beneficiary via `_scheduleIdsOf[beneficiary]`. If a beneficiary accumulates a very large number of distinct vesting schedules, this loop could potentially consume excessive gas, causing the transaction to exceed the block gas limit and preventing the beneficiary from releasing all their vested tokens in a single transaction.
FixConsider implementing a pagination mechanism or a batch release function that allows beneficiaries to release tokens for a subset of their schedules at a time. Alternatively, if the number of schedules is expected to be small, document this limitation clearly. For existing contracts, monitor gas usage for beneficiaries with many schedules.
StatusUnresolved
Low

Hardcoded Vesting and Pre-Mint Parameters

L-01Several critical economic parameters, such as `MAX_PRE_MINT_PER_ADDRESS_WAD`, `MAX_TOTAL_PRE_MINT_WAD`, and `MIN_VESTING_DURATION`, are hardcoded as constants within the contract. These values define fundamental aspects of the token's initial distribution and vesting mechanics. Hardcoding them removes the flexibility to adjust these parameters in response to evolving market conditions, regulatory changes, or protocol needs without requiring a full contract upgrade.
IssueSeveral critical economic parameters, such as `MAX_PRE_MINT_PER_ADDRESS_WAD`, `MAX_TOTAL_PRE_MINT_WAD`, and `MIN_VESTING_DURATION`, are hardcoded as constants within the contract. These values define fundamental aspects of the token's initial distribution and vesting mechanics. Hardcoding them removes the flexibility to adjust these parameters in response to evolving market conditions, regulatory changes, or protocol needs without requiring a full contract upgrade.
FixEvaluate whether these parameters should be made configurable by the owner or a governance mechanism. If flexibility is desired, consider storing these values in state variables that can be updated through a controlled function (e.g., `onlyOwner` or `onlyGovernance`). This would allow for dynamic adjustments without necessitating a contract upgrade.
StatusUnresolved
Info

Limited Scope of Balance Limit Mechanism

I-01The `maxBalanceLimit` feature is designed to restrict token balances for certain addresses during a specified period. However, the contract explicitly excludes the `owner`, the initial `recipient`, all initial vesting `beneficiaries`, and the designated `pool` address from this limit. This design choice significantly narrows the applicability of the balance limit, meaning it only affects a subset of token holders and may not achieve a broad-based control over token distribution.
IssueThe `maxBalanceLimit` feature is designed to restrict token balances for certain addresses during a specified period. However, the contract explicitly excludes the `owner`, the initial `recipient`, all initial vesting `beneficiaries`, and the designated `pool` address from this limit. This design choice significantly narrows the applicability of the balance limit, meaning it only affects a subset of token holders and may not achieve a broad-based control over token distribution.
FixThis is an intended design choice. Ensure that the implications of these exclusions are fully understood and align with the project's economic model and risk management strategy. Clearly communicate the limited scope of the balance limit to users and stakeholders.
StatusUnresolved
Info

Potential for `LibTransient` Slot Collision (Low Probability)

I-02The `LibTransient` library uses a `keccak256` hash (`HAS_SCHEDULE_TRANSIENT_SLOT`) to define a storage slot for a boolean flag. While `keccak256` collisions are extremely rare, using a fixed hash for a storage slot in a general-purpose library could theoretically lead to a collision if another part of the contract or an inherited contract also uses `LibTransient` with the same slot, or if a future upgrade introduces a state variable at that specific storage slot. This is a very low probability risk.
IssueThe `LibTransient` library uses a `keccak256` hash (`HAS_SCHEDULE_TRANSIENT_SLOT`) to define a storage slot for a boolean flag. While `keccak256` collisions are extremely rare, using a fixed hash for a storage slot in a general-purpose library could theoretically lead to a collision if another part of the contract or an inherited contract also uses `LibTransient` with the same slot, or if a future upgrade introduces a state variable at that specific storage slot. This is a very low probability risk.
FixFor future upgrades or when integrating other libraries, perform a thorough storage slot analysis to ensure no unintended collisions occur. While the probability is minimal, awareness of this pattern is important for long-term contract maintenance and upgrade safety.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates a solid technical foundation, utilizing Solady libraries for robust ERC20 and Ownable implementations (7.2 Code Security). Custom error handling is well-implemented, improving clarity. However, a potential gas limitation exists in the `_releaseAllFor` function if a beneficiary has an excessively large number of vesting schedules, which could hinder token release (7.2 Code Security). The use of `LibTransient` for storage flags is an interesting pattern, though its slot collision risk is extremely low (7.2 Code Security).

GovernanceMedium4/10

The contract design incorporates significant centralized control, with the `owner` able to lock/unlock the pool and update the token URI, and the `controller` able to disable the balance limit (7.3 Access Control, 7.5 Governance). This centralization, while common, represents a single point of failure. Critical economic parameters like pre-mint limits and minimum vesting durations are hardcoded, limiting flexibility for future adjustments without an upgrade (7.4 Economic). The balance limit mechanism's scope is significantly reduced by explicit exclusions for key addresses, impacting its overall effectiveness (7.4 Economic).

UpgradesLow7/10

The contract is designed for upgradeability using the `Initializable` pattern from Solady, with the constructor correctly disabling initializers (7.7 Upgrades). The `OZ_ProxyAdmin` managing the proxy suggests a standard and secure upgrade path (7.7 Upgrades). No immediate upgrade safety issues were identified within the provided implementation code, assuming proper storage slot management in future versions.

Security Checklist

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

Holder Composition

49.8% in top 10
4.5% in wallets45.4% in contracts
Effective Concentration22.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

$462.5K across 10 pairs
Uniswap v4AAPLcanalysed$458.9K99.2%Uniswap v4USDC$2.9K0.6%Uniswap v4USDC$5050.1%Uniswap v4USDC$960.0%Uniswap v4ETH$320.0%Uniswap v4USDC$110.0%
Show 3 more pairsShow less
Uniswap v4USDC$60.0%Uniswap v4USDC$60.0%Uniswap v4ETH$10.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 Holder80.6%
Top-3 Unlocked97.3%

Key Addresses

6 addresses
Deployer
0x8c4b…ac0b
Unlocked LP Held By
0xe6fc…71f10xc796…6c470xc43a…d5160x0f44…33860x87d8…d0db

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

What Raised This Score

9 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (49.8% total → 22.6% effective; 4.5% in EOAs, 45.4% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 80.6% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 97.3% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 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
Coinbase Wrapped Staked ETH (CBETH)High RiskThe Innovation Game (TIG)High RiskBasemateHigh RiskCAPACITRHigh RiskKAITOHigh RiskA Society For AI Agents (1F916)High Risk

Would You Like a More Detailed Audit of iPod?

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

Get Detailed Audit