Skip to main content

What is a native token

What is a native token

A native token is the built-in currency of a blockchain network -- the token that exists at the protocol level, not as a smart contract deployed on top of it. Examples include ETH on Ethereum, SOL on Solana, BNB on BNB Smart Chain, TAO on Bittensor, and AVAX on Avalanche. Every blockchain has exactly one native token, and it plays a foundational role that smart-contract-based tokens (such as ERC-20) cannot fully replicate.

Native tokens are used to pay transaction fees (gas), reward validators or miners for securing the network, and in many Proof of Stake networks, serve as the staking asset that validators lock to participate in consensus. Without the native token, the network cannot function -- it is the economic fuel that makes the blockchain operate.

In short: a native token is the chain's own built-in currency, used for gas fees, validator rewards, and staking, and it exists at the protocol level rather than as a smart contract.

How native tokens differ from smart-contract tokens

The distinction between native tokens and smart-contract tokens is fundamental but often overlooked. Both types of tokens can be held in wallets, transferred between addresses, and used in decentralized applications. However, they differ in origin, mechanics, and role.

Dimension Native token Smart-contract token (e.g. ERC-20)
Where it exists Built into the protocol itself Deployed as a smart contract on top of the protocol
Created by The network's protocol rules (genesis block, emission schedule) A developer deploying a contract
Needed for gas Yes -- required to pay transaction fees No -- gas is always paid in the native token
Role in consensus Often used for staking and validator rewards Not involved in consensus
Can exist without smart contracts Yes -- predates smart contract functionality No -- depends on the contract deployment platform
Supply controlled by Protocol rules (hard-coded emission, burning, inflation) Contract logic (mint/burn functions set by the deployer)

A practical example: on Ethereum, ETH is the native token. When a user sends an ERC-20 token (say, USDC) to another address, the user must pay the transaction fee in ETH, not in USDC. The ERC-20 token cannot move without the native token to pay for the computation. This dependency is baked into the protocol and cannot be circumvented.

Gas and transaction fees

The most visible role of a native token is paying gas fees. Every operation on a blockchain -- transferring tokens, interacting with a smart contract, deploying a new contract -- requires computational resources from validators or nodes. Gas fees denominated in the native token compensate these operators for their work. Without gas fees, there is no economic incentive for validators to process transactions, and the network would stall.

Gas fee structures vary by network. Ethereum uses a dynamic fee model (base fee + priority tip). Solana uses a fixed low-fee model. BNB Smart Chain and other EVM chains have their own fee parameters. But in all cases, the fee is paid in the chain's native token.

Staking and consensus participation

In Proof of Stake networks, the native token is typically the staking asset. Validators must lock a specified amount of the native token to participate in block production and validation. This staked amount serves as economic collateral: validators who behave honestly earn rewards (paid in the native token), while validators who misbehave risk losing their stake through slashing.

This creates a circular economic loop: the native token secures the network through staking, and the network rewards stakers with newly minted or fee-derived native tokens. The security of the network is directly tied to the total value of staked native tokens.

Validator rewards and emission

