ERC-20

What Is ERC-20?

ERC-20 is an Ethereum token standard that defines a common interface for fungible crypto assets created through smart contracts.

Fungible means that equal units of the same token are interchangeable under the token contract’s accounting rules.

For example, one whole unit of an ordinary ERC-20 token has the same contract-defined properties as another whole unit of that token.

The official ERC-20 specification defines functions for checking token supply and balances, transferring tokens, and authorizing third parties to spend tokens.

It also defines standardized events that allow wallets and applications to observe transfers and approval changes.

ERC-20 is a Final Ethereum Request for Comments standard and remains the main technical foundation for fungible tokens across Ethereum-compatible ecosystems.

The standard improves interoperability because wallets, smart contracts, blockchain explorers, custody systems, and other crypto applications can use the same basic methods for many different tokens.

ERC-20 does not determine a token’s price, supply policy, legal classification, utility, collateral backing, governance rights, or investment quality.

What Does ERC Mean?

ERC stands for Ethereum Request for Comments.

An ERC describes an application-level standard or convention that developers can implement in Ethereum smart contracts and related software.

The number 20 identifies the proposal that introduced this fungible-token interface.

It does not refer to the number of tokens, decimal places, supported networks, or contract functions.

ERC-20 is also frequently called EIP-20 because the document exists within the Ethereum Improvement Proposal process.

Why Was ERC-20 Created?

Before a shared fungible-token standard, each smart contract could expose different names and rules for balance checks, transfers, and delegated spending.

A wallet would need custom integration code for every token.

A decentralized application could not safely assume that two token contracts supported the same operations.

ERC-20 created a minimum shared interface that allows one application to interact with many fungible tokens.

This interoperability helped make token balances usable across payments, governance, lending, liquidity systems, vaults, games, rewards programs, and other crypto applications.

The standard deliberately remains limited so developers can add specialized behavior without changing its basic interface.

How ERC-20 Works

An ERC-20 token is controlled by a smart contract deployed on Ethereum or a compatible blockchain.

The contract records how many token units each address owns.

It also records the total token supply and any allowances that owners have granted to spenders.

When a valid transfer occurs, the contract reduces the sender’s balance and increases the recipient’s balance.

The contract emits a

event so external software can observe the movement.

When an owner approves a spender, the contract updates an allowance and emits an

event.

The blockchain’s nodes execute these contract rules and verify that every accepted state change is valid.

The token contract does not maintain a separate blockchain because it operates within the state and security model of its host network.

Core ERC-20 Functions

The required ERC-20 interface includes six main functions.

These functions are

, , , , , and .

The standard also describes the optional

, , and metadata functions.

Minting, burning, pausing, taxation, voting, freezing, and supply caps are not required by the core interface.

A token can add these features through custom logic or standardized extensions.

The totalSupply Function

The

function returns the number of token units currently included in the token’s reported supply.

The value is expressed in the token’s smallest internal unit.

It does not automatically reveal the maximum possible supply.

A contract may allow additional tokens to be minted later even when the current total supply is much lower than a stated maximum.

A token may also support burning, which can reduce the current total supply.

Users should review minting permissions and supply controls instead of using

as proof of permanent scarcity.

The balanceOf Function

The

function returns the token balance recorded for a specified address.

The result is expressed in the token’s smallest internal unit.

A displayed wallet balance is normally calculated by formatting this integer according to the token’s decimal setting.

The function reports only the balance within one token contract.

It does not include similarly named tokens created at other contract addresses or on other networks.

Some unusual tokens can change balances through rebasing or other accounting logic without emitting an ordinary transfer for each holder.

The transfer Function

The

function moves a specified amount from the caller’s balance to a recipient.

The caller must have enough tokens to complete the operation.

A successful transfer must emit a

event.

The ERC-20 specification requires a zero-value transfer to be treated as a normal transfer and to emit the event.

The function returns a Boolean success value under the standard.

Applications must not assume that a returned value of

can never occur.

Many modern implementations revert on failure instead of returning

, but integrations must account for the behavior of the specific token.

The approve Function

The

function allows a token owner to set how many tokens a spender may transfer from the owner’s balance.

The spender does not receive the tokens immediately.

Instead, the contract records an allowance that the spender can use later through

.

The approval applies to one owner, one spender, and one token contract.

An approval on one network or token contract does not automatically authorize spending elsewhere.

Users should treat approval transactions as financial permissions rather than harmless wallet connections.

The allowance Function

The

function reports how many tokens a spender is currently authorized to transfer from an owner.

The value can decrease when the spender uses

.

The owner can update the amount through another approval transaction.

Some implementations treat the maximum unsigned integer as an unlimited approval and may not reduce that value after each transfer.

An unlimited approval remains dangerous while the spender retains access and the owner has a token balance.

Users should review and revoke permissions that are no longer required.

The transferFrom Function

The

function allows an approved spender to transfer tokens from an owner to a recipient.

The spender must have sufficient allowance, and the owner must have sufficient balance.

A successful call normally reduces the available allowance unless the implementation treats it as unlimited.

The function must emit a

event for the token movement.

This delegated transfer model allows smart contracts to collect payments, accept deposits, lock collateral, or perform other approved actions.

The model also creates risk because a malicious or compromised spender can use the remaining allowance without asking the owner to approve every transfer.

ERC-20 Events

The ERC-20 standard defines the

and events.

Events are transaction logs that off-chain applications can index efficiently.

Wallets, analytics tools, accounting systems, and blockchain explorers use these logs to track token activity.

An event should always be interpreted together with the contract address that emitted it.

A malicious contract can use familiar event names without representing an authentic or valuable token.

The Transfer Event

The

event records the sender, recipient, and token amount.

Normal transfers use nonzero sender and recipient addresses.

Token creation is commonly represented by a transfer from the zero address to the recipient.

Token destruction is commonly represented by a transfer from the holder to the zero address.

The ERC-20 specification requires newly created tokens to trigger a

event from the zero address when the implementation creates supply.

An observed mint event does not prove that future minting is impossible.

The Approval Event

The

event records an owner, spender, and allowance value.

Applications can use it to follow changes in delegated spending authority.

An approval does not transfer tokens or change ownership by itself.

It enables the spender to use

within the permitted amount.

Revoking an allowance does not reverse token transfers that occurred while the permission was active.

ERC-20 Name and Symbol

The

and functions provide human-readable token information.

The name might describe the asset, while the symbol provides a shorter display label.

Both functions are optional in the original ERC-20 specification.

Names and symbols are not unique.

Anyone can deploy a token that copies the name and symbol of another asset.

Wallets and users should verify the complete contract address and blockchain network rather than relying on branding alone.

What Are ERC-20 Decimals?

The optional

function tells applications how to format the token’s smallest units for human-readable display.

A token with 18 decimals divides its internal integer amount by 10 to the power of 18 for standard display.

For example, an internal amount of 1,000,000 units represents one token when the token uses six decimals.

Decimals do not make the blockchain balance a floating-point number.

Smart contracts perform token accounting with integers.

The decimal value affects display and denomination rather than the underlying arithmetic model.

Eighteen decimals are common and are the default in the current OpenZeppelin ERC-20 implementation, but ERC-20 tokens can use other values.

ERC-20 Supply Models

ERC-20 does not prescribe how token supply must be created.

A fixed-supply token can mint its complete supply during deployment and expose no later minting function.

A capped token can permit minting until a contract-defined maximum is reached.

An uncapped token can allow an authorized account or protocol process to create additional units without a permanent maximum.

An algorithmic token can adjust supply according to programmed conditions.

A wrapped token can issue units when an underlying asset is deposited and burn units when that asset is withdrawn.

The official ERC-20 supply guide explains that supply logic must be added to the base implementation through an appropriate minting mechanism.

Minting ERC-20 Tokens

Minting creates new token units and increases the total supply.

The core ERC-20 interface does not define a public mint function or specify who may call it.

A token can restrict minting to an administrator, governance process, bridge, staking system, vault, or another contract-defined authority.

Unsafe minting permissions can dilute existing holders or break collateral assumptions.

Users should inspect whether minting is possible, who controls it, whether a cap exists, and whether the implementation can be upgraded.

A statement that a token has a fixed supply should be verified through deployed contract logic and privileged permissions.

Burning ERC-20 Tokens

Burning destroys token units and normally reduces the total supply.

The core standard does not require holders to have a public burn function.

An implementation may let holders burn their own tokens or let approved spenders burn tokens through an allowance.

Other systems burn tokens only during redemption, settlement, or protocol operations.

Sending tokens to an inaccessible address is not always the same as a contract-level burn because the reported total supply may remain unchanged.

Users should examine the token’s actual burn logic before interpreting supply data.

ERC-20 Approvals and the Allowance Race Condition

Changing an existing nonzero allowance directly to another nonzero amount can create a transaction-ordering risk.

A spender may use the old allowance before the owner’s replacement approval is confirmed and then receive the new allowance afterward.

The original ERC-20 specification notes that user interfaces should first set the allowance to zero before assigning a different nonzero value.

The token contract itself should not require this sequence because doing so would reduce compatibility with older applications.

Reducing or increasing an allowance through carefully designed helper functions can improve usability, but support varies among implementations.

Users should avoid leaving larger allowances than an application reasonably needs.

Unlimited Token Approvals

An unlimited approval usually sets the allowance to the maximum value supported by a 256-bit unsigned integer.

This approach reduces the need to submit a new approval before every interaction.

It also gives the spender continuing authority over current and future balances of that token.

If the spender contract is exploited, upgraded maliciously, or controlled by a compromised administrator, the allowance may be used to remove the holder’s tokens.

Convenience should be weighed against the amount and duration of the permission.

A limited allowance can reduce the maximum loss from one compromised spender.

What Is ERC-2612 Permit?

ERC-2612 is an extension that allows an ERC-20 owner to create an allowance through a signed message.

The signed permission can be submitted on-chain by another account or smart contract.

This can combine an approval and an application action into one user flow.

The official ERC-2612 permit specification adds

, , and to ERC-20.

Each successful permit consumes a nonce so the same signature cannot be reused normally.

A deadline limits how long the signature remains valid.

Permit support is optional and is not part of the original core ERC-20 interface.

Permit Signature Risks

A permit signature can authorize token spending even though signing it does not immediately send an on-chain transaction from the owner.

Phishing websites may present a permit as a login, verification, or harmless gasless message.

The spender can submit a valid signed permit later and use the resulting allowance before its deadline.

Users should inspect the token, spender, amount, network, nonce, and expiration before signing.

A signature request should not be considered safe merely because the wallet reports that no gas payment is required.

Contract wallets may require additional signature-validation support beyond the basic externally owned account pattern.

Does ERC-20 Support Automatic Receiver Callbacks?

The core ERC-20 transfer functions do not require a receiving smart contract to acknowledge the tokens.

A transfer can therefore succeed even when the recipient contract has no function for recording or returning the tokens.

This can leave assets trapped in incompatible contracts.

ERC-20 also does not automatically call recipient code after an ordinary transfer.

The ERC-1363 extension adds transfer-and-call and approve-and-call operations for applications that need callback behavior.

Callback-enabled extensions add external calls and must be reviewed for reentrancy and receiver-security risks.

SafeERC20 and Nonstandard Tokens

The ERC-20 specification says that callers must handle a returned value of

.

In practice, some older or unusual token contracts do not return a Boolean value even when the transfer succeeds.

Other implementations revert on failure rather than returning

.

A direct interface call that assumes one behavior can fail or misinterpret the result.

The current SafeERC20 utility wraps token operations and handles both false-returning tokens and certain tokens that return no value.

A wrapper improves compatibility but cannot make a malicious token economically safe.

Fee-on-Transfer Tokens

A fee-on-transfer token deducts a charge during token movement.

The recipient receives less than the amount requested by the sender or calling contract.

A protocol that credits the requested amount instead of measuring the amount actually received can become undercollateralized.

Applications should compare token balances before and after a transfer when they support this token behavior.

Fee rules may also change when the contract is upgradeable or controlled by an administrator.

Standard ERC-20 function names do not guarantee a fixed transfer result.

Rebasing ERC-20 Tokens

A rebasing token changes account balances according to a contract-defined adjustment process.

The balance displayed by

can increase or decrease without an ordinary transfer initiated by the holder.

Positive rebases expand displayed balances, while negative rebases reduce them.

Some systems use internal shares and calculate visible balances through an exchange rate.

Applications that assume balances change only through transfers may account for rebasing tokens incorrectly.

Users should understand whether a token represents a fixed unit balance or a changing proportional claim.

Wrapped ERC-20 Tokens

A wrapped ERC-20 token represents another asset through a smart contract or custody arrangement.

Users may deposit an underlying asset and receive corresponding ERC-20 units.

Redemption normally burns or returns the wrapped units and releases the underlying asset.

The wrapper’s value depends on the availability and integrity of its backing mechanism.

Smart contract exploits, custody failures, bridge failures, frozen collateral, or incorrect accounting can break the expected relationship.

ERC-20 compliance proves only interface compatibility and not the existence of sufficient backing.

ERC-20 Governance Tokens

An ERC-20 token can be extended to represent voting power in an on-chain governance system.

Voting may depend on current balances, delegated balances, or historical balance checkpoints.

The current ERC-20 implementation library includes an ERC-20 voting extension for delegation and historical vote queries.

Holding governance tokens does not necessarily activate voting power automatically because some systems require delegation.

Token voting can also be influenced by concentrated ownership, borrowed assets, low turnout, and administrator permissions.

The core ERC-20 standard does not define governance rules.

ERC-20 Vault Shares

ERC-20 tokens can represent shares in a tokenized vault.

Each share represents a proportional claim on assets managed by the vault rather than a fixed unit of the underlying token.

The ERC-4626 tokenized vault standard extends ERC-20 with standardized deposit, withdrawal, mint, redemption, and conversion functions.

Vault shares can increase or decrease in underlying value according to strategy performance, fees, losses, and accounting rules.

ERC-20 compatibility alone does not explain what backs a share token or how it can be redeemed.

ERC-20 Error Messages

The original ERC-20 standard predates Solidity custom errors and does not define a standardized set of failure messages.

Different tokens may return

, revert with a text message, revert with a custom error, or behave incorrectly.

The Final ERC-6093 standard defines structured custom errors for common token failures.

Examples include insufficient balance, invalid sender, invalid receiver, insufficient allowance, invalid approver, and invalid spender errors.

Standardized errors can help wallets and applications explain failures more consistently.

ERC-6093 does not change the core ERC-20 interface or require every existing token to adopt its errors.

Does ERC-20 Use ERC-165?

The original ERC-20 standard does not require ERC-165 interface detection.

An application cannot assume that calling

will identify every ERC-20 token.

Software commonly identifies compatibility through the contract ABI, verified source code, known token lists, registry data, and direct function testing.

The existence of familiar function selectors does not prove complete standards compliance.

A malicious contract can imitate parts of the interface while applying harmful or unexpected behavior.

ERC-20 vs. Native ETH

ETH is Ethereum’s native crypto asset and is not itself an ERC-20 token.

Ethereum accounts can send native ETH through protocol-level value transfers.

ERC-20 balances exist inside individual smart contracts.

Paying Ethereum transaction fees requires ETH even when the transferred asset is an ERC-20 token, unless a separate system sponsors or abstracts the fee.

An ERC-20 representation of ETH can be created for applications that require the token interface, but that wrapped asset remains different from native ETH.

ERC-20 vs. ERC-721

ERC-20 represents fungible balances, while ERC-721 represents individually identified non-fungible tokens.

An ERC-20 account owns a quantity of interchangeable units.

An ERC-721 account owns distinct token IDs.

ERC-20 commonly uses decimal formatting, while one ERC-721 token is normally transferred as a complete unique unit.

ERC-721 also includes safe-transfer receiver checks that are absent from the core ERC-20 standard.

ERC-20 vs. ERC-1155

ERC-20 manages one fungible token type per contract interface.

ERC-1155 allows one contract to manage many token IDs with separate balances.

Those ERC-1155 token IDs can represent fungible, semi-fungible, or unique assets.

ERC-1155 also defines batch transfer operations and receiver callbacks.

The best standard depends on whether a project needs one fungible asset or many asset types managed by one contract.

Common ERC-20 Use Cases

Stable-value tokens can use ERC-20 to represent transferable units connected with a reserve, collateral system, or algorithmic mechanism.

Governance systems can use ERC-20 balances or delegated units as voting power.

Blockchain games can use ERC-20 tokens for interchangeable currencies, rewards, or resources.

Vaults and staking systems can issue ERC-20 receipt tokens representing deposited positions.

Wrapped assets can use ERC-20 to represent claims on assets held elsewhere.

Projects can also use the standard for loyalty points, access credits, payment units, or tokenized financial claims.

The interface does not determine whether a particular use is lawful, fully backed, decentralized, or economically sustainable.

ERC-20 Smart Contract Risks

An ERC-20 implementation can contain errors in transfer, allowance, minting, burning, taxation, or access-control logic.

A privileged administrator may be able to pause transfers, freeze balances, block addresses, mint supply, change fees, or upgrade the contract.

A proxy upgrade can alter token behavior after holders acquire it.

External calls in customized token logic can create reentrancy or denial-of-service risks.

Incorrect integrations can lose funds even when the token itself behaves according to its code.

Standards compliance improves interoperability but does not replace audits, testing, source review, and permission analysis.

Token Approval Phishing

Approval phishing attempts to persuade a user to authorize a malicious spender.

The interface may describe the action as verification, connection, reward eligibility, or account recovery.

Once the approval is confirmed, the spender can use

to take tokens within the allowance.

A permit signature can create similar authority without an immediate on-chain approval transaction from the victim.

Users should verify the token contract, spender address, allowance amount, network, and purpose of every approval or permit.

A recovery phrase or private key should never be entered into an application to cancel an ERC-20 allowance.

Token Transfer Scams

Scammers can send unknown ERC-20 tokens to a wallet without the owner’s permission.

The token name, symbol, or metadata may contain a misleading website or claim.

Interacting with the advertised site can lead to malicious approvals or signatures.

Attackers can also create addresses that visually resemble addresses from a user’s transaction history.

Users should copy verified addresses from trusted records rather than selecting a destination based only on matching beginning and ending characters.

Receiving an unknown token does not require the wallet owner to interact with it.

How Developers Should Implement ERC-20

Developers should generally begin with a reviewed and actively maintained implementation.

The current ERC-20 development guide provides core contracts and extensions for permits, caps, burns, pausing, voting, wrapping, vaults, and other functions.

Supply creation should be explicit and protected by suitable access control.

Transfer customizations should preserve balance, supply, event, and allowance invariants.

Developers should test zero-value transfers, maximum values, insufficient balances, insufficient allowances, minting, burning, approvals, and transfers involving unusual addresses.

Integrations should also be tested against false-returning, no-return, fee-on-transfer, rebasing, paused, and callback-enabled tokens when those assets are supported.

How Users Can Evaluate an ERC-20 Token

The first step is to verify the blockchain network and complete token contract address.

The second step is to inspect current supply, maximum supply claims, and minting authority.

The third step is to review administrator, pause, freeze, blocklist, fee, and upgrade permissions.

The fourth step is to determine whether the token is backed by another asset and how redemption works.

The fifth step is to examine transfer fees, rebasing behavior, restrictions, and unusual wallet effects.

The sixth step is to review audits, verified source code, and incident history without treating any audit as a guarantee.

The seventh step is to check holder concentration, available liquidity, and the conditions under which liquidity can disappear.

The eighth step is to understand the actual source of demand or yield rather than relying on token branding.

The ninth step is to inspect approvals before and after using unfamiliar smart contracts.

The tenth step is to test a new token or contract with a limited amount before exposing significant funds.

Example of an ERC-20 Transfer

Suppose Alice owns 500 units of an ERC-20 token and wants to send 75 units to Bob.

Alice’s wallet confirms the correct blockchain, token contract, recipient address, amount, and transaction fee.

The wallet submits a transaction calling the token’s

function.

The token contract verifies that Alice has at least 75 units.

It decreases Alice’s balance to 425 units and increases Bob’s balance by 75 units.

The contract emits a

event containing Alice’s address, Bob’s address, and the transferred amount.

Ethereum validators include the transaction in a block, and nodes independently verify the resulting state change.

After confirmation, wallets and applications can read the updated balances from the token contract.

Example of an ERC-20 Approval

Suppose Alice wants a vault contract to deposit 100 units of an ERC-20 token on her behalf.

Alice first verifies the vault contract address and the token it will spend.

She calls

and grants the vault an allowance of 100 units.

The token contract records the allowance and emits an

event.

Alice then calls the vault’s deposit function.

The vault uses

to move 100 units from Alice into the vault.

The token contract checks Alice’s balance and the vault’s allowance before completing the transfer.

After the transfer, the used allowance is normally reduced according to the token implementation.

Common ERC-20 Mistakes

One common mistake is identifying a token only by its name or symbol.

Another mistake is assuming that every ERC-20 token uses 18 decimals.

A third mistake is granting unlimited approval to an untrusted contract.

A fourth mistake is believing that disconnecting a wallet revokes token allowances.

A fifth mistake is ignoring the Boolean result or nonstandard behavior of token transfers.

