Beware of scammers using Etherscan

Blockchain indexing services rely on contract events to help archive data and provide us with transaction records in a beautiful user interface, which is often called a "block explorer" such as Etherscan. But malicious contracts can appear to be "normal" and pollute these events, thereby deceiving block explorers and providing unsuspecting users with misleading information about the origin of tokens.

For example, a malicious user could deploy a simple ERC20 contract and “airdrop” tokens to a group of users, create a seemingly healthy liquidity pool on an automated market maker, and wait for users to buy or sell tokens based on false propaganda, believing that the tokens are part of a known developer/entity.

break down

An ERC20 token (which is a universal standard for token interfaces) is a collection of contract properties, functions, inputs, outputs, and events. As long as our contract has the correct functional characteristics, we can use custom logic in these functions - even functions that provide incorrect data.

For example, we could have some/all block explorers display a different address to end users (in certain views) if the contract deployer sends a token. Assume the following;

• The contract deployer has malicious intent and wants to create some hype for their token.

• The token has some liquidity in an AMM (like Uniswap) for users to buy/sell, and the main liquidity provider positions belong to the team behind the token.

• The sender is known to many users, not just some random address.

This isn’t just an ERC20 issue…tainted data can be inserted into any token standard event, such as NFTs (ERC721, ERC1155), to confuse users and potential investors into thinking the project has specific parties of interest/influence when in fact it does not.

This issue is not "new", but we wrote this article to highlight what is happening and what users should do before "copying" a "legitimate-looking" project.

When a block explorer sees an event emitted by a transaction, they record it in their off-chain database and relate it to other data so they can build a nice graph of transaction relationships to show to the end user in their UI.

Proof of Concept

We will deploy a proof-of-concept contract using an older version of Solidity, but also prove that it works with any version of Solidity or anything in Ethereum, it is a matter of trust from the off-chain application trusting the contract. Generally speaking, the inherited trust in events is "correct", it is a way for a contract to make available data to the off-chain program for indexing.

In the contract above (located at 0x3afe99bd92b1aed3237196b26743681766d4940e), we modified the logic to change the sender address in the Transfer event to the address marked as “OpenSea:Wallet” on popular block explorers, provided that we (the one who created the contract) are sending tokens.

What it does is that when the block explorer indexes that event, it sees from the Transfer event that the address 0x5b32…1073 sent the tokens, instead of the actual sender 0x11b6…04C9, which could lead to this method being exploited by bad actors to trick users into thinking;

• A popular figure has a vested interest in the token

• A popular figure is “unloading” a large amount of tokens

• The token is legitimate because on the block explorer it shows known entities “interacting” with the token contract

Let’s call transfer() from the contract deployer address and see what the block explorer indexes. We are just moving tokens from my address (0x11b6…04C9) to a destination address (0x4bbe…1520).

The “OpenSea: Wallet” ERC20 activity view shows that it appears to have sent a token called OpenSeaRevenueShare to the destination.

The transaction indicates (in “tokenTransferred”) that “OpenSea: Wallet” sent tokens to the destination address.

The destination address shows that “OpenSea: Wallet” transferred 10 tokens to them.

Looking for Something?

Most of these malicious contracts that exploit users are not "verified", and since we only have access to the bytecode on the block explorer, if the event is tainted with bad data, it is difficult for users to verify it based on certain conditions, just like our proof of concept. If the contract is not verified, such as we cannot see the Solidity/Vyper/... code and are only exposed to the bytecode, then we should take precautions before interacting with the contract.

If a token is “airdropped” to us or another entity, we should be cautious, especially when trying to liquidate tokens on a DEX, as there have been incidents in the past where artificial price creation methods have been used to steal tokens from DEXs.

A quick way is to check if the event parameters match the transaction sender, this is not foolproof because the airdropper has multiple sender contracts. For example, if the transaction "From" field does not match the event, please proceed with caution.

The method of polluting events with bad data is working on mainnet. A known issue. For example, if we run the following query on Google BigQuery, we can understand what is happening with the contracts that are emitting events to trick indexers into thinking that Vitalik Buterin is spending their tokens.

example

ElonPlaid (0x907f3040e13bd57f3b00f89bb8ee19424a95b065)

On the constructor emits a Transfer() event tainted with Vitalik Buterins address for the entire token supply.

When a transaction is started using a token, a Transfer() event is emitted which is tainted with Vitalik Buterin’s address.

• Contract creator provides liquidity to DEX (4ETH value)

• After three days, 6 ETH of liquidity is removed, with a profit of 2 ETH

KenshaInu (0x3a7eaa257181719965f8ebe64bb7c13ffbbca36b)

On the constructor emits a Transfer() event tainted with Vitalik Buterins address for the entire token supply.

• Contract creator provides liquidity to DEX (5ETH value)

• Three days later, 6.9 ETH of liquidity was withdrawn, and 1.9 ETH of profit was obtained

IronDoge (0 xf6072df56114e1a1c76fe04fb310d468c9ba8c38)

On the constructor emits a Transfer() event tainted with Vitalik Buterins address for the entire token supply.

• Contract creator provides liquidity to DEX (4ETH value)

• One day later, 5.8 ETH of liquidity was removed, making the project a profit of 1.8 ETH

These are just three of many examples of bad actors taking advantage of tainted events to defraud users, and their targets are not only Vitalik Buterin’s known addresses.

Summarize

While block explorers are extremely useful in visualizing blockchain data, their logic can be abused to display misleading/incorrect data. The old blockchain adage of “don’t trust, verify” seems appropriate, especially when we all trust block explorers to provide absolutely accurate data without considering how they interpret the data.

This is a known and potentially difficult problem to solve, and I hope this post helps people be less FOMO and more careful before “copying” a project because it makes it look like someone is invested when they aren’t.