Abstract’s goal is to enable developers to build more powerful interchain dApps through collaboration, convention, and modularity. We provide a full-stack CosmWasm development experience, including smart-contract, middleware, and frontend tooling. The Abstract SDK streamlines the development of interchain applications with a powerful and easy-to-use modular application framework whose capabilities are fully realized via account-abstraction and our on-chain application infrastructure.

To learn more about our framework and our full developer vision, please check out our official documentation.

Introduction

The Cosmos SDK changes the game for blockchain-based applications. It allows for scalable development and deployment of application-specific chains by providing a well-defined framework emphasizing modularity. The “appchains” coincide with the fat application thesis, which states that the value lies in the applications themselves rather than in a shared, fat protocol like Ethereum or Solana. IBC enables interoperability between these appchains, and CosmWasm allows for the programmability of cross-chain interactions through a secure and efficient smart-contract environment. “inter-chain”

The Problem

It is difficult and slow to build CosmWasm applications. Teams start from scratch, and waste valuable time integrating primitives such as DEXes, money markets, oracles, and other DeFi building blocks. The fat app thesis encourages teams to drive value to their applications, consequently creating an environment of siloed development. This lack of inter-team collaboration hinders innovation and experimentation, and is partially why the CosmWasm ecosystem is relatively immature compared to the Ethereum and Solana ecosystems.

Secondly, while CosmWasm application updates (“migrations”) don’t require a replacement binary like chain upgrades, updates remain highly manual and dangerous, especially when multiple contracts are involved. This leaves user funds and team reputations at risk.

Finally, developing a cross-chain application requires deep prerequisite knowledge of IBC, proper handling of callbacks, error cases, and knowledge of interchain smart-contract security. Even for an experienced IBC developer, cross-chain interactions require new IBC ports, as well as channel and asset identification on both sides.

The Solution

We bring the modularity and scalability of the Cosmos SDK to CosmWasm applications with the Abstract SDK, our interchain application framework. The Abstract SDK is designed for organizations and individual developers to build composable, distributed applications in a fast, secure, and cost-effective manner. We place an emphasis on standardization and composability, congruent with well-studied smart-contract design patterns such as Ethereum’s Diamond Proxy Pattern (EIP-2535) and Web2 microservices and customized to the extensive capabilities of CosmWasm.

The foundation for every Abstract application is an Abstract Account, a smart-contract wallet. Modules, the smart-contracts built using the SDK, isolate shared logic and extend the functionality of the Account. This transforms it into an application. Module version management is performed via a permissioned on-chain module registry, allowing for dynamic application upgrades with protections against incorrect migrations. Inter-team collaboration is incentivized because modules can be monetized, providing sustainable income for developers and rewarding continued maintenance. Complex logic can be imported rather than rewritten.

The Abstract SDK provides easily-understandable abstractions for local and cross-chain interactions over IBC. Via an on-chain name service, assets, chains, and other resources can be referenced by name, rather than their complex identifiers. Abstract Accounts (and applications) can create and execute upon multi-hop interchain outposts developed specifically for chain-abstracted protocols and wallets.

Why?

Read about Abstract’s origins here.

Our goal is to help realize the ideal of full user sovereignty in ushering in the next generation of interoperable applications. The interchain becomes ubiquitous not only via technical superiority, but via a thriving developer ↔ user economy, the most important multi-sided market in Web3.

Our team consists of 7 highly experienced Web3 software engineers, and both our founders are technical. Abstract’s tooling has been in development for over 2 years.

Abstract’s framework and on-chain infrastructure is open-source, chain-agnostic to any CosmWasm-enabled chain, and allows control of and interoperability with any chain connected to IBC.

Abstract’s Interchain CosmWasm Tooling

Below we’ll go over the different components of the Abstract stack, servicing interchain developers.

Features TL;DR:

Production-Ready

• Abstract Account: Multi-chain smart-contract wallet
• Version Control: On-chain module registry with version management
• Name Service: On-chain name service for assets, contracts, addresses, chains (channels), and DEX pairs
• Abstract SDK: Modular CosmWasm application framework
• Console: Developer interface for managing Accounts, applications, and modules
• API: GraphQL API for quick contract queries and indexed information
• Interchain Abstract Accounts: Cross-chain smart-contract accounts

Pre-Release

• Abstract.js: Typescript SDK for use alongside the Abstract SDK
• EVM Interchain Accounts: Control and interact with any EVM chain

