Quantum Audit Logo

Is Lotto Coin a Scam?

Early-stage security check — honeypot & rug-pull analysis

Lotto Coin LOTTO
0x908b…679c
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 9d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract implements an ERC20 token with vesting functionalities, utilizing Solady libraries for efficiency and security. It operates as an upgradeable proxy, correctly using the `Initializable` pattern. Key features include a temporary balance limit, vesting schedules with cliff and duration, and a controller role for specific administrative actions. While the core ERC20 and vesting logic appears sound, the audit identified several areas of concern related to access control immutability, misleading function naming, and high token concentration limits, leading to a Medium overall risk level.

1 High2 Medium2 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$577.6K
Liquidity
$559.0K
Price
$0.000775
Token Age
1d
Top 10 Holders
78.2%

Security Findings

1 High2 Med2 Low2 Info
High

Centralization Risk: Immutable Controller and Inflexible Exclusion List

H-01The `controller` address, which is authorized to call `disableBalanceLimit`, is set only during the `initialize` function and cannot be changed thereafter. If the controller's private key is lost or compromised, the ability to manage the balance limit is permanently affected. Similarly, the `isExcludedFromBalanceLimit` mapping is primarily populated during initialization and when `lockPool` is called. There is no function to add or remove addresses from this exclusion list post-initialization, leading to significant operational inflexibility. For example, if a new exchange or critical protocol integration requires exclusion, it cannot be done without an upgrade.
IssueThe `controller` address, which is authorized to call `disableBalanceLimit`, is set only during the `initialize` function and cannot be changed thereafter. If the controller's private key is lost or compromised, the ability to manage the balance limit is permanently affected. Similarly, the `isExcludedFromBalanceLimit` mapping is primarily populated during initialization and when `lockPool` is called. There is no function to add or remove addresses from this exclusion list post-initialization, leading to significant operational inflexibility. For example, if a new exchange or critical protocol integration requires exclusion, it cannot be done without an upgrade.
FixImplement a mechanism for the owner (preferably a multi-signature wallet) to update the `controller` address. Introduce functions, callable by the owner, to add or remove addresses from the `isExcludedFromBalanceLimit` mapping. This enhances operational flexibility and reduces single points of failure.
StatusUnresolved
Medium

Misleading Function Name `lockPool`

M-01The `lockPool` function's name is misleading. Despite its name, it does not 'lock' the pool's ability to transfer tokens or interact with the contract in any restrictive way beyond adding it to the `isExcludedFromBalanceLimit` mapping. The `isPoolLocked` state variable, set by this function, only gates subsequent calls to `lockPool` and `unlockPool` and has no direct impact on token transfer logic. This could lead to incorrect assumptions about the contract's behavior and potential operational errors.
IssueThe `lockPool` function's name is misleading. Despite its name, it does not 'lock' the pool's ability to transfer tokens or interact with the contract in any restrictive way beyond adding it to the `isExcludedFromBalanceLimit` mapping. The `isPoolLocked` state variable, set by this function, only gates subsequent calls to `lockPool` and `unlockPool` and has no direct impact on token transfer logic. This could lead to incorrect assumptions about the contract's behavior and potential operational errors.
FixRename the `lockPool` function to accurately reflect its functionality, e.g., `addPoolToBalanceLimitExclusion` or `setPoolExclusionStatus`. Update documentation to clearly explain its actual effect.
StatusUnresolved
Medium

Lack of Emergency Stop/Pause Mechanism

M-02The contract lacks a general emergency stop or pause mechanism. In the event of a critical vulnerability, exploit, or unforeseen issue affecting the token or its ecosystem, there is no way for the owner or a designated role to temporarily halt transfers or vesting releases to prevent further damage. This is a common security feature in critical smart contracts.
IssueThe contract lacks a general emergency stop or pause mechanism. In the event of a critical vulnerability, exploit, or unforeseen issue affecting the token or its ecosystem, there is no way for the owner or a designated role to temporarily halt transfers or vesting releases to prevent further damage. This is a common security feature in critical smart contracts.
FixConsider implementing a `Pausable` mechanism (e.g., from Solady or OpenZeppelin) that allows the owner to pause and unpause critical functions like `_transfer` and `release`. This provides a crucial safety net for incident response.
StatusUnresolved
Low

High Pre-Mint Allocation Limits

L-01The constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are both set to `0.8 ether`. Assuming `WAD = 1e18`, this means up to 80% of the `initialSupply` can be allocated to a single beneficiary, and the total pre-minted amount can be up to 80% of the `initialSupply`. While technically consistent, allowing such a high concentration of vested tokens to a single address or in total could lead to significant centralization of token distribution, potentially impacting market dynamics or decentralization goals.
IssueThe constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are both set to `0.8 ether`. Assuming `WAD = 1e18`, this means up to 80% of the `initialSupply` can be allocated to a single beneficiary, and the total pre-minted amount can be up to 80% of the `initialSupply`. While technically consistent, allowing such a high concentration of vested tokens to a single address or in total could lead to significant centralization of token distribution, potentially impacting market dynamics or decentralization goals.
FixReview these allocation limits to ensure they align with the project's desired token distribution strategy and decentralization objectives. If a more distributed initial allocation is desired, these constants should be adjusted.
StatusUnresolved
Low

