Agentic Chain (AGNT) security report
Radar AI scanned the verified Agentic Chain AGNT contract on BNB Smart Chain. The review found no exposed mint, blacklist, proxy upgrade, or selfdestruct behavior, but identified high-risk external transfer dependencies, unchecked tax-rate initialization, owner-controlled migration, and significant reported owner concentration.
The verified source does not expose post-deployment minting, blacklist controls, proxy upgrade functions, or selfdestruct behavior. However, transfers depend on externally configured tax and dividend contracts, invalid tax parameters can create honeypot-like transfer failures, and the owner can control migration into the trading lifecycle. These risks warrant caution and operational verification.
Trust score: 48/100. Source verified: Yes. Chain: bsc. Contract: 0xc396df2ed18837df07a58f7cc407217cef807777.
This report was last modified on 2026-09-29 and contains 5 material findings.
high finding: Tax processor failure can redirect the contract's entire token balance
If the external tax processor call fails, the contract transfers its entire token balance to the configured taxProcessor address, rather than only the tax amount being liquidated. A malicious, compromised, or deliberately reverting tax processor could therefore receive accrued taxes and any other AGNT held by the token contract.
Evidence: In _processTax(), a failed ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) call is caught, after which the contract executes _plainTransfer(address(this), taxProcessor, remainingBalance), where remainingBalance is balanceOf(address(this)) and is not limited to taxAmount. taxProcessor is assigned during initialize().
Recommendation: Restrict the fallback transfer to the intended taxAmount or otherwise account for pre-existing contract balances. Use an immutable or governed processor, validate its code and behavior, and add tests covering processor reverts and unexpected token balances.
high finding: Dividend contract failure can block ordinary token transfers
When dividendContract is nonzero, every transfer involving a non-excluded ordinary address calls the external dividend contract's setShare function. Any revert from that contract causes the entire token transfer to revert, creating a potential transfer lock if the dividend contract is misconfigured, compromised, or unavailable.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) for addresses that are not the token contract, zero address, dead address, dividend contract, or a configured pool. Each call is wrapped in catch, but the catch executes revert DividendShareUpdateFailed(...). dividendContract is supplied during initialize() and has no setter or bypass mechanism.
Recommendation: Do not make core ERC-20 transfers depend on a reverting external dividend callback. Consider handling failures without reverting transfers, adding a controlled pause or recovery path, and validating the dividend implementation before initialization.
medium finding: Initializer permits tax rates that can make pool transfers fail or deliver no tokens
The initializer accepts arbitrary uint16 buy and sell tax rates without enforcing a maximum of 10000 basis points. Rates above 10000 cause amount - tax to underflow and revert for affected pool transfers; a 10000 rate sends the full amount as tax and leaves the recipient with zero tokens. This creates a configuration-dependent honeypot-like or unusable trading path.
Evidence: initialize() stores params.buyTax and params.sellTax directly in poolState without validation. _getTaxWithPoolState() calculates (amount * currentBuyTaxRate) / 10000 or the equivalent sell calculation, and _taxedTransfer() executes uint256 remainingAmount = amount - tax.
Recommendation: Require buyTax and sellTax to be at or below 10000 basis points, preferably impose a lower documented cap, and verify initialized values on-chain before enabling trading.
medium finding: Owner-controlled migration state can restrict pool transfers and control trading activation
The owner can keep the token in BondingCurve state, where transfers to or from every configured pool are rejected. The owner alone can call startMigration() and finalizeMigration(), determining when the contract leaves this restricted state and when the tax-enforced lifecycle begins. This is a material centralized launch and transfer-control risk.
Evidence: _transfer() in BondingCurve state requires !pools[from] && !pools[to], reverting transfers involving configured pools. startMigration() and finalizeMigration() are both protected by onlyOwner. GoPlus identifies owner address 0xe2ce6ab80874fa9fa2aae65d277dd6b8e65c9de0 and reports an owner balance of approximately 36.58% of total supply.
Recommendation: Document the migration authority and timing, use a timelocked or multisignature owner, publish the configured pool and lifecycle parameters, and verify that trading is not dependent on an unbounded discretionary owner action.
medium finding: Large owner allocation creates material concentration and control risk
A holder with this allocation can exert substantial market and governance influence and may materially affect price or liquidity-related behavior if sold or transferred.
Evidence: initialize() executes _mint(msg.sender, maxSupply), where maxSupply is 1e9 ether. GoPlus reports owner_address 0xe2ce6ab80874fa9fa2aae65d277dd6b8e65c9de0 and owner_percent 0.365817.
Recommendation: Publish a transparent allocation and vesting schedule, use verifiable lockups or multisignature custody where appropriate, and monitor large-holder transfers. This finding does not attest to current market conditions or future selling activity.