Is BEN a Scam? New Token Security Check

Security Findings

1 High2 Med1 Low1 Info

High

Potential Reentrancy in `_liquidateTax` Function

H-01The `_liquidateTax` function is called within the `_transfer` function. While the provided code is truncated, the presence of `ITaxProcessor` and `IDividend` interfaces strongly suggests that `_liquidateTax` will make external calls to these contracts. If these external calls are made before critical state updates (e.g., updating `poolState` or `balanceOf(address(this))`) or without proper reentrancy guards, a malicious external contract could re-enter `_transfer` or `_liquidateTax` to drain funds or manipulate the contract's state. This is a common vulnerability pattern in contracts interacting with external addresses.

IssueThe `_liquidateTax` function is called within the `_transfer` function. While the provided code is truncated, the presence of `ITaxProcessor` and `IDividend` interfaces strongly suggests that `_liquidateTax` will make external calls to these contracts. If these external calls are made before critical state updates (e.g., updating `poolState` or `balanceOf(address(this))`) or without proper reentrancy guards, a malicious external contract could re-enter `_transfer` or `_liquidateTax` to drain funds or manipulate the contract's state. This is a common vulnerability pattern in contracts interacting with external addresses.

FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard` or a custom mutex) on the `_liquidateTax` function and any other functions that make external calls and modify state. Ensure that all state changes related to the external call are completed before the call is made (Checks-Effects-Interactions pattern).

StatusUnresolved

Medium

Timestamp Dependence for Critical State Transitions

M-01The `_liquidateTax` function relies on `block.timestamp` to determine critical state transitions, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is suitable for general time-based events, miners can manipulate it within a small window (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner or a sophisticated attacker to slightly accelerate or delay the transition to `TaxFree` or `TaxEnforced` states, potentially impacting tax collection or anti-farmer mechanisms in a specific block.

IssueThe `_liquidateTax` function relies on `block.timestamp` to determine critical state transitions, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is suitable for general time-based events, miners can manipulate it within a small window (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner or a sophisticated attacker to slightly accelerate or delay the transition to `TaxFree` or `TaxEnforced` states, potentially impacting tax collection or anti-farmer mechanisms in a specific block.

FixFor highly sensitive time-based events where precise timing is critical, consider using a time-weighted average oracle or a more robust time source if available and suitable for the use case. For less critical events, acknowledge the inherent miner manipulability of `block.timestamp` and ensure the impact of minor deviations is acceptable. In this context, the impact might be limited but should be understood.

StatusUnresolved

Medium

Integer Truncation Risk for Packed State Variables

M-02The `PackedPoolState` struct uses smaller integer types (`uint64`, `uint48`, `uint96`) for `taxExpirationTime`, `antiFarmerExpirationTime`, and `liquidationThreshold` respectively. During initialization, `initialLiquidationThreshold` (a `uint256`) is cast to `uint96` for `liquidationThreshold`. If `START_LIQ_THRESHOLD` (which sets `initialLiquidationThreshold`) is initialized with a value greater than `type(uint96).max` (approximately `7.9 * 10^28`), it will be silently truncated, leading to an incorrect and potentially exploitable `liquidationThreshold`. While `block.timestamp` is currently well within `uint48` and `uint64` limits, extremely large `antiFarmerDuration` values or very long c…

IssueThe `PackedPoolState` struct uses smaller integer types (`uint64`, `uint48`, `uint96`) for `taxExpirationTime`, `antiFarmerExpirationTime`, and `liquidationThreshold` respectively. During initialization, `initialLiquidationThreshold` (a `uint256`) is cast to `uint96` for `liquidationThreshold`. If `START_LIQ_THRESHOLD` (which sets `initialLiquidationThreshold`) is initialized with a value greater than `type(uint96).max` (approximately `7.9 * 10^28`), it will be silently truncated, leading to an incorrect and potentially exploitable `liquidationThreshold`. While `block.timestamp` is currently well within `uint48` and `uint64` limits, extremely large `antiFarmerDuration` values or very long c…

FixEnsure that `START_LIQ_THRESHOLD` is always initialized with a value that fits within `uint96` to prevent silent truncation. Add a `require` statement in the `initialize` function to explicitly check `require(params.initialLiquidationThreshold <= type(uint96).max, 'Liquidation threshold too large');` or similar. For time-related variables, consider if `uint256` is more appropriate if durations could be exceptionally long, or add checks to ensure sums fit within the packed types.

StatusUnresolved

Low

Centralized Control Over Migration Functions

L-01The `startMigration` and `finalizeMigration` functions are protected by the `onlyOwner` modifier. This grants the contract owner exclusive control over initiating and completing the migration process, which involves critical state changes. While common for administrative functions, this centralization introduces a single point of failure. If the owner's private key is compromised, an attacker could manipulate the contract's state transitions related to migration.

IssueThe `startMigration` and `finalizeMigration` functions are protected by the `onlyOwner` modifier. This grants the contract owner exclusive control over initiating and completing the migration process, which involves critical state changes. While common for administrative functions, this centralization introduces a single point of failure. If the owner's private key is compromised, an attacker could manipulate the contract's state transitions related to migration.

FixFor critical administrative functions, consider implementing a multi-signature wallet (e.g., Gnosis Safe) as the contract owner. This distributes control and requires multiple approvals for sensitive operations, significantly reducing the risk associated with a single compromised key. Alternatively, implement a time-lock mechanism for these functions to provide a window for users to react to pending changes.

StatusUnresolved

Info

Initial Token Distribution to Deployer

I-01During the `initialize` function, the entire `maxSupply` of tokens is minted to `msg.sender` (the deployer of the proxy contract). This means that initially, all tokens are held by a single address. While this is a common pattern for initial token distribution, it implies that the deployer has full control over the initial supply and subsequent distribution.

IssueDuring the `initialize` function, the entire `maxSupply` of tokens is minted to `msg.sender` (the deployer of the proxy contract). This means that initially, all tokens are held by a single address. While this is a common pattern for initial token distribution, it implies that the deployer has full control over the initial supply and subsequent distribution.

FixThis is an informational finding and not a vulnerability in itself. However, it is important for transparency and to ensure that the project's token distribution strategy is clearly communicated to the community. If not already planned, consider a clear and secure strategy for distributing these tokens to avoid centralization concerns or potential market manipulation.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract demonstrates good technical practices, leveraging OpenZeppelin's upgradeable ERC20 and Ownable implementations (7.2 Code Security). The `PackedPoolState` struct uses efficient storage packing, and initial parameter checks are robust (7.1 Architecture). However, the `_liquidateTax` function, which is called within `_transfer`, appears to involve external calls to `ITaxProcessor` and `IDividend` (based on interfaces), presenting a potential reentrancy vulnerability if not properly guarded (7.2 Code Security, 7.6 External). Additionally, critical state transitions rely on `block.timestamp`, which can be subject to minor miner manipulation (7.2 Code Security). Integer truncation risks exist when casting `uint256` values to smaller types like `uint96` for `liquidationThreshold` during initialization (7.2 Code Security).

GovernanceLow7/10

The economic model incorporates dynamic tax rates and anti-farmer mechanisms, with checks like `taxDuration >= antiFarmerDuration` ensuring logical consistency (7.4 Economic). The `maxSupply` is fixed and minted entirely to the deployer during initialization, which is a common but notable initial distribution strategy (7.4 Economic). Access control for critical state changes, such as `startMigration` and `finalizeMigration`, is restricted to the contract owner (7.3 Access Control, 7.5 Governance). This centralization introduces a single point of failure, where a compromised owner key could lead to unauthorized state transitions (7.5 Governance).

UpgradesLow9/10

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's `Initializable` and `Upgradeable` contracts, including `_disableInitializers()` in the constructor and the `initializer` modifier (7.7 Upgrades). Immutable and constant variables are handled appropriately, preventing modification in future upgrades. A minor concern is the `PackedPoolState` struct; while efficient, any future changes to its layout in an upgrade would require careful management (e.g., using `_gap` variables) to avoid storage collisions, a standard consideration for upgradeable contracts (7.7 Upgrades).

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

20.3% in top 10

8.4% in wallets11.9% in contracts

Effective Concentration13.2%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$272.3K across 6 pairs

Pancakeswap v2QQQBanalysed$207.4K UniswapUSDT$41.7K Pancakeswap v3USDT$23.3K Pancakeswap v2WBNB$1 Pancakeswap v2USDT$1 Uniswap v2USDT$0

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder23.8%

Top-3 Unlocked53.3%

Key Addresses

11 addresses

Deployer

0x51e0…536e

Unlocked LP Held By

0x8835…036f0x5004…4d870x64ac…b9200xf92f…4a700x71a0…4e0b0x8e0b…e8380xe980…beb00xf1db…41bd0x4ff4…0c710xed26…cde5

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

5 factors

Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Token age < 7 days (early, volatile)
1 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Not Signed In

Is BEN a Scam?

Security Findings

Potential Reentrancy in `_liquidateTax` Function

Timestamp Dependence for Critical State Transitions

Integer Truncation Risk for Packed State Variables

Centralized Control Over Migration Functions

Initial Token Distribution to Deployer

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of BEN?