For example, a malicious user could deploy a simple ERC20 contract and "airdrop" tokens to a group of users, creating a healthy-looking liquidity pool on an automated market maker, waiting for users to buy or sell tokens based on false propaganda, believing this Tokens are part of a known developer/entity.

break down

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

For example, if a contract deployer sends a token, we can have some/all block explorers show a different address to the end user (in some views). The assumptions are as follows;

Contract deployers are malicious and want to create some hype for their tokens. The token has some liquidity in AMM (like Uniswap) for users to buy/sell, and the main liquidity provider positions belong to the team behind the token. Many users know the sender, not some random address. It's not just an ERC20 problem...Tainted data can be inserted into any token standard event like NFT (ERC721, ERC1155) to confuse users and potential investors into thinking the project has a specific stakeholder/ Influencers, when in fact they are not.

This issue isn't "new", but we wrote this article to highlight what's going on and what users should do before "copying" a "legitimate-looking" item.

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

proof of concept

We're going to deploy a proof-of-concept contract that uses an older version of Solidity, while also proving that it has no issues with any Solidity version or anything in Ethereum, it's a trust issue from an off-chain application trust contract. In general, inherited trust in events is "correct" and is a way for a contract to provide available data to off-chain programs 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 "OpenSea: Wallet" on popular block explorers, provided we (the one who created the contract) Send tokens.

What it does is that when the block explorer indexes the event, it sees from the Transfer event that the address 0x5b32…1073 sent the token instead of the actual originator 0x11b6…04C9, which could cause the method to be badly exploited by actors to induce users to believe that;

A popular figure has a vested interest in the token A popular figure is "unloading" a lot of coins The token is legal because on the block explorer it shows a known entity "interacting" with the token contract Let's call transfer() from the contract deployer address and see what the block explorer has indexed. We just moved coins from my address (0x11b6...04C9) to a destination address (0x4bbe...1520).