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

Although this is an old question, the recent AMA talked about ccdscan being able to display the source code for smart contracts. Any pointers how I would go about making this visible? The decoded wasm module does indeed have code, but I’ve been unable to decipher this into something readable.

I don’t know exactly waht was meant in the AMA, but we are working on adding “reproducible build” setup to cargo-concordium.

This will build a contract in a way that you can check that it is coming from a specific rust source, and embed metadata about this into the module on the chain.

That will eventually then be exposed on CCDScan.

Ah ok, so nothing that can be done with the current toolset. I’ll check updates on this to see if and when I can upgrade my smart contract / module display to include this. Thank you.