Quantum Inu (QINU) security report
Quantum Inu was AI scanned by Radar using verified source and GoPlus evidence. Material findings include hidden platform control behind owner() renunciation, gas-sensitive dividend transfers, launch-period wallet limits, and concentrated token holdings. Slither was not run.
The contract does not show an obvious mint, honeypot, or tax mechanism, but it should not be treated as fully decentralized. The platform retains privileged control over dividend configuration, fee withdrawal, and creator changes, while owner() always returns the zero address. Dividend-enabled transfers may also require unusually high gas, and launch-period wallet restrictions can block transfers under specified conditions.
Trust score: 54/100. Source verified: Yes. Chain: ethereum. Contract: 0xae215a2f6ec8cdbd6b2ffd0bb6bf0a9ab55dc578.
This report was last modified on 2026-09-28 and contains 4 material findings.
high finding: Platform retains privileged control despite owner() appearing renounced
The contract reports owner() as address(0), but the platform address retains exclusive administrative capabilities. This creates a misleading renunciation signal and leaves important behavior dependent on a centralized platform account.
Evidence: KlikToken sets _owner = address(0) in the constructor and owner() always returns _owner. The platform-only functions withdrawFees() and changeCreator() require msg.sender == platform. DirectDividendToken also restricts configureDividends() and enableDividends() to the platform. GoPlus separately reports hidden_owner: 1, while owner_address is the zero address.
Recommendation: Disclose the platform privileges prominently and use an immutable governance design, multisig, timelock, or verifiable decentralized controller. Consider removing or permanently disabling privileged functions after deployment and avoid presenting owner() == address(0) as equivalent to full decentralization.
medium finding: Dividend-enabled transfers can require very high gas and revert
Once dividends are enabled, a non-excluded holder exists, and the token contract has reward funds, ordinary token transfers invoke bounded dividend processing checks. Transfers can revert unless the remaining gas exceeds the automatic processing budget and reserve, creating an operational denial-of-service condition for wallets, routers, and integrations using normal gas limits.
Evidence: DirectDividendToken._update() checks holders.length and _rewardBalance(). When the balance is nonzero, it requires gasleft() > AUTO_PROCESS_GAS + TRANSFER_GAS_RESERVE before attempting automatic processing. AUTO_PROCESS_GAS is 720,000 and TRANSFER_GAS_RESERVE is 65,000. The function also reverts below 130,000 gas with InsufficientDividendGas().
Recommendation: Do not make ordinary transfers depend on a large gas reservation. Move dividend processing to an optional external operation, use a fail-open transfer path, or set bounded processing requirements that cannot cause standard transfers to revert.
medium finding: Immutable launch-period wallet and buy restrictions can block legitimate transfers
When MAX_WALLET_SECONDS is nonzero, the token applies a time-based maximum wallet and per-origin pool-buy limit. These controls are selected at deployment and exempt platform, creator, pool, the dead address, and burns, producing asymmetric transfer behavior during launch. The restrictions are not a permanent honeypot, but they can cause expected swaps or wallet transfers to revert during the active window.
Evidence: KlikToken._update() enforces a 2% max wallet through maxTxAmount and tracks pool purchases by tx.origin per block. It rejects non-exempt recipient balances above maxTxAmount and rejects pool-originated purchases above 110% of maxTxAmount. The launch duration is supplied through the constructor and is immutable for each deployed token. GoPlus reports is_anti_whale: 1 and transfer_pausable: 0.
Recommendation: Publish the exact launch duration, wallet limit, pool address, and exempt-address policy before trading. Prefer predictable per-address limits over tx.origin accounting and provide integration guidance for routers and aggregators.
medium finding: Dividend configuration and reward behavior depend on a platform-selected hook
The platform selects the dividend currency and dividend hook before circulation, then separately enables dividends. The hook is the only address authorized to create dividend liabilities, while the token's payment and transfer behavior changes after enablement. A faulty, unavailable, or incompatible hook or reward currency can leave rewards unprocessed and can increase transfer execution complexity.
Evidence: DirectDividendToken._configureDividends() accepts a platform-selected currency and hook, and enableDividends() is also platform-only. accrueDividend() requires msg.sender == dividendHook. Dividend payment uses low-level calls and strict balance checks for ERC20 rewards, while native payments depend on recipient callbacks and pool-state checks.
Recommendation: Use an audited immutable hook or governed configuration, validate reward-token compatibility before enabling dividends, expose a documented emergency disable or migration path, and test behavior with the intended PoolManager and reward assets.