Tokenize Everything (万物上链) security report
SecureChain AI scanned the verified Tokenize Everything contract on BSC. GoPlus found no honeypot, minting, blacklist, proxy, or reported taxes. Independent source review found medium risks involving lazy tax expiration, blocking dividend callbacks, initialization-time tax configuration, and external tax-processing fallbacks. Slither was not run.
The supplied evidence does not show a proven honeypot, mint function, blacklist, proxy, or active owner control; GoPlus reports is_honeypot=0, is_mintable=0, is_blacklisted=0, is_proxy=0, and owner_address=0x0000000000000000000000000000000000000000. However, source review identified medium-severity business-logic and availability risks. Tax state expiration is only processed during transfers to mainPool, and external dividend callbacks can revert token transfers if the configured dividend contract fails. Slither was not run, so this is not a Slither-complete audit.
Trust score: 70/100. Source verified: Yes. Chain: bsc. Contract: 0x2740fac3c69aab40c18ec90fee62500fa5be7777.
This report was last modified on 2026-09-19 and contains 4 material findings.
medium finding: Dividend callback can globally block token transfers
Every transfer involving a normal user address invokes dividendContract.setShare for the sender and/or recipient. Any revert from that external contract is propagated through DividendShareUpdateFailed, causing the token transfer itself to revert. If the configured dividend contract is paused, misconfigured, malicious, or otherwise unavailable, ordinary token transfers can become unavailable.
Evidence: In _afterTokenTransfer, IDividend(dividendContract).setShare(...) is called without suppressing failure; the catch block executes revert DividendShareUpdateFailed(from, reason) or revert DividendShareUpdateFailed(to, reason). The dividendContract address is supplied during initialize and is not changeable through a public setter.
Recommendation: Use a trusted, independently tested dividend contract and validate it during initialization. Consider making share updates non-blocking, queueing failed updates, or adding a carefully governed emergency bypass that cannot alter balances.
medium finding: Tax expiration is lazily enforced only on transfers to mainPool
The contract checks taxExpirationTime and antiFarmerExpirationTime only inside _liquidateTax, and _liquidateTax only performs state processing when the current transfer recipient is mainPool. Consequently, after the configured expiration timestamp, buys or transfers involving other configured pools may continue using the old tax state until a transaction sends tokens to mainPool.
Evidence: _transfer calls _liquidateTax(to), while _liquidateTax contains the state-transition logic under && (to == mainPool). Tax calculation for TaxEnforcedAntiFarmer can apply to all entries in pools, so a transfer involving another pool does not itself trigger expiration.
Recommendation: Evaluate and transition expired tax states before every taxed transfer, or use timestamp checks directly in _getTaxWithPoolState. Add tests covering expiry with no subsequent mainPool sell and activity on secondary pools.
medium finding: Initialization can configure prohibitive tax rates and restrictive pool behavior
initialize accepts buyTax and sellTax as uint16 values with no application-level maximum. Rates up to 65535 basis points are accepted. A rate above 10000 basis points makes remainingAmount = amount - tax underflow in _taxedTransfer, reverting the affected buy or sell. Initialization also selects the pools, tax processor, dividend contract, and migration durations, so launch-time configuration is a significant trust and availability boundary.
Evidence: initialize stores params.buyTax and params.sellTax directly in PackedPoolState. _getTaxWithPoolState computes amount * rate / 10000, and _taxedTransfer executes uint256 remainingAmount = amount - tax. No require limits either rate to 10000 basis points or validates the external processor and dividend contract behavior. GoPlus supplies blank buy_tax and sell_tax fields, so the deployed effective rates were not independently confirmed from the supplied evidence.
Recommendation: Enforce explicit maximum rates, normally <=10000 basis points or a lower documented cap, and validate all initialization addresses and durations. Publish the initialized parameters and independently verify the deployed pool state before users trade.
medium finding: Tax-processing failure sweeps the entire token-contract balance to taxProcessor
When the external TaxProcessor call fails, the fallback transfers balanceOf(address(this)) to taxProcessor rather than limiting the transfer to the taxAmount being processed. Tokens accidentally sent to the token contract, or any other balance accumulated there, can therefore be transferred to the configured processor. This creates a material external-dependency and asset-routing risk.
Evidence: In _processTax, the catch block reads uint256 remainingBalance = balanceOf(address(this)) and then calls _plainTransfer(address(this), taxProcessor, remainingBalance). The fallback is reached when ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) reverts.
Recommendation: Restrict fallback handling to the intended tax amount, explicitly account for pre-existing balances, and use a recovery mechanism with transparent authorization for unrelated tokens. Verify the processor address and behavior before deployment.