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 or LEVEL, a proposed Michelson instruction, 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 or Gnosis Safe) 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.
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.
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.
