bInference (BINF) security report
bInference was AI scanned by Radar using verified source and GoPlus evidence. No Critical issue was proven, but High and Medium risks include 69.58% owner concentration, owner-controlled pool migration, transfer blocking through the dividend contract, unlimited tax-processor allowance, and unsafe initializer tax-rate parameters. Slither was not run.
The contract is not an unrestricted ERC-20. The owner controls migration state, the configured dividend contract can make transfers revert, and the tax processor receives an effectively unlimited allowance after liquidation. No mint function or blacklist mechanism was found after initialization, and GoPlus reports no proxy, honeypot, mintable, blacklist, or pausable signals.
Trust score: 52/100. Source verified: Yes. Chain: bsc. Contract: 0x9862d6478cb8098645815ff27f91efbc659f7777.
This report was last modified on 2026-09-30 and contains 4 material findings.
high finding: Owner-controlled migration state can restrict pool transfers and delay trading transitions
While the token remains in BondingCurve state, every transfer involving any configured pool reverts. Only the owner can call startMigration() and finalizeMigration(), so the owner controls when pool trading becomes possible and when anti-farmer taxation begins. An owner that delays or mishandles these transitions can prevent intended pool interaction.
Evidence: _transfer() requires !pools[from] && !pools[to] in PoolState.BondingCurve. startMigration() and finalizeMigration() are both external onlyOwner functions. The supplied GoPlus signal does not report a permanent honeypot, but it does not remove this source-level owner control.
Recommendation: Verify the live poolState, migration transaction sequence, and owner governance before trading. Use an immutable launch schedule or timelocked/multisignature control for state transitions if this design is retained.
medium finding: Configured dividend contract can globally block token transfers
After each transfer, _afterTokenTransfer() calls dividendContract.setShare() for non-excluded addresses and reverts if that external call fails. A misconfigured, unavailable, or adversarial dividend contract can therefore cause ordinary transfers to revert, creating a material transfer-availability dependency.
Evidence: _afterTokenTransfer() executes try IDividend(dividendContract).setShare(...) and reverts with DividendShareUpdateFailed on failure. dividendContract is supplied during initialize() and is not changeable through any exposed function in FlapTaxTokenV3.
Recommendation: Validate the dividend contract implementation and authorization before initialization, add controlled failure handling or a recovery mechanism, and monitor setShare failures. Do not configure an untrusted or upgradeable dividend endpoint without governance safeguards.
medium finding: Tax processor receives an effectively unlimited allowance over token-contract balances
During the first tax liquidation, the token approves taxProcessor for type(uint256).max. The external processor can then transfer tokens from the token contract under that allowance. This is a powerful trust assumption: a compromised or malicious processor could move accumulated tax tokens or other tokens held by the contract.
Evidence: _processTax() calls _approve(address(this), taxProcessor, type(uint256).max) when the allowance is insufficient, then invokes ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). The processor address is supplied during initialization and cannot be changed by the token contract.
Recommendation: Use a tightly controlled, audited tax processor, restrict its ability to move more than the intended tax amount, consider exact or resettable allowances, and document that processor compromise can affect token-contract-held assets.
medium finding: Initializer permits tax rates that can make pool trades revert
buyTax and sellTax are uint16 values but are not capped at 10000 basis points. If either rate exceeds 10000, _taxedTransfer() computes remainingAmount = amount - tax and reverts for affected pool transfers. This can create a honeypot-like trading restriction if unsafe parameters are supplied at initialization.
Evidence: initialize() directly stores params.buyTax and params.sellTax without an upper-bound check. _getTaxWithPoolState() calculates amount * rate / 10000, while _taxedTransfer() subtracts the result from amount. The supplied evidence does not include the deployed initialization values, so the live impact is not proven.
Recommendation: Require buyTax and sellTax to be <= 10000 during initialization, verify the deployed rates and poolState before trading, and reject configurations that can produce a tax greater than the transfer amount.