TQ Tezos
Published in

TQ Tezos

Introducing FA2: A Multi-Asset Interface for Tezos

A request for comment about TZIP-12: a proposal for a unified interface supporting multiple token types and multi-asset contracts on Tezos

Overview

Key Resources:

Introduction

Background

FA2 Design Considerations

  • Ethereum’s major token standards have emerged based on popular token types (ERC-20 for fungible tokens, ERC-721 for non-fungible)
  • Although FA1.2 has seen early momentum, Tezos is nascent enough not to have strong path dependence towards standards specific to token types
  • In the long-run, a token standard which is agnostic to token type may produce stronger network effects and less friction as wallets and external applications need to support just one core transport API across multiple token types
  • Over-specification of permissioning restricts developers’ expressivity to create novel implementations and creates integration friction for wallets, constraining network effects from both sides
  • Under-specification leads to fragmentation and capture by popular implementations or use cases (e.g. exchanges)

Standard vs. Implementation

FA2 Implementation Patterns

Practical Use (i.e. learning from Ethereum)

Future-proofing

For more, see Contract Signatures and Read-only Calls

Further Directions and Request for Comment

  • Are operators the best available approach to permissioning transfers by external contracts?
  • Should operators have specified allowances (i.e. number of tokens allowed to transfer) or expiration (e.g. n blocks or n transactions after approving an operator)?
  • If operators do have expiration, should they have a default expiration? Note: Timestamps or LEVEL, a proposed Michelson instruction, may ease implementation of operator expiry based on number of blocks
  • Should transfer hooks be a core component of FA2 or instead be included in a separate standard which developers compose with FA2?
  • What types of permissioning should be defined in token standards vs. smart contract wallets (a la Argent or Gnosis Safe) and/or dedicated permissions standards?
  • Is there a permissions schema that is widely used in practice and requires a standard API, but is not covered by FA2 as presented in TZIP-12?
  • Should (or to what extent should) contract metadata be an independent standard / protocol feature or should it be specific to a token standard a la ERC-20?
  • Should there be a standard mechanism for attaching metadata externally (e.g. in a separate contract registry or off-chain)?
  • Should versioning be stored in contract metadata?
  • What should be included in contract versioning?
  • Should Total Supply be part of token metadata rather than a separate entrypoint?
  • How should decimals and granularity be handled to avoid fragmentation while also easing wallet integration?
  • Should any parts of contract storage be standardized (e.g. to assist indexers)?
  • How might FA2 be affected by future amendments?
  • What best practices and/or tooling should be developed such that smart contract standards can prepare for future protocol amendments?

Next Steps

  • Agora/Blog Post: Implementing FA2
  • FA2 Michelson interface
  • SmartPy implementations (single- and multi-asset versions)
  • Single Asset Fungible
  • Single Asset NFT
  • Single Asset Non-Transferrable
  • Multi-asset Contract

Acknowledgements

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
TQ Tezos

TQ Tezos works to advance the Tezos ecosystem by helping companies build on Tezos, creating open source software, and connecting the community.