Radar by SecureChain AI

Hashly Labs (HASH) security report

Radar AI scanned the verified Hashly Labs HASH contract on Ethereum. The source has fixed supply and no mint, blacklist, pause, or proxy path, but exposes medium-severity centralized controls over trading activation, transfer taxes, pool classification, exemptions, and fee routing.

The contract is not an unrestricted fixed-behavior token. The owner can delay public trading indefinitely before activation and can change buy and sell taxes, pool classifications, exemptions, and fee destination within the contract’s rules. These are material centralized-control risks, although the verified source caps each tax at 5%.

Trust score: 63/100. Source verified: Yes. Chain: ethereum. Contract: 0x5070d2434c94caf5edd904b6a2c945b1f61d59b6.

This report was last modified on 2026-10-13 and contains 3 material findings.

medium finding: Owner controls which addresses are treated as AMM pools and tax-exempt

The owner can designate arbitrary addresses as pools and can exempt or unexempt arbitrary addresses. Because tax logic depends on these mappings, owner changes can alter which transfers incur buy or sell taxes and which accounts bypass taxation.

Evidence: setPool() writes isPool[pool] and setTaxExempt() writes isTaxExempt[account], both under onlyOwner. In _transfer(), transfers involving a flagged pool are taxed when neither side is exempt, while any exempt side bypasses the tax branch.

Recommendation: Track PoolUpdated and TaxExemptUpdated events, publish the intended pool and exemption policy, and use governance or immutable configuration for these classifications where possible.

medium finding: Owner can indefinitely prevent unrestricted trading before activation

Trading remains restricted until the owner calls enableTrading(). Before that call, transfers are allowed only when either the sender or recipient is explicitly marked canTransferBeforeTrading. The owner controls that allowlist and can choose not to enable trading, leaving ordinary transfers restricted indefinitely.

Evidence: In _transfer(), the contract reverts with TradingNotEnabled() when tradingEnabled is false and both canTransferBeforeTrading[from] and canTransferBeforeTrading[to] are false. enableTrading() is external onlyOwner and is a one-way owner-controlled switch.

Recommendation: Verify that trading has been enabled and monitor the TradingEnabled event and canTransferBeforeTrading changes. Consider removing unilateral activation control or using a documented, externally governed launch mechanism.

medium finding: Owner can materially change trading taxes and fee destination

The owner can change buy and sell taxes at any time up to the 5% per-side cap and can redirect collected tax tokens to a new recipient. This creates ongoing centralized control over the token’s transfer economics and fee flow.

Evidence: setTax() is onlyOwner and accepts any buyBps and sellBps up to MAX_TAX_BPS, which is 500 basis points. setTaxRecipient() is onlyOwner and assigns taxRecipient. GoPlus also reports slippage_modifiable as 1, consistent with owner-controlled transfer-cost parameters.

Recommendation: Monitor TaxUpdated and TaxRecipientUpdated events, document acceptable fee limits, and consider immutable or governed fee parameters if users require predictable transfer economics.