Logótipo oficial do MASTR MASTR
Menu
Ler a publicação

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.

Origens e história · 2015–2018 · 3 min de leitura

Os capítulos e gráficos técnicos estão em inglês. A navegação está disponível em sete 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 com pressupostos explícitos; não comprova um incidente específico. Abrir o 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.

Exemplo 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.

Perguntas a reter

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

Fontes primárias e leituras

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

Continuar a explorar

Percursos de leitura

MASTR

Apoiar a investigação independente

As investigações, as provas originais e os guias são de acesso livre. Os donativos voluntários ajudam a financiar a investigação e a manter disponíveis as ferramentas MASTR.

Abrir carteira