search

o1-labs / rfcs

RFCs for everything O(1) Labs
4 stars 4 forks source link

Fungible Token Standard #44

Closed garwalsh closed 3 months ago

garwalsh commented 7 months ago

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 commented 7 months ago

PR that implements and describes new TokenContract API: https://github.com/o1-labs/o1js/pull/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: https://github.com/o1-labs/o1js/pull/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 commented 7 months ago

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 commented 3 months ago

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