DIAX (DIAX) security report
SecureChain Radar AI scanned DIAX using verified Solidity source and GoPlus evidence. Slither was not run. GoPlus found no detected honeypot, minting, blacklist, or owner-balance risk. The source review identified medium-risk concerns: a failing dividend contract can revert ordinary transfers, the tax processor receives unlimited allowance over token-contract balances, and initializer-supplied tax rates above 100% can make pool trades revert. Current live tax, state, owner timing, and external processor behavior require on-chain verification.
DIAX was AI scanned using the verified Solidity source and supplied GoPlus evidence. No confirmed direct theft or minting path was identified, and GoPlus reports no honeypot, blacklist, mintability, or owner-balance signal. Material medium-risk controls remain around dividend-contract transfer blocking, tax-processor custody, and unrestricted initialization tax parameters. Slither was not run.
Trust score: 58/100. Source verified: Yes. Chain: bsc. Contract: 0xd9a093f9ac6b2ab0e2e15eaf83de3f5682a97777.
This report was last modified on 2026-09-29 and contains 5 material findings.
medium finding: Dividend contract failure can block ordinary token transfers
Every transfer involving a non-excluded sender or recipient invokes dividendContract.setShare(). If either callback reverts, _afterTokenTransfer reverts the entire ERC20 transfer. A misconfigured, paused, malicious, or incompatible dividend contract can therefore prevent users from transferring tokens, including transfers that do not involve a pool.
Evidence: In _afterTokenTransfer(), setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) are each wrapped in try/catch that reverts with DividendShareUpdateFailed on failure. The calls are executed by the inherited ERC20 transfer path for transfers, transferFrom, and taxed transfers.
Recommendation: Make dividend-share updates fail-open or decouple them from ERC20 transfers. Consider queued share updates, a bounded administrative recovery mechanism, and explicit validation that the configured dividend contract implements the expected interface before trading begins.
medium finding: Tax processor receives unlimited allowance over token-contract holdings
Once tax processing occurs, the token contract approves taxProcessor for type(uint256).max and never revokes that approval. The configured tax processor can subsequently call transferFrom(address(this), ...) and move any DIAX balance held by the token contract, including accumulated tax tokens and any tokens accidentally sent there. This is a strong custody and external-contract trust assumption rather than a direct arbitrary-user drain.
Evidence: _processTax() executes _approve(address(this), taxProcessor, type(uint256).max) when the allowance is insufficient. No allowance reset or spending limit is implemented. The GoPlus evidence does not assess the behavior or trustworthiness of taxProcessor.
Recommendation: Use exact per-liquidation approvals, reset allowances after processing, restrict the processor interface and deployment configuration, and add monitoring for unexpected transferFrom activity from the token contract.
medium finding: Initialization permits trade-blocking tax rates above 100%
buyTax and sellTax are accepted as uint16 values without a maximum of 10000 basis points. If either configured rate exceeds 10000, _taxedTransfer computes tax greater than amount and amount - tax reverts, blocking the corresponding pool buys or sells while that tax state is active. This is a deployment-configuration risk; the supplied data does not include the live configured rates.
Evidence: initialize() stores params.buyTax and params.sellTax directly into poolState. _getTaxWithPoolState() calculates amount * rate / 10000, while _taxedTransfer() performs uint256 remainingAmount = amount - tax. GoPlus reports is_honeypot=0 but provides blank buy_tax, sell_tax, and transfer_tax values, so the live configuration is not established by the supplied evidence.
Recommendation: Enforce buyTax <= 10000 and sellTax <= 10000 in initialize(), preferably with a lower protocol maximum. Publish the live pool state and tax rates, and test all migration and expiration paths before enabling liquidity.
medium finding: Owner-controlled migration state can restrict pool trading before migration
While the token remains in BondingCurve state, any transfer to or from a configured pool reverts. Only the owner can call startMigration() and finalizeMigration(). Consequently, delaying or failing migration prevents trading through the configured pools; calling the state transitions also determines when tax enforcement begins.
Evidence: _transfer() requires !pools[from] && !pools[to] in BondingCurve state. startMigration() and finalizeMigration() are both onlyOwner. The GoPlus record reports owner_address=0x0000000000000000000000000000000000000000 and owner_balance=0, while no live poolState response was supplied.
Recommendation: Verify the on-chain owner, state, migration events, and pool mapping. Use an immutable or timelocked migration process where possible, and document the expected state transitions before users provide liquidity.
medium finding: External tax processing can redirect or strand collected taxes
Tax liquidation delegates handling of collected tokens to an externally configured taxProcessor. If processing reverts, the catch branch transfers the entire remaining token-contract balance to taxProcessor rather than retaining the balance for a retry or refund. This creates a material reliance on the processor's implementation and configuration, and can redirect accumulated tax tokens even when the intended liquidation failed.
Evidence: _processTax() calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). On failure, it obtains balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance). The taxProcessor address is set during initialize() and is not changeable through the shown public interface.
Recommendation: On processing failure, retain funds for a controlled retry or send only the specific liquidation amount. Add recipient and processor validation, transparent accounting, and an emergency recovery path governed by a timelock or multisig.