CertiK reviewed BenTen Inu (Benten Inu - Audit) on 5 Jun 2023: 13 findings, 0 critical; 1 marked fixed, 3 acknowledged, 9 open.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 1 | 1 |
| Medium | 0 | 2 | 0 |
| Low | 9 | 0 | 0 |
All **BENT** tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute **BENT** tokens without the consensus of the community. *Note: The holder list can be found on the [BSC Chain](https://bscscan.com/token/0x1e8af416823b1911c6b640a10b817b47f962d56a#balances).*
```solidity function swapAndLiquify() private lockTheSwap { uint256 contractBalance = balanceOf(address(this)); swapTokensForBNB(contractBalance); uint256 deltaBalance = address(this).balance; if (deltaBalance > 0) { payable(marketingWallet).sendValue(deltaBalance); } } ``` The `swapAndLiquify()` function executes the `router.swapExactTokensForETHSupportingFeeOnTransferTokens()` function to convert `BENT` tokens into `BNB` and transfers the `BNB` to the designated `marketingWallet` address. Consequently, the `marketingWallet` address gradually accumulates a substantial amount of `BNB`. If the `marketingWallet` is an EOA (Externally Owned Account), the mishandling of its private key can have devastating consequences for the project as a whole. For the common deflationary token, the entire tokenomics model requires a certain level of liquidity to support. However, the current implementation transfers the swapped `BNB` to the `marketingWallet` without utilizing it for liquidity provisions. There are also no mechanisms within the contract to inject liquidity into the main pair liquidity pool when required. Consequently, the token may face the risks related to price instability and manipulation due to inadequate liquidity in the BENT-WBNB pool, thus leading to a potential price drop.
According to the following code snippet: ```solidity function includeInReward(address account) external onlyOwner { require(_isExcluded[account], "Account is not excluded"); for (uint256 i = 0; i < _excluded.length; i++) { if (_excluded[i] == account) { _excluded[i] = _excluded[_excluded.length - 1]; _tOwned[account] = 0; _isExcluded[account] = false; _excluded.pop(); break; } } } ``` Variable `_rOwned[account]` is not updated in the function `includeInReward()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The Rate was higher at the moment of the `excludeFromReward(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward.
| Address | Chain | Source code |
|---|---|---|
| 0x1e8a…d56a0x1e8af416823b1911c6b640a10b817b47f962d56a | Chain: BNB Chain | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us