Most blockchain networks emit new native tokens as block rewards to incentivize validators. This emission is controlled by the protocol's rules -- not by any individual or smart contract. Some networks have a capped total supply (like Bitcoin's 21 million BTC), while others have ongoing inflation with or without burning mechanisms (like Ethereum's post-merge fee burning).

The emission schedule of a native token is a core part of the network's economic design. It determines the long-term supply dynamics and the incentive structure for validators. Changing the emission schedule typically requires a protocol-level upgrade (hard fork or governance vote), not a simple contract modification.

Examples of native tokens

Different blockchain networks implement their native tokens with different supply rules, fee models, and staking mechanics. Understanding these differences helps illustrate what "native token" means in practice:

Network Native token Key roles Supply model
Ethereum ETH Gas fees, validator staking, base currency Uncapped supply with fee burning (deflationary under high usage)
Solana SOL Transaction fees, validator staking Inflationary with declining emission schedule
BNB Smart Chain BNB Gas fees, validator staking, governance Capped supply with periodic burns
Bittensor TAO Subnet registration, miner/validator rewards, staking Capped supply with halving emission
Avalanche AVAX Gas fees, staking, subnet creation Capped supply with fee burning

In each case, the native token is inseparable from the network's operation. Removing ETH from Ethereum or SOL from Solana would break the chain entirely -- no transactions could be processed, no validators could be rewarded, and no smart contracts could execute.

Native tokens in crypto AI projects

Many crypto AI projects have their own native tokens because they operate their own blockchain networks or subnets. For these projects, the native token plays a dual role:

  • Infrastructure role: paying for transactions, staking, validator rewards -- the same functions as any blockchain's native token.
  • Application role: the token may also be used to pay for AI-specific services (inference, compute, data access), reward AI compute providers, or participate in governance of AI-related parameters.

When a project's token is native rather than a smart-contract token, it means the token is architecturally inseparable from the network. The chain cannot operate without it. This is a stronger form of token necessity than a smart-contract token that could theoretically be replaced by any other token.

However, "native" does not automatically mean "necessary for AI." A project can have a native token that secures its network through staking and pays for gas, while the AI components of the project do not meaningfully require the token to function. The infrastructure role and the AI role are separate questions.

Token necessity and native tokens

When evaluating whether a token is necessary for a project's AI pipeline, native tokens present a nuanced case. On one hand, a native token is undeniably necessary for the network's operation -- the chain literally cannot function without it. On the other hand, the question of AI necessity is separate: does the AI pipeline specifically require this token, or would the AI components work the same way if deployed on a different chain with a different native token?

A strong case for AI-level token necessity exists when the native token directly mediates AI-specific actions: paying for inference, rewarding compute providers, staking as a quality guarantee for model outputs. A weaker case exists when the native token only serves generic infrastructure functions (gas, staking) while the AI layer could theoretically operate on any chain.

Where it appears in DecAIHub project cards

In a DecAIHub project card, the value for a native token is recorded as native in the Token standard field. When a card shows Token standard: native, it means the project's token is not deployed as a smart contract on another chain but is the built-in currency of the project's own network.

This distinguishes the project from those whose tokens are ERC-20 contracts on Ethereum, BEP-20 on BNB Smart Chain, or SPL on Solana. A native token indicates that the project operates its own blockchain or subnet with its own consensus mechanism.

The token standard field tells readers the technical format of the token. To understand the token's role, readers should check the Token model field (utility, governance, fee mechanism, staking) and the Evidence table for Tier-1 artifacts showing how the token is actually used in the project's pipeline.

What "native token" alone does not prove

  • Native token does not prove decentralization. A project can operate its own chain with a native token and still have a small, centralized validator set or centralized governance. The token's native status describes its technical role, not the network's decentralization profile.
  • Native token does not prove AI necessity. The token may be essential for the chain's consensus and gas fees while being irrelevant to the project's AI pipeline. Whether the AI components require the token is a separate question answered by the Token necessity axis in DecAI Fit.
  • Native token does not prove the network is mature. A project can launch its own chain with a native token while the network is still on testnet or in early beta. Check the Network status field for maturity information.
  • Native token does not mean the project built its own chain from scratch. Many native tokens exist on subnets, app-specific chains, or forked networks. The native token indicates the token's protocol-level role, not the project's engineering effort.
  • Native token does not prove adoption. A native token with no active validators, no user transactions, and no real usage is still technically a "native token." Technical classification does not equal real-world utility.

Do not confuse with

  • ERC-20 and other smart-contract tokens -- ERC-20 tokens are deployed as contracts on an existing chain and depend on that chain's native token for gas. Native tokens exist at the protocol level and do not depend on any smart contract.
  • Token standard -- the umbrella concept covering all technical formats (ERC-20, BEP-20, SPL, native token). "Native token" is one type of token standard -- the one where the token is built into the chain itself.
  • Token model -- the token model describes the role of the token (utility, governance, staking, fee mechanism). A native token can serve any of these roles. "Native" describes the technical format; "utility" or "governance" describes the function.
  • Wrapped native tokens (WETH, WSOL) -- some ecosystems create ERC-20-compatible wrappers around native tokens so they can be used in smart contracts that require the ERC-20 interface. WETH is an ERC-20 representation of ETH, not ETH itself. The wrapped version follows a smart-contract standard; the original remains a native token.
  • Gas token -- sometimes native tokens are informally called "gas tokens" because they are used to pay gas. But "gas token" is not a formal standard or classification -- it is a description of one of the native token's functions.

Frequently asked questions

Why can't gas fees be paid in any token?

Gas fees are processed at the protocol level -- by the validators and the consensus mechanism itself, before any smart contract logic executes. The protocol is designed to accept only the native token for gas because it needs a single, reliable unit of account to meter computation and prevent spam. Some networks and Layer 2 solutions are experimenting with fee abstraction (allowing gas to be paid in other tokens), but under the hood, the native token is still typically involved in the final settlement.

What is the difference between a native token and a utility token?

"Native token" describes the technical format: the token is built into the blockchain protocol. "Utility token" describes the economic role: the token is used to access services, pay for usage, or participate in the project's functionality. A native token can also be a utility token -- for example, TAO on Bittensor is both the native token of the Bittensor network and a utility token used to pay for AI inference and reward subnet participants. The two labels describe different dimensions of the same token.

Can a project have both a native token and ERC-20 tokens?

Yes. A project that operates its own blockchain has a native token for that chain. The same project might also issue ERC-20 tokens on Ethereum for bridging, liquidity, or cross-chain compatibility. Some projects maintain their native token on their own chain and a wrapped or bridged version on Ethereum or other EVM chains. These are technically different tokens (native vs. smart-contract) that represent the same underlying asset through bridging mechanisms.

External references

See also

No comments to display

Back to top