Glow Token V2

CertiK1 address on BNB Chain

CertiK reviewed Glow Token V2 on 3 Aug 2022: 29 findings, 1 critical; 8 marked fixed, 7 acknowledged, 14 open.

1 open critical finding
Open the reportOpen Glow Token V2’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings29

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical100
High045
Medium031
Low1302
CriticalPotential Out-of-Gas ExceptionOpen

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.

Low`_nonce` Never ChangedOpen

The variable `_nonce` is used in function `_random` to make a random number. However, it is always the initial zero and never changed.

LowAddress Type Could Be Indexed In EventsOpen

It is recommended to add `indexed` keyword for parameters in events, which makes it easier for users to navigate event logs.

LowCheck Effect Interaction Pattern ViolatedOpen

The order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern.

LowMiscalculation of Max HoldingOpen

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.

LowMissing Approval OperationOpen

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.

LowMissing Error MessagesOpen

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.

LowMissing Event for `address(this)`Open

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.

LowMissing Input ValidationOpen

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.

LowPotential Sandwich AttacksOpen

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()

Show 4 more
LowThird Party DependenciesOpen

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.

LowUnlocked Compiler VersionOpen

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.

LowUnnecessary EventOpen

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.

LowUpdate AMM MistakenlyOpen

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); } ```

Contracts in scope1

AddressChainSource code
0xef3725d9e4b9d758483c86be917ab7321dc2830cChain: BNB ChainSource code: Verified source

Part of Glow Token V2’s security record

Glow Token V2
Audits1 audit by 1 firmLast audit Aug 2022, by CertiK.
Critical findings1 open critical findingReported in “Glow Token V2” by CertiK, Aug 2022. Not marked fixed in that report.
Open Glow Token V2’s security record

Security firm

CertiK

1,044 projects reviewed · 1,375 reports · latest May 2025

See CertiK’s audits

Something 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