Common Issues with Non-Standard ERC-20 Tokens on Etherscan

ERC-20 is a widely adopted standard for creating fungible tokens on the Ethereum blockchain. Adhering to this standard ensures compatibility and interoperability between different tokens, allowing for smooth integration with wallets, exchanges, and other decentralized applications (dApps).

However, deviations from the ERC-20 standard can lead to several issues, affecting both Etherscan's web interfaces and API results. In this article, we will explore two common issues related to non-standard ERC-20 token contracts.

Non-Standard Functions

Non-standard functions implemented in ERC-20 token contracts can cause problems on both Etherscan's web interfaces and API results.

1. Modified Functions

  • Function behavior
    Modifying the behavior of functions like the totalSupply can result in misleading values being displayed on token pages. This can lead to incorrect calculations and misrepresentation of the token's circulating supply.
Example of a modified totalSupply function behavior
  • Function names
    Modifying the function names such as names() instead of name() can affect how tokens are displayed on Etherscan.
ERC-20 standard implementation in OpenZeppelin's repo

2. Event Spoofing

Event spoofing refers to the manipulation of token transfer events emitted by the token contract. If the transfer event is spoofed, it can lead to discrepancies between the actual token transfers and the displayed information on ERC-20 Token Transfers tab in Address pages. This can create confusion and impact the transparency of token transactions.

For more information on how event spoofing is carried out, kindly read the article here.

3. Token Transfers Without Emitted Events

Event Logs are essential for block explorers like Etherscan, as they allow tracking of token transfers without the need to search through the entire blockchain for a single piece of historical data, which can be both costly and time-consuming.

Think of it as posting updates on a bulletin board for everyone to see. In this case, block explorers can readily access these token updates.

In the screenshot above, the token transfer history of the address 0x8c14...835F shows only 1 transfer event amounting 442,902,484,199.05802236 HOKK whereas the token balance of the address is shown as 463,838,878,509.887326641 HOKK.

This is due to the token contract implementing a reflection mechanism in which the token contract automatically distributes a portion of every transaction fee to all token holders. When a fee is incurred, a percentage of the fee is deducted from the transaction amount, and the remaining amount is transferred to the recipient. The deducted fee is then distributed proportionally to all token holders based on their share of the total token supply.

According to the Code Reader, no event is emitted for the reflection mechanism. Therefore, specific information related to the reflection mechanism cannot be tracked and displayed properly on the block explorer:

The token holdings dropdown menu on the address page may not accurately reflect the latest holdings amount because it depends on token transfer events emitted by the contract, unless the token contract has updated information. (Refer: How to update Token Information?)

Alternatively, if you want to check the current token balance of an address manually, you can navigate to the 'Read Contract' section of the token contract, enter the address in the balanceOf field, and click 'Query'.


Adhering to the ERC-20 standard is crucial for ensuring consistent and reliable token functionality within the Ethereum ecosystem. Deviating from the standard by implementing non-standard functions can result in issues as mentioned within this article.

Teck Yuan Lee
Teck Yuan Lee
Last updated: