Fungible Token Standard

[garwalsh]

Will build on: https://forums.minaprotocol.com/t/draft-fungible-token-standard-zkapps/6142

In light of the work to generalise the base token here:
https://app.zenhub.com/workspaces/sdk-6130fedb3b0fc600123d8796/issues/gh/o1-labs/o1js/1274

[mitschabaude]

PR that implements and describes new TokenContract API: o1-labs/o1js#1384

IMO the Approvable and Transferable interfaces, proposed for the token standard here should be changed to exactly match the new TokenContract

Here I proposed that we remove the Callback API, which is done by now: o1-labs/o1js#1402
So the token standard should also no longer rely on that API, but on what the TokenContract does: accepting an AccountUpdateForest which contains all the account updates that it has to approve, in one structure

I don't have strong opinions on some of the "viewable" APIs in the standard

I don't think the Pausable API proposed there is needed.

[mitschabaude]

I think it would also be nice if the token standard RFC could demonstrate that the proposed token standard is sufficient to cover all important token use cases.

I've written up an analysis of a tricky use case, a DEX which allows smart contracts to interact with it, here: https://o1-labs.slack.com/archives/C062EFYE2D7/p1706872456552659
The conclusion of that thread it's that it's somewhat hard to implement the DEX use case, but possible using offchain state, and even easier if the account update limit was raised

[Trivo25]

see https://app.zenhub.com/workspaces/sdk-6130fedb3b0fc600123d8796/issues/zh/102