Beaker helps simplify CosmWasm development workflow.

Last update: Dec 29, 2022

Related tags

Overview

Beaker

Beaker makes it easy to scaffold a new cosmwasm app, with all of the dependencies for osmosis hooked up, interactive console, and a sample front-end at the ready.

Getting Started

Installation
Prerequisites
Scaffolding your new dapp project
Your first CosmWasm contract with Beaker
Deploy contract on LocalOsmosis
Contract Upgrade
Signers
Console
Typescript SDK Generation
Frontend

Reference

Getting Started

This section is intended to give you an introduction to Beaker, for more detailed reference, you can find them here.

Prerequisites

Rust for building cosmwasm contract
Docker for running wasm rust-optimizer and spinning up LocalOsmosis
Node for frontend related stuffs and beaker-console

Installation

Beaker is available via cargo which is a rust toolchain. Once cargo is ready on your machine, run:

cargo install -f beaker # `-f` flag for up-to-date version

Now beaker is ready to use!

Scaffolding your new dapp project

In the directory you want your project to reside, run:

beaker new counter-dapp

This will generate new directory called counter-dapp which, by default, come from this template.

So what's in the template? Let's have a look...

.
├── frontend
├── contracts
├── Cargo.toml
├── Beaker.toml
├── .gitignore
└── .beaker

`frontend` and `contracts`

These should be self explanatory, it's where frontend and contracts are stored. And as you might be able to guess from the name, one project can contain multiple contracts.

`Cargo.toml`

There is a Cargo.toml here which specifies cargo workspace.

[workspace]

members = [
  'contracts/*',
]

[profile.release]
...

All the crates (rust packages) in contracts directory are included, with unified release profile. With this, when we have to optimize multiple contracts deterministically, we can do that with ease (see Contracts as Workspace Members section in rust-optimizer).

`Beaker.toml`

This is our configuration file, you can find more information about it here.

`.beaker`

Last but not least, .beaker which is the most unusal part. It contains 2 files:

├── state.json
└── state.local.json

These 2 files has similar functionality, which are containing beaker related state such as address, code-id, label for each contract on each network for later use.

While state.json is there for mainnet and testnet state. state.local.json is intended to use locally and being gitignored since its state will not make any sense on other's machine.

And I don't think we have to explain about .gitignore don't we?

Your first CosmWasm contract with Beaker

After that we can create new contract (the command uses template from cw-template)

cd counter-dapp
beaker wasm new counter

Now your new contract will be avaiable on contracts/counter.

If you want to use other contract template, you can change the configuration, for example:

# Beaker.toml

[wasm]
template_repo = "https://github.com/osmosis-labs/cw-tpl-osmosis.git"

Deploy contract on LocalOsmosis

LocalOsmosis, as it's name suggest, is Osmosis for local development. In the upcoming release, Beaker will have more complete integration with LocalOsmosis, it has to be installed and run separately.

You can install from source by following the instruction at osmosis-labs/LocalOsmosis, or use the official installer and select option 3:

curl -sL https://get.osmosis.zone/install > i.py && python3 i.py

After that, counter contract can be deployed (build + store-code + instantiate) using the following command:

beaker wasm deploy counter --signer-account test1 --no-wasm-opt --raw '{ "count": 0 }'

What's happending here equivalent to the following command sequence:

# build .wasm file
# stored in `target/wasm32-unknown-unknown/release/<CONTRACT_NAME>.wasm`
# `--no-wasm-opt` is suitable for development, explained below
beaker wasm build --no-wasm-opt

# read .wasm in `target/wasm32-unknown-unknown/release/<CONTRACT_NAME>.wasm` due to `--no-wasm-opt` flag
# use `--signer-account test1` which is predefined.
# The list of all predefined accounts are here: https://github.com/osmosis-labs/LocalOsmosis#accounts
# `code-id` is stored in the beaker state, local by default
beaker wasm store-code counter --signer-account test1 --no-wasm-opt

# instantiate counter contract
# with instantiate msg: '{ "count": 0 }'
beaker wasm instanitate counter --signer-account test1 --raw '{ "count": 0 }'

