Smart Contract Audit

transferLock() pushed the lockId into _userLocks[newOwner] but never removed it from _userLocks[oldOwner]. The old owner would still see transferred locks.

Impact: Data integrity — old owner still sees transferred locks on My Locks page.

Resolution: Added _removeFromArray() helper using swap-and-pop pattern.

.transfer() forwards only 2300 gas. If recipient is a multisig whose fallback requires more gas, withdrawals revert.

Impact: Admin may be unable to withdraw fees with multisig wallets.

Resolution: Replaced with low-level call{value: ...}("") + require(ok).

withdrawFees() emitted no event, making admin activity invisible to off-chain indexers.

Impact: Low — reduces auditability of admin actions.

Resolution: Added event FeeWithdrawn(address indexed to, uint256 amount).

Unbounded calldata string could increase gas cost disproportionately.

Impact: Low — only affects gas cost.

Resolution: Added require(bytes(description).length <= 256).

createToken() performs an external call (refund excess fee) without nonReentrant modifier. The function follows CEI pattern (state changes before external call), so re-entrancy risk is minimal.

Impact: Low — CEI pattern prevents exploitation, but defense-in-depth recommends the guard.

Resolution: Acknowledged. Contract inherits Ownable but not ReentrancyGuard. CEI ordering mitigates the risk.

Token name and symbol have no maximum length constraint. Extremely long strings increase deployment gas costs and may cause display issues in wallets and explorers.

Impact: Low — only affects gas cost and UX.

Resolution: Frontend enforces max 32 chars for name and 10 chars for symbol. On-chain enforcement not critical.

supply_ * 10 ** decimals_ can overflow for extremely large supply values. Solidity 0.8.24 checked arithmetic will revert, but the error message is unclear to users.

Impact: Low — transaction reverts safely but user may not understand why.

Resolution: Frontend validates supply input. On-chain revert is safe behavior.

finalize() calculates tokensSold as (totalRaised * 1e18) / tokenPrice, and claimTokens() uses the same formula. This assumes all presale tokens use 18 decimals. Tokens with different decimals (e.g. 6 or 8) will have incorrect distribution amounts.

Impact: Medium — tokens with non-18 decimals will have wrong claim amounts. Could result in over/under distribution.

Resolution: Acknowledged. Platform documentation states presale tokens must use 18 decimals. Frontend enforces this by filtering token input. Future version may add dynamic decimal support.

createPresale() does not verify that tokenAmount_ is sufficient to cover the maximum possible token distribution (hardCap / tokenPrice). If insufficient tokens are deposited, claimTokens() will revert for later claimers due to insufficient contract balance.

Impact: Medium — some contributors may be unable to claim tokens if the presale sells out but deposit is insufficient.

Resolution: Acknowledged. Frontend calculates required token amount from hardCap/price and pre-fills the field. A future upgrade could add on-chain validation.

cancelPresale() performs a safeTransfer (external call) without nonReentrant modifier. Status is set to Cancelled before the transfer, so re-entrancy would fail the status check.

Impact: Low — CEI pattern prevents exploitation.

Resolution: Acknowledged. Status change before external call mitigates the risk.

safeTransferFrom records the nominal amount, but fee-on-transfer tokens deliver less than the specified amount. This affects totalTokens tracking in Launchpad and lock amounts in TokenLocker.

Impact: Low — fee-on-transfer tokens are uncommon. Users of such tokens would see incorrect balances.

Resolution: Acknowledged. Platform documentation advises against using fee-on-transfer tokens. Standard ERC-20 tokens work correctly.

When a presale ends without reaching soft cap, status remains Active. Refunds are allowed via time-based check, but status does not transition to a terminal state automatically.

Impact: Info — no security impact. Status is cosmetic; refund logic works correctly.

Resolution: Acknowledged. On-chain automatic status transition would require an external trigger. Frontend displays the correct state based on timestamp and cap checks.