Short answer: a coin is the native asset of a blockchain, while a token is issued and managed on an existing blockchain through a smart contract, token program, or comparable protocol mechanism. Bitcoin is native to the Bitcoin network, and ETH is native to Ethereum. An ERC-20 asset, by contrast, is represented by a contract on Ethereum. This distinction is technically useful, but project documentation and trading platforms do not always use the words consistently.
This analysis addresses technical classification and the practical consequences for transfers. It does not assess whether an asset is a good investment, predict its price, or determine its legal and tax treatment in a particular country.
How the Claims Were Checked
The evidence hierarchy gives priority to protocol specifications, official blockchain documentation, issuer documentation, and blockchain explorers where an on-chain identifier must be verified. General descriptions from price aggregators, promotional articles, and unsourced asset lists are not sufficient to establish whether an asset is native or contract-issued.
Source freshness matters most for supported networks, contract addresses, fee assets, token controls, and service availability. Stable protocol history can rely on foundational documents, while live network and issuer information should be checked again immediately before a transaction. If an official page provides no publication or update date, it is treated as live but undated documentation rather than as permanently valid evidence.
- Confirmed fact: directly supported by an applicable primary source.
- Condition-dependent conclusion: correct only for a specified network, implementation, wallet, or transaction method.
- Assessment: a practical interpretation derived from confirmed technical facts.
- Unknown: not safely determinable without current asset, network, or platform data.
No market-price calculation, return estimate, or numerical confidence score is used in this analysis.
The Technical Difference Between a Coin and a Token
A coin belongs to the base protocol
A native coin is recorded according to the blockchain’s core accounting rules rather than by a separately deployed token contract. It normally has a protocol-level role such as paying transaction fees, rewarding network participants, or participating in staking and network security.
Bitcoin’s foundational paper describes a peer-to-peer network that records the history of electronic transactions through proof of work. BTC is therefore the native asset accounted for by that network, not a token contract running on Bitcoin. [1]
On Ethereum, accounts have a native ETH balance and can also hold tokens. Ethereum’s documentation distinguishes externally controlled accounts from contract accounts and explains that both can receive ETH and tokens, while contract accounts are controlled by deployed code. [2]
A token depends on a host network
A token uses the infrastructure of a blockchain that already exists. Its balances and transfer rules may be implemented by a smart contract, a shared token program, or another asset-issuance framework. The host blockchain processes and finalizes the transaction, while the token implementation defines asset-specific behavior.
ERC-20 is a clear example. The standard defines an interface for tokens implemented within Ethereum smart contracts, including transfer, approval, supply, and balance functions. It does not create an independent blockchain for each ERC-20 asset. [3]
Solana uses a different architecture but preserves the same basic distinction: SOL is the network’s native currency, while other digital assets are created and managed through token programs and mint accounts. [4]
| Question | Coin | Token |
|---|---|---|
| Where is it defined? | In the blockchain’s base protocol and native ledger rules | In a contract, token program, mint, asset module, or comparable issuance mechanism |
| Does it need its own blockchain? | It is native to a blockchain | No; it relies on a host blockchain |
| What usually pays network fees? | The native asset of the network | Usually the host network’s native asset, not necessarily the token being transferred |
| How is it identified? | By the blockchain and its native asset designation | By the blockchain plus a contract address, mint address, asset ID, or equivalent identifier |
| What controls supply? | Base-protocol issuance and burn rules | Token code, mint authority, issuer rules, governance, or a combination of these |
| Typical examples | BTC on Bitcoin, ETH on Ethereum, SOL on Solana | ERC-20 tokens on Ethereum and SPL tokens on Solana |
Why the Name Alone Is Not Enough
The words “coin” and “token” are conventions rather than universal protocol keywords. A project may call its asset a token even when the asset is native to its current network. BNB Chain documentation, for example, describes BNB as the network’s native token and states that it is used for gas and staking. Under the functional test used in this article, native BNB on BNB Smart Chain has the operational characteristics commonly associated with a coin, despite the documentation’s chosen label. [5]
An asset can also have native and represented forms. BTC on the Bitcoin network is native BTC. A wrapped asset representing BTC on another blockchain is a token on that host chain; it is not the same ledger entry as native BTC. Solana’s documentation explicitly places wrapped assets in the token category. [4]
Even a familiar ticker may refer to several network-specific implementations. Tether’s official integration documentation lists USD₮ across multiple protocols and gives different contract addresses or asset identifiers for different networks. Consequently, “send USDT” is incomplete operational information: the sender and receiver must also agree on the network and supported implementation. [6]
Claim Registry
| Claim | Verification status | Primary source type and name | Source date | Limitation | What could change the conclusion? |
|---|---|---|---|---|---|
| ETH is Ethereum’s native asset, while ERC-20 assets are implemented through smart contracts. | Confirmed | Official Ethereum documentation, “Ethereum accounts” and “Ethereum gas and fees”; standards specification, “ERC-20: Token Standard” [2] | Accounts page updated April 13, 2026; gas page updated June 24, 2026; ERC-20 created November 19, 2015 | This establishes Ethereum’s architecture, not the authenticity or quality of every ERC-20 contract. | A future core-protocol change could alter fee or account mechanics. A specific asset may also use a different token standard. |
| Transferring a token may require a separate balance of the host network’s native coin. | Condition-dependent | Official Ethereum documentation, “Ethereum gas and fees” [7] | Updated June 24, 2026 | Ethereum mainnet gas is paid in ETH, but a relayer, sponsored transaction, custodial platform, or account-abstraction system may pay on the user’s behalf. | The selected chain, wallet, layer, application, or fee-sponsorship model can change who supplies the native fee asset. |
| A ticker such as USDT does not by itself identify the transfer network or token contract. | Confirmed, but dynamic | Issuer integration documentation, “Supported Protocols and Integration Guidelines” [6] | Undated live documentation, accessed July 28, 2026 | The issuer can add, discontinue, or deprecate protocol support. Exchanges and wallets may support only a subset. | An issuer update, contract migration, network deprecation, or platform integration change could alter the valid options. |
| BNB demonstrates that official naming does not always follow the everyday coin-versus-token convention. | Confirmed terminology issue | Official BNB Smart Chain documentation, “Introduction” [5] | March 16, 2026 | The documentation calls BNB a native token. Other publications may classify the same native asset as a coin. | A terminology policy change would affect the label, but not necessarily BNB’s protocol-level role. |
| A particular exchange, wallet, or recipient currently supports a given asset on a particular network. | Unknown until checked | Current deposit, withdrawal, or order interface of the platform involved; recipient confirmation where applicable | Must be checked immediately before the transaction | Asset support, networks, compliance requirements, maintenance status, and routes can change without affecting the underlying protocol classification. | Any platform update, maintenance event, compliance result, or temporary suspension may change availability. |
What the Difference Changes for a User
Transaction fees
Holding a token does not automatically mean that the wallet can send it. On Ethereum, gas fees are paid in ETH, including when the transaction calls an ERC-20 contract. A wallet containing an ERC-20 token but no usable ETH may therefore be unable to initiate a standard on-chain transfer. [7]
This is not a universal promise about every chain or application. Some services deduct fees internally, sponsor transactions, or use other execution models. The fee asset and payer must be checked for the exact route.
Network and asset identification
For a native coin, the network normally identifies the asset: BTC on Bitcoin or ETH on Ethereum. For a token, a ticker should be supplemented with its network and official on-chain identifier. Contract addresses, mint addresses, and asset IDs distinguish an intended token from similarly named or fraudulent assets.
A practical description is therefore “USDT on a specified network using the confirmed contract or asset identifier,” not merely “USDT.” Tether specifically instructs users to confirm the transport protocol when sending its tokens between addresses. [8]
Issuer and contract controls
Native coins follow base-protocol rules, although those rules can change through network governance and upgrades. Tokens may introduce an additional control layer. Depending on the implementation, an issuer or administrator may be able to mint new units, freeze accounts, pause transfers, upgrade contracts, or revoke authority.
Such controls are not present in every token and should not be assumed from the word “token” alone. Solana’s token documentation, for instance, describes optional mint and freeze authorities; their actual status must be read from the specific mint and current on-chain data. [9]
Classification checklist
- Identify the blockchain on which the asset currently exists.
- Check whether it is recorded as the network’s native balance or through a contract, mint, or asset module.
- Find the official contract address, mint address, or asset ID if one is required.
- Determine which asset pays the network fee.
- Check whether mint, freeze, pause, blacklist, or upgrade authorities exist.
- Distinguish a native asset from wrapped, bridged, or synthetic representations on other chains.
- Confirm that the receiving wallet or platform supports the exact network and implementation.
After establishing the asset and network, users considering an exchange can check the currently available exchange directions and networks. This availability check is a practical step, not evidence for an asset’s technical classification. Requirements may depend on the selected direction and the outcome of applicable compliance checks.
Transfer Risks and a Repeat-Verification Procedure
Wrong network or asset identifier: compatible-looking addresses do not prove that both parties support the same token implementation. Tether’s multi-protocol structure illustrates why the network must be confirmed separately from the ticker. [6]
Wrong recipient address: blockchain transactions may not provide a chargeback mechanism. Bitcoin documentation states that a completed payment cannot be reversed by the sender and can only be returned voluntarily by the recipient. Solana documentation likewise warns that sending to an unsuitable address can permanently lock funds in some cases. [10]
Insufficient native coin for fees: a displayed token balance can be unusable for a direct transfer if the wallet lacks the host chain’s fee asset. The amount required is dynamic and should be obtained from the wallet or network at the time of submission rather than copied from an article.
Phishing and impersonation: a fraudulent interface can substitute a recipient address, token contract, or approval request. Unexpected promises of guaranteed returns, requests for seed phrases, and instructions to send cryptocurrency for “protection” are warning signs. The FTC warns that scammers commonly impersonate companies and government bodies and use irreversible cryptocurrency payments to obtain funds. [11]
Jurisdiction and compliance differences: access, verification requirements, taxation, and the legal classification of an asset vary between countries and services. Technical classification as a coin or token does not determine regulatory status.
Final pre-transfer check
- Read the current official project documentation rather than relying on the ticker or an old screenshot.
- Confirm the asset’s blockchain and whether it is native, wrapped, bridged, or contract-issued.
- Compare the full contract, mint, or asset identifier with an official source and a reputable explorer.
- Verify the recipient’s supported network and required address format.
- Check the fee asset, estimated network fee, minimums, limits, and any current platform restrictions.
- Review the complete destination address instead of checking only its first or last characters.
- Use a small test transfer when the platform permits it and the resulting fees are proportionate.
- Recheck all details if the wallet, exchange, bridge, network, or token contract has changed since the previous transfer.
The most reliable classification test is functional: determine which blockchain supplies the ledger and consensus, then determine whether the asset exists natively in that protocol or through an issuance layer on top of it. The label used by a project is secondary. For an actual transfer, the decisive details are the network, on-chain identifier, fee asset, recipient compatibility, and current platform availability.