Abstract Accounts

Read more about Abstract Accounts here.

Abstract’s application architecture is centered around our smart-contract wallet, coined an Abstract Account. This serves as a secure vault for asset management and provides a base upon which modules can be installed, creating an application. Applications can be installed upon Accounts via sub-accounts. The Account is also responsible for cross-chain communications, handling creation of and communication with interchain Accounts.

This enables Account owners to “self-host” their applications on fully sovereign smart-contracts. This follows the natural evolution of decentralized finance (DeFi) to a new era of personalized, sovereign finance, which we’re coining MyFi.

Modules

Read more about Abstract modules here.

A module in Abstract is a smart-contract that can be installed on an Abstract Account to extend its capabilities. Modules can be installed, removed, and configured by the Account’s owner, allowing for a high degree of customization. Additionally, modules can take on dependencies on other modules and securely interact with each other.

App modules are instantiated and owned by one Account.

• Ex: ETF module allows the owner to manage the Account as an ETF. The module handles value calculation for deposits and withdrawals, and the owner manages the allocation.

Adapter modules serve as standard interfaces that facilitate communication between Accounts and various external services. They adapt a service to an interface.

• DEX Adapter: Provides a standard interface for performing actions on DEXes.
• CW-Staking Adapter Provides a standard interface for interacting with LP positions across Cosmos.

Integrations

Developers using the Abstract SDK can interact with the following services via standardized interface through Abstract’s adapter modules within minutes:

• Osmosis
• Kujira
• Astroport
• Wyndex
• Astrovault

Module Registry (On-Chain)

See the live module registry or read more on the Version Control docs.

On-chain registry of versioned contracts to their code ids and metadata. Allows developers to register and monetize their modules.

• abstract:dex:0.20.0 => juno...xxx
• abstract:etf:0.3.0 => 205

This “package registry” is one of the most important components in enabling truly composable apps. All Abstract Apps can pull updates from the modules registry, allowing applications to be dynamically updated with the Account owner retaining full sovereignty.

Abstract Name Service (On-chain)

See the live name service or read more on the ANS docs.

The ANS is a smart contract that stores the following data:

Assets: The most relevant assets on the local blockchain.

• osmosis>osmo on Osmosis => uosmo
• osmosis>osmo on Juno => ibc/...XYZ
• juno>dao on Juno => juno...xxx
• juno>dao on Osmosis => ibc/...YZA
• berachain>bera on Berachain => 0xAul...E3a
• berachain>bera on Union => factory/union...nkz

Contracts: Contracts related to certain protocols or applications that could be dynamically resolved. This could be used to store the address for an asset-pair for a dex.

• croncat/factory on Osmosis => osmo...xxx
• berachain>bex/crocsw on Osmosis => 0x9...osu

Channels: IBC channel data to map a protocol + destination chain to a channel id. This allows for dynamic IBC transfers without having to know the channel id beforehand.

• osmosis on Neutron => channel-5

Pools: Essential liquidity pools for DeFi protocols, mapping ANS-ID to pool-id or contract.

• astroport/neutron>ntrn,osmosis>osmo on Neutron => neutron...ua5
• berachain>bex/berachain>bera,union>uno on Union => 0xYo...b7a

Abstract SDK (Framework)

Read more about the SDK via its technical documentation and get started by building an app!

The Abstract SDK itself is the Rust-based CosmWasm framework with which developers write and test application modules. Applications using the SDK work seamlessly with the on-chain infrastructure. It provides common abstractions via traits for maximum ease-of-use and modularity.

All Abstract modules are easily testable using cw-orchestrator with out-of-the-box abstractions for Abstract Accounts and all other on-chain infrastructure.

IBC Capabilities

Abstract Accounts can create single- and multi-hop outposts on IBC-enabled chains, enabling cross-chain applications. Our on-chain IBC abstractions ensure that all actions are authenticated and relayed to the proper destinations, and allow for single-chain management of complex multi-chain infrastructure.

Typescript + React Developer SDK (Pre-Release)

Abstract.JS provides comprehensive means for interacting with applications built using the Abstract SDK. It is also provider-agnostic, meaning that developers can use either Graz or Cosmos Kit in their frontend development. The design patterns used by Abstract.js are largely based on high-quality Ethereum packages such as wagmi and viem. It additionally provides code-generation plugins for ts-codegen for readable clients.

