WIP: V2 FungibleToken Standard

[joshuahannan]

Adds the v2 fungible token standard, as described in this forum post: https://forum.onflow.org/t/streamlined-token-standards-proposal/3075/37

A few highlights:

• Turns FungibleToken into a contract instead of a contract interface
• Introduces a new contract interface with a totalSupply field and function to get the vault types that the contract implements. This will help external parties learn about which vaults a contract implements since contracts can implement multiple vault types now
• Adds a Transferable interface to include a transfer function
• Adds getAcceptedTypes() to the Receiver interface so a receiver interface can indicate which vault types it accepts.
• Moves standard paths to inside the vault object definition because they are specific to the actual vault instead of the contract now.
• Defines the VaultInfo struct to return type and path information for a specific vault type
• Moves createEmptyVault into the vault resource
• Adds type parameters to the all the events since contracts can have multiple vault types defined

There are probably more that I am missing, but most of the details are in the forum post, so that is another good resource.

[joshuahannan]

The only test I have written so far is a deployment test, which is currently failing because it says the ExampleToken.Vault does not implement FungibleToken.Vault correctly, which I am confused about. maybe it is a bug.

Once we can align on which features to include, I'll work on adding more tests

[bluesign]

The only test I have written so far is a deployment test, which is currently failing because it says the ExampleToken.Vault does not implement FungibleToken.Vault correctly, which I am confused about. maybe it is a bug

Transfer?

[joshuahannan]

oh yeah, good catch! The test still fails with the same error though. 😅

[bluesign]

oh yeah, good catch! The test still fails with the same error though. 😅

createEmptyVault inside vault interface, it should be on contract interface I guess. tried to do a PR but couldn't manage

[austinkline]

I hope it isn't too early to give feedback! 🙏

Main thing I think we could explore is whether a Provider can be rethought to include a way to scope them to a specific allowed amount to be withdrawn. Would love to hear your thoughts on that!

[austinkline]

Maybe out of scope, but you could make these transfers "safe" by making use of LostAndFound

[joshuahannan]

I love what LostAndFound does, but I don't think it belongs in a standard like this unfortunately. I might be able to be convinced otherwise though

[austinkline]

ExampleToken isn't the standard, though, is it? that's where we can add these kinds of utiltities

[austinkline]

It absolutely doesn't belong in the FT interface or the base FT contract though. If ExampleToken should be a minimum implementation, it wouldn't belong here either so I think it just depends on what the purpose of ExampleToken is

[justjoolz]

I think there is definitely room for more than one Example, there should be at least a minimal single token example plus a separate multi-token example, a derived balance example etc.

[joshuahannan]

Good point. I was getting them mixed up. I'll leave this open and come back to it once we address all the other comments. I like the suggestion of keeping this as a minimal example, then making another one that has multiple tokens, lostandfound usage, etc

[austinkline]

This makes sense to me 👍

[austinkline]

Is there a way the FungibleToken interface itself can enforce that this is correct?

[joshuahannan]

not that I am aware of. @turbolent do you know if it would be possible to implement post conditions for destructors in a resource interface

[bluesign]

I would put there something like:
if self.balance>0
99% of the cases it is 0.

[joshuahannan]

What would that accomplish @bluesign ? Maybe I am misunderstanding.

[bluesign]

flow still thinks registers are updated even update is no-op.

For example, currently FlowToken spams this on every block. ( FlowToken.totalSupply as changed ) Actually it is a bit Flow-go problem. But it is good to not even write something, when it is not changed I guess.

[joshuahannan]

oh yeah, that is a good point. I'll change that. That could be changed in the current example contract and flowtoken too

[bjartek]

Why is this address and not a capability? I just feel that a capability gives the user so much more options here. They can transfer into their own capability with a good event.

[joshuahannan]

I figured that people would only ever use this for a basic transfer, and if they want to use a special capability, they can just use the regular withdraw-deposit method. I'm not dedicated to that position though, so I could be convinced to put it as a capability if enough people want that.

[bjartek]

The problem with withdraw/deposit is that it is impossible to create a good event out of that in the transfer method since it only contains one side. In .find profile we already link ftReceiver using our wallet abstraction and I would love to be able to send in that capability to this to be used for transfer.

Other use cases can be if you want to transfer funds from one wallet to a shared/pooled wallet of some kind.

I would really love though to have a static function in the new standard that can emit a shared event. Right now when you want to crawl for deposit events you have to know all the contract names. If the shared interface contract has a static function (when we get those) that said you could use to transfer with then that function could emit an event and everything would be so much simple. (The same argument is even stronger in NFTs IMHO)

[joshuahannan]

I'm not understanding the point about the event. We could still have a shared event here whether or not we have a capability or address:

pub event TokensTransferred(amount: UFix64, from: Address?, to: Address?, type: Type)