The flag --no-wasm-opt is skipping rust-optimizer for faster development iteration.

For testnet/mainnet deployment, use:

beaker wasm deploy counter --signer-account <ACCOUNT> --raw '{ "count": 0 }' --network testnet
beaker wasm deploy counter --signer-account <ACCOUNT> --raw '{ "count": 0 }' --network mainnet

Instantiate message can be stored for later use:

mkdir contracts/counter/instantiate-msgs
echo '{ "count": 0 }' > contracts/counter/instantiate-msgs/default.json
beaker wasm deploy counter --signer-account test1 --no-wasm-opt

You can find references for beaker wasm subcommand here.

Contract Upgrade

Contract upgrade in CosmWasm goes through the following steps:

store new code on to the chain
broadcast migrate msg, targeting the contract address that wanted to be upgraded with the newly stored code

To make a contract migratable, the contract needs to have proper entrypoint and admin designated.

To create the contract entrypoint for migration, first, define MigrateMsg in msg.rs, this could have any information you want to pass for migration.

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct MigrateMsg {}

With MigrateMsg defined we need to update contract.rs. First update the import from crate::msg to include MigrateMsg:

use crate::msg::{CountResponse, ExecuteMsg, InstantiateMsg, QueryMsg, MigrateMsg};

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn migrate(_deps: DepsMut, _env: Env, _msg: MigrateMsg) -> StdResult<Response> {
    // perform state update or anything neccessary for the migration
    Ok(Response::default())
}

Now deploy the contract with admin assigned

# `--admin signer` use signer address (test1's address in this case) as designated admin
# raw address could be passed in as well
beaker wasm deploy counter --signer-account test1 --no-wasm-opt --raw '{ "count": 0 }' --admin signer

Now try to change the execute logic a bit to see if the upgrade works:

pub fn try_increment(deps: DepsMut) -> Result<Response, ContractError> {
    STATE.update(deps.storage, |mut state| -> Result<_, ContractError> {
        state.count += 1000000000; // 1 -> 1000000000
        Ok(state)
    })?;

    Ok(Response::new().add_attribute("method", "try_increment"))
}

With admin as test1, only test1 can upgrade the contract

beaker wasm upgrade counter --signer-account test1 --raw '{}' --no-wasm-opt

Similar to deploy, upgrade is basiaclly running sequences of commands behind the scene:

beaker wasm build --no-wasm-opt
beaker wasm store-code counter --signer-account test1 --no-wasm-opt
beaker wasm migrate counter --signer-account test1 --raw '{}'

And, like before, --no-wasm-opt only means for developement. For mainnet, use:

beaker wasm upgrade counter --signer-account test1 --raw '{}' --network mainnet

Migrate message can be stored for later use:

mkdir contracts/counter/migrate-msgs
echo '{}' > contracts/counter/migrate-msgs/default.json
beaker wasm upgrade counter --signer-account test1 --no-wasm-opt

You can find more information about their options here.

Signers

Whenever you run command that requires signing transactions, there are 3 options you can reference your private keys:

--signer-account input of this option refer to the accounts defined in the config file, which is not encrypted, so it should be used only for testing
--signer-mnemonic input of this option is the raw mnemonic string to construct a signer
--signer-private-key input of this option is the same as --signer-mnemonic except it expects base64 encoded private key
--signer-keyring use the OS secure store as backend to securely store your key. To manage them, you can find more information here.

Console

After deployed, you can play with the deployed contract using:

beaker console

It might prompt you like the following:

? Project's Typescript SDK seems to be missing, would you like to generate?

Press enter to proceed for now, and we will discuss about it in detail in the Typescript SDK Generation section.

This will launch custom node repl, where contract, account are available. contract contains deployed contract. account contains pre-defined accounts in localosmosis.

So you can interact with the recently deployed contract like this:

await contract.counter.signer(account.test1).execute({ increment: {} });
await contract.counter.query({ get_count: {} });

You can find avaialable methods for the aforementioned instances here:

You can remove contract and/or account namespace by changing config.

# Beaker.toml

