Token

Reading depth

Each view includes the earlier layers; the complete engineer or auditor page is shown by default.

BeginnerCore purpose and mental modelPractitionerAdds mechanisms and economicsEngineer or auditorAdds state and verification

Dependency check

Advanced detail assumes prerequisite knowledge

Before using practitioner mechanisms or engineer and auditor checks, review any unfamiliar dependency. These paths come from canonical depends_on relationships; Web3 Academy does not track completed lessons.

Review 2 dependencies

• AssetDirect prerequisite

  1. Token
  2. Asset

• ClaimDirect prerequisite

  1. Token
  2. Claim

A token is a programmable ledger entry that represents units a blockchain system can track and transfer.

Category: Money and assetsCircle category cue

System record

Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.

Why it exists

Tokens let software identify ownership or entitlement and apply consistent transfer, issuance, and redemption rules.

Traditional-finance analogy

Account entry or security certificate is the closest comparison recorded for this concept.

Where the analogy stops

• A token's transfer and control rules execute through blockchain software.
• The legal or economic right represented by a token depends on its specific design and issuer.

Main actors

• ActorHolder
• ActorIssuer or protocol
• ActorTransfer-rule administrator

Assets and claims

Assets — controlled or transformed resources

Assets are resources the mechanism moves, holds, values, or transforms.

• AssetToken units

Claims — entitlements and corresponding dependencies

Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.

• ClaimRights defined by the token contract or issuer

A token is a ledger representation, not one fixed kind of economic asset.

Why it exists

Applications need a common way to identify balances and apply rules for transfer, issuance, burning, approvals, redemption, or governance. Token interfaces make those operations legible to wallets and other contracts. The economic meaning still comes from the token’s issuer, backing, protocol rules, and legal context.

Traditional-finance analogy

An account entry, security certificate, currency unit, or membership record can all resemble a token. No single analogy is sufficient: two tokens with the same technical interface can represent a direct asset, redeemable claim, pooled share, debt claim, derivative exposure, or governance right.

Main actors

The holder controls units under the token’s authorization rules. The issuer or protocol defines supply and entitlements. Administrators may pause, freeze, upgrade, or recover units. Operators receive allowances or approvals to act for a holder. Integrators decide how the token is valued and accepted elsewhere.

Assets and claims

To interpret a token, ask two separate questions:

1. What state does the contract or protocol record?
2. What economic right does one unit represent?

The first question is technical. The second may require reserve reports, governance rules, legal documents, or another protocol’s accounting. The asset-versus-claim page joins the two.

These six labels are a starting taxonomy, not mutually exclusive token types. A layered token can be a pooled share with a redeemable claim, or a debt claim whose payoff is also a derivative exposure. Name every material right and the layer at which the token is a direct asset.

Step-by-step token lifecycle

1. Define the ledger unit and the economic right, if any, that one unit represents.
2. Establish who may issue, transfer, approve, freeze, upgrade, burn, or redeem units.
3. Mint units only under the documented supply, backing, or entitlement rule.
4. Transfer units or delegate a bounded operator right while preserving authorization and balance accounting.
5. Burn, lock, or redeem units when their ledger position or associated claim is settled.
6. Reconcile balances, total supply, backing, and any external obligation after every operation.

State transitions

Table: State transitions

Operation	Balance effect	Supply effect	Control to verify
Transfer	Sender decreases; recipient increases	None	Holder signature or authorized operator
Mint	Recipient increases	Total supply increases	Issuance authority and backing rule
Burn	Holder or designated account decreases	Total supply decreases	Holder consent or documented administrative power
Approve	Balances do not move yet	None	Scope, amount, spender, expiry or revocation behavior
Redeem	Token is burned or locked and another asset may leave	Depends on model	Eligibility, liquidity, conversion, and single settlement

An interface may omit, extend, or restrict these operations. “ERC-20” describes an API contract; it does not prove that minting is capped, transfers are permissionless, or redemption exists.

Flows and return

Capital flow occurs when token units or their underlying assets move. Claim flow occurs when minting or deposit creates an entitlement. Control flow runs through holders, spenders, administrators, and upgrade keys. Return flow exists only when a named payer, economic activity, or issuance program supplies value; a token balance alone is not a payer. Risk flow follows bugs, privileged actions, backing shortfalls, and integrations that assume the wrong token behavior.

A token balance has no automatic return. Borrowers may pay interest, users may pay fees, issuers may distribute asset income, and sponsors may fund incentives. Protocol issuance creates new units and can dilute non-recipients rather than paying from existing revenue. If token code, backing, custody, or an integration fails, holders or the dependent protocol’s users absorb the loss unless an explicit reserve, insurer, guarantor, or recovery process reallocates it.

Assumptions and failure modes

Interpreting a token assumes that its contract identity, chain, decimals, authorization rules, supply controls, backing, and stated economic rights are the ones an integration actually observes. A familiar interface, name, or symbol does not establish those facts. Failure modes include unauthorized mint or transfer, accounting drift, frozen or unredeemable balances, compromised administration, backing shortfall, and dependent contracts applying the wrong behavioral assumptions. The affected holders or integration users bear the result unless a specifically funded recovery layer reallocates it.

Engineer or auditor lens

Review balance and supply conservation, zero-value and boundary transfers, allowance races and operator scope, mint/burn authorization, fee-on-transfer or rebasing behavior, hooks, callbacks, pause/freeze/deny-list powers, proxy upgrades, event consistency, decimals, and non-standard return values. Integrations should check observed behavior rather than assuming every token implements a nominal standard identically.

Common misunderstandings

• “A token is the underlying asset.” Often it is a representation or claim.
• “The symbol identifies the token.” Contract address, chain, and verified implementation matter; symbols can collide.
• “A standard interface proves solvency.” Interface compatibility says nothing about backing or issuer performance.

Primary reference

The final ERC-20 specification standardizes balances, transfers, approvals, allowances, supply, and events so tokens can be reused by wallets and applications. It explicitly leaves room for implementations with different trade-offs; the interface is not an economic classification.

Machine-readable model

Key equations

Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.

This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.

Assurance contract

Security properties

These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.

Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.

1. SP-01Desired · not evaluated

   Transfers conserve units except when an authorized issuance or burn rule applies

2. SP-02Desired · not evaluated

   No account balance becomes negative

3. SP-03Desired · not evaluated

   Only authorized actors can mint, burn, transfer, or spend another holder's units

Prerequisites

Direct dependencies recorded by this concept's canonicaldepends_on relationships.

• AssetPath 1

  An asset is an economic resource or enforceable right that someone controls and expects to preserve, exchange, or use for value.

• ClaimPath 2

  A claim is a right held by one party to receive assets, income, redemption, control, or another specified benefit from a system or obligor.

Learn next

Concepts that directly depend on this one, ranked by the recommended learning path. Check each page for additional prerequisites.

• Asset versus claimPath 4

  The asset-versus-claim distinction asks whether a token is the resource itself or a right whose value depends on another asset or obligor.

• Claim tokenPath 5

  A claim token records a transferable or account-bound entitlement to assets, income, redemption, governance, or another protocol-defined benefit.

• StablecoinPath 6

  A stablecoin is a token designed to track a reference value, usually a currency, through reserves, collateral, redemption, or market incentives.

Knowledge check

Quiz

Answer in your own words, then open the model answer.

What problem does Token exist to address?

Model answer

Tokens let software identify ownership or entitlement and apply consistent transfer, issuance, and redemption rules.

Mark as understood