EVM IBC (Pre-release)

We enable control and interaction with EVM-based chains with our proprietary implementation for interchain accounts on EVM via Union, one of our core partners. This gives the EVM ecosystem unfettered access to the Interchain and visa-versa, enabling the development of advanced cross-chain liqudity orchestration, application protocols, and even cross-chain SAFEs.

Application Console

Feel free to check out the mainnet and testnet Consoles, both of which are currently live.

The developer console allows teams to manage their applications built using Abstract. It provides GUIs for all on-chain infrastructure and Abstract Accounts. It also serves as the marketplace upon which devs can list and monetize their modules as described earlier.

Abstract API

Query the API here.

A chain-agnostic GraphQL API for accessing all of Abstract from anywhere. Supports custom configurations for any CosmWasm network with Abstract.

Case Studies

XION

Mint an NFT on Neutron directly from XION here! This demonstration walks you through each step of the process, though all actions can be fully abstracted away in practice.

XION is consumer-oriented chain focused on eliminating the complexities of Web3 interaction through “generalized abstraction,” offering users the ability to interact with apps and liquidity on any chain.

XION uses Abstract’s ICAAs to enable chain abstraction and for full control and programmability of any chain over IBC. We’ve had over 160K Abstract Accounts and over 400K transactions executed using Abstract’s infrastructure in just a few weeks of release.

FortyTwo Finance

FortyTwo is the interchain’s DeFi yield aggregator. It offers a single interface where users can manage their yield positions and understand their portfolios spread across any IBC-enabled chain.

One of FortyTwo’s primary products is a dex-agnostic autocompounder, which achieves maximum yield on pools across IBC. This leverages Abstract’s DEX and Staking adapters and scales to any pair on any dex on any chain.

Abstract makes developing single- and multi-chain applications easy. Developers should be able to focus on their business logic, and not the bulls**t. Users should be able to focus on the application, and not care the tech. Both of these ideals are realized through Abstract’s comprehensive interchain platform, all-the-while abstracting away the complexities of multi-chain development and interaction.

Additional Resources

Abstract Money Chain Abstraction

Acknowledgementns

We wish to give thanks to the open-source community and the many teams that we’ve worked with in improving the Abstract SDK to make the development experience as amazing as possible, including (but not limited to):

• Confio
• FortyTwo
• Yieldmos
• DaoDao
• Cosmology
• Xion

Abstract Changelog

Get in touch!

Follow Us on Twitter

A High-Level Overview of Abstract Money, Interchain App Platform was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

BOOT (by Abstract) simplifies all of this by providing a type-safe library and a standard way of deploying and interacting with your CosmWasm smart contracts.

Getting Started

The following sections detail setting up a library for interfaces and a separate package for the scriptsso that publishing the contract interfaces is easy.

Contract Interface Library

To get started with BOOT, create a new folder anywhere (though we often do it alongside our contracts in the same repository) called interfaces by running:

cargo init --lib interfaces

Following this example, the file structure will now look like:

.
├── Cargo.toml
├── contracts
│   ├── Cargo.toml
│   └── src
│       ├── contract.rs
│       └── ...
└── interfaces
    ├── Cargo.toml
    └── src
        └── lib.rs

If your cargo project is a workspace, be sure to add interfaces to the [workspace].members array at the workspace root.

Install boot-core

cd interfaces
cargo add boot-core
cargo add --path ../contracts

Then add any other dependencies, which should look similar to the following:

[dependencies]
boot-core = "0.1.3" # latest version as of writing this article
my-contract = { path = "../contracts" }
# common
cosmwasm-std = "1.1"
serde = { version = "1.0.103", default-features = false, features = ["derive"] }

Defining Contract Interfaces

The contract interface is what your scripts will be interacting with to deploy and manage the deployed instance of your contract. It provides accessible methods for interfacing with the contract entry points and can maintain state between script runs based on the deployment configuration.

First, create a new file in the src directory of the interfaces package, and add it to the library declaration file:

touch src/my-contract.rs
echo 'pub mod my_contract;' >> src/lib.rs

In your new contract file, define a struct for your contract interface and provide the [Instantiate|Execute|Query|Migrate]Msgs to the boot_contractmacro, which will generate fully-typed instantiate, execute, query, and migrate methods.

use boot_core::prelude::boot_contract;
use my_contract::{InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg};

#[boot_contract(InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg)]
pub struct MyContract<Chain>;

