Upgrade to FungibleToken contract coming on testnet and mainnet

🛠️ Builders Flow Protocol
1

We want to let you know that there will be an upgrade to the FungibleToken smart contract standard.

This upgrade adds a new method for receivers to specify the vault types that they can receive. This will not cause a breaking change to any existing deployed Fungible Token contracts or contracts that have types that implement FungibleToken.Receiver because it includes a default implementation for the method.

Expected dates to get the changes in effect is as follows:

  • CanaryNet: Wednesday, March 15th
  • Testnet: Thursday, March 16th

And assuming that the upgrades on the canary and testnet go well,

  • Mainnet: Wednesday, March 22 (This date may be delayed)

The FungibleToken code that will be used for the upgrade can be found in this PR.

Note - We are open to changing the timeline if the community provides feedback on the suggested change.

Why This Change is Happening

  • Adding type information to FungibleToken.Receiver capabilities has the potential to streamline the FT receiving process and minimize transaction failures.
  • The current FungibleToken.Receiver interface only contains the deposit method. It does not offer a clear-cut method for knowing the Vault types that a particular receiver can receive. To address this issue, getSupportedVaultTypes function was suggested. More details can be found in the FLIP

Action Required

  • For any custom receivers like TokenForwarding, FungibleTokenSwitchboard contract or any resource in other contracts that conforms FungibleToken.Receiver should define a getSupportedVaultTypes function to return an array of Vault types that the Receiver can take in the deposit() method. Until this change is made, custom receivers will only return an empty dictionary for this method ({}) as the return value.

The proposed interface features a default implementation of the getSupportedVaultTypes() function, ensuring that existing FTs will not encounter any breakage and will have a ready-made implementation available. This default implementation also eliminates the need for upgrading existing FTs, but they should still upgrade eventually for clarity purposes.

In this PR, the Flow team has also implemented the getSupportedVaultTypes function for the FungibleTokenSwitchboard and TokenForwarding contracts.
These contracts will be upgraded at the same time as FungibleToken on their respective networks.

If you have any questions regarding these changes, please ask in the PR comments, on Discord in the #developers channel, or reply here.

2 Likes
2

The contract has been upgraded on Canary to account 0xee82856bf20e2aa6

3

These contracts have been updated on testnet:

  • FungibleToken - 0x9a0766d93b6608b7
  • FungibleTokenSwitchboard - 0x9a0766d93b6608b7
  • TokenForwarding - 0x51ea0e37c27a1f1a
4

Put a comment there: https://github.com/onflow/flips/pull/69

5

I commented there [0], but also writing here: Why did we change the getSupportedVaultTypes signature to pub fun getSupportedVaultTypes(): {Type: Bool} from pub fun getSupportedVaultTypes(): [Type] ?

This is pretty ugly also does not make any sense.

[0] https://github.com/onflow/flow-ft/pull/127

6

These contracts have been updated on mainnet:

  • FungibleToken - 0xf233dcee88fe0abe
  • FungibleTokenSwitchboard - 0xf233dcee88fe0abe
  • TokenForwarding - 0xe544175ee0461c4b