I do see your point about wanting to be able to use different kinds of capabilities. So are you imagining a transaction like this?

// Can pass in any storage path and receiver path instead of just the default.
// This lets you choose the token you want to send as well the capability you want to send it to.
transaction(amount: UFix64, to: Address, senderPath: StoragePath, receiverPath: PublicPath) {

    prepare(signer: AuthAccount) {

        // Get a reference to the signer's stored vault
        let vaultRef = signer.borrow<&{FungibleToken.Provider}>(from: senderPath)
			?? panic("Could not borrow reference to the owner's Vault!")

        let recipient = getAccount(to)
        let receiverCap = recipient.getCapability(receiverPath)

        // Transfer tokens from the signer's stored vault to the receiver capability
        vaultRef.transfer(amount: amount, recipient: receiverCap)
    }
}

That seems reasonable

[bluesign]

I am still not sure about balance being derived field.

are there some use-cases require this ?

[joshuahannan]

@dete Was the one who made the ask for a derived field. Maybe he can provide some insight

[LanfordCai]

Maybe it is because a derived field will make it easy to add some special mechanisms like rebase

[swordc]

@dete Was the one who made the ask for a derived field. Maybe he can provide some insight
Maybe it is because a derived field will make it easy to add some special mechanisms like rebase

Highly discouraged to use getBalance() on flow just for an rebase token.
Since the contract codes can be updated on flow, malicious project can modify getBalance() to attack contracts that include this function.
It is risk to import an external function only for reading balance. for example, re-entrancy attack could ocuur

[austinkline]

To give another side of the coin for balance being a function which I ran into recently while implementing ScopedFTProviders

Because balance is not a function, I could not actually wrap the FT standard because I need to delegate balance to the underlying capability being stored.

[joshuahannan]

I'm actually going to hold off on including the scoped provider for now. It is something we will definitely include in this upgrade the future, but I don't want that discussion to distract from the discussion of the core proposal yet

[justjoolz]

I'm not sure if I'm not getting something here but does this proposal allow creating new vault types at run time?
ie. using LP Tokens as an example.... how would you create a new token/vault type to match the new swap pool?
#59

[bjartek]

Can we consider overflow or flow-js-testing for tests here? Both a very much more readable then these tests that contains alot of boilerplate.

[joshuahannan]

@justjoolz I don't understand the use case very well, so I'm not totally sure, I don't think it could create new token types at run time that are equivalent to every other fungible token that gets implemented with this standard. You could potentially give your Vaults IDs so that they would be the same type but differentiated by IDs, but I don't know if that solves your use case, because to Cadence, they still would look like the same type. Does that help? Do you have any ideas?

[joshuahannan]

@bjartek Yes, we're also going to refactor the tests here to use a better testing framework, but just haven't gotten to it yet

[justjoolz]

@joshuahannan use case is just that, creating tokens at run time. For example currently BloctoSwap and Incremental.fi have to deploy a new copy of the LP token contract to a new address for every swap pair that they list, which means a lot of identical code deployed on the network... extra storage space used etc.

A protocol that wants to issue 'social tokens' like Roll would have to do the same. Or an NFT fractionalizing protocol like Fractional.art .. any platform that wanted to programmatically issue unique tokens to creators on their platform.

With the current proposal here you'd need to be able to create a new resource type definitions at run time, I can't see how that could happen easily....

One possible solution following same pattern as #59 would be to use a more generic string identifier (which can still come from getType().identifier and be appended to if there are multiple tokens of the same type defined... something like: A.00000000.ExampleToken.Vault.TypeA
A.00000000.ExampleSwap.Vault.FLOW_FUSD

The identifier could be passed in as an optional parameter to the createNewVault, withdraw and transfer functions.... though it would be ugly passing in nil all the time when you didn't want to use this feature..... it would work great if Optional parameters where totally optional... as in you could choose to not pass in a value at all (instead of passing in nil it would simply default to nil if omitted) That would improve the semantics for interacting with normal single token per contract

What do you think? Is it too much to try and force this into the same standard? Would it be better as a separate complementary standard for these kind of use cases? Or better to just have everyone who wants this functionality to roll their own?

[joshuahannan]

I still don't really see the need to deploy a whole new contract to do this, even with the existing fungible token standard. They could just give their vaults an identifier field and add a pre-condition to the deposit function that the deposited vault must have the same identifier as the vault being deposited into. Then they could also define a separate createEmptyVault with another parameter, like you say, to create a vault for a specific token type. Same with minting.

With this standard, if there is enough support for it, we could even make a getIdentifier(): AnyStruct? that optionally returns an identifier and also make the createEmptyVault() method include that second optional identifier by default.

Does all that make sense?

[joshuahannan]

Closing this in favor of #131 because I screwed up Git and I'm not sure how to fix it