Module name in GRPCv2?

Hi, Concordium Client ouputs the, what I believe to be, module name?

concordium-client module inspect 48682eecb17547b46a2a62fa05b1cbf95054be4804db99db8878db3766c04799
Module:       '48682eecb17547b46a2a62fa05b1cbf95054be4804db99db8878db3766c04799'
Wasm version: V0
- BictoryListing
    - buy
    - list
    - unlist
    - updatePrice

I’m referring to BictoryListing. How can I get this information using GRPCv2?
There’s GetModuleList, but that returns a list of ModuleRefs, and there’s GetModuleSource which returns the source code in bytes.

This information is extracted from the module source.

The client parses the module source (which is a Wasm standard byte format with an extra version header) and then extracts this information.

Ok, so if I decode the bytes, will I be able to read this name as well?


If you remove the first 8 bytes of the response then the rest is just a standard Wasm module.

If you parse that and look at the exported definitions you will find there

  • init_BictoryListing
  • BictoryListing.list

I hope you see the schema here.

1 Like

Is there a way to determine if a smart contract is a CIS2 contract?

Yes in the sense that a CIS2 contract should also be CIS0 contract. And this interface allows you to ask the contract whether it supports CIS2 or not.

I’m currently querying the GRPC v2 endpoint using GetModuleSource. Is the CIS-2 information not available there?

The interface you are referring is a call to the smart contract? If so, what would be the StandardIdentifier value for CIS-2?

The standard identifier is defined in the standard, CIS-2: Concordium Token Standard 2 - Interoperability Specifications

So for CIS-2 it is CIS-2 (see table at the top of that page).

The CIS-2 information is not available in the module itself, no. It is an isntance that satisfies CIS-2 or not, not the module itself.

1 Like