TapeFour (TapeFour) security report
Radar AI scanned TapeFour on BNB Smart Chain from verified source. The review found medium-severity risks involving erased unpaid rewards and externally controlled transfer and payout behavior.
The source does not show an owner-controlled mint, proxy, or explicit honeypot mechanism. However, holder rewards can be permanently underpaid or erased during claims when the contract balance is insufficient, and the configured shareholder manager can block transfers or redirect reward payments.
Trust score: 62/100. Source verified: Yes. Chain: bsc. Contract: 0xe6df1162a3243e3064e43f187ea14808ddfdffff.
This report was last modified on 2026-10-30 and contains 3 material findings.
medium finding: Insufficient reward balance can permanently erase unpaid holder rewards
The claim path clears an account's accrued reward state before checking whether the contract holds enough quote tokens. If the available balance is lower than the claimable amount, the contract pays only the available balance but does not restore the unpaid remainder.
Evidence: In `_claimFee`, `info.rewardDebt` is updated and `info.claimable = 0` before `balanceQuote` is checked. When `amountQuote > balanceQuote`, the amount is reduced to `balanceQuote`, `FeeInsufficient` is emitted, and any unpaid remainder is discarded. A zero quote balance can therefore erase the entire recorded claimable amount without payment.
Recommendation: Compute the payable amount before finalizing accounting, or preserve the unpaid remainder in `info.claimable` after a partial payment. Add tests for zero-balance and partial-balance claims, including claims invoked through the batch `claimFee(address[] accounts)` function.
medium finding: Configured shareholder manager can censor transfers and redirect reward recipients
If a shareholder manager is configured, it is consulted during every token transfer and every reward claim. A manager implementation that reverts or marks an account as blacklisted can block transfers or claims, while its redirect result determines where rewards are sent instead of directly to the account.
Evidence: `postInitialize` assigns `shareHolderManager`. `_transfer` calls `isBlacklisted(address(this), from)` and reverts with `TaxToken: blacklisted sender` when true. `_claimFee` also returns without paying blacklisted accounts and calls `claimRedirect(account)`; a nonzero returned address receives the quote reward.
Recommendation: Make transfer eligibility independent of a failure-prone external manager, or define an explicit fail-open policy and immutable trusted-manager governance. Emit configuration and redirect events, document blacklist authority, and provide a verifiable recovery process for blocked or redirected claims.
medium finding: External founder and helper integrations can delay tax dispatch and fee processing
Tax dispatch depends on external founder, wrapped-native, and token-helper calls. Reverting or unavailable integrations can defer founder, burn, or liquidity allocations; in some paths, a founder ERC20 transfer revert propagates through dispatch and can cause the triggering transfer to revert.
Evidence: `_transferFounderFee` uses `IERC20(quote).safeTransfer(founder, amountQuote)` without a try/catch for ERC20 quote payments. `_sendFounderNative` calls `ITokenHelper(tokenHelper).getGasLimit(address(this))` and then sends native currency to `founder`. `_dispatchFee` is invoked from transfer paths, so a reverting external dependency can affect ordinary transfers that trigger dispatch.
Recommendation: Isolate fee processing from user transfers using bounded, failure-tolerant accounting. Catch and reserve failed founder payments consistently, validate helper configuration before enabling a phase, and provide explicit keeper recovery paths for deferred balances.