[console]
account_namespace = false
contract_namespace = false

await counter.signer(test1).execute({ increment: {} });
await counter.query({ get_count: {} });

With the Typescript SDK which was previously mentioned, it is used to extend the Contract instance with method generated ftom execute and query messages. For example:

await counter.getCount()

sc = counter.signer(test1) // create signing client for `counter` with `test1`

await sc.increment()
await sc.getCount()

With this, it's more convenient than the previous interaction method since you can use tab completion for the methods as well.

Beaker console is also allowed to deploy contract, so that you don't another terminal tab to do so.

.deploy counter -- --signer-account test1 --raw '{ "count": 999 }'

.build, .storeCode, .instantiate commands are also available and has the same options as Beaker cli command, except that --no-wasm-opt are in by default since it is being intended to use in the development phase.

.help to see all avaiable commands.

Apart from that, in the console, you can access Beaker's state, configuration and sdk from state, conf and sdk variables accordingly.

Typescript SDK Generation

Beaker leverage cosmwasm-typescript-gen to generate typescript client for cosmwasm contract. By default, Beaker's template prepare ts/sdk directory where typescript compiler and bundler are setup, so the generated client definition could be used by beaker-console, frontend or published as library for others to use.

To generate sdk for contract, run

beaker wasm ts-gen counter # replace `counter` with any of contract name

With this a package is avaiable in ts/sdk with name <project-name>-sdk which can be used by any node / js / ts project.

Let's try adding multiply method to our contract and see how this works.

// msg.rs

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(rename_all = "snake_case")]
pub enum ExecuteMsg {
    Increment {},
    Multiply { times: i32 }, // [1] add this enum variant
    Reset { count: i32 },
}

// contract.rs

