AGENTINE (AGENTINE) security report
Radar by SecureChain AI scanned the verified AGENTINE contract on BNB Smart Chain. Findings include an external tax processor with broad access to token-contract-held balances and dividend callbacks that can revert transfers. Slither was not run.
AGENTINE is not free of material contract risks. The token delegates tax handling to an externally configured processor with an effectively unlimited allowance and sends all token-contract-held tokens to that processor if processing fails. Transfers can also revert when the configured dividend contract rejects share updates.
Trust score: 48/100. Source verified: Yes. Chain: bsc. Contract: 0xb47db73293380088a1d78fb5c51bf9038f217777.
This report was last modified on 2026-11-04 and contains 2 material findings.
high finding: Tax processor can control and drain token-contract-held AGENTINE
The configured taxProcessor receives an unlimited AGENTINE allowance and is called to process accumulated tax balances. A compromised or malicious processor can use that allowance to transfer token balances held by the token contract, including accumulated tax tokens. The failure path also sends the contract's remaining token balance directly to taxProcessor.
Evidence: In _processTax(), the contract sets allowance(address(this), taxProcessor) to type(uint256).max when the allowance is insufficient, then calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). If that call reverts, the catch block reads balanceOf(address(this)) and executes _plainTransfer(address(this), taxProcessor, remainingBalance). taxProcessor is supplied during initialize() and has no setter or owner-controlled replacement function.
Recommendation: Use a narrowly scoped allowance for each liquidation, approve only the exact amount, and isolate tax balances from unrelated token balances. Do not transfer the entire contract balance on processor failure; instead retain the tax amount, emit a failure event, and provide a controlled recovery mechanism. Validate the processor implementation and governance before deployment.
medium finding: Dividend callback can block ordinary token transfers
When dividend tracking is enabled, every transfer involving a non-exempt address makes external setShare calls. If the configured dividend contract reverts, the token transfer also reverts, creating a transfer-denial or lock condition for affected addresses.
Evidence: In _afterTokenTransfer(), dividendContract.setShare(from, balanceOf(from)) and dividendContract.setShare(to, balanceOf(to)) are called through try/catch. Each catch block executes revert DividendShareUpdateFailed(...). dividendContract is supplied during initialize() and is not changeable afterward. Pool addresses, the token contract, the zero address, the burn address, and the dividend contract are exempt, but ordinary transfers are not.
Recommendation: Consider making dividend-share synchronization non-blocking, queueing failed updates for later processing, or adding a bounded recovery and disable mechanism. Validate that the dividend contract is trusted, live, and gas-efficient before initialization.