The generic “<Chain>” argument is to help the rust-analyzer with type analysis because sometimes the macro-expansion engine does not fully understand generically typed macros.

If your entry point Msgs have any generic arguments, pull them out into newtypes before passing into the macro.

Next, you’ll want to define the constructor for the struct defined above. In the following example:

use boot_core::prelude::{BootEnvironment, Contract};

// ...

impl<Chain: BootEnvironment> MyContract<Chain> {
    /// Construct a new instance of MyContract
    /// * `contract_id` - what your contract should be called in local state (*not* on-chain)
    /// * `chain` - the chain to deploy to
    pub fn new(contract_id: &str, chain: &Chain) -> Self {
        let crate_path = env!("CARGO_MANIFEST_DIR");
        // This can be the absolute path of the file like it is below
        // or it can simply be the name of the contract file like "my-contract",
        // and the path of that file set via WASM_DIR env variable
        let wasm_path = "../../target/wasm32-unknown-unknown/release/my-contract.wasm";
        Self(
            Contract::new(contract_id, chain)
                .with_wasm_path(wasm_path),
        )
    }
}

Notice that we build the Contract instance with_wasm_path, where we provide the contract name. This contract name will be used to search the artifacts directory (set by ARTIFACTS_DIR env variable) for the .wasm file of your contract. Alternatively you can specify a path to the released wasm after running RUSTFLAGS=’-C link-arg=-s’ cargo wasm . See the CosmWasm documentation on compiling your contract for more information.

Script

Now that we have the interface written for our contract, we can start writing scripts to deploy and interact with it.

Setup

Like before, we’re going to setup a new folder for our scripts. This time, we’ll call it scripts and initialize it as a binary crate:

cargo init --bin scripts

If your cargo project is a workspace, be sure to add scripts to the [workspace].members array at the workspace root.

Your scripts will have basically the same dependencies as your contract interfaces, but with a few additions:

cargo add --path ../interfaces

and also add the anyhow and dotenv crates:

cargo add anyhow dotenv log

Env Configuration

The dotenv crate will allow us to load environment variables from a .env file. This is useful for setting up the chain configuration for your scripts.

# .env
# info, debug, trace
RUST_LOG=info

# where the contract wasms are located
ARTIFACTS_DIR="../artifacts"

# where to store the output state data
DAEMON_STATE_PATH="./daemon_state.json"

# Mnemonics of the account that will be used to sign transactions
LOCAL_MNEMONIC=""
TEST_MNEMONIC=""
MAIN_MNEMONIC=""

IMPORTANT: Make sure to exclude the .env file in your gitignore.

Main Function

Now that we have our dependencies setup, we can start writing our script. Either create a new file in the src directory of the scripts/src package, or use the main.rs file that was created by default.

This function is mostly just boilerplate, so you can copy and paste it into your new script file. It will just call your function and give you nicer error traces:

fn main() {
    dotenv().ok();
    env_logger::init();

    use dotenv::dotenv;
    if let Err(ref err) = deploy_contract() {
        log::error!("{}", err);
        err.chain()
            .skip(1)
            .for_each(|cause| log::error!("because: {}", cause));
::std::process::exit(1);
    }
}

Deployment Function

First, we’ll define a function that will deploy our contract to the chain. This function will setup the environment (connecting to the chain), deploy the contract, and return a Result with the contract address.

// scripts/src/my_contract.rs
use anyhow::Result;
use boot_core::networks;
use boot_core::prelude::{instantiate_daemon_env, NetworkInfo};
// Traits for contract deployment
use boot_core::interface::*;
use interfaces::my_contract::MyContract;

// Select the chain to deploy to
const NETWORK: NetworkInfo = networks::juno::UNI_5;
const CONTRACT_NAME: &str = "my-contract";

pub fn deploy_contract() -> anyhow::Result<String> {
    // Setup the environment
    let (_, _sender, chain) = instantiate_daemon_env(network)?;

    // Create a new instance of your contract interface
    let contract = MyContract::new(CONTRACT_NAME, &chain);
    // Upload your contract
    contract.upload()?;

    // Instantiate your contract
    let init_msg = InstantiateMsg {
        // ...
    };
    // The second argument is the admin, the third is any coins to send with the init message
    contract.instantiate(init_msg, None, None)?;

    // Load and return the contract address
    let contract_addr = contract.address()?;
    Ok(contract_addr)
}

