cosmwasm/cosmwasm

WebAssembly Smart Contracts for the Cosmos SDK

The following packages are maintained here:

CosmWasm

.

Packages

Crate Usage Download Docs
cosmwasm-crypto Internal only
cosmwasm-derive Internal only
cosmwasm-schema Contract development
cosmwasm-std Contract development
cosmwasm-storage Contract development
cosmwasm-vm Host environments

Overview

To get that contract to interact with a system needs many moving parts. To get oriented, here is a list of the various components of the CosmWasm ecosystem:

Standard library:

This code is compiled into Wasm bytecode as part of the smart contract.

  • cosmwasm-std - A crate in this workspace. Provides the bindings and all imports needed to build a smart contract.
  • cosmwasm-storage - A crate in this workspace. This optional addition to cosmwasm-std includes convenience helpers for interacting with storage.

Building contracts:

  • cosmwasm-template - A starter-pack to get you quickly building your custom contract compatible with the cosmwasm system.
  • cosmwasm-examples - Some sample contracts (build with cosmwasm-template) for use and inspiration. Please submit your contract via PR.
  • cosmwasm-opt - A docker image and scripts to take your Rust code and produce the smallest possible Wasm output, deterministically. This is designed both for preparing contracts for deployment as well as validating that a given deployed contract is based on some given source code, allowing a similar contract verification algorithm as Etherscan.
  • serde-json-wasm - A custom json library, forked from serde-json-core. This provides an interface similar to serde-json, but without ay floating-point instructions (non-deterministic) and producing builds around 40% of the code size.

Executing contracts:

  • cosmwasm-vm - A crate in this workspace. Uses the wasmer engine to execute a given smart contract. Also contains code for gas metering, storing, and caching wasm artifacts.
  • go-cosmwasm - High-level go bindings to all the power inside cosmwasm-vm. Easily allows you to upload, instantiate and execute contracts, making use of all the optimizations and caching available inside cosmwasm-vm.
  • wasmd - A basic Cosmos SDK app to host WebAssembly smart contracts.

Ongoing work is currently tracked on this project board for all of the blockchain / contract work.

Creating a Smart Contract

You can see some examples of contracts under the contracts directory, which you can look at.

If you want to get started building you own, the simplest way is to go to the cosmwasm-template repository and follow the instructions. This will give you a simple contract along with tests, and a properly configured build environment. From there you can edit the code to add your desired logic and publish it as an independent repo.

API entry points

WebAssembly contracts are basically black boxes. The have no default entry points, and no access to the outside world by default. To make them useful, we need to add a few elements.

If you haven't worked with WebAssembly before, please read an overview on how to create imports and exports in general.

Exports

The required exports provided by the cosmwasm smart contract are:

extern "C" fn allocate(size: usize) -> u32;
extern "C" fn deallocate(pointer: u32);

extern "C" fn instantiate(env_ptr: u32, info_ptr: u32, msg_ptr: u32) -> u32;
extern "C" fn execute(env_ptr: u32, info_ptr: u32, msg_ptr: u32) -> u32;
extern "C" fn query(env_ptr: u32, msg_ptr: u32) -> u32;
extern "C" fn migrate(env_ptr: u32, info_ptr: u32, msg_ptr: u32) -> u32;

allocate/deallocate allow the host to manage data within the Wasm VM. If you're using Rust, you can implement them by simply re-exporting them from cosmwasm::exports. instantiate, execute and query must be defined by your contract.

Imports

The imports provided to give the contract access to the environment are:

