0

I have a issue for batch transfer FA2 tokens (here). in certain cases, some FA2 tokens may not strictly adhere to the TZIP spec, especially the different names of annotations. For instance, while the TZIP specifies that the list should be called "txs," some tokens may use "tx" and some even omit the name but tzkt still identifies them as FA2 tokens. The problem is I cannot follow tutorial to do the thing like this for all FA2 tokens:

const transfer_params = [
    {
        from_: "tz1VSUr8wwNhLAzempoch5d6hLRiTh8Cjcjb",
        txs: [...]
    },
    {
        from_: "tz1aSkwEot3L2kmUvcoxzjMomb9mvBNuzFK6",
        txs: [...]
    }
]

Is there any solution for this?

1
  • hardcode conditionals for all possibilities
    – maelswarm
    Jun 13 at 9:29

1 Answer 1

0

These contracts shouldn’t be marked as FA2

(this one has tx instead of txs: https://ghostnet.tzkt.io/KT1H9hKtcqcMHuCoaisu8Qy7wutoUPFELcLm/entrypoints

this one has no txs : https://ghostnet.tzkt.io/KT1ACSHQLVEtuVPQsbjGFUtsPi9sUH2BEohX/entrypoints)

if they don’t follow the standard… The only thing to do is to handle edge cases manually when you target these specific contracts.

But in some sense these contracts are still compatible -- one can send the same Micheline values to them.

Theoretically one could disentangle the construction of the parameter from the specific annotated type of the contract -- e.g. one could use a single canonical annotated type to construct Micheline parameter values, or just hardcode this construction... I don't know how this would work in taquito though.

I wonder if there are any contracts which use the right annotations but the wrong structure, so that they appear compatible in JSON but are actually incompatible in Micheline..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.