#[cfg_attr(not(feature = "library"), entry_point)]
pub fn execute(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, ContractError> {
    match msg {
        ExecuteMsg::Increment {} => try_increment(deps),
        ExecuteMsg::Multiply { times } => try_multiply(deps, times), // [2] add this match arm
        ExecuteMsg::Reset { count } => try_reset(deps, info, count),
    }
}

// [3] add this function
fn try_multiply(deps: DepsMut, times: i32) -> Result<Response, ContractError> {
    STATE.update(deps.storage, |mut state| -> Result<_, ContractError> {
        state.count *= times;
        Ok(state)
    })?;

    Ok(Response::new().add_attribute("method", "try_multiply"))
}

Then redeploy the contract:

beaker wasm deploy counter --signer-account test1 --no-wasm-opt --raw '{ "count": 0 }'

Then regenerate counter's client

beaker wasm ts-gen counter

Now we can test it out in the beaker console

sc = counter.signer(test1)

await sc.increment()
await sc.getCount()
// => { count: 1 }

await sc.multiply({ times: 2 })
await sc.getCount()
// => { count: 2 }

await sc.multiply({ times: 10 })
await sc.getCount()
// => { count: 20 }

sc is an instance of CounterContract which you can find it in ts/sdk/src/contracts/CounterContract.ts.

Frontend

Beaker project template also come with frontend template. But in order to interact with it you need:

Keplr installed
Keplr chain setup for LocalOsmosis
Add test account to Keplr
- Add account via mnemonic in Keplr
- List of test accounts and its mnemonics in LocalOsmosis

Now we are good to go! Let's dive in

cd frontend
yarn && yarn dev

Then open http://localhost:3000/ in the browser.

In frontend directory, you will see that .beaker is in here. It is actually symlinked to the one in the root so that frontend code can access beaker state.

License

The crates in this repository are licensed under either of the following licenses, at your discretion.

Apache License Version 2.0 (LICENSE-APACHE or apache.org license link)
MIT license (LICENSE-MIT or opensource.org license link)

Unless you explicitly state otherwise, any contribution submitted for inclusion in this library by you shall be dual licensed as above (as defined in the Apache v2 License), without any additional terms or conditions.

Comments

[Research] CosmWasm path to production (mainnet)
This issue is for tracking the clarification of the path to production (mainnet) for CosmWasm. Since Osmosis implements permissioned CosmWasm, See what are the steps to take, who is involved in order to have clear understanding on what Beaker should support, who else needs to be involved, what system needs to eventually be upgraded and later we can have a clear documentation for the dapps developer.

The following is my attempt to flesh out the understandings along with :question: questions and :bulb: ideas.

Grouping for wasm gov proposal types

According to the wasm gov docs, there are additional proposal types for wasm gov. Grouping by their functions for further reference:

Deployment and Migration (**main focus for this issue)

StoreCodeProposal

InstantiateContractProposal

MigrateContractProposal

Code Permission

UpdateAdminProposal

ClearAdminProposal

UpdateInstantiateConfigProposal

Code Pinning

PinCodes

UnpinCodes

Execution

SudoContractProposal

ExecuteContractProposal

[❓ 1] on mainnet, which of the above are required to be execute through governance? 📝 Answer 1 by @czarcas7ic

[💡 1] Same wasm gov configuration as mainnet for testnet (stagenet?) and/or localosmosis variation would be ideal for testing. @czarcas7ic @nicolaslara

For Code Pinning and Execution, if the [❓ 1] is clear, it doesn't seem to be important for this issue. Let's move on to the main topic.

Deployment and migration

StoreCode requirements

There was a discussion with @ValarDragon @daniel-farina about hash verification and contract-list

#56

This is what I imagine would happen if there is a need to store code:

graph TD StoreCode[Submit `StoreCodeProposal`] SubmitRepo[Submit source and metadata] Val{validate} Voting[Gov Voting] StoreCode == wasm byte code ==> Val SubmitRepo == source code & build metadata ==> Val Val -->|passed| Voting

[❓ 2] should we require hash validation before triggering the voting period of the proposal? if so it sounds like a chain upgrade, what else could be an alternative? @ValarDragon

📝 Answer 2 by @daniel-farina

The StoreCodeProposal already contains wasm byte code, one can get that by querying the proposal. For Submit source and metadata this would trigger a question:

[❓ 3] In what format should we store the source reference & build metadata (for deterministic build)? 📝 Answer 3 by @daniel-farina

[💡 3] Specific & special region in the proposal description for source reference & build metadata

[❓ 4] Do we require public git repository? or just upload an archive somewhere? 📝 Answer 4 by @daniel-farina

[❓ 5] Where does contract list update sits in the process? 📝 Answer 5 by @daniel-farina

Deployment

This is normally a 2 steps process of StoreCode -> InitiateContract, but common pattern of a dapp has the following:

StoreCode -> InitiateContract tends to happen sequentially.

A dapp can have more than 1 code/contract and could be depending on each other

The following graph is a general execution plan for a deploying a dapp.

[💡 6] Note that this structure is dependency graph so the process as code @daniel-farina mentioned in #48 could incorporate the whole flow like what terraform does.

[❓ 7] Is it possible / how hard it is to have multiple related proposals (like in the process above) to go through the gov together as bundled proposal? Does it make sense to do so? I can imagine how this could simplify the flow... @ValarDragon @sunnya97

Migration

The following graph is a general execution plan for a migrating multiple contract for a dapp. It shares the same question as for the deployment.

Lastly:

[❓ 8] Will we use https://commonwealth.im/osmosis/ for wasm governance? 📝 Answer 8 by @daniel-farina

Let me know your thoughts.
question ⚙️ task
opened by iboss-ptk 12
beaker cli broken after building osmosis binary
Hello all.

I am trying to run testnet on my local machine. So I cloned osmosis-labs/osmosis repository and moved to this commit(https://github.com/osmosis-labs/osmosis/commit/101f3f7a5dd3959a09800fcae334e257a2f373ab). (In order to test estimateSwap feature)

After running local network, I tried to deploy my smart contract which developed with CosmWasm. But there was an issue with beaker cli like below.

reproduce environment:

beaker 0.0.8

go 1.18.1

ubuntu 21 w/ WSL

step to reproduce

install beaker and run beaker console -> it works fine.

git clone https://github.com/osmosis-labs/osmosis and checkout commit (https://github.com/osmosis-labs/osmosis/commit/101f3f7a5dd3959a09800fcae334e257a2f373ab).

do make install

run beaker console again and this shows an error.
opened by AtticusDavid 8
getState()?.counter.addresses.default missing "default" attribute when deploy the contract with --label
To replicate: follow the instruction on https://docs.osmosis.zone/cosmwasm/testnet/cosmwasm-beaker from "Install Beaker" to "Deploy contract on permissionless network" and inspect the content of the following files: frontend/lib/state.ts (line 15) and frontend/.beaker/state.json

At frontend/lib/state.ts (line 15), there's a usage for getState()?.counter.addresses.default to get the smart contract address. getState() will return the data taken from the file frontend/.beaker/state.json and frontend/.beaker/state.local.json. After further investigation, I've found out that state.json is missing the "default" property within "addresses" and the content is as follows:

"testnet": { "counter": { "code_id": 1479, "addresses": { "My first Beaker Contract": "<address>" }, "proposal": { "store_code": 56909 } } } }

This could be the problem from the code generation of Beaker.

I've tried running the following command with and without --label

beaker wasm deploy counter --signer-account test1 --network testnet --no-wasm-opt --raw '{ "count": 0 }' --label 'My first Beaker Contract'

and it seems that the --label is the cause of the problem.

My current workaround is to change the attribute name from "My first Beaker Contract" to "default".
opened by ApexTone 6
[Research] prost on osmosis proto
Generate rust types from osmosis proto to create StargateMsg for cosmwasm to call osmosis specific stuffs

copy/paste the generated type and test with StargateMsg
opened by iboss-ptk 6
[Bugfix / Enhancement] Broken beaker fix, docs additions

Purpose:

The purpose of this PR is to add beaker documentation related to building on top of custom beaker templates, some useful flags to get started & information for more command-line flags, and a fix to the currently broken beaker logo on https://stage-docs.osmosis.zone/developing/tools/beaker/#getting-started

Changelog:

Added an image link to the image in beaker's readme replacing direct path import Added content on custom beaker templates and some command line flags (redirection to docs folder added as well)

opened by xBalbinus 6
Add support for querying contract state and executing arbitrary contract messages
Are there plans to support querying contract state and executing arbitrary contract messages? This could be a wrapper around wasmd commands query wasm smart and tx wasm execute. I'm imaging commands like:

beaker wasm query mycontract --raw '{ "config": {}}'

beaker wasm query mycontract --signer-account test1 --raw '{ "increment_count": {}}'
opened by vernonjohnson 5

Wasm proposal.yml

Submitting a proposal is currently done this way:

beaker wasm proposal store-code --title "Testnet Contract" --description "Testnet Contract" --signer-account test1 --network testnet counter --gas 25000000uosmo --gas-limit 25000000

We should be able hardcode maximum gas (In mainnet this won't be more than 1 OSMO)

I think we could simplify this by making a yaml file instead or json. This will be really useful as the description can be quite long.

beaker wasm proposal store-code --proposal proposal_407.yaml counter

Example proposal.yml idea

title: Proposal to allow DappName to be enabled in Osmosis
description: |
            A lengthy proposal description
            goes here  
            we expect this to be many lines...
code:
    github:   https://github.com/osmosis-labs/beaker/
    reviewed_by: https://....
settings: 
    gas:  25000000uosmo 
    network: testnet

Notes

create struct that has all proposal options
make the struct subcommand compatible and serde serializable
allow serialization for toml, yaml
put the code part as a metadata structure in the proposal description

⚙️ task

opened by daniel-farina 4

Use keyring for signing (Signer-account)
For the signer-account option I think having a few predefined ones works well for localosmosis but for testnet/mainnet it would be best to use:

use system keyring so that I can use my own keys

option to specify the keyring backend

https://docs.cosmos.network/master/run-node/keyring.html

I guess we could call them: system-signer-account && beaker-signer-account?

This way we can allow people to request testnet tokens via the faucet for their own addresses, and eventually add an option to the faucet to approve contracts as well as we discussed yesterday.
enhancement ⚙️ task
opened by daniel-farina 4
Update ts codegen tooling
@pyramation just released cosmwasm-typescript-gen as @cosmwasm/ts-codegen

Let's use that now.

beaker wasm ts-gen xyz leads to:

Need to install the following packages: cosmwasm-typescript-gen
enhancement
opened by ethanfrey 3
Connect wallet component for the frontend template
What do you think about creating a reusable "Connect wallet" component?

What I'm talking about is pretty much RainbowKit, but for Cosmos. Making an extensible component for something like this may be important because alongside Keplr we have Cosmostation, Leap and other yet to be released wallets.

It will allow users to:

Get links to install extension-wallets

Connect to extensions and mobile wallets

Copy address, see the balance of a selected (probably staking) token

Change networks (maybe)

Devs to:

Have a single component that they can just drop into their app to get wallet connection functionality

Add custom wallets/chains by overriding config

Customize the look and feel of the modal

Enjoy the same API that RainbowKit offers (making it easier for devs to transition)
opened by fadeev 3
`Beaker new` project should have values in `.gitignore`
Currently a project generated from beaker new counter-dapp has a blank gitignore, this is one step we should automate out!

[ ] use https://github.com/github/gitignore/blob/main/Rust.gitignore as base

[ ] add artifacts (for wasm artifacts)

[ ] add **/state.local.json

enhancement ⚙️ task
opened by ValarDragon 3

Can't open beaker console after ts-gen

after type beaker console --network testnet,

the following errors show up in terminal.

counter git:(main) ✗ beaker console --network testnet
beaker[testnet] ◇ /Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/dist/index.js:315
        throw Error(msg);
              ^

Error: "CounterContract" not found in sdk.
    at errorIfNotFound (/Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/dist/index.js:315:15)
    at /Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/dist/index.js:269:27
    at /Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/dist/index.js:180:16
    at Array.map (<anonymous>)
    at mapKV (/Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/dist/index.js:178:49)
    at getContracts (/Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/dist/index.js:265:12)
    at initializeContext (/Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/src/console.js:82:22)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async run (/Users/agrajak/.npm/_npx/b773047406ff4129/node_modules/beaker-console/src/console.js:93:3)

Node.js v19.2.0
Error: Failed to execute npx

Steps to reproduce

beaker new counter ( and select `counter-example)
beaker wasm deploy counter --signer-account test3 --no-wasm-opt --raw '{ "count": 0 }' --network testnet
beaker wasm ts-gen counter
beaker console --network testnet

Enviroments

node v19.2.0
apple m1 air (apple silicon)
beaker 0.1.1

opened by AtticusDavid 4

Instantiate should not error when there is no store code proposal
Current Behaviour

When there is no store code proposal registered in beaker and run

beaker wasm instantiate c --signer-account test1

I causes

Error: Proposal store code not found for contract `c` on network `local`

Expected behaviour

I should not error and let user instantiate the contract
opened by iboss-ptk 0
Make Beaker js an npm package

Currently ts codegen / console are in ts land, which is now require non-scoped execution and polluted scripts in ts/sdk directory. It might make sense to package beaker as js lib that contains codegen logic wrapper and integrate nicely with beaker console, keep these logics in js land.

opened by iboss-ptk 0
Add top level CI support

Similar to https://github.com/osmosis-labs/beaker/issues/35

cw-template installs in the project itself, but that was designed for one-contract repos.

beaker could just strip out .github and .circleci from those folders (or we use a new cw-template branch).

What would be more interesting is a top level, multi-contract test harness. cw-plus has an example for monorepos, but I am sure that can be simplified (and remove some of our optimisations for 15+ packages in parallel)

opened by ethanfrey 0

Releases(v0.1.2)

v0.1.2(Dec 7, 2022)
What's new

fix ts-codegen compatibility issue

Source code(tar.gz)
Source code(zip)
v0.1.1(Sep 27, 2022)
What's new

update test validator mnemonic to be in-sync with localosmosis

fix typo in query execution (by @rrrliu)

Source code(tar.gz)
Source code(zip)
v0.1.0(Sep 22, 2022)
What's new

CosmWasm 1.1 support

Use programmatic approach to ts-codegen over cli approach, which gives more control to the developer.

scaffolding template update

minimal for no example, only skeleton type template

counter-example (no pun intended) has counter contract + frontend example

Migration

see v0.1.0 migration
Source code(tar.gz)
Source code(zip)
v0.0.8(Aug 29, 2022)
What's new

Bail on external command line error to avoid confusion

Add execute and query command (by @vernonjohnson)

Source code(tar.gz)
Source code(zip)
v0.0.7(Jul 18, 2022)
What's new

[bug fix] when contract name has "-" the .wasm artifacts will turn them into "_" hence it caused store-code to fail to find .wasm.

Source code(tar.gz)
Source code(zip)
v0.0.6(Jul 15, 2022)
What's new

Update and clear contract admin (#77)

Add instantiate permission option (#78)

Typescript sdk generation automation (#80)

Auto add wasm32-unknown-unknown build target when trying to build but doesn't exist (#81)

Source code(tar.gz)
Source code(zip)
v0.0.5(Jul 12, 2022)
What's new

Allow setting contract admin (#61)

Contract upgrade (#66)

Store code proposal file (yaml/toml) (#64)

Sync code_id from store code proposal based on its status (#70)

Allow using system keyring as a signer (#74)

Source code(tar.gz)
Source code(zip)

Owner

GitHub

Unified directories for different use cases of an application, providing standard directories for local development, when run as service or when run by a user.

UniDirs Unified directories for different use cases of an application, providing standard directories for local development, when run as service or wh

3 Sep 30, 2022

Beaker helps simplify CosmWasm development workflow.

Related tags

Overview

Beaker

Table of Contents

Getting Started

Reference

Getting Started

Prerequisites

Installation

Scaffolding your new dapp project

frontend and contracts

Cargo.toml

Beaker.toml

.beaker

Your first CosmWasm contract with Beaker

Deploy contract on LocalOsmosis

Contract Upgrade

Signers

Console

Typescript SDK Generation

Frontend

License

Comments

Grouping for wasm gov proposal types

Deployment and migration

StoreCode requirements

Deployment

Migration

reproduce environment:

step to reproduce

Notes

Steps to reproduce

Enviroments

Current Behaviour

Expected behaviour

Releases(v0.1.2)

v0.1.2(Dec 7, 2022)

What's new

v0.1.1(Sep 27, 2022)

What's new

v0.1.0(Sep 22, 2022)

What's new

Migration

v0.0.8(Aug 29, 2022)

What's new

v0.0.7(Jul 18, 2022)

What's new

v0.0.6(Jul 15, 2022)

What's new

v0.0.5(Jul 12, 2022)

What's new

Owner

CosmWasm-Examples is a collection of example contracts and applications built using the CosmWasm framework

CosmWasm/Sylvia counting contract w/ IBC enabled (Cosmos, Rust, CosmWasm, Sylvia)

Helpers crate to simplify ink! chain extension development

Examples and helpers to build NFT contracts on CosmWasm

My code for the terra.academy course on CosmWasm smart contracts

A CosmWasm Tutorial by Terra Academy.

A gRPC-based scripting library for interacting with CosmWasm smart-contracts.

A simple example demonstrating cross-contract calls in CosmWasm smart contracts

CosmWasm multi-contract testing framework

A Multi-chain Decentralized Exchange (DEX) built on CosmWasm for the WYND DAO.

Template for multi-contract CosmWasm projects

CosmWasm + zkVM RISC-V EFI template

A blazingly fast compiling & optimization tool for CosmWasm smart contracts.

An example CosmWasm contract for connecting contracts over IBC.

📦+🦀=♥️ A tool that helps wrap binary releases for easy distribution

A Software Development Kit (SDK) for Zero-Knowledge Transactions

Local blockchain for Free TON DApp development and testing.

This is the Repo used to learn blockchain development in conjusction with the CyberGen NFT Project.

Unified directories for different use cases of an application, providing standard directories for local development, when run as service or when run by a user.

`frontend` and `contracts`

`Cargo.toml`

`Beaker.toml`

`.beaker`