// This interface will compile into required Wasm imports.
// A complete documentation those functions is available in the VM that provides them:
// https://github.com/CosmWasm/cosmwasm/blob/0.7/lib/vm/src/instance.rs#L43
//
extern "C" {
    fn db_read(key: u32) -> u32;
    fn db_write(key: u32, value: u32);
    fn db_remove(key: u32);

    // scan creates an iterator, which can be read by consecutive next() calls
    #[cfg(feature = "iterator")]
    fn db_scan(start: u32, end: u32, order: i32) -> u32;
    #[cfg(feature = "iterator")]
    fn db_next(iterator_id: u32) -> u32;

    fn addr_validate(source_ptr: u32) -> u32;
    fn addr_canonicalize(source: u32, destination: u32) -> u32;
    fn addr_humanize(source: u32, destination: u32) -> u32;

    /// Verifies message hashes against a signature with a public key, using the
    /// secp256k1 ECDSA parametrization.
    /// Returns 0 on verification success, 1 on verification failure, and values
    /// greater than 1 in case of error.
    fn secp256k1_verify(message_hash_ptr: u32, signature_ptr: u32, public_key_ptr: u32) -> u32;

    /// Verifies a message against a signature with a public key, using the
    /// ed25519 EdDSA scheme.
    /// Returns 0 on verification success, 1 on verification failure, and values
    /// greater than 1 in case of error.
    fn ed25519_verify(message_ptr: u32, signature_ptr: u32, public_key_ptr: u32) -> u32;

    /// Verifies a batch of messages against a batch of signatures and public keys, using the
    /// ed25519 EdDSA scheme.
    /// Returns 0 on verification success, 1 on verification failure, and values
    /// greater than 1 in case of error.
    fn ed25519_batch_verify(messages_ptr: u32, signatures_ptr: u32, public_keys_ptr: u32) -> u32;

    /// Executes a query on the chain (import). Not to be confused with the
    /// query export, which queries the state of the contract.
    fn query_chain(request: u32) -> u32;
}

(from imports.rs)

You could actually implement a WebAssembly module in any language, and as long as you implement these functions, it will be interoperable, given the JSON data passed around is the proper format.

Note that these *c_void pointers refers to a Region pointer, containing the offset and length of some Wasm memory, to allow for safe access between the caller and the contract:

/// Refers to some heap allocated data in Wasm.
/// A pointer to an instance of this can be returned over FFI boundaries.
///
/// This struct is crate internal since the VM defined the same type independently.
#[repr(C)]
pub struct Region {
    pub offset: u32,
    /// The number of bytes available in this region
    pub capacity: u32,
    /// The number of bytes used in this region
    pub length: u32,
}

(from memory.rs)

Implementing the Smart Contract

If you followed the instructions above, you should have a runable smart contract. You may notice that all of the Wasm exports are taken care of by lib.rs, which should shouldn't need to modify. What you need to do is simply look in contract.rs and implement instantiate and execute functions, defining your custom InstantiateMsg and ExecuteMsg structs for parsing your custom message types (as json):

pub fn instantiate<S: Storage, A: Api, Q: Querier>(
    deps: &mut Deps<S, A, Q>,
    env: Env,
    info: MessageInfo,
    msg: InstantiateMsg,
) -> StdResult<Response> {}

