RESEARCH: WASM in the Cosmos SDK

I can think of a number of use cases(Staking derivatives, asset issuance, cross chain collateralization etc) where it on chain code would be a helpful.

WASM seems like a great target for some SDK applications for on chain code.

One option is Perlin’s Life golang Wasm engine:

Concerns are mostly that it doesn’t seem to have good support for Host functions to inject into the runtime environment. This pretty crucial if you want your wasm code to actually interact with the rest of the Cosmos SDK.

Wasmer has a C api that looks like it would wrappable in go and could be a nicer path to golang integration.


One downside of Wasmer is that host functions are either going to trampolines in C or rust to golang.

I would like to echo support for this being a focus. Lack of on-chain WASM support is a major downside of the current SDK, and is something thats crucially needed. Its rather trivial to integrate SNARK verifier’s (and the examples you provided). This is also something being explicitly built out for Polkadot, Eth, DFinity, so perhaps there is some potential for standardization that could happen on how WASM code interacts with the blockchain for state. (Or is there a clear way to do this in WASM, I haven’t looked too much into it?)


The typical way to interface on chain code with state is via host functions. For instance, a Host function that provides the ability to query data from the multistore. Serialization and deserialization of data from inside the WASM engine is an interesting challenge.

1 Like

WASM support would be great!
Rust amino should help with serialization/deserialization, right? AFAIK it is almost production ready, right?

One of the big open questions in my in integrating WASM into the SDK is how to serialize and deserialize golang structs into the WASM virtual machine.

Oasis Lab’s made has a proposal I think we can align strongly with.


We have just released a Go integration for the Wasmer WebAssembly runtime :tada:

It’s in average between 50 and 100x faster than Life.

We also published an article analyzing the API and comparing it with Life/Wagon:

I’d love to hear your feedback! :slight_smile:


Rust Amino is almost done?

Hey @syrusakbary I am super interested in adding support for wasmer in the Cosmos SDK.

I think we will make a demo relatively soon.

1 Like

Awesome! Let me know if we can help in any way :slight_smile:

PS: feel free to send me an email to if you have feedback/suggestions so we can follow up in a faster way

One thing that seems exciting about the wasmer interface is the ability to move back and forth between the wasm memory space and golang memory space.

This enables much more complex apis between the go world and the wasm world.

In wasi interface proposed by oasis, the interface is largely confined to serialized data into $HOME and STDIN/STDOUT.

In the wasmer interface, the interface is defined by the cgo api.

A winning team from HackAtom Berlin integrated WASMER into the SDK.

See diff below

1 Like

any more infomation?

I worked on this, unfortunately I do not personally have time to continue on it, but one of my teammates will be. Some points of interest:

  • Wasmer does not have gas metering. Another interpreter, Life, does. But Wasmer was easier to integrate in the short time available.
  • Passing data and calling functions back and forth across the go-wasm boundary was a pretty insane experience, but doable. We were able to get it into a pretty clean api by passing everything as JSON.
  • That brings me to the next point- we used Rust’s serde JSON library because it is usually the standard choice. This is the fastest JSON library in existence because it uses macros to generate custom code for each data structure. But this bloated out the contract size quite a bit, to 50-100kb for a very trivial contract. This would be prohibitively expensive to deploy.
  • There are a lot of other things in that were not really optimized for the miniscule bytecode sizes that would make deploying custom contracts viable. A good course of action would be to give contract developers a standard set of dynamically linked libraries instead of having everything compile into the deployed contract.
  • But if you just want to make a cleaner/well-encapsulated alternative to Cosmos SDK, or maybe to port over Substrate or something, you don’t need tiny bytecode sizes. If the logic is being written in WASM by the developers of the chain, of course they don’t care about the size of the bytecode.