CertiK reviewed Glow Token V2 on 3 Aug 2022: 29 findings, 1 critical; 8 marked fixed, 7 acknowledged, 14 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 | 1 | 0 | 0 |
| High | 0 | 4 | 5 |
| Medium | 0 | 3 | 1 |
| Low | 13 | 0 | 2 |
In the function `_processRewards`, the gas may be insufficient in the last iteration of the while-loop, which will lead to the reversion of EVM. The function `_transfer` calls the function `_processRewards` when selling, so it may cause the sell transaction can not be executed successfully.
The variable `_nonce` is used in function `_random` to make a random number. However, it is always the initial zero and never changed.
It is recommended to add `indexed` keyword for parameters in events, which makes it easier for users to navigate event logs.
The order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern.
In function `_buyTokens`, the transaction may be charged fees, so the max holding of receiver should be `_balances[recipient] + amount - tokenTax`. The fees should not be calculated in the max holding.
In function `_addLiquidity` and `_swapTokensForBNB`, the `_pancakeRouter` transfers token without approval. Although the `_pancakeRouter` is approved with the max allowance in the constructor, the allowance may be decrease to an insufficient amount over time. Besides, if the router has been changed, there will no allowance for the new router, which will cause reversion of transaction.
The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller. But there are a lot of `require`s in the code that do not have error messages.
In the function `_transferIncluded`, the `newAmount` is sent to `recipient` and the `tokenTax` is sent to `address(this)`. So only emit for `recipient` is not enough.
There are many functions in the contract which do not check for the given input values, such as zero address validation, BEP20 token address validation.
A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - _pancakeRouter.swapExactETHForTokensSupportingFeeOnTransferTokens() - _pancakeRouter.addLiquidityETH() - _pancakeRouter.removeLiquidityETHSupportingFeeOnTransferTokens() - _pancakeRouter.swapExactTokensForETHSupportingFeeOnTransferTokens()
The contract is serving as the underlying entity to interact with third party protocols. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.
The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.
In function `transferFrom`, the event `Transfer` is unnecessary and emitted mistakenly. The balance changes of sender and recipient have already been emitted event in function `_transfer`, so there is no need to emit again. Besides, the recipient does not receive the total amount. The tax is for contract address.
Only when `enabled` is true, `_excludeAccountFromRewards(AMM)` is needed. In this way, the EVM will revert transaction if `enabled` is false. Besides, it is better to exclude the AMM account from lottery as well. ```solidity function ownerUpdateAMM(address AMM,bool enabled) public onlyOwner { _automatedMarketMakers[AMM]=enabled; _excludeAccountFromRewards(AMM); emit OwnerUpdateAMM(AMM,enabled); } ```
| Address | Chain | Source code |
|---|---|---|
| 0xef37…830c0xef3725d9e4b9d758483c86be917ab7321dc2830c | 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