Quantum Audit Logo

Is CONDO a Scam?

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

Is this your token? Publish your own audit on this page →

CONDO CONDO
0xfe99…9b26
Ethereum
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.Own this token? Put it under verification →
Last checked today 1 audit on record New Launch · 4d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The LaunchToken contract implements an ERC-20 token with unique features including buy/hold caps, a launch guard period, and a holder reward distribution mechanism. The contract leverages OpenZeppelin libraries for standard ERC-20 functionality. Key findings include a critical integer overflow vulnerability in reward calculations, a high centralization risk associated with the `factory` role, and potential for rewards to become stuck under specific conditions. Several minor issues related to error message clarity, event logging, and unused variables were also identified. The contract operates as an implementation behind a proxy, making the `initialize` function and `factory` role critical for secure deployment and future upgrades.

1 Critical1 High2 Medium2 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (4d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.14M
Liquidity
$181.9K
Price
$0.001155
Token Age
4d
Top 10 Holders
23.2%

Security Findings

1 Crit1 High2 Med2 Low1 Info
Critical

Integer Overflow in Reward Calculation

C-01The calculations `(total * ACC_PRECISION) / eligibleSupply` in `notifyReward` and `(balanceOf(account) * accRewardPerToken) / ACC_PRECISION` in `pendingReward`, `_settle`, and `_rebase` are susceptible to integer overflow. Specifically, `total * ACC_PRECISION` and `balanceOf(account) * accRewardPerToken` can exceed `type(uint256).max` if `total` or `balanceOf(account)` are sufficiently large, especially when `eligibleSupply` is small, causing `accRewardPerToken` to grow rapidly. An overflow would lead to incorrect reward calculations, potentially resulting in a denial of service for reward distribution or an attacker being able to manipulate reward values.
IssueThe calculations `(total * ACC_PRECISION) / eligibleSupply` in `notifyReward` and `(balanceOf(account) * accRewardPerToken) / ACC_PRECISION` in `pendingReward`, `_settle`, and `_rebase` are susceptible to integer overflow. Specifically, `total * ACC_PRECISION` and `balanceOf(account) * accRewardPerToken` can exceed `type(uint256).max` if `total` or `balanceOf(account)` are sufficiently large, especially when `eligibleSupply` is small, causing `accRewardPerToken` to grow rapidly. An overflow would lead to incorrect reward calculations, potentially resulting in a denial of service for reward distribution or an attacker being able to manipulate reward values.
FixImplement explicit overflow checks for the multiplication operations `total * ACC_PRECISION` and `balanceOf(account) * accRewardPerToken`. Consider using OpenZeppelin's `SafeMath` library or similar custom checks to prevent these overflows. Ensure that intermediate products do not exceed `type(uint256).max` before division.
StatusUnresolved
High

Centralization Risk with `factory` Role

H-01The `factory` address has extensive control over critical contract functions, including setting the `market`, enabling holder fees, and being a valid `rewardSource`. More critically, the `factory` can manipulate the `eligibleSupply` by arbitrarily excluding and including addresses from reward participation via `_setRewardExcluded`. This allows the `factory` to potentially drain accumulated `carriedReward` or disproportionately accumulate rewards by excluding all other holders and then re-including themselves. This centralizes significant power, creating a single point of failure and a high trust requirement in the `factory` operator.
IssueThe `factory` address has extensive control over critical contract functions, including setting the `market`, enabling holder fees, and being a valid `rewardSource`. More critically, the `factory` can manipulate the `eligibleSupply` by arbitrarily excluding and including addresses from reward participation via `_setRewardExcluded`. This allows the `factory` to potentially drain accumulated `carriedReward` or disproportionately accumulate rewards by excluding all other holders and then re-including themselves. This centralizes significant power, creating a single point of failure and a high trust requirement in the `factory` operator.
FixConsider implementing a multi-signature wallet for the `factory` role to distribute control. For highly sensitive actions like `_setRewardExcluded`, implement a time-lock mechanism or a community governance vote to provide transparency and allow users to react to changes. Clearly document the powers of the `factory` role.
StatusUnresolved
Medium

Potential for Stuck Rewards if `eligibleSupply` is Zero

M-01If `eligibleSupply` remains zero for an extended period, all `notifyReward` calls will only increase `carriedReward`. While `carriedReward` is eventually added to `total` when `eligibleSupply` becomes non-zero, there's no explicit mechanism to force `eligibleSupply` to be non-zero if all token holders are excluded or if the token is held entirely by excluded addresses. This could lead to rewards being indefinitely stuck in `carriedReward` if no eligible supply ever emerges.
IssueIf `eligibleSupply` remains zero for an extended period, all `notifyReward` calls will only increase `carriedReward`. While `carriedReward` is eventually added to `total` when `eligibleSupply` becomes non-zero, there's no explicit mechanism to force `eligibleSupply` to be non-zero if all token holders are excluded or if the token is held entirely by excluded addresses. This could lead to rewards being indefinitely stuck in `carriedReward` if no eligible supply ever emerges.
FixImplement a mechanism to allow the `factory` or a governance entity to re-enable `eligibleSupply` if it becomes zero, perhaps by forcing the inclusion of a specific address or by allowing a portion of `carriedReward` to be recovered if it remains stuck for a prolonged period. Alternatively, consider a fallback mechanism for `carriedReward` distribution if `eligibleSupply` remains zero.
StatusUnresolved
Medium

`MarketAlreadySet` Error Misuse in `enableHolderFees`

M-02The `enableHolderFees` function uses `revert MarketAlreadySet()` when `holderFeesEnabled` is true. This is misleading as the error message suggests the market is already set, not that holder fees are already enabled. While functionally correct, it impacts user experience and clarity, potentially causing confusion for users or integrators.
IssueThe `enableHolderFees` function uses `revert MarketAlreadySet()` when `holderFeesEnabled` is true. This is misleading as the error message suggests the market is already set, not that holder fees are already enabled. While functionally correct, it impacts user experience and clarity, potentially causing confusion for users or integrators.
FixCreate a specific error message for when holder fees are already enabled, such as `revert HolderFeesAlreadyEnabled()`. This improves clarity and user experience.
StatusUnresolved
Low

Lack of Event for `_setRewardExcluded`

L-01The `_setRewardExcluded` internal function, which significantly impacts reward distribution by changing `eligibleSupply` and `rewardExcluded` status, does not emit an event. This makes it difficult to track changes to reward exclusion status and `eligibleSupply` on-chain, hindering transparency and monitoring by external parties.
IssueThe `_setRewardExcluded` internal function, which significantly impacts reward distribution by changing `eligibleSupply` and `rewardExcluded` status, does not emit an event. This makes it difficult to track changes to reward exclusion status and `eligibleSupply` on-chain, hindering transparency and monitoring by external parties.
FixEmit an event (e.g., `RewardExclusionChanged(address indexed account, bool excluded, uint256 newEligibleSupply)`) whenever `_setRewardExcluded` is called. This enhances transparency and allows for better off-chain monitoring of reward eligibility.
StatusUnresolved
Low

`creator` Role Specificity and Potential for Misconfiguration

L-02The `creator` address has special handling during the launch block (`block.number == _launchBlock && to == creator`), allowing it to bypass initial buy caps. While intended for initial distribution, if the `creator` address is misconfigured during `initialize` or subsequently compromised, it could be used to bypass these critical launch restrictions. The `creator` address is immutable after initialization.
IssueThe `creator` address has special handling during the launch block (`block.number == _launchBlock && to == creator`), allowing it to bypass initial buy caps. While intended for initial distribution, if the `creator` address is misconfigured during `initialize` or subsequently compromised, it could be used to bypass these critical launch restrictions. The `creator` address is immutable after initialization.
FixEnsure rigorous verification of the `creator` address during deployment and initialization. Consider adding a mechanism (e.g., a time-lock or a multi-sig confirmation) for setting such critical, immutable addresses if the deployment process is complex or involves multiple parties.
StatusUnresolved
Info

Unused `metadataURI` State Variable

I-01The `metadataURI` state variable is set during the `initialize` function but is not used anywhere else within the contract's on-chain logic. While it might be intended for off-chain use (e.g., for token metadata), its presence in storage without on-chain utility could be considered dead storage or a potential for confusion regarding its purpose within the contract.
IssueThe `metadataURI` state variable is set during the `initialize` function but is not used anywhere else within the contract's on-chain logic. While it might be intended for off-chain use (e.g., for token metadata), its presence in storage without on-chain utility could be considered dead storage or a potential for confusion regarding its purpose within the contract.
FixIf `metadataURI` is purely for off-chain consumption and has no on-chain effect, consider if it's strictly necessary to store it in contract state. If it is, add a comment explaining its purpose. If it's intended for on-chain use, ensure it's integrated into relevant functions.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract is built upon OpenZeppelin's ERC20, providing a solid foundation for token standards. The custom logic for buy/hold caps and the reward system is well-structured. However, a critical integer overflow vulnerability was identified in the `notifyReward` and `_settle` functions, specifically in the multiplication `total * ACC_PRECISION` and `balanceOf(account) * accRewardPerToken`, which can lead to incorrect reward distribution (7.2 Code Security). Access control is robust for `factory`-only functions, but the extensive power granted to the `factory` (e.g., `setMarket`, `enableHolderFees`, `_setRewardExcluded`) presents a significant centralization risk (7.3 Access Control). The `claim` function correctly handles reentrancy by updating state before external calls.

GovernanceHigh1/10

The tokenomics are defined by immutable constants, providing predictability for supply and initial trading limits. The reward mechanism, while designed to incentivize holding, is vulnerable to manipulation by the `factory` due to its ability to arbitrarily exclude addresses from `eligibleSupply` (7.4 Economic). This could allow the `factory` to accumulate a disproportionate share of rewards or cause rewards to become stuck if `eligibleSupply` remains zero. The absence of a decentralized governance model means the `factory` address holds ultimate authority over critical operational parameters, posing a significant centralization risk (7.5 Governance).

UpgradesMedium5/10

The contract is intended to be deployed as an upgradeable proxy implementation, utilizing an `initialize` function for one-time setup. This design allows for future logic upgrades, enhancing flexibility and bug fix capabilities. The `factory` address, set during initialization, plays a crucial role in managing the contract's lifecycle and operational parameters. However, the security of the upgrade mechanism is contingent on the proxy's ownership and the `factory`'s integrity. Any compromise of these roles could lead to unauthorized upgrades or malicious changes to the contract's logic (7.7 Upgrades).

Security Checklist

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

Holder Composition

23.2% in top 10
8.3% in wallets14.9% in contracts
Effective Concentration14.3%

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

$243.3K across 27 pairs
Uniswap v4ONDOanalysed$181.9K74.8%Uniswap v4USDC$6.5K2.7%Uniswap v4USDC$6.1K2.5%Uniswap v4USDC$4.9K2.0%Uniswap v4USDC$4.8K2.0%Uniswap v4USDC$4.1K1.7%
Show 4 more pairsShow less
Uniswap v4USDC$3.0K1.2%Uniswap v4USDC$3.0K1.2%Uniswap v4USDC$3.0K1.2%Uniswap v4USDC$3.0K1.2%

The 17 remaining pairs hold $23.0K 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

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

Key Addresses

2 addresses
Deployer
0x9e20…1b99
Unlocked LP Held By
0x4c12…da0a

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 status UNKNOWN (owner could not be resolved)
  • 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 = 75% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 75% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 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
SEIHigh RiskDolomite (DOLO)High RiskRedstone (RED)High RiskPinLink (PIN)High RiskFuse Cat (FUSECAT)High RiskEtherStreet (STREET)High Risk

Would You Like a More Detailed Audit of CONDO?

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

Get Detailed Audit