# Request for Comment on TZIP-12 (FA2): A Multi-Asset Interface for Tezos

**URL:** https://forum.tezosagora.org/t/request-for-comment-on-tzip-12-fa2-a-multi-asset-interface-for-tezos/1737
**Category:** Research and Development
**Tags:** michelson, ligo, smartpy
**Created:** [March 6, 2020, 7:14pm UTC](https://forum.tezosagora.org/t/request-for-comment-on-tzip-12-fa2-a-multi-asset-interface-for-tezos/1737 "2020-03-06T19:14:00Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![galfour](https://forum.tezosagora.org/user_avatar/forum.tezosagora.org/galfour/32/29_2.png) [@galfour](https://forum.tezosagora.org/u/galfour)
#### Post date: [March 24, 2020, 11:04pm UTC](https://forum.tezosagora.org/t/request-for-comment-on-tzip-12-fa2-a-multi-asset-interface-for-tezos/1737/4 "2020-03-24T23:04:02Z")

</div>

# FA2 Answer

# Permissions

> Are operators the best available approach to permissioning transfers by external contracts?

I believe they are not, for multiple reasons:

- They are a topic complex enough to deserve its own separate treatment
- They make the standard heavier than needed, and can easily be factored out of it
- Their current version is both too complex (most contracts not needing them) and too simple, as evidenced by the next points

> - 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](https://ligolang.org/docs/advanced/timestamps-addresses/) or LEVEL, a [proposed Michelson instruction](https://gitlab.com/cryptiumlabs/tezos/-/merge_requests/71), may ease implementation of operator expiry based on number of blocks  
> 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?

Only having operator/owner, specified allowances and expiration still leave out important use–cases:

- Multisig
- Daily spending limit
- Votes
- Generic blackbox permission

Adding all of these features would make the standard (and contract size) blow up.

> 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](https://www.argent.xyz/) or [Gnosis Safe](https://safe.gnosis.io/)) and/or dedicated permissions standards?

I believe permission matters be all moved to a dedicated permission standard, that the token standard should refer to that permission standard, and that wallets should support it.

* * *

# Metadata

> 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)?

[Yes. I discuss it more extensively in this thread.](https://forum.tezosagora.org/t/metadata/1769)

> Should Total Supply be part of token metadata rather than a separate entrypoint?

It of course _should_. However, we do not really have support for metadata right now. So I suggest adding it in the standard (as other kind of metadata), and removing it later once we stop needing it, as we should.

> How should decimals and granularity be handled to avoid fragmentation while also easing wallet integration?

In metadata too. However, I believe it is best to leave it dealt informally instead of adding it in the contract until we have metadata.

* * *

# Version

> Should versioning be stored in contract metadata?  
> What should be included in contract versioning?

All talks of smart-contract “versioning” have been confusing me, and I believe they will until I see a clear description or concrete proposition.

* * *

# External Views

> Should any parts of contract storage be standardized (e.g. to assist indexers)?

[Yes. I discuss it more extensively in this thread.](https://forum.tezosagora.org/t/external-views/1768)

* * *

# Future Proofing

> 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?

I believe not much can be done on that front so far. I found the discussion of potential future amendments and their implications good enough for now.

---

_[View the full topic](https://forum.tezosagora.org/t/request-for-comment-on-tzip-12-fa2-a-multi-asset-interface-for-tezos/1737)._