Health is wealth (Healthcoin) security report
Radar AI scanned the verified Health is wealth contract on BNB Smart Chain. The main finding is that dividend-contract callback failures can revert qualifying token transfers. The source also requires atomic initialization because initialize mints the full initial supply to its caller. Slither was not run.
The contract does not show an obvious mint-after-deployment, blacklist, proxy-upgrade, or owner-controlled tax-setting function. However, transfers can be blocked if the configured dividend contract reverts, and an uninitialized deployment could be claimed by an attacker who would receive the initial supply and ownership.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0xd976b2ab3cf025f6136558687c174520c92b7777.
This report was last modified on 2026-10-07 and contains 2 material findings.
medium finding: External dividend callback can block token transfers
Every qualifying transfer invokes dividendContract.setShare for the sender and recipient. Any revert from either call causes DividendShareUpdateFailed to revert the entire token transfer. A malfunctioning, incompatible, or adversarial dividend contract can therefore create a transfer-denial condition for accounts that are not excluded by the contract's skip rules.
Evidence: In _afterTokenTransfer, IDividend(dividendContract).setShare(...) is called inside try/catch, and the catch block executes revert DividendShareUpdateFailed(from, reason). The same pattern is used for the recipient. dividendContract is assigned during initialize and there is no token-level function to replace it. The ABI exposes dividendContract(), and the verified source defines the callback behavior.
Recommendation: Use a non-blocking callback pattern that records failed share updates instead of reverting the ERC20 transfer, or add a tightly controlled and transparently governed mechanism to disable or replace a failed dividend integration. Test transfers when the dividend contract reverts, runs out of gas, or returns unexpected behavior.
medium finding: Uninitialized deployment can be claimed and supplied by the first caller
The external initialize function mints the entire maxSupply to msg.sender and sets that caller as the owner through __Ownable_init. If a proxy or clone is ever deployed without atomically calling initialize, the first caller can configure the token, receive the initial supply, and obtain ownership. This is a deployment-condition risk rather than a confirmed current exploit.
Evidence: initialize(...) is external and protected only by the one-time initializer modifier. It calls __Ownable_init(), then _mint(msg.sender, maxSupply). The constructor disables initialization only on the implementation contract; proxy or clone storage must still be initialized separately. GoPlus reports owner_address as the zero address, which is consistent with a previously initialized and renounced instance but does not independently prove that every deployment path is initialized atomically.
Recommendation: Initialize each proxy or clone in the deployment transaction or constructor calldata, verify initialization state before distribution, and prevent factory-created instances from being exposed between deployment and initialization. Confirm the deployed instance's initialization event and owner history.