Issue multiple FungibleTokens from a single contract

[justjoolz]

Issue To Be Solved

Currently if a project wishes to issue multiple tokens that are compatible they need to deploy a new contract for each token they wish to issue.

This is quite common requirement in DeFi applications issuing LPTokens, Fractional tokens, social tokens etc.

Suggest A Solution

Create a 2nd FungibleTokens (plural) interface that adds an ID field to the Vault resource allowing for an extra dimension of token type per contract implementation.

Are there any drawbacks to this approach?

I'm thinking FungibleTokenZ might be a better name to avoid the confusion of plural vs singular. (FungibleTokenSet or FungibleTokenCollection)

Should this live in this repo or have another separate repo? Personally, I think it would make sense to put them here together and mention the appropriate use cases for each..

[bluesign]

Hey @justjoolz,

This is very good idea, few suggestions:

• I feel there is a need for Ticker Symbol

• tokenID and tickerSymbol ( if added ) should be guaranteed to be globally unique. ( I think this is the most tricky part, squatting symbol etc ) I think we will end up 2 level here: ISSUER.TOKEN (ex: CIRCLE.USDC etc )

• Maybe linking with existing Fungible Token standard can be a better choice. ( I mean adding ticker symbol and token ID there somehow ) More like FungibleTokenV2 instead of FungibleTokens ( I think it is also possible to update old Tokens to support new standard )

• In general I like separating by Type more than separating by ID. But in this case, I think it can be a valid exception. But also I am a bit scared there maybe some misuse cases. ( System actors can force people to use their own ISSUER for some benefits )

[justjoolz]

I was thinking Ticker Symbol and issuer could be defined as MetadataViews but not a requirement of the interface? Issuer in this case would be similar to Contract level metadata for an NFT collection

Here tokenID is used in same way as ID in NFT standard, ie not unique across implementations.

Not sure if there is a good way (semantically) to have singular and plural token issuing in the same contract, unless we had optional parameters (ie. don't need to pass tokenID: nil to a Vault issued from a singleton contract)

[bluesign]

Ah I just got the tokenId, this is good point.

I think having 2 standards (when multiple already covers single use case with tokenId=1) can be confusing for adaptation.

Also as metadata is a standard now, forcing new standard to use existing standard can be beneficial.

Maybe something like NFT minting, you can mint a new type of FT. ( so people can query which subtype of FTs contract has also they can have separate totalSupply etc when minted )

[joshuahannan]

This is definitely needed, but @dete has a more fundamental update in mind for the fungible token standard to be able to support multiple definitions by basically using resource interfaces defined in a contract instead of contract interfaces. He has written a proposal that he is going to share with the community soon.

[justjoolz]

@bluesign the design does work like Minting new FTs (and storing in a shared collection), totalSupplyByID is intended to be used exactly as you described.

@joshuahannan that sounds interesting, look forward to seeing the proposal...

I tried to keep this as simple as possible and as a blend of the existing FT and NFT standards without introducing any new patterns/concepts.

[joshuahannan]

@justjoolz Have you seen the proposal yet? We posted it last week: https://forum.onflow.org/t/streamlined-token-standards-proposal/3075/13

[joshuahannan]

This is handled in the v2 standard, so I am going to close this issue