BNCDAO (BNCDAO) security report
SecureChain Radar AI scanned the verified BNCDAO contract on BSC. GoPlus found no honeypot, minting, blacklist, pause, or proxy indicators. Source review identified medium risks involving delayed tax expiration, external dividend callbacks that can revert transfers, and broad tax-processor access to accumulated tax tokens. Slither was not run.
No Critical or High vulnerability was confirmed from the supplied evidence. The main material risks are conditional: transfers can fail if the configured dividend contract rejects share updates; tax enforcement may continue beyond its configured expiry for buys and non-main-pool transfers; and the fixed tax processor can receive or pull accumulated tax-token balances through the approved liquidation flow. GoPlus indicates the deployed token is not currently detected as a honeypot, mintable, blacklisted, pausable, or proxy-based.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0x6b3131b25b5230213cd084b0dae07ac0f44b7777.
This report was last modified on 2026-09-29 and contains 4 material findings.
medium finding: Tax expiry is only processed on transfers to the main pool
The contract claims time-dependent taxes automatically expire, but the state transition logic is executed only when _liquidateTax is called with to == mainPool. Buys from the main pool, transfers involving other configured pools, and ordinary wallet transfers do not trigger the expiration transition. As a result, tax enforcement can remain active after taxExpirationTime until a qualifying sell or transfer to mainPool occurs.
Evidence: _transfer calls _liquidateTax(to), while _liquidateTax performs expiration and anti-farmer state changes only inside the condition ending with (to == mainPool). Tax calculation then uses the unchanged poolState for transfers that do not target mainPool.
Recommendation: Evaluate tax and anti-farmer expiration directly during every _transfer call, or use a shared state-refresh function before tax calculation regardless of the destination. Add tests covering buys, alternate pools, wallet transfers, and expiry boundaries.
medium finding: Configured dividend contract can block token transfers
Every transfer involving a non-exempt user invokes dividendContract.setShare. If either external call reverts, the custom DividendShareUpdateFailed error reverts the entire token transfer. The dividendContract address is supplied during initialization and is not validated as nonzero or otherwise independently verified. A malfunctioning, incompatible, or intentionally reverting dividend contract can therefore prevent ordinary user transfers.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks that explicitly revert on failure. Only the token contract, pools, zero address, dead address, and dividend contract itself are exempted.
Recommendation: Avoid making core ERC-20 transfers dependent on an external dividend callback. Consider non-blocking failure handling, a separately controlled dividend-update queue, or a validated and replaceable dividend module with a documented emergency bypass.
medium finding: Tax processor has privileged custody of accumulated tax tokens
The token grants taxProcessor an effectively unlimited allowance and invokes it to liquidate collected tax tokens. If processing fails, the fallback path transfers the entire token-contract balance, rather than only the current taxAmount, directly to taxProcessor. A compromised or incorrectly configured processor can therefore control accumulated tax balances and may pull future balances using the retained maximum allowance.
Evidence: _processTax sets allowance(address(this), taxProcessor) to type(uint256).max when needed and calls processTaxTokens(taxAmount). In the catch branch it reads balanceOf(address(this)) and transfers the full remainingBalance to taxProcessor. The taxProcessor address has no setter in the token contract.
Recommendation: Use bounded approvals or approve only the current amount, limit fallback transfers to the intended taxAmount, and add governance or timelock controls around processor configuration. Verify the deployed processor implementation and its authorization model before relying on accumulated tax balances.
medium finding: Owner-controlled migration lifecycle can change trading behavior
The owner controls startMigration and finalizeMigration, which determine when pool transfers become permitted and when tax enforcement begins. An owner that remains active could delay migration, finalize at an unexpected time, or leave the contract in the Migrating state. GoPlus reports the current owner address as the zero address, reducing evidence of active control on the scanned deployment, but the source-level privilege remains relevant to deployment and lifecycle management.
Evidence: startMigration and finalizeMigration are both onlyOwner. BondingCurve rejects transfers to or from configured pools, Migrating permits plain transfers, and finalizeMigration enters TaxEnforcedAntiFarmer with configured tax timestamps. GoPlus reports owner_address as 0x0000000000000000000000000000000000000000.
Recommendation: Document the intended migration authority and state transitions, emit and monitor lifecycle events, and ensure ownership is renounced or governed only after migration is irreversibly complete. Add safeguards against prolonged or premature lifecycle transitions.