Potential Gas Limit Issues for `computeAvailableVestedAmount`

L-02The `computeAvailableVestedAmount(address beneficiary)` function iterates through all `_scheduleIdsOf[beneficiary]` to sum up available amounts. If a beneficiary has an extremely large number of individual vesting schedules, this loop could potentially consume a significant amount of gas, possibly approaching the block gas limit for a single transaction. While unlikely for typical usage, it represents an edge case for denial-of-service for specific beneficiaries.
IssueThe `computeAvailableVestedAmount(address beneficiary)` function iterates through all `_scheduleIdsOf[beneficiary]` to sum up available amounts. If a beneficiary has an extremely large number of individual vesting schedules, this loop could potentially consume a significant amount of gas, possibly approaching the block gas limit for a single transaction. While unlikely for typical usage, it represents an edge case for denial-of-service for specific beneficiaries.
FixConsider if there's a practical limit to the number of schedules a single beneficiary might have. If this number could grow very large, explore alternative designs, such as paginated retrieval of available amounts or a mechanism to claim all available amounts in batches.
StatusUnresolved
Info

Vesting Schedule Creation Limited to Initialization

I-01Vesting schedules (`vestingSchedules` array) can only be created during the `initialize` function. There is no public or owner-controlled function to add new vesting schedules post-initialization. This design choice limits the flexibility of the vesting mechanism, requiring a contract upgrade if new vesting terms are needed for future allocations or programs.
IssueVesting schedules (`vestingSchedules` array) can only be created during the `initialize` function. There is no public or owner-controlled function to add new vesting schedules post-initialization. This design choice limits the flexibility of the vesting mechanism, requiring a contract upgrade if new vesting terms are needed for future allocations or programs.
FixConfirm if this limitation is an intentional design choice. If future flexibility is desired, consider adding an owner-controlled function to create new vesting schedules, ensuring proper validation and access control.
StatusUnresolved
Info

Local Import Path for `Wad.sol`

I-02The contract imports `WAD` from `src/types/Wad.sol`. While functionally correct within the project structure, using a local import path for a fundamental constant like `WAD` (typically `1e18`) means its definition is project-specific rather than relying on a universally recognized library. It's important to ensure `Wad.sol` consistently defines `WAD` as `1e18` to avoid miscalculations in critical economic logic.
IssueThe contract imports `WAD` from `src/types/Wad.sol`. While functionally correct within the project structure, using a local import path for a fundamental constant like `WAD` (typically `1e18`) means its definition is project-specific rather than relying on a universally recognized library. It's important to ensure `Wad.sol` consistently defines `WAD` as `1e18` to avoid miscalculations in critical economic logic.
FixEnsure `src/types/Wad.sol` is correctly defined and its value is `1e18`. For clarity and consistency, consider explicitly defining `WAD = 1e18` within the contract or using a more standard library import if available, although the current approach is not inherently insecure if the definition is correct.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good architectural practices by leveraging battle-tested Solady libraries for ERC20, Ownable, and Initializable functionalities (7.1 Architecture). The code generally follows secure coding standards, with no apparent reentrancy or integer overflow vulnerabilities (7.2 Code Security). However, the immutability of the `controller` role and the `isExcludedFromBalanceLimit` mapping after initialization introduces significant operational inflexibility and centralization risk (7.3 Access Control, 7.8 Operations). Additionally, the `lockPool` function's name is misleading, as it only adds the pool to an exclusion list rather than truly locking its functionality (7.2 Code Security).

GovernanceHigh2/10

The economic model includes a temporary balance limit and vesting schedules, providing structured token distribution. The `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` constants allow for up to 80% of the initial supply to be allocated to a single beneficiary and in total, which could lead to high token concentration (7.4 Economic). The `controller` role, responsible for disabling the balance limit, is immutable post-initialization, posing a centralization risk if the key is compromised or lost (7.5 Governance). There is no general emergency stop mechanism, which is a common security feature for critical contracts (7.8 Operations).

UpgradesLow7/10

The contract correctly implements the upgradeable pattern using Solady's `Initializable` module, including `_disableInitializers()` in the constructor and an `external initializer` function. This design ensures that the contract can be safely upgraded via a proxy mechanism (7.7 Upgrades). The storage layout appears compatible with standard proxy patterns, minimizing risks associated with upgrades. No immediate upgrade safety issues were identified.

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

78.2% in top 10
14.3% in wallets63.9% in contracts
Effective Concentration39.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

$559.0K across 4 pairs
Uniswap v4USDCanalysed$559.0K100.0%Uniswap v4USDC$20.0%Uniswap v4USDC$20.0%Uniswap v4USDC$20.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 Holder58.4%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xc404…84a6
Unlocked LP Held By
0x6358…651b0x3662…ba860x6642…3673

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 > 30% (78.2% total → 39.9% effective; 14.3% in EOAs, 63.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 58.4% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
VelvetHigh RiskDiemHigh RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High RiskUmiaHigh RiskLisk (LSK)High Risk

Would You Like a More Detailed Audit of Lotto Coin?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit