Tokens are not a native feature of most networks — they are contracts implementing an agreed set of functions, and the agreement is what makes wallets and exchanges able to handle them.
What a standard is
A specification of function names, parameters and events that other software can rely on.
Which is a social convention enforced by nothing except the fact that non-compliant tokens do not work with existing tools.
The contract holds a mapping of addresses to balances, and transferring updates that mapping.
Where balances live
In the token contract, not in your wallet.
Which is why a wallet must be told which token contracts to display — it cannot discover them all.
An address holding a token it does not display still holds it, and the balance is readable from the contract.
The approval pattern
To let a contract move your tokens, you grant an allowance.
Which is a separate transaction and persists until changed.
Unlimited approvals are common for convenience and represent a standing permission that outlives the interaction.
Revoking unused approvals is a specific maintenance task that most users never perform.
Non-fungible standards
Each item has a unique identifier with its own owner record.
Which is the whole difference — a mapping from identifier to owner rather than from address to quantity.
Metadata, including images, is generally stored elsewhere with the contract holding a reference.
Where the artwork actually is
Frequently on a web server or on a content-addressed network.
Which means the token references content that may or may not persist.
Content addressing guarantees that the data matches the reference and does not guarantee that anyone is still storing it.
Fully on-chain approaches exist and are expensive, which is why they are uncommon.
Multi-token standards
Designs handling both fungible and non-fungible items in one contract with batch operations.
Which is efficient for applications issuing many item types.
Non-standard behaviour
Some tokens deviate — taking fees on transfer, returning no value where one is expected, or having pausable transfers.
Which breaks integrations that assumed standard behaviour, and has caused real incidents.
Reading the contract, or a reliable summary of it, is the only way to know what a specific token actually does.
This is technical description and not a recommendation regarding any token.
Permit-style approvals
Extensions allowing approval via signature rather than a separate transaction.
Which removes a transaction and its cost from the user flow.
It also means a signature alone can grant spending permission, which changes what a signing request implies.
Signature phishing
Requests to sign messages that grant permissions or authorise transfers.
Which appears harmless because no transaction is submitted at the time.
This has become one of the more common loss mechanisms, and reading what is being signed is the only defence.
Royalty enforcement
Creator fees on secondary sales are generally a marketplace convention rather than a protocol guarantee.
Which is why they became optional when marketplaces competed on fees.
Contract-level enforcement mechanisms exist and restrict where tokens can be traded.
Burning and supply
Sending to an unspendable address removes tokens from circulation without changing the recorded total in some implementations.
Which is why circulating supply figures require care about what is counted.
Contracts with mint functions can increase supply, and whether that function still has an owner is checkable.
Reading a contract
Verified source, presence of mint or pause functions, ownership status and transfer logic.
Which takes a few minutes on an explorer and tells you more than most written descriptions.
Airdrops and unsolicited tokens
Anyone can send tokens to any address, so appearing in a wallet means nothing about legitimacy.
Which is used to lure people into interacting with malicious contracts.
Interacting with an unexpected token is the risk, not holding it, and ignoring it is generally the correct response.
Address poisoning
Sending zero-value transactions from addresses resembling ones you have used, hoping you copy the wrong one from history.
Which is a documented and effective attack, and verifying full addresses defeats it.
Wrapped native assets
Native currency is not itself a token, so a wrapped version exists to make it conform to the standard.
Which is why interfaces sometimes require wrapping before a trade.
The wrapped version is redeemable one-for-one through the contract.
Reading before interacting
Contract address from an official source, verified code, and a look at the functions.
Which is a few minutes and prevents interaction with impostor contracts sharing a name.
Metadata permanence
Where images and attributes are hosted determines whether they persist.
Which has already resulted in collections whose artwork no longer resolves.
Checking whether metadata is content-addressed and pinned is the practical question.
Closing
A token is a contract, and reading it is the only reliable way to know what it does.
Standards evolution
Newer standards address known weaknesses in earlier ones, including transfer callbacks and approval expiry.
Which improves safety and fragments compatibility until adoption is broad.
Most deployed value remains in the original standards for this reason.