Ethimus (ETHIMUS) security report
Radar AI scanned Ethimus on Ethereum. The verified source shows a fixed-supply ERC-20 without visible admin mint, fee, blacklist, or upgrade controls, but every non-mint transfer calls an immutable distributor that can revert and block transfers.
The main identified risk is a medium-severity transfer denial condition: the immutable distributor is called during every non-mint transfer and can cause transfers to fail by reverting or consuming excessive execution resources. The source does not expose privileged minting, fee changes, blacklist controls, or upgradeability.
Trust score: 68/100. Source verified: Yes. Chain: ethereum. Contract: 0x67d46a11d38f8837db91c9ba8299807812e4c8a4.
This report was last modified on 2026-10-08 and contains 1 material finding.
medium finding: Immutable distributor callback can block all non-mint transfers
LaunchToken overrides _update and, after completing the ERC-20 balance update, calls distributor.onTransfer for every transfer where from is nonzero and distributor is nonzero. Any revert or unusable behavior in that external contract causes the entire token transfer transaction to revert. Because distributor is immutable and there is no fallback or recovery path in LaunchToken, this creates a material transfer-denial and potential asset-lock risk if the configured distributor fails or intentionally rejects callbacks.
Evidence: In src/LaunchToken.sol, _update contains: `if (from != address(0) && distributor != address(0)) { IHolderDistributor(distributor).onTransfer(from, to, value, balanceOf(from), balanceOf(to)); }`. The distributor address is assigned once in the constructor with `distributor = distributor_` and has no setter. The callback is made after `super._update`, but a revert in the external call reverts the complete transaction, including the balance update.
Recommendation: Use a trusted, audited distributor implementation that cannot unexpectedly revert, and test transfer behavior against failure, gas, and reentrancy conditions. If operationally acceptable, add a recovery design such as disabling the hook, using a non-blocking notification pattern, or routing callback failures without reverting token transfers. Verify the deployed distributor bytecode and its callback behavior before relying on transfers.