Additional Scripts

So you have your contract deployed, but what now? You can write additional scripts to interact with your contract. For example, you can write a script to query the contract state, or to execute a contract method.

Here’s an example of a script that queries the contract state:

// scripts/src/my_contract.rs
// use ...
use my_contract::{QueryMsg};
// ...

pub fn query_contract() -> Result<()> {
    // Setup the environment
    let (_, _sender, chain) = instantiate_daemon_env(NETWORK)?;

    let contract = MyContract::new(CONTRACT_NAME, &chain);
    // Load the contract address (this will use the address set from the previous deploy script)
    let contract_addr = contract.address();
    // Query the contract
    let res = contract.query(QueryMsg::Balance {
      address: contract_addr,
    })?;
    // Print the result
    println!("{:?}", res);
    Ok(())
}

And one that executes a contract method:

// scripts/src/my_contract.rs
// use ...
use my_contract::{ExecuteMsg};
// ...

pub fn execute_contract() -> Result<()> {
    // Setup the environment
    let (_, _sender, chain) = instantiate_daemon_env(NETWORK)?;

    
    let contract = MyContract::new(CONTRACT_NAME, &chain);
    let contract_addr = contract.address();

    // Execute a contract method
    let res = contract.execute(ExecuteMsg::UpdateBalance {
      address: contract_addr,
      balance: Uint128::from(1000000u128),
    })?;
    // Print the result
    println!("{:?}", res);
    Ok(())
}

Refinement

You can also refine your contract interface to make it easier to use. For example, you can create a function that will execute a specific contract method and return the result, instead of having to call contract.execute and contract.query separately.

// interfaces/src/my_contract.rs
// Import the boot traits
use boot_core::interface::*;
// ...


impl<Chain: BootEnvironment> MyContract<Chain> {
    pub fn new(contract_id: &str, chain: &Chain) -> Self {
      // ...
    }
    
    /// Query the balance of an address
    /// `address` - the address to query
    pub fn balance(&self, address: Addr) -> Result<BalanceResponse> {
        let balance_query = QueryMsg::Balance { address };
        self.query(balance_query)
    }
    
    /// Update the balance of an address
    /// `address` - the address to update
    /// `balance` - the new balance
    pub fn update_balance(&self, address: Addr, balance: Uint128) -> Result<ExecuteResult> {
        let update_balance_msg = ExecuteMsg::UpdateBalance {
            address,
            balance,
        };
        self.execute(update_balance_msg)
    }
}

References

• Boot Core
• Boot Cw-plus
• Abstract Contract Interfaces

Deploying and scripting your smart contract using BOOT was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: this article is outdated and will be updated shortly.

This guide will walk you through the steps to create a CosmWasm smart-contract module using Abstract. You will be able to leverage other modules, interact with OSes, and deploy your contract all from one repository.

Overview

Scaffold Generation

Open a terminal window and run the following command to generate the scaffold app on your machine:

If you don’t yet have it installed you can install it with cargo install cargo-generate

cargo generate gh:Abstract-OS/app-module-template \
               --branch template \
               --name <module-name>

The above will clone the template repository into <module-name> which will be the name of your Abstract module.

All message structs will be prefixed with this module name as well. Ex: ModuleNameInstantiateMsg. This is to differentiate from the actual InstantiateMsg (the true entry point) imported from abstract_os.

This name will also be the base name for most module-specific variables in the app. From here-on-out, the examples in this guide will be using “balancer”. This name will be the base name for most app-specific variables in the app as mentioned above.

Project Structure

Open the module-name folder, where you will find the following folders:

• contracts: your CosmWasm smart contracts
• interfaces: Rust deployment interfaces for your smart contracts
• scripts: scripts for deploying your module to Abstract Version Control and for writing tests

Now that you have a fresh template, you are ready to start writing your module.

cargo fmt # cleanup any template residuals
cargo build

Contract Structure

All the following files are referenced from contracts/src directory. If you’ve ever written a CosmWasm smart contract before, this should be pretty standard aside from the contract.rs entry point.

msg.rs

Message declarations for your module. Here you will find the entry-point msg declarations as well as their responses.

error.rs

Human-readable error declarations for the module.

state.rs

The actual state stored on-chain for your smart-contract. Item and Map are both from the cw-storage-plus library, which provides powerful storage abstractions.

