LookAlive (LOOK) security report
Radar AI scanned LookAlive on Ethereum. The fixed-supply token has no visible upgrade or post-deployment mint path, but its source contains launchpad-controlled buy restrictions and rescue-mode transfer bypasses.
The main risks are centralized launch controls and transfer restrictions. During the blinking period, ordinary direct buys can revert unless the transaction originates from the deployer or an approved registry relayer. The launchpad can also enable rescuing mode, which bypasses the buy gate and max-wallet check for transfers. No unlimited minting, upgradeability, fee-setting function, blacklist mapping, or explicit sell block was identified in the supplied source.
Trust score: 55/100. Source verified: Yes. Chain: ethereum. Contract: 0xef4ca098b76239b532467ac8c332129149723e5e.
This report was last modified on 2026-10-07 and contains 2 material findings.
medium finding: Launchpad and relayer registry control access to buys during the blinking period
While blinking is true, transfers from the canonical pool revert unless the transaction origin is the deployer, the launchpad, or an address recognized as a relayer by the immutable registry. This means ordinary direct buys can be blocked during the configured launch window, while access depends on external relayer-list administration.
Evidence: In _update, when fromPool is true, !graduated, block.timestamp < windowEnd, and tx.origin != deployer, the contract requires registry.isRelayer(tx.origin); otherwise it reverts with BuyLocked(). The blinking state ends only when graduation occurs or block.timestamp reaches windowEnd. initialize sets windowEnd and the pool once, while the registry address is immutable.
Recommendation: Disclose the gating behavior and relayer dependency prominently. Confirm that the configured relayer registry has transparent administration and that the launch window cannot be extended through another contract. Consider avoiding tx.origin-based authorization and using explicit caller or signed-user authorization if unrestricted direct buys are intended.
medium finding: Launchpad-controlled rescuing mode bypasses transfer restrictions
The launchpad can enable rescuing mode, causing every token update to skip the buy gate, graduation check, and max-wallet enforcement. This is a privileged operational control and can permit pool-originated transfers to destinations that would otherwise be rejected, subject to the initiating pool operation and normal ERC-20 balance rules.
Evidence: setRescuing(bool b) can be called only by launchpad and sets rescuing. At the start of _update, if rescuing is true, the contract immediately calls super._update(from, to, value) and returns, bypassing the BuyLocked and MaxWalletExceeded checks. The source comments explicitly describe this mode as being used for a pool-to-wallet rescue.
Recommendation: Restrict rescue operations with an explicit, narrowly scoped rescue function, destination controls, event logging, and a time-bounded mechanism. Publish the conditions under which rescuing can be enabled and ensure the launchpad cannot use it to move pool-held tokens without an auditable recovery process.