PANTHEON (PANTHEON) security report
Radar by SecureChain AI scanned PANTHEON on BNB Smart Chain. Findings include pool-transfer restrictions controlled by the owner, transfer dependence on an external dividend callback, and broad fallback forwarding to the tax processor.
PANTHEON is not an unrestricted ERC-20 during its BondingCurve state: transfers involving configured pools revert until the owner starts and finalizes migration. After migration, transfers can still depend on the configured dividend contract, whose failed setShare call reverts the transfer. Tax processing also delegates control to an external processor and can forward the entire token balance to it when processing fails. GoPlus reports no proxy, minting, blacklist, or honeypot signal; Slither was skipped.
Trust score: 58/100. Source verified: Yes. Chain: bsc. Contract: 0x9234c02039d281396724083394e0aa1fa7c07777.
This report was last modified on 2026-10-08 and contains 3 material findings.
medium finding: External dividend callback can block token transfers
When dividendContract is nonzero, every transfer involving a non-exempt address calls IDividend.setShare. Any revert from that callback causes the token transfer to revert through DividendShareUpdateFailed. The dividend contract is selected during initialize and cannot be changed by this token contract.
Evidence: In _afterTokenTransfer, setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) are called unless the address is the token contract, zero address, dead address, dividendContract, or a configured pool. Each call is wrapped in try/catch, but the catch explicitly executes revert DividendShareUpdateFailed(...).
Recommendation: Use a trusted, tested dividend contract and validate its code and configuration during initialization. Consider making dividend accounting non-blocking, isolating failures, or adding a controlled recovery path so ordinary ERC-20 transfers cannot be permanently disabled by an external callback.
medium finding: Owner can keep configured pool transfers restricted
The owner controls the transition out of BondingCurve state. While that state remains active, all transfers to or from any address marked in pools revert, so the owner can delay or prevent trading through those configured pools until migration is started and finalized.
Evidence: _transfer checks PoolState.BondingCurve and executes require(!pools[from] && !pools[to], "Transfers to/from pools are restricted in BondingCurve state"). startMigration and finalizeMigration are both external onlyOwner functions, and no permissionless or time-based transition exists.
Recommendation: Document the launch state machine and migration authority, emit or monitor governance-controlled transition events, and consider enforcing bounded transition windows or a transparent, independently verifiable migration mechanism.
medium finding: Tax-processing failure forwards the entire token balance to the tax processor
If the external tax processor call fails during liquidation, the fallback transfers the token contract's full balance—not only the current tax amount—to taxProcessor. This creates a trusted-processor and accidental-deposit loss path if the configured processor is compromised, incorrect, or intentionally reverts.
Evidence: In _processTax, a failed ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) call is caught. The contract then reads balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance) for the entire remaining balance.
Recommendation: Limit fallback transfers to the intended taxAmount or separately tracked accrued-tax balance. Validate taxProcessor during initialization, avoid forwarding unrelated token deposits, and use explicit accounting and recovery controls for failed processing.