ERC-20 defines a common interface for tokens whose units are interchangeable within one token contract. It specifies balance and supply queries, transfer functions, delegated spending allowances, and events. Shared method names make it possible for wallets and applications to integrate many tokens through similar calls. Ethereum's native ETH is not itself an ERC-20 token; wrapped ETH is a contract-based representation. A familiar interface therefore describes interoperability, not the origin or economic quality of the underlying asset.

A direct transfer moves tokens from the caller's balance. An approval instead authorizes a specified spender to transfer tokens later, up to an allowance, using the delegated transfer flow. For example, approving a contract to spend fifty units does not by itself send fifty units to that contract. The distinction matters when reading wallet prompts and investigating unexplained transfers. Review the token contract, spender address, authorized amount, and subsequent transfer events rather than assuming every signed token interaction is a one-time payment.

Token contracts can add minting powers, transfer restrictions, upgrade mechanisms, or other behavior around the standard interface. Display names and symbols can be copied, and decimals affect presentation rather than creating additional economic value. Integrations must inspect actual contract behavior and handle failure conditions appropriately. A token appearing correctly in a wallet proves neither reserve backing nor the absence of administrative control.

For research, the network and contract address are stronger identifiers than a ticker, and deployed code is stronger evidence than branding alone.