Everything about, and the road to FA2 for Tezos explained.
Please Note: Stakin has discontinued its Tezos public infrastructure as of 1st of January 2022, as such the baker is no longer generating rewards and this guide is no longer maintained. For more information, read our official announcement (link to it) or visit https://stakin.com.
Hey Readers,
Recently, TQ Tezos announced that FA2 (TZIP-12) would be implemented shortly. FA2, FA1.2 refers to smart contract specifications for digital assets. In a nutshell, FA2 proposes that the implementers should handle everyday considerations like defining the contract’s token type, administration, contract upgradability, and supply operations. In this article, we will give you a further explanation of FA2, what came before, and what the motivation behind it is.
FA1.2
Currently, the focus of the Tezos network is still on FA1.2 and a Multisig Contract, which are the predecessors of FA2. To be able to understand FA2, we first have to take a look at its predecessors.
FA1.2 (TZIP-7) touches on the ERC20-like fungible token standard. In a nutshell, FA1.2 consists of a ledger that maps identities of token balances provides a standard application program interface (API) for token transfer operations, and provides approval to external contacts accounts to transfer users tokens. ERC20 was created on Ethereum as a standard interface that would allow any tokens on the network to be re-used by other applications such as wallets and decentralized exchanges. For those interested in the technical implementation, there are many different versions such as LIGO, Lorentz, and SmartPy.
When FA1.2 launched last year, the aim to follow up with a new token standard proposal was shared right away. Eventually, this led to the proposal of FA2 — a standard token proposal for public comment on Tezos Agora. Although FA1.2 has seen a high demand for financial use cases that needed a single fungible token contract, FA2 is skeptical of the token type. Also, it allows both single- and multi-token contracts via one standard API.
Motivation Behind FA2
To implement a particular token smart contract, many considerations and dimensions have to be considered. The first is that tokens can be fungible or non-fungible. Fungible tokens or digital assets are interchangeable, meaning that they can be exchanged with any other digital asset of the same type. So, for example, Euro’s can be exchanged for Dollars. Non-fungible tokens can’t be exchanged for another digital asset of the same type.
A variety of different permission policies can be implemented to define the number of digital assets that can be transferred, who initiates the transfer, and who receives the assets. Token contracts can be designed to support just one single token type or multiple digital asset types to optimize batch transfers and atomic swaps of the tokens.
All of these considerations can lead to the expansion of token standards, each optimized for a specific type of digital asset or use case. If you look at the Ethereum ecosystem, for example, you can see that many different ideas have been proposed. Non-fungible (ERC-721) and fungible (ERC-20) are still the most commonly used.
To make a long story short, token wallets and exchanges, as well as other stakeholders, need to support multiple standards and multiple token APIs. With the introduction of FA2, a unified token contract interface that accommodates all the above-mentioned issues is created. The goal of the FA2 proposal is to provide the possibility of self-expression — through their creation of new types of digital assets — to contract developers. while at the same time, keeping one common interface standard for external developers.
FA2 (TZIP-12)
FA2 provides developers with a broad scope to define and invent new token types with complex interactions. It also helps to maintain a standard API for wallets, exchanges, and applications. For example, think about non-transferrable badges to incentivize behavior or multi-asset contracts that contain thousands of different gaming items.
Now, this is where it gets technical; let’s take a look at the FA2 abstract. A token type is identified on the blockchain by a pair, composed of the token contract address, the token ID, and a natural number. With FA1.2 the underlying contract implementation supports only one token type ID. But, with FA2 the contract supports and is responsible for assigning and managing multiple token IDs. This differentiation helps FA2 users to not have to depend on one specific ID value, to get the right information about a digital asset. Furthermore, FA2’s interface specification proposes to standardize transfer semantics (supporting both single and multi-token transfers), accessing balances and total supply, metadata, and some basic operator permissioning.
FA2 leaves it to whoever is implementing, to select the permission policies that will be applied to all tokens and token owners managed by the FA2 contract. The illustration below shows the different standard permission policies that can be selected.
Conclusion
Before TQ Tezos developed the FA2 proposal, they took an in-depth look into Ethereum use-cases. From there on, they’ve made sure the FA2 aims to offer usable permission policy, introduce operators by token type, and expiration and the notion of default expiry for operators. During the FA2 design process, many features that would be very well-suited for specific applications or tooling where identified. However, most of them were not universal enough or may create other kinds of dependence for future standardization efforts. A highly generalized standard, as is the case with FA2, seems to be the most pleasing for all users.
More Information
DISCLAIMER: This is not financial advice. Staking, delegation, and cryptocurrencies involve a high degree of risk, and there is always the possibility of loss, including the loss of all staked digital assets. Additionally, delegators are at risk of slashing in case of security or liveness faults on some protocols. We advise you to do your due diligence before choosing a validator.
Join the conversation