Commonly-used state like the Admin and Contract Version are already provided natively by the Abstract-SDK and exposed to your handlers (details below 👀)

contract.rs

This file serves as the overall entry point into your module. Abstract provides a wrapper around the CosmWasm entry points, and exposes their configuration to you through the AppContract type. Your module-specific types for error, messages, and receive are then all encapsulated into a single new type: <ModuleName>App.

pub type BalancerApp = AppContract<
    BalancerError,
    BalancerExecuteMsg,
    BalancerInstantiateMsg,
    BalancerQueryMsg,
    BalancerMigrateMsg,
>;

Further down, we can see that our APP is an instance of this <ModuleName>App which declares each of the handlers for instantiate, query, execute, migrate, and replies.

const APP: BalancerApp = BalApp::new(MODULE_NAME, MODULE_VERSION)
    .with_instantiate(handlers::instantiate_handler)
    .with_query(handlers::query_handler)
    .with_execute(handlers::execute_handler)
    .with_migrate(handlers::migrate_handler)
    .with_replies(&[(EXAMPLE_REPLY_ID, handlers::example_reply_handler)])
    .with_dependencies(&[EXCHANGE]);

The dependencies specify which modules your users need to have installed in their OS to interact with the module. By default, the template declares the abstract:dex module as a dependency.

Finally, a Rust macro takes the type and const declaration of your app to export the actual CosmWasm entry points from your contract.

export_endpoints!(APP, BalancerApp);

handlers

All of the handlers for the messages sent to your contract (declared in msg.rs) are held within the handlers directory, and the appropriate messages can be handled via match statement.

Below is the ExecuteMsg handler for Equilibrium’s balancer module.

pub fn execute_handler(
    deps: DepsMut,
    _env: Env,
    info: MessageInfo,
    balancer: BalancerApp,
    msg: BalancerExecuteMsg,
) -> BalancerResult {
    match msg {
        BalancerExecuteMsg::Rebalance {} => rebalance(deps, info, balancer),
        BalancerExecuteMsg::UpdateAssetWeights { to_add, to_remove } => {
            update_asset_weights(deps, info, balancer, to_add, to_remove)
        }
        BalancerExecuteMsg::UpdateConfig { deviation, dex } => {
            update_config(deps, info, balancer, deviation, dex)
    }
}

The <ModuleName>App acts as an adapter between your contract and the Abstract SDK, exposing Abstract Name System, other module functionality, asset value calculation, and much more. Read more in the Abstract docs.

Deployment

Interfaces

Within interfaces is a template.rs file that declares the deployment interface for your module. By default, the new function should be enough to deploy the contract but you can add additional functions to perform more advanced actions. See abstract-boot for more examples.

Scripts

To make your module available for other OSes to install on a local, Testnet, or Mainnet network, you can deploy your module directly from the template repo.

1. Configure Deployment Env

Rename the example env

# in the root
mv .env.example .env

Configure the variables (this example uses uni-5 Juno testnet)

# human-readable name of the chain
CHAIN="juno"
# name of the deployment to be exported 
DEPLOYMENT="v0.0.1"
# "local" | "testnet" | "mainnet"
NETWORK="testnet" 

# Mnemonic of the account that will be used to deploy the contracts (admin)  
TEST_MNEMONIC=""
# Abstract version control address for app deployment  
VERSION_CONTROL_ADDRESS=junoxxx

The Abstract version control address can be found on https://beta.abstract.money/deployments (check our discord for when it is available)

2. Configure the Deployment Network

In src/bin/deploy_app.rs, configure the network to instantiate the daemon to be UNI_5 for Juno testnet or JUNO_1 for Juno mainnet. Other available networks are exported from boot_core (docs).

use boot_core::{instantiate_daemon_env, networks::juno::{JUNO_DAEMON, UNI_5, JUNO_1}};

pub fn deploy_app() -> anyhow::Result<()> {
    let network = UNI_5;
    //...
}

3. Deploy to Version Control

Run the following command:

cargo deploy

…and your module will be registered to Abstract Version Control. You can verify this by going to https://beta.abstract.money/ans (soon) and checking the registered modules.

Need help?

Connect with us on Discord! We’d be happy to help you with any questions, feedback, or suggestions.

References

• Introduction | CosmWasm Documentation

Getting Started with Abstract — How to create your own App Module was originally published in Abstract Money on Medium, where people are continuing the conversation by highlighting and responding to this story.