pub fn execute<S: Storage, A: Api, Q: Querier>(
    deps: &mut Deps<S, A, Q>,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, ContractError> { }

pub fn migrate<S: Storage, A: Api, Q: Querier>(
    deps: &mut Deps<S, A, Q>,
    env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, MigrateError> { }

pub fn query<S: Storage, A: Api, Q: Querier>(
    deps: &Deps<S, A, Q>,
    env: Env,
    msg: QueryMsg,
) -> StdResult<Binary> { }

The low-level c_read and c_write imports are nicely wrapped for you by a Storage implementation (which can be swapped out between real Wasm code and test code). This gives you a simple way to read and write data to a custom sub-database that this contract can safely write as it wants. It's up to you to determine which data you want to store here:

pub trait Storage {
    fn get(&self, key: &[u8]) -> Option<Vec<u8>>;
    fn set(&mut self, key: &[u8], value: &[u8]);
}

Testing the Smart Contract (rust)

For quick unit tests and useful error messages, it is often helpful to compile the code using native build system and then test all code except for the extern "C" functions (which should just be small wrappers around the real logic).

If you have non-trivial logic in the contract, please write tests using rust's standard tooling. If you run cargo test, it will compile into native code using the debug profile, and you get the normal test environment you know and love. Notably, you can add plenty of requirements to [dev-dependencies] in Cargo.toml and they will be available for your testing joy. As long as they are only used in #[cfg(test)] blocks, they will never make it into the (release) Wasm builds and have no overhead on the production artifact.

Note that for tests, you can use the MockStorage implementation which gives a generic in-memory hashtable in order to quickly test your logic. You can see a simple example how to write a test in our sample contract.

Testing the Smart Contract (wasm)

You may also want to ensure the compiled contract interacts with the environment properly. To do so, you will want to create a canonical release build of the <contract>.wasm file and then write tests in with the same VM tooling we will use in production. This is a bit more complicated but we added some tools to help in cosmwasm-vm which can be added as a dev-dependency.

You will need to first compile the contract using cargo wasm, then load this file in the integration tests. Take a look at the sample tests to see how to do this... it is often quite easy to port a unit test to an integration test.

Production Builds

The above build process (cargo wasm) works well to produce wasm output for testing. However, it is quite large, around 1.5 MB likely, and not suitable for posting to the blockchain. Furthermore, it is very helpful if we have reproducible build step so others can prove the on-chain wasm code was generated from the published rust code.

For that, we have a separate repo, rust-optimizer that provides a docker image for building. For more info, look at rust-optimizer README, but the quickstart guide is:

docker run --rm -v "$(pwd)":/code \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.11.4

It will output a highly size-optimized build as contract.wasm in $CODE. With our example contract, the size went down to 126kB (from 1.6MB from cargo wasm). If we didn't use serde-json, this would be much smaller still...

Benchmarking

You may want to compare how long the contract takes to run inside the Wasm VM compared to in native rust code, especially for computationally intensive code, like hashing or signature verification.

TODO add instructions

Developing

The ultimate auto-updating guide to building this project is the CI configuration in .circleci/config.yml.

For manually building this repo locally during development, here are a few commands. They assume you use a stable Rust version by default and have a nightly toolchain installed as well.

Workspace

./devtools/check_workspace.sh

Contracts

Step Description Command
1 fast checks, rebuilds lock files ./devtools/check_contracts_fast.sh
2 medium fast checks ./devtools/check_contracts_medium.sh
3 slower checks ./devtools/check_contracts_full.sh
Issues

Collection of the latest Issues

rashid3011

rashid3011

Comment Icon0

I am following the steps provided in this documentation -

wasmd keys add fred - here i am just creating a wallet named fred.

JSON=$(jq -n --arg addr $(wasmd keys show -a fred) '{"denom":"upebble","address":$addr}') && curl -X POST --header "Content-Type: application/json" --data "$JSON" #404 - Trying to get free tokens to interact.

RES=$(wasmd tx wasm store target/wasm32-unknown-unknown/release/voting.wasm --from fred $TXFLAG -y) - Trying to store the bytecode in chain.

but if do the echo $RES, i am getting this error

code: 13 codespace: sdk raw_log: 'insufficient fees; got: 1588usponge required: 15877upebble: insufficient fee' txhash: 96290B0DCB6452645EA655D8189CA2F7045B4958A024A104B98023BE96536263

what might be the issue?

rtviii

rtviii

Comment Icon4

Hi, This both a proposal and a question.

The problem: i'm trying to generate typescript bindings for cosmwasm contracts to speed up the development with our js package. In the ideal world, query and execute methods along with types would be transpiled directly from rust contract to typescript and that'd be the end of story. In the short term though it'd be really nice to have the clarity as to which generated .json type corresponds to a method's parameter and which -- to its return type.

Currently

In terms of the cw-template and in the most basic case this would work as follows:

yields the following schema

Desirable

With "param/return type method tags" or whatever this might instead look like the following:

yields the following schema

This is just one possible implementation, probably with lots of edge cases down the road -- i'd really love to hear what you guys think to this end. Perhaps this is better done as a custom schemars trait or a macro or a serde injection...

Implementation details aside, i think it'd be useful to have this additional reference/link between the schema files because the space of things that can be reconstructed (in typescript or other langs) from them right now is limited by its lack.

In general, i'd be very happy to contribute to any transpilation effort here.

Seeing as @webmaster128 wrote this bit -- would like to refer to your expertise on this. Please advise!

odeke-em

odeke-em

Comment Icon2

Howdy Cosmwasm! @orijtech is planning on rolling out an audit of Cosmwasm before the end of Q2 2022. In the audit we plan to do:

  • Correctness checks
  • Performance improvements if applicable
  • Cryptographic algorithm correctness and speed ups
  • Code style examinations

This issue serves as a promise and placeholder for us to publicly roll out the results of the audit. /cc @veorq @kirbyquerby from Orijtech Inc.

hashedone

hashedone

enhancement
Comment Icon3

Some messages (eg. WasmMsg::Execute) contains Binary field being actually a json message passed to something. Technically speaking this is chunk of bytes, practically speaking - it is [almost] always a json. After all, on test using MT I get a result like:

And obviously having an actuall message here would be very helpful. Creating custom debug impl which prints this binary as string would be probably easier to work with.

tk-o

tk-o

Comment Icon2

Question

How can I access info.funds within the reply handler, so I could include the funds param to cover a fee required while calling another smart contract?

Resources

  1. An example contract on Github
  2. Gitpod workspace — use cargo test transfers to see the failing reply call due to failing BroadcastTransfer handler.

Context

This is a minimal example enabling the following interaction:

  1. [Contract A: InitiateTransfer] A user initiates a transfer of their assets.
  2. [Contract B: LockFunds] The funds need to be locked within the contract.

    Here it's just dummy lock of already sent coins, but the real example covers also CW20, and CW721. That's why I created a call to another smart contract.

  3. [Contract A: reply] A reply to the LockFunds submessage needs to call another contract.
  4. [Contract C: BroadcastTransfer] This is an example of the another contract, which charges a fee in native coins

The question within the context

How can I access info.funds within the reply handler (step 3.), so I could include the fee while calling broadcast transfer handler (step 4.)?**

This call requires some fee in native coins, hence, I need to send a message with the funds param. This forwards required funds to cover the fee.

ferencdg

ferencdg

Comment Icon0

https://finder.terra.money/testnet/tx/A7660E316D1A2D7797E9489748F3010AD02091E2C45511DC5F3E33EE1709DF39 out of gas in location: Contract Execution; gasWanted: 10000000, gasUsed: 52791: out of gas

The transaction above reports that it ran out of gas before hitting the gas limit on testnet. I think the reporting is incorrect, and it did run out of gas. My guess is that if a transaction runs out of gas while processing a ReplyOn::Success message, then the report is incorrect.

lightyear15

lightyear15

Comment Icon7

I am experimenting with cosmos/ibc-go repository. I have my own version of the ibc-go repository that makes use of cosmwasm-enabled vm and smart contracts https://github.com/ChorusOne/ibc-go/tree/giulio/ics_28_wasm_client_rebase The VM is instantiated here while the calls to the contract are made here The contract itself has its entrypoints in here When I make the first call I get the error message as reported in the issue title

in go side the stacktrace brings me here. I tried to dig into the rust code and the only possible valid call to cache_err function that generates an error message that matches with the one I get is here Any idea of what I am doing wrong? thanks

ltchang2019

ltchang2019

Comment Icon3

Coming from Telegram chat with @webmaster128 (Feb 6th, 2022).

TL;DR, when replying to an executed submessage response, it would be useful to know whether the submessage call failed due to an error in the contract code or because it ran out of gas. Exposing the amount of gas used during submessage execution in the SubMsgExecutionResponse struct would be helpful. We could compare SubMsgExecutionResponse.gas_used to the SubMsg.gas_limit to help determine the cause of the failed submessage.

ethanfrey

ethanfrey

Comment Icon1

There are some new items we can support in a post-stargaze flags. Stuff that is present in the 0.43/0.44/0.45 sdk series. We can enable them indpendently under feature flags in a backwards compatible way:

  • Should we add support for "feegrant" to cosmwasm?
    • I think we should allow contracts to issue fee grants and revoke them (so a multisig can cover fees paid by members)
  • Should we add support for "authz" to cosmwasm?
    • I don't see the need for contracts to use it. Users can use it on basic accounts, contracts have other ways to do this (eg cw1)
  • Should we integrate IBC version negotiation, Support IBC version negotiation in contracts wasmvm#269?
    • This is first implemented in ibcv2 then improved after my feedback in ibcv3. I will wait til ibcv3 is tagged then support this one, by providing a backwards compatible enhancement to the ibc query types. If the contract doesn't use that, it defaults to current functionality - accept the version provided or error - no way to suggest a different one
  • Should we pass the IBC relayer address to the contract?
    • This requires ibcv2 and would be great to expose with a flag, not an option. If you require ibcv2 then it will always be present

These are my thoughts on them. Once we decide which features we want to cover, we can break out issues to define the API and implement.

playXE

playXE

Question ❓
Comment Icon31

Hello! I would like to use cosmwasm with C or any other compiled language. Is there any examples on how to do so? How I should for example compile smart contract using emcc? Maybe there's some example contracts written in C?

webmaster128

webmaster128

Comment Icon17

This is a new package with the following goals:

  • Versioning independent of cosmwasm-std, such that CosmWasm 0.16 and 1.0 developers can use the same library
  • Add features required by defi users and implement them in a correct and heavility tested way
  • Ensure a small footprint in terms of code size and performance
  • Ensure we don't pull in float operations

TODOs:

  • Implement Sum for all types consistently (https://github.com/CosmWasm/cosmwasm/pull/1187)
  • Create checked_multiply_ratio returning an Option allowing to recover from overflow
  • Implement floor/ceil for all decimals
  • Copy over Uint64, Uint128, Uint256, Uint512, Decimal and Decimal256
  • Let all the checked_* functions returns Option instead of StdResult for better stdard library complience and avoiding performance hit (see https://github.com/CosmWasm/cosmwasm/pull/1157).
  • Consider using macros to ensure API and implementation consistency across types
  • Signed integers
  • Signed decimals?
  • constify all the things
  • Find a consistent way to convert Uint64/Uin128 to the primitives u64 and u128. Are we happy with the current API?
  • Deprecate cosmwasm_std:{Decimal, Decimal256, Uint128, Uint256, Uint512, Uint64} and point the users to the math library
Feature Uint64 Uint128 Uint256 Uint512 Decimal Decimal256
const zero
const one ✅ (#1333) ✅ (#1333) ✅ (#1333) ✅ (#1333)
Sum
Add
AddAssign ✅ (#1253) ✅ (#1253)
Sub ✅ (#1242)
SubAssign ✅ (#1242) ✅ (#1253) ✅ (#1253)
Mul ✅ (#1245)
MulAssign ✅ (#1245) ✅ (#1255) ✅ (#1255)
Div ✅ (#1279) ✅ (#1279)
DivAssign ✅ (#1279) ✅ (#1279)
Rem
RemAssign ✅ (#1250) ✅ (#1250) ✅ (#1250) ✅ (#1250)
floor/ceil N/A N/A N/A N/A
pow ✅ (#1251) ✅ (#1251) ✅ (#1251)
checked_add
checked_sub
checked_rem
checked_mul
checked_div
checked_div_euclid
checked_pow
saturating_pow
checked_from_ratio N/A N/A N/A N/A ✅ (#1281) ✅ (#1281)
checked_multiply_ratio ✅ (#1280) ✅ (#1280) ✅ (#1280) N/A N/A N/A
A const constructor ✅ (#1256) ✅ (#1264) ✅ (#1264)
const is_zero ✅ (#1256) ✅ (#1256) ✅ (#1256) ✅ (#1256) ✅ (#1256) ✅ (#1256)
const fn atomics N/A N/A N/A N/A ✅ (#1256) ✅ (#1256)
const fn decimal_places N/A N/A N/A N/A ✅ (#1256) ✅ (#1256)
ueco-jb

ueco-jb

Question ❓
Comment Icon0

Currently QuerierWrapper returns all kind of SystemResults, SystemErrors and ContractResults on WasmQuery::ContractInfo {..} Basically case like this:

This probably can get simplified for end user.

ezekiiel

ezekiiel

Comment Icon2

Generating the starter cosmwasm contract by running:

Then, modifying the default code to add a Foo member with a usize parameter as follows:

Causes floating point instructions to be outputted when compiled which will prevent the contract from being uploaded. This is unexpected as using u64 instead will work. An example upload and error message:

The floating point instructions are generated by cargo wasm and not the rust optimizer so I don't think this is necessarily a bug with cosmwasm but it might be nice to somehow warn about this in either documentation or in the optimizer. Seems like a pretty subtle footgun. I'm happy to work on this if people have thoughts on how this might be resolved.

archseer

archseer

Comment Icon4

Seems to be a "feature" so raw Uint128 values can be treated as decimals.

This is very surprising, since the Div implementation doesn't follow this behavior, and Mul doesn't this either.

Similar to #1155 I propose the Decimal() constructor to be made public. The Mul implementation should be fixed, then the old behavior can be more explicit via decimal_val * Decimal(uint_val).

JakeHartnell

JakeHartnell

Comment Icon2

Was talking with @sgoya about a contract and it would be really nice to be able to query the distribution module like we can query the staking or bank module. Something like query_all_rewards or query_rewards similar to query_all_balances and query_balances in QuerierWrapper would be really useful.

Have some folks that would be willing to contribute to this if you could provide some pointers.

uint

uint

Comment Icon0

Currently, the profiler produces very unreliable timings for each code block.

It's my theory that things would improve with a better way to track specific executions - currently the take_measurement fn guesses that for a given block, the earliest started (and not yet finalized) measurement is the one we're trying to finalize. This might be unreliable, especially with any kind of concurrency going on.

What we could do during preprocessing is inject an extra local into every fn in the module and use it to track the id of the measurement we're currently taking - start_measurement would receive an execution id from host, wasm code at the beginning of the block would store that with local_set, and then the wasm code at the end of the same block would local_get the execution id and include it in take_measurement params.

The problem is I haven't yet found a clean way to inject locals. It can't be done with wasmer middleware and it seems tricky to achieve with walrus.

hashedone

hashedone

Comment Icon3

There are no primitives for signed calculations in cosmwasm std, and there are not even "wrapping" operations to simulate those behavior. Not a problem for Uint128, as it can be converted to native u128, and then to i128, but it doesn't help with (de)serialization.

Also Uint256 (and probably Uint128) is missing modulo operation which is useful to have.

Versions

Find the latest versions by id

v1.0.0 - May 14, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-rc.0 - May 05, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta8 - Apr 06, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.7 - Apr 06, 2022

Contracts builds missing because the CI failed. But the release is here :)

v1.0.0-beta7 - Mar 22, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.6 - Mar 21, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta6 - Mar 07, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.5 - Mar 07, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.4 - Feb 18, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta5 - Feb 08, 2022

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta4 - Dec 23, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta3 - Dec 14, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta2 - Oct 24, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-beta - Oct 11, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-soon2 - Oct 05, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v1.0.0-soon - Sep 10, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.2 - Sep 07, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.1 - Aug 31, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0+contracts - Aug 11, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0 - Aug 05, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0-rc6 - Aug 04, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0-rc5 - Jul 27, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0-rc4 - Jul 22, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0-rc3 - Jul 21, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.15.2 - Jul 21, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0-rc2 - Jul 20, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.15.1 - Jul 20, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.16.0-rc1 - Jul 19, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.15.0 - Jun 24, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

v0.15.0-alpha3 - Jun 23, 2021

Attached there are some build artifacts generated at this tag. Those are for development purposes only! Please use crates.io to find the packages of this release.

Information - Updated Jun 12, 2022

Stars: 655
Forks: 162
Issues: 56

Repositories & Extras

Generates PDF files directly in the browser with JavaScript and WASM (WebAssembly)

Idea here is to push all the work involved in creating a PDF to the browser side, instead of using precious server resources

Generates PDF files directly in the browser with JavaScript and WASM (WebAssembly)

This is a minimal example of the gcode-rs crate with web assembly

1) Install Rust, wasm-pack, and &quot;rollup&quot;

This is a minimal example of the gcode-rs crate with web assembly

The Wasm-Enabled, Elfin Allocator

The Rust and WebAssembly Working Group

The Wasm-Enabled, Elfin Allocator

AssemblyLift is a framework for building serverless applications powered by WebAssembly (WASM)

We're open to ideas and PRs! Please start a forking workflow to open a new Pull Request

AssemblyLift is a framework for building serverless applications powered by WebAssembly (WASM)

The wasm-to-rust tool allows compilation from WebAssembly to Rust source code

This is still very much a work in progress so not every WebAssembly binary successfully compiles to valid Rust source code

The wasm-to-rust tool allows compilation from WebAssembly to Rust source code

Collection of externs to interact with ethereum-like network

Parity Wasm Tutorial - a full fledged tutorial on how to write contracts in Webassembly for Kovan and other Wasm-enabled networks

Collection of externs to interact with ethereum-like network

Markdown editor built using Rust WebAssembly

Run wasm-pack build --target web to compile rust into wasm

Markdown editor built using Rust WebAssembly

rust-wasm-mandelbrot

WebAssembly でマンデルブロ集合を描きます

rust-wasm-mandelbrot
Facebook Instagram Twitter GitHub Dribbble
Privacy