LIFE (LIFE) security report
Radar AI scanned the verified LIFE contract on BNB Smart Chain and found material tax-processing, initialization, transfer-callback, and migration-control risks.
The contract is not free of material security and control risks. The most significant issue is that a reverting tax processor causes the token contract to transfer its entire token balance—not only the current tax amount—to that processor. Transfers can also revert whenever the configured dividend contract rejects share updates, and pool transfers remain restricted while the owner leaves the contract in BondingCurve state. Initialization must be performed atomically because the initializer mints the full maximum supply to its caller.
Trust score: 42/100. Source verified: Yes. Chain: bsc. Contract: 0x317d4841801cf9a6245be44979129e6ea6477777.
This report was last modified on 2026-10-05 and contains 5 material findings.
high finding: Tax processor failure path transfers the entire contract token balance
When tax processing fails, the fallback path transfers every LIFE token held by the token contract to the configured taxProcessor. This can include taxes accumulated from multiple liquidation cycles, not merely the taxAmount associated with the failed call. The configured processor is therefore a powerful custody point for collected tax tokens.
Evidence: In _processTax(), a failed ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) call is caught, then balanceOf(address(this)) is read and _plainTransfer(address(this), taxProcessor, remainingBalance) transfers the full balance to taxProcessor.
Recommendation: Do not transfer the full contract balance in the failure handler. Limit fallback handling to the current taxAmount, use an explicit recovery process, and add governance or timelock controls around the tax processor. Test processor reverts and partial-processing scenarios.
high finding: Uninitialized deployment can be taken over and receive the full supply
The external initialize function is protected only by the one-time initializer guard and has no factory or deployer restriction. If a proxy or clone is deployed without initialization in the same transaction, the first caller can choose the token configuration, become owner, and receive the full maximum supply minted by initialize.
Evidence: initialize(...) is external and uses initializer, then calls __Ownable_init(), which assigns ownership to msg.sender, and executes _mint(msg.sender, maxSupply). maxSupply is fixed at 1e9 ether. The supplied materials do not include deployment-transaction evidence proving atomic initialization.
Recommendation: Initialize every proxy or clone atomically in its deployment transaction, verify the Initialized event and owner configuration, and have deployment tooling reject uninitialized instances before they are exposed publicly.
medium finding: Dividend callback failure can block ordinary token transfers
Transfers involving non-excluded accounts invoke the configured dividend contract. If either setShare call reverts, the token transfer itself reverts. A misconfigured, unavailable, or adversarial dividend contract can therefore prevent affected transfers and may create a material transfer-lock condition.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)). Each call is wrapped in try/catch, but the catch reverts with DividendShareUpdateFailed instead of allowing the token transfer to complete.
Recommendation: Decouple balance transfers from dividend bookkeeping, or provide a bounded failure-tolerant mode with an authorized repair path. Validate the dividend contract during initialization and test behavior when setShare reverts or consumes excessive gas.
medium finding: Owner-controlled migration sequencing can keep pool transfers restricted
While the pool state is BondingCurve, every transfer to or from any configured pool reverts. The owner controls the only exposed transitions into Migrating and then tax-enforced states, so the owner can delay migration and keep configured pool interactions unavailable.
Evidence: In _transfer(), the BondingCurve branch requires !pools[from] && !pools[to]. startMigration() and finalizeMigration() are both onlyOwner, and no permissionless or time-based transition exists.
Recommendation: Use an immutable or time-bounded migration schedule, publish the expected transition conditions, and consider a permissionless transition after the bonding-curve phase has elapsed. Monitor owner actions and document the restriction clearly.
medium finding: Initialization accepts unchecked tax and external dependency configuration
Initialization accepts buy and sell tax rates, pool addresses, tax processor, dividend contract, router, and timing parameters without validating several safety invariants. A bad deployment configuration can impose excessive taxes, route tax processing to an untrusted contract, or create transfer and liquidation failures. The supplied ABI does not expose post-initialization correction functions for these settings.
Evidence: initialize() directly stores params.buyTax, params.sellTax, params.taxProcessor, params.dividendContract, params.v2Router, and params.pools. The tax calculation divides by 10000 but does not cap rates at 10000, and the external dependency addresses are not checked for code or interface compatibility.
Recommendation: Validate rates, addresses, pool uniqueness, timing relationships, and dependency interfaces before initialization. Add deployment-time assertions and immutable configuration manifests, and use trusted audited implementations for external processors and dividend contracts.