damn (我靠) security report
Radar AI scanned the verified damn contract on BNB Smart Chain. Material findings include conditional transfer failures from invalid tax configuration or dividend callback reverts, plus a broad allowance granted to the tax processor. No Slither analysis was run.
The contract does not expose owner-controlled minting, blacklist, pause, or post-deployment tax setter functions in the verified source. However, initialization does not validate that buy and sell tax rates are at most 10000 basis points, and a misconfigured rate can make pool transfers revert. Transfers also depend on an external dividend contract, while the tax processor receives an unlimited allowance over tokens held by the token contract.
Trust score: 64/100. Source verified: Yes. Chain: bsc. Contract: 0x3db2114a7abd610efa450384a8d8aeb4b3107777.
This report was last modified on 2026-11-04 and contains 4 material findings.
medium finding: Unchecked tax rates can make pool transfers revert
initialize accepts buyTax and sellTax without requiring either value to be at most 10000 basis points. During taxed transfers, the contract computes tax as amount multiplied by the configured rate divided by 10000, then subtracts that tax from amount. A rate above 10000 makes amount - tax revert, preventing affected buys or sells while the tax state is active.
Evidence: In initialize(), params.buyTax and params.sellTax are copied directly into poolState without an upper-bound check. In _getTaxWithPoolState(), tax is calculated as (amount * currentPoolState.buyTaxRate) / 10000 or the equivalent sell expression. In _taxedTransfer(), uint256 remainingAmount = amount - tax; Solidity 0.8 arithmetic reverts if tax exceeds amount.
Recommendation: Validate both tax parameters with require(params.buyTax <= 10000 && params.sellTax <= 10000) during initialization. Also test every migration and tax state with boundary rates before deployment.
medium finding: Dividend callback failure can block token transfers
Every transfer involving a non-excluded address invokes the configured dividend contract through setShare(). If that external call reverts, the token transfer itself reverts. A broken, unavailable, incompatible, or intentionally reverting dividend contract can therefore prevent ordinary transfers for affected accounts.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) when the addresses are not excluded. Both calls catch failures and revert with DividendShareUpdateFailed. dividendContract is assigned during initialize() and has no setter or fallback path in the token source.
Recommendation: Do not make transfer success depend on an external dividend callback. Consider non-blocking share updates, queued synchronization, or a bounded administrative recovery mechanism. Validate the dividend implementation and test callback failures before initialization.
medium finding: Tax processor receives unlimited allowance over token-contract balances
When taxes are first liquidated, the token grants taxProcessor an unlimited ERC20 allowance over the token contract's balance. This creates a strong trust dependency: a compromised or malicious tax processor can use transferFrom to move tokens held by the token contract beyond the intended current liquidation amount. If processing fails, the catch branch also transfers the remaining token-contract balance directly to taxProcessor.
Evidence: _processTax() calls _approve(address(this), taxProcessor, type(uint256).max) when the allowance is insufficient. The allowance is not reduced after processing. The catch branch calculates remainingBalance = balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance). taxProcessor is set from initialization parameters and is not changeable in the shown token contract.
Recommendation: Limit approvals to the current taxAmount, reset or reduce allowances after processing, and ensure the processor cannot transfer unrelated token balances. Add explicit accounting so failure handling forwards only the intended tax amount and document the processor's trust assumptions.
medium finding: Owner controls the migration gates that enable pool trading and tax states
The owner controls startMigration() and finalizeMigration(), which govern the transition out of BondingCurve. While the token remains in BondingCurve, transfers to or from every configured pool revert. This is a privileged launch and trading-control dependency rather than evidence of an active exploit in the supplied scan state.
Evidence: _transfer() requires !pools[from] && !pools[to] in PoolState.BondingCurve, otherwise reverting with Transfers to/from pools are restricted in BondingCurve state. startMigration() and finalizeMigration() are both external onlyOwner functions that move the pool through migration states.
Recommendation: Use an explicit launch process with publicly documented migration conditions, multisignature ownership, and event monitoring. Verify the deployed state and migration completion independently before treating pool transfers as enabled.