Darkex (Darkex) security report
Radar AI scanned Darkex's verified contract source on BNB Smart Chain. Material findings include mutable owner controls over fees and exemptions, owner withdrawals, and automatic swaps without minimum output protection. Slither was not run.
Darkex does not expose an apparent mint, blacklist, proxy upgrade, or explicit honeypot restriction in the reviewed source. However, the owner retains material control over transfer fees, treasury routing, fee exemptions, swap behavior, and contract-held assets. These controls create meaningful centralization and execution risks.
Trust score: 58/100. Source verified: Yes. Chain: bsc. Contract: 0x0d0b469508d9f30cd481d10d4cd695481ff503b9.
This report was last modified on 2026-10-07 and contains 5 material findings.
medium finding: Owner can disable automatic swaps, changing fee-processing behavior
The owner can toggle automatic fee-token swaps on or off. Disabling swaps causes fee tokens to remain in the contract until a manual owner action or another enabled swap path processes them, changing how treasury proceeds are realized.
Evidence: toggleSwap(bool enable) is external onlyOwner and directly assigns swapEnabled. _transfer only calls swapTokensForEth when swapEnabled is true, while manualSwap() is separately restricted to the owner.
Recommendation: Place swap-control changes behind a timelock or multisignature process, publish expected behavior when swaps are disabled, and monitor contract-held fee tokens and native currency.
medium finding: Owner can materially change transfer fees and fee exemptions
The owner can set the treasury transfer fee up to 8%, redirect future treasury proceeds, and arbitrarily include or exclude addresses from fees. This allows the owner to change transfer economics and selectively exempt accounts after deployment.
Evidence: setFee(uint16,uint16) is restricted by onlyOwner and validateFees permits treasuryTax_ <= 800, representing up to 8% when fees are calculated as amount multiplied by the tax and divided by 10,000. setTreasuryAddress is also onlyOwner and changes the recipient of fee proceeds. excludeMultipleAccountsFromFees lets the owner change fee treatment for any supplied address array. GoPlus reports slippage_modifiable as 1, consistent with mutable transfer economics.
Recommendation: Document the maximum fee and fee-exemption policy before deployment, use a timelock or multisignature owner, emit and monitor all fee and exemption changes, and consider immutable fee bounds or governance-controlled changes.
medium finding: Owner can withdraw assets held by the token contract
The owner can direct native currency and arbitrary ERC-20 tokens held by the contract to chosen destinations. This includes accumulated treasury-fee tokens before they are swapped and any other ERC-20 assets held by the contract.
Evidence: withdrawETH() is external onlyOwner and transfers the entire address(this).balance to treasuryAddress. withdrawTokens(address token,address to,uint amount) is external onlyOwner and calls IERC20(token).transfer(to, amount) with no restriction on the token, recipient, or amount other than the token contract's response.
Recommendation: Restrict withdrawals to explicitly documented operational assets, use a multisignature or timelocked owner, add recipient and asset safeguards, and publish the withdrawal policy for users.
medium finding: Automatic fee-token swaps accept any native-asset output
When swapEnabled is true and the contract holds tokens, ordinary transfers can invoke a swap of the entire contract token balance. The router call uses amountOutMin equal to zero, so the swap accepts any output amount. This creates an execution and treasury-proceeds risk during adverse execution conditions, although it does not itself prove theft or a honeypot.
Evidence: In _transfer, transfers meeting the stated conditions call swapTokensForEth(contractTokenBalance) when the contract balance is greater than zero. Each router branch calls a SupportingFeeOnTransferTokens function with amountOutMin set to 0. The resulting native currency is forwarded to treasuryAddress. GoPlus reports slippage_modifiable as 1.
Recommendation: Use a bounded minimum output derived from a trusted execution policy, limit swap size, consider a configurable but constrained slippage parameter, and test failure and low-output cases across supported routers.
medium finding: Treasury proceeds are sent through a low-level call whose result is ignored
After a successful router swap, the contract attempts to send newly received native currency to treasuryAddress using a 30,000-gas low-level call but does not check the returned success value. A treasury contract that rejects or consumes insufficient gas can cause proceeds to remain in the token contract until an owner withdrawal is performed.
Evidence: In every swap branch, the contract executes treasuryAddress.call{value: address(this).balance - currentNativeAmount, gas: 30_000}(''); without checking the returned boolean. withdrawETH() is the separate onlyOwner recovery path.
Recommendation: Check the low-level call result and define failure handling, or use a withdrawal-based treasury design with explicit accounting and monitoring for retained native currency.