Slot7 (Slot7) security report
Slot7 was AI scanned using its verified BNB Chain source and supplied GoPlus evidence. Slither was skipped. No public mint, blacklist, selfdestruct, or proxy upgrade path was identified, but migration and tax configuration are centrally controlled, external contracts can affect fee handling and transfer execution, the owner holds about 62.2% of supply, and liquidity data is inconsistent.
The contract does not show an immediately exploitable public mint or obvious blacklist honeypot, and GoPlus reports is_honeypot=0 and is_mintable=0. However, migration is owner-controlled, initialization accepts tax rates up to uint16 without a 100% ceiling, and external tax/dividend dependencies can materially redirect fees or halt ordinary transfers. Current liquidity and ownership concentration also warrant caution.
Trust score: 52/100. Source verified: Yes. Chain: bsc. Contract: 0x006487e80ab2609fdddeac53776eb4cfc15e7777.
This report was last modified on 2026-09-20 and contains 6 material findings.
high finding: Unbounded initialization tax rates can create a trading lock or confiscatory tax path
The initializer accepts buyTax and sellTax as uint16 values but does not require either value to be at or below 10,000 basis points. During TaxEnforced states, _taxedTransfer calculates remainingAmount = amount - tax. Rates above 10,000 basis points cause an arithmetic revert for pool-related transfers, while a 10,000 basis-point rate sends the full amount as tax and leaves the recipient with zero. The owner controls when migration reaches tax-enforced states.
Evidence: initialize() stores params.buyTax and params.sellTax directly in poolState. _getTaxWithPoolState computes amount * rate / 10000. _taxedTransfer executes uint256 remainingAmount = amount - tax. startMigration() and finalizeMigration() are onlyOwner functions that activate the tax lifecycle.
Recommendation: Validate buyTax and sellTax against an explicit maximum of 10,000 basis points, preferably a lower governance-approved cap. Emit and monitor the configured rates before migration, and use a timelocked or multisig-controlled migration process.
high finding: Owner-controlled migration can activate configured restrictions and fees without a user safety delay
The owner can transition the token from BondingCurve to Migrating and then to TaxEnforcedAntiFarmer without an expiry, public veto, or timelock. In BondingCurve, transfers to or from any configured pool are rejected. After finalization, configured buy and sell taxes apply and may route collected tokens through the external tax processor. This creates a powerful centralized control over market availability and trading conditions.
Evidence: _transfer() requires !pools[from] && !pools[to] in PoolState.BondingCurve. startMigration() and finalizeMigration() are both onlyOwner. finalizeMigration() changes the state to TaxEnforcedAntiFarmer and establishes tax expiration timestamps.
Recommendation: Use a multisig and timelock for migration, publish the exact pool list and tax configuration, and add bounded, observable state-transition rules. Consider removing permanent owner discretion over activation timing.
medium finding: Trusted tax processor can receive or pull all accumulated tax tokens
Tax liquidation grants the configured taxProcessor an effectively unlimited allowance and calls its processTaxTokens function. If that call fails, the fallback path transfers the entire token balance held by the token contract directly to taxProcessor. The processor address is supplied during initialization with no code, interface, ownership, or behavior validation and cannot be changed through the exposed ABI.
Evidence: initialize() assigns taxProcessor = params.taxProcessor. _processTax() approves type(uint256).max when needed, calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount), and on catch executes _plainTransfer(address(this), taxProcessor, remainingBalance).
Recommendation: Validate the processor during initialization, use a trusted immutable or governed processor, avoid unlimited approvals where possible, and do not transfer all retained fees to the processor on failure. Add bounded recovery and transparent accounting for failed liquidations.
medium finding: Dividend callback failure can block ordinary token transfers
When dividendContract is nonzero, every transfer involving a non-excluded account calls dividendContract.setShare. Any revert from that external call is propagated as DividendShareUpdateFailed, reverting the complete token transfer. A broken, incompatible, or maliciously configured dividend contract can therefore prevent users from transferring tokens, even when no pool tax applies.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)); both calls catch failures and revert with DividendShareUpdateFailed. dividendContract is assigned from initialization without a nonzero or compatibility check.
Recommendation: Make share synchronization failure-tolerant, isolate it from the ERC20 transfer path, or use a robust trusted dividend implementation with operational fallback. Validate the configured contract and test transfer behavior when the dependency is paused or unavailable.
medium finding: Large holder concentration creates substantial centralized sell-pressure risk
GoPlus reports the owner address holds approximately 62.199% of total supply. A single holder controlling a majority of supply can materially affect price and liquidity through transfers or sales, even though the source does not provide an owner-only balance seizure function.
Evidence: Supplied GoPlus evidence: owner_address=0xe2ce6ab80874fa9fa2aae65d277dd6b8e65c9de0, owner_balance=621989644.9664965, owner_percent=0.62199; total_supply=1000000000.
Recommendation: Disclose the holder allocation and vesting or distribution plan, monitor large-holder movements, and assess whether liquidity can absorb a major sale. Do not treat ownership renunciation alone as a substitute for supply decentralization.
medium finding: Liquidity information is inconsistent and may indicate insufficient exit liquidity
The supplied project metadata lists approximately 10,313.92 USD of liquidity, while GoPlus reports the PancakeV2 pair liquidity as 0.00000000 and lp_holder_count=0. This inconsistency prevents reliable confirmation of available exit liquidity and may expose holders to severe price impact or inability to sell.
Evidence: Project data: liquidityUsd=10313.92. GoPlus DEX evidence: pair=0xb2ba57e6e47575ec09ec09?; liquidity=0.00000000; lp_holder_count=0. The supplied pair address is 0xb2ba57e6e47575ec09ec09? No, source evidence identifies 0xb2ba57e6e47575ec09b6a2b86048ff998b9df6ae.
Recommendation: Reconcile the pair and liquidity data on-chain, verify reserves and LP ownership, and confirm that the reported pool is the active trading venue before relying on the quoted liquidity figure.