Logo Oficial MASTR MASTR
Menú
Leer la publicación

MASTR · CRYPTO & WEB3

Programmable money: why token standards changed the industry

Common interfaces made wallets and markets reusable. They did not make every asset economically equivalent or safe.

Orígenes e historia · 2015–2018 · 3 min de lectura

Los capítulos y gráficos técnicos están en inglés. La navegación está disponible en siete idiomas.

What does a token standard actually promise?

From a payment to a state transition

A smart-contract platform lets a transaction call code that changes shared state. The network verifies the resulting state transition under its rules. This makes it possible for balances, collateral, ownership records and trading logic to interact. It does not make the programme’s business assumptions correct. An oracle can provide a bad input; an administrator can retain powerful controls; a user can authorise an economically harmful action that is completely valid execution.

The interface created a common language

ERC-20 specifies an interface for fungible token balances, transfers and allowances. ERC-721 specifies an interface for distinguishable tokens and their ownership. Their historical significance lies in interoperability: a wallet or exchange can support a common vocabulary instead of writing a completely separate integration for each asset. The contract address and chain still matter because a name or symbol is not a unique identifier.

A common interface is not a common guarantee
Diagrama educativo simplificado con supuestos indicados; no demuestra un incidente concreto. Abrir el gráfico completo ↗

An interface is not the whole implementation

Two tokens can implement the same functions while using very different administrative rules. One might have a capped supply, another an authorised minter. Transfers may depend on restrictions implemented beyond the standard interface. A contract can also be upgradeable. Standard compliance therefore answers a narrower question than an investment pitch suggests: can an application call these expected functions, not whether the issuer is solvent, the supply fair or the asset suitable for a user.

Allowances introduced a second relationship

Owning tokens and authorising another contract to spend them are different states. A swap may need an allowance, but that permission can remain after the swap completes. Disconnecting a website from a wallet does not necessarily change the onchain allowance. This is why approvals and signed permits deserve their own reference entries instead of being hidden inside a generic transaction tutorial.

Composability magnifies both usefulness and dependencies

A lending protocol can accept a receipt token created elsewhere. A market can trade that receipt. A vault can automate several such positions. The common interfaces make this possible, but each added dependency can transmit failures. Draw the contracts and the claims between them before calling a stack decentralised. The engineering history is a story of reusable interfaces and of the new control surfaces those interfaces expose.

Ejemplo explicado

A wallet may show two assets called USD with the same icon. One is issued by a recognised contract; the other is a newly deployed copy. The display labels match, but the chain-and-contract pair, redemption arrangements and administrative powers do not.

Preguntas para recordar

  • Identify the chain and contract.
  • Inspect controls beyond the standard interface.
  • Separate transfer authority from token ownership.

Fuentes primarias y lecturas

  1. ERC-20: Token Standard ↗
  2. ERC-721: Non-Fungible Token Standard ↗
  3. ERC-2612: permit extension ↗

Seguir explorando

Rutas de aprendizaje

MASTR

Apoya la investigación independiente

Las investigaciones, las pruebas originales y las guías son de acceso libre. Las donaciones voluntarias ayudan a financiar la investigación y a mantener disponibles las herramientas de MASTR.

Abrir billetera