SynapseAi (SPS) security report
Radar AI scanned SynapseAi SPS on BNB Smart Chain on October 15, 2026. The verified source has fixed supply and no upgrade path, but includes medium-severity dividend dilution and reward-configuration trust risks.
No critical or high-severity exploit was identified from the supplied verified source. Two medium-severity risks remain: the token contract can receive unclaimable dividend shares, and the deployment owner controls the reward router and oracle implementations during configuration.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0x175d634f9b56a7a6a0486aeabd6c3c668bdefcb7.
This report was last modified on 2026-10-15 and contains 2 material findings.
medium finding: The token contract receives dividend shares that it can never withdraw
Synapse refreshes the dividend share for address(this) after transfers, including when tax proceeds accumulate in the token contract. SynapseDividends includes that balance in totalShares, but its payout routine explicitly rejects holder == address(this). Once the token contract's balance reaches the configured minimum share threshold, it participates in rewards while its accrued BNB cannot be paid, permanently diluting other dividend recipients.
Evidence: In Synapse._update, dividends.setShare(address(this), balanceOf(address(this))) is called after every transfer when dividends are configured. SynapseDividends._setShare adds that share to totalShares. SynapseDividends._pay contains require(holder != address(this), "BNB self payment"), so withdrawDividendsFor(address(this)) and batch payment for that address cannot succeed. The precondition is that the token contract's tax balance reaches minimumShareBalance.
Recommendation: Exclude address(this) from dividend shares, or implement a deliberate and auditable treatment for tax-held SPS that does not accrue an unpayable BNB claim. Add tests covering tax accumulation, share accounting, and total reward allocation after the token contract crosses the threshold.
medium finding: Owner-selected reward router and feeds create a powerful configuration trust boundary
Before ownership is renounced, the owner can select arbitrary contract implementations for the reward router and both execution feeds. The checks validate code presence and selected feed metadata, but do not verify trusted implementations, router behavior, oracle integrity, or that the router will preserve tax proceeds. A malicious or faulty configuration can disrupt tax processing, distort minimum-output calculations, or cause approved tax tokens to be transferred to an unintended router-controlled destination.
Evidence: Synapse.configureRewards is onlyOwner and accepts router, tokenFeed, and nativeFeed addresses supplied by the caller. It checks code.length, feed baseToken/usdToken relationships, and a nonzero factory pair, then stores the supplied interfaces and creates SynapseDividends using tokenFeed. processTaxes approves rewardRouter for the tax amount and calls swapExactTokensForETHSupportingFeeOnTransferTokens on that configured address. No implementation identity, router code hash, or governance timelock is enforced.
Recommendation: Use immutable, audited router and feed addresses where possible, or restrict configuration to an allowlist governed by a timelock or multisignature. Validate swap output and recipient behavior against a trusted router, and require configuration tests or a delayed activation before tax processing is enabled.