A sixth mistake is crediting a fee-on-transfer deposit by its requested amount instead of its received amount.

A seventh mistake is treating

as proof of a permanent supply cap.

An eighth mistake is assuming that ERC-20 compliance proves collateral backing or redemption value.

A ninth mistake is signing a permit without checking its spender, amount, and deadline.

A tenth mistake is treating an audit or verified source code as a guarantee that the token cannot fail.

FAQ

What does ERC-20 mean?

ERC-20 is the Ethereum standard that defines common functions and events for fungible smart contract tokens.

Is ERC-20 a cryptocurrency?

ERC-20 is a technical standard, while an individual contract implementing the standard can create a cryptocurrency token.

Is ERC-20 the same as Ethereum?

No, Ethereum is the blockchain network, while ERC-20 is a smart contract interface used for tokens operating on that network.

Is ETH an ERC-20 token?

No, ETH is Ethereum’s native asset and does not itself use the ERC-20 contract interface.

Are ERC-20 tokens fungible?

Yes, equal units of one ordinary ERC-20 token are interchangeable under the contract’s accounting rules.

What are the six core ERC-20 functions?

They are

, , , , , and .

What events does ERC-20 define?

The standard defines the

and events.

Are name, symbol, and decimals required?

No, all three metadata functions are optional in the original ERC-20 specification.

Do all ERC-20 tokens use 18 decimals?

No, 18 is common, but each token can use a different decimal value.

What does an ERC-20 approval do?

It gives a spender permission to transfer tokens from an owner within a specified allowance.

What is transferFrom used for?

It allows an authorized spender to transfer tokens from an owner to a recipient.

What is an unlimited ERC-20 approval?

It is an allowance set to an extremely large maximum value so the spender can continue transferring tokens without repeated approvals.

Does disconnecting a wallet revoke approvals?

No, on-chain allowances remain active until they are changed through the token contract or otherwise lose effect.

What is an ERC-20 permit?

A permit is an optional ERC-2612 signed message that creates or changes an allowance without requiring the owner to submit the approval transaction directly.

Can ERC-20 tokens be minted?

Yes, when the implementation includes a minting mechanism and an authorized party or protocol condition can use it.

Can ERC-20 tokens be burned?

Yes, when the implementation includes contract logic for destroying token units.

Does ERC-20 require a fixed supply?

No, supply policy is determined by the individual token implementation.

Can ERC-20 transfers charge fees?

Yes, customized tokens can deduct transfer fees even though this behavior is not required by the core standard.

Can an ERC-20 balance change without a transfer?

Yes, rebasing and other customized accounting models can change reported balances without ordinary holder transfers.

Can ERC-20 tokens become stuck in a contract?

Yes, the core transfer function does not require receiving contracts to confirm that they can handle or return the tokens.

Does ERC-20 support ERC-165 interface detection?

No, the original ERC-20 specification does not require ERC-165.

Does ERC-20 guarantee that a token is backed?

No, the standard does not verify reserves, collateral, redemption rights, or solvency.

Does ERC-20 compliance make a token safe?

No, a compatible token can still have dangerous permissions, flawed code, weak backing, poor liquidity, or malicious operators.

How can users identify the correct ERC-20 token?

Users should verify the blockchain network and full contract address through an authoritative source.

What is the main benefit of ERC-20?

Its main benefit is interoperability through a shared interface that many crypto wallets and smart contracts understand.

Conclusion

ERC-20 is Ethereum’s foundational standard for fungible smart contract tokens.

It defines common methods for checking supply and balances, transferring tokens, and granting delegated spending authority.

Its

and events allow crypto applications to monitor token movements and permissions.

Optional metadata functions provide a token name, symbol, and decimal setting, but these values do not prove authenticity.

The standard does not determine how supply is created, whether tokens are backed, who controls administration, or whether the asset has financial value.

Extensions can add signed permits, voting, pausing, caps, callbacks, vault functionality, standardized errors, and other features.

Approvals remain one of the largest user risks because a malicious spender can use an active allowance through

.

Developers must account for false return values, no-return tokens, transfer fees, rebasing, callbacks, unusual decimals, and customized restrictions.

Users should verify contract addresses, review permissions, understand minting and upgrade authority, and investigate the token’s backing and economic design.

ERC-20 compatibility creates a shared technical language, but it does not replace smart contract security, careful transaction review, or independent financial research.