OICQ (OICQ) security report
OICQ was AI scanned from verified Solidity source with GoPlus evidence. No Critical or High finding was established. Medium risks include external tax-processor custody, transfer blocking through dividend callbacks, and possible migration lock after ownership renunciation.
The contract was AI scanned using the verified source and GoPlus evidence. No Critical or High exploit was established from the supplied materials, but three Medium risks were identified: tax-token custody is delegated to an external processor, dividend callbacks can block transfers, and renounced ownership can leave pool trading restricted if migration is incomplete.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0xa6b6d6605640af299142789f04fcbd926d667777.
This report was last modified on 2026-09-29 and contains 3 material findings.
medium finding: External tax processor can receive the entire accumulated tax-token balance on processing failure
When tax processing reverts, the contract catches the failure and transfers its entire remaining token balance to the configured taxProcessor address. A compromised, malicious, or incorrectly configured processor can therefore cause collected tax tokens to be delivered directly to that address instead of being processed according to the intended fee-splitting logic.
Evidence: In _processTax(), ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) is called inside try/catch. The catch branch reads balanceOf(address(this)) and executes _plainTransfer(address(this), taxProcessor, remainingBalance). The contract also grants the processor an effectively unlimited allowance when processing taxes.
Recommendation: Use a narrowly scoped allowance, transfer only the specific tax amount involved in the failed operation, and add explicit recipient and processor governance controls. Consider a recovery path that preserves funds rather than forwarding the complete contract balance to the external processor.
medium finding: Dividend callback failure can block token transfers
If dividendContract is configured and its setShare call reverts for a sender or recipient, _afterTokenTransfer reverts the entire token transfer. A broken, unavailable, or deliberately restrictive dividend contract can therefore prevent affected holders from transferring tokens, creating a transfer-denial risk.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) for non-excluded addresses. Each failed call is caught and then reverts with DividendShareUpdateFailed. Because the hook executes during ERC20 transfers, the token balance update is rolled back when the callback fails.
Recommendation: Decouple dividend accounting from transfers, or make share updates non-blocking with a retry or queued-update mechanism. If synchronous updates are required, provide a governed way to disable or replace a failed dividend contract.
medium finding: Renounced ownership can permanently prevent migration and pool trading
The BondingCurve state rejects transfers to and from every configured pool. Only the owner can call startMigration and finalizeMigration. GoPlus reports the current owner address as the zero address; if ownership was renounced while the contract remains in BondingCurve, no account can complete migration and configured pool trading remains restricted indefinitely.
Evidence: In _transfer(), PoolState.BondingCurve requires !pools[from] && !pools[to]. startMigration() and finalizeMigration() are both onlyOwner. Supplied GoPlus evidence reports owner_address as 0x0000000000000000000000000000000000000000. The supplied data does not include the current poolState, so the lock condition is conditional rather than proven.
Recommendation: Do not renounce ownership until migration is finalized. If migration is already stuck, deploy or use an authorized recovery mechanism before ownership renunciation; otherwise redesign lifecycle controls so pool restrictions cannot become irreversible.