Galanar (GALANAR) security report
Radar AI scanned Galanar's verified Ethereum contract. The review found medium-severity reward payout, recovery authority, supply custody, and launch restriction risks. Slither was not run and no GoPlus findings were supplied.
The source review identified medium-severity risks involving reward payout forfeiture, factory-owner recovery of forfeited rewards, and launch-period transfer restrictions. No critical or high-severity exploit was established from the supplied source.
Trust score: 68/100. Source verified: Yes. Chain: ethereum. Contract: 0x89f7f92697bfa13da398d5799cd40719b2f21812.
This report was last modified on 2026-10-05 and contains 5 material findings.
medium finding: Factory receives the entire fixed supply during initialization
The complete token supply is minted to the factory address rather than directly to the pool or a distribution contract. The subsequent allocation and transfer of that balance therefore depends on factory implementation and operational controls, creating a concentration of initial supply authority.
Evidence: LaunchToken.initializeV2 performs _mint(msg.sender, TOTAL_SUPPLY) after setting factory = msg.sender. Since msg.sender is the initializing factory, the factory initially receives the full MAX_SUPPLY amount and later controls how that balance is distributed.
Recommendation: Use an explicit, verifiable allocation flow that transfers supply only to documented destinations, emit allocation events, and subject factory distribution logic and ownership to multisignature or timelocked governance.
medium finding: Failed reward payouts can permanently consume holder entitlements
A reward entitlement is marked as paid before the external payout call. If the native transfer or reward-token transfer fails, the contract moves the amount from totalPaid to totalForfeited and does not restore the holder's claimable balance. A non-compliant or adversarial reward token could transfer assets while returning failure, leaving the holder without the entitlement.
Evidence: HolderRewards._pay first executes totalPaid += amount. On a failed low-level call, it executes totalPaid -= amount and totalForfeited += amount, emits RewardForfeited, and returns zero. The comment in _pay explicitly states that a rejected token return can still mean the token moved funds and that the claim remains consumed.
Recommendation: Use a trusted reward-token allowlist with strict transfer semantics, or verify the recipient's balance before and after payout where practical. Do not consume the entitlement unless delivery is confirmed, and define a transparent retry or compensation mechanism for failed payouts.
medium finding: Factory owner controls recovery of forfeited rewards
The live owner of the configured factory may transfer forfeited reward assets to any nonzero recipient. Although the function is limited to amounts classified as forfeited and cannot directly rescue ordinary holder entitlements, payout failures can place value into that forfeited category, making recovery authority a material centralization and governance risk.
Evidence: LaunchToken.rescueForfeitedRewards checks msg.sender against IRewardLaunchConfiguration(factory).owner() and calls _rescueForfeitedRewards. That function accepts an arbitrary recipient and amount up to totalForfeited - totalForfeitedRescued, subject to available balance and backing checks.
Recommendation: Document this authority prominently, use a timelocked or multisignature factory ownership model, emit and monitor recovery events, and consider routing recovered funds to a predetermined recovery address or affected claimants rather than an arbitrary recipient.
medium finding: Launch guard can materially restrict transfers and purchases
During the configured guard duration, transfers from the pool manager are subject to an early-access check at launch, a dynamic buy cap, and a recipient holding cap. These controls can prevent otherwise valid purchases or transfers until the guard expires and depend on market parameters supplied during initialization.
Evidence: LaunchToken._update applies EarlyAccessOnly when from == poolManager at launch and earlyBuyer[to] is false, rejects pool-manager purchases above currentBuyCap(), and rejects recipient balances above MAX_HOLD while guardActive(). guardDuration, launchBlock, and the earlyBuyer list are populated by initializeV2 from the registered market configuration.
Recommendation: Publish the exact guard duration, buyer allowlist policy, buy-cap schedule, and hold-cap behavior before launch. Test all intended pool and router paths, and provide an operational fallback if the configured pool manager or launch parameters prevent normal trading.
medium finding: Reward behavior depends on externally configured hook, locker, and base asset
When rewards are enabled, the initialized market selects the reward base asset, hook, and locker. The token trusts those configured contracts for funding and reward accounting, so misconfiguration, nonstandard token behavior, or failure of the associated system can impair funding and payouts.
Evidence: initializeV2 calls _initializeRewards(m.base, address(m.key.hooks), locker). HolderRewards.fund permits only rewardHook or rewardLocker to fund rewards, while _pay performs external calls to rewardToken. The source validates nonzero addresses but does not establish that the reward asset is a standard, immutable-behavior ERC-20.
Recommendation: Restrict deployments to audited hook, locker, and reward-token implementations; validate reward-token behavior during initialization or through an allowlist; and document that reward availability depends on these external components.