BeanX (BeanX) security report
Radar by SecureChain AI reviewed BeanX's verified source on BNB Smart Chain. The scan found a high-severity tax processor custody risk and medium-severity transfer availability and migration-control risks.
The source review identified one high-severity custody risk and two medium-severity control or availability risks. GoPlus reported the contract as open source, non-proxy, non-mintable, non-blacklisted, and not identified as a honeypot; these signals do not remove the source-level risks described here.
Trust score: 48/100. Source verified: Yes. Chain: bsc. Contract: 0xc0a395b18aa826900f78f2961ce6b6b99bb27777.
This report was last modified on 2026-10-10 and contains 3 material findings.
high finding: Initialization-configured tax processor can control and drain accrued tax tokens
The token approves the taxProcessor for an effectively unlimited allowance and invokes its external processTaxTokens function. A malicious, compromised, or incorrectly configured processor can use that allowance to transfer the entire BeanX balance held by the token contract to an arbitrary recipient. If processing reverts, the catch block explicitly transfers the remaining token-contract balance to taxProcessor.
Evidence: In _processTax, the contract executes _approve(address(this), taxProcessor, type(uint256).max) when needed, then calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). The catch branch obtains balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance). taxProcessor is assigned during initialize and has no setter in the verified contract.
Recommendation: Use a narrowly scoped allowance equal to the current tax amount, restrict the processor to a reviewed immutable or governed implementation, and do not forward the entire token-contract balance on processing failure. Add explicit recovery and accounting controls for failed liquidations.
medium finding: Dividend callback failure can block token transfers
When dividendContract is configured, ordinary transfers invoke an external setShare callback for eligible sender and recipient addresses. Any callback failure is caught and rethrown as DividendShareUpdateFailed, causing the entire token transfer to revert. A broken, unavailable, or intentionally reverting dividend contract can therefore create a transfer-availability failure.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) unless the address is excluded. Each call is wrapped in try/catch, but the catch block executes revert DividendShareUpdateFailed(...). dividendContract is set during initialize and cannot be changed through the exposed ABI.
Recommendation: Do not make core ERC20 transfers depend on a mandatory external callback. Consider non-blocking share updates, queued synchronization, a bounded failure mode, or a governed emergency method to disable or replace the dividend integration.
medium finding: Owner-controlled migration can keep pool transfers restricted
The contract starts in BondingCurve state, where every transfer involving a configured pool reverts. Only the owner can transition through startMigration and finalizeMigration, and there is no time-based fallback that automatically enables pool transfers. This creates a material launch-control dependency and can prevent pool trading if migration is delayed or mismanaged.
Evidence: initialize sets poolState.state to PoolState.BondingCurve and records the supplied pool addresses. In _transfer, BondingCurve state requires !pools[from] && !pools[to]. Both state-transition functions are protected by onlyOwner, and no public permissionless transition path exists.
Recommendation: Use an explicit, auditable migration timetable, multisignature governance, and operational monitoring for owner-only transitions. If appropriate for the design, add a constrained fail-safe or documented recovery path that cannot arbitrarily change tax or pool permissions.