There are inconsistent behaviors of some procedures in ZRC1.
e.g.

• 🟢 IsTokenOwner throws an error if not a token owner
• 🟢 IsMinter throws an error if not a minter
• 🔴 IsSelf throws an error if self
• 🔴 IsTokenExists throws an error if the token exists

This inconsistency can be confusing and error-prone.

Therefore the following can be

• 🔴 IsSelf throws an error if self
• 🔴 IsTokenExists throws an error if the token exists

changed to

• 🟢 IsNotSelf throws an error if self
• 🟢 IsTokenNotFound throws an error if the token exists

help me create my own coin with zilliqa.

Comment tracker for ZRC 1.

As of now the reference-contracts directory looks like this:

.
├── FungibleToken-Mintable.scilla
├── FungibleToken-Operator.scilla
├── FungibleToken.scilla
├── MetaFungibleToken.scilla
├── multisig_wallet.scilla
├── nonfungible-token.scilla
├── style-guide.md
└── zrc6.scilla

and it's not clear what, for instance, nonfungible-token.scilla's ZRC number is.

One possible proposal could be to prepend all the contract names with their ZRC index like so:

.
├── zrc2_FungibleToken-Mintable.scilla
├── zrc2_FungibleToken-Operator.scilla
├── zrc2_FungibleToken.scilla
├── zrc3_MetaFungibleToken.scilla
├── zrc4_Multisig-Wallet.scilla
├── zrc1_NonFungibleToken.scilla
├── style-guide.md
└── zrc6_NonFungibleToken.scilla

We could use a guide to patterns/antipatterns in Scilla.

Examples:

• Don't use ping-pong between contracts. Instead, attempt to complete everything in one contract before invoking transitions on the other contract. If the second contract for some reason discovers a problem, then throw an exception (or otherwise cause an execution error), so that the entire chain of invocations are rolled back.

• Avoid using the size operation, as it requires reading the entire map from the state. Instead, manually maintain a size counter, and use a dedicated procedure to update the map and the counter together, so that they are always kept in sync.

Comment tracker for ZRC-2: #31

$ cd example/zrc2
$ node transfer.js 
Your account address is:
0x501A70ffEAA3F31C1caccE3479e74713546BAA44
undefined

Why this undefined?

If I add console.log(JSON.stringify(callTx, null, 4)); after await contract.call(...), I get:

{
    "code": "",
    "data": "{\"_tag\":\"Transfer\",\"params\":[{\"vname\":\"to\",\"type\":\"ByStr20\",\"value\":\"0xBFe2445408C51CD8Ee6727541195b02c891109ee\"},{\"vname\":\"amount\",\"type\":\"Uint128\",\"value\":\"100\"}]}",
    "version": 21823489,
    "toAddr": "0x509aE6e5D91CEE3c6571Dcd04aa08288a29D563A",
    "nonce": 130,
    "pubKey": "03043f88a66a8d79df51c17b7297239b613db510abb04dddc072f0aac5666e716e",
    "amount": "0",
    "signature": "8dc1069bf5b4473ca255f393f026b10c55b705d8fd1859a4149983b4686d078866499a9a43e66df038d2defb35328a1f5eba5da97ac3908fa093ff83c5f50460",
    "gasPrice": "3b9aca00",
    "gasLimit": {
        "low": 10000,
        "high": 0,
        "unsigned": false
    },
    "provider": {
        "middleware": {
            "request": {},
            "response": {}
        },
        "nodeURL": "https://dev-api.zilliqa.com",
        "reqMiddleware": {},
        "resMiddleware": {}
    },
    "status": 3,
    "toDS": false,
    "blockConfirmation": 0,
    "eventEmitter": {
        "handlers": {},
        "emitter": {},
        "promise": {}
    }
}

Does "status": 3 mean "Consensus failure in network"? What is it? Why? How to make it work?

Lines 39-41 in the ZRC-2 reference contract (fungible token) look like they should be removed , see

(* Dummy user-defined ADT *)
type Unit =
| Unit

This ADT Unit is not used anywhere.

Comment tracker for ZRC#0

Comment Tracker for ZRC#3

ZRC#3 extends ZRC#2 to enable a more equitable check-teller transaction pattern, as an alternative or supplement to the omnipotent operator.

For example when running ./ci_scilla_type_check.sh and a .scilla file has type errors, the docker removal cleanup does not run. This is slightly more annoying for the script than the npm test because the docker container is not named.

For example, the ZRC-1 and ZRC-2 contracts share the same name for a callback, namely TransferSuccessCallBack.

This prevents using both of these ZRCs in one user contract because that forces the user to have two TransferSuccessCallBack transitions with different type signatures.

In this message, recipient is token recipient. Therefore, recipient : _sender should be recipient: to.

  msg_to_sender = { _tag : "MintCallBack"; _recipient : _sender; _amount : Uint128 0;
                    recipient : _sender; token_id : token_id; token_uri : token_uri };

https://github.com/Zilliqa/ZRC/blob/master/reference/nonfungible-token.scilla#L384-L385

By having the guard clause RequireNotPaused in procedures, batch operations result in multiple (wasted) calls to RequireNotPaused. When operations occur in large batches, this is a waste of gas fees and network efficiency.

Procedures affected by this:

• MintToken
• BurnToken
• TransferToken