CONDO (CONDO) security report
CONDO was AI scanned from verified Solidity source with GoPlus evidence; Slither was skipped. No post-initialization mint, proxy, blacklist, pause, or tax was identified.
The contract was AI scanned using the verified Solidity source and supplied GoPlus evidence; Slither was skipped. No post-initialization mint, proxy upgrade, blacklist, pause, or transfer-tax mechanism was found. Material risks remain around removable liquidity, authorized reward notifications, and the short launch trading guard.
Trust score: 61/100. Source verified: Yes. Chain: ethereum. Contract: 0xfe99b2fe66c7725ce30730010a864740e7c39b26.
This report was last modified on 2026-09-29 and contains 4 material findings.
medium finding: Authorized reward caller can report distributions without proving funds arrived
notifyReward accepts an arbitrary amount from rewardSource or factory but does not transfer tokens, verify the contract's balance increase, or require native msg.value to equal amount. A compromised, malicious, or misconfigured authorized caller can inflate the reward accumulator and cause available reward assets already held by the token contract to be distributed according to the fabricated amount; claims can also become unclaimable if funds are absent.
Evidence: In notifyReward(uint256 amount), authorization is limited to msg.sender == rewardSource or msg.sender == factory, then accRewardPerToken is increased using amount plus carriedReward. The payable function does not validate msg.value, and the ERC20 path does not pull rewardToken from the caller. rewardSource is configured by the factory in enableHolderFees.
Recommendation: Use a pull-based transferFrom flow or verify balance deltas before accounting. For native rewards require msg.value == amount. Minimize authorized callers and monitor rewardSource and factory activity.
medium finding: Launch guard can block ordinary buys and transfers during the first blocks
During the launch guard, transfers out of the configured market are subject to a ramped per-buy cap, and inbound transfers to non-market addresses are subject to a 5% maximum holding cap. In the launch block, market purchases to any address other than creator revert. These restrictions can cause automated trades, aggregators, and users to fail during launch and create execution risk, although the guard expires permanently after three blocks.
Evidence: _update reverts with CreatorOnlyBlock when block.number == _launchBlock and a market transfer is not to creator; it reverts with BuyCapExceeded for buys above currentBuyCap and HoldCapExceeded when the recipient balance would exceed MAX_HOLD while guardActive(). GUARD_BLOCKS and RAMP_BLOCKS are both 3.
Recommendation: Clearly disclose the launch-block restriction and cap schedule, test all intended routers and liquidity flows, and ensure launch interfaces expose guardActive, currentBuyCap, and MAX_HOLD before users trade.
medium finding: Creator has an uncapped launch-block acquisition path
The creator is exempt from the launch-block buy cap and the initial funding path from factory is exempt from transfer restrictions. A creator can therefore acquire a large position at launch and subsequently sell it after restrictions expire, creating material concentration and price-impact risk. This is not an arbitrary external attacker exploit, but it is a meaningful business-logic and holder-risk consideration.
Evidence: _update sets creatorOpening when block.number == _launchBlock and to == creator, then skips the buy cap and hold cap. Transfers with from == factory or to == factory also return before cap checks. GoPlus reports creator_balance=0 at the scan time, but this does not eliminate the source-level capability.
Recommendation: Disclose the creator allocation and launch-block exemption, monitor creator and factory-associated wallets, and consider applying the same caps to creator purchases if fair-launch behavior is required.
medium finding: Initialization is permissionless until the clone is initialized
A fresh clone can be initialized by the first caller because initialize only checks whether factory is zero. That caller becomes factory, creator assignment is controlled by the supplied argument, and the full fixed supply is minted to msg.sender. The deployed token appears initialized, so this is primarily a deployment and factory-operational risk rather than evidence that the current supply was attacker-minted.
Evidence: initialize is external and reverts only when factory != address(0); otherwise it sets factory = msg.sender and calls _mint(msg.sender, TOTAL_SUPPLY). The constructor protects the implementation by setting factory to 0xdead, but newly created clones begin with factory equal to zero.
Recommendation: Have the factory initialize each clone atomically during deployment or use a constructor-provided immutable initialization authority. Monitor clone creation and initialization transactions and verify that no deployed clone remains uninitialized.