Skip to main content
Learn how to integrate the 08-wasm module in a chain binary and about the recommended approaches depending on whether the x/wasm module is already used in the chain. The following document only applies for Cosmos SDK chains.

Importing the 08-wasm module

08-wasm has no stable releases yet. To use it, you need to import the git commit that contains the module with the compatible versions of ibc-go and wasmvm. To do so, run the following command with the desired git commit in your project:

app.go setup

The sample code below shows the relevant integration points in app.go required to set up the 08-wasm module in a chain binary. Since 08-wasm is a light client module itself, please check out as well the section Integrating light clients for more information:

Keeper instantiation

When it comes to instantiating 08-wasm’s keeper, there are two recommended ways of doing it. Choosing one or the other will depend on whether the chain already integrates x/wasm or not.

If x/wasm is present

If the chain where the module is integrated uses x/wasm then we recommend that both 08-wasm and x/wasm share the same Wasm VM instance. Having two separate Wasm VM instances is still possible, but care should be taken to make sure that both instances do not share the directory when the VM stores blobs and various caches, otherwise unexpected behaviour is likely to happen (from x/wasm v0.51 and 08-wasm v0.2.0+ibc-go-v8.3-wasmvm-v2.0 this will be forbidden anyway, since wasmvm v2.0.0 and above will not allow two different Wasm VM instances to shared the same data folder). In order to share the Wasm VM instance, please follow the guideline below. Please note that this requires x/wasm v0.41 or above. The code to set this up would look something like this:

If x/wasm is not present

If the chain does not use x/wasm, even though it is still possible to use the method above from the previous section (e.g. instantiating a Wasm VM in app.go an pass it to 08-wasm’s NewKeeperWithVM constructor function, since there would be no need in this case to share the Wasm VM instance with another module, you can use the NewKeeperWithConfig constructor function and provide the Wasm VM configuration parameters of your choice instead. A Wasm VM instance will be created in NewKeeperWithConfig. The parameters that can set are: Another configuration parameter of the Wasm VM is the contract memory limit (in MiB), which is set to 32, following the example of wasmd. This parameter is not configurable by users of 08-wasm. The following sample code shows how the keeper would be constructed using this method:
Check out also the WasmConfig type definition for more information on each of the configurable parameters. Some parameters allow node-level configurations. There is additionally the function DefaultWasmConfig available that returns a configuration with the default values.

Options

The 08-wasm module comes with an options API inspired by the one in x/wasm. Currently the only option available is the WithQueryPlugins option, which allows registration of custom query plugins for the 08-wasm module. The use of this API is optional and it is only required if the chain wants to register custom query plugins for the 08-wasm module.

WithQueryPlugins

By default, the 08-wasm module does not configure any querier options for light client contracts. However, it is possible to register custom query plugins for QueryRequest::Custom and QueryRequest::Stargate. Assuming that the keeper is not yet instantiated, the following sample code shows how to register query plugins for the 08-wasm module. We first construct a QueryPlugins object with the desired query plugins:
Note that the Stargate querier appends the user defined accept list of query routes to a default list defined by the 08-wasm module. The defaultAcceptList defines a single query route: "/ibc.core.client.v1.Query/VerifyMembership". This allows for light client smart contracts to delegate parts of their workflow to other light clients for auxiliary proof verification. For example, proof of inclusion of block and tx data by a data availability provider.
You may leave any of the fields in the QueryPlugins object as nil if you do not want to register a query plugin for that query type. Then, we pass the QueryPlugins object to the WithQueryPlugins option:
Finally, we pass the option to the NewKeeperWithConfig or NewKeeperWithVM constructor function during Keeper instantiation:

Updating AllowedClients

If the chain’s 02-client submodule parameter AllowedClients contains the single wildcard "*" element, then it is not necessary to do anything in order to allow the creation of 08-wasm clients. However, if the parameter contains a list of client types (e.g. ["06-solomachine", "07-tendermint"]), then in order to use the 08-wasm module chains must update the AllowedClients parameter of core IBC. This can be configured directly in the application upgrade handler with the sample code below:
Or alternatively the parameter can be updated via a governance proposal (see at the bottom of section Creating clients for an example of how to do this).

Adding the module to the store

As part of the upgrade migration you must also add the module to the upgrades store.

Adding snapshot support

In order to use the 08-wasm module chains are required to register the WasmSnapshotter extension in the snapshot manager. This snapshotter takes care of persisting the external state, in the form of contract code, of the Wasm VM instance to disk when the chain is snapshotted. This code should be placed in NewSimApp function in app.go.

Pin byte codes at start

Wasm byte codes should be pinned to the WasmVM cache on every application start, therefore this code should be placed in NewSimApp function in app.go.