ZRC#2

[GreyEcologist]

Comment tracker for ZRC-2: #31

[as1ndu]

While operators are useful for use cases like custodial tokens. Some devs may prefer a non custodial token standard i.e one without operators?

[snowsledge]

@as1ndu Populating default_operators is optional. You can submit an empty List when initialising (deploying) the contract.

Also, the operator roles are appointed by the token_owner, and can be revoked anytime. This means that it also optional, and just an additional feature for token_owner to delegate some responsibility whenever necessary.

[snowsledge]

Hey all! We are changing up and revamping the ZRC-2 Fungible token standard to conform with the interface and events for XSGD contract (our first use-case 🎉 !). Please review the PR as linked below:
#35

Thank you! 🙏

[as1ndu]

Thanks for the clarifiaction, @evesnow91. It's a great way for the standard to support both custodial & none custodial tokens without having duplicate standards.

We could have an example folder that contains;

• init.json
• input_state.json
• input_blockchain.json
• input_message.json
• output.json
• FungibleToken.scilla

Under this example folder, may also be usage folder with samples how developers can interface with the contract both via EOA & contracts with the js library for example.

Users may not know how to properly construct the data structures in these json files during local dev.

This example folder might help speed up the dev learning curve by eliminating some mystery experienced by a dev unfamiliar with what's going on. It can also act as a great "Getting started with ZRC2" resource.

[snowsledge]

@as1ndu Xiaohuo (@renlulu) added the test cases in the JS script format:
#37

[csajedi]

Is the revamp completed or stable where it is now? I want to reconcile what's changed with the ZRC3 format. I've always believed these two contracts should have as similar an interface as possible, to make